Hi all,
I notice several issues when creating SOD policies through the API.
1: When creating an SOD policy using the API (POST v3/sod-policies), we specifically need to name the left bucket and right bucket. I think some default values would be preferable here. That if we do not specify the names specifically, something like “List A” and “List B”. I consider this a very small thing. We can build our own defaults when creating such policies.
2: We specifically need to give at least one entitlement on each criteria list. This makes it more difficult to work with SOD policies, both automated from the API and manually through the UI. We want to have processes to be able to add and remove entitlements from a given list (A or B). We don’t care about whether we first remove an entitlement and then add another entitlement or first add an entitlement and then remove another entitlement, but since an empty list is apparently considered a corrupt state, it will sometimes fail in the former case. It also prevents us from first creating the SOD policies with empty lists, but with policy and violation owner determined, to then ask others to fill the policies with the entitlements. So technically we can’t have separation of duties for creating SOD-policies 
Also, considering an empty list corrupt is not necessary, even when the state is ENFORCED. The idea behind these SOD-policies is
“Anyone who has at least one entitlement from list A and at least one entitlement from list B is violating the policy”. So if list A contains entitlements and list B is not, no-one will violate the policy by default, at that point in time, but that should not be the reason to disallow that as a state. I am already thinking of workarounds such as adding dummy entitlements that no one has to the lists by default, to ensure we are never reaching a state of having no entitlements at all. Surely this is not how we should use this functionality. I would argue that placing the constraint that the lists should have at least one entitlement is creating more problems for the customers then that it is solving. I don’t consider this a bug, but a design flaw.
3: When using the API to create an SOD-policy, we have to give the list of entitlements as reference. For most APIs from SailPoint we can refer to entitlements and other objects using this json object
{
"type": "ENTITLEMENT",
"id": "e44193753be14e9c76453eba9dc12345",
"name": "Administrator"
}
The API documentation also mentioned this is how we should refer to the entitlement. This is also quite easy, because if you run a GET v3/sod-policies/:id request, you will see the entitlements in the same way as well, so you can easily copy the json, and use that json as input on creating a second SOD-policy, that will be similar. However, for some reason, the API to create this SOD-policy is complaining if the JSON for entitlement references contain the “name” key and it mentions it should be null. What I would expect is that this value may be omitted (since it is not needed to find the object, as the id value is sufficient, but it should allow the value to be given (and only give an error if the value does not match the name of the entitlement with that given id. I consider this a bug as the desired convention and the API documentation are aligned, but are not matching with the actual behavior of the API.
4: I wanted to disable an SOD-policy we have and use the PATCH API with this body:
[
{
"op": "replace",
"path": "/enabled",
"value": false
}
]
For some reason however the path is not /enabled as we see with other ISC objects such as roles, access profiles and workflows, but state:ENFORCED and state:NOT_ENFORCED, which is inconsistent and unnecessary.
5: If you want to disable an SOD-policy we now have to use this API body for PATCH
[
{
"op": "replace",
"path": "/state",
"value": "NOT_ENFORCED"
}
]
However. If your SOD policy has entitlements in either list that are not existing anymore (maybe because the source was deleted or because an entitlement aggregation discovers that the entitlement does not exists on the application anymore), we get an error (let me call an SOD-policy object “corrupt” if it contains deleted entitlements). You can’t patch an attribute of the object with a perfectly fine value if an unrelated part of the object is considered corrupt. It is not even possible to disable it when it is corrupt. But if an entitlement was deleted, why is it turning the SOD-policy in
a corrupt state to begin with? Shouldn’t there be a process for it to keep it in a non-corrupt state, for example by removing it automatically (allowing empty lists) and mailing the SOD-policy owner on the change? After all, the entitlement with that particular ISC-created ID) is gone and will never be recreated with the same ID right?
Hope this feedback helps.
Kind regards,
Angelo