IGA Capability: Entitlement Management
Alternative Names
-
Group management
-
Privilege management
Entitlement Management Functions
-
Entitlement lifecycle management. Creation, modification and deletion of entitlements (such as groups).
-
Maintenance of entitlement associations. Maintenance of relation between user accounts and entitlements, such as maintenance of group membership. Interpretation of association attributes (e.g. group membership attributes).
Overview
Entitlement management deals with association between identities and entitlements. Entitlements are assigned to an identity, giving an identity access to a particular asset or an operation. These are usually groups, permissions, associations to access control lists, low-level system roles and so on. Simply speaking, entitlement management deals with a question: Who has access to what?
Entitlement management has two primary functions. Firstly, it manages entitlement lifecycle. Entitlement management may create and delete groups and similar entitlements as needed. Secondly, entitlement management manages entitlement associations, such as membership in group or assignment of a system privilege.
In comprehensive IGA deployments, entitlements can themselves be identities and vice versa. E.g. user’s membership in an organization, in which organization (identity) is considered an entitlement when assigned to a user. On the other hand, a role (entitlement) can be considered an identity, for example in a case that it is automatically synchronized with LDAP group or an application role.
Entitlements, Policy and Fulfillment Ambiguities
Entitlement management usually works on a lower level, it deals with concepts related to applications, services and directories, such as groups, filesystem permissions and application privileges. There is an ambiguity whether high-level concepts such as business roles are subject of entitlement management, or whether they are part of a policy that drives entitlement management. Strictly speaking, in IGA context, a business role does not specify who has access to what, it rather specifies who should have access to what. Therefore, business roles are closer to the policy (what should be) rather than operational reality (what is). Nevertheless, interpretation and implementation of the concepts of roles and entitlements varies from system to system.
Following table provides overview of entitlement spectrum, from high-level policy concepts to low-level privileges.
| Level | Description | Term | Examples | Maintained in |
|---|---|---|---|---|
Highest |
Pure business concepts, specified in business (non-IT) language. |
Roles |
Pure business roles (composed of other roles, not entitlements) |
IGA platform |
High |
Business concepts, may include some simple IT concepts. |
Roles |
Hybrid business roles (composed of other roles and entitlements) |
IGA platform |
Mid |
Mixed IT concepts and business concepts |
Roles |
IT roles |
IGA platform |
Low |
IT concepts, occasionally some business concepts |
Entitlements, Application roles |
Application roles |
Target systems, optionally synchronized to IGA platform |
Lowest |
Pure IT concepts, often referring to operating system, filesystem or networks |
Entitlements |
Operating system groups (UNIX groups) |
Target systems |
Similarly, there is an ambiguity in the depth of details the entitlement management is concerned with. For example, it is not clear whether entitlement management is concerned with the name and format of an attribute that associates LDAP group to LDAP account, or weather this is a responsibility of fullfilment capability. Strictly speaking, fulfilment is concerned with a propagation of changes to target systems, and group membership is often an information source. Therefore we consider management of association attributes to be a responsibility of entitlement management.
For our purposes we resolve the ambiguities as follows:
-
Entitlement management deals with reality (who has access to what). Entitlements are data structures that are directly used for policy enforcement, such as low-level privileges, operating system groups, access control lists and the attribute values that they use. Entitlements are usually evaluated by the system for every operation. Alternatively, they can be evaluated on login time and cached for the duration of user session. As entitlements are directly used for policy enforcement, there is almost zero chance that the entitlements become inconsistent with reality. Entitlements are usually application-specific. Methods of group construction, maintenance (e.g. ability to create nested groups), access control list languages and enforcement rules may be different for each application.
-
Policy management deals with policy (who should have access to what). Policy concepts are not directly used to enforce the policy, they are influence the reality indirectly. For example, business roles (in IGA context) are not used for direct policy enforcement. Business roles are usually translated to accounts and entitlements (groups, privileges) for purposes of policy enforcement. As policy concepts (such as roles) are not used directly, there is a chance that policy may be inconsistent with reality. For example, user account may have entitlements that are not based on policy. Therefore, synchronization processes (such as reconciliation) are needed to make sure that the policy and reality are consistent. Policy concepts are usually universal, application-agnostic. Policies are expressed using the same principles and language for all connected applications.
-
While manipulation of account and entitlement attributes is a responsibility of fulfilment, it is a responsibility of entitlement management to know which attribute needs to be changed and to what value to manage entitlements. For example, it is a responsibility of fulfillment to know that a group has member attribute. Fulfilment is also responsible for changing the attribute, using appropriate operation and protocol and so on. However, it is a responsibility of entitlement management to know that this is an association attribute, denoting group membership. Entitlement management is also responsible for knowing, that this attribute should contain username of the accounts that are members of the group, that an account must be a member at most once, that the groups cannot be nested, and so on.
Relevant MidPoint Features
Following midPoint features are relevant to this IGA capability:
| IGA Function | MidPoint Features |
|---|---|
Entitlement lifecycle management |
|
Maintenance of entitlement associations |
Entitlement association |