I have a DelimitedFiles source and I created some entitlements through the entitlement aggregation (ent1, ent2). I also aggregated some accounts with entitlements that are not presents in the entitlement aggregation (ent8, ent9). Theses entitlements are created in IdentityNow.
First question, is it possible to disable this behavior and not create entitlements from account aggregation ?
Second part, I tried to remove the entitlements created through the account aggregation (ent8, ent9) by running a new entitlement aggregation (with only ent1, ent2). The problem is that ent8 and ent9 are not removed and persist in IDN. But if I remove ent2 from the entitlement file the entitlement aggregation correctly removes ent2 from IDN.
In the end, by running an entitlement aggregation with only ent1 in the file I still have in IDN ent1, ent8 and ent9. ent8 and ent9 was created through account aggregation and cannot be removed.
We have promote managed attributes in Account Aggregation task, if you don’t enable that checkbox then Entitlements will not be created. But we don’t have such kind of controls in IDN. Also for delimited file it is not aggregation actually, it is importing the data.
If you don’t pass any values for the entitlement attributes, then it won’t create any entitlements from Account Aggregation.
If you don’t pass any values for entitlement attributes in user feed in the 2nd run, it won’t remove entitlements as those are sticky I believe.
Ya since those are not created through Entitlement Aggregation.
Can I know why you need to restrict entitlements, there is no harm in having them even of no use.
Hi Mathieu,
Like Krishna mentioned - there’s no realy harm in having this entitlements which are most probably there because they got detected on one of the user accounts.
What you can do if they are requestable is - you can select this entitlements in the entitlement tab
this will hide this entitlements in the request center so actually noone apart from admins will see them
Also I’ve just tested that it seems there’s undocumented call (or at least not present in the Postman collection) with DELETE method in the entitlements endpoint and you can actualy remove any entitlement via REST API call
To explain a little more, we have a lot of disconnected applications, so we compiled all of these applications into a single delimited file source. We have a CSV file containing all the entitlements for each application and a CSV file containing all the accounts. The problem we are facing is that since there is no optimistic provisioning like IIQ in IDN, when we make an access request the account is not created in IDN, we have to do an accounts imort again. Since there are multiple applications in this source, we can’t extract the accounts from a single app to import it into IDN, so we do an accounts extract from IDN delimitedFiles source, add a row for the new account and aggregate it back. If we make a mistake in the spelling of an entitlement when adding the new row, a new entitlement is created. Maybe we are doing things wrong? Do you have any idea how we can handle this?
Account aggregations will bring in any entitlement that is assigned to at least one user on the source by design. This is for visibility into who has access, and what they have access to, so that it can be remediated via certification campaigns if necessary. You cannot disable this. If an account has an entitlement, the entitlement will be added to IDN each time the account aggregation runs.
The recommendations from @MVKR7T are your best options for handling this scenario.
Hello,
This method is no longer available… Any other suggestions to delete an entitlement? It has been created because of a wrong configuration, but it is now no longer assigned to anyone.
You can utilize the
POST https://{tenant}.api.identitynow.com/cc/api/source/reset/{cloudExternalId}
This will reset your source and remove everything such as accounts, entitlements and access profile but your source configuration will remain same.
After which you can re run the account aggregation and entitlement aggregation again to get things right.
