Create Workflows to Retry Failed Access Request Provisioning

[nhassan (Noor Hassan)]

Hi All,

Use Case:: When access request provisioning fails due to e.g SailPoint outage or problem on the VA side or any other identity related error, SailPoint doesn’t attempt to retry failed access request provisioning unless it’s birth right access or dynamic role. I had to check this with SailPoint support but I’ve been advised there’s no way/option available to retry this. The only workaround is to ask the requester to re-request this, which is really a pain as it will go to the approval process again, especially if there are multiple stages of approval and also if there are many failed provisioning access requests.

Objective: I want to automate this process to retry failed access request provisioning by creating the two workflows below if possible. Could you please help with this?

1: For Failed Access Request Provisioning (direct connection source)

Trigger (?) - when access request provisioning status is set to ‘failed’ (instead of ‘committed’)

• Not sure if this would work when we use some logic in the filter in the ‘Provisioning Completed’ trigger when provisioning of access request is failed e.g $.accountRequests[?(@.source.name != "Jira Requests" && @.provisioningResult == "failed")]. Can you think of any other trigger we can use? OR
• Use ‘Access Request Decision’ - not sure if we can use this where there are multiple stages of approval?

Action (?) - gets the failed access request details e.g access request id, access name/Id, requester, recipient, source(s) details, operation (add/remove)

Action (Get Identity) - gets the user details
Action (Get Access) - gets the user current access

Operator (Compare Strings) - checks whether user has the access as sometimes it throws an error message/failure although access is provisioned successfully.

Action (Manage Access) - provision the access if user doesn’t have it and bypass the approval process.

• We’ve multiple stages of approval setup for granting access but not for revoking access (only comments is required).
• Is there a way to bypass the approval stages?

Action (Wait) - wait for 2/3 minutes
Action (Get Access) - gets the user access
Operator (Compare Strings) - checks whether the access is provisioned

Action (Send Email) - Notify me if the access request is successfully provisioned.
Action (Send Email 1) - Notify me if the access request is not successfully provisioned.

Operator (End Step - Success)

2: For Failed Access Request Provisioning (non-direct source/Delimited File)

Trigger (?) - when access request provisioning status is set to ‘failed’ (instead of ‘committed’)

• Not sure if this would work when we use some logic in the filter in the ‘Provisioning Completed’ trigger when provisioning of access request is failed e.g $.accountRequests[?(@.source.name == "Jira Requests" && @.provisioningResult == "failed")]. Can you think of any other trigger we can use? OR
• Use ‘Access Request Decision’ - not sure if we can use this where there are multiple stages of approval?

Action (?) - gets the failed access request details e.g access request id, access name/Id, requester, recipient, source(s) details, operation (add/remove)

Action (Get Identity) - gets the user details
Action (Get Access) - gets the user current access

Operator (Compare Strings) - checks whether user has the access as sometimes it throws an error message/failure although access is provisioned successfully.

Action (HTTP Request) - creates a Jira ticket with the following details and bypass the approval stages.

• Subject: Grant/Revoke Test User Access to [Application Name]
• Description: provisioning team: access profile owner email
• Table with these details (9 rows and 2 columns)
  • System: [name of the application]
  • User: [recipient]
  • Email: [recipient email]
  • Username: [recipient AD samAccountName]
  • Access Level (Entitlement): [entitlement name]
  • Access Level (Access Profile):[access profile name]
  • Comment: [requester comments]
  • Approver (Audit Trail): [who approved and when]
  • SailPoint ID: [request tracking ID]
• Assignee: [access profile owner]
• Reporter: [recipient]

Operator (Compare Numbers) - checks whether API call is successful and notify me accordingly.

Action (Send Email) - notify me if the Jira ticket is created
Action (Send Email 1) - notify me if the ticket creation fails for whatever reason.

Operator (End Step - Success)

---

Thanks

[ramrangasamy87 (Ram Rangasamy)]

Hi Noor,

This is possible. All you need to do is, configure the provisioning retries in the source under “connectorAttributes” as shown below.

retryableErrors:

[
{
“op”: “add”,
“path”: “/connectorAttributes/retryableErrors”,
“value”: [“InvalidConfigurationException”,“Connection reset”,“Read time out”]
}
]

provisioningRetryThreshold:

[
{
“op”: “add”,
“path”: “/connectorAttributes/provisioningRetryThreshold”,
“value”: “1”
}
]

provisioningMaxRetries:

[
{
“op”: “add”,
“path”: “/connectorAttributes/provisioningMaxRetries”,
“value”: “3”
}
]

once you have configured it, if the access request fails, the source will retry and provision the request.

Note: All the possible error need to be captured in the retryableErrors, otherwise they won’t be retried.

I have implemented and it is working. Once request fails, it will automatically retry and request will be updated like below

“approvalStatus”:“FINISHED”,
“provisioningStatus”:RETRY",

Regards,
Ram

[nhassan (Noor Hassan)]

Hi Ram … thanks for your help with this.

A few questions related to this …
1: We would need this config for each individual source to retry failed provisioning access requests, isn’t?
2: Would this approach work for both sources types i.e direct connection and delimited source?
3: Which endpoint should we use to update the provisioning policy of a source regarding retryableErrors?
4: Once the initial access request fails, does it retry immediately or later e.g during identity refresh or nightly refresh? I’m thinking what will happen if there’s an issue with a source or on the VAs side or SailPoint outage for few hours or a day etc, in that case retry would still fail.
5: Would the JSON look like below?

“connectorAttributes”: {
“mergeColumns”: [
“groups”
],
retryableErrors:

[
{
“op”: “add”,
“path”: “/connectorAttributes/retryableErrors”,
“value”: [“InvalidConfigurationException”,“Connection reset”,“Read time out”]
}
]

provisioningRetryThreshold:

[
{
“op”: “add”,
“path”: “/connectorAttributes/provisioningRetryThreshold”,
“value”: “1”
}
]

provisioningMaxRetries:

[
{
“op”: “add”,
“path”: “/connectorAttributes/provisioningMaxRetries”,
“value”: “3”
}
]

[ramrangasamy87 (Ram Rangasamy)]

1: We would need this config for each individual source to retry failed provisioning access requests, isn’t? Yes, you need to configure this for all the sources individually.
2: Would this approach work for both sources types i.e direct connection and delimited source? It will work for direction connection as far as I am aware, because for delimited source will be take care manually.
3: Which endpoint should we use to update the provisioning policy of a source regarding retryableErrors? use this api " https://sailpoint.api.identitynow.com/beta/sources/:id"
4: Once the initial access request fails, does it retry immediately or later e.g during identity refresh or nightly refresh? I’m thinking what will happen if there’s an issue with a source or on the VAs side or SailPoint outage for few hours or a day etc, in that case retry would still fail. It will retry immediately as soon as it fails. It retries based on the configuration that you have specified in the source. In case issue is not resolved due to VA or any other issue, It will fail after all the attempts
5: Would the JSON look like below? Yes
[/quote]