We are working on a workflow used in the leaver phase where we remove the roles and, for certain sources, remove all additional entitlements an identity might have. Even though we don’t want the identities to request single entitlements (allowEntitlementRequest is marked as false), there still might be standalone entitlements that identities have that needs to be removed by this leaver flow.
We started testing the Manage Access Action with a very simple workflow:
1: External trigger without any input needed.
2: Manage access, where we choose a static identity and choose a static (standalone) identity
3: End workflow success step.
So because we run this workflow to remove access, all identities can now request all entitlements without approval flow. This looks like a bug to me which poses a big security risk.
For our use case, it makes sense that the manage access actually manages the revocation of access, instead of requesting it and triggering the approval flow. It would be strange if the leaver workflow can only revoke entitlements if we allow identities to request entitlements.
Ideally there are two ways how we can manage access via workflows.
One way is where we treat workflows as powerful creators. If a workflow resembles a leaver flow that should be able to remove access, disable or delete accounts, it makes sense that no approval is required. So here it is not an access (revocation) request, but a command. Hence the action name “manage Access”
Another way is we treat workflows as functionality enhancing endpoints. Maybe a system can call the workflow to request something on behalf of somebody, where the workflow does some small checks, and then calls the access request action/API, to ensure that the standard approval flow also occurs. Hence the action name “Create Request for Access”.
No progress has been made on the ticket. I know you shouldn’t have to do this, but a workaround until a fix is in place would be to add an HTTP action to toggle the allowEntitlementRequest back to false.