No public API replacement is planned for this endpoint before the March 31st, 2024 deadline.
To initiate a role refresh, you can select “Apply Changes” in the roles user interface to refresh roles for all identities. Alternatively, you can use the following APIs to process one or more identities, which will result in roles being recalculated for the identities being processed.
For more information on applying role changes, please see this document.
so you mean the deadline will be moved? because we need that endpoint to refresh the roles.
BTW, IDN still uses that API call.
IDN will not be affected since it will have access to internal APIs that will allow the “Apply Changes” button to continue working. Due to resource constraints, we will not be able to provide a public endpoint for this functionality in time for the deadline.
Can you help me understand your use case for programmatically refreshing roles instead of manually applying the changes when a role is updated? There might be a path forward based on your particular use case.
we create and update roles every day, we are a team of 4 doing it, so we cannot be triggering the update each time we modify a role as it triggers all the identities to be evaluated.
So we have a scheduled task that triggers the role refresh every night … you know like the feature that IDN used to had and decided to remove.
Thank you for clarifying your scenario. However, this is a private API that had no SLA, and due to resource constraints we will not be able to prioritize a replacement for this endpoint over other higher priority APIs. For the time being, the recommended approach is to manually press the “Apply Changes” button in the roles UI when all of your daily role changes are done.
or, since there are not enough resources on your side, you can push the deadline until you can provide a proper and complete replacement of all the API endpoints that are used by your clients
IDN admins do need a way to trigger (or schedule) one big role refresh, rather than firing off a bunch of them when role changes are made. After all, SailPoint pays for the CPU time to do all those refreshes, costs that will be passed on to customers, when we could just be paying for one.
For the record, I’ve worked with customers who have tens of thousands of roles, with new roles being created for every combination of (retail branch + job code), or one role per university course per semester, or similar. It’s particularly common with SAP and mainframe banking software. Gustavo’s use case isn’t that unusual.
If we create a role, enable it and make it requestable, we can’t request it yet through the UI, because in the request center, the UI only shows roles that are visible in search as well. It only becomes visible in search after we perform the apply changes task on all roles. So we don’t only use the apply changes button to trigger provisioning, but also to be able to use the request center for that role.
Processing identities doesn’t have an effect on this.
Hello @colin_mckibben any news about the deprecation of /api/role/refresh? Sailpoint is going to create an alternative API to do the same?
Regards,
Bea.
Hi Colin,
we need to have a way to trigger the “Apply changes” every day … we found out, the hard way, that people did not got the access due to a temporary error in the target application and IDN did not retried to give the access, so right now we have to manually trigger the apply changes every day, but this is a problem specially during weekends and holidays.
Refreshing identity by identity is not really a solution as we have 25,000 and there is a limit of 50 or 250 (can’t recall) for each call to refresh identities.
In fact, my ask is for IDN to at least once a day refresh all identities or provide the way for your clients to automate that.
And please, do not suggest to submit an idea as we know that it will take years just to be read and then ignored regardless the number of votes it has.
Thanks,
Gustavo
According to Processing Identity Data - SailPoint Identity Services, it already should do what you expect it to do right? Perhaps something is wrong in your tenant? Have you tried submitting a support ticket for this?
The information we got a while ago from SailPoint (we had a call with the product manager of the “feature”) said that they were removing the identity processing that was happening twice a day and it was indeed removed, so we had a script that was triggering the identity refresh (now the “Apply Changes”) every day.
I do hope that the documentation is accurate and is a problem in the tenant as it would mean that we should have one identity refresh per day at 8pm.
I can say for a fact that we do not as we have found out today a weird behavior in IDN that was either not noticed in the past or was added “recently” …
If you have a provisioning failing IDN does not ever re-tries to do the provisioning only refreshing the identity (or apply roles) corrects the situation.
But even more weird, if IDN does a provisioning and for some reason the user is removed the access in the target system before the target system was aggregated again, IDN never tries to give the access unless an apply role is triggered … I’m trying to setup that in our sandbox tenant to be able to open a support ticket … I think is because the optimized aggregations cause that only the accounts that changed will flag an identity refresh and since the new aggregation returns the same entitlements for the user as the previous one there is no difference even if IDN showed that it had it on the source.
A search for: created:[now-10000d TO now] AND “All Identities” only shows Manual triggered events, so unless there is another way to find those scheduled refreshes I think they do not happen at all in our tenant, does it show you something in yours? or is there another way to see those refreshes?
Actually the article you shared indicates for the scheduled process “but only reexamines user access data (roles and lifecycle state-driven access) for identities whose identity data changes” and in this case the identity data does not change, only account data has changed.
so right now, not even when a provisioning fails IDN tries again since no attribute has changed, it has passed from being very reliable in itself to require a LOT of babysitting.
Thank you for your response @gsanr, I reread that documentation and see you are right in that the scope of the refreshes does not include the cases you mentioned.
@kirby_fitch, believing you are still working on the behavior of the scheduled refreshes. Could you please read the concerns of @gsanr here?
I do understand the need of SailPoint to prevent unnecessary refreshes and computations. This to save energy costs, which will be better financially and environmentally. And I do support this fully.
However, it seems that the amount of refreshes has been reduced so much, that it has a bad impact on the behavior of ISC, that it now requires continuous executing of manual steps.
If customers notice that an expected refresh (triggering things such as provisioning retries, correlation attempt retries, provisioning back access that was removed from directly from the target application) is not occurring, I think that workaround are being looked for to trigger the refresh, such as creating an identity attribute with a transform that outputs the current day, to guarantee that each day all identities have different identity attributes, or trying to schedule unoptimized account aggregation in some way, to ensure that a proper refresh occurs.
Downside of these workarounds is that we are back at square one: “Too many unneeded refreshes occurring.”
Could you please take a look here, to see if if for each different use case there is a suitable solution to ensure we would need to build these workaround for enforcing a refresh on all identities?
I can think of some use cases here, other cases exist as well:
1: Provisioning fails to a newly requested role, where this application was the only part of the role.
2: Provisioning fails to a newly requested role, where this role contained multiple sources, for which provisioning did succeed.
3: An account is uncorrelated, after which an identity is being created, will correlation occur within a respectable time-frame?
4: Access is directly removed in the target application. unoptimized (Single) account aggregation detects this. Will access be re-provisioned?
5: Attribute sync fails. Will it be retried?
6: Any hiccup on SailPoints side (mentioned in status.sailpoint.com) results in an action not being performed, will it be retried?
I wonder what your advice would be here @kirby_fitch.
Kind regards,
Angelo
I had a revelation yesterday … we have been triggering a manual apply roles every day close to the end of the day, and yesterday I checked the number of “account activities” that were doing while the apply roles ran vs the total number of “account activities” of the day.
My expectation was to have a very low number, as the event-processing should be taking care of all with some exceptions, but what I found was that in the last 10 days (we did 5 apply roles) the lowest was 51% and the highest 78%.
I’m still checking to see the details of those activities, maybe there are some repeated ones, but even removing the “Failed” ones does not do a change (they were 5% of the total in the day I checked )
Could you check in your tenant what is the % of account activities that happen when you do an “Apply changes”?
If the numbers I have are real and they are similar in other tenants, I think it would mean that we NEED to have this identity refresh running not once, but at least twice a day
I will do a test running back to back apply changes to see if there are repeated changes, as this is too weird for me.
Gustavo