Page 1 of 1

Understanding RBAC better

#1 Auzzie  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 43
  • View blog
  • Posts: 573
  • Joined: 20-January 09

Posted 26 January 2010 - 08:32 AM

If like me you are thinking of a way in which you can implement a permissions system for your website and after looking at various other systems like Wordpress, phpBB amongst others you are still left confused, then look no further.
As it stands there are several different Control types which you might want to look at to base your permissions/security system on. The purpose of me writing this is to try and clarify each one to you and help you to decide which might be best for you.

RBAC: Role Based Access Control is the newer alternative to Mandatory Access Control (MAC) and Discretionary Access Control (DAC), both of which will be discussed later.
A lot of research has already been devoted by academics on access controls and from this comes RBAC which does involve some basic entities.
The following conventions are useful when it comes to defining an RBAC model:

The subject is something that can be controlled. So for example it could be an entire page or it could be as specific as a branch or folder within a repository system (like SVN, CVS etc).
In some instances the subject can be split into two different elements, a type and an identifier.

Actions can’t be just thought of as just allowing or denying access to our RBAC subjects, they should be more than just that. So for example you could allow certain users to upload their patches to the SVN branch but you could restrict them from viewing that branch (if for example the branch was just full of patches). So in this example actions could include ‘upload’ and ‘view’.

An accessor can be a user or a piece of software, like a bot. Many people restrict accessors to just user’s forgetting the various other possibilities. Accessor’s are similar to subjects in the form of splitting them into two parts. When you do this the first part would be the type of accessor. The most common usage here would be website users. The second part will be an identifier for the accessor, like a user id number for example.

This is one of the most common conventions applied to most, if not all forms of access control. It is done by combining the subject with the action, so going back to a previous example, combining viewing files within a specific folder or the SVN branch, or view a webpage would be a permission. This is from the combination of the subject (Folder in the branch or webpage) and the action (view).

Within the RBAC model, there will never be a direct link between the accessor and permission to perform an action on the subject. So instead accessors can and usually are assigned one or more roles, by doing this we create an assignment.

The role is the bearer of permissions and is usually thought of as a user group within most software. Roles are usually granted one or more permissions, like for example an administrator would be granted the permission to access the admin page, along with (usually) full read, write, edit and delete rights throughout the site.


Seeing as the RBAC model can work at a more general then compared to Access Control Lists, often roles start to merge slightly, for example in some setup’s a standard user might be given moderator permissions for one board on a forum, but when that user goes to another board they are just a standard user.
The basic RBAC model is know in academic literature as RBAC 0- and by adding hierarchy it becomes RBAC1-
In my next blog post I will talk more about MAC, DAC and ACL.

Is This A Good Question/Topic? 0
  • +

Page 1 of 1