How to dinamically authenticate an user inside a workflow?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hello everyone, I’m actually building a workflow that handles a costum “Request for others” with some costum forms that I have implemented. After some choices that the End-user makes, the HTTP Request block named: “submit request” is sending the approval request. The point is that actually I’m using the OAuth2.0 authentication that is related to a ClientID and a ClientSecret of a static account (an admin identity in my case). My requirement is to send this request with the credentials of the user that is launching this interactive form in the launchpad, anyone experienced with this kind of things can help me?

2

Hello @s_tartaglione

This is almost not possible .

  • Client ID and Secret are no where stored , to evaluate them during workflow execution .

  • HTTP action Client Secret is a static value and cannot be a variable value

3

There is an alternative?

4

I see no other alternative . The access request has 2 identities associated : requester , recipient . When the requester is not same as recipient , the request is made on behalf and will end up showing in requester tenant . No Luck ! :upside_down_face:

5

Yes it is ok, but who is launching the interactive form is not the same of the service account used to make the HTTP request. So i don’t know if in the workflow there is a way to authenticate dinamically the user that is using in that moment the workflow

6

Hi @s_tartaglione,

There are two ways to submit an access request within workflows:

  1. Manage Access action
  2. HTTP Action (using the “Submit Access Request” API)

In the first method, the Workflow Owner is designated as the requestor, and the request will appear under the Workflow Owner’s tenant requests.
In the second method, the Client Credentials Owner is considered the requestor, and the request will show up under their tenant requests.

In line with SailPoint’s security standards, the client secret is only visible at the time of creation and cannot be exposed or referenced from another variable. As a result, the client secret used in the HTTP action will appear masked.

We faced a similar requirement and ultimately had to proceed using client credentials tied to an admin identity. If you discover an alternative approach, I’d love to hear it!

7

Mhh thanks for your response, probably I can change the actually HTTP request “submit access request” that are present with the “manage access” and try to achieve the same results. I’ll update you if I will achieve that :slight_smile: .

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.