HI All,
I am currently working on the provisioning part of one of the JDBC source in Identitynow, while testing the provisioning part one bug I found. When I removes any account from JDBC source and run the aggregation for that source on Identitynow, it creates that account again on source and as well it shows on IDCenter. Can anyone let me know why I am facing this issue and fix for this.
Hi Priyanka,
How are you provisioning the access/account.? If you are doing direct entitlement assignment from Request center or API, you will need to remove the entitlement with remove entitlement API call. If not, they will be added back as the entitlements are sticky in nature.
The identity probably have a role or access profile that is creating the account, or your code is not deleting the account from the source and it re-aggregates.
have you check if it vanishes from the DB?
Hi @jesvin90,
Thanks for the update. So if we assign the entitlenent directly to a user via the API or Request center, then these entitlements has to be removed from ID Center itself? So if for any reasons these entitlements added via ID Center API are removed from the target then ID Center would add them back anyways because of sticky entitlement?
So can we create access profiles for these entitlements and then request the access profile instead? Would this not be sticky in nature? We just wanted to ensure if anyone modifies a users role in the target directly we wanted to maintain the same in ID Center and not revert back the changes. Also we have observerd same behaviour when we delete an account in the target and during Identity Refresh task the account gets created back in the target.
If you are using roles for JDBC and once you disable account and that excess is not removed then role tries to reassing the access again.
So, use Access Profiles then it will not reassign it again.
Thanks,
Siva.K
Thanks for the reply. I will try with Access profile for the JDBC source and test it.
The entitlements assigned from request center can be removed either through the Request center (by manager) or through an access review or through a direct entitlement removal API call (can be triggered via WF) for IDN not to trigger the re-provisioning.
IDN will re-add the entitlement any other way you remove it. This applies to direct account removal from the target as well because IDN will try to re-add the entitlement which would require the account to exist in the first place.
Access profiles are one way to handle this (as they are not sticky) but you will need to create an AP for every entitlement that would need to be requested and whenever a new entitlement is added at the target system. This can become difficult if we are talking about a large number of entitlements in the target system.
Also, keep in mind that it is not a best practice to make modifications directly at the target system in an IGA managed environment.
I have already raised similar post regarding this sticky entitlement issue, but I didn’t get any proper solution and most common suggestions provided are either to use before provisioning rule or creating access profiles.
How to remove entitlements granted via request on IDN - Identity Security Cloud (ISC) / ISC Discussion and Questions - SailPoint Developer Community
I went with access profiles approach for access requesting to avoid this stickiness issue because before provisioning rule doesn’t fit for my integration. Also, by using access profile there will be operational overhead involved as there will be need of creating new profile for any new entitlement aggregated.
I would suggest you to go-head with the access profiles approach for access request if your application’s entitlements are fixed and less chance of new entitlements that would be aggregated.
Thank you.
Shanmukh Gali
Thank you for your response. I will implement this in our tenant.