Workflow to remove ALL leavers' standing access

[mostafa_helmy]

Hi everyone,

This workflow auto-revokes any standing access leavers have either through a micro targeted access certifications or by leveraging revoke access requests after being terminated. This should ensure that all leavers’ access is removed upon terminated and not just access assigned through birthright roles. Additionally, an audit trail is generated to document when and why the access was removed.

This workflow was designed and built with the help and input of a multiple people! Thanks to everyone involved

Workflow Design

High-level design?

Simple Implementation

This solution uses a single workflow triggered by the Identity Attribute Change event.

Advanced Implementation

This solution uses two (optionally three) workflows - the master, an optional scheduled, and two options of child workflows depending on your requirements.

• The Master workflow’s trigger is Identity Attribute Change. It calls the child workflow once.
• [Optional] The Scheduled workflow’s trigger is Scheduled Trigger. It calls the child workflow in a loop.
• The child workflows’ trigger is External Trigger (as it is being called by the Master and Scheduled workflows).

1. The Master Workflow

The master workflow is triggered off of changes of the cloudLifecycleState attribute also ensuring the newValue is inactive. This can be different per environment according to when you want to remove all standing access of leavers.

2. The Child Workflow Options

Option 1: Access Certification Child Workflow

This child workflow only gets the id of the leaver identity. The child workflow creates a micro targeted certification campaign specifically for the leaver. Be default, we are assigning the campaign to the leaver’s manager, however all notifications and recommendations are disabled. Then it automatically completes the campaign and revoke all access.

Option 2: Access Request Child Workflow

This child workflow also only gets the id of the leaver identity. The child workflow uses the Search API to find access items that can be revoked such as standalone entitlements and revocable Access Profiles and Roles (i.e. non-birthright access). It then uses the default Manage Access step to submit access requests to revoke such access.

[Optional] 3. The Scheduled Workflow

Optionally, you can use this workflow to perform a cleanup of all standing access for your existing leavers. The scheduled workflow is scheduled to run every 12 hours, however this can be tweaked as required. The Search API is utilized to find all leavers that have standing access that should be revoked.

Considerations

Please make sure you properly test the workflows in your sandbox environments before introducing any changes to your production environments

Which child workflow should I use?

The recommended approach is using Option 1: Access Certification Child Workflow for the following reasons:

• Simple and clean approach to remove ALL access
• Concise audit record of all leaver access being removed in one area (the leaver campaign)
• No scalability or perfomance concerns

You may want to use Option 2: Access Request Child Workflow for the following reasons:

• The need to filter on specific access that should be removed
• Leaverging the configured revoke access approvals in your leaver process

Please note that using the Option 2: Access Request Child Workflow introduces some limits to the process with looping, which may result in an incomplete removal of access on the initial go. It might be a good idea to use the Scheduled Workflow in addition to the Option 2: Access Request Child Workflow to ensure ALL access is removed in the later iterations.

Usage Instructions

Please make sure you properly test the workflows in your sandbox environments before introducing any changes to your production environments

1. Download the three required Workflow JSON scripts (see below).

2. Create a Personal Access Token (PAT) to get a client ID/secret pair needed for the API calls. You must add the sp:scopes:all scope to your PAT.

3. Upload the Simple workflow JSON (if using the simple implementation) or the Child workflow of choice JSON first into your Identity Security Cloud tenant.

4. Edit the Workflow in the Workflow Builder, substituting: your OAuth Client ID, OAuth Client Secret, OAuth Token URL and Request URL with the PAT details and the correct tenant name for the followin steps depending on your choice of child workflow

• Simple / Access Certification Child workflow steps:
  • Update Campaign Deadline
  • Autocomplete Leaver Campaign
• Access Request Child workflow steps:
  • Get Standalone Entitlements
  • Get Revocable Access

Next steps are only required if using the Advanced Implementation

5. Generate a new access token from the child workflow’s external trigger to avoid problems where the master/scheduled workflows and preferred child workflow are not in sync.

• In the preferred child workflow, edit the External Trigger step
• Press [+New Access Token]. This generates a new Client URL, Client ID and Client Secret.
• Write them down somewhere as you will need them in the upcoming steps

6. Upload the Master workflow JSON into your Identity Security Cloud tenant.

7. Edit the Master Workflow in the Workflow Builder, substituting: your OAuth Client ID, OAuth Client Secret, OAuth Token URL and Request URL with the External Trigger details genetated from the Child workflow for the Remove Standing Access step.

8. [Optional] Upload the Scheduled workflow JSON into your Identity Security Cloud tenant.

9. Edit the Scheduled Workflow in the Workflow Builder, edit the Scheduled Trigger step, changing the frequency to whatever is requrired.

10. Edit the Find Leavers with Access step substituting: your OAuth Client ID, OAuth Client Secret, OAuth Token URL and Request URL with the PAT details and the correct tenant name.

11. Edit the Remove Leaver Access step, substituting: your OAuth Client ID, OAuth Client Secret, OAuth Token URL and Request URL with the External Trigger details genetated from the Child workflow.

Workflow Definitions

Simple Leaver Workflow

Leaver - Simple - Remove All Access - fix.json (5.0 KB)

Advanced Leaver Workflows

Leaver - Master - RemoveStandingAccess.json (1.5 KB)
Leaver - Scheduled - RemoveStandingAccess.json (3.1 KB)
Leaver - ChildAccessCertifications - RemoveStandingAccess.json (4.7 KB)
Leaver - ChildAccessRequests - RemoveStandingAccess.json (4.3 KB)

[ashish_kumar3284 (Ashish Kumar)]

@mostafa_helmy

One questions, can we update the step “Create Leaver Campaign” just to include only access from a specific application instead of all applications?

Thanks

[mostafa_helmy]

I don’t think the Create Access Certification step supports that at the moment.

I initially created another implementation of the Child Workflow which uses Access Requests instead of Access Certifications.

It uses the Search API to only find the roles, access profiles, and entitlements that can be removed and honours the heirarchy. By tweaking the Search queries used in the Get Standalone Entitlements and Get Revocable Access steps, you should be able to target only specific applications.

The reason I did not post this implementation is because it has limitations due to the need to use workflow loops.

Leaver - ChildAccessRequests - RemoveStandingAccess.json (4.5 KB)

[jfinley (Justine Finley)]

Hi @mostafa_helmy Is Get Revocable Access an out of the box action? I wasn’t able to find it.

[mostafa_helmy]

It’s basically an HTTP Action step which calls our /v3/search API, I just renamed it and all other steps from the workflow JSON to have a meaningful name. That way it was easier for me to visualise which step does which action.

Same thing for the Get Standalone Entitlements step, just a slightly different search query.

[JB281 (Joseph Barone)]

Excellent work! Thanks so much for this Mostafa and team!

[mostafa_helmy]

I updated the post to reflect the two options for child workflows (Access Certifications vs Access Requests) along with when to consider either option.

[udayputta]

Nice Post Mostafa. Does this allow to remove all of the entitlements which are assigned by access profiles for a particular source account? I see you have introduced loop will the loop work if there are more entitlments like 50+

[mostafa_helmy]

Hey Uday, there are two ways of removing acces:

1. Recommended: Using the workflow that generates a micro-certification which will remove all access
2. Using the workflow which submits Access Requests, which can remove all Roles/Access Profiles (including all their sub-entitlements) without looping, but needs to loop to remove any out of role / out of access profile entitlements.

Currently there is a limit of 100 iterations per loop, which is why an additional “Scheduled” workflow was created, in case you decide to use the Access Request workflow (which requires loops). The scheduled workflow will keep calling the Access Request workflow on a scheduled basis for each leaver it finds that still has access that needs to be removed.

It is not an ideal scenario, which is why I would always recommend using the Access Certification workflow approach.

[tomkelly]

Hi Mostafa, how did you rename the nodes in the workflow? don’t see a option for this in the UI.

[mostafa_helmy]

Hey Tom, there isn’t a way to do that from the UI. You have to change all references from the JSON definition and re-upload the modified JSON.

To rename a step, you need to:

1. Rename the step itself
2. Rename the previous steps “nextStep” reference
3. Rename any downstream step references to the renamed step (e.g. If you rename a step from “Get Identity” to “Get Leaver Details”, then $.getIdentity.id would become $.getLeaverDetails.id)

[joC11 (Joanna Clapka)]

Hi, I tried implementing this in our test environment today. Followed all the steps in your first post, saved and enabled both workflows with no errors however when manually changing the LCS of a test user to Inactive it does not trigger the master workflow.

I double checked that the trigger is correctly set and capitalisation matches the LCS config but I’m not able to get it working.

Any ideas what could be causing this?

[mostafa_helmy]

Sorry I just saw this response now. Ping me directly to try and investigate what’s happening at your side.

[matt_totty]

Good morning. I am curious to know how to get the Get Current TimeStamp beta operator. Or how to grab now() without having it?

[mostafa_helmy]

The “Get Current Timestamp” operator is just a “Define Variable” which I renamed through the workflow JSON definition. In it, I am using the following JSONPath expression which returns the current timestamp in ISO8601 format

$.now()

In theory, you might be able to use the above expression as an in-line variable, but I haven’t tested that myself.

{{$.now()}}

[mostafa_helmy]

Here is the JSON definition of that step

			"Get Current Timestamp": {
				"attributes": {
					"variables": [
						{
							"name": "now",
							"transforms": [],
							"variableA.$": "$.now()"
						}
					]
				},
				"description": "Get the current timestamp which will later be used to update the generated Certification Campaign due date",
				"nextStep": "Get Leaver Details",
				"type": "Mutation"
			}

[matt_totty]

Ok, thank you! I just saw the beta tag and thought it was something that is built in now lol.

[mostafa_helmy]

Ah yes! It was still a Beta step back when I initially created this workflow

[natanbueno (Natan Oliveira)]

Hello, we are having the following error, could you help us solve it?

{"error":"actionStep(Update Campaign Deadline) Err: task failed: activity error (type: sp:external:http:v2, scheduledEventID: 29, startedEventID: 30, identity: a1556ebf-07a8-48b0-bb48-d168e83f3cf5): request failed (type: HTTP Response Returned a Client Error, retryable: false): request failed: 400 - 400 Bad Request - {\"detailCode\":\"400.1 Bad request content\",\"trackingId\":\"430f36222dc3425fb80e9f6c70309e1e\",\"messages\":[{\"locale\":\"und\",\"localeOrigin\":\"REQUEST\",\"text\":\"The request was syntactically correct but its content is semantically invalid.\"},{\"locale\":\"en-US\",\"localeOrigin\":\"DEFAULT\",\"text\":\"The request was syntactically correct but its content is semantically invalid.\"}],\"causes\":[]}"}

[matt_totty]

I am seeing this exact error on my side as well. I did not see this before last Friday. Edit: Mine is occurring on the POST to revoke {“autoCompleteAction”:“REVOKE”}.
I have an additional error in the log too.
Potential deadlock detected: workflow goroutine "root" didn’t yield for over a second