Best Practice for Custom Leaver Workflow Inquiry

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Hello everyone,

I have an inquiry about using LCM Provisioning workflow as a subprocess in a custom leaver workflow (can be run either from a QuickLink or an event trigger).

Currently, two of the steps that the custom leaver workflow has are:

  1. A step to remove all roles
  2. A step to remove all entitlements and disabling all links (i.e., AccountRequest operation is Disable, AttributeRequests operations are Remove, and provisioning policies for each application contain the necessary attributes changes to disable the native account)

Each of these two steps construct a plan, with this plan being executed by a Provisionerobject.

After each of these steps, we have an extra step which refreshes the identity via the refreshIdentity call method. The reason for having two refresh identity steps is that after removal of roles, we can be sure that the entitlements currently residing on that identity are additional entitlements (i.e., not granted by a role) before we head on and remove the identity’s entitlements.

However, as number of applications grow, we fear that the usage of Provisioner object in directly executing the plan would degrade performance since we directly execute the plan using this object and not make use of a more efficient process like LCM Provisioning as a subprocess.

So, my question is, what is the best practice for implementing such scenario in order to make sure performance is not degraded? Do we:

  1. Keep it as it is?
  2. Create a large provisioning plan and hand it to the LCM Provisioning subprocess?
  3. Another better option than the previous two?

If handing it to the LCM Provisioning subprocess is better, do we set the foregroundProvisioningattribute to false or true? Since there are steps afterwards that require the provisioning step to be finished. Also, are there any other arguments that need to be set as well?

Thanks in advance.

2

Hi @kareem_ramzi ,

You can configure the new workflow where in first step use call method and select the method name as buildEventPlan and pass arguments event, trigger, identityName, and op as disable. Result variable will be plan. Later configure Identity Request Initilaize, Identity Request Provision and Identity Request Finalize subprocess at last.

Above workflow will automatically disable all the applications.

3

Hi @kareem_ramzi ,

You can have single workflow step to create Provisioning Plan instead of having 2 steps for role and entitlements.

Please check all application and corresponding account provisioning policies which should be removed as part of leaver workflow. If any customizations are needed, provisioning plan should be created accordingly.

4

Best practice for implementing a Leaver workflow in SailPoint IdentityIQ is to start with a Rule that creates the provisioning plan based on your specific requirements and configuration. This approach is generally preferred over using the BuildEvent method because it provides greater flexibility and control.

Within the Rule, you can create entitlement removal requests based on the target application. For entitlement removals, ensure that every AttributeRequest includes assignment=“true” so that assigned entitlements are properly deprovisioned during the leaver process.

When creating the leaver provisioning plan, use the appropriate arguments according to your requirements, such as:

deassignEntitlements

noFiltering

noRoleDeprovisioning

After generating the plan, invoke the Compile Provisioning Project step to compile and validate the provisioning actions.

If Identity Request tracking is required, create an Identity Request using the appropriate workflow method and then execute the Identity Request Provision step to process the request. If user notifications are needed, the Identity Request Notify step can also be included.

For provisioning execution, it is recommended to enable background provisioning by setting:

XML

1

foregroundProvisioning=“true”

Show more lines

or configure it according to your processing requirements.

foregroundProvisioning=“true”

Finally, an Identity Refresh step can be added after the Identity Request Provision step to ensure that the identity state, roles, and entitlements are updated correctly.

Overall, this approach provides better control, flexibility, auditability, and consistency for Leaver processing in SailPoint IdentityIQ.

5

better create your plan and call the lcm provisioning workflow , so it will work like sailpoint native funtionlity and sailpoint will support for any issue.
FOreground and backgroupnd provisioning, i will go with background true and foreground false. So performance maintaince task will pick as per sailpoint availablity and process , it will not send and try end to end during trigger which may end up with performance.
in high level
Do you customization in wrapper workflow and then call lcm provisioning workflow to perform native functionality

6

Remove Roles → Identity Refresh → Build Single Disable/Remove Plan → LCM Provisioning (foregroundProvisioning=true) → Post-leaver processing.

This is the approach I’ve typically seen used for large-scale leaver workflows in IIQ environments with many applications.

7

Hi @kareem_ramzi

  1. Instead of creating two steps one for role removal and second for entitlement removal, you create a method like buildProvisioningPlan to include both roles and entitlements in a single plan
    (Coming to how to identify which entitlement granted by role, you can refer to “granted by role” flag in IdentityEntitlement object of the user)
  2. LCM provisoning workflow is good at handling large scale provisioning actitivies, so it would be great to use that and the workflow OOB handles the identity refresh in it’s subprocesses.

Hope this answers your question.

Thanks
Sam

8

Thank you all for the helpful responses. I need to emphasize that there are steps after the provisioning step that require the provisioning to be fully done before they’re executed. Also, I got a few concerns:

@Harikrishna_06 Will that assure that the subsequent steps after the provisioning steps will be executed only when provisioning is done?

@mandarsane If I were to create a single step to remove roles and entitlements, how can I differentiate between additional entitlements and entitlements that are granted by roles? What objects do I need to retrieve in my rule in order to add them to the plan: IdentityEntitlement or AttributeAssignment objects?

@Shubham7499 Same question as the previous one.

@mkumariaas Setting foregroundProvisioning=false, will that assure that the subsequent steps will be executed only after provisioning is fully done?

@vikaspawar0303 This workflow can either be called from an event trigger or a QuickLink. So if I set foregroundProvisioning=true and the workflow is called from a QuickLink, wouldn’t that hang the browser of the launcher for quite some time given that the plan is large with a lot of applications?

@soswain_resmed Okay so if I use the LCM Provisioning as a subprocess, do I set the foregroundProvisioning to true or false? Also, will the subsequent steps only be executed after the provisioning is fully complete or not? I need them to only be executed after the provisioning is fully done with no errors.

9

You can keep foregroundProvisioning as true.
Coming to the subsequent steps, LCM provisioning has OOB error handling to catch any errors pass it on. Before you move to the next step, you can use step transition condition to check whether the LCM workflow executed successfully or not.

Thanks,
Sam

10

@soswain_resmed Does the LCM Provisioning subprocess produce an output variable to check if the provisioning was successful or not so I can add it to the step transition condition? If so, what is it called, and what values does it send?

11

The project variable is the one which contains the error messages if there are any failure in provisioning. The project is of object Type ProvisioningProject and form it we can get the list of messages and to get any error, the Message.Type should be “Error”.

List<Message> eMsg= project.getErrorMessages() //this will directly get us the error messsages

or

List<String> eMsgList = new ArrayList()

List<Message> msg = project.getMessages() 

for(Message m : msg){

if(m.getType() == Message.type.Error)

eMsgList.add(m.getMessage());

}

Thanks,
Sam

12

@soswain_resmed Alright so when I call the LCM Provisioning subprocess I would always get an output variable project that I can instantly reference in the following step correct? Do I need to add it to my main workflow’s process variables list or anything?

Also, setting foregroundProvisioning to true and running this workflow from a QuickLink, wouldn’t that lead to hanging the browser for the user that launched the QuickLink?

13

@kareem_ramzi yes sailpoint functionlity will not break , its like you have release control and let sailpoint do the thing on backend

14

Hello Kareem. Since you are calling LCM Provisioning as a subprocess, the parent waits for it to return before running the next step (Advanced Workflow Topics). Sequencing is already guaranteed regardless of foregroundProvisioning, so you don’t need true for it.

That makes foregroundProvisioning=false the better fit for the QuickLink case: it allows the workflow to suspend and resume in a background task thread, so the browser session isn’t held on a long leaver (reference), while the subprocess wait still keeps your post-leaver steps in order. true only matters if you want it fully synchronous in the session, like testing or an event-trigger run where nothing’s waiting at a browser.

The subprocess returning doesn’t mean every target is finished. Direct read-write connectors apply immediately, but Integration Executors can stay queued and unmanaged requests become work items (Processing Provisioning Requests).

project isn’t passed up automatically. Return it from the subprocess step and declare it in the parent:

<Return name="project" to="project"/>   <!-- on the subprocess step -->
<Variable name="project"/>              <!-- in the parent workflow -->

Your transition can then read project.getErrorMessages() and gate on it, treating a clean result as “no hard errors,” not “every async target done” (Editing Workflow XML).

15

Depending on what you need, the LCM Provisioning workflow may not give you much value.

Using the Provisioner directly to do everything you need may be reasonable.

16

@mkumariaas Alright got it, thank you for the information

@punna0001 Thank you for the extensive details, I got the full picture now.

@paul_hilchey We need to submit large provisioning plans. We believe that as applications grow, provisioning plans will get larger and thus the usage of Provisioner to execute the plans will be less efficient than using LCM Provisioning.

17

Hi there,

May be you have already found the solution for this but I think you would want to use OOTB workflow ‘Identity Request Provision’ or directly ‘Provision with retries’ as subprocess to your custom leaver workflow. These OOTB workflow are designed to implement such provisioning requirements.
And if you want to get the feedback on provisioning then you can also add ‘Identity Request Initialize’ workflow in a step to your custom workflow after you have the Provisioning Plan build. the initialize workflow generates the access request which has all provisioning details depending on what you add to the plan in custom workflow.

I feel LCM provisioning workflow is not better choice for custom leave workflow when there are OOTB workflows available.

Hope this all makes sense to you. Thanks.