Hello all, my question is similar to Grouping multiple entitlement requests into a single request, which never received an answer.
I have a web services connected source that has two entitlement types, Role and Division. They are aggregated via different endpoints, however, one of each must be provided at the same time during entitlement provisioning on a user. I have created an ISC role consisting of source entitlements Role ‘123’ and Division ‘abc’. The API to provision permission to a user looks like this:
POST www.application.com/api/subject/{subjectID}/division/{divisionID}/roles/{roleID}
subjectID would be the nativeIdentity of the account, and divisionID and role ID are the IDs of the division and role.
I’m open to suggestions if anyone has ideas on how to accomplish this. Thank you.
The base issue that was faced in your linked article is going to apply to your scenario as well. Since ISC sees that you are adding multiple entitlements, it is going to generate two events to provision the access. However, there might be a away to make this work.
With a webservices connector, you can use a before provisioning rule. You could use the api to lookup the user and determine ISC role that granted the entitlement. From there you could find the other entitlement. Then you can just connect directly to your application from the code.
POST [www.application.com/api/subject/{subjectID}/division/{divisionID}/roles/{roleID}](http://www.application.com/api/subject/%7BsubjectID%7D/division/%7BdivisionID%7D/roles/%7BroleID%7D)
The one concern that I see is that you might have two attempts to add this transaction in flight at the same time so you will need to make sure that your logic can accommodate that the entitlements may have already been provisioned. You could handle this be checking to see if the entitlement has already been added or you could handle this based on the response code depending on the application API functionality.
You can achieve this using a “Before Operation” rule. In this approach, you capture the attribute requests from the provisioning plan and process them to create the custom payload required for your use case.
However, this method may lead to an error stating that “access has already been assigned.” This occurs because multiple access items trigger multiple backend requests simultaneously.
To avoid this issue, you can use the configuration parameter addRemoveEntInSingleReq, which processes the requests as a single operation.
Give this method a try, and let me know if it works for you!
I had a similar (not exactly identical though) requirement in the past and was managed via this approach:
Have only one type of Entitlement in ISC called “Division-Role”, which will have values like Purchase-Buyer, Purchase-Manager, Accounts-Payroll etc. (How you like to create these combinations will depend on your business requirement)
You will be granting an entitlement from ISC that is a combination of a role and division
In Before Operation rule, you split the entitlement into 2 parts based on the separator "-" (separator can be some other character or a string as well. whatever works best for you)
Now you can use these 2 strings in the API URL
Biggest challenge might be creating entitlements as combination of Div-Role, but you can simply make every possible combination from all the divisions and roles. Many of these might not be even used ever
Hi Alicia, thank you for your response. I believe your suggestion would require making an api call to ISC, which would mean hard coding auth creds/token into the rule, which I want to avoid.
Hi Gopi, thank you for your response. The issue I’m facing is that the entitlements I wish to add are two different types, and so they are not included in the same provisioning plan, even with addRemoveEntInSingleReq set to True. If I consolidate the entitlements type to just one, having two http operations to call the different source endpoints for Roles and Divisions, then ISC would not be able to distinguish between the two items, meaning it wouldn’t be able to properly form the request URL to Add Entitlement for a user.
Hi Nithesh, your suggestion is something that I have been considering, so it’s good to see someone else recommend this as an option. The question I have about this is how will ISC react when it goes to aggregate user accounts, it looks for entitlements, and it sees the original source values and they don’t match to any of the concatenated values created by the rule? Will there be a looping scenario where ISC tries to continually provision access because the role is added to the identity, but it can’t see that the entitlement is added to the user?
You can get the user information and credentials from the connector configuration and pass them in as variables. You don’t need to hard code the either into the rule.
I worked on a similar scenario where the endpoint was the same, but the entitlement contained multiple values in the format roles-Products. To handle this, I aggregated the values as roles:products.
In this scenario, however, each entitlement has a separate endpoint. Is it possible to implement a similar approach here?
I’m working on something very similar in IdentityIQ. From the terminology in description of the problem and responses I gather the ISC version of the webservice connector seems very similar, if not the same.
I basically used an approach similar to what Nithesh is suggesting, and create entitlements for each unique combination of divisionID & roleID.
In the user schema added a “Managed, Entitlement, Multi-Valued” attribute for it of type group.
Used an “After Operation” rule on the user aggregation to check for each encountered combination if the entitlement exists, and create it if needed.
This replaces the group aggregation. However the group schema definition is still needed, and in your rule when creating the entitlement you manage those attributes.
Then made a “Before Operation” rule on the add/remove entitlement operation where we get the entitlement from the provisioning plan, retrieve divisionID & roleID from it and put it in the endpoint URL.
Set the context url of the operation to “api/subject/$plan.nativeIdentity$”
And do something like this in the rule:
@agutschow It’s true you can get the credentials for the application, but your initial response sounded to me like you were suggesting making an api call to ISC. So I was asking how could you get an ISC auth token inside a rule if you’re not hard-coding it? Maybe I misunderstood your response.
@Gopi2000@robbe_deneef I have implemented exactly what you both are describing. It’s a good suggestion and it works. But there’s one caveat; the entitlement value ISC is provisioning will never match any value that’s returned during a user aggregation. So, ISC thinks the division:role combo entitlement wasn’t added, and then triggers an add entitlement operation, for every user. Have you guys encountered this scenario? Was there something you did to correct it?
@nick_lubrano
In the user schema I added an attribute, for the terminology in your case something like “divisionRoles”. Type: group. Attributes: managed, entitlement, multi-valued.
In the user aggregation I chain the user retrieval into retrieving the divisionRoles (using parent endpoint configuration) for each user, filling up that user attribute.
In my case could do that from response mapping, might require another before operations rule in other situations.
I found that as long as the values match with what is used as ‘identity attribute’ for the Group schema this made it all work together.
Ah ok yes that makes sense. Unfortunately, the application I’m working with (called Genesys, for those interested) does not include detailed entitlement information in the request response, so I’m having to look for an alternative, but it’s seeming more likely that this is just an application limitation.