Authorization on complex ownership

Question

I have problem with object ownership in my web application. In my web application. There are object types:

1. Faculty
2. Student
3. Student Group
4. Student Lesson

The following user roles are available:

1. Group Leader
2. Teacher
3. Dean
4. Admin

Each Object type has many objects. In the application, the role "User" has permissions on specific object types, for example:

GroupLeader1 has permission on StudentGroup5
Dean4 has permission on Faculty2

And object types has hierarchy:

Faculty has Students.
StudentGroup has Students.
Student has Lessons



Dean4 has permission on all students which corresponds to Faculty2.
Dean3 has permission on all students which corresponds to Faculty4.
GroupLeader1 has permission on all student which corresponds to StudentGroup5.

How can I handle this complex ownership problem, are there any models for this situation?

My question is which security model can be used for that situation. I tried to use RBAC model, but i cannot implemented RBAC model for that situation. — Taleh Ibrahimli, Mar 18 '16 at 20:38

score 2 · Accepted Answer · edited Mar 17 '17 at 13:21

This is a the classic problem. I've been interested in this for some time now and I'm not aware of any standard model that really solves it out of the box (yet).

RBAC can be adapted to work for your situation by introducing parameters. There are several names that these adaptions go by, the most common is parameterized RBAC (pRBAC). I've also seen names such as Context Aware RBAC, Object Aware RBAC and relational RBAC, which are different incarnations of the same basic idea. Unfortunately, some of these terms, because there is no standardization or consensus, also refer to other access models.

There are several pRBAC concepts floating around, which all differ in detail but are still largely the same idea.
You could take a look at the papers A Design for Parameterized Roles by Mei Ge and Sylvia L. Osborn. A formal model has been described by Ali E. Abdallah and Etienne J. Khayat in their paper A Formal Model for Parameterized Role-Based Access Control.

Just as in standard RBAC, in pRBAC, a subject is assigned a role. The role consists of one or more permissions, each permission consists of an operation, object pair.
In extension to RBAC, pRBAC allows objects to have parameters and users to be initialized for a certain role with parameter values for an object they have a permission on in that role.

So, for example, the object studentCourseResult would be assigned the parameter studentId. Instead of have a role named Teacher you would define the role TeacherOf with parameter values studentId = {1, 2, 7, 9, 11}.
If the parameter value for the object is within the set of parameter values assigned to a subject for this role, access is granted.

Note that it is an easy step from here to not only allow the = operator for parameter constraints, but also allow >, <, <=, etc.

Other than pRBAC you could take a look at Attribute Based Access Control (ABAC), which is quite fashionable at the moment (but it is solving a different problem and creating new ones) and authoriZation Based Access Control (ZBAC) which is definitely a very interesting concept, but likely an overkill for the use case you describe, as it mostly (and very neatly) solves the problem of cross domain authorization.

score 0 · Answer 2 · answered Dec 18 '16 at 15:17

While I like a lot of the concepts mentioned by @Jacco, truth is that would be pretty much overkill in your scenario. Even RBAC is really kinda the inverse of what you need...

The only model you need here is simply DAC - with inheritance. That is, in your example, Faculty2 will have an ACE granting permission to Dean4 - and all students that correspond to Faculty2 will inherit these permissions. So if Dean4 goes to perform some operation on Student6, who belongs to Faculty2, he will be authorized the same ACE that was set on Faculty2 and is inherited by all students.

If you want, you can treat the requirement of GroupLeaders can only get permissions on StudentGroups and etc, as a sort of "RBAC meta-constraint" - so not granting access based on the user's role, but applicatively treating it as a runtime restriction.

From there, you should just treat the system conceptually as a standard DAC-based system.

The important thing in these types of systems is to support only as much complexity as is strictly required - but no more.
Sometime it is less complex to invert the perspective of control.

Authorization on complex ownership

2 Answers2