I am trying to follow the role bases access control model to restrict what users can or cannot do in my system.

So far I have the following entities:

users - People who will use the system. Here I have usernames and passwords. roles - Collection of roles that users can have. Stuff like manager, admin, etc. resources - Things that users can manipulate. Like contracts, users, contract drafts, etc. operations - Things that users can do with the resources. Like create, read, update or delete.

Now, my doubt rises here in the diagram where I have a relation like this:

operations (0..*) are executed upon resources (0..*) which generates a table I called permissions and that will store the operation and the resource.

The permissions table will look like this (one row of it): ID: 1, operation: create, resource: contract.

Which means a permission to create a contract.

I have done it this way because I feel some resources may not have all kinds of operations . For instance, for registering contracts, users can upload files, but this operation is not available for registering a provider.

So now when the administrator will be giving permissions to a role, he will not have list of resources with every single operation registered in the system.

I think each resource has its own collection of operations that can be executed upon him.

I can clarify if something is not understandable.

Is this the correct way to implement the rbac?

EDIT

What I mean is that by having a permissions table which has operation and resource, I have TWO extra tables because I want to associate resources with operations. I could have also just done resources have permissions where the permissions table would store the permissions.

But then what would have happened is that some permissions which do not even exist for some resources would have appeared when the admin would be assigning them.

So I want to know from a database design point of view if this table permission which has one column operation and another resource is correct? Will I run into problems if it stays like this?

  • 2
    What do you mean by "correct?" Note: don't answer with a tautology like "best practice." State your specific requirements. – Robert Harvey May 9 '17 at 19:05
  • 1
    My definition of "correct" is usually "that which most effectively meets your software's functional and non-functional requirements." Note that the NIST offers detailed guidelines and best-practices for role-based security. See csrc.nist.gov/groups/SNS/rbac – Robert Harvey May 9 '17 at 19:18
  • You may be interested in looking how it is done in the pundit project. – Antarr Byrd May 9 '17 at 21:40
  • 1
    You should consider using a library for this. – RibaldEddie May 9 '17 at 23:32
  • There are plenty of libraries that will do RBAC or ABAC for you – David Brossard May 10 '17 at 20:58
up vote 3 down vote accepted

Your design seems pretty close to me. Just a couple suggestions.

users - People who will use the system. Here I have usernames and passwords.

Fine

roles - Collection of roles that users can have. Stuff like manager, admin, etc.

Fine too. But you will also need a "UserRoles" entity/table that will tell you which users have which roles. It is likely that a given user may have two or more roles.

resources - Things that users can manipulate. Like contracts, users, contract drafts, etc.

Might be just a question of semantics. I don't think users directly manipulate resources; roles do. Thus it goes user -> user role -> role -> operation -> resource

operations - Things that users can do with the resources. Like create, read, update or delete.

yep, except "roles" instead of "users"

The permissions table will look like this (one row of it): ID: 1, operation: create, resource: contract. Which means a permission to create a contract.

Hmmm. There are two ways to go with this. You could have the permissions table you describe, but you would also need an additional RolePermissions table/entity that tells you which role has which permission. But I am not sure that is necessary.

A simpler way to do it is a permissions table/entity with these columns/attributes: Role ID, Operation ID, ResourceID. That way, operations x resource combinations are assigned directly to a role, rather than loaded into a permission that is assigned to a role. It eliminates one entity. There really isn't need for a separate role-agnostic permissions table, unless you wish to predefine what permissions combinations are allowed and which ones are not.

  • First of all, I totally agree with the "roles" instead of "users" correction. That's what I meant also. Now, the thing is that I want to associate resources with operations also. For example: a contract resource has an operation like upload_file. So what I don't want is that upload_file operation to also appear in another resource that doesn't have an upload_file operation like providers(another resource) when the admin is assigning permissions to a role. – imran.razak May 10 '17 at 9:21

I would not use or implement RBAC. Instead I would use ABAC. Let me explain...

  • RBAC or role-based access control is about user management and role assignment. In RBAC, you get to say that Alice is a manager. You can define static permissions along with that. For instance, a manager can approve loans. So there is a link from Alice to manager to approveLoan as a permission. There are plenty of systems that will let you do that so you do not need to implement your own tables. Even LDAP has support for limited sets of RBAC. That is OK so long as you have a relatively small set of roles and permissions. But what if you want to take into account specific permissions as is your case? View, delete, insert? What if you want to take relationships into account?
  • ABAC or attribute-based access control is about policy-driven, fine-grained authorization. With ABAC you can use roles as defined in RBAC and write policies e.g.
    • Managers can view documents in their department
    • Employees can edit documents they own

In your question, you essentially defined the information model. Your objects and their attributes e.g. a user (name, password, department...); an object (e.g. a contract) and so on.

Information model

In ABAC, you would therefore entirely decouple your app code / logic from the authorization logic which is then stored as policies using attributes. The permissions themselves are stored right in the policy (see example above). The ABAC deployment architecture looks like the following

Attribute Based Access Control Architecture

The point is that if you take an ABAC approach, you write policies for ABAC (either in XACML or ALFA - there are plenty of tools for that) and you never have to custom-code or custom-implement RBAC or access control again.

  • In your example of policies, it says Managers can view documents in their department. Does it mean that the system will already have predefined permissions, roles and resource types? – imran.razak May 11 '17 at 12:43
  • No. It means that you would have something (LDAP? A table?) that links a user (Alice) to her roles (manager...). You would then have a table that would contain document metadata (that is typically a table within the app you are protecting). The permission itself (view, edit, delete) is stored in the policy. – David Brossard May 11 '17 at 15:23

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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