IGA Capability: Policy and Role Management
Alternative names
-
Role management
-
Role governance
-
Role modeling
-
Role lifecycle management
-
Policy management
Policy and Role Management Functions
-
Role-based policies. Policy definition based on roles, such as role-based access control (RBAC) mechanism.
-
Role structure. Organization of roles for easier access and definition. Using mechanisms such as role hierarchies, role catalogs and metaroles.
-
Role modeling and governance. Creation and efficient maintenance of role definitions. Management of role lifecycle, role ownership, role model versioning and curation, review and approval process.
-
Segregation of Duties. Policy prohibiting dangerous combination of privileges.
-
Automatic role assignment. Automatic assignment and unassignment or roles, usually using a set of rules.
-
Deputy management. Ad-hoc delegation of rights from user to user, usually for a short period of time.
Overview
The policies are the heart of identity governance. Policies specify how things should be, what is the ideal state of all the systems and data. As organizations and regulations tend to be quite complex, policies are often complex too. Moreover, policies tend to change in reaction to changed regulations or organizational needs. All of that makes policy management quite a challenging thing to do.
There are many ways to express an organizational policy. The policy may be expressed by a completely non-structured free-form text form that can only be interpreted by humans, and even that in quite an ambiguous way. The policy may be expressed in a compilable code, unambiguously interpretable by computers. However, none of that extreme approaches work in practice. Therefore, in reality, the way a policy is expressed is somewhere in between the extremes.
Most methods used to express identity governance polices rely on a concept of a role. A role is a grouping of privileges into a named, manageable set. Ideally, roles should relate to real-world concepts, such as work positions or organizational responsibilities. However, such correspondence of roles to real-world concepts is not always possible, and many roles are quite abstract in their nature. The important characteristic of a role is that it is easier to manage than individual privileges grouped in a role.
In theory, a role is a grouping of entitlements. Which in IGA context usually means grouping of application-specific entitlements such as LDAP groups, application privileges, account attribute values that match a specific access control list and so on. While in traditional RBAC context such role definition is usually processed when user logs into the system (a.k.a. "just in time" approach), in IGA context the roles are processed differently. Role definition has to be processed before the user logs into the system for the first time. Membership in an IGA role means that the account will be associated with (made member of) a particular LDAP group or application privilege at the time when the role is assigned to user (a.k.a. "just in case" approach), long before the user logs in.
The roles can usually contain other roles, thus creating a role hierarchy. Role hierarchy can be utilized as a form of re-use, grouping frequently-used privilege groups into role, then including them in other roles. However, role hierarchy is usually used to divide roles into several types or layers. The usual role types are as follows:
-
Application roles grant access to a single application or system. Application roles often correspond to application-level entitlement such as groups. They usually grant account and entitlement in a single application. Many IGA platforms can operate without any need for application roles, managing application-level entitlements directly. However, even such platforms often use application roles nevertheless, for governance purposes. Application roles are sometimes automatically synchronized with entitlements (e.g. Active Directory groups).
-
Technical roles or IT roles are ad-hoc grouping of permissions, mostly for the purpose of re-use in other (business) roles. They often represent some organizational or administration concepts, such as reports read-only access or basic OS permissions, however, they do not represent complete business concept. Technical/IT roles may span several applications. They are usually defined as a combination of application roles.
-
Business roles often represent business-level concepts, such as work position or job responsibility. Business roles are designed to be understandable to a common user, using organizational and business terminology rather than IT slang. Ordinary users are supposed to look up appropriate business role in access request process, managers are supposed to review and approve/reject the request. Therefore it is paramount that business roles use a language that the users can understand. Business roles are usually defined as a combination of application and/or technical roles.
The most challenging part of all the role-based mechanisms is undoubtedly design and maintenance of role definitions. We refer to this process as role management, or, perhaps more precisely, role lifecycle management. Typical medium-to-large organization needs a large number of roles. It is unlikely that a single person or even a small team can create and maintain definitions of thousands of roles. Roles contain a significant amount of organizational knowledge, such as responsibilities of particular teams or work positions, a knowledge, that is often not documented or recorded in any way. Role definition needs a cooperation of many people, people from business units, identity team, security office and management. Therefore role definition and maintenance work is sometimes distributed among several people or teams.
A common approach is to assign owners to roles. Owners are responsible for maintenance of role definition and policing of role usage. Role ownership is one of the methods to distribute role maintenance work, usually applied to business roles.
Roles are sometimes organized in role catalogs, hierarchical structures similar to categories in an electronic shop. Catalogs are usually used for presentation purposes, making role selection easier for common users, especially for purposes of access request processes. However, there may be more than one role catalog, some catalogs may be used for the purposes of role maintenance. E.g. role presentation catalog may organize roles according to business functions or areas of interest, whereas role definition catalog may organize the roles according to business unit or area responsible for role definition maintenance, yet another catalog may organize the roles for reporting or compliance purposes.
While definition and maintenance of individual roles can be distributed to independent teams, the maintenance of an entire role model requires strong coordination. Role model is a set of roles designed to be used in an organization. Individual roles in a role model are supposed to work together, to make sense both from business perspective and implementation (IT) perspective. Roles designed by independent owners are often less than ideal as a consistent role model. There are duplicate roles, roles that copy definition instead of using role hierarchies, overlapping roles, non-systemic role naming conventions and so on. Role models have to be curated. Definition of individual roles need to be coordinated by an experienced identity specialist, otherwise the role model evolves into an unmaintainable state. Also, business roles usually rely on lower-level roles (other business roles, technical/IT and application roles). Therefore it does not make sense to change the roles one-by-one. Changes to the entire role model has to be considered together, reviewed, validated and applied as a consistent policy. Role model versioning is used to organize consistent updates to the role model. While old version of role model is in use, new version of the model can be prepared, reviewed, modified and approved without affecting production environment. When a new version of the model is ready, production environment can be switched to a new version in one operation.
Introduction of new roles into the system is relatively easy. Modification of existing roles is more difficult. However, decommissioning of existing roles is perhaps the most challenging process. The roles are usually assigned to existing users, the users are often using the privileges that the roles provide, therefore the roles cannot be deleted right away. The usual process is to mark the roles as deprecated first. This makes the roles unavailable for further assignment, however existing assignments remain functional. Then the deprecated role assignments are evaluated and replaced with an equivalent assignment of new roles. When the deprecated role is no longer assigned, it can be deleted or archived.
Design and maintenance of role models is both an art and a science. There needs to be the right balance, the right understanding of the organizational structure, processes and culture. It is very easy to get the role model very wrong. One of the well-known issues in role modeling is role explosion problem. Role explosion is a multiplication of role definitions that gets out of control. The role explosion can be mitigated by using advanced role-based mechanisms, such as algorithmic functions in role definition (RBAC/ABAC hybrid), metaroles (roles applied to roles) or similar mechanisms.
Overall, roles have a tendency to multiply. It is easy to create new roles, yet it is quite difficult to keep role definitions up to date and decommission old roles. Role certification process can counteract natural tendencies to increase number of roles out of control. Role certification works in much the same way as access certification works. However, role definitions are certified instead of user-role assignments.
|
Terminology
The terms role management and role-based access control (RBAC) are many things to many people.
We use the role-related terms in quite a broad sense.
We do not refer to NIST RBAC model, or any other formalized role-based access control model.
What me mean are generic mechanisms that are based on the concept of a role.
Although the basic principles of most role-based mechanism is similar, there are subtle details.
We try to abstract from such details.
Also, this section is mostly about role management, by which we mean the process of creating and maintaining role definitions.
Strictly speaking, this is different from role-based access control (RBAC), which is a process of using roles to control access to assets.
|
There are methods to express a policy that do not use roles, such as attribute-based access control (ABAC). Such methods can be very powerful and extremely flexible. However, with great power comes great responsibility, and management of such policies is almost always problematic as they get longer and more complex. E.g. it is difficult to split ABAC policy into smaller pieces, each of them managed by an independent delegated administrator. Roles allow such separation of administration responsibilities. Moreover, roles simplify governance, as role designers, owners and reviewers can be specified, roles provide natural boundaries to split certification effort and so on. Hence, most practical identity governance deployments are role-based, albeit the roles usually provide some degree of ABAC-like flexibility inside their definitions, thus effectively creating an RBAC/ABAC hybrid.
Roles are assigned to users in several ways:
-
Roles can be manually assigned to users by identity administrator. Such approach is simple, however, it is feasible only in a very small deployments.
-
Roles are assigned and unassigned automatically, based on rules. The rules are often based on organizational membership of the user.
-
Users are requesting role assignment in an access request process. The request is usually subject to approval by managers, role owners and/or security staff.
Practical deployment use a combination of all three methods. Manual role assignment/unassignment is used rarely, usually for special cases, or in emergency situations. Automatic, rule-based role assignment is used for roles that are clearly related to organizational assignment of the user. For example, Basic employee role is assigned to all employees of particular organization, Auditor role may be granted to all members of information security team and so on. In the common case, only a relatively small number of roles can be assigned/unassigned automatically, as the rules who should have a particular role is not known. Most of the roles are assigned using access request process.
Role structure and content specify significant part of access control policy. Therefore it is quite natural, that there are policies that limit assignment of roles to users. Segregation of duties (SoD) policy is often implemented at a role level, denying assignment of certain role combinations to a user. For example, a user may either have Funds requester and Funds approver role, but not both roles at the same time. Purpose of SoD policies is to avoid dangerous combinations of privileges, such as the privilege to request funds and approve them by the same person.
The policies usually apply in several enforcement modes. The policy can be fully enforced, for example strictly denying assignment of roles that violate SoD policy. This is known as preventative application of a policy: the policy prevents a violation from happening. Alternatively, the policy may ask for an approval, allowing the assignment in case that it is approved. Policies may be configured without any enforcement, only reporting the violations. This is known as detective application of policy, detecting policy violations and following up on them. This option is often used when new policy is introduced, expecting that there will be numerous violation. The policy is used to find the violations, remedy each of them individually, gradually progessing towards full compliance, at which point the policy can be fully enforced.
The policies are closely related to remediation, a process to address policy violations. However, remediation is often a manual process, governed by workflow capability. The policy engine is responsible for initiating the remediation process (starting workflow or opening case).
Roles, together with organizational structure assignment can be used to define delegated administration policies. For example, administration of certain set of users can be delegated to a dedicated administration team, limiting the administration rights as needed. Delegated administration may be used to distribute role definition, configuration maintenance, or for similar purposes.
Delegated administration is a "static" policy, specified by administrators and seldom changed. On the other hand, there is often need to delegate certain responsibilities of a user to another user for a short period of time. This feature is often used to temporarily delegate privileges during vacations or business travel. Such delegation is usually set up by the delegating user, using a self-service user interface. Such "deputy" can use privileges of delegating user until the delegation expires.
Relevant MidPoint Features
Following midPoint features are relevant to this IGA capability:
| IGA Function | MidPoint Features |
|---|---|
Role-based policies |
Abstract role (concept) |
Role structure |
Archetype |
Role modeling and governance |
Assignment |
Segregation of Duties |
|
Automatic role assignment |
|
Deputy management |