There’s an updated article for the data model
I’m nearing the end of my development work for the first version of the NIST RBAC API for PHP. Rather than trying to explain this myself I quote the Wikipedia page on this and Role Based Access Control (RBAC) in general:
The NIST RBAC model is a standardized definition of role based access control. Although originally developed by the National Institute of Standards and Technology, the standard was adopted and is copyrighted and distributed as INCITS 359-2004 by the International Committee for Information Technology Standards (INCITS).
In computer systems security, role-based access control (RBAC)[1][2] is an approach to restricting system access to authorized users. It is a newer alternative approach to mandatory access control (MAC) and discretionary access control (DAC). RBAC is sometimes referred to as role-based security.
Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Unlike context-based access control (CBAC), RBAC does not look at the message context (such as a connection’s source).
Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user; this simplifies common operations, such as adding a user, or changing a user’s department.
The NIST RBAC Model uses a limited set of concepts to define an RBAC system as depicted below. The system has (1) users, users have (2) sessions and sessions and users have (3) roles assigned to them. Each role consist of (4) permissions and permissions are based on (5) objects and (6) operations.
Great though standards are they hardly ever give you concrete stuff like an actual implementation or a data model. As part of my series of little releases leading up to the release of the NIST RBAC PHP API I’m delivering a worked out RBAC Data Model based on the NIST standard. The model has been designed with an ERD tool named “Dezign for Databases” and it can generate the DDL code for just about any database. For the moment I’m releasing this in MySQL 5 format but if there are requests for other databases please let me know and I’ll update the post accordingly.
An Entity-Relationship diagram of the model is depicted below:
The model contains 6 main entities:
- user: this contains all the user data
- session: this contains the session data for all currently logged on users
- role: this contains all the roles that are defined
- permissions: this contains all the permissions based on objects and operations
- object: objects are the items that require protection
- operation: operations are the actions that are performed on the objects
As you can see the entities in the data model map on the entities shown in the NIST RBAC entity model. Because there are a fair number of many-to-many relationships in the model there are a number of bridge tables to help out:
user_session: this combines the user with an active session, i.e. which users of the set of all users are currently logged inAs Alex pointed out in the comments below this is not a many-to-many relationship but a one-to-many relationship and therefore doens’t require a bridge table- user_role: this combines the user with any number of roles (but at least one)
- session_role: when a user logs in all the assigned roles are associated with the session. This allows for temporary changes to the role structure, i.e. take away a role for the duration of the session or add a role for the duration of the session
- role_permission: this associates a role with one or more permissions
The model is 4NF/5NF and fully relational. For MySQL usage it requires an InnoDB (or equivalent) database. I have only tested it myself with MySQL 5.0/5.1 and the InnoDB storage engine but there should be nothing in the DDL file that would conflict with other (transactional) storage engines. If you encounter problems with executing the file please let me know (don’t know if I can fix them but I’ll give it a try).
January 30, 2010 at 04:01
Thanks for taking the time to write this, it is really great!
I have never used the shortcut thing you are doing with operations? Can you point me in the right direction?
Do you have any default data for roles or permission? Have you implemented this and if so how is working for you?
I was looking to plan my ACL and starting reading about RBAC and found your site. Thanks again!
Mike Plant
[Reply]
postme Reply:
January 30th, 2010 at 19:01
@Mike
Yes I have default data for roles and permissions, it’s part of the release I’m preparing that delivers the data model, library, management application, test framework and demo application. I’m trying to finish the documentation and release the package within two weeks.
Could you explain what you mean with “shortcut thing” that I applied with operations?
Meint
[Reply]
March 17, 2010 at 14:49
Hey, really great stuff !
The correct implementation of RBAC, not too complicated, but yet, it has everything one needs to secure the system !
Could you only share with us default data, maybe ? It would be really great if you could !
Once again, great stuff !
Milorad
[Reply]
May 11, 2010 at 02:50
Have you release any code? I am very interested in contributing code. But I would like to see what you have done first.
Thanks in advance?
[Reply]
May 15, 2010 at 06:48
Hi
Thanks for posting this. Looking forward to using your library. Can you give an update on the status of your development?
[Reply]
June 2, 2010 at 13:20
Awsome explanation of RBAC. Would really like to see a working demo. Are you any close to releasing this stuff yet?
Eagerly awaiting…
Phil.
[Reply]
postme Reply:
June 2nd, 2010 at 19:29
Hi Phil,
I’ve released the code and will post about it this evening, hope it’s to your liking (although one guy from the first test group rejected the code out of hand because it wasn’t OOP).
Meint
[Reply]
July 27, 2010 at 18:04
Hi,
if I’m not completely wrong you have a little mistake in your concept. You introduced a mapping table for sessions to users (or vice versa). This is not neccessary, since the ANSI/NIST standard does not specify a many-to-many relationship between users and sessions. Any session in RBAC belongs to exactly one user. So instead of mapping the user to a session in a separate table, you can reference the user directly in the session table. Which means one JOIN less needed.
Cheers
Alex
[Reply]
postme Reply:
July 30th, 2010 at 17:30
Hi Alex,
Thank you for your feedback, you had me worried a bit so I went back to check with the standard. This is what I found:
This excerpt is from page 7 of the “A Proposed Standard for Role-Based Access Control” document. After rereading this excerpt your argument certainly makes sense, there is no specific need for a many-to-many relationship but only a one-to-many relationship. I will change this in the database schema and associated code for the next version, probably will be in two weeks time.
Thanks for taking the time to let me know so I can improve the software.
Kind regards,
Meint
[Reply]
December 2, 2010 at 17:48
Great post! But there is a part which just about everyone who discuss RBAC always fail to elaborate on… setting permissions.
The way you explain it (and most do), I would be lead to believe that for example, User 1 and User 2 are assigned the Project Manager roll.
On that basis, do both users have access to all the Project objects (resources) across the system? I doubt it cause that wouldn’t be flexible at all.
What if ‘User 1′ was allowed read/write on ‘Project A’ and ‘User 2′ was only allowed read access on ‘Project B’?
That would mean that somewhere, an administrator used the RBAC UI and specifically assigned User 1 to Project A and checked the ‘allow’ for ‘read’ and ‘write’ permissions. And then assigned User 2 to Project B and checked the ‘allow’ for ‘read’ permission.
Where is all of that stuff mapped in your DB schema?
Thanks
[Reply]
postme Reply:
December 18th, 2010 at 14:26
Hi Christian,
RBAC trades in flexibility for easier administration and maintenance. In your example of User 1 and User 2 where User 1 gets read/write on Project A and User 2 gets read on Project B you would have to construct two different roles encapsulating the behaviour you’re alluding to. This is not very practical from an RBAC perspective and to solve it you would need to simplify the authorisation schema to fit with the RBAC model. If you want the fine grained control from your example RBAC is not the solution. On the other hand if you have to administer 1000s of users the fine grained access control will give you a lot of work to maintain :-)
Looking at the RBAC model you can define the object (in your example the projects) and the operation (in your example read/write and read) and group these in permissions. So you would have “permission A” consisting of object “Project A” and operation “read/write” and you would have “permission B” consisting of object “Project B” and operation “read”. Each of these permissions can be assigned to a specific role or your create a specific role to fit the permissions.
In practice this approach would blow up the RBAC model because you would get as much or more roles than you have users. The RBAC Model requires simplication so in the example above you would generate a series of permissions on project management related objects like Project A, B, C etc … with either read or read/write operations and group the read oriented permissions in a role “Projectmanager A” and the read/write permissions in a role “Projectmanager B”. Anyone assigned to Projectmanager A can only do read operations and anyone assigned to Projectmanager B can do read/write stuff.
I hope this clarifies the distinction in RBAC versus directly assigned permissions.
Regards Meint
[Reply]
Pingback: NIST RBAC Data Model update « Mind IT
August 21, 2011 at 02:42
You’re not modeling segregation of duty (SOD). With this model how would resolve conflicting user role assignments?
[Reply]
postme Reply:
August 21st, 2011 at 10:15
Hi Nicholas,
I haven’t implemented this feature as it tends to be overkill for most implementations, however the NIST RBAC standard does provide solutions for what you’re asking. There’s a static and dynamic SOD option available within the standard. Both options are not that hard to add to the implementation, in both cases a role hierarchy needs to be added and a role constraint feature which in the case of static SOD impact User Asdignment (UA) and Role Hierarchy (RH) and in the case of dynamic SOD impacts the Session – Roles relationship.
Time permitting I will have a look in the coming weeks whether I can at least model this correctly from the data model perspective.
Regards,
Meint
[Reply]
December 18, 2011 at 01:11
Excellent work, however, there is one aspect about this model that I question:
Wouldn’t it be better to simplify your ‘operation’ entity to contain only say two columns, ‘id’(pk) and ‘name’, where name would contain the designation for specific a operation; ‘create’, ‘read’, ‘update’ and ‘delete’.
This way, joining entities ‘object’, ‘operation’, ‘permission’ and ‘role_permission’ would yield the required information through ‘role_permission’. This seems ‘more relational’ and logically better – what’s your idea in making specific a operation a column?
Cheers,
Jorge
[Reply]
postme Reply:
December 30th, 2011 at 10:37
@Jorge, Hi Jorge yes you’re entirely right, I’ve been a bit lazy there. I’ll see if I can change this in the data model this evening and I’ll post the updated data model. Regards Meint
[Reply]