Hi all, I have an application that supports only Single Valued Entitlement allotment for a user.
Let’s say an identity has a birthright role for the application and it requests for another role for the same application, the identity will be a member of two different roles which can cause incorrect updates on the application, is there a way to automatically revoke the birthright role access/ previous role access when a new role is requested from Request Centre.
Welcome to the developer community Tushar.
How did you configure your birthright role? Is it assigned via standard criteria? What is the criteria you are using? There may be a way to setup the criteria so it automatically deprovisions the birthright role when new access is detected.
For example, if your source gives a base value for the entitlement for all users (ex. “none” or “user”) and your birthright role assigns a different value (ex. “birthright”), then you could configure your criteria this way.
This will allow your birthright criteria to work for new users while maintaining access for users who already have the birthright role. Then, if a user requests a different role, they will be assigned that new role which should change the value of the entitlement to something other than “user” or “birthright”. Because of how we configured the membership criteria, the birthright role shouldn’t try to provision the birthright role since the new entitlement value doesn’t match the criteria.
Hi Colin, I had already thought of the solution that you suggested but wouldn’t it be a problem if the number of possible entitlements on the end system is higher(let’s say 100+), then in such case, how viable is adding 99 different criteria for auto-deprovisioning of a birthright role?
Also Colin, I am using a Standard Criteria for birthright roles.
Does your birthright role only grant one of the 100+ entitlements to users? I’m guessing the other 99+ entitlements are what a user can request via Request Center.
Also, what logic do you use to determine a user should receive the birthright role? Is that based on a lifecycle state?
Yes Colin, since the source supports only one entitlement at a time i.e., no multiple entitlements are allowed, so a user only gets the basic access via birthright role and criteria is based on lifecycle state only. And yes 99 entitlements out of 100 are available in request center.
Is there a default entitlement granted to accounts before the birthright role is assigned?
Yes there is an entitlement granted there as well.
So the example solution I provided should work for your scenario. The criteria states that the identity’s lifecycle state must be “active” AND the group attribute must equal “none” OR “birthright”, where “none” is the default entitlement granted by the source and “birthright” is the group that the birthright role will grant. Let’s consider a few scenarios supported by the information in this doc:
- A new account is created on the source, and the source assigns the account to the default group “none”. The corresponding identity is activated in IDN. IDN detects that the identities lifecycle state is now “active” AND the group attribute for the source is “none”. IDN assigns the identity the birthright role, which grants the identity the “birthright” group on the source.
- An identity refresh occurs. IDN sees that the identity still has the “active” lifecycle" status AND the group attribute is “birthright”. Since the identity is already assigned the birthright role, IDN takes no action.
- The identity requests a new role and is approved for that role, which sets the group to “admin” in the source. Upon the next identity refresh, IDN sees that the identity no longer meets the role criteria. It shouldn’t de-provision the group entitlement since another role has granted the identity that entitlement, but it also won’t try to reset the entitlement value since the identity no longer meets the criteria.