Using IdentityNow to manage self‑service access requests is quite straightforward, but I’m struggling with the access removal part. Access profile/role/application owners are the ones with the functional expertise and should be able to revoke access within their scope. However, it seems that only managers can revoke access on behalf of their team members.
At the moment, access owners have to open a ticket with the IAM team so that a certification campaign can be created to remove access. This process is neither efficient nor scalable.
I’m curious to understand how you handle access removal on your side.
Completely agree that not being able to revoke any users access is kind of annoying especially when it was available in IIQ.
The workaround that I’ve seen recently is using forms to accomplish this. You can make a form launcher that is available to everyone to revoke access and have that data piped to the access request API to remove access. This of course requires development to do, but the backend is actually pretty simple (Form and workflow).
If you want any further details on that process, let me know!
That’s the process that I am currently working on :
Have a form that allow user to select certain identities (only identities that have an account on app A)
Have a select field only with access profiles that the user selected has on app A
That’s the part I am struggling with
Otherwise having a form to select a user, an AP/role and send an access removal API call is pretty straightforward. The difficulty is to be able to properly scope what access are displayed dynamically based on the user selected.
That is one limitation of the single form. The workaround there is using another form that gets sent to the user. So the flow would be like this:
Select the identity in the first form as well as the source the access needs to be removed from.
Pipe that info into another form in the workflow and utilize “form Inputs” to filter down the advanced search on what access profiles the identity has available.
May need to an API call to the get the access profile ID for each requested to removal item.
Loop through each of the access profiles that the user requested to be removed and submit an access request API call for each item.
I know this is a little clunky since the user will need to submit one form then wait for another form to be sent to their email, but I think it’s the best we have at the moment.
same idea but a bit enhancement using launchers instead of waiting for that form in the email.
launcher→1st form to pick users and account → submit → workflow kicks off to get the APs list for the identity → and presents the next form based on the workflow step output (does not have to be end of workflow)→ pick list of APs(max allowed 30, i think) then pass it back to the workflow to perform action revoke.