Here is a the database design for a "fine grained" Role Based Access Control (RBAC) system I am currently working on.



The general concept is that a user can have one or more roles.

• Each role is defined in the in "rabac_roles_has_domain_privileges" table.
• A role is defined as the right (or denial) to exert a privilege on a domain.
• A role is given an 'importance', i.e. an integer value between 0 and 100. The higher the number the greater the importance.
• A domain is a collection of objects a user may want to access (or perform an action on), such as a 'member page' or 'forum topic'.
• A privilege is a collection of actions a user may want to perform on an object, such as 'view', 'add', 'delete', 'edit'.

Briefly (and I will be adding more information with time)

• A domain can either be singular or plural.
• A domain is "plural" if it is a collection of more than one object.
• A domain is "singular" if it corresponds to only one object (so the object and domain name will be the same)

The same can be said about actions. (At this stage it is worth noting that plural domains will always finish with a 's'. Domains and objects are named by 'nouns' whereas, privileges and actions are named by 'verbs'.).

A role is defined by several domain-privilege pairs.

• Domains that are singular have precedence over their corresponding object defined in a plural domain. This is important to define "fine-grained" role permissions.

For example, a singular domain defined by the action 'view' will have precedence over a plural domain defined by the actions 'add', 'edit', 'view'. (The plural domain also contains the action 'view' but will yield to the singular domain.)
The same can be said for privileges.

Here are somemore pictures that should hopefully clarify things:

Users has roles

This picture shows that the user 'ben' has the 'administrator' and the 'member' role. This is just an example since the 'administrator' role automatically has access to all objects and can perform all actions.

Roles definition

The administrator role is the most important, followed by moderator, then member and finally the last is public.
NOTE: Two different roles can have the same importance. This is allowed.

Roles as permissions

Take a look at the moderator role definition. You will see that the moderator can perform all_actions on all_objects, except for the 'admin_page', which he is only allowed to view.

Privileges has actions

This picture clarifies the idea of 'singular' and 'plural'. Hopefully it is self explanatory.

Domains has objects


This project (including the admin panel) is 95% complete. It is already useable and written in PHP, so if you would like to try it out send me an email at ben at sqlrecipes dot com (If you do try it out, I would appreciate your feedback and suggestions.)

The system is distributed under the BSD license and requires the ADODB database connection layer (ADOdb Database Abstraction Library for PHP (and Python) for MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Firebird, Interbase, LDAP, Access, VFP, DB2 and many other databases) as well as a MySQL database server.

If you have any suggestions concerning this article please post your comment below.

Attached Files

	RBAC.zip (21.0 KB, 400 views)
	rbac_admin.zip (261.4 KB, 353 views)

The project is now 95% complete, I still need to add a few more API methods and tidy things up. The admin Control Panel is completely finished though, so you can administer roles, privileges and domains using a GUI.

How can I check if an user A with role id 1 can perform action READ or EDIT from module ARTICLE on article_id 8 that was originally owned by user_id 4?

Thanks

Dinh

Hi Dinh,

There are several ways of doing this.

1) One Is to create a "super user" role that enables users to edit anyones articles. You then assign that role to user A.

If it is important that the article_id be 8 and that the user who created the article be user_id = 4, you will have to make these checks manually as this is not related to the RBAC logic.

One you have done the test your pseudo code would look something like:

$user_id = 1

if ( isAllowedTo($user_id, 'read_edit', 'article')){
Do what ever you want here
}

You may be wondering whether it is possible to find out all the privileges a user is allowed to perform with just one query. The answer is YES.
This means you could find out all the privileges a user has when they login, store the information in $_SESSION and you won't have to query the database again. Doing it this way, checking a users right to perform a certain action is extremely fast.


You will also be able to find out all the users that are able to perform a certain action on a given object with just one query as well.

The critical part of the RBAC implementation is the database design. Everything flows from there. (So take the time to study the design. Once you get it, everything else falls into place). Once your design is right you should be able to obtain all the infromation you need with just one query (and perhaps a little post processing to find out which privilege has priority over another.).

So there are really no secrets... all the information is on this page, which means you should be able to implement an RBAC system in any programming language. If you want to see how I did it in PHP send me an email. I would be interested to hear from people who want to port it to other languages.

> I followed most of the article that you wrote on your site and the
> document that you published about Authorize_bv, but there is a couple of
> things that I do not get.
>
> Firstly, the data model that you provided with the article does not seem
> to allow/disallow certain permissions directly to the user. What I mean
> is that lets say the user belongs to a "moderator" role, that has "read"
> access to "all_pages", how would you take read access away from this
> user without making modifications to the role "moderator"? I see you use
> something similar to this in the PDF document of Authorize_bv, but I
> fail to see how it will fit in the current data model.
>
Yes, Authorize_bv did this on the 'user' level, which means each user would have personal privileges assigned to them. Even though it seems at first more flexible it is not efficient and requires more database entries. That is when I moved to the role based approach. Rather than assign privileges to each user, you now assign the privileges to a 'role' and then each user is assigned a role. This makes it a lot more flexible to modify and administer. (i.e. instead of changing each users priviliges, which could run in the thousands..., you now only need to change one role definition.)

The way to achieve your aim using the role based approach is to create a new role called 'moderator_read_disabled' and give it an importance greater than the 'moderator' role. You could then define the new role as 'read'action 'disabled' on 'all_pages'.
You then assign this new role to the users (i.e. moderators) you want. Since it has a higher importance than the standard 'moderator' it will take precedence, but only for the 'read' action that affects the 'all_pages' domain. The other moderator privileges will work as normal.

> How would you handle groups of users? Lets say we have 10 users in a
> department, and these 10 must have access to "moderator". Is there some
> functionality to allow me to put these 10 in a group and then assign the
> "moderator" role only to the group?
>
This would be easy to implement. All you would need to do is instead of assigning roles to individual users you would assign roles to 'groups'. If you look at the first image on this thread you will see the second table from the top is called 'rbac_users_has_roles'. Instead of storing user_ids you would store group_ids and just change the field and table names accordingly.

You would also need 2 more tables to define your groups and another to keep the many-to-many relationship between the users and the groups. However if these tables already exist in your system the rbac_bv class can easily be integrated into it.

This would only require minor changes to the API, namely changing a few field names and table names in the SQL queiries.

> I would like to see what your final product looks like as I am also
> doing some research in this area. I also went through LiveUser, but to
> be quite honest, it looks a bit dodgy and heavy. I like your version
> more, but I am just curious about the above questions.
>
I hope these explanations help. Please feel free to ask more questions.
In reality there isn't much to a role based access control system. Once the database design is done all you are really doing is querying the database to find out if a user can peform a certain action on a given object.

I received an email the other day asking whether the RBAC system can be used to manage numerous articles, and whether it is possible to find out which articles a person is allowed to read the moment they log into a system.


The answer to both these questions is 'yes'.

An article is just an 'object'. You can group articles that belong to a certain category into a 'domain'.

Let say there are two types of articles. Ones that are for the public and others that are private (or sensitive.)
We can then create two domains named 'public articles' and 'private articles' and assign the various articles to them.

We then create a role called 'view public articles' that defines the privilige to 'view' 'public articles'.
Let's say we want to play it safe and make sure that the 'view public articles' role is not allowed to view 'private articles', so we add this requirement to the 'view public article' role. (We would only do this if there is a chance of making a mistake and assigning an already marked private article to the public domain.)

We then need to assign users to roles so that we can determine which users are allowed to read what.

Once this is done we can then find out which articles a person can read the moment they login with just one query.

If any of yo would like to contribute some documentation, or perhaps some notes that would help others get up to speed with the system please post them here.

thank you very much for sharing this package with us; i will check the whole class out and try to port it to CodeIgniter with maybe removing Adodb...