In today’s world, organisation often use IT systems to store and process vast quantities of data. If those data are disclosed, it will be huge lose to the companies and it may lose many customers. Many companies counts systems as one of the most important assets. Organizations use access control mechanisms to mitigate the risks of unauthorized access to their data, resources, and systems. Increasingly complex data access and sharing requirements drive the need for increasingly complex access control models and mechanisms. Access Control Lists (ACLs) are the oldest and most basic form of access control. They gained prominence in the 1970s with the advent of multiuser systems where the need to limit access to files and data on shared systems became necessary.

While widely used, ACLs do have their limitations. The ACL for a particular file, process, or other resource must be checked every time the resource is accessed, and this can be an inefficient means of providing access control.

Role-based Access Control (RBAC) is a newer access control model than the ACL paradigm. Unlike ACLs, access to a resource is determined based on the relationship between the requester and the organization or owner in control of the resource; in other words, the requester’s role or function will determine whether access will be granted or denied. Role-based Access Control addresses some of the shortfalls of the ACL model, while presenting some new and interesting opportunities.

RBAC: Role Based Access Control
RBAC: Role Based Access Control

Some of the important points of RBAC are:

  • RBAC determines access based on roles, and since more than one person can have the same role (the role of software engineer, for example), this means that one set of access control permissions on a particular resource—the source code tree for a new piece of software, for instance—can be set once for all members of the software engineering department.
  • RBAC also allows users to be members of multiple groups. An accountant can be a member of the “employees” group, thereby gaining access to resources to which all employees need access, but would also be a member of the “accounting” group, which provides access to the company’s spreadsheets and financial reports.
  • RBAC is also increasingly being implemented at the application level, particularly in enterprise settings where it is commonly implemented as a component of enterprise middleware. Implementing RBAC at the application level creates new opportunities for scalability and versatility because a single middleware product can be used to control access to many systems and resources.

Most implementations of RBAC-based middleware require additional infrastructure components. Many, for example, require directory services, such as Microsoft Active Directory or Sun Java System Directory Server, in addition to relational database management systems, such as offerings from Oracle or IBM.

Defining a Role

A role contains one or more system privileges where each privileges defines an administrative right to a certain object or type of object in the system. By assigning a user a role, the user inherits the capabilities of the privileges defined in that role.

In Enterprise RBAC system,a role should have five semantic components:

  • Name — a human readable and business-friendly way to identify a role
  • Description — the role’s purpose, clearly defined
  • Tags — important for managing multiple roles and creating roles to manage to roles
  • Assignments — assigning roles to individuals or groups of individuals
  • Policies — specific rules and permission sets assigned to a role

Defining a Policy

A policy has one primary component:

  • Array of Statements — a policy can have many statements. You should be able to save policies and re-use them across multiple roles. In other words, a policy is a collection of specific permission rules.

Defining a Statement

A statements has three components:

  • Resource — the targetted feature, environment, or operation
  • Effect — typically “Allow” or “Deny”
  • Action — a resource can have many actions, like deleteUser, addUser, modifyUser. These actions should have human readable names, like “Delete a User” for “deleteUser”. This is essential when you get into more complex actions, like “Modify Image Upload” for “imgUploadMod”.

For example:
{ "effect": "deny", "resources": [ "prod/primaryDB/*" ], "actions": [ "deleteDB" ] }

Mapping Roles

You should be able to assign multiple roles to an individual user. Ideally, you would have a clear user interface that allows you to build these roles and attach them to individual users or groups of users.


One of the most significant is the fact that dividing people into categories based on roles makes it more difficult to define granular access controls for each person. It is often necessary to create more specific versions of roles or devise other mechanisms to exclude specific individuals who fall into a particular role, but do not necessarily need to have the full rights accorded to other members of a group. Consider a large organization XYZ, which has subsidiaries in multiple locations. It might be necessary to segregate IT personnel across the various locations. Furthermore, it might be necessary to organize IT systems so that certain resources reside in particular locations with their own administration personnel. With such a setup, a generic “administrator” role might need to be decomposed into sub-roles based on the type of resource to be administered, and perhaps also based on the location that the resource serves. Giving a SharePoint administrator from the Colorado site office the ability to administer a SharePoint deployment at the New York headquarters might make sense; on the other hand, it might not. However, creating a generic “SharePoint Administrator” role does not allow for easy differentiation between the two use cases; opportunities exist for one administrator to have unnecessary or undesired access to particular systems. What is needed in this case is the ability to differentiate individual members of a group and to selectively allow or deny access based on a granular set of attributes.