I am looking for a solution to a use case where there are two types of access, by birth and on-demand, the ones by birth will be assigned with a role and the ones on-demand with access profiles, each time they request an access on-demand (access profile) the previous one has to be deleted and the new one placed, it is important to ensure that only one access profile can be used for a given application, is this possible to carry out through a workflow?
For the one provisioning for birthright through a role, you could add a criteria in the role to check that the identity does not hold those entitlements, like this for example:
This is possible with a Workflow which has an External Trigger. This Workflow would be called by the “Access Request Submitted” Event Trigger and would check if the identity currently has one of these Access Profiles. If yes, then it submits a request to remove the old AP in order to allow the new one.
See this post on how to configure a Workflow with a request-response type Event Trigger: Implementing A Request Response Type Trigger in Workflows
What if we make entitlement attribute as single valued, not multi-valued. By default attribute value will be overridden. AFAIK, once the aggregation Runs, if no old entitlement value in account then the respective Access Profile will be deleted.
Would this work even if the request was not generated in IdentityNow? In this scenario, the requests are generated in ServiceNow and through the integration of the service catalog, the assignment of these access profiles is triggered.
I haven’t tested this scenario, but it should work because the ServiceNow Catalog integration calls the Access Request API to submit the request. This is equivalent to making the Access Request through the IDN Request Center
Before workflow module is introduced, for a similar requirement in our project, we achieved it by modifying the plan in beforeprovisioning rule by adding the existing entitlements of the account for removal operation.
After the workflow module is in place, I tried resolving the use case by workflow. I used “Access Request Decision” trigger with a condition that the access is approved and provisioned successfully. And then added the steps to remove any existing profiles of the source.
But, the issue I faced is it fails the workflow trying to remove an access profile which is granted as birthright by the role. I had to exclude the birthright access profile for removal if the role is assigned to the user.
