From a security perspective, RBAC always provides superior security to ACLs. However, there are places where the cost of using RBAC would be too high. These include: the security of Windows file systems, Oracle/Sybase/SQL Server DBA and employee-specific functions such as where an employee manages his or her own 401(k). Developers should use RBAC in almost all cases.
Role-based access control (RBAC) systems allow developers to control security within their application at a very granular level. Instead of focusing on the identity of the user to determine whether he or she should be able to do or see something in the application, RBAC determines security based on the user’s role within the organization. For example, instead of giving access to John Doe, a designer in Detroit, access would be given to a role for Michigan designers and John Doe added to the set of users with that role. With role-based access control, regulatory auditors are assured that only certain users have sensitive access because all permissions are granted from roles.
However, most of the development thus far has used user-based access control. This is often implemented through Access Control Lists (ACLs). ACLs are tables that list each userID and what that user can do or see within the system. This is often called Discretionary Access Control (DAC) since access is given at the discretion of some user, often the superuser or administrator user.
This document describes when it is best to use RBAC and when using the user-based ACLs would be better.
Other Models Can Be Supported Inside RBAC
Role-Based Access Control (RBAC) is an incredibly robust security system. Sandhu and Munawer of George Mason University have proven that RBAC provides support for both previous access models, Discretionary Access Control (DAC) and Mandatory Access Control (MAC). DAC is the security of most operating systems, where the owner of data has the discretion of who can access it and who cannot. MAC — required for many military systems — makes security mandatory, limiting what a user can do even with data he or she owns. RBAC can perform MAC easily and DAC with some difficulty. Therefore, where discretionary access control is actually necessary, RBAC would be a poor performance choice.
Most platform systems (e.g., Sybase, Windows 2000, Oracle) use DAC through ACLs to protect themselves. While it is possible to use RBAC to protect these systems and gain substantial benefits (mostly by preventing any one Super-Administrator to exist and providing greater tracking), your company may think that it is not a good value for the cost. It may not be cost-effective to protect the basic operating systems with the RBAC since the hooks to the underlying security mechanisms have not been written.
ACLs When Access Is User-Specific
ACLs are also superior where the security is tied to an individual, apart from his or her role with the company. Examples include a benefits portal where the employee manages his or her own 401(k), health insurance selections, etc. Note that the administration of this benefits portal should be secured using the RBAC.
RBAC Better Choice For Business Applications
We stress for almost all business applications, RBAC is vastly superior in security and administrative overhead to using ACLs. Most programmers are steeped in ACLs (whether from mainframe or client-server) and this makes them very resistant to converting to the RBAC’s role-based access control. They should therefore default to using RBAC for all applications.