I have a use case that I am struggling with. I have two account attributes - Consider EntitlementA and EntitlementB - the combination of which together will assign the user a unique privilege in the target system.
So, here are the scenarios with issues,
(1) User has EntA1+EntB1 already Provisioned, both the entitlements are now not available for provisioning with other combinations - say EntA1+EntB2 or EntA2+EntB1. In Short, I need the already provisioned entitlements of an account to be available for requisition with other remaining combinations.
(2) Even if we bypass this restriction somehow, and the user now has EntA1+EntB1 already provisioned but requests for EntA1+EntB2 - SailPoint removes EntA1 from the plan as it is already available in the identity cube and hence it fails to provision in the target system requires both values of Entitlement A and EntitlementB to be available in the web service API call for provisioning.
Have you looked into rolling these entitlement combinations into access profiles? For example:
AP1 = EntA1 + EntB1
AP2 = EntA1 + EntB2
AP3 = EntA2 + EntB1
AP4 = EntA2 + EntB2
When a user is assigned AP1, IDN provisions their account with EntA1 and EntB1. If you want them to have a different entitlement combination, revoke their AP1 and grant them a different AP. IDN will automatically handle the entitlement changes.
Thanks for the response. We do have the entitlements in Access profiles. But the problem still persists.
Use case 1:
Let’s assume an identity has AP1 already provisioned, and now requests for AP2. SailPoint removes EntA1 from the plan and only has EntB2 as an attribute request since the identity’s account already has EntA1 but I need both entitlements’ information in order to make the web service update call.
Use Case 2:
Identity has AP1 and AP4. But on aggregation, SailPoint will assume that the identity also has AP2, which isn’t the case as the requirement is rigid on the combination. If the combination isn’t explicitly provisioned - I don’t want it to be assigned(by detection) to the identity.
Use Case 3:
I still need the AP2 as requestable but it won’t be if SailPoint assumes it is already assigned.
Basically, the access profile assignment criteria is not just the existence of the entitlements encapsulated in it but the actual provisioning of the entitlements in that exact combination. The real-life use case would be as below,
Access Profile
Location(EntA)
Role(EntB)
Profile1
NYC
Teller
Profile2
NYC
Clerk
Profile3
Boston
Teller
Profile4
Boston
Clerk
If a user has Profile1 and Profile4,
I don’t want Profile2 to be assigned by default.
I need Profile2 as requestable.
Typically in such cases in IdentityIQ, we would go for a custom account attribute instead of two entitlements. But can it be done in IDN ?
I would think that location is considered an attribute as opposed to an entitlement. Do you have identities that can be a teller or clerk in multiple locations? I can see the issue you are having, and I don’t think making location an entitlement is the solution.
You might try having a separate access profile for each location and role combination.