Workflow to revoke only Requestable roles and access profiles

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello Everyone,

We have a requirement to revoke only requestable roles and access profiles for terminated identities via Workflow. I’m using below API search query in "HTTP Request " operation to get the same. Unfortunately, it’s not returning me any identities. Could someone please help?

{
    "indices": [
        "identities"
    ],
    "query": {
        "query": "attributes.cloudLifecycleState:terminate AND !roleCount:0",
        "innerHit": {
            "type": "access",
            "query": "type:ROLE AND requestable:true"
        }
    },
    "includeNested": true
    
}
2

Hi Theja,

Take a look at the /requestable-objects endpoint in SailPoint’s APIs. It lists the available requestable APs and Roles for a particular identity AND lets you know if they’re assigned. You could use this and loop through the assigned ones to revoke them in your workflow.

Thanks,

Liam

3

Thanks @liamkokeeffe . Can we pass dynamic values in request parameters? As the HTTP request is inside the loop, want to know how to pass the identity id for the GET request

image
image340×504 11 KB

4

Hey, use this attribute in the query “revocable:true”

best!

5

revocable: true, does this means that all are requestable ones?
We have a scenario where the roles are getting revoked but access profile which was part of that role still exists in identities? (may be a bug) For this scenario I believe revocable will be false as the access profiles were encapsulated in a role. So, we need to remove these APs as well. Correct me if i’m wrong

1 Like
6

Hi Theja,

Are you trying to process multiple identities in one workflow run? Or a single identity?

After seeing Ivan’s response, I think using the ‘requestable: true’ query would be an easier solution. The high level workflow would look like this:

  1. Identity termination action trigger (eg. LCS identity attribute changes to terminate)
  2. Get the identity access (AP’s and Roles) - can specify a search query (requestable:true)
  3. Loop through the returned access and submit revoke requests

I believe the loop limitation is still 100 items, so workflows may not be the appropriate solution if you are expecting identities to have more than 100 requestable access assigned.

Thanks,

Liam

7

Hi @liamkokeeffe ,

Scope is to process many identities. But this can be handled by setting limit in HTTP operation for API search query. I’ll have a try by adding “revocable: true” in query and check if it returns only the requestable objects.

8

Hi Theja,

The query will be requestable:true.

Do not believe revocable is an attribute you can search on.

Thanks,

Liam

9

For revocable query in a workflow, try using the below step

                "actionId": "sp:http",
                "attributes": {
                    "authenticationType": "OAuth",
                    "jsonRequestBody": {
                        "indices": [
                            "identities"
                        ],
                        "query": {
                            "innerHit": {
                                "query": "revocable:true  AND NOT source.id:<filter if needed>",
                                "type": "access"
                            },
                            "query": "id:\"{{$.trigger.id}}\""
                        }
                    },
                    "method": "post",
                    "oAuthClientId": "",
                    "oAuthClientSecret": "",
                    "oAuthCredentialLocation": "oAuthInHeader",
                    "oAuthScope": null,
                    "oAuthTokenUrl": "https://<tenant>.api.identitynow.com/oauth/token",
                    "requestContentType": "json",
                    "requestHeaders": "Content-Type:application/json",
                    "textRequestBody": "",
                    "url": "https:/<tenant>.api.identitynow.com/v3/search"
                },
                "description": "Get all Revocable Access",
                "nextStep": "Has Revocable Access?",
                "type": "action",
                "versionNumber": 2
            }
10

Thanks @margocbain, @liamkokeeffe . I have used below query to get only the requestable roles. It is working fine in Postman if I give the identity Id value manually. But it’s not working inside the loop. It’s not able to get the identity Ids inside the loop. (FYI…I can see the Identities Ids being passed as loop input)

@colin_mckibben Appreciate your help here.

{"indices":["identities"],"query":{"innerHit":{"query":"revocable:true AND type:ROLE","type":"access"},"query":"id:\"{{$.loop1.loopInput.id}}\""}}

image
image763×517 15.8 KB

11

Are you passing $ context to loop if not, pass the context.

12

I have tried passing the context and changing the Query to “query”:“id:"{{$.loop1.context.id}}"”}}. Still no luck

13

What exactly is configured as loop input?

14

Input to the loop is from above HTTP request which pull the identities from a query.
Loop Input: $.hTTPrequest.body
Contex searcht: $.hTTPrequest.body[*].id

15

Its working as expected if I give ID manually as below for HTTP operation.

{"indices":["identities"],"query":{"innerHit":{"query":"revocable:true AND type:ROLE","type":"access"},"query":"id:506195b565d242c2b654db83c85bc4b5"}}

But its failing for below

{"indices":["identities"],"query":{"innerHit":{"query":"revocable:true AND type:ROLE","type":"access"},"query":"id:\"{{$.loop1.loopInput.id}}\""}}
16

Hi Theja,

You don’t need to pass revocable:true or requestable:true in your query because if you are calling REST API list-requestable-objects | SailPoint Developer Community suggested by @liamkokeeffe then its returning only requestable objects of identity. just update “query”:“types:ROLE” and try. hope this will helps.

17

Hi Sagar,

I’m not calling requestable objects API. I’m calling search API. Attached is the complete workflow
Roleremoval20241113.json (4.3 KB)

19

Loop Input: $.hTTPrequest.body
Contex searcht: $.hTTPrequest.body[*].id

if already id is mentioned in the context then why specify id again in the query , isn’t just “id:“{{$.loop1.context}}””}} enough

20

Still the same. Any way to check the steps execution inside the loop?

22

Put a “Send Email” action inside the loop and send the search body as an email to yourself. If you find {{$.loop1.loopInput.id}} rendered correctly in the email, then there is some issue with execution of workflow and you need to contact SailPoint for help