Are roles the right way to control access?
In some cases, clearly yes — there’s a whole formal model of role-based access control (RBAC) out there and it’s worked well in some business contexts for years.
But in other cases, just as clearly, RBAC is inadequate.
I raise this because in the context of an identity management system, one of the things we have to do is control who has access to whose profile. For example, can one employee see another’s work phone number? Home phone number? Scheduled termination date? Who can edit these things?
It turns out that pure RBAC is a poor model for access controls in these cases.
If we use RBAC, then we have to define roles for users who can access this data. Whose data can they access? Everyone’s apparently. For example, we might say that “all employees can access the work phone numbers of all users.” Sounds reasonable. Another example might be “only HR can access home phone numbers and scheduled termination dates.” Is that reasonable too?
If we think about these examples, we have to conclude that RBAC isn’t up to the task. For example, do we allow one HR user to see another HR user’s scheduled termination date? What about his own? If Bob in the corner (who happens to work in HR) is going to be terminated on Friday, should he know that? That’s a security problem.
What about usability problems? I would think that co-workers should be able to find one another’s home phone number. What happens if someone is hurt at work and you want to contact their family? How about if there is an emergency off-hours and you want to call someone to see if they can help? Clearly, we want to open up home contact information — not to the entire organization, as this could raise privacy concerns — but perhaps to people in the same department or location.
The same thing applies to scheduduled termination dates. It would be useful for managers to be able to see and change these for their subordinates. For example, a manager responsible for a large segment of the organization might want to periodically see what contractors are due for termination in the coming few weeks and perhaps extend some contracts to allow for unfinished work. On the other hand, the same manager should not be able to see his own scheduled termination date, or that of anyone who does not report to him.
The common thread that runs through these scenarios is relationships. What one user — lets call him the requester — can see of and modify in another’s profile — lets call the second user the recipient — should depend not merely on the requester’s role, but also on the relationship between the requester and recipient.
That’s the context of access control decisions inside an identity management system. In other systems, context may include other things — how is the requester related to the data he wishes to access?
And this is where RBAC falls short. To make access control decisions about what a given user can see or do, we need more than the identity of the requester — we need context for their requested access. In identity management, that context is a relationship.
So why do I bring this up?
In previous releases of Hitachi ID Identity Manager, access control within our software was built on an RBAC model. What I’ve seen of other, competing products is the same — access control decisions are made based on the requester’s role and usually nothing else.
Organizations that wanted to manage sensitive data in their IDM system would then either have to exclude it, reducing the value of their investment, or write lots of custom code, increasing the cost of their system. These were not good options.
Starting with release 8.0 of Hitachi ID Identity Manager, we completely overhauled our internal access control model. Our customers first define relationships and then attach access rights to those relationships. Relationships can be anything — manager/subordinate, same-location, same-department, etc. Really any set of criteria based on each user’s profile attributes and group memberships.
This means that with Hitachi ID Identity Manager 8.0, organizations can easily model their real-world requirements, without resorting to custom logic. Want to allow managers to see/edit termination dates for their subordinates? No problem. Want branch office IT staff to be able to reset passwords for co-located users? Easy. Want to block HR staff from seeing their own termination dates? Simple.
Call us and try it out. You’ll be impressed by the difference a smarter access control model can make.