Separation of duty policies

A separation of duty policy is a logical container of separation rules that define mutually exclusive relationships among roles. Policies for separation of duty are defined by one or more business rules. The rules exclude users from membership in multiple roles that might present a business conflict.

A separation of duty policy uses business rules to define the relationships among roles. The separation of duty policy groups the business rules for ease of administration. For example, we can assign a set of administrators to a policy, making the administrators responsible for tracking the violations of a set of rules.

Policy owners

We can specify one or more owners for the policy. Owners can be any combination of users and roles. We can configure policy owners to participate in policy and role change workflows. For example, a policy owner can approve or reject separation of duty violation activities that occur when roles are added to a Security Identity Manager user. Separation of duty policy owners can also:

• Exempt users or revoke exemptions from any policy violations that occur
• Be used as principals in system access control items (ACIs)

Exemption approval and revocation

Policy owners can approve and revoke exemptions by default, but they do not necessarily require this ability. We can configure roles or users to have access control capabilities over separation of duty policies though ACIs. The ACIs allow policy owners to do tasks such as editing or tracking violations. We can also configure the approval workflow to use participants other than the policy owner.

Separation of duty rules

A separation of duty policy can include multiple rules. For each rule, two or more roles must be listed. The number of roles to which a user can belong depends on how many roles you allow in the rule. The number of roles that you allow to coexist must be one fewer than the total number of roles in the list. For example, we might create a rule that excludes procurement and order approval. The allowed number of roles in the rule must be one, meaning that a user can have only one role. If we add more roles, such as invoicing and financing, we can allow up to three roles. Each user can have three different roles and the system capabilities defined by that role.

Allowed roles set to greater than one are typically used to prevent one person from having complete control over a process. The process is described by a set of roles. For example, a rule named "A user cannot have full control over the procurement process" might be defined by three roles named purchaser, approver, and orderer. In this example, the rule has two allowed roles. A user can be a member of two of these roles, but the user cannot a member of all three roles.

Enabled and disabled policies

An enabled policy creates exemption approvals and warns users before they submit a role membership change that breaks a separation of duty rule.

A disabled policy can still track violations, but it does not generate approvals or warn users. Violations from disabled policies are not displayed in audit reports. Using a disabled policy is a good way for a security administrator to track violations that occur before a policy is active in the system.

Role hierarchy and rules

Two roles in a rule cannot be direct ascendants or descendants of each other in the role hierarchy. For example, we cannot have a rule with both HR organization and HR department x if HR department x is a child role of HR organization.

• ACI operations for the separation of duty policy protection category
  We can configure role owners to have access control capabilities over separation of duty policies though access control items (ACIs). The ACIs allow role owners to do tasks such as editing or tracking violations. ACIs must apply to the business unit in which the policy is defined. Creators of separation of duty ACIs can define ACI filter rules to scope the policies to which an ACI applies.
• Default ACIs for the separation of duty policy
  See descriptions of the default access control items (ACIs) for separation of duty capabilities.
• Separation of duty approval workflow operation
  After we create the policy, an approval workflow operation named approveSoDViolation for each violation is started during person operations. These operations might be role membership changes that cause separation of duty policy violations.
• Separation of duty policy violations and exemptions
  A violation is a specific violation of a separation of duty policy, and an exemption is an approved separation of duty violation. Policy evaluation is a way to discover violations.
• Enabling the Manage Separation of Duty Policies portfolio task
  System administrators have access to the Manage Separation of Duty Policies portfolio task. Other users must be assigned to a group that has access to the task.
• Create separation of duty policies
  An administrator can create a separation of duty policy to use for auditing purposes. For example, we might create a separation of duty policy to report users that belong to multiple roles that are mutually exclusive.
• Modify separation of duty policies
  An administrator can modify a separation of duty policy. For example, we can add or remove policy owners. We can also add or remove separation rules, change role attributes for a specific rule, and enable or disable the policy.
• Evaluating separation of duty policies
  An administrator can evaluate a separation of duty policy without doing a data synchronization. By running the evaluation, we can view current policy violation and exemption information. The evaluation process searches for violations to the policies specified.
• Deleting separation of duty policies
  As an administrator, we can delete a separation of duty policy that is no longer needed to manage exclusive relationships between roles.
• View policy violations and exemptions
  An administrator or policy owner can view a summary of the separation of duty policy violations and exemptions for each rule in the policy. The administrator or policy owner can also do administrative operations, such as approve or revoke, on the violations and exemptions.
• Approving policy violations
  An administrator or policy owner can approve separation of duty policy violations for each rule in the policy.
• Revoking policy exemptions
  An administrator or policy owner can revoke separation of duty policy exemptions for each rule in the policy.

Parent topic: Policy administration