DaltonK.21011 (Customer) asked a question.
Hi all,
We are currently rolling out Okta to use a JIT workflow with our AWS IAM and Identity center and I need some guidance on fleshing out advanced logic. In short, i've already set up my provisioning and integration with AWS and I am able to create a basic access request where a user can request a certain role (Admin, EC2 User, RO, etc) for X amount of time. However, I want to expand it out to allow the user to pick how long they want it for. So far I am not able to manipulate my existing flow to make the logic work. I can ask the question and provide choices, but I haven't figured out how to map the choice 8 hours to actually be 8 hours for example. I also wanted to add approvals on this process so that if a user request Admin access for example approvals are sent out.. I haven't messed with the latter yet because I am focusing on the timing first.. Any guidance would be appreciated.
This is what I have so far.. which is not fully functional.
@DaltonK.21011 (Customer) - There isn't a way to dynamically set this up with just the Access Requests console. If it NEEDS to be dynamic you can likely do it by leveraging "Call a workflow" to call a delegated Flow to do this.
To do it stand-alone in the AR console you would need to have a match for each of the drop down selections. So lets say you have 2,4,8 hours.
You would have 3 different actions each with their own associated "Wait" time. The logic would then be "If Approved AND If Dropdown == 2" then do the 2 hour action. If 4, the 4 hour action and so on.
And yes. If you have multiple drop downs for selection you would have to build out each logic tree. So Select one of these 4 resources you want access to. Select one of these 4 times. That would be 16 different logic paths that would need to be build out.
Thanks Tim, let me look in to the call a workflow option
Essentially Access Requests (AR) can be utilized two ways: You can either do everything in the available interface where AR functions as both the frontend && backend or for scenarios where you need a higher degree of customization it can function as a clean frontend and the backend can be a Delegated Workflow that takes inputs from Access Requests and then performs the processing on the backend.
This allows you to do things like grant access to resources that may have an API but doesn't have any sort of streamlined provisioning.
The AR product is definitely still being developed and even in the last year the buildout options have expanded and I expect them to continue to do so. So I do expect a higher degree of flexibility natively in the product as it continues to mature.