I’ve implemented the webservice connector. The connector is working well for create account, Add entitlement.
I’m facing issue after configuring Disable account and Revoke entitlement. The API is working to set the values in target system. During both the operation, I’m using same API call, since I just need to set one of the attribute active=false. I’ve written a before operation rule to fetch the additional values, which needs to be part of the API like firstname, lastname, email etc. This is working entirely fine, but I’m not seeing the single account aggregation is working for this correctly, since during revoke its removing the entitlements in SailPoint. After I execute the aggregation manually the entitlements are coming back in SailPoint and value active=false setting properly. At the target system the values are set properly.
I’ve used the same single user account aggregation, which works fine for Create account, not for the above operations.
Hello Seemarani, what are the attributes which are getting returned in the single account aggregation? By any chance is the API still sending the value of the entitlement which was to be removed?
@aishwaryagoswami yes it us returning both types of entitlements and also active attribute as well. But I’m wondering, why single account aggregation is not triggering immediately after disable or revoke entitlements
First of all, single account aggregation does not run automatically for any modify operation. It only runs after an account is created (that’s a default behavior).
If you want to run a single account aggregation after each operation, then you have to configure parent child operation. But I do not see a need.
To narrow down your issue, please validate following:
After you remove an entitlement when you see it is removed from SailPoint, please validate it in target as well. Maybe it is not getting removed from target and when you run single account aggregation it brings it back.
If above is checked, if target does not have the entitlement, you removed, and aggregation is bringing it back. Then check the account activity / events and try find out the trigger maybe it’s a role which is getting reassigned as when you run aggregation it processes the identity.
Also please clarify your configuration:
Do you have two different operations configured for Disable and Revoke?
which operation you have a before operation rule?
Please write the use case which is failing bit confused with your problem statement (disable and Revoke).
you mentioned disable is working but revoke is not working as expected?
So i think you are looking for the single account aggregation, meaning as soon as the disable operation happens you want the updated information on account right. So try configuring the response object mapping. This will be basically setting the variables with the updated values (response) returned by the endpoint. And this will work as a part of updating the values that were changed during the HTTP operation of disable. Similar as the single account operation.
Entitlements are coming back, this is common that the requested entitlements will be shown on the identity. This will happen if you have requested the entitlements directly. Because entitlements are sticky in nature, they will get reprovisioned even if you remove them. So i would suggest if you do the testing by creating an access profile and requesting that this should resolve the issue of you getting the entitlements back even after getting disabled.
The disabled use case issue has been resolved, where I need to set active=false during This is achieved using setting the response attribute.
For revoke entitlements (access profile), where I need to set only active=false, instead of removing entitlements. But currently access profile/ entitlements getting removed in SailPoint. ideally as per our requirement it just set active=false attribute in SailPoint. At the target side it is working as expected, since I’ve written before operation rule to set only active attribute, without removing the entitlement attribute values. I’ve attempted to use the response attribute resolution, but to keep the entitlement as is SailPoint is not working
@neeraj99 In addition, in the logs I’ve verified, since we are setting the active=false, the response is getting failed, saying User updation failed for *****, User is not active
So you are saying that user is getting disabled properly. But somehow their entitlements are also getting removed even though there correct?
For revoke entitlements (access profile), where I need to set only active=false, instead of removing entitlements. Here i am understanding that whenever a revoke operation on entitlement is called. Rather than removing you want to update the attribute called active to false.
But currently access profile/ entitlements getting removed in SailPoint. For this one, can you confirm that when you do a get user from Postman or any other tool, you are able to see the entitlements? Check for the same user who has active=false. Also when you say it is getting removed from sailpoint, is it the same behaviour on postman as well or there you are able to see the entitlement on the user?
Ideally as per our requirement it just set active=false attribute in SailPoint. personally I feel that the api endpoint you are using may be removing the entitlements automatically if the active is set to false. Check this out as well. This can also be a possibility…
At the target side it is working as expected, since I’ve written before operation rule to set only active attribute, without removing the entitlement attribute values. Try a single account aggregation before disabling the account. And see if the entitlements are still there. If not then there is something wrong with the Single account aggregation Operation.
In addition, in the logs I’ve verified, since we are setting the active=false, the response is getting failed, saying User updation failed for ***, User is not active This particular message you are getting while disabling the user for the first time? If this message is appearing when the user’s active attribute is already set as false then i would suggest that make an API call in your BO rule and only call the API if active=true. You can verify this same from postman. By setting the active=false for a user who already has the active attribute set as false.
If possible when you update the User such that active is set as false, what is the response you get on postman can you send the sample here and also what is configured in your response mapping of Remove entitlement.
Usecase1: Only disable set active= false. This is purely setting the attribute only. This is completely working fine. We can close this issue.
Usecase2: Revoke entitlements/ access profile using certification campaign is the current issue. The requirement here is without removing the entitlements, just need to set active=false. From the postman I’ve executed the API call, this is working fine.
But, if we do the same from SailPoint, since during the BO rule we are trying to set active=false (the attribute value set is working here as well), but in SailPoint since we select Revoke operation, it is removing the entitlements, but in target side the entitlements still exist, as required as per BO rule. We need to sync target (entitlements exists) and Sailpoint (No entitlements/ access profiles)
If I try to execute the update API call setting the active=false and with the entitlements values in it, giving me the same error message as in SailPoint
User updation failed for *****, User is not active.
Overall, I need to avoid removing the entitlements during the revoke operation. But as per API call, we understand, once we set active=false, we won’t be able to do any updation.
