Using DirX Identity SoD Policies
This chapter describes how to set up SoD policies with DirX Identity’s built-in policy mechanism.
About this Use Case
You can set up SoD policies within DirX Identity at any privilege level: roles, permissions and groups. You can even set up policies at different levels; for example. between a role and a group. The following figure illustrates the options for setting up SoD policies, except for the option to set up a policy between a role and a group (which means that you can define hierarchical SoD).
The disadvantage of the SoD mechanism is that the policy engine must resolve users multiple times during rule execution if SoD checking is enabled, which lowers performance.
Documentation Hints
You can find additional information related to this use case in the following documents:
Application Development Guide
-
Understanding Request Workflows → Request Workflow Architecture → Selecting Request Workflows → Assignment Workflow Selection → Workflow Selection Mechanism for SoD - describes how SoD request workflow selection works.
-
Understanding Tcl-based Workflows → Full SoD Check Workflow - explains and gives hints for configuring the SoD full check workflow.
-
Understanding Tcl-based Workflows → Policy Execution Workflow - explains how the policy execution is influenced when SoD is enabled.
Customization Guide
Customizing Status Reports → Customizing Provisioning Status Reports → Virtual Objects and Attributes – explains how to use the described attributes to add SoD information to your status reports.
Provisioning Administration Guide
Use the context-sensitive help when working with SoD policies, SoD tabs at users or SoD activities of request workflows. Alternatively, you can access these parts of the documentation directly through the online help.
This guide contains two other sections that give additional insight into the topic:
-
Managing Policies → Managing SoD - general hints how to manage SoD policy objects and folders.
-
Managing Auditing → Managing SoD – provides an overview of the SoD topic.
-
Managing Users → Working With Links at User Entries - explains the meaning of the dxrPrivilegesGrantedLink attribute for SoD.
Specific Hints and Guidelines
Segregation of duties policies can help to fulfill compliance regulations. However, we recommend the following:
-
Keep the number of SoD policies you create to the necessary minimum. Defining too many SoD policies may initiate a large number of approval workflows, which will slow down your assignment processes. Having too many policies also affects the overall performance of the privilege resolution mechanism even though the algorithms are optimized for performance.
-
Activating SoD policies forces the policy execution workflow to perform immediate privilege resolution during rule-based processing even if you have configured it not to do so (that is, you did not set the Assign Privilege and Resolve option in the workflow wizard). The reason for this is that DirX Identity SoD checking works hierarchically and so the resolved privileges must be known. Performing this operation decreases the policy execution service performance. To avoid too much loss of performance, try to define rules that assign multiple privileges instead of defining multiple rules with one privilege each. This recommendation comes from the fact that a resolution is performed once per rule.
-
If you define an SoD workflow for a privilege that requires approval and the approval workflow is different from the SoD workflow, the SoD workflow has precedence, so the normal approval workflow is not started! We recommend keeping SoD workflows and normal approval workflows the same: you should include SoD approvers into your normal workflows and then use them as SoD workflows.
Setup and Configuration
Using DirX Identity’s SoD feature requires you to set up:
-
The central SoD flag at the domain object
-
SoD policies for each conflicting pair of privileges
-
SoD request workflows
-
A regularly running full SoD check
-
Reports and queries
-
Access policies
Set Up the Domain-Wide SoD Flag
Set the Segregation of duty (SOD) checks flag at the domain object. Note: restart DirX Identity Manager if you intend to test the policies within the Manager.
Set Up SoD Policies
Define SoD policies for each conflicting pair of privileges. Set the Is Active flag at each policy.
If the related privilege combination is already assigned to a user, an SoD workflow is started immediately to request approval for this SoD violation. As a result, you should be careful when activating SoD policies because the SoD process can generate a large number of SoD workflows within seconds.
Set Up Request Workflows for SoD
Ensure that assignment approval workflows are correctly configured. The workflow engine uses these workflows if an SoD approval is required.
Set Up a Full SoD Check
Run a FullSODCheck workflow regularly to detect SoD violations that are not currently approved. Note that this workflow automatically creates SoD approval workflows for all unresolved conflicts. It also reports all discovered SoD conflicts that have not yet been approved in its log files.
Set Up SoD Reports and Queries
DirX Identity comes with the following pre-configured SoD reports:
SoD policies with all properties - a report on all configured SoD policies.
SoD exceptions with all properties - a report on all approved and existing SoD exceptions.
Both reports are ready to use.
If you want to modify the reports, copy them to the folder Status Reports → Customer Specific.
You can also use or set up queries. DirX Identity comes with two default queries in the folder Policies → Queries:
All Active SoD Policies - displays all active SoD policies. This is the most important query for productive use.
All Inactive SoD Policies - displays all inactive SoD policies.
Copy these query folders to a project-specific folder (use the domain name as folder name) and refine them accordingly. Use, for example, another Search base that retrieves only active SoD policies from your specific project folder or define a query folder that retrieves all exceptions for a specific name. Use, for example, the filter:
(objectClass="dxrSodException" and cn="*$Name[Smith]*")
Running the Use Case
After setting up the SoD scenario, the policies have an immediate effect, which means that they are evaluated during each privilege assignment. SoD mitigation workflows are started as necessary to request approval.
Setting Up or Modifying SoD Policies
After setting up or modifying an SoD policy, we recommend that you test it.
Checking the Full SoD Check Result
Don’t forget to check the full SoD check runs, especially after setting up new SoD policies.
Using DirX Identity Manager or Web Center, assign all privileges of a policy or pairs of these privileges to a user. If the policy is correctly configured, the workflow engine notes the conflict and asks you if you want to proceed. Abort the assignment (otherwise a real approval workflow is started!).
Using SoD Reports or Queries
Note that SoD exceptions are always stored below the relevant SoD policy. You can view all exceptions either from the user side (that means all exceptions valid for that user) or from the policy side (all users that have exceptions for that policy).
You can use reports or queries or a combination of both.