Hi everyone, hope you’re doing great and wishing you all a productive week!
We are currently working on an initiative to automate the maintenance of SoD policies in ISC, leveraging the new v2025 API framework.
I would love to share our approach and challenges here, and seek your input or any best practices you might have.
What We Have Done
We developed a Java-based automation that:
- Authenticates using OAuth2.0 Client Credentials.
- Fetches all entitlements (
GET /v2025/entitlements
) — including parsing custom classifications like Test SoD Classification insideaccessModelMetadata
. - Fetches all existing SoD policies (
GET /v2025/sod-policies
). - Dynamically updates the leftCriteria and rightCriteria based on the SoD classification mappings.
- Retains the original policyQuery and metadata to avoid impacting existing workflows.
- Updates policies using
PUT /v2025/sod-policies/{id}
.
Challenges and Open Questions
1. Entitlements API is Experimental
- We noticed that
GET /v2025/entitlements
is still experimental, requiring theX-SailPoint-Experimental: true
header. - Question: Is there any roadmap or stability assurance for this API? Should we plan periodic validation against future SailPoint releases?
2. Platform Limits: 500 Policies and 50 Entitlements per List
- ISC limits us to 500 SoD policies maximum and 50 entitlements per access list (left or right).
- Our current idea:
- If a list exceeds 50 entitlements, split the policy into multiple sub-policies with suffixes like
Policy Name - Part 1
,Policy Name - Part 2
, etc. - However, this won’t fully solve the issue if both sides exceed 50 entitlements.
- If a list exceeds 50 entitlements, split the policy into multiple sub-policies with suffixes like
- Question: Has anyone implemented a better approach to handle scenarios where both sides exceed 50 entitlements?
Is there any recommended design pattern for scaling SoD rules under these platform constraints?
3. Policy Violation Resets on Update
- When a policy is updated, all existing violations are cleared, and new violations are only generated in the next run.
- To mitigate this, we are planning to:
- Export and archive violation reports before every policy update.
- Apply versioning and change tagging in the policy metadata.
- Open questions we have:
- What is the exact technical reason behind this violation reset behavior in ISC?
Is it tied to how the access graph or violation engine treats policy IDs internally? - Are there any best practices to avoid loss of important violation history after updating a policy?
- What is the exact technical reason behind this violation reset behavior in ISC?
Conclusion
I would greatly appreciate it if anyone could share:
- Any ideas to improve the SoD automation process?
- How you are handling the 50-entitlements-per-list limitation?
- How to manage or reduce the impact of policy violation resets?
Thank you so much in advance for your valuable insights!
Regards,
Muhammad