Why Role Based Provisioning is not RBAC

Talking with peers in the Identity space, it continues to strike me how two fundamentally different concepts remains a topic of confusion. I am specifically referring to Role based provisioning versus Role Based Access Control (RBAC).

RBAC is an approach to restrict system access to users with the appropriate authorization and enforced on the access control layer. RBAC is a non-discretionary access control mechanism which promotes the central administration of an organizational specific security policy.

This pattern of modelling access control has been around for a long time and with the raised compliance concerns of Segregation of Duties (SoD), RBAC have shown to be an effective model to enforce this within the enterprise - therefore also widely used.

Role based provisioning is the concept of clustering or grouping the way entitlements and attributes are being provisioned to target resources, for instance a particular role might imply a set of groups in the corporate Active Directory (AD) as well as access to a financial reporting system. The groups in AD would be entitlement carrying attributes, but the provisioning role wouldn’t be limited to these and could of course also define other attributes such as department and division.

Role based provisioning relies upon the target system to be the enforcer of the authorization layer. Of course the provisioning of entitlements can contain policies ensuring that SoDs are being considered and honored. Perhaps this is where the confusion occurs? Perhaps the terminology is being used too relaxed among identity vendors.

In the modern world of mobile users, connected wirelessly on portable devices such as tablets or smartphones creates a new set of challenges which quickly introduces the discussions around context aware access controls. Context of course being nothing more than a set of key value pair attributes defining where you are, what device you are one, time zone you are in or whatever it might be, but still simply attribute data derived from or provided by the user and associated device.

Analysts, such as Gartner, predict that by 2020, 70% of enterprises will use attribute-based access control (ABAC) as the dominant mechanism to protect critical assets, up from less than 5% today.

Fair enough, even though i believe that statement when i see it in reality - but lets not confuse this with role based provisioning, which serves a completely different purpose. Lets try to defuse the confusion by defining the two models.

• A role-based access control (RBAC) model grants access to resources based on a user role, such as the user's job title or work responsibility. (Here we are talking authorization and its enforcement)

• A role-based provisioning model, automates the access entitlement provisioning process for a specific managed resource, based on the roles to which the user belongs. (Here we are talking how to set attributes, entitlements carrying or regular attributes, not how to enforce them)

What’s funny about Gartner’s predictions, is the specific explanation on how “RBAC is one-dimensional because it cannot take context in the equation and will therefore fail to address challenges.”, the analyst seems to have missed the specific paragraphs in the NIST standard about static and dynamic constraints as well as temporal constraints, addressing the topic of contextual information and recent publications and research such as http://csrc.nist.gov/groups/SNS/rbac/documents/kuhn-coyne-weil-10.pdf. Basically allowing for attributes to dynamically impact the roles.

Having said the above, i do believe that context will become increasingly important but when jumping in to these discussions, please note the difference between these two concepts.