Workflow to revoke specific accesses after lifecycle changes to inactive

Dear community,

I wanted to share with you a use case that we managed to solve using workflows (OOTB functionality) hoping the approach might help some of you tackle similar requirements. I found some similar use cases in here but we wanted to use OOTB as much as possible and we also wanted to target very specific accesses without having to go trough certification campaigns, hence the flow below.

Before I dive into it I just wanted to mention, that I’m a ServiceNow developer who is just starting to get his hands dirty with IdentityNow. Should you notice something that is not correct or explained poorly, please let me know.

In this scenario we are targeting only Access Profiles, however this could be of course applied to Entitlements or Roles as well.

Our use case was to revoke specific accesses, that are managed trough IdentityNow, after a user has been terminated (moved to inactive). For these “specific” accesses, we have cca. 220 different Access Profiles set up that can be requested by end-users. We don’t want to remove all accesses after an Identity becomes inactive, hence we had to look for a way how we can target specific accesses and revoke them. Obviously we started looking into workflows and exploring our options there.

One thing I need to mention is that we have a strict naming convention for our Access profiles, Roles or Entitlements, which I would see almost as a requirement to achieve our scenario.

One of the challenges we faced was that a loop in a workflow can only take 100 items as input. Hence we can’t iterate trough all the “specific” access profiles (as we have more than 200).
However we are 100% certain, that a user doesn’t have more than 100 of the access profiles assigned.
Therefore we just needed to get the Access Profiles by Identity, and then somehow filter them.
Sounds easy but it is a bit tricky in the workflows, as you can get accesses either by identity or by search query (but not combined).

Lucky for us there is this thing called JSONPath Syntax
So utilizing the JSONPath Syntax, we can narrow down the list of things we actually want to revoke.

Enough of boring text, let me show you how we set it up :

First we have a Trigger on Identity Attributes with an Advanced filter to trigger when an Identity moves to the inactive state :

$.changes[?(@.attribute == “cloudLifecycleState” && @.newValue == “inactive”)]

Once we have the workflow triggered, we grab all the accesses from the identity that triggered the flow:

$.trigger.identity.id

Now we are finally at the exciting part.
To be able to “loop” you need to define an Input and a Context.
In the Input you can define a JSONPath expression that can query an output that you retrieved in a previous step.
So we want the Access Profiles retrieved for an Identity and get all the Access Profiles starting with a specific pattern.
Let’s say we want to put in the loop just Access profiles that start with ABC

$.getAccess.accessItems[?(@.name =~ / ABC.*/i)]

From the shared link above regarding JSONPath Syntax
we know the following :
image

Hence the Loop Input will be queried by whatever starts with “abc” as in the example.

That’s all the magic required.
The Loop will be initiated with the list we narrowed down to include only access profiles starting with “abc” and revoke them accordingly.

This will iterate trough the provided identity and accesses and revoke them.

and that’s is it. And it didn’t even hurt!

Hope we can inspire or help some other peers tackling similar requirements.
If you have any feedback or comments, obviously let me know.

A lot of inspiration and ideas for this are drawn from :

ashish_kumar3284

Thank you ! :heart:

And obviously a huge thanks to our internal team for bouncing ideas off of each other and eventually making it happen :heart_hands:

4 Likes

This is incredible @adamslamena!

:joy:

2 Likes