NIST RBAC Data Model

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:

  1. user: this contains all the user data
  2. session: this contains the session data for all currently logged on users
  3. role: this contains all the roles that are defined
  4. permissions: this contains all the permissions based on objects and operations
  5. object: objects are the items that require protection
  6. 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:

  1. user_session: this combines the user with an active session, i.e. which users of the set of all users are currently logged in As 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
  2. user_role: this combines the user with any number of roles (but at least one)
  3. 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
  4. 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).

An updated version of the model has been posted recently.

  • Michael Plant

    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

    • postme


      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?


  • Milorad

    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 !


  • Tom

    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?

  • Ashutosh Bijoor


    Thanks for posting this. Looking forward to using your library. Can you give an update on the status of your development?

  • Phil

    Awsome explanation of RBAC. Would really like to see a working demo. Are you any close to releasing this stuff yet?

    Eagerly awaiting…


    • postme

      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).


  • Alex


    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.


    • postme

      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:

      Each session is a mapping of one user to possibly many roles, i.e., a user establishes a session during which the user activates some subset of roles that he or she is assigned. Each session is associated with a single user and each user is associated with one or more sessions. The function session_roles gives us the roles activated by the session and the function user_sessions gives us the set of sessions that are associated with a user. The permissions available to the user are the permissions assigned to the roles that are activated across all the user.s sessions.

      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,


  • Jeach

    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?


    • postme

      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

  • Pingback: NIST RBAC Data Model update « Mind IT()

  • Nicolas Pujol

    You’re not modeling segregation of duty (SOD). With this model how would resolve conflicting user role assignments?

    • postme

      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.



  • Jorge

    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?


    • postme

      @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

  • Lauren

    This is a great system, but for some reason I’ve run into a problem with Google Chrome. It seems that once I login as a user on the demo provided, I essentially stay permanently logged in until my session is reset through the code. For example, I login as admin, I click on logout and when I go to change user by logging in again, I end being automatically logged in as admin again. This seems to be a Chrome only problem since I was able to get the login/logout functions working as they should in Firefox.

    I figured you’d like to be aware of this and fix it accordingly seeing as Chrome is quickly becoming a very popular web browser.

    I just hope that you’re still looking at the comments on this since this was posted over 2 years ago.

    Thanks for posting this project!

  • Tushar

    Thanks ! This is really a great place to understand the core RBAC.

    I did not undertand this part – use of Session with User and Roles. Any use case where session can be used to activate the roles ?

  • Imants Horsts

    Great and simple explanation, but I still have some questions:
    1. What are columns “locked” used for in objects and operations tables?
    2. Any chance to see some sample data how you used default CRUD columns (named _*) in operations table? Do you create records like [name=”full”, _create=1, _read=1, _update=1, _delete=1] or [name=”editor”, _create=0, _read=1, _update=1, _delete=1] in there?
    3. Do this model allow to add custom operations somehow? For example, I sometimes need custom operation like “print” on some objects (but not all)?