Identity and access management (IAM) systems automate business processes to grant access to new users, revoke access when people leave an organization, manage access requests and approvals, automate access changes to reflect changing business needs, enforce policies regarding user access and more.
Some people assume that, before an identity and access management (IAM) system can be deployed:
These pre-conditions to IAM deployment are a myth. Every organization, no matter how bad their access rights data, has at least manual processes to grant and revoke access and those processes work at some level. While cleaning up entitlement data is a worthwhile goal, it is in no way a pre-requisite to automating IAM processes.
On the other hand, once an IAM system is deployed, a variety of processes, including analytics, org-chart construction, data cleansing and more can be brought to bear to support the definition of roles and the automatic assignment of roles to users.
In other words, IAM does not depend on role-based access control (RBAC) and RBAC does not strictly require IAM, but RBAC is much easier to deploy once an IAM system is in place.
It is appropriate to start any discussion of role-based access control (RBAC) with some definitions, to eliminate ambiguity. The following terms will be used throughout this document:
Role-based access control was popularized and given mathematical rigor by researchers working for the National Institute of Standards and Technologies. Their work on RBAC is available at the following web site:
The RBAC concepts in this document are loosely based on the definitions and concepts in the NIST RBAC work.
Different participants in the IAM marketplace -- analyst firms, software vendors, consultants -- use the same terms to mean different things. Here we clarify how terms such as roles, groups and user classes will used in this document.
It is important to differentiate between two concepts: roles and groups. Hitachi ID Systems uses these terms as follows:
Groups are assigned to accounts while roles are assigned to users. Groups can be assigned directly to accounts or indirectly, when a user is assigned a role that includes a group. Roles can be assigned directly to users or indirectly, when a parent role is assigned to a user.
Confusingly, within some systems and applications, groups are referred to as roles or by other names, such as privileges. For consistency, all such constructs, which exist on target systems and are assigned to accounts on those systems will be referred to as groups here.
Many participants in the IAM industry refer to two distinct concepts -- organization structure and collections of entitlements -- using the same term: role. Using one label for two concepts can lead to confusion and bad designs, which in turn can lead to implementation risk, needless cost and missed deadlines.
To avoid these problems, it is important to define clear terminology, as follows:
On some systems, such as Active Directory and RAC/F, groups can be nested -- i.e., a group can include other groups among its members.
The ability of a role to contain other roles means that a role hierarchy can be defined. Another term for this is nested roles.
Note that none of the above makes any mention of an organizational structure. The terms above all relate to entitlements, either as they exist on target systems or to how they are represented in an IAM system.
There are separate terms relating to organizational structure and the relationships between people:
Clear terminology supports clear definitions of processes, such as the following:
To understand RBAC, one first has to understand the administrative burden of managing entitlements at scale.
Consider an organization with 20,000 users and 10,000 resources and where each resource is accessed by an average of 50 users:
Continuing with this example, if users can be collected into sets of about 100 users each, where members of each set have identical access requirements, then:
In other words, if entitlements are highly regular, as in our example, then 500,000 entitlements can be replaced by 2,500 entitlements plus 20,000 user-to-set associations. This reduced complexity is an important motivation for RBAC -- less things to manage.
These concepts are illustrated in the following figures.
RBAC is not built into every application. Moreover, few off-the-shelf applications are able to refer to an external policy decision point to resolve security enforcement decisions at runtime (i.e., "is user X allowed to access resource Y?"). As a result, RBAC is typically layered on top of the existing security mechanism that is built into each system and application. This can be done both at access request time and periodically:
This is illustrated in Figure [link].
In the Figure:
Periodic enforcement is illustrated in greater detail in Figure [link].
In the Figure:
A purely role-based model can be quite difficult to manage in practice. Some users have unique access needs, so would need their very own roles. As the number of roles grows to approach the number of users, the cost of developing and maintaining roles becomes prohibitive.
As the number of roles approaches the number of users, RBAC degenerates back to direct user management, but with an extra layer of indirection between roles and users. Such an RBAC system would provide no benefit.
Roles only make economic sense when they are shared by many users. How many is "many?" There is no concrete number -- it depends on the cost of developing and maintaining roles in a given organization and the frequency of access requests that refer to each role. A good starting point is to consider roles only when twenty or more people need the same access.
Users whose access needs cannot be completely met with roles also need direct-assigned entitlements. Support for both direct-assigned and role based entitlements means that fewer roles can be defined, and assigned to more users per role. This improves the cost effectiveness of RBAC.
For this to work, the RBAC policy engine (shown in Figure (Screenshot:rbac-batch-enforcement-simple-2)) needs an indication that a given entitlement is acceptable and should not be "corrected" just because it is not predicted by the user's assigned roles.
A user's entitlements may vary from what the user's assigned roles predict: they may be "surplus" -- meaning the entitlement is more than what the role predicts, or "deficit" -- meaning that the user's roles predict that a user should have a given entitlement, but the user does not and should not have that entitlement. Surplus and deficit exceptions apply to both accounts and group memberships.
An RBAC policy engine must support such approved exceptions, to avoid an explosion in the number of rules caused by users whose needs do not quite fit the role model.
Entitlement management with a combination of roles and approved exceptions is illustrated in Figure [link].
Approved exceptions, which prevent the RBAC policy engine from attempting to remediate surplus and deficit discrepancies that are actually desirable, is illustrated in Figure [link].
A useful improvement to the basic role model of requesting access with roles to automate the access request process wherever possible. If a user's roles or other entitlements can be predicted based on identity attributes -- such as the user's location, department, job title, etc. -- then it makes sense to automate role assignment rather than waiting for users to request access manually.
Automated role assignment links user classes, whose membership is based on identity attributes, to roles, which contain entitlements. It may be additive -- i.e., "all users in user class UC1 should be automatically assigned the entitlements in role R1" and, optionally, subtractive -- i.e., "when a user is no longer a member of user class UC1, if he had previously been assigned role R1, then the role should be detached and its constituent entitlements revoked."
This process is illustrated in Figure [link].
One of the motivations for RBAC is to help identify the entitlements that should be revoked when a user moves to a different job function. Role changes enable this process, but there is an implicit assumption that old entitlements are revoked at the same time that new ones are assigned. In practice, this may not be true, as users continue to perform their old job function for some time, at least in a backup capacity. It is important to implement a process that decouples role changes into add-now, revoke-later pairs of requests, to support this.
Roles may be thought of as the intersection between business responsibilities and the technical entitlements needed to fulfill them. It can be helpful to think about roles either as primarily business oriented -- i.e., business roles that represent job functions or responsibilities, or as primarily technical -- i.e., collections of entitlements that are normally assigned together, often within the scope of a single system or application.
These approaches are combined using a role hierarchy. Higher level roles represent business function and include as members lower level roles, which represent patterns of entitlement assignment within each system and application. Business roles may be defined by business analysts, while technical roles may be defined by application owners.
This is illustrated in Figure [link].
Using a role hierarchy can ease role development, as people focus on defining roles they understand (either technical or organizational) and because multiple, similar roles can be simplified by moving shared entitlements into child roles.
2017-06-15 - H.D.
Excellent explanation of RBAC concepts