My Next Attempt at Controversy: Roles and the (ir)relevance of NIST
Well, I think I am done talking about directories now, especially after reading Ian Yip’s hilarious recap of the debate, as it were. Having now appeared as a significant bit player in this drama, I have decided to leave it in the hands of more capable people like Clayton and am moving on to familiar (and hopefully fertile) ground.
Day 2 of the Catalyst Conference turned towards the more pragmatic topics of role management and provisioning. It was with a great deal of interest that I heard Tim Weil discuss a standards effort he is leading to promote the implementation and interoperability of RBAC components. As I understood it, the goal is to make it easy for roles defined in one system (say ORM or SailPoint) to be used in another system (OIM or Sun IM), without having to do massive integration projects. Burton’s Kevin Kampman has blogged about this if you are interested.
Tim’s perspective on this is very relevant, having dealt with such practical issues through numerous implementation projects while at Booz Allen Hamilton. It was this very perspective that I wanted to tap into by asking him a question that vexes me a lot, but he gracefully sidestepped since it wasn’t directly related to the talk he was giving. However during a Twitter exchange with Ian Glazer I promised to explain my side fully in a blog post, so here goes.
My Question To Tim
Is the NIST RBAC standard fundamentally flawed, given that it is missing a key element in access control decisions – relationships, the very thing that Burton spent day 1 of the conference stating was the missing link for IdM to tackle?
My Thesis
It is, and companies looking to the NIST RBAC standard as the template for how to approach role management are going to end up missing the boat.
My Rationale
In a conversation later with Ian and Lori, I illustrated my case with the following access control examples:
Scenario A
A doctor wants to enter a hospital he is assigned to, presumably using a physical access device like a Honeywell card. In order for the doctor to get into a hospital, all he needs is for his identity in the system to have a “Doctor” role that is checked for when he enters the hospital. This is a simple scenario that the NIST RBAC standard can easily take care of.
Scenario B
However, in order for that doctor, Dr. X, to view the medical charts (electronically) of a particular patient, Patient Y, the good doctor not only needs to have a “Doctor” role, but also needs to have the “Attending Doctor” role WITH RESPECT TO Patient Y. In other words, the Access Control around the medical charts is based on a specific relationship established between Dr. X and Patient Y, that could be expressed as a relationship-based role. NIST RBAC seems to be wholly unequipped to handle this use case.
NIST RBAC is an important tool to any discussion on role structures. But it should not be treated as complete by any means, merely a start. The use case illustrated in Scenario B is rapidly becoming the more common use case, as Fine-Grained Authorization needs and Data Security come front-and-center in the discussion around Access Control. Yet work on resolving such scenarios is currently excluded from discussions on RBAC and left up to the ABAC crowd (learn what is ABAC here). Having two different mechanisms to implement security (often in the same systems) will surely lead to more holes than a chunk of swiss cheese.
Those that feel this is promotion for our ORM (formerly Bridgestream) product should know that it is not, since the relationship-based roles concept that they created has so far been limited to approval use cases, and has not made its way into any access control discussions. One reason I feel this isn’t happening is because it seems no one has figured out how to express this in an XACML policy, which can easily handle ABAC, but not Relationship-based RBAC. This led to the next controversial question I asked at Catalyst, which I will bring up in a later post.
I’d love to hear other perspectives on this, so leave me some comments.
About The Author
I assume that in Scenario B the user was Dr. K instead of Dr. X, all access would have automatically been granted.
To what extent could these relationships be modeled in a standard?.. and is it enough.
Regardless of the depth of standardization of RBAC, there will still be ABAC definitions that will encompass Roles, Role Relationships and other attributes
In your scenario, is Patient Y in a particular Role that has a relationship with the Attending Doctor Role? Or is it attribute based? Role to Role relationships could be modeled, but real-time, logic based Role to attribute (or individual) relationships fall outside Role definition, IMO.
There are too many scenarios pertaining to the relationship of the two individuals (and the surrounding conditions). What if Doctor X is not allowed to treat infants, and Patient Y is an infant. Or what if Doctor X is a contractor and is not allowed to treat patients with a certain insurance? Or has this patient ever reported a complaint against this doctor? What if this data changes often?
Role to Role vs. Role to Individual vs. Individual to Individual… Where do we draw the standardization line?
Nishant –
Thanks for drawing attention to my Catalyst 2008 talk on the INCITS CS1.1 standards activity – RBAC Implementation and Interoperability. I remember your question regarding the weaknesses in the RBAC model. At the time I had about 45 seconds on the teleprompter and this was not going to provide a substantive answer to your remarks.
Have a look at SailPoint’s Open Role Exchange forum
http://openroleexchange.org/
which is a follow-on activity related to the CS1.1 work. I also intend to address your comments about access control and relationships going forward. My first take that this is in the context of ‘functional vs. structural roles’, an area highlighted in the CS1.1 draft and more fully developed in the HL7 RBAC research.
Cheers
Tim Weil
Vice Chair – INCITS CS1.1
http://cs1.incits.org
There is no controversy as most folks agree. The challenge however is in coming up with a deeper industry playbook regarding how to approach roles and relationships.
The open role consortium is a great first step and I hope that Oracle will show leadership. If not, I can start my own controversy for lack of participation…
Is the NIST RBAC standard fundamentally flawed, given that it is missing a key element in access control decisions – relationships?
Your thesis :an unequivocal “yes, it is” – seemed to be flawed also.
The Access Control around the medical charts of Y is based on a role Ri which defines a specific role of the doctor who treats the set of patients Pi where i goes from 1..n
Fundamentally, NIST model is not flawed but requires some additional roles to be defined and that is an operational matter. That does not make the fundamental theoretical strength of the NIST standard flawed.
We can not have a new theoretical model to cater for each of the new roles that might require to be created.
The strength of the NIST model lies in its ability to be extended to include all special circumstances by creation of certain additional roles.
If you feel strongly that relationship extension will make the NIST model really fool proof and propose a new standard in a formal peer reviewed paper, within minutes, some one will come out with a special case where that model also does not address the very special case.
If a special case can be addressed by creating a new role, the original standard does not need extension or modification, or else, we are in a slippery slope with all standards! That is not a very safe ground to be on for any one seeking the comfort of a standard!
Chandra
Chandra Nath,
Your solution for solving the use case using static roles is the very solution that companies try to avoid as it leads to an explosion of roles (Ri, as you put it, where i will reach into the 10s of 1000s very quickly). If it was simply defining a role, this would not be a problem. But each such role has to be associated with a new policy, which is a cumbersome task.
No standard worth is salt is born fully defined. Most standards go through several iterations (look at SAML or SPML), usually driven by a better understanding of prevalent and emerging use cases. I agree that you cannot keep changing the standard for every edge use case, but the relationship-based scenario is not an edge case, it is a significant portion of the use cases that exist across different verticals – government, military, healthcare, higher ed and retail (and those are just the ones I have seen). Adherence to the principles of NIST RBAC have forced one customer into a design involving over 50,000 roles because of data striping. That is not a sustainable solution when better ones are possible.
Scenario B describes a one-to-many relationship between users and resources (one doctor needs permission to access many patient records). The RBAC model was primarily developed as a solution for many-to-many relationships (i.e., where many users can share common permissions to many resources). The key benefit of RBAC roles is the sharing of common permissions.
In order to grant each doctor permission to specific patient records, the RBAC solution would require the creation of a special role for each doctor (e.g., Doctor X’s ‘Attending Doctor’ role). Yes, this would result in an explosion of roles, but the RBAC model still works.
Since Scenario B is fundamentally a one-to-many situation, managing these doctor-to-patients policies will always be a cumbersome task. There is no technology that can get around the mathematics of it.
Another point of view is: The role is “Doctor of patient M”. Since the many part is “patient M” it is the the patients who are assigned to the role.
The role “Doctor of patient M” should be created as a child of the “Doctor X” user object. The role should be created automatically by the implementation whenever a user is assigned to the “Doctor” role. In this case we would have object specific roles, and not relationship roles, wich (I think) is also not considered in the standard.
I just stumbled over this as I’m working on a project in my college. I don’t know what NIST RBAC is but we basically have the same problem in our project.
Role(Doctor)
Resource(Patient)
Privileg(medicate)
Person(Doctor X, {Role(Doctor)})
Person(Doctor Y, {Role(Doctor)})
Rule(Role(Doctor), Resource(Patient), Privilege(medicate), restrictive = true)
Resource-Instance(Patient, Patient A)
Resource-Instance(Patient, Patient B)
Restriction(Person(Doctor X), Resource-Instance(Patient, Patient A))
Restriction(Person(Doctor Y), Resource-Instance(Patient, Patient B))
allowed(Person(Doctor X), Resource-Instance(Patient, Patient A), Privilege(medicate)) = true
allowed(Person(Doctor X), Resource-Instance(Patient, Patient B), Privilege(medicate)) = false
As the given rule is “restrictive” restrictions must be checked. Using this approach you can keep the actual RBAC very simple but extend it with a lot of restrictions to achieve your requirements.
It’s still only a blueprint but should work well even with role and resource inheritance.
Best regards
Felix
NIST RBAC is an important tool to any discussion on role structures. But it should not be treated as complete by any means, merely a start.