For the /cc/api/source/loadEntitlements endpoint this replaced, we were able to ‘disableOptimization.’ I see that the import-accounts endpoint has that parameter. May I ask that SailPoint add that parameter to this endpoint?
I agree on this one! I think it is more logical that the entitlement endpoint gets changed to become something like ‘/beta/sources/:id/load-entitlements. After all you are asking the source to fetch the entitlements. So the source is the dominant object type here.
I don’t mind if there are aliases and that the current endpoint also keeps working, as long as it is properly documented, but consistency is key!
Kind regards,
Angelo
1 Like
I agree that the naming could be better. There has been such a high velocity of changes to the beta APIs that we’re bound to make some mistakes like this. Renaming the endpoints is something we can look at when promoting to v3, but for now it will remain as it is in beta.
@vsandhu1 I have passed your feedback about disableOptimization to engineering.
1 Like
Just curious is the “privileged” flag supported through the CSV upload process or does that need patched after the fact through the API?
Thanks!
That will need to be patched after the fact. Privileged is not changed during aggregation.
Colin,
Is there any update on the commas? I just tried the new load-accounts and it works with having comma’s in the delimited data wrapped in double quotes.
The entitlements version is still failing.
Hello @colin_mckibben,
The renamed /api/entitlements/aggregate/ endpoint does not appear to include an unoptimized flag “disableOptimization” like the old CC loadEntitlements did, and the new BETA/sources/:id/load-accounts does. Is this disableOptimization function planned to be added to the beta endpoint, or is a different endpoint going to be added for this option?
There are still too many situations where this is required and where resetting all entitlements for the source is also not a useful option.
Looking back, it appears that @vsandhu1 also noted this but I don’t think there was a response.
Thanks Colin!
1 Like
Hi Brian. Can you please elaborate on your use case for disableOptimization for entitlements?
It looks like engineering agrees with you and they have created a ticket to work on this. I took the liberty of opening a feedback topic for you so we can track the work there.
Most recently, we have had many instances where a standard optimized aggregation will not pick up changes to entitlements, such as their descriptions. In these situations, we have verified that their manually changed description flag is set to false, but running either account or entitlement aggregation fails to update the data.
Even if the entitlement is assigned to an account, running unoptimized account aggregation also does not read the changes to the entitlement. In order to read in the new descriptions, we have to run the CC loadEntitlements API with disableOptimization true. The new beta API fails to update the fields, and does not have the optimization option.
The new beta Entitlements Reset can also work in the case of a new source or one that does not have certs, roles or entitlement requests active. However, that’s more like a nuclear option.
I also saw there was a Remove Entitlements endpoint referenced in a KB article last year but it appears to have been removed. I don’t think that one would work well at scale anyway - having to pick and choose individual entitlements if many have been updated, for example.
Thanks for taking a look!
2 Likes
Thanks Brain for the clear explanation; we have the same issue so the option is an absolute must for us too.
Thanks for the clarification Brian. Is it just the descriptions that aren’t being updated when running the aggregation? If so, then it may actually be a bug/enhancement request to make sure that entitlement aggregations include description changes. If there are other fields that aren’t getting updated, then maybe it really should have an unoptimized flag.
Description is the most common and visible piece that does not consistently update on optimized aggregations for AD. This was true for the old CC endpoint as well. I have not tried this new API on other data inconsistencies just yet, so I don’t really have an answer for you there.
On AD sources there was a separate side-effect in the situation of the source being created pre-June’23, the un-optimized entitlement pull would also replace any
"manuallyUpdatedFields": null
with
"manuallyUpdatedFields":{
"DISPLAY_NAME": false
}
This second version is preferred. I think this was dealt with separately, in a recent bug fix.
We’ve also seen some strangeness with flat file processing - when I tried to bring in an entitlement feed it generated new entitlements even though I had included the entitlement ID’s for each of the lines that should have matched an existing entitlement, and did not remove the entitlements that were omitted from the import. That said, the UI entitlement import did roughly the same thing. I ended up having to entitlement/reset that source and try again the next day.
I guess if we’re looking for a use-case, the long and short of it is that sometimes it is useful to be able to force the system to re-read the full data set and repopulate it, in case something got stuck or otherwise isn’t able to refresh properly. I understand it’s a lot of cycles just based on the amount of time it takes to process even as few as 9000 records. Fully resetting a production source, I would say usually isn’t an option.
Another part of this use-case is that June’23 example, where the code behind the AD sources was changed but didn’t properly apply to AD sources on our tenant until a forced-unoptimized aggregation cycle caught it almost 8 months later.
Hope this helps!
Sorry in advance if I’m repeating a question asked earlier, but if this was already covered I missed it. the CC endpoint had support for multiple Entitlement types using the Query Parameter “ObjectType” to specify the name of the Entitlement Type being uploaded. I’ve tried that and few other things I thought might work haven’t had any luck. Anyone know how to do this, or is not yet supported? Hoping I’m just missing something obvious. 