As an IdentityIQ implementation becomes more mature, there will inevitably be more applications connected. Depending on how the roles are set up, this will have one major consequence: provisioning the roles will take longer.
The way IIQ will attempt to provision the roles, out of the box, is serially. It will run through each application being provisioned one at a time, waiting for a response from the target, before it moves on to the next operation. Oftentimes, this will be no issue as many roles will still fly through, assuming everything goes right. There are many cases though (admin roles and such) that end up having hundreds of different applications to be provisioned at once when a new user is brought in. In these cases, it’s possible that hours go by before a single role request completes.
One way I found to speed up this process is by customizing the provisioning workflow to split the ProvisioningPlans up in a way that allows each to be provisioned concurrently. This in itself is not so difficult:
- Add a step to the provisioning workflow that splits up the plans and sends each to a separate custom workflow.
- In the custom workflow, basically just compile the plan and then execute it:
provisioner.setNoRoleExpansion(true); //the role was already expanded
provisioner.compile(plan);
provisioner.execute();
There are a few more pertinent attributes that I needed to add along the way (request name, requester, etc.), but it’s really not too complicated up until this point. The part that proves to be a bit more difficult to accomplish is retrieving the results of each plan and attaching them to the Access Request.
One of the biggest issues here arises from the very purpose of this task: the concurrency of the provisioning. It’s hard to write hundreds of results to the same Access Request at the same time, from different threads, without running into issues. One way to avoid this issue is to retrieve the message immediately, but then save it off to a custom object to be read in at a later time:
String status = acctReq.getResult().getStatus(); //See note
Custom custom = new Custom();
custom.setName(identityRequestId + “-” + appName);
custom.put(“application”, appName);
custom.put(“status”, status);
context.saveObject(custom);
* Note, the result could potentially be on the ProvisioningPlan, the AccountRequest, or the AttributeRequest depending on the application
The one issue with split provisioning is that most applications only provide a result at the AccountRequest or ProvisioningPlan level, so it’s not really possible to tell which individual attributes failed/succeed per application unless the error message is explicit in that regard. Keep that in mind if it’s imperative to have line items marked perfectly accurately on the Access Request.
Finally, create a custom scheduled task to clean up the Access Requests based on the custom objects. Simply find all associated objects (use the name or an attribute you add), update the ProvisioningState of the IdentityRequestItems, and set the errors on the Access Request. Delete the custom objects as they’re processed and that’s it!
The reason this method works so much better than immediately applying the results is that I’m only touching the IdentityRequest object with one thread and won’t run into any locking issues. It should be safe to run it as often as every five minutes and just scan recently submitted access requests. I’ve seen role requests that previously took 5+ hours brought down to less than ten minutes using this method. Hopefully this helps you get your provisioning moving much faster too!