role based access control - same role, different departments

Question

This question about RBAC implementation. Can a subject have a role in a certain realm?

Suppose a university is made up of departments. Departments have courses. Courses have students. Students have grades in courses.

Note that these grades are WITHIN the realm of a particular department, but they are not directly OWNED by the department.

We wish to declare that the "department head" role should have access to all things within the realm of their department - including all grades. Is there a standard / recommend way to do this. I am (slightly) familiar with ownership, but the grades are owned by the student. The fact that the grade is within the department is indirect.

From my initial reading, it seems that at least, one would have to create many duplicated roles - "math department head", "history dept head", "english dept head", etc. It seems preferable to define the "department head" role and assign that role to a subject _relative_to_ a certain department, then have that flow down to grades within department X. Is that possible? Thanks so much for your assistance.

Answer 1

you want to use attribute-based access control which extends beyond role-based access control to include other attributes about users, resources, and more.

In your example you have to create a role "MathDepartmentHead" if you use RBAC. But if you use ABAC you can write a rule as follows:

A user with the role "department head" can do the action "view" on all resources if and only if resource.department==user.department.

You can read more about attribute-based access control here:

• ATTRIBUTE BASED ACCESS CONTROL (ABAC) - OVERVIEW

There are a couple ways to achieve attribute-based access control. The standard way is to use XACML, the extensible access control markup language. It's also worth considering Microsoft's claims-based

• OASIS XACML - an implementation of attribute-based access control.
• Microsoft claims-based authorization on MSDN

In the world of XACML, there are several open-source and vendor implementations available. I work for one the vendors, Axiomatics.

Some of the use cases that are seen in this space include protecting sensitive medical data, PII, and even academic information as is your use case.

If you want to start modeling attribute-based access control policies, have look at the ALFA plugin for Eclipse, a free tool that lets you write XACML in pseudo-code.

I hope this helps. If you go down the ABAC route, you will:

• avoid role explosion
• enable relation-based access control (Permit if user.department==resource.department)
• be able to implement segregation of duty rules e.g. the department head can view data in his or her department except for data relating to students or staff that are family members.

Answer 2

Yes, it is possible. Think of forums, where moderators would be able to moderate only certain topics.

What you should do is, in my opinion, define different rules, such as "Can change Math", "Can change Art", "Can see Math"...etc depending on what you have.. Than you Math teach would have value TRUE for "Can change Math" and false for other "change" rules but "true" for others.

Or, you can set rules under departmants... for instance a list determining how can edit, and who can only see the grades etc...

however you should give more infor about your system for direct answer. Hope this helps.

Answer 3

It is not as well documented as RBAC but what you're describing I have considered Responsibility Based Access Control.

A simple example from our favorite, the DMV: You can have a DMVEmployee role who can create a Title object. One of the properties of the title object would be (in a normalized system at least) a reference to a person - a "responsibility". It can be used as an object level role but as a property has the ability to contribute to the object's validity. (Title update requires Owner.age >= 18 and Owner.Deceased != true). That responsibility might grant the owner the ability to change the vehicle's address (if CurrentUser == Title.Owner) but nothing else.