I looked at the documentation and don’t found a answer for this…
I got the following scenario:
User do not exists in API, I did a entitlement request, Sailpoint got success to create the account into API
I went to this user Identity, gone to Accounts and clicked to Remove this account, the disappeared from user Identity and Source Accounts Listing…
I made a new entitlement request… but now Sailpoint try create the account into the API and receives the “User Already Exists” message…
How can I configure Sailpoint to first check if Account exists and them run Create Account… I have the Get Object HTTP Operation and it is before Create Account…
Hello @leonardo_lsilva , just wondering what’s your use case that you are trying to mimic by removing the account from Identity (from UI) and then requesting entitlement from SailPoint?
As practically, no one would be doing this in real scenario in Prod. I hope that is part of your particular test that you want to run and confirm?
Strange to see “skipGetObjectInCreate” flag not working for you, can you please share the source configuration where you set this (mask other details that’s irrevelant)?
Removing an account from the profile does not delete it from the target. It will only remove it from Sailpoint. If you do the aggregation again it will come back.
What I’m trying to deal is, when a Identity lose access to that API… so for some reason Identity “X” couldn’t have access to “API Y” so what is the flow? Isn’t remove that entitlement from API? Then… I need disable this user in API database…
Can you tell me what is the correct way to do this?
If a identity is added at IdentityNow and the access was granted for the Target API, we expects that IdentityNow check if Target API has an user created in their DB if not just create…
If the user loses access to Target API we expects that IdentityNow trigger the endpoint that disable this user account (this Target API do not delete users, it just set the registry to inactive)
In a future if this Identity gets access to Target API, IdentityNow was supposed to use the same registry that was disabled earlier instead create a new registry in Target API
Steps that I already done…
Import Data → Account Aggregation
Request Center → Entitlements → Choose one Entitlement from Target API → Requesting For an Identity that do not exists in Target API
Request Center → Entitlements → Choose one Entitlement from Target API → Requesting For an Identity that I just did the remove account
When I did those steps I expected that when the ran “Remove Account” IdentityNow trigger the Delete Account HTTP Operation (in my API it do not delete just update STATUS) in the second entitlement request I expected that IdentityNow trigger Update Account HTTP Operation updating STATUS to active…
For my Target API Delete Account and Disable Account will be processed by the same endpoint both just update STATUS to inactive
“Remove account” in the IdentityNow interface just removes the account from the IdentityNow repository. It leaves the account intact in the endpoint. So when you removed it in IdentityNow but didn’t remove it in the back-end system, IdentityNow saw it as gone and tried to create a new account, but the back-end system saw that as an attempt to create a duplicate. The use-case you’re trying to solve for is already handled with account aggregation and correlation.
There is no native way to delete an account on an endpoint from within IdentityNow. If you want to configure the “Disable Account” action to run a “Delete” operation, you could do that. Or you would need a before provisioning rule to change the request action. Or you could probably do something with a WebService Before Operation rule that evaluates attributes passed to an account update or add/remove entitlement call to call a delete action in one of those scenarios.
For my API “Delete Account” == “Disable Account” its the same endpoint because the business rules do not allow delete a registry… so this username would be only disabled… my main question is how to disable this username in the API when I remove access permission from that Identity on IdentityNow…
If I just configure “Disable Account” in the WebService Connector Source?
But this will lead me to create problem… for aggregation my list endpoint just shows actives accounts, in this case I will need change this? and keep active and inactives accounts in Sailpoint ??
Hola Leonardo, a qué te referís conque el usuario pierde acceso al API? Pregunto en español porque tal vez el inglés esté provocando una interpretación incorrecta
Greetings, Leonardo, would you clarify your assertion concerning the user’s deprivation to API access? I pose this query in Spanish in hopes that English may not promulgate any false interpretation.
Lo que quiero decir con perder acceso es que hoy un usuario (una identidad) puede tener acceso a la API de Target, pero por alguna razón este usuario cambia de rol y después de este cambio de rol ya no puede acceder a la API de Target. para actualizar esto en la base de datos de Target API…
Hoy estamos usando SailPoint para administrar el acceso a esta API de Target, solo para agregar nuevos usuarios y vincular derechos, ya que la API tiene su propia base de datos y el control de acceso mira esta base de datos.
If i understand correctly, you don’t need a delete operation, since you just want to disable the account.
Configure a Disable Account operation in the source. Then, the most common is configure a disable action using a cloudLifecycle in the identity Profile. Just losing all entitlements on the source will not trigger a disable for the account.
Another option for that: you could check if the user have any entitlements and call a disable endpoint, inside a AfterOperationRule on your Remove Entitlement operation.
A way to get this work was change my “Create Endpoint” as my system never deletes a registry I just added a new verification to check the tuple (cpf,login) if got the exact result so I just return that registry to IDN and it continues thinking that was created… When I need remove this API account from one identity I use disable and later remove from IDN… and the last update is to filter only active registries into my API database, so IDN inactives disappears from IDN
