Delving deeper into Relationship-based RBAC
Ian Glazer thinks that I have opened Pandora’s box by talking about the need to bring context and intent into the area of RBAC by using relationships (one of many ways to express context). I think it’s a topic ripe for some discussion, so I’m glad to be the one taking the lid off.
Mat Hamlin left an interesting comment on my previous post, in which he tried to understand what exactly I was trying to say. He asks:
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?
Let me explain how relationship-based roles are defined, and how they address the scenario I posed in my previous post.
When discussing Relationship-based RBAC, one will usually find that, by necessity, the access control policies are defined by people different from the people who will manage relationships. Thus, the admitting nurse or the triage desk may create an “Assigned Doctor” relationship between Dr. X and Patient Y when Patient Y is admitted. These people, working the front line, are unaware (as they should be) of access control issues and needs. Their job is to simply find a doctor to assign the patient to. They are usually the ones making decisions about the creation of the relationship based on things like whether the patient is an infant, what specialization the doctor has, etc.
The folks designing the access control policies in the back-end systems want to set up a policy that defines what the doctor assigned to a patient has access to in the system – charts, history, personal information, etc. So they define an access control policy that states that anybody in the “Attending Doctor” role has access to resources “Charts”, “History”, “Personal Information”, etc.
The real meat is in defining the “Attending Doctor” role, and how it is used in the system. A relationship-based role is a new kind of structure, different from statically defined roles, or dynamically-defined (Attribute-based) roles that we see commonly in systems today. Most roles simply have a member concept, and an authorization decision based on a role simply looks to see if the interacting user is a member of the authorized role. However, a relationship-based role has a member relationship concept, with each relationship having two end-points. So in Relationship-based RBAC, the authorization decision is based on looking at the member relationship of the role, and determining if the interacting user is one end of the relationship, while the protected resource is connected to the other end of the relationship.
Thus, you can have 100s of doctors connected to 1000s of patients using the “Assigned Doctor” relationship, but 1 “Attending Doctor” role that knows how to handle those many 1000s of relationships in its authorization context.
This is a very powerful concept, especially as social graphs start making their way into enterprise application contexts. So we are going to see more need for systems that handle this kind of need.
About The Author
Any time we look at roles, we need to remember that roles must be considered in association with policy. Policy is a set of one or more rules used to determine an outcome. This seems to be the territory that the Attribute-based Access Control approach is addressing, whether the attributes represent a “role” or any other characteristic. It would be ill-advised to try and represent every alternative with a role, when a role+attribute(s) combination can be used to address the problem more directly. It remains to be seen how deeply we can articulate relationships (each additional attribute adds to the complexity of the evaluation), but this is certainly heading in the right direction.
Roles are fairly static; policies and attributes enable situational evaluations. This balance limits the proliferation of roles, as well as the explosion of policy-driven environments that are equally difficult to manage.
Another challenge is to clarify what a role represents. A business role is an articulation of a business relationship or responsibility. A technical or IT role is a set of privileges or tools that are used to accomplish the business role. Business roles map to IT roles. If you try and merge the two into one, you come up with an IT role. It becomes difficult to ascertain what it was or is intended to accomplish, and it becomes inflexible, bound to an application.
Remember the balance between roles and policies, and between business and IT roles. It makes the definition and evaluation process much more effective and easier to manage.
Kevin’s statement: “Roles are fairly static; policies and attributes enable situational evaluations.” concisely and effectively echos my ramblings in the original comment.
The relationship between individuals could be modeled as a relationship between roles, but the relationships themselves would have to be “related” with a rule or policy… correct? This is the gap that I am not sure we can or should span in the standard.
In your scenario, the connection is made by the admitting nurse, and I assume this connection is established via attributes of existing objects such as the User record or Appointment record.
So the Relationship Based Role would provide access to charts, history, and personal information of a Patient to a Doctor, if … the defined policy returns true (to establish the relationship).
This Relationship Based Role would be helpful in developing and understanding access controls for real-time enforcement like in an SSO solution, but does not provide a lot of value to applications like provisioning and access certification, where static definition are needed.
…and just a quick comment on the Business Roles and IT Roles discussion. I would add that modeling role types (Business, IT, and others) provides value in the management of the Roles themselves.
Such as:
* Only Business Roles can be directly assigned to users
* Only “Administrators” can edit IT Roles
* Business Roles can only contain other Roles, and not direct entitlements
* All Business Roles must be approved by HR
For more of my comments on this, please follow this shameless plug to more of my rambilngs
Firstly let me say that this pandora’s box should have been opened a long time back. Relationship based RBAC is something that is seen more and more common in enterprise applications. Every vendor has tried to implement this in their own way and a couple of interesting research articles have been written on this, but a standard solution has not been implemented.
The crux of the problem is simple – every user has a role to play in the system, and based on this role the user is allowed to perform certain actions (for e.g. viewing a record, modifying a record, or some other custom action). These action should only available to the user within a certain context. One of the facets of this context is the relationship the user has with the resource the user is trying to perform the action on. So for example, lets assume there is a role called Doctor. Using the regular RBAC how can you specify the following control access rule: “Doctors are allowed to view patient records for only those patients that have been treated.”? After a while you will realize RBAC will not let you do this easily because you will end up creating a Role called Doctor and a permission called “View patient record” and associate this permission to the Doctor role.
What we really need to be able to do is to create a relationship between the Doctor and the Patient record and based on that relationship give the appropriate permissions.
I do hope that this is only the beginning of a discussion that can spawn off a standard solution for implementing relationship based RBAC.