Administrator guide
Separation of duties
How Warde checks a request against your identity engine's separation of duties rules, and the one setting that decides what happens on a conflict.
Warde does not keep its own separation of duties (SoD) rules. Your identity engine holds them, and Warde asks the engine before approval whether the access on a request conflicts with what the person already holds or with the rest of the request.
The setting
One instance-wide setting decides what happens when a conflict is found. Set it in Guided Setup step 6.
| When a conflict is found | What happens |
|---|---|
| Warn (the default) | Approvers see the conflict and still decide. Warn never stops a request. |
| Block | The request line fails before approval, and the requester is told why |
| Off | Nothing is checked, and approvers see nothing |
Where the check runs decides when the check happens:
| Where the check runs | Meaning |
|---|---|
| Both (the default) | The Request Access and Access Bundles forms check before submit, and each request line is checked again after submit and before approval |
| Client side (form) | The forms check, and cannot be submitted until everything on them is checked. A line is still checked after submit unless the form checked it and found no conflict, which covers access added because other access needs it. |
| Server side (approver) | Each request line is checked after submit and before approval, and the result is added to the request as a comment |
A form check makes people wait for each engine to answer before they can submit.
With Off, the forms do not check, request lines are not checked before approval, and approvers see no conflicts. The engine still applies its own rules when it adds the access.
Which engines answer
| Engine | Checked before approval |
|---|---|
| SailPoint IdentityIQ | Yes. Warde asks IdentityIQ's policy check for each request. |
| SailPoint Identity Security Cloud | No. ISC applies its SoD policies itself when it provisions. |
| Microsoft Entra ID Governance | No. Entra has no pre-provisioning conflict check. |
| ServiceNow tasks | No |
For access fulfilled by an engine with no check, the row reads Not checked, and approvers see that.
Where a verdict shows
- On the form: each row shows the result of Check for conflicts, and Check again after a change.
- For approvers: in the Warde: before you approve comment on the approval record.
- For the requester: as a comment on the requested item.
- For administrators: the Admin Workspace list Requests > SoD warned or blocked.
When the engine does not answer
| Setting | What it does | Default |
|---|---|---|
x_66256_warde.sod.pending_timeout_mins | How long Warde waits for the engine's answer before acting on the next setting | 15 |
x_66256_warde.sod.unavailable_action | proceed lets the line continue, marked as unavailable, and the engine still applies its own rules when it grants; block fails the line | proceed |
Related settings
| Setting | What it does | Default |
|---|---|---|
x_66256_warde.sod.context_lines | How many of the same person's other open requests are sent with each check, so two pieces of access requested at the same time are checked against each other. Each item in a bundle counts as one. | 20 |
x_66256_warde.sod.bundle_member_cap | The largest bundle checked before approval. A bigger bundle is marked as not checked, and the engine applies its own rules when it adds the access. | 40 |