How to provision accounts with no entitlements using role-based provisioning

A common way of provisioning entitlements in target systems is to make use of the role model in Access Governance Suite. By assigning roles to identities we can getAccess Governance Suite to take care of the provisioning of individual entitlements associated with the role. Utilizing the role model in this way abstracts the complexity and technical details of entitlements away from the requester, who only needs to know which business role to assign, and it can also facilitate birthright provisioning where business roles are automatically assigned based on rules, attributes or populations.

For role-based provisioning to work we normally create IT roles that have profiles that determine the entitlements required in the target system. We then create a business role that has one or more IT roles as required roles. When a business role is assignedAccess Governance Suite determines the entitlements needed by any required IT roles and provisions them. If a role is assigned that requires entitlements on a target system and the identity does not currently have an account on that system,Access Governance Suite will create the account and add the entitlement. But in some cases we may need a role that just provisions an account in the target system with no entitlements, such as an LDAP account where no group memberships are needed. This presents a problem, because if we give the IT role a profile we need to define in a filter which entitlements make up the role and should therefore be provisioned. In this case we don't want to provision an entitlement, just the account. We could use a dummy entitlement that doesn't exist (and subsequently remove it from the request) but that would result inAccess Governance Suite expecting to see that entitlement in the data during aggregation since the role requires it. As this dummy entitlement will never appear we will never "close the loop" between a provisioning action and detection of the presence of the provisioned data during aggregation. This would show up on the Entitlements tab of the identity, as an entitlement that does not exist on the account.

A solution to this is to use a Role Provisioning Policy to assign the dummy entitlement, thereby avoiding the use of a profile and filter that would causeAccess Governance Suite to expect to detect the provisioned data following provisioning and subsequent aggregation. An attribute defined in the Role Provisioning Policy gets added to the provisioning plan as AttributeRequest. To get this working we need to take two main steps: create a suitable Role Provisioning Policy and remove the AttributeRequest for the dummy entitlement using a Plan Initializer.

1) Create the Role Provisioning Policy

Create a new IT role called, for example, "AppX Account Only IT Role". Don't create a profile. Click "Add Provisioning Policy", give the Provisioning Policy a name and select the application that you want it to apply to. Click "Add Field". Fill in some of the fields for a dummy attribute like this example:

• Name: dummy
• Type: String
• Value: Script
• Default Value Script: return "AccountOnly";

Save the field and the Provisioning Policy and submit the role, then create a business role (e.g. "AppX Account Only") and make the IT role a required role of this business role.

2) Remove the AttributeRequest for the dummy entitlement

If the role is assigned and the identity does not already have an account on the target application,Access Governance Suite will generate a ProvisioningPlan with an AccountRequest with its operation set to "Create", and an AttributeRequest to add the dummy entitlement. To preventAccess Governance Suite from trying to provision the dummy entitlement we need to remove the AttributeRequest from the ProvisioningPlan, but keep the AccountRequest. A convenient place to do this is in the PlanInitializerScript of the application, which gets evaluated during provisioning. We need to iterate through each AccountRequest in the plan, and for each one iterate through its AttributeRequests until we find the dummy entitlement, which we remove from the AccountRequest. The PlanInitializerScript needs to be added to the XML of the Application object inside a ProvisioningConfig tag. Sample code is below.

<ProvisioningConfig>
<PlanInitializerScript>
<Source>
import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.object.ProvisioningPlan.AttributeRequest;

System.out.println("Original plan: " + plan.toXml());
List accReqs = plan.getAccountRequests();
if ((accReqs != null) &amp;&amp; (accReqs.size() > 0)) {
// Iterate through AccountRequests
for (AccountRequest accReq : accReqs) {
AttributeRequest dummyAttrReq = new AttributeRequest();
dummyAttrReq = null;
List attrReqs = accReq.getAttributeRequests();
// Iterate through AttributeRequests and find dummy entitlement
for (AttributeRequest attrReq : attrReqs) {
if (attrReq.getName().equals("dummy")) {
dummyAttrReq = attrReq;
break;
}
}
if (dummyAttrReq != null) {
// Remove dummy entitlement AttributeRequest from AccountRequest
accReq.remove(dummyAttrReq);
}
}
}
System.out.println("New plan: " + plan.toXml());
</Source>
</PlanInitializerScript>
</ProvisioningConfig>

However, if you are using an IntegrationConfig to do the provisioning you will instead need to put the code into a Rule (everything inside and including the Source tabs). You then reference the Rule object in the IntegrationConfig XML like this:

<PlanInitializer>
<Reference class="sailpoint.object.Rule" name= "Rule_AppXPlanInitializer"/>
</PlanInitializer>

Assignment of the business role should now result in the provisioning of the account with no entitlements. Since there is no profile on the IT role,Access Governance Suite does not expect to detect the dummy entitlement in the aggregated data.