I am currently implementing the ServiceNow Governance connector and my business team has a requirement where the final member of an assignment group is not to be revoked.
I figured that the best way of implementing something like this would be via a BeforeProvisioning rule: I can remove the AttributeRequest objects if I determine that the there is one final member of an assignment group that is presently being revoked.
However, this raises the question of properly auditing this scenario, especially making it clear that no provisioning to remove assignment group was actually performed. BeforeProvisioning rules don’t allow for influencing the final ProvisioningResult to as to return a failed provisioning status.
Any thoughts on how I can handle this scenario? I am open to exploring options other than BeforeProvisioning rules too!
IdentityIQ has a feature called “Policies” for this (Setup | Policies).
Create an Advanced Policy and you can supply a rule for the logic. e.g. If you found out the request is going to remove the last user from the group, then you can return a PolicyViolation object.
You can modify the workflow variable “policyScheme” in workflow “LCM Provisioning” to control the behavior when a policy violation happens. The default is “continue”, but you can change it to “interactive” to ask the user to change his access request.
But there is a catch - you can have access requests pending for approval. e.g.
Group 1 has two users, User 1 and User 2.
Access request 1 is submitted to remove User 2.
Now your policy is executed. It sees that currently Group 1 has two users, so no PolicyViolation is raised. Access request 1 is submitted for approval.
Access request 2 is submitted to remove User 1.
Your policy is executed again. It sees that currently Group 1 has two users, so no PolicyViolation is raised. Access request 2 is submitted for approval.
Now you see that’ll be a problem. Both requests are valid at the time of submission, but not when they are later approved and executed.
So your idea of using before provisioning rule is on the right track - you will need to check again right before provisioning and block it if necessary.
The “interactive” policyscheme is a user-friendly feature - it prevents user from wasting time submitting a request that will be voided by the before provisioning rule, at least as well as it can, due to the issue of requests pending for approval.
In before provisioning rule, you can modify the provisioning plan and it will be reflected in the access request log (the removed item will not be listed in the provisioning engine section). For more user-friendliness, you can send email notification or log messages to the access request in your before provisioning rule.