I have 2 entitlement types as group and roles in my webservice connector. They are 2 different endpoints for these entitlement aggregations. I see all the values for these entitlement types are pulled correctly after running Entitlement Aggregation.
Create Account needs both group and roles to be sent in the http request body along with other identityattributes like first and last name. I have “Create Account With “Ent” Request” also enabled for my source.
Even though I raise a new user request(from Request Center) by selecting- one single group and one single roles, I see that it is being sent as 2 separate requests instead and throws error that the roleId is missing.
Message: 400 : Bad Request : {“Error”:“Bad Request”,“Message”:[“RoleId required.”,“RoleId must match a valid role.”]}, HTTP Error Code: 400
My requirement is that we need to be able to pass both group and roles as a single request. Could you please share how we can handle this? Can Webservice before operation rule be used for Create Account?
Even in the request center, when you select the group and role, on the “review request” page you will see them as two seperate cards. The default behaviour of sending it as two requests is useful. Ex: While triggering a workflow, the workflow is able to act on each request-card.
I doubt if this behavior can be altered. May be you can do something via the before-provisioning rule
This is intresting, May i suggest that you create a business role in sailpoint ISC & add both the access items in that role.
In that case, it would be one access request created but with 2 different access. Kind of like in one plan both will be available.
Okay its getting little more intresting…
So tell me one thing when you are requesting the group and role
Is there any mapping on the end system? That if Group A comes then it should have Role D only.
Lets say if there’s no mapping like that what you can try is to manipulate the plan Using Before Operation rule. By manipulation i mean update the Http call Body.
So what you can do is as the request comes and you will be aware that its sending group only at that time you can make a check in Before Operation rule. If type== group then add a default role.
In this way it does not errors out and when the second request comes for role, It would be able to assign as you already have a Group in the downstream app.
Or better what you can do is check on account first if there exists a Group already and current request is coming for Role, Then you add the Role from current plan and get the old Group from account & Vice versa.
Whereas if this is a first time operation in that case account is not thete then you send a dummy data as (Dummy Role) + Plan Group; this creates account and the next request of Role that you raised will be considered as a entitlement requestand added to the identity. Vice Versa if Role is requested first in that case (Dummy Group) +Plan Role
Documentation here clrearly says that, the connector must send multiple requests for different entitlement types:
So, how about this?
identity a basic access profile that can be used to create account on the source. This basic_AP will have the required default combination of baisc_group and basic_role.
Ones the account is created, have a child operation to add the required access to this user.
May be also consider another child operation to delete the basic_AP
Its all theory and need to test this. But I still think because of the above documentation the basic_AP will be divided into two calls
so I will go back to playing with before procisioning rule before connecting with SP
We defined roleId and groupId combination in a role. Created multiple roles for different frequently used combinations. Checked this setting-Create Account With “Ent” Request. Now I am able to get those 2 attributes in single request while creating the account.
