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}
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!
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
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…
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.
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.
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?
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.
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?
