We have created over 200 access profiles over the API.
After a couple of days we have deleted them (using the UI)
After about 20 minutes, we have re-created them (some were changed)
During a certification campaign, we noticed that the data is corrupted (with no information from ISC about this):
identities that should have been present in the campaign were not there (noticed by a reviewer)
on the access tab for the identity the AP was not visible although the corresponding entitlement was there. Re-processing the identity didn’t help.
Issue:
The endpoint /access-profiles returns for AP X the ID 12345 (OK), the /search endpoint returns for the same name (only) the ID 66666 (NOT OK).
The endpoint /access-profiles/66666 returns a 404 error. The UI shows an error as well when clicking on the AP.
Multiple APs are affected…
What is the correct behavior?
Data should not get corrupted
Corruption should be detected by the system.
ISC admins should be informed about this, and informed on how to resolve the issue(s) if an automatic solution is not possible
What product feature is this related to?
ISC
What are the steps to reproduce the issue?
Use ISC? See above, although without SailPoint’s support it may be harder to reproduce. I am sure the engineers will investigate the logs and be able to reproduce the issue to be able to fix it.
Do you have any other information about your environment that may help?
@adamian We are encountering similar issues with the search feature, specifically related to entitlements. When searching for entitlements through the UI or API, the results are returned. However, clicking on an entitlement from the search results triggers an error message: “An error occurred. If you are unable to continue your work, please contact SailPoint support. The server did not find a current representation for the target resource.” Additionally, when searching for the entitlement directly through the source UI, it is missing. Interestingly, manually searching for the entitlement outside of IDnow returns the correct result. Currently have a P2 submitted with SailPoint support to figure out what is going on but haven’t had much tracktion on this.
@adamian thank you for reporting this. For this particular bug, please open a support case. There may be several systems involved that go beyond my expertise to identify the root cause.
We have an internal issue going on (engineering team working on the fix) that when few access profiles are recreated then they are not getting properly synched to different databases and that is why they are not available in the request center.
In these cases, we have to run a sync for these access profiles to sync it to different databases
I have checked with engineering team and found that this is known issue which is already being tracked here [IDNLANAI-10934].
The engineering team is working on a fix to avoid happening this in future.
I’m running into something similar where I can’t update connector rules via API. I can get a connector rule by ID, but the call to update the connector rule returns a 404 not found: “The server did not find a current representation for the target resource.”
Hi @MattUribe, your issue is definitely different. Open an additional post if you haven’t already. (And make sure that you use the expected Content-Type: application/json-patch+json)