The proliferation of systems and their use by different entities and organisations raised a lot of questions about the security aspects of these systems. The security is a set of concepts or layers used at different levels to ensure that the system behave as expected and the right person get the appropriate permissions to do a specific task on the system. The applications are no longer isolated; consequently, access control policies face a large, heterogeneous, and dynamic environment (Ferraiolo & Kuhn, 1992).
One of the security concerns is the access control, which consists in managing who (person or system) could access which object and how (operation). In the context of multi users and multi applications, the Role based access control is a permission model. Traditionally application have had to build and encore the roles internally, it was hard to manage all these permissions and users especially in the case of multiple and important number of users. With the actual operating systems and their application design-oriented, things have changed by providing and easy and flexible way to manage applications’ facilities (Sandhu & Coyne, 1996).
RBAC conceived in 1990, is a mature security model for controlling access to operating systems and software. In this model, permissions are granted to roles in which users can be added. It can be considered as a grouping and centrally management of permissions. These roles can be used by different applications.
RBAC has been defined by the NIST as “Access control based on user roles (i.e., a collection of access authorizations a user receives based on an explicit or implicit assumption of a given role)”
This model provides administrators and software developers with a great flexibility and simplifies from them the heavy task of managing permissions (Butler, 2011). We can feel the benefit of RBAC within a company and how easy it is to work with permissions. An example from the real life is the Microsoft Active Directory used in Windows and Microsoft environments. Working as SharePoint developer or administrator, implies a daily manipulation of permissions, especially in the case where we have tens of site collections with hundreds of sub sites within. I felt the greatness of the RBAC when we had an AD group called External Collaborators, in which we added different collaborators, consultant and support companies, they had to access tens of sites (Project, planning, meetings boards …etc.) It was 100 times easier to simply add a person to that group rather than going for each area and adding the user with the specific permissions.
Also, the case of having couple of system within the company and a new person joins it, it is easier for system administrators to add this person in a group (e.g. Finance) and by this, the new employee get same level of access (as his/her colleagues) to all the required systems.
– David F. Ferraiolo & D. Richard Kuhn (1992). Role-Based Access Controls. 15th National Computer Security Conference (1992), Baltimore MD pp. 554 – 563
– Ravi S.Sandhu & Edward J.Coyne (1996). Role based access control. Available at: http://profsandhu.com/journals/computer/i94rbac(org).pdf
– Michael Butler (2011). Extending Role Based Access Control. SANS whitepaper, available at: http://www.sans.org/reading-room/analysts-program/access-control-foxt