Role Based Access Control + Data Ownership based permissions

Question

Is there a common system or pattern that combines the permissions given by a role in a RBAC-system with permissions in relation to data ownership?

For example:

Bob is a doctor and has the role with the privilege 'view patient details'
but only if 'patient is assigned to doctor Bob'

the above example places the relation on the Actor (Doctor Bob in this case) but I'm actually looking for group-based solution:

For example:

Bob is a doctor and has the role with the privilege 'view, patient details'
Bob is a member of group 'A'.
Bob can view all patient details for patients assigned to group 'A'

My question is
Is there any common access model that does the above?

summary of the answer(s) I found
There seem to be two more or less related solutions for this scenario: Parameterized RBAC (pRBAC) and Object-Sensitive RBAC (ORBAC). The pRBAC solution has, from what I could find, generated more interest than ORBAC. In my opinion, it is also the more elegant and flexible of the two solutions.

There are other lines of research out there that look to solve the same access control issue, but those are aimed at replacing RBAC with some other type of Access Control model.

Answer 1

This is a very good question, and it has been identified as one of the problems with RBAC. There is been a line of research on parameterized roles (the pdf can be found online), and more recently, the idea of relationship-based access control has emerged (see work of P. Fong et al, for instance this one). I'm not sure how much has been implemented though.

Answer 2

You could configure a modern Multi-Level Security (MLS) product to address the issue. These systems are designed for military grade data protection on shared infrastructure. Typically the systems use Role Based Access Control (RBAC), Discretionary Access Control (DAC), and Mandatory Access Control (MAC) based on security labels.

The security labels address your missing element. In an MLS system all objects have a label to include both data and processes. The labels provide the scheme to address your doctor and specific group situation.

Here is an example configuration. The master label set (known as system encodings) includes a label scheme that has individual groups for all the doctor groups in question. The application that is used by all doctors could be limited by the RBAC control you mentioned. Each doctor would also have their unique security label in their account profile and thus would only be able to access the data defined by that label.

Initial configuration is heavy lifting but you get tons of other features useful in your case such as controlling which document print at which printer (think hardware limits just like doctor group limits).

The Wikipedia page for MLS provides vendors (when not in SOPA blackout). Oracle’s Trusted Extensions product had some good commercial use case examples online along the lines of your question.

Answer 3

There is a similar pattern that Exchange 2010 is using; where the access model is limited using the "Scope" property that applies to the Binding layer. In this implementation, Scope is the "relation" between the authenticated user, and the OU that the "patient" is in.

Exchange 2010 has a delegation model where groups of winrm Powershell cmdlets are essentally grouped into roles, and the roles assigned to a user.

(Image source)

This is a great & flexible model considering how I can leverage all the benefits of PowerShell, while using the right low level technologies (WCF, SOAP etc), and requiring no additional software on the client side.

(Image source)

This is a very modern application design, and I'm trying to imitate it myself. I have a similar question on StackOverflow here

Answer 4

I realize this question is nearly 4 years old. The answers, especially the one given by userxxxxx, are great.

Since then, a new access control paradigm has matured and addresses the shortcomings of RBAC. It's called attribute-based access control (ABAC) and lets you express relationships using these said attributes inside policies. The policy language is based on a standard called XACML (eXtensible Access Control Markup Language).

If we revisit the OP's scenario

Bob is a doctor and has the role with the privilege 'view, patient details'

Bob is a member of group 'A'.

Bob can view all patient details for patients assigned to group 'A'

The way this would be rewritten in ABAC is:

A user with the role == doctor can do the action == view on an object of type == patient details if the patient's assigned group is in the list of the doctor's groups.

Using ALFA as a notation, you get

namespace healthcare{
    policyset viewMedicalRecords{
        target clause actionId == "view" and object.nature == "patient details"
        apply firstApplicable       
        policy doctors{
            target clause user.role=="doctor"
            apply firstApplicable
            rule allowSameGroup{
                permit
                condition patient.group == doctor.group
            }
        }       
    }
}

You can read more on ABAC on NIST's (National Institute of Science & Tech) website. They are the ones who also defined RBAC.