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

[#1]

• Introduction
• Create the role provisioning policy
• Remove the AttributeRequest for the dummy entitlement

Introduction

A common way of provisioning entitlements in target systems is to make use of the role model in IdentityIQ. By assigning roles to identities we can get IIQ 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 assigned IIQ 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, IIQ 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 in IIQ 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 cause IIQ 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.

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.

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, IIQ will generate a ProvisioningPlan with an AccountRequest with its operation set to "Create", and an AttributeRequest to add the dummy entitlement.  To prevent IIQ 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();

               if ((attrReqs != null) &amp;&amp; (attrReqs.size() > 0)) {

                   // 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, IIQ does not expect to detect the dummy entitlement in the aggregated data.

[Andreas_Mueller]

While the dummy attribute is a nice solution for this problem, it has some shortcomings, namely

• the account is not deprovisioned even after the identity does not have the role any more.
• the role provisioning policy is evaluated during every identity refresh, each time resulting in a provisioning request (which may needlessly prolong the refresh )
• the provisioning policy is difficult to understand for business users who usually model the roles

An alternative solution could be to use the dummy entitlement which does not exist in the target system.

The dummy entitlement can then be used in roles as any other entitlement.

The problem mentioned above (that this would cause missing entitlements when the application is actually aggregated) can be solved.

To deprovision the account when the dummy entitlement is revoked, the plan initalizer script can be changed accordingly.

To use such a dummy entitlement, do the following (works in IIQ 6.1p1) :

1. Create a Customization Rule for the application which adds the dummy entitlement to the group attribute
   This will make sure every user with an account will have the dummy entitlement when the application is aggregated.
   The first account aggregation of the application will also create the new entitlement.
2. Write a plan initializer script as shown above, but make the following adjustments:
   • if the operation on the attribute request is "add", remove the request for the dummy entitlement (instead of the dummy attribute request as shown above)
   • if the operation for the attribute is "remove", convert the account modify request into an account delete request.

The Customization Rule could do something like this:

  // add imports here

  String accountOnlyGroup = "Account Only...";

  Schema schema = application.getSchema(Application.SCHEMA_ACCOUNT);

  String groupAttr = schema.getGroupAttribute();

  Object groups = object.getAttribute(groupAttr);

  if (groups == null) {

   object.setAttribute(groupAttr, accountOnlyGroup);

  }

  return object;

The Plan Initializer Script could look like this:

...

  for (AccountRequest accReq : accReqs) {

    AttributeRequest dummyAttrReq = null;

    List attrReqs = accReq.getAttributeRequests();

    // Iterate through AttributeRequests and find dummy entitlement

    for (AttributeRequest attrReq : attrReqs) {

     Object value = attrReq.getValue();

     if (value == null) continue;

     if (value instanceof String &amp;&amp; ((String) value).equalsIgnoreCase(accountOnlyGroup)) {

      dummyAttrReq = attrReq;

      break;

     }

     if (value instanceof List) {

      List valueList = (List) value;

      if (valueList.contains(accountOnlyGroup)) {

       valueList.remove(accountOnlyGroup);

      }

     }

    }

    if (dummyAttrReq != null) {

     if (dummyAttrReq.getOperation().equals(ProvisioningPlan.Operation.Remove)) {

      // change account Request to type delete

      accReq.setAttributeRequests(new ArrayList());

      accReq.setOperation(AccountRequest.Operation.Delete);

     } else {

      // Remove dummy entitlement AttributeRequest from

      // AccountRequest

      accReq.remove(dummyAttrReq);

     }

    }

   }

The only downside of this approach is that the dummy entilement will be shown as "missing" until the account is aggregated from the application. Maybe somebody has a solution for this?

[DerekHackbardt]

Has anyone come up with other options for this?  Or had success/experience with either of these methods?

[yash_shah]

Hello,

I have used the similar approach in which I followed below steps:

1) Create a Business Role and add Provisioning Policy at the Business Role level. In the provisioning policy I selected the Application from the drop box to which I want to provision account.

In the policy, I added one field and give name of the field as one of the target system attribute with some static value. (if your target application does not have any attribute with static value than just add any field with any name like "dummy_attribute".

2) At the application level, create provisioning policy for the Create Account operation and specify all the required fields values.

3) This step is option and need to do only if in step-1 you created dummy attribute. Here in the normal LCM provisioning policy workflow, you can add the step to modify the plan where you can iterate provisioning plan for all the attribute requests and remove the one having attribute name "dummy_attribute".

4) Select any idetity in Sailpoint and following the normal Request access procedure, add the business role to user. This will provision the business role and internally provisions account in the target system.

Please let me know if this approach works for you or if you face any issues.

Thanks

Yash

[mtosto]

Hello Mr. Mueller,

I am having an issue with the customization rule for this solution. Upon trying to retrieve the group attribute from the account schema (schema.getGroupAttribute()), a "null" value is returned. I have checked that I was given back the schema object before trying to extract the group attribute and I do have the schema object returned.

Is there a workaround for this issue?

Regards,

Michael Tosto

[#6]

Hi Yash,

I have created a Business Role and added Provisioning Policy at the Business Role level. In the provisioning policy I selected the Application from the drop box to which I want to provision account.

In the policy, I added one field and given name of the field as one of the target system attribute with some static value.

The role based provisioning works fine.But on revoking  the role,the account is not de-provisioned.

[Andreas_Mueller]

Hi Paul,

Accounts are not automatically deprovisioned.

You have to adjust the before Provisioning rule and change the operation on the account request from Modify to delete.

Gruß/Regards

Andreas

———————————————

Am 05.07.2017 um 11:49 schrieb aparajita.paul <compass@sailpoint.com<mailto:compass@sailpoint.com>>:

Compass <https://community.sailpoint.com/?et=watches.email.document_comment>

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

new comment by Aparajita Paul<https://community.sailpoint.com/people/aparajita.paul?et=watches.email.document_comment> View all comments on this document<https://community.sailpoint.com/docs/DOC-1431?et=watches.email.document_comment#comment-13106>

[smason]

Instead of a 'dummy' attribute, I've come up with a different method:  Have the 'profiles' section of the 'account' IT role demand that a required attribute for an account be 'not null'.  Consider an example for Active Directory account creation via an "IT AD Account" role:

<Profiles>
  <Profile>
    <ApplicationRef>
      <Reference class="sailpoint.object.Application" name="%%AD_APP_NAME%%" />
    </ApplicationRef>
    <Constraints>
      <Filter operation="NOTNULL" property="sAMAccountName" />
    </Constraints>
  </Profile>
</Profiles>

When sAMAccountName is null, the 'create' provisioning form on the application definition is fired, resulting in a new account without having to assign a security group.  Of course, deprovisioning still needs to be taken care of through the leaver lifecycle event, or other means. 

[claudio_meyer]

Hi @Andreas_Mueller 

is it a good idea also to add an create account request in this section, in case dummyAttrReq != null ?

I'd like to provision account creation as birthright provisioning for application ServiceNow. This one offers only role and group entitlements, but no accounts.

Thanks for letting me know

Cheers

[jplefebvre2]

I tried to implement this, but with a filtering logic. Sadly, it doesn't seem possible since we cannot log filtered items in the project level with this rule (no access to the project object). We can only add filtered Request into the provisioning plan, which is completely ignored and not logged in the provisioning transaction.

[Zubin]

in dummy attribute solution, is it possible to disable user account on target application?
When someone submits a request for removal of business role, we want disable operation of target application to be called. How to achieve this?