Role Based Access Control (RBAC) is a method of organizing authorization management in a way that, with some extensions, enables an authorization management solution to offer the capabilities to:
- Define and maintain the design of an authorization model for individual resources, applications, etc.
- Manage the authorization models from the consolidated authorization management concept, using the concept of roles for managing authorizations.
RBAC roles are an intermediate entity between permissions and users that both organizes and connects them. This is depicted below:
Role Based Access Control Explained
Within this model, a permission is the right to perform a certain action with regard to a certain (type of) object. Permissions are collected in roles. Roles are given, or assigned, to users. Whenever a role is assigned to a user, the user thereby obtains the permissions that are contained in the role.
Although roles may seem a minor addition to traditional authorization management solutions, they are indeed a very important factor in bringing authorization management to a business level. Among others, the following reasons can be given for this:
- A single role can contain permissions in multiple systems or applications. Roles therefore transcend the boundaries of those systems and applications. In traditional authorization management solutions, these boundaries complicate getting a full view of, and management grip on, user permissions.
Roles can be given names that are meaningful to business users and can therefore be related to business concepts. For instance, if certain permissions are to be granted to
- employees who have a certain position within a company, then those permissions can be collected in a role having that position’s name. The permissions can then be assigned to the people in question by giving them the role. It could also be that certain permissions are granted to all employees. In such a case, these might be put in an “Employee” role that is given to all employees.
- Roles support situations with multiple levels of abstraction regarding permissions through the concept of role inheritance. Through role inheritance, roles that contain permissions can themselves be combined in other, more abstract roles.
For example, an organization might have application owners who have a detailed knowledge of the technical permissions within their applications. These application owners could organize these technical permissions into roles, where each role could contain the permissions required to perform a certain task in an application. A line manager could then combine these application roles into “higher-level” roles, each of which might correspond to a business function.
- Roles provide a basis for implementing certain business policy rules, such as Segregation of Duties (SoD). A policy rule stating that two tasks or functions may never be assigned to the same employee could be translated to an RBAC enforceable SoD rule that the corresponding two roles may never be assigned to one user.
Other benefits of using RBAC as a basis for authorization management are discussed later in this document.
The RBAC Standard
The model that is summarily described in the previous subsection has been captured in a standard that’s carried by the American National Standards Institute (ANSI) and the International Committee for Information Technology Standards (INCITS). This standard is known as American National Standard ANSI INCITS 359-2004. The standard describes both static RBAC and dynamic RBAC.
Static RBAC concerns the model that defines who is allowed to do what, incorporating restrictions as SoD. In other words, it concerns the model that was just discussed.
The Dynamic RBAC Concept
Dynamic RBAC adds to this the concept of sessions. In dynamic RBAC, a user may in fact be assigned more permissions statically than he or she is allowed to use at any one time. Through the mechanisms defined under dynamic RBAC, it is enforced that a user doesn’t obtain more permissions than he or she is allowed within or across his active sessions.
Implementation of dynamic RBAC requires that all applications and systems within an IT environment use the same session infrastructure and/or constantly synchronize information about active sessions. This is technically feasible only in very few organizations, and necessary or practical in even fewer. For that reason, dynamic RBAC is not discussed further within this white paper.
Implementation of static RBAC does not require synchronization at the level of user sessions, but at the data storage level. Most applications that are available today store their identity and access information in either one of a limited set of relational databases or a directory server. Standard communication protocols and/or connectivity interfaces are available for these data stores. Applications that use other means for storing data generally provide an interface for managing identity and access data. This means that implementation of an integrated static RBAC solution is possible in the majority of IT environments.
For such implementations, the ANSI NISTIC standard can be considered a good basis. However, some comments can be made regarding the standard’s practical applicability:
- The normative part of the standard is a rather theoretical or even mathematical model. This makes sense, because the underlying principles of RBAC are based in set theory and should therefore be described accordingly. The mathematical model covers how RBAC concepts should be implemented in RBAC software solution, but it says little about how those software solutions should be implemented in IT or business environments.
- The standard describes the basic functionalities that every RBAC solution should offer, and could be considered a least common denominator for such solutions. It does not necessarily include all functional features that are needed for practical and manageable implementations, especially in larger or more complex environments.
It is fair to say that ANSI INCITS 2004-359 acts as a solid foundation for RBAC solutions, but requires extensions and modifications to help ensure practical applicability within real-world business environments.
Related Sofy solutions
Author: Tony Kanters