Best Role-Based Access Control (RBAC) database model

Question

What is the best database schema to track role-based access controls for a web application?

I am using Rails, but the RBAC plugin linked by Google looks unmaintained (only 300 commits to SVN; latest was almost a year ago).

The concept is simple enough to implement from scratch, yet complex and important enough that it's worth getting right.

So how do others architect and implement their RBAC model?

Solution 1

To my rather basic knowledge in that area, the basic actors of an RBAC are:

• Resources.
• Permissions.
• Users.
• Roles (i.e. Groups).

Resources <- require -> (one or many) Permissions.

Roles <- are collections of -> (one or many) Permissions.

Users <- can have -> (one or many) Roles.

The tables for such a model would be:

• permission
• role
• user
• role_permission
• user_role

Now you might want to include resources here as well if you want users of your application to be able to configure which permissions a resource need. But I never needed that. Hope that helps.

Solution 2

Here is a simple diagram to illustrate Amr Mostafa's excellent answer

Solution 3

I happen to be working on the RBAC sub-system here at work at them moment... what a coincidence.

My model is based on the building blocks of the different entities in the system that require permissions, be they attributes to view/update or actions to perform. There are also, of course, different roles in the system (which can be given to users), and the glue that holds the whole thing together is the access rule, which connects a specific role, a specific permission-needing entity and the permission granted. An access rule might look like these:

rule 14: guest role + page name + read permission
rule 46: approver role + add column + execute permission

and so on. I'll leave the ERD as an exercise to the reader ;-) if you have questions, leave a comment.

Yuval =8-)

Solution 4

You can use Restful ACL Rails plugin.

Solution 5

I think the answer to your question goes as deep as you wish to go. If you happen to think about putting roles into groups and then associating groups with users wouldn't be enough. Eventually you'll need to give specific permissions to a user on a specific object (a forum, a video etc).

I'm more close to Yuval's answer, all we need is to associate project-wide objects + actions + users. To provide this; a base object (Entity) makes perfect sense. Any object inheriting from Entity can be easily associated with a user + action this way.

As you also wish to keep things simple; my suggestion would be;

• Any object due to rbac restrictions should derive from a base Entity.
• There should be a list of roles, which are one-to-one related with an Entity.
• There should be a list of relations between users and roles.

To take things one step further, I would also reccomend the following (for an automated rbac)

• I use service-based access to my objects. That is; I create respositories of objects (which do the db-access for me) and I access repositories via service functions.
• I use a custom attribute at the beginning of every service function. This defines the required role to access that function.
• I use the User parameter to access to all my service functions, and each service function does a role check before executing itself. Reflection helps me to understand which function I call, and what kind of role it has (via custom attributes)
• I also run an initializer on my application startup, and it checks for all the functions (and their attributes) and sees if I added a new required role. If there's a role I just added and doesn't appear to be on the db, it creates it on db.

But alas, that's just available for .NET, as far as I know Java doesn't have custom attributes so that's not yet likely to be available for Java.

I'd like to come up with some code examples but I'm too lazy to do that. Still if you have questions about my way of rbac; you can ask here and I'll surely reply.

View more solutions

Comments

[Dan]

When you create a resource, how do you decide what roles and permissions to assign to it? Do you inherit them from its parents? That's the part which I'm mystified with. If you leave it empty for 'someone' to assign roles and permissions to it, this would become a huge management overhead on the system.

[Yuval]

This is indeed an overhead, and must be taken care of, either by the developer writing the resource, or someone who is responsible for this cross-application feature. It's kind of like synchronization code... either it appears everywhere, or it's no good.

[Dan]

When you say that 'Resources require (one or many) permissions', I'm assuming that this is for the UI of that resource, which allows a user to set allow/deny values to each permission for each user... correct? If so, then in your DB schema, you may have 10, 20 (or more) possible resources associated with a single permission. For example, a 'Project Manager' has a 'Create' permission. Then you would link such permission with a Project, Schedule, Task, Document, Timesheet resources (just to name a few), because a Project Manager may create all those resources? Thanks!

[Mark Eirich]

RESTful_ACL is nice, but has no built-in concept of role-based control, so this isn't actually an RBAC solution.

[Peter Kriens]

the web page says it is no longer maintained :-(

[Yardboy]

Yeah, what a difference a few years makes. :) Personally, I have taken to using Devise for authentication and a combination of roll-your-own role assignment and CanCan for most of my authorization needs. I got started down this road after watching Railscasts #192 (railscasts.com/episodes/192-authorization-with-cancan). I'm a fan of the binary-masking method of storing user roles.

[HPWD]

I understand this in concept but what might the table structure look like for the core values?

[Jaseem Abbas]

How do I group similar permissions so that it helps me display the same in the frontend?

[kipzes]

You don't have to use the UserRoleID and the RolePermissionID. Instead of that in User_Role, the combination of UserID and RoleID should be unique and the primary key. This is the same for the Role_Permission table with RoleID and PermissionID.

[mlinuxgada]

Well, Rbac != ACL in my opinion.

[geoyws]

You might want to consider AERBAC researchgate.net/profile/D_Kuhn2/publication/… "RBAC and ABAC have their particular advantages and disadvantages. RBAC trades up-front role structuring effort for ease of administration and user permission review, while ABAC makes the reverse trade-off: it is easy to set up, but analyzing or changing user permissions can be problematic."

[Yordan Georgiev]

nice diagram, yet you just happen to leave out the resources model ...

[Sanjay Prajapati]

What exactly should be in the permissions table? Can you please give example?

[Arash]

This diagram is wrong. User one-to-many User_Role many-to-one Role one-to-many Role_Permission many-to-one Permission. and Resource entity is omitted.