Webservices Add Entitlement by Requesting keeps on reprovisioning and created Identity refresh activities

Hi all,

I have a webservices connector which is configured with Add Entitlement operation.

I have a requirement where the entitlements should be requestable (I have a freedom to create Access Profile/ Role) but for the sake of testing, we have marked entitlements as requestable and think it can be the way going forward for few other accesses.

So when i try to request different accesses through Request center basically (entitlements) there are a lot of identity refresh entries in account activity which corresponds to Modify account.
Now i am not sure why is it happening but i can see that on those refresh activities i can see my access items being listed there whichever i have been requesting.
So if i had requested A,B,C,D,E,F earlier and now i am requesting G then i can see entries being made as Add access A,B,C,D,E,F,G and it is not just once but if there are 7 access in total then 7 identity refresh activities are there.

My end goal was to add only one access at a time. and i am able to do that by adding an Before Operation rule on Add Entitlement operation.
But the main issue is that on UI it is giving me all the accesses until i aggregate the account again and if i aggregate then again the Modify operation is being made to add the other accesses. So need inputs on how can i remove those identity refresh (Modify) activities and make sure only 1 access is provisioned at a time.

Your inputs are valuable thanks in advance :slight_smile:

@neeraj99 Did you check whether the account on sailpoint has the requested entitlement intact before and after aggregation?

Did you check if the entitlement is provisioned to the target and getting aggregated back to the source?

Because entitlements are sticky in nature as you mentioned you have requested through request center if it finds that if any moment the entitlement is removed in target then it’s going to provision again.

If you remove it from certification or Manager removes that entitlement it wont reassign.

You won’t see this behaviour if you use Access Profiles.

Yeah i verified it after req. the ent is added in the UI page, so i would see 3,4 entitlements there which i had req. previously.
Now once i do the aggregation, one entitlement comes in as the downstream application accepts only one at a time. But as soon as the aggr. completes a lot of identity refreshes are triggered and i can see on target system, access being changed everytime from A->B->C…
#2, So basically our usecase is simply a user can change the profile frequently and it is not a viable optn to use certification for removal of Entitlements.
#3, Yes i tried with Access Profiles it works fine when i have AP like one activity only no un-necessary Identity refreshes etc.

I think i’ll have to go with Access profiles only. But if there’s any way we can stop these ent. being sticky on user would be a lot helpful.

Thanks for the quick response :slight_smile: Appreciate it.

@neeraj99 at this moment seems like Access Profile is the good option.

But if you want to go with entitlement only then you may use of before provisioning rule to remove these entitlement or even explore workflows.

You definitely need to let IDN know that the previously requested entitlements (from request center) are removed from SailPoint. Otherwise as you mentioned as per your requirement you kind of replacing old entitlement to newly requested one using beforeOperation rule, when you aggregate the account SailPoint observes that previously request entitlement is not intact and since you did not remove it from SailPoint it will retry in every identity refresh as entitlements are sticky in nature.

Please read the “Revoking Requested Entitlement” Section

Managing Requests for Entitlements - SailPoint Identity Services

1 Like

Does this relate to the ‘sticky’ entitlements issue that people are having?

See Idea: Flag to allow customers to turn off | SailPoint Ideas Portal

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.