We are integrating a webservice based application to IDN. There is an established process where we have to provide brithright access to the new user for an application.
This birthright is read-only access. We are trying to achieve it using role membership where we have defined the criteria and added the access profile consists of birthright entitlement. Now for the new user, this is a smooth process where it matches the criteria and user’s new account will be created and birthright will be provided. But how to handle this for the existing user base present at the target system who also matches the criteria but may have elevated access right over their lifecycle rather than birthright.
For eg.- If i put the condition of LCS=active, then it will try to provision the entitlement for all user’s having active LCS.
Sailpoint keeps trying to remove the entitlement when the user has moved on or add it when not desirable.
Is there any way we can achieve it in a clean manner.
We are also looking for another approach of Event Triggers Fire and Forget but unsure which is the best way of achieiving this use case.
Important thing to note here is the entitlement attribute is Single-Valued
My first suggestion is to create another role with membership criteria that is specific to existing users who need the elevated access. Can you share the membership criteria for new users, as well as what criteria an existing user needs for the elevated access?
There is a WS target that we have to provision an account as a part of birthright
The only way to trigger an account creation in IDN is to assign the user an entitlement
We assign the user a role (LCS=prehire) with an entitlement “read-only”, now this entitlement is single valued.
Once the user is in LCS=active, IDN tries to remove the entitlement but that’s not what should happen as per requirement.
Another issue if we try to overcome #4 by adding LCS=active in the criteria, the user can place an access request for an elevated entitlement “business admin” which will overwrite the entitlement. Then this role will re-evaluate that the user does not have “read only” and try to provision that, which is again against the requirement.
We are doing migration from one IGA to IDN and that’s where Yunus concern is coming from about how do we handle existing users.
name of the entitlement is “security profile” and it can hold 1 of the 100+ values. But when we do account creation as a part of birthright access we give security profile = read only.
Ok, so at a minimum, all pre-hire and active identities should have the security profile set to read only so they have access to the source. However, active identities should be allowed to request values for security profile that are greater than read only without the role membership reverting them back to read only. What if you try something like this in your role membership criteria. This should read “grant any identity that is prehire or active AND has not yet been assigned the security profile entitlement the read only value for security profile”. This should allow active employees to request higher security profiles without being overwritten on next aggregation.
This should allow active employees to request higher security profiles without being overwritten on next aggregation.
I am not sure if this will work? When a user gets a higher security profile say “business admin” via access request, they will continue to match the criteria of the role (they are active and don’t have have “read only”), now the role is configured to give “read only” security profile which the user would not have any more (they would have “business admin”). So the role would try to provision “read only” again to the user.
1- New user created which matches the role criteria
2- Got the target account created and Readonly access
3- Changed the access from the target system UI
4- Ran the aggregation and observed the elevated access has been updated in IDN
5- Same Add entitlement items in the activity log, because they continue to meet the role criteria
The issue we have is, if we try to solve for role adding the user to “read only” entitlement then we have an issue on remove, if we solve remove it is an issue on add.
Add some criteria in role which is more of negation, means user should not be part of role when they have account in that WS source. You will keep the current criteria as it is and add one more negation.
What will happen now:
Identity created for user
He still does not have account for WS source so he will be part of birthright role.
Role gets provisioned and he gets read only access.
He has account created on end source which means his read only access would be removed on next role refresh because he would not be part of the role.
Now you can assign any role you want through request centre and it would work as usual.
You can create identity attribute to define if user has account on that WS source and use that identity attribute in role criteria.
Thanks Chirag for the response, one thing jumps out to me is on Step #4 described in your logic. When the user is removed from the role, it would trigger a remove entitlement operation for “read only” access, which is undesirable.
Any ideas on that? We are thinking to write a before operation rule on remove entitlement operation and remove the attribute request to remove the “read only” access.
I have not gone through each and every line of discussion here but you mentioned on first update that entitlement is single valued so I assumed to put any new value you need to remove read only access.
That’s correct, but there may be a time period between when “account is created” via role provisioning and the user requests access other than “read only”, in this scenario the the user will be out of the membership for the role since the user’s account is created and therefore role will try to remove the “read only” access without the user having requested any other access.
Does “read-only” access hold any real business value? I assumed you are using it to just create initial account and that purpose is achieved. If “read-only” entitlement is giving some access then we need to think different solution here.
