Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

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.

share|improve this question
1  
why the downvote? –  Jacco Aug 30 '12 at 16:06

4 Answers 4

up vote 3 down vote accepted

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.

share|improve this answer
    
Although the linked resources look interesting, they are locked behind a pay-wall :( –  Jacco Feb 27 '12 at 12:26
    
@Jacco : If you look for the title of the papers on Google, you can directly get the versions the authors put on their webpage. –  Charles Morisset Feb 27 '12 at 12:52
    
Thanks! The paper on parameterized roles looks like an elegant solution and was very much worth looking into. –  Jacco May 14 '12 at 8:57

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.

share|improve this answer
    
Very intersting, thanks. –  Jacco Jan 18 '12 at 8:54

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.

Exchange Roles Image (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 of how Exchange 2010 remote admin works (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

share|improve this answer

Each object gets an "owner" field, who is the user that created the object. Only the owner can delete the object. Only the owner (or su) can change the owner to another user. The owner automatically has full rights to the object, and no one else has any rights, though this could be changed by default.

This is a slight bastardization of RBAC, as you are supposed to use only roles and never users. This is basically how Windows' DAC works.

Each object also gets an ACL, which is a list of ACL Items. An ACL Item is a role and its permissions, such as "sales = read/write".

Example (via a database that does row-level security):

CREATE ROLE 'A';
CREATE USER 'Dr. Bob';
CREATE USER 'Dr. Frank';
GRANT 'A' TO 'Dr. Bob';

SET ROLE 'Dr. Frank';

INSERT INTO PATIENTS VALUES ('Joe Smith');
SELECT * FROM PATIENTS WHERE NAME = 'Joe Smith';
--{id=1, owner='Dr. Frank', name='Joe Smith', acl=null}

SET ROLE 'Dr. Bob';
SELECT * FROM PATIENTS WHERE NAME = 'Joe Smith';
--0 record(s) . Dr. Bob is not the owner, so can't see the record

SET ROLE 'Dr. Frank';
UPDATE PATIENTS SET ACL = '{A=r}' where name = 'Joe Smith';
--give read permission to role A

SET ROLE 'Dr. Bob';
SELECT * FROM PATIENTS WHERE NAME = 'Joe Smith';
--{id=1, owner='Dr. Frank', name='Joe Smith', acl={A=r}}

DELETE FROM PATIENTS WHERE NAME = 'Joe Smith';
--error, Dr. Bob is not the owner so cannot delete

UPDATE PATIENTS SET owner='Dr. Bob' WHERE NAME = 'Joe Smith';
--error, Dr. Bob is not the owner so can't change ownership
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.