4

It appears that in RBAC, a Subject creates a Session with an Active Role(s), these Roles are then used to determine what permissions and actions can be taken. This appears to be fine for most of our organization until you reach Subjects with the Customer Role. Customers should only be able to read things they own, as opposed to other roles which would have read/write (or whatever actions) on things of the same type.

I'm not sure how best to implement this using RBAC. Should the session also contain the Subject? A few references suggest no.

Note: it is possible I am being too purist, but I'm checking to see what I'm missing. I have considered the PostgreSQL route where a User is a Role, and then the active role in the session is the User. What are my options for restricting a role to only view things not by type but by ownership?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
xenoterracide
  • 322
  • 1
  • 2
  • 11

4 Answers4

1

I think this can be implemented using Capabilities. Every subject has a set of pairs (o,r) where o is the object and r are the rights. For example if Customer1 can read file1, and read-write on file2, you can have a Capability list like that:

Customer1={(file1,{read}),(file2,{read,write})}

If many Customers have the same rights you may use groups to limit the storage that is used to save this information.

But then you have to be sure that the subjects can not modify the Capability list.

Avraam Mavridis
  • 287
  • 1
  • 2
  • 7
0

Well what you can do is to define a container of some sort; assign the subset of its objects rights equal to the subject access / permission level. Sounds trivial but i know it works. Its can be visualized in form of access control matrix another role when tries to access object of another trust level; would prompt a permission error.

See this https://www.owasp.org/images/d/d5/Acm.png

or better owasp access control matrix in google

Saladin
  • 1,547
  • 3
  • 14
  • 23
0

You are hitting the limitations of RBAC. In addition to considering capabilities as suggested by Avraam Mavridis, consider using attribute-based access control (ABAC), which extends the possibilities of RBAC by including additional attributes (metadata) such as user attributes (location, clearance, citizenship) and resource metadata (classification, ownership...).

XACML is the OASIS standard that implements ABAC. With XACML, you can easily write a relationship rule that would say:

  • only allow access to a resource if and only if the requestor id == owner id.

Better still, you could rewrite the rule in a negative way since being the owner may not be sufficient to access a resource but not being the owner is sufficient to deny access:

  • deny access to a resource if the requestor id != owner id
David Brossard
  • 1,360
  • 7
  • 16
-1

For consistency within an RBAC system all resources must contain ownership information. The Session Sate object usually contains information used to enforce access control rules. Sessions are created (or modified) upon authentication and deauthentication. The rules for who is allowed to authenticate and what resources they have access to is controlled by the Super User. It is logical to think that all session can only be modified by the system based on the intentions of the Super User. A normal user should never be able to modify the session state and change the primary key of their user record.

Now lets think of a scenario. An employee is currently logged in to the system. They are fired by management. The Super User removes this account, and their Session State must be destroyed and their privileges must be revoked immediately. The Super User owns the session object and destroys it upon request. The user doesn't control when they are logged in, if this where true they could damage other data owned by that user account.

rook
  • 46,916
  • 10
  • 92
  • 181