What does Identity Request Execution Status "Verifying" mean?

[#1]

IdentityIQ utilizes Identity Requests (also known as Access Requests) to encapsulate attribute requests and report provisioning results. The Identity Request status is updated at various times and to various values depending on the request type. This article is meant to help illuminate how the Identity Request provisioning verification works, and what the various statuses mean.

Let’s assume that we have a provisioning plan that sets a specific attribute value in Active Directory. At the end of the LCM workflow, the attribute request is left in a “Committed” state. Despite the fact that the account has been updated in AD, we notice that the Identity Request status is still “Verifying.”

This is the typical result we would expect to see at the conclusion of a successful provisioning workflow.

So what does it mean that the Identity Request is still “Verifying” and that my attribute request is “Committed”?

Let’s first approach this problem using a human analogy.  You can kick / throw a ball, and your nerves can sense when the muscles are no longer interacting with the ball. But your brain might not actually believe it unless you see the ball being thrown or kicked.

Now let's look at this from an IdentityIQ perspective:

We see that the same process seen in the real world holds true for provisioning in IdentityIQ.  In this case, however, governance is the brain, aggregations are the senses, and provisioning connectors are the muscles.  The provisioning connectors can tell that something has been completed or not.  But this could mean that a ticket has been closed, or a transaction has been completed. Aggregations can verify that the state is where we want it.

In IdentityIQ, “Committed” can mean different things depending on the implementation, but in general “Committed” means the changes have been written to the external system.  Because some systems use ticketing systems to request changes and others can not immediately read back the changes, IdentityIQ shows “Committed” for provisioning operations that for all intents and purposes should be complete.  This just means that the product has told the external system to make a change. That change may be instantaneous, as in the case of the direct connector, or the change may take a long time to be executed, as in the case of a message external ticketing system.  Really the product has to facilitate the lowest common denominator of functionality across all connectors at this point because the LCM code is generic and connector agnostic.

Changes have been written or committed, but… they haven’t been verified.  “Verifying” is what we call "closing the loop" and independently verifying the changes have been carried out through what we see during aggregation processes. And then a task runs that compares what the Identity Request expected to see in the provisioning versus what comes in the aggregation.

Two things need to happen for verification to take place and for a request to move to status of an Identity Request to “Completed”:

1. The account aggregation needs to read in the new link record for the account that was provisioned to.  This happens through the regular account aggregation mechanisms.  Delimited files are reread, direct connectors are re-aggregated -- whatever the connector does for aggregation.  This updates the link record in IdentityIQ with the latest State of entitlements on the account.
2. The task called the “Perform Identity Request Maintenance” runs.  This is an out-of-the-box task that ships with IdentityIQ.  By default this task is scheduled to run once a day at approximately 1 AM.   This task looks at open identity requests that are in state “Committed" or in a state attempting to retry a provisioning operation.  For the ones in a committed state the task compares the requests for entitlements to be added or removed the current state of the link.  If the desired state matches the state read in by the most recent aggregation then the request is moved to state “Finished”.

You can turn on tracing for the identity request maintenance task and see what is happening under the hood.

After the task has completed, the Identity Request in the above example has the following changes: the Verification Date is now set along with the Active Directory Attribute Request being set to “Finished” and the request’s Execution Status now set to “Completed”.

You may notice that certain Identity Requests never get set to "Completed." This can happen for multiple reasons, but one of the main reasons would be if you added and then removed role (or likewise set and then reset an attribute value). In cases where you have toggled an account setting, you will have two access requests - one to update the account, and other to undo the update. In this case, the first access request cannot be verified since the account is no longer in the expected state needed for verification.

[jennifer_mitchell]

Yes. If you look at the Complete Identity Request step of the Identity Request Finalize subprocess workflow that ships with IdentityIQ, you will see that we support the option of "auto-verifying" requests so they never have to go through that verification process.  I believe this is typically used when you have an application you don't aggregate from regularly which you want to provision to.  However, the logic used there could be used in a custom task (or rule run by the rule runner task) which could periodically clean up unverified/unverifiable requests -- marking them complete and possibly notifying someone of the set of requests on which that forced verification occurred so they could follow up if necessary.

[#3]

Thanks jennifer.mitchell​, I'll look into this - very handy to know!

[mike_erickson]

Jennifer - This is very helpful.  I like the idea of running a rule on a schedule to clean up these items that are in the verifying state.  I'm looking at the subprocess but I'm unsure how I might make that into a rule.  Any additional suggestions?

[jennifer_mitchell]

It turns out that subprocess call a workflow library method that you can't see into to see exactly how it works. My apologies.

This is a rough sketch at how I would do it. (I have not coded anything up and tested it, but it should at least get you started.)

1) Create a QueryOptions with a Filter looking for executionStatus = Verifying.

2) Use that QueryOptions to do a context.search to retrieve all IdentityRequests with that execution status.

3) Loop through the list of returned items, doing whatever you want done with them -- such as building into a list to send an email, sending individual emails, marking as terminated or completed -- whichever you intend.  (You may further filter your query with date info or some other criteria, or you may examine the identity requests for other attributes to determine whether you want to clean up each individual one as you process the list.)

See the Filters and Filter Strings.pdf​ white paper for more on QueryOptions and Filters.

See the BeanShell Developer's Guide for IdentityIQ​ for tips on performance optimization, especially around context.search signatures and which is the most efficient, as well as proper treatment of iterators when you are looping.

[chris_hajdu]

I already had a rule written that shows only the "Verifying" IdentityRequest objects:

  import java.util.List;

  import java.util.Iterator;

  import sailpoint.api.*;

  import sailpoint.object.*;

  QueryOptions qo = new QueryOptions();

  qo.addFilter(Filter.eq("executionStatus","Verifying"));

  Iterator result = context.search(IdentityRequest.class, qo);

  //

  // Iterate .

  //

  while (result.hasNext()) {

    IdentityRequest obj = (IdentityRequest)result.next();

    System.out.println("Verifying Request = " + obj.toXml());       //<--- here you could do whatever you wanted with each IdentityRequest. I just chose to print them out.

  }

[mike_erickson]

Hi Chris - Thanks for the code example.  I've created a rule using this code, selected the IdentityRequest items in questions from debug and used 'Run Rule' to act on those items.  After it runs, I get a blank text box and no errors.  Now I've been working on replacing your line 'System.out.println' with code to change the values of completionStatus and executionStatus to 'Success' and 'Completed' respectfully to make these IdentityRequest items appear to be completed.  I cannot seem to get the values to update.  I'm guessing that I'm not using the proper method to update the value.  I've tried 'return' and 'map'.  I'm hoping you can give me some suggestions.  Thanks.

[chris_hajdu]

This rule prints the results to standard out for your application server. For me, that means it goes to catalina.out (as I'm using Tomcat.)

If you want to return results in the rule window of the debug page, you will need to print everything into a string buffer and then return the string buffer when you are done. Alternatively, run the rule from the IIQ console (command: rule <rulename>) and the rule will print everything out in the IIQ console.

In order to change these values to finished, use this rule snippet. This searches for IRs in the verifying state and marks them as completed.

  import java.util.Iterator;

  import sailpoint.object.IdentityRequest;

  import sailpoint.object.IdentityRequest.ExecutionStatus;

  import sailpoint.object.QueryOptions;

  QueryOptions qo = new QueryOptions();

  qo.add(Filter.eq("executionStatus", IdentityRequest.ExecutionStatus.Verifying));

  Iterator results = context.search(IdentityRequest.class, qo);

  //

  // Iterate .

  //

  int i = 1;

  int decacheNumber = 100;  // we will decache after every nth identity, where n is determined by the decacheNumber.. use 100 or so for this number

  while (results.hasNext()) {

    IdentityRequest ir = (IdentityRequest)results.next();

    System.out.println("ir = " + ir.toXml());

    ir.setVerified(new Date());

    ir.setExecutionStatus(ExecutionStatus.Completed);

    context.saveObject(ir);

    context.commitTransaction();

    i++;

    if (i % decacheNumber == 0)  {

      context.decache();

    }

  }

  return;

[mike_erickson]

Thanks again Chris.  With a little bit of tweaking, I was able to get this code to work.  Here is my code.

  import java.util.List;
  import sailpoint.api.*;
  import sailpoint.object.*;
  import java.util.Iterator;
  import sailpoint.object.QueryOptions;

  QueryOptions qo = new QueryOptions();
  qo.addFilter(Filter.eq("executionStatus",IdentityRequest.ExecutionStatus.Verifying));
  Iterator results = context.search(IdentityRequest.class, qo);

  int i = 1;
  int decacheNumber = 100;

  while (results.hasNext()) {

    IdentityRequest ir = (IdentityRequest)results.next();

    System.out.println("ir = " + ir.toXml());

    ir.setVerified(new Date());

    ir.setExecutionStatus(ExecutionStatus.Completed);

    context.saveObject(ir);

    context.commitTransaction();

    i++;

    if (i % decacheNumber == 0)  {

      context.decache();

    }

  }

  return;

[daniel_chan]

Does the close-loop verification cover entitlement revokes?  For example, when a manager revokes an entitlement during an Access Review, how can I tell that the request is executed in the target system (operations) vs. the entitlement is actually revoked (reality) from a reporting perspective?  I would like to be able to run a report to identify the problematic revokes (out of hundreds) to follow up and troubleshoot.

[kquach]

Does the task "Perform Identity Request  Maintenance" applicable for delimitedfile connectors? We have an access request that has the Competion Status to Incomplete because there is a manual workitem that is still in "Committed" status.  The application is configured as a DelimitedFile

Thanks