Comments on: My Next Attempt at Controversy: Roles and the (ir)relevance of NIST

By: mac to ipod

mac to ipod — Mon, 05 Apr 2010 13:42:24 +0000

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.

By: Felix-Johannes Jendrusch

Felix-Johannes Jendrusch — Wed, 09 Sep 2009 17:01:39 +0000

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

By: Alejandro Lapeyre

Alejandro Lapeyre — Thu, 23 Apr 2009 10:53:38 +0000

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.

By: Philip Jackson

Philip Jackson — Sun, 10 Aug 2008 04:55:46 +0000

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.

By: Nishant Kaushik

Nishant Kaushik — Fri, 18 Jul 2008 23:35:04 +0000

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.

By: Chandra Nath

Chandra Nath — Thu, 17 Jul 2008 19:38:50 +0000

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

By: James

James — Sat, 12 Jul 2008 15:56:28 +0000

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…

By: TIm Weil

TIm Weil — Sat, 12 Jul 2008 15:03:46 +0000

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

By: Mat Hamlin

Mat Hamlin — Fri, 11 Jul 2008 16:45:16 +0000

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?

By: Ranjeet

Ranjeet — Wed, 09 Jul 2008 23:14:24 +0000

I assume that in Scenario B the user was Dr. K instead of Dr. X, all access would have automatically been granted.