My RBAC Heresy
The ANSI RBAC standard is incomplete. There, I’ve said it. The RBAC inquisition can torture me all they want, but I won’t recant. I’m sticking to my heretical view.
ANSI/INCITS 359-2004, originally crafted by NIST, defines the logical construct for role-based access control, and has become holy writ for those of us going down the RBAC path. I recently talked about an additional object not part of the RBAC model, and got pushback from some colleagues because it’s not part of the canonical NIST scripture, so to speak. So let me lay out my case for this heresy.
The RBAC model shows users related to roles, which are related to permissions. At the time of execution, this is all that’s necessary: if the user is a member of a role that provides the appropriate permission, access is granted. But this model is not sufficient for the engineering of roles up-front.
An enterprise has a set of users, each of whom is entitled to a set of permissions. We want to define a set of roles that will aggregate permissions in a way that is useful to the business and reflects the way the business operates. We can start this task by creating a permissions matrix with all users listed down the side, and all permissions listed across the top, and a binary indicator in each cell showing whether this user is entitled to this permission or not.
This is quite a matrix. Besides it’s size, it has a few drawbacks. For role engineering, we don’t care which users have certain permissions, but we do care why certain users have certain permissions. We want to be able to automatically provision/deprovision users to roles based on their identity attributes. User ID or user name are irrelevant, but the profile of the user’s identity attributes, such as job title, job code, location code etc. (assuming they’re an employee) are very relevant.
As I’ve written before, there are two domains to the role engineering problem: a) mapping permissions to roles and b) mapping users to roles. A user-permission matrix may help for the first, but it won’t for the second. And it is more unwieldy than it needs to be even for the first problem domain.
All we really care about for role engineering is defining roles that will cover each unique combination of values for the identity attributes. This set of unique-combination-of-identity-attribute-values represents the provisioning requirements that need to be supported by roles. While “unique-combination-of-identity-attribute-values” does seem to roll right off the tongue, I have been using a different term: job. Granted, this term really only works for internal users, excluding customers, partners or other external users. But at least for internal users, this term is descriptive, and doesn’t require a lot of explanation to the layperson.
We don’t care if 1,000 employees have a single job, or one (at least initially). The job is entitled to a set of permissions for which roles must be defined. In fact, another way to think of the job object is as a unique combination of permissions. (If we have perfect identity data, these two definitions will give us the same result, but in practice we don’t, so they diverge a bit.)
So for the purposes of role engineering, we have a new object: users are related to jobs, which are related to roles, which are related to permissions. Once the roles and the user-to-role mapping rules have been defined, the job object can be bypassed.
So even though I too worship at the altar of the ANSI RBAC standard, I have come to add a new book to the RBAC bible. Just don’t burn me at the stake.
