Hello,
We are creating access requests using a plugin. The access requests are getting created fine, we are creating a plan and calling LCM Provisioning to create the access requests
However, while this access request is waiting for approval, if we go to manage access and raise a request for the same item (same user), we are able to do so
If we raise an access request from the manage access page and then try to request the same item from the manage access page it stops us. It looks like the Manage access page isn’t able to detect the access requests created via the plugin. We tried comparing the identity request created via plugin vs what manage access creates, and we tried copying over the missing tags but that didn’t help
If anyone has any thoughts around what could be causing this it would be a great help!
When you select to add an Entitlement in the Manage User Access page, there is a REST API call done in the background (/ui/rest/requestAccess/accessItems/ID-of-selected-entitlement-or role/additionalQuestions). The response from this REST call is what triggers the yellow pop-up which says “The item you are trying to select is already assigned”. The Access Request workflow does not contain any logic to check if the requested access is already held by the target identity.
This is most likely the reason why you don’t get any errors when launching the Access Request Workflow externally (from your plugin, or via the SCIM API, etc.). You would need to customize your Workflow (or your plugin) so that it validates if the identity already has the access being requested.
The logic to check existing request(s) is present in the plugin, but the issue is OOTB Manage User access is unable to detect any request raised by us via the plugin
Correct, as I mentioned earlier the Access Request Workflow (LCM Provisioning) does not perform any validation to check if the identity already has the requested access. This validation is done at the UI level (via a REST API call) on the Manage User Access screen when you click on the checkmark to select an entitlement. If your plugin is already performing this validation, then I would assume the plugin should prevent the user from submitting the access request if the requestee already has that access.
Yes, Paulo, We are able to do and already restricting users to again select Access either it was raised via Manage User Access or our plugin. But the issue is the Manage User Access pages, it isn’t able to validate the existing request raised by the plugin. The plugin is doing everything expected, the problem is OOTB Manage User Access Page.
When you call the LCM Provisioning workflow from your plugin, what is the flow variable set to?
It should be set to either “AccessRequest” or “RoleRequest”
Yes @christian_cairney, We checked that as well. Per requirement, we need a separate flow value, but just to validate if OOTB Manage User Access has any such validation, for testing purposes we added AccessRequest as flow, but still, it’s unable to validate for existing access requests.
Can you dump an example of your plan (toXml) you are sending to the LCM Provisioning workflow?
Hello @christian_cairney were you able to find any issues in the logs?
It looks like that log shows a request failing to provision.
When you submit your access request via the Plugin, do you:
- Have an open pending task result for this request?
- Does that task result object have an IdentityRequestId in the XML
- If it has the IdentityRequestID - can you provide the XML of the (IdentityRequest) object? Is the ‘type’ of this identity request ‘AccessRequest’ or ‘RoleRequest’?
- If the TaskResult does not have an IdentityRequestId - does it reference a WorkflowCaseID?
- Does the workflowcase exist? And does it have a plan?
I think bottom line here is you need a TaskResult associated with your plugin access request in order for the UI to pick up on whether there is a pending request already. Perhaps we start there - do you see a TaskResult for your plugin initiated access request?