Workflow to remove access changes important global security setting

Feedback Bugs
, , ,
1

Hi team,

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:
image

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.
image

We performed a test of the workflow and it was successful, but now every identity can request all entitlements we have without approval flow.

Before executing the workflow:
beta/access-request-config

image
image568×679 33.7 KB

ui/admin#admin:global:system:features
image
ui/d/request-center/request-access
image

After executing the workflow:
beta/access-request-config

image
image553×676 33.6 KB

ui/admin#admin:global:system:features
image
ui/d/request-center/request-access
image

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.

3 Likes
3

Thank you for reporting this Angelo. We’re looking into it.

5

We are able to reproduce this issue and are investigating solutions. Ticket number for our reference is PLTWRKFLW-2900.

1 Like
6

Great, thank you @colin_mckibben.

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”.

4 Likes