swipe to navigate

Motivation for roles: usability, efficiency and security

Assigning entitlements indirectly, through roles, rather than directly, is intended to produce the following benefits:

  • Usability:

    Entitlements on systems and applications often have obscure, hard to understand names. Replacing them with business friendly role names simplifies the request process for business users. Moreover, it is anticipated that requests will include fewer parts where roles, rather than individual entitlements, are used.

  • Efficiency:

    By assigning multiple entitlements at once, it is possible to accomplish more in less time -- improving the efficiency of access administration staff.

  • Security:

    If roles capture exactly the access rights that users who fulfill a given business function need to perform their job, then assigning them only the appropriate role ensures that they have only the access rights they need, and nothing more. This supports a policy of least privilege.


Many participants in the Identity and access management (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:

  • A security group is an object that exists on a managed system or directory, to which security rights have been assigned. Accounts can be made members of security groups, which is the primary mechanism of assigning security rights to users. For example, Active Directory has security groups, SAP has roles (formerly called activity groups), RAC/F has group profiles, etc. The general term for all such objects on target systems systems is simply 'security group' or 'group' for short.

    On some systems, such as Active Directory and RAC/F, groups can be nested -- i.e., a parent group can include child groups among its members.

  • Entitlements are security rights that may be assigned to users. On almost all systems, entitlements are either login accounts (e.g., AD account, RAC/F login, SAP user, etc.) or security group memberships assigned to accounts that are, in turn, associated with the user. While users can be assigned other rights directly, such as to files and folders, this is rarely a good idea, as it is very difficult to manage.

  • Roles are named collections of entitlements. They may contain login accounts, security groups or other roles. Roles exist within the IAM system and are not present on target systems.

    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:

  • A user class is a set of people or personas that have something in common. Users might be added to a user class individually, but more commonly users are implicitly members of a user class, by virtue of a rule which specifies their department, location, business unit, etc.

  • An organizational hierarchy is a linkage between users or containers. For example, users may be linked to their direct managers, creating a hierarchy of people. Departments may be connected to other departments, creating a hierarchy of people-containers.

Clear terminology enables clear definitions of processes, such as the following:

  • Roles or group memberships can be automatically assigned to members of user classes.
  • Members of a user class may be invited to approve the assignment of entitlements.
  • Managers may be invited to review the entitlements of their subordinates.


Comment via LinkedIn