Use Case
One of the features of Identity Security Cloud is the persistence of requested entitlement assignment, often referred to as ‘stickiness’.
Per the documentation:
Once an entitlement has been assigned to an identity using access requests, it will be provisioned to the identity’s source account. If the entitlement is directly removed from the account on the source, it will be reprovisioned to the account at the next aggregation.
This can create conflicts, as not every organization is in a position to manage entitlement assignment solely through ISC. Two common scenarios are:
- An application team modifying accounts (removing entitlements or deleting accounts on the back end), which ISC will then attempt to re-create due to the persistent request.
- Removing entitlements from an acount using a BeforeProvisioning rule, which, if handled improperly, will result in the access being restored seconds after it is removed.
Solution
Fortunately, there are options for handling each of these scenarios.
It is worth noting that there are three basic methods for removing requested entitlements which resolve the stickiness as part of their process:
- Revocation during Certification
- API remove request
- Manage Access workflow action
For more fine grained control, however, we turn to the BeforeProvisioning Rule.
Under the hood, this ‘stickiness’ is managed by the assignment flag on the ProvisioningPlan.AttributeRequest.
This flag takes a boolean value. If true, ISC maintains that assignment if it is removed on the target. Below are examples of how to handle that assignment flag for the above scenarios
Removing Requested (Sticky) Entitlements Using a BeforeProvisioning Rule
A common scenario for many organizations is the removal of entitlements on termination.
Access requested through ISC already has the assignment flag set to true. Therefore, when removing the access, we also want to set the assignment flag on the removal request to true.
For the below code block, we will assume the requirement is to remove all access whenever disabling an account (common termination scenario).
List accountRequests = plan.getAccountRequests();
if (null != accountRequests) {
for(AccountRequest accountRequest: accountRequests) {
if (accountRequest.getOp().equals(AccountRequest.Operation.Disable)) {
String nativeId = accountRequest.getNativeIdentity();
//Get user account
Account account = idn.getAccountByNativeIdentity(application.getName(),nativeId);
List entNames = application.getEntitlementAttributeNames();
for (String entName : entNames) {
//Get entitlements associated with account
List ents = (List)idn.getRawAccountAttribute(account, entName);
if(ents != null) {
//add remove request
AttributeRequest attrRequest = new AttributeRequest(entName, ProvisioningPlan.Operation.Remove, ents);
//This is where we address the assignment flag
attrRequest.put("assignment", true);
//add attributeRequest to accountRequest
accountRequest.add(attrRequest);
}
}
}
}
}
Add Requests (Circumventing Stickiness when Assigning Access)
For integrations where teams may need to manage accounts outside of ISC, while also using the access request features, it will be necessary to remove the request persistence (stickiness) entirely at the time the access is assigned.
This can be handled by adding the following block of code to the BeforeProvisioning rule:
List accountRequests = plan.getAccountRequests();
List entNames = application.getEntitlementAttributeNames();
if (null != accountRequests) {
for(AccountRequest accountRequest: accountRequests) {
if (null != accountRequest) {
if(accountRequest.getOp().equals( ProvisioningPlan.ObjectOperation.Modify ) ) {
List attributeRequests = accountRequest.getAttributeRequests();
if (null != attributeRequests) {
for (AttributeRequest req : attributeRequests) {
if (null != req) {
if (ProvisioningPlan.Operation.Add.equals(req.getOperation())) {
//check if it is entitlement request
if (entNames.contains(req.getName())){
//set assignment to false for Added entitlement
req.put("assignment", false);
}
}
}
}
}
}
}
}
}
This code block checks if an incoming request is to add an entitlement, and if so, mark the assignment flag as false. Once in place, any future requested entitlements for this source will no longer be persistent (sticky).
Modifying Services Standard IdentityNow BeforeProvisioning Rule
For those using the Services Standard IdentityNow BeforeProvisioning Rule, the OOTB rule can be updated with a few small modifications to handle these scenarios as well.
Access Removal
The OOTB method included with the SSBPR is RemoveEntitlements. The OOTB method, unfortunately, does not address requested entitlements. Instead, the following modifications will allow for managing add and remove operations.
The below method is an alternate version of the OOTB RemoveEntitlements method. This method will address the sticky assignment flag. Add this code to the BeforeProvisioning rule, alongside the existing helper action methods:
public void removeStickyEntitlements(Identity identity, AccountRequest accountRequest, String attribute) {
log.debug("Enter removeStickyEntitlements: " + attribute);
if(accountRequest == null) {
log.error("removeStickyEntitlements: Invalid Arguments: accountRequest is null");
return;
}
if(attribute == null) {
log.error("removeStickyEntitlements: Invalid Arguments: attribute is null");
return;
}
if(identity == null) {
log.error("removeStickyEntitlements: Invalid Arguments: Identity is null");
return;
}
Account account = getAccount(identity, accountRequest);
if(null != idn.getRawAccountAttribute(account, attribute)) {
List ents = (List)idn.getRawAccountAttribute(account, attribute);
if(ents != null) {
AttributeRequest attrRequest = new AttributeRequest(attribute, ProvisioningPlan.Operation.Remove, ents);
attrRequest.put("assignment", true);
accountRequest.add(attrRequest);
}
}
log.debug("Exit removeStickyEntitlements");
}
This method uses the same arguments as the OOTB RemoveEntitlements method:
{
"Action": "RemoveStickyEntitlements",
"Attribute": "memberOf",
"Value": null
}
*For Attribute, use the name of the entitlement for your source. Above example would relate to an Active Directory source.
Additionally, the method call will need to be added to the action switch statement within the accountRequest loop:
case "removeStickyEntitlements":removeStickyEntitlements(identity, accountRequest, attribute);break;
For simplicity, I usually recommend adding all custom methods to the bottom of the switch statement, directly above:
case "ThrowError":throwError(identity, accountRequest, attribute, value);break;
as I find it preferable to see all custom methods at a glance.
Circumventing Stickiness on Add Operations in SSBPR
The previously mentioned block of code can be added to the very end of the SSBPR. Ensure this is added outside of ALL braces as the last code in the rule.
//Remove entitlement Stickiness
List accountRequests = plan.getAccountRequests();
List entNames = application.getEntitlementAttributeNames();
if (null != accountRequests) {
for(AccountRequest accountRequest: accountRequests) {
if (null != accountRequest) {
if(accountRequest.getOp().equals( ProvisioningPlan.ObjectOperation.Modify ) ) {
List attributeRequests = accountRequest.getAttributeRequests();
if (null != attributeRequests) {
for (AttributeRequest req : attributeRequests) {
if (null != req) {
if (ProvisioningPlan.Operation.Add.equals(req.getOperation())) {
//check if it is entitlement request
if (entNames.contains(req.getName())){
//set assignment to false for Added entitlement
req.put("assignment", false);
}
}
}
}
}
}
}
}
}
//end entitlement stickiness
Conclusion
The approach showcased above will allow you to selectively manage ‘sticky’ entitlements on a source by source basis.
While this does add a great deal of flexibility in managing access on a target system from multiple points, consideration should be taken from a policy perspective on whether or not to allow external management of access governed by ISC. Using one system to add access and another to remove it can cause difficulties for the Production support team tasked with managing and troubleshooting day to day operations.
However, as previously mentioned, not all organizations are in a position to grant sole access management to a single platform. This is especially true with new implementations, where existing processes must be able to work alongside the new ISC integration. Using this approach will allow for access management to be shared between ISC and another platform without creating a conflict between where each tries to override the decisions of the other.