Eligibility Policies
Eligibility policies are the answer to complex attachment policies and overly complex identity life cycle processes in IGA
Policy-driven administration is the core of sound access risk management, the basis for distinguishing easily between access that is policy-compliant and access that is not — this allows risk management efforts to be concentrated on exceptional access.
Last week I discussed how detachment policies can smooth the path to adoption of policy-driven administration for IGA (identity governance and administration) solutions by offering entitlement owners more control over how and when entitlements are removed when the attachment policy no longer applies. This week I am covering one more aspect of my vision for policy-driven administration that simplifies the management of policies: eligibility policies.
Like attachment and detachment policies, eligibility policies should be embedded in entitlements to allow entitlement owners to select the populations of identities that are eligible to be assigned. Identities that do not satisfy an eligibility policy cannot be assigned to that entitlement under any circumstance, whether by access request or attachment policy. Furthermore, any identities assigned to the entitlement would be removed immediately (regardless of what the detachment policy may say) if the eligibility policy no longer applies.
For example, let’s pretend that an eligibility policy specifying that only active employees are eligible for assignment to an entitlement. The following three things would happen as a result:
The entitlement would be removed immediately from all identities that are not classified as active employees
When the entitlement’s attachment policy is recalculated, any identities satisfying the attachment policy still would not be assigned if they did not satisfy the eligibility policy as well
When an access request is submitted for the entitlement, the request would be rejected automatically if the recipient identity does not satisfy the eligibility policy
Attachment policies provide a means for exceptions through the request mechanism: An identity that does not satisfy an entitlement’s attachment policy will not be assigned automatically to that entitlement, but can still be assigned through the request process if approved (as long as the eligibility policy is satisfied). There are no exceptions for eligibility policies. If an identity does not meet the eligibility criteria for assignment to an entitlement, the identity cannot be assigned to that entitlement unless the eligibility policy is modified.
When crafting an eligibility policy, it’s occasionally easier to start by considering the types of users who should not have access under any circumstances. Since there are no exceptions, eligibility policies are generally defined in quite broad terms. Policies are most likely to specify concepts such as:
All active employee equivalents
Active employees in a manager role
Active employees in a certain division
Attachment and eligibility policies are complementary, which serves to simplify the crafting of attachment policies for IGA solutions with complex identity life cycle processes covering numerous types of affiliations. In the absence of eligibility policies, entitlement owners would be required to consider all contingencies when crafting their attachment policies. This typically would result in more policy statements than might otherwise be necessary.
Let’s say an entitlement owner wanted to assign an entitlement to all active identities in a certain cost center. The cost center part of the equation is simple, but the question of active identities could be complex. This could be simplified by stipulating that all eligible identities in the cost center should be assigned access automatically. If everything had to be done with an attachment policy, it would likely result in a policy with multiple clauses joined by some combination of AND, OR or NOT logical operators. The presence of an eligibility policy provides a backstop that eliminates much of the need to define attachment policies so precisely, since the eligibility policy would kick out any identities that do not meet their criteria.
Another common requirement of IGA stakeholders is to hide certain entitlements so they can be requested only for authorized individuals. The intention is to prevent people from accidentally getting approved for access they should not have. This is somewhat feasible when applied to linear, wizard-like access request processes with something that looks remarkably like an eligibility policy. However, what is most often done in these circumstances is to hide certain entitlements from requesters, not recipients.
It is difficult to hide entitlements when using the more business-friendly, non-linear access request processes that apply an electronic commerce paradigm (catalog with shopping cart).1 This is where proper eligibility policies are advantageous, as they guarantee that identities cannot be assigned to entitlements for which they are not eligible.
Eligibility Applies to Identity Life Cycle As Well
The absence of exceptions may appear too rigid at first glance, but it makes sense when we look at the full scope within which eligibility policies are applied. The true power of eligibility policies become evident when one considers how they interact with identity life cycle processes. Attachment and eligibility policies could be considered book-ends for identity life cycle processes:
Attachment policies embedded in entitlements offer more granular and decentralized control over the establishment of Birthright access, which applies most often at the beginning of an identity’s life cycle:
Attachment policies offer the added benefit of removing access when the policy no longer applies
Eligibility policies embedded in entitlements offer more granular and decentralized control over the revocation of access at the end of an identity’s life cycle
Within the overly simplistic joiner-mover-leaver paradigm, revocation of access for leaver events typically is approached in a coarse, top-down manner — often a script that runs when the leaver event occurs for an identity. The presumption in these cases is that all access should be removed, and any exceptions result in complexity that can leave gaps that are difficult to track.
Imagine an organization where former employees need to retain access to certain applications (perhaps some human resources modules) after leaving. With a top-down identity life cycle approach, the process that revokes access when leaver events occur would need to be modified to not remove the entitlements for the applications former employees need to continue accessing. The complexity increases as more exceptions to immediate revocation must be applied for different sub-groups of identities. All of this work must be centralized necessarily because the actions performed as a result of leaver events are controlled through a single choke-point.
If eligibility policies existed, entitlement owners could control the conditions under which assignments to their entitlements are retained or revoked. This decentralization places control in the hands of application and entitlement owners that are often in the best position to make such risk management decisions. Additionally, these policies can be audited more easily than opaque identity life cycle scripts.
Most IGA solutions today only offer the concept of attachment policies, and these implementations are often handicapped by making these policies standalone instead of embedding them in entitlements. The true power of policy-driven administration can only be realized through the combination of attachment, detachment and eligibility policies embedded in entitlements.
Policy-driven administration does possess a concept of a visibility policy that can apply somewhat in this circumstance, but it is distinct from an eligibility policy.