Closing the Assignment Loop for Policy-Driven Administration
Providing control over how and when policy-assigned entitlements are removed can encourage uptake of policy-driven administration
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.
The most important thing I learned in my adventures implementing policy-driven administration in the past was that merely adding and removing access automatically based on policies was not enough. Stakeholders invariably worried about the implications of removing entitlements immediately when associated policies no longer applied to users.
My original concept for policy-driven administration operated in the following manner:
Policies were embedded in entitlements, allowing entitlement owners to select identities to assign automatically based on attribute values
Identities that satisfied the policy for that entitlement were assigned at the point when policies were recalculated:
If an entitlement assignment existed already (perhaps due to an access request), it was flagged as being controlled by a policy
Once an identity no longer satisfied the policy (either because the policy changed or attribute values changed), the entitlement assignment was removed
I anticipated that the last point in the above sequence would be appreciated the most, as it represented an improvement over what I had observed with typical birthright access implementations in IGA solutions where policy-assigned access was never removed automatically. However, multiple stakeholders admitted to anxiety around the removal of entitlements from users who might still need the access despite no longer complying with the policy. This anxiety caused most stakeholders to hesitate when it came to applying policies and significantly limited adoption.
It was explained that when users changed job responsibilities formally, an informal transition period often was observed that could last for several weeks to allow for a smoother transfer of responsibilities. Immediately removing access when a policy no longer applied could turn out to be disruptive to the business. Although it was acknowledged that it was desirable to remove access when a policy no longer applied, perhaps it would be better if that automatic removal of access could be delayed somehow.
This is how I came up with the concept of a detachment policy. Originally, I called the policies embedded in entitlements assignment policies because they were intended to control the automatic assignment and removal of user access. However, now I needed a name for an additional policy that controlled when and how access was removed once the assignment policy no longer applied. I didn’t like de-assignment policy or un-assignment policy as possible names because they did not feel like proper English. I played with removal policy for a while, but I really wanted a name that conveyed tight coupling with the assignment policy.
Finally, I arrived at detachment policy and renamed the assignment policy to attachment policy. This seemed to convey the proper relationship between the policies, where attachment policies controlled the attachment of entitlements to identities while detachment policies controlled the manner (and timing) of detachment of entitlements from identities.
The nature of attachment policies did not change much as they continued to select identities for attachment to entitlements based on attribute values. However, once the policy no longer applied, control was passed to the detachment policy to determine what to do with the non-compliant entitlement assignment. These detachment policies provided entitlement owners with control over the manner and timing for removal of entitlement assignments in the form of a simple set of options:
Remove — Default behavior carried over from the previous policy model to remove the entitlement assignment immediately
Retain — Don’t remove the entitlement assignment:
Entitlement assignment would be converted to behave as if it was requested — no longer under control of the policy
Defer — Provide a grace (transition) period prior to removal of the entitlement assignment:
Deferral could be set at the system level or individually for specific entitlements
Request — Remove the entitlement assignment immediately but generate an access request to allow the entitlement to be assigned again if approved
Review — Generate a review task to allow someone (typically the new supervisor) to determine if the entitlement assignment should be retained or revoked:
Entitlement assignment would be converted to behave as if it was requested — no longer under control of the policy
Once entitlement owners were able to control what happened to entitlement assignments once the attachment policy no longer applied, much of the anxiety surrounding policy-driven administration receded.
This was not the greatest challenge that I faced in my policy-driven administration journey, but I do think it was the most important lesson. It was one of those aha moments when I started to view policy-driven administration as more of a business than a technical solution.