We’re confronting challenges in automating control of Access Profiles in IdentityNow, particularly concerning the updated Request Center. With the ability for users to request multiple Access Profiles simultaneously, we’re exploring solutions to prevent a user from having more than one Access Profile for a specific application.
Previously, the older Request Center allowed us to efficiently implement double-checking using the “Access Request Decision” event trigger and its asynchronous integration with AWS EventBridge. However, this approach encounters issues with the new Request Center and events ordering.
Currently considering a shift to the “Access Request Submitted” trigger, we’d like to hear from anyone who has faced similar challenges or if there are recommended approaches for this specific use case.
Thanks in advance for any guidance, experiences, or suggestions that could help address this challenge.
Hi Matheus,
I doubt this will work now in the new Request center as it allows to request for multiple access profiles. Could you please let us know what is the target system you want to acheive this requirment ?
Thank you for your response. The target system in question is an internal system that requires a “single access profile” per user. We don’t utilize IdentityNow Workflows; instead, we have our own automation that leverages the “Access Request Decision” event trigger. As mentioned earlier, we are currently exploring more effective approaches to ensure a single access profile.
Hello Matheus, if your idea is that when someone requests an access for an application, and already has an assigned access, through the workflows you can make them remove the previous accesses they have to the application.
In this project, we don’t use workflows, so we need to develop an automated way to achieve this behavior through the IdentityNow API and Event Triggers.
What type of connector you are using for this?, If its a JDBC connector, you can ask DB team to write the store procedure to handle the same for any provisioning requests.
Configure Operations in sequence.:- Configure two add entitlement operations, where first one will actually remove the existing entitlement and the second one will add the requested entitlement. You can use Get-Object operation in-between to get the user details.
Write before operation rule:- In Add Entitlement operation, write a before operation rule to get the user’s existing access and remove it, Then actual Add Operation will add the requested entitlement.