Skip to main content

LinkedIn Twitter Facebook YouTube
Hitachi ID certification

Product Sites

Segregation of Duties

Segregation of duties (SoD) policies allow organizations to define toxic combinations of entitlements, which no one user should possess. The most common business driver for these policies is fraud prevention -- i.e., ensuring that fraud cannot be committed without collusion by at least two people.

An effective SoD engine has several components:

  • Policy definitions:

    • Define sets of two or more entitlements that should not be held by a single user.
    • Should support different types of entitlements, such as roles, login accounts and groups.
    • Should support large sets, such as "no user should have more than 2 of these 30 entitlements."

  • Approved exceptions:

    There are inevitably situations where an SoD policy should, legitimately, be violated. It should be possible to define approved exceptions to SoD rules.

  • Proactive enforcement:

    Change requests that pass through an IAM system should be subject to SoD policy checking. Changes that would trigger an SoD violation should be blocked at source.

  • After-the-fact detection:

    Many users and entitlements will exist before the IAM system is deployed or before a given SoD policy is defined. Moreover, system administrators may assign entitlements to users outside the IAM system. These scenarios mean that not all SoD violations can be prevented -- some have to be detected after the fact and remediated manually.

An effective SoD engine should detect violations even if the policy is stated in terms of roles but the violation is in terms of lower-level entitlements -- or vice-versa.

Consider the following variations, where R1 is a role that consists of entitlements Ea and Eb and R2 is a role that consists of entitlements Ec and Ed:

SoD policy

User has

User requests

Why this is a violation
R1 and R2 are mutually exclusive.



Direct violation.
(as above)


Ec, Ed

User would effectively get R2.
Eb and Ec are mutually exclusive.



User has Eb from R1, would get Ec from R2.
(as above)

Ea, Eb


User has Eb directly, would get Ec from R2.
(as above)

Ea, Eb


User has Eb directly, would get Ec.


A separate source of complexity is nested groups. i.e., entitlements on most systems are just groups, to which users are assigned and which are assigned access rights. Simple groups contain only accounts, but some systems, such as AD and RAC/F, support nested groups, where the members of a group can include other groups.

Just as nested roles create complexity and lead most SoD policy engines to yield false negative results (i.e., allow users to create undetected violations), nested groups also lead most SoD engines to fail to detect violations.

The Hitachi ID Identity Manager SoD engine decomposes both nested roles and nested groups, and will detect violations involving both/either.

Identity Manager includes the most advanced segregation of duties (SoD) engine available. It actually works, whereas competitor product SoD engines can be bypassed where both SoD rules and roles are deployed.

The Identity Manager SoD engine supports:

  • Policy definition:
    • An SoD rule is defined as a toxic sets of entitlements.
    • Entitlements that participate in the SoD rule may themselves be roles, login IDs on specified target systems or membership in specific security groups.
    • Users who have at least N of the M SoD entitlements are considered to be in violation.

    This is a very general model. It supports rules such as "No user shall belong to more than 2 of these 30 groups."

  • Approved exceptions:
    • Users may be allowed to violate SoD rules, so long as an authorized person has approved the violation.
    • Access certification is used to periodically renew approved SoD exceptions.

    This is a practical model. It allows organizations to knowingly violate rules where there is a strong business reason to do so and where suitable compensating controls are in place.

  • Proactive enforcement:
    • Identity Manager's SoD engine is an integral part of the workflow engine.
    • All change requests that pass through the Identity Manager workflow engine must either:
      1. Satisfy all SoD rules (i.e., violate none); or
      2. Include a request for an approved exception to every violated rule.
    • Requesters -- via the Identity Manager UI, API or automation engine -- simply cannot ask for violations without also asking for an approved exception.

    SoD should be proactive rather than after-the-fact, wherever possible. This is supported by Identity Manager.

  • Reporting on out-of-band and pre-existing violations:
    • There are several ways to bypass the Identity Manager pro-active SoD enforcement engine:
      • Pre-existing conditions, where a user violated the SoD rule before Identity Manager was implemented.
      • Pre-existing conditions, where a user violated the SoD rule before the rule was added to Identity Manager.
      • Out of band changes, made by administrators outside of Identity Manager.
    • In these cases, there is no general way for Identity Manager to know which of the offending entitlements is inappropriate, so it cannot automatically remediate the violating users.
    • Instead, Identity Manager includes reports to identify violating users and help security staff make appropriate remediating changes.

    SoD reporting is the defense of last resort.

  • Deep inspection:
    • Consider an SoD rule: "no user may have roles R1 and R2."
    • Now assume that role R1 contains entitlements E1 and E2, while role R2 contains E3, E4.
    • Next, consider a user who already has E1, E2 and E3, but has never been explicitly assigned R1. This user effectively has R1. If this user requests E4 or R2, the request should be flagged as an SoD violation.
    • The Identity Manager SoD engine, perhaps uniquely in the marketplace, will detect such violations. In general, it supports enforcement where SoD rules may cover any combination of individual entitlements and nested roles.

    To the best of Hitachi ID Systems' knowledge, no other SoD engine will detect SoD violations where the SoD rule is defined in terms of one level of the role hierarchy but the violation takes place at another level. This means that other SoD engines in reality only give organizations a false sense of security!

Return to Identity Management Concepts

page top page top