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

Identity Security Cloud (ISC) ISC Community Knowledge Base
,
1

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.

image
image3560×1858 359 KB

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

image
image3560×1858 276 KB

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

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

image
image3560×1858 492 KB

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

image
image3570×1868 545 KB

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!

image
image1920×1002 108 KB

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!

image
image1842×696 60.1 KB

13 Likes
3

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

4

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
1 Like
5

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…

6

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.

2 Likes
7

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.

8

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

9

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.

1 Like
10

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.

9 Likes
12

A post was split to a new topic: Workflow to trigger unoptimized aggregation

13

Hello @kirby_fitch, @colin_mckibben I am trying to replicate this API call and I believe everything is set up correctly, however I am running into an error mentioned in Workflow HTTP Request query params don’t allow colons. Is it possible that this guide became obsolete because of the error mentioned in the thread I’ve linked?

14

Hi @kirby_fitch,
I am facing issue while I am testing above workflow with below Error at HTTP Request Step
error getting Access Token for OAuth: Post “https://xxxxx-api.identitynow-demo.com/oauth/token?grant_type=client_credentials”: dial tcp: lookup xxxxx-api.identitynow-demo.com on 169.254.xx.xx:53: no such host

Here is my request URL with query param:
Request URL: https://xxxxx.api.identitynow-demo.com/accounts?filters=identityId eq “{{$.trigger.identity.id}}” and sourceId eq “sourceid of AD”

Could you please help me on this?

15

This issue has been resolved. Problem with my Request URL.

1 Like
16

Could you pls let me know what the issue & fix was as I am facing the same.

17

@rishisri I had issue with my below account request URL v3 was missing

Request URL: https://xxxxx.api.identitynow-demo.com/accounts?filters=identityId eq “{{$.trigger.identity.id}}” and sourceId eq “sourceid of AD”

It should be
https://xxxxx.api.identitynow-demo.com/v3/accounts?filters=identityId eq “{{$.trigger.identity.id}}” and sourceId eq “sourceid of AD”

1 Like
18

Thank you for your quick response. my url is correct but getting the error dial tcp: lookup my url on 169.254.20.10:53: no such host (type: Error, retryable: true): dial tcp: lookup my url on 169.254.20.10:53: no such host (type: OpError, retryable: true): lookup my url on 169.254.20.10:53: no such host (type: DNSError, retryable: true)"}. I replaced actual URL with my url which is working in postman. I really appreciate if you have any suggestions on this. Thank you.

19

@rishisri Can you share your workflow json after removing sensitive info?

20

Thank you.

{
“name”: “my workflow”,
“description”: “To Add/Remove/query Access”,
“modified”: “2025-01-02T15:23:25.124518554Z”,
“modifiedBy”: {
“type”: “IDENTITY”,
“id”: “62559f9236754a1bb504a611d72d5340”,
“name”: “999999”
},
“definition”: {
“start”: “Get Identity”,
“steps”: {
“Compare Numbers”: {
“choiceList”: [
{
“comparator”: “NumericEquals”,
“nextStep”: “Get Access”,
“variableA.$”: “$.hTTPRequest2.statusCode”,
“variableB”: 200
}
],
“defaultStep”: “End Step - Failure”,
“displayName”: “”,
“type”: “choice”
},
“Compare Numbers 1”: {
“choiceList”: [
{
“comparator”: “NumericEquals”,
“nextStep”: “End Step - Success 1”,
“variableA.$”: “$.hTTPRequest1.statusCode”,
“variableB”: 200
}
],
“defaultStep”: “End Step - Failure 1”,
“displayName”: “”,
“type”: “choice”
},
“Compare Numbers 2”: {
“choiceList”: [
{
“comparator”: “NumericEquals”,
“nextStep”: “End Step - Success 2”,
“variableA.$”: “$.hTTPRequest.statusCode”,
“variableB”: 200
}
],
“defaultStep”: “End Step - Failure 2”,
“displayName”: “”,
“type”: “choice”
},
“Compare Strings”: {
“choiceList”: [
{
“comparator”: “StringEquals”,
“nextStep”: “HTTP Request 2”,
“variableA.$”: “$.trigger.formData.requestType”,
“variableB”: “Add”
}
],
“defaultStep”: “Compare Strings 1”,
“description”: “”,
“displayName”: “”,
“type”: “choice”
},
“Compare Strings 1”: {
“choiceList”: [
{
“comparator”: “StringEquals”,
“nextStep”: “HTTP Request”,
“variableA.$”: “$.trigger.formData.requestType”,
“variableB”: “Remove”
}
],
“defaultStep”: “HTTP Request 1”,
“displayName”: “”,
“type”: “choice”
},
“End Step - Failure”: {
“displayName”: “”,
“failureName”: “AddAccessError”,
“type”: “failure”
},
“End Step - Failure 1”: {
“description”: null,
“displayName”: “”,
“failureName”: “QueryAccessError”,
“type”: “failure”
},
“End Step - Failure 2”: {
“description”: null,
“displayName”: “”,
“failureName”: “RemoveAccessError”,
“type”: “failure”
},
“End Step - Success”: {
“displayName”: “”,
“type”: “success”
},
“End Step - Success 1”: {
“displayName”: “”,
“type”: “success”
},
“End Step - Success 2”: {
“displayName”: “”,
“type”: “success”
},
“Get Access”: {
“actionId”: “sp:access:get”,
“attributes”: {
“accessprofiles”: false,
“entitlements”: true,
“getAccessBy”: “searchQuery”,
“query”: “source.id:2c68a5b419624fb2a5cbee75d8911ed2 AND displayName: {{$.trigger.formData.geoTabRoleNeeded}}”,
“roles”: false
},
“displayName”: “”,
“nextStep”: “Manage Access”,
“type”: “action”,
“versionNumber”: 1
},
“Get Identity”: {
“actionId”: “sp:get-identity”,
“attributes”: {
“id.$”: “$.trigger.formData.requesterName”
},
“displayName”: “”,
“nextStep”: “Compare Strings”,
“type”: “action”,
“versionNumber”: 2
},
“HTTP Request”: {
“actionId”: “sp:http”,
“attributes”: {
“authenticationType”: “OAuth”,
“jsonRequestBody”: {
“email”: “[email protected]”
},
“method”: “post”,
“oAuthClientId”: “xxxx-client”,
“oAuthClientSecret”: “$.secrets.7fefd315-e9d7-4a1e-ab71-c93e3a87abf0”,
“oAuthCredentialLocation”: “oAuthInHeader”,
“oAuthTokenUrl”: “https://ssourl/auth/realms/security/protocol/openid-connect/token”,
“requestContentType”: “json”,
“url”: “https://myurl/myapi/removeAccess”
},
“displayName”: “”,
“nextStep”: “Send Email”,
“type”: “action”,
“versionNumber”: 2
},
“Manage Access”: {
“actionId”: “sp:access:manage”,
“attributes”: {
“addIdentities.$”: “$.trigger.formData.requesterName”,
“requestType”: “GRANT_ACCESS”,
“requestedItems.$”: “$.getAccess.accessItems”
},
“displayName”: “”,
“nextStep”: “End Step - Success”,
“type”: “action”,
“versionNumber”: 1
},
“Send Email”: {
“actionId”: “sp:send-email”,
“attributes”: {
“body.$”: “$.hTTPRequest.body.message”,
“context”: {},
“from”: “[email protected]”,
“recipientEmailList”: [
“[email protected]”
],
“replyTo”: “[email protected]”,
“subject”: “request Status”
},
“displayName”: “”,
“nextStep”: “Compare Numbers 2”,
“type”: “action”,
“versionNumber”: 2
}
}
},
“creator”: {
“type”: “IDENTITY”,
“id”: “62559f9236754a1bb504a611d72d5340”,
“name”: “199770”
},
“trigger”: {
“type”: “EVENT”,
“attributes”: {
“filter.$”: “$[?(@.formDefinitionId == ‘72217952-9c65-491a-8ebb-5141a9f99fdd’)]”,
“formDefinitionId”: “72217952-9c65-491a-8ebb-5141a9f99fdd”,
“id”: “sp:form-submitted”
}
}
}

21

This is the step I am testing which is failing.

“HTTP Request”: {
“actionId”: “sp:http”,
“attributes”: {
“authenticationType”: “OAuth”,
“jsonRequestBody”: {
“email”: “[email protected]”
},
“method”: “post”,
“oAuthClientId”: “xxxx-client”,
“oAuthClientSecret”: “$.secrets.7fefd315-e9d7-4a1e-ab71-c93e3a87abf0”,
“oAuthCredentialLocation”: “oAuthInHeader”,
“oAuthTokenUrl”: “https://ssourl/auth/realms/security/protocol/openid-connect/token”,
“requestContentType”: “json”,
“url”: “https://myurl/myapi/removeAccess”
},