# Violations A **Segregation of Duties (SoD) violation** occurs when a user has, or is about to receive, access that conflicts with a defined SoD policy. A violation means the system detected access that breaks a rule designed to prevent risky or conflicting capabilities. There are two types of violations: * **Direct** — the user holds the conflicting entitlement explicitly. * **Indirect** — the user has effective access to a conflicting entitlement through inheritance, such as a parent group or role hierarchy. ### How violation detection works {% stepper %} {% step %} A user is assigned one or more entitlements: role, group, resource, or organization. The algorithm retrieves the user's complete entitlement set from the AuthorizationManager. {% endstep %} {% step %} The system evaluates all active SoD policies: * For each policy, it evaluates each segment independently. * For each **active** segment, it: * applies any existing exemptions and excludes exempted entitlements from evaluation * compares the user's entitlements against the segment's conflicting sets * classifies each match as direct or indirect * records a segment violation when matched entitlements meet or exceed the segment `threshold` * A segment is **breached** when the user holds at least `segmentThreshold` entitlements from that segment, directly or through inheritance. * A **violation** is recorded when at least `policyThreshold` segments are independently breached. {% endstep %} {% step %} Both **direct** (explicit assignment) and **indirect** (inherited via group / org membership) entitlements are evaluated. {% endstep %} {% step %} Violations can also be triggered on-demand by an admin (see [Detecting Violations](#detecting-violations)). {% endstep %} {% endstepper %} Violation data is stored in **Elasticsearch** for fast querying. *** ## Violations tab Go to **Webconsole** → **Access Control** → **Segregation of Duties** → **Violations**. The violations view shows **users** who are currently in violation, grouped by policy. | Column | Description | | ---------- | ------------------------------------------- | | **User** | Name and login of the violating user. | | **Policy** | The SoD policies violated, shown as badges. | Click a user row to expand the accordion and see per-policy violation details. ### Detecting violations Violations are detected automatically when entitlements change. To trigger an on-demand re-evaluation across all users, go to **Webconsole** → **Access Control** → **Segregation of Duties** → **Violations** → **Detect Violations**. This calls `POST /rest/api/sod-policy-violation/impacted-users/detect` asynchronously in the background. To search for users already known to be in violation, use the search bar (filter by name, login, or specific policies). ### Viewing a user's violations Click on a **user** in the violations list. The accordion expands to show per-policy sections. Each section displays the violated entitlements in four categories: | Category | Direct | Indirect | | ------------- | ------------------------------------- | --------------------------------- | | Roles | Roles the user holds directly | Roles inherited via groups / orgs | | Groups | Groups the user is a direct member of | Groups inherited from parent orgs | | Resources | Resources directly assigned | Resources inherited | | Organizations | Orgs directly assigned | Orgs inherited | **Direct violations** must be remediated by removing the entitlement from the user. **Indirect violations** must be remediated by removing the user from the parent group or organization, or by removing the entitlement from that parent. For the available actions, see [Remediation](#remediation). ### Resolving violations From the user's violation detail view, select the entitlements to act on and choose an action: | Action | Effect | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Remove** | Permanently removes the entitlement from the user (or from the parent group/org for indirect violations). Re-evaluates violations after removal. | | **Whitelist / Allow** | Adds an exemption for this violation. Only available for `SOFT` severity policies. The violation is recorded as accepted rather than unresolved. | ### SelfService violation resolution During a **User Access Review (UAR)** campaign, users or their managers may be presented with an SoD violation resolution modal that: * shows the violating policy summary: name, severity, risk, and threshold * lists each breached segment and the entitlements contributing to the violation * displays a projected active segment count as entitlements are removed, so the reviewer can confirm whether the selection resolves the violation * supports two modes: * **Resolve** — select entitlements to remove. A confirmation indicator shows whether the selection is sufficient. * **Skip** — leave the violation unresolved. This is allowed for `SOFT` policies with exceptions enabled. See [Severity levels](#severity-levels). *** ## Severity levels The **severity** of a violation determines what happens when a provisioning operation would create an SoD conflict. The check runs inside `UserMgr.validateAgainstSodPolicy()`, which is called during every user save unless the request explicitly sets `skipSodPolicyCheck=true`. ### HARD violation A HARD violation **blocks the provisioning operation entirely**. What happens: {% stepper %} {% step %} ### Evaluation of incoming entitlements The system evaluates the user's incoming entitlement set against all active SoD policies (via `AuthManager.isConflict()`). {% endstep %} {% step %} ### Conflict found A HARD conflict is found. {% endstep %} {% step %} ### Audit log Audit log entry is written with action `HARD_SOD_POLICY_VIOLATION_DETECTION`, including the full violation details serialized as JSON. {% endstep %} {% step %} ### Exception thrown and rollback A `SodPolicyServiceException` (`ResponseCode.SOD_POLICY_VIOLATION`) is thrown — the user save rolls back and the entitlement change is rejected. {% endstep %} {% step %} ### Notification The policy's `managerGroupId` members are notified via the `SOD_VIOLATION_HARD` notification type, every time the violation is detected (including repeat occurrences). {% endstep %} {% endstepper %} The calling code receives the exception, and the end user or API consumer gets an error response. The conflicting entitlement is never persisted. ### SOFT violation A SOFT violation **allows the provisioning operation to proceed** but records and notifies about the conflict. What happens: {% stepper %} {% step %} ### Evaluation of incoming entitlements The system evaluates the user's incoming entitlement set against all active SoD policies. {% endstep %} {% step %} ### Conflict found A SOFT conflict is found. {% endstep %} {% step %} ### Audit log Audit log entry is written with action `SOFT_SOD_POLICY_VIOLATION_DETECTION`. {% endstep %} {% step %} ### Save proceeds The user is saved to the database normally — the entitlement change is applied. {% endstep %} {% step %} ### Violation recording and notifications * For **existing users**: if this is a **new** (previously unknown) violation, the violation is recorded in Elasticsearch (`UserViolatedSodPolicyDoc`) and the manager group is notified via `SOD_VIOLATION_SOFT`. For **repeat** known violations, no additional notification is sent. * For **new users** (no existing ID): the violation is noted in the audit log but no Elasticsearch doc is written and no notification is sent at detection time (the doc is maintained after save via `maintainViolatedSodUserDoc`). {% endstep %} {% step %} ### Post-save reconciliation After the save completes, `maintainViolatedSodUserDoc` reconciles the violation tracking document. Stale violations that no longer apply are removed from Elasticsearch, and the manager group receives a `SOD_VIOLATION_RESOLVED` notification. {% endstep %} {% endstepper %} #### Summary comparison | Behaviour | `SOFT` | `HARD` | | -------------------------- | ----------------------------------------------------------------------- | ---------------------------------------- | | Provisioning blocked | **No — save proceeds** | **Yes — save is rejected** | | Exception thrown | No | `SodPolicyServiceException` | | Audit action | `SOFT_SOD_POLICY_VIOLATION_DETECTION` | `HARD_SOD_POLICY_VIOLATION_DETECTION` | | Manager group notification | On first (new) violation only | **Every time** the violation is detected | | Notification type | `SOD_VIOLATION_SOFT` | `SOD_VIOLATION_HARD` | | Elasticsearch tracking | Yes — recorded in `UserViolatedSodPolicyDoc` | No (save never completes) | | Resolution notification | Yes — `SOD_VIOLATION_RESOLVED` when cleared | N/A | | Can be skipped | `ProvisionUser.skipSodPolicyCheck=true` skips both SOFT and HARD checks | Same flag | ### Violation resolution notification When a user's entitlements are updated and a previously recorded SOFT violation no longer applies (e.g., one of the conflicting entitlements was removed), the system: {% stepper %} {% step %} ### Detect resolution on next save Detects that the violation is no longer present during the next save. {% endstep %} {% step %} ### Notify manager group Sends a `SOD_VIOLATION_RESOLVED` notification to the manager group. {% endstep %} {% step %} ### Remove record Deletes the violation entry from the Elasticsearch document. {% endstep %} {% endstepper %} *** ## **Remediation** **Remediation** in OpenIAM SoD is the process of fixing or formally handling a conflict in user access after a violation is detected. When a user is found to violate a policy, administrators have two options: * **Remove conflicting access.** Removes the specified conflicting entitlements from the user via the provisioning service. This is the standard remediation path. * **Grant an exemption.** Creates a formal exemption that allows the user to retain the conflicting entitlements. Exemptions can be queried per user via the service to support auditing. *** ## Integration with Access Certification SoD violations are surfaced inside **Access Certification** reviews. When a manager reviews a user's access during a certification campaign: * Each access review item is checked against active SoD policies. * Violations are displayed as `AccessReviewItemSodViolation` records attached to the review item. * Each violation includes: policy name, severity, risk classification, conflicting entitlement details, segment information, and whether it is a direct or indirect violation. * The manager can certify (retain) or revoke access, with SoD context visible for informed decision-making. * Resolved violations are tracked via the `resolved` flag on the violation record. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs-beta.openiam.com/segregation-of-duties/violations.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.