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.
Comments (2)
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.
Posted by Kevin Kampman | July 14, 2008 12:32 PM
Posted on July 14, 2008 12:32
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
Posted by Mat Hamlin | July 16, 2008 2:44 PM
Posted on July 16, 2008 14:44