Hi all,
We have a working source that supports direct provisioning. We want to turn this source into a read only source, for testing purposes (for example to do what-if analysis before a go-live).
So what we do is remove the ENABLE and PROVISIONING features from the source JSON.
We then create a role, which points to an entitlement from this source. We don’t assign any approvers to this role. We do allow access requests though
We then request this role for ourselves. We check the status and see the following:
This should not occur. There is no approval flow, so no approval needed, so there can’t even be such a thing as a self-approval here. So it should directly create a manual task to the source owner, which is me (angelo_mekenkamp) in this case. In the same way how, when we had the features added, it immediately provisioned the access. Now the requests gets forwarded to a random IdentityNow admin.
This makes it more difficult for developers to test the source by temporarily blocking direct provisioning to the source. I believe similar behavior occurs to sources that actually do not support direct provisioning, not just sources where we deliberately removed the PROVISIONING feature flag.
I mentioned this to @jennifer_mitchell, who agreed with me that this behavior is wrong and asked me to submit a bug report for this.
In addition see the following configuration where we would even allow self-approval on roles that have approval steps defined. I don’t think this configuration should actually be relevant here, since we specifically have no approval flow on this role, but I still want to show it for completeness sake:
Kind regards,
Angelo