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.