After adding an entitlement to an account the request is never completed but is stuck in the "Pending Verification" state.
I can see in the entitlement collector log that the new entitlement relationship has been processed.
When viewing the account I can also see the new entitlement.
But why does not Via L&G understand that the request is completed? What am I missing here?
From the screenshot of the change request, it looks like the system attempted to add the entitlement to a User (and not to account).
This is why the change request is pending verification. The system awaits for the entitlement be appear under the user and not under the account of a user.
Try the following:
In the configuration of your application, make sure you enable the "Entitlements Require Account" (Requests tab in the application configuration)
You will need to associate the application with an account template
Hi Boris,
The client has unusual requirement.
There is NO explicit 'Create Account' provisioning capability in the application (REST web service AFX connector) i.e. when Add Application Role capability is invoked, the application would implicitly check whether user's account exists in the application or not. If the account does not exist, it will create the account in the application and then add the application role to that account in the application. If the account already exists, in that case it straight away add the application role to that account i.e. without creating the account!
In such a scenario, how should the 'Create Account' action be handled since the target application does NOT explicitly have this capability? The application interface is via REST web services (connector)!
Suggestions are appreciated.
Thanks!
Sandeep
In your scenario, is the account name being calculated in the application as well or the name of the new account is known before (for example: the account name in the application will be identical to the sAMAccountName) ?
Yes, the account name will be exactly the same as user's userid.
Haven't tried the following approach, but it might do the job
In the Create Account capability in the connector configuration, configure a "dummy" path which will return a success message but will not perform any real action.
Thanks Boris for the valuable workaround. I had suggested the same to the client BUT at present they do not have any such web service method/ call available in Production environment for the app. If there is NO other feasible workaround, then I shall raise a case with RSA Support to justify the product behavior.
Other possibility I am trying to explore is - in the fulfillment workflow, check if the action/ operation is CreateAccount and bypass the out of the box provisioning Java node! However, my concern is, this might interfere/ impact expected product behavior i.e. create temporary account (until collection verifies it) or fail subsequent dependent add app role actions etc. Moreover, the custom approach might not be officially supported by RSA.
Yep. modifying the fulfillment workflow might do the job.
Give it a try. However I don't think that bypassing the java node is the correct approach.
The system needs to "think" that the change item was provisioned, otherwise it will be in a Pending Action state.
Similar thread - Dummy Fulfillment to skip "Pending action"
You are correct. Thank you for a very quick response and solution!
From the screenshot of the change request, it looks like the system attempted to add the entitlement to a User (and not to account).
This is why the change request is pending verification. The system awaits for the entitlement be appear under the user and not under the account of a user.
Try the following:
In the configuration of your application, make sure you enable the "Entitlements Require Account" (Requests tab in the application configuration)
You will need to associate the application with an account template