Using Workflow's HTTP Request Action to Work With IdentityNow APIs

[kirby_fitch]

Purpose
Show you how to use Workflow’s HTTP Request Action to Work With IdentityNow APIs.

Configuration Steps

• Get a Personal Access Token (PAT) to call IdentityNow APIs.
• Trigger a workflow when an identity’s lifecycle state changes.
• Add a workflow action to get an identity’s AD account.
• Add a workflow action to send an email with AD account info.

Get a Personal Access Token (PAT) to call IdentityNow APIs.

1. Select your name in the top-right corner.
2. Select the Preferences menu.
3. Select the Personal Access Tokens menu.

4. Copy your Secret and Client ID into a safe place (you’ll need this later).

Trigger a workflow when an identity’s lifecycle state changes.

Add an Identity Attributes Changed trigger and set Attribute to Filter: cloudLifecycleState.

Add a workflow action to get an identity’s AD account.

Add an HTTP Request action and set the following attributes (leave all other fields blank):

• Authentication Type: OAuth 2.0 - Client Credentials Grant
• Token URL: https://TENANT.api.identitynow.com/oauth/token, replacing TENANT with your tenant name
• Client ID: Obtained above
• Client Secret: Obtained above
• Credential Location: Header
• Request URL: https://TENANT.api.identitynow.com/v3/accounts, replacing TENANT with your tenant name
• Query Parameters:

filters:identityId eq "{{$.trigger.identity.id}}" 
filters:sourceId eq "<SOURCE ID>" // ID for your Active Directory source.

• Method: GET
• Request Content Type: JSON

Add a workflow action to send an email with AD account info
Add a Send Email action and set the following attributes (leave all other fields blank/default):

• Recipient Email Address: an email address of your preference
• Subject: Lifecycle State Changed, Check AD Account
• Body:
  Dear Admin,<br><p>An identity's lifecycle state has changed. Please check their AD account:</p>${accountName}
• Templating Context:
  {"accountName.$":"$.hTTPRequest.body[0].name"}

Don’t forget to add an End Step - Success!

Outcome

Once you save and enable the workflow, the target address will receive this email each time an identity’s lifecycle state changes. Hope you found this helpful!

[blanghals (Ben Langhals)]

I too am looking for an example to follow for the Query Parameters. I see where to enter the name and value for the parameters in the Query parameters section, but I’m unclear on how to set them in the URL

[blanghals (Ben Langhals)]

In case it helps someone else, I found that an inline variable like this did the trick.

/v3/identities/{{$.trigger.identity.id}}/set-lifecycle-state

[jeseri (Jesper Ericsson)]

Hi, perhaps a new thread should be started but trying here first.
It works fine to use as described in this guide, however I would like to not use my personal token. Instead I have created client credentials from global → security settings → API Management and gotten my credentials and set all possible scopes. But when I try using these credentials I get error 403, forbidden.
I have tried without setting scope and with “sp:scopes:default sp:scopes:all”.

Is it not possible to use this kind of credentials or am I doing something wrong? Since it works with my personal token I guess former…

[colin_mckibben]

Hi Jesper. Did you create your global security credentials using the CLIENT_CREDENTIALS grant type? If so, that is the reason you are seeing a 403. The OAuth client credentials grant type doesn’t have a user context, and therefore can’t access many of our APIs which do require a user context. Furthermore, the HTTP Action in Workflows doesn’t have support for the AUTHORIZATION_CODE grant type, which would provide a user context after logging into IDN.

You must use a PAT (personal access token) when authenticating to IDN APIs using the HTTP action.

[jeseri (Jesper Ericsson)]

Hi Colin, yes I used client_credentials grant type. Alright I see, thank you for the quick response! Then I can stop looking for a “fix” for that and I will use PAT instead.

[arjun_sengupta]

Hello Colin,

Thanks a lot, I also faced the same issue yesterday and after using PAT it got solved.
Is there any plans to leverage Global credentials for these operations in future?

Regards
Arjun

[colin_mckibben]

There are no plans as of now. A user context is required for the majority of our APIs, so it’s best to use PAT for automations.

[angelo_mekenkamp]

I do like using the HTTP Request Action to call IdentityNow APIs when the out of the box actions are not sufficient.

I do want to raise a security risk here.
Even though the PAT secret will be encrypted here (does encryption occur before it gets send to the SailPoint server or afterwards?), it still allows other admins to use your personal access token for their own actions. They could either change the HTTP request to make a different call, but they could also use the workflow API to copy the reference to the secret (it looks like $.secrets.734625cf-abcd-1234-ef12-0702123c2f3), put it in a different workflow in the same tenant on a different HTTP request. This new workflow might even call the v3/create-personal-access-token endpoint (create-personal-access-token | SailPoint Developer Community) to create a second PAT for your account. This API then reveals the new PAT secret in plain text and this could be used by the malicious admin to perform any action pretending to be you. This will make audit data untrustworthy.

To limit this risk somewhat. You could think to create an identity in IdentityNow and create a PAT for that account which can be used for the workflow HTTP requests. By doing this, you can at least ensure that audit records that are saying you did something actually were performed by you. Additionally, you can limit the scope of the PAT such that it can only do what it should be able to do, and thus preventing the PAT from creating other PATs. Unfortunately, that last option is not always possible as not each operation has its own scope, so some operations still require the sp:scopes:all scope in order for the PAT to be able to call it.