<role> <name>Judge</name> <inducement> <construction> <resourceRef oid="ef2bc95b-76e0-59e2-86d6-3d4f02d3ffff" type="ResourceType"/> </construction> </inducement> <assignment> <policyRule> <name>excluded-role</name> <policyConstraints> <exclusion> <targetRef oid="12345678-d34d-b33f-f00d-987987987988" type="RoleType"/> </exclusion> </policyConstraints> <policyActions> <enforcement/> </policyActions> </policyRule> </assignment> </role>
Segregation of Duties
Since 3.5This functionality is available since version 3.5. The functionality was further improved in version 3.6.
Segregation of Duties (SoD) is a mechanisms that prevents accumulating of too much power in the hands of a single person. It places constraints on assignments of entitlements to users. For example SoD may prevent a single user from creating a request and also approving it.
In its simplest form the Segregation of Duties is implemented at the RBAC level by role exclusions. It means that roles that exclude each other cannot be assigned to the same user at the same time. This is the basic SoD mechanism that is implemented in midPoint now. More complex SoD rules will be implemented in the future.
Role Exclusion Definition
Following role excludes role with oid
12345678-d34d-b33f-f00d-987987987988. These two roles cannot be assigned at the same time.
Attempt to do so will result in an error.
The exclusion is considered to be bi-directional even if it is defined in only one of the two excluded roles.
Therefore the order of role assignment is insignificant, whichever role is assigned as second will result in a failure.
In midPoint 3.5 and later the exclusion is defined by using the policy rules mechanism:
Currently, the role exclusion mechanism ignores the time validity of individual assignments.
Hence, if roles
(Technically, both roles are still assigned at the same time. The other things is that those two assignments cannot be effectively active at any moment.)
Policy Rules have two parts important for role exclusion configurations: constraints and action. Constraints part defines which roles are exclude which roles. The action part define what to do when such an exclusion is detected. There are three options:
Enforcement means that role conflict is not allowed. Any attempt to assign conflicting roles will end with an error.
Pruning means that the conflicting roles are unassigned. When a new role is assigned the existing roles that are in conflict with the new role will be unassigned.
Approval means that the request will be subject to an additional approval. The approver may decide whether to allow assignment of conflicting roles. If the operation is approved then it proceeds. (Optionally you can request recording the situation in the assignments by using "record" policy action.)
MidPoint does not have direct configuration for role exclusion classes (set of roles where each excludes all other roles from the same class or from different classes). However this configuration can easily be created an maintained by using role hierarchies and metaroles.
For example, the following example illustrates "exclusion class" between executive and controlling roles. The controlling metarole defines exclusion of all executive roles:
<role> <name>Controlling metarole</name> <description>Excludes all executive roles using a filter</description> <inducement> <policyRule> <name>executive exclusion</name> <policyConstraints> <exclusion> <targetRef type="RoleType"> <filter> <q:equal> <q:path>subtype</q:path> <q:value>executive</q:value> </q:equal> </filter> <resolutionTime>run</resolutionTime> </targetRef> </exclusion> </policyConstraints> <policyActions> <enforcement/> </policyActions> </policyRule> </inducement> </role>
The metarole above is to be assigned to controlling roles (where subtype is different from "executive", e.g. "controlling"). If the user has any controlling role assigned and attempts to have other role with subtype="executive" assigned, the request will be refused because of the SoD conflict. Thus it is not possible to mix executive and controlling roles.
In midPoint 3.4 and earlier there was no policy rules feature. Therefore the role exclusion was defined as:
<role> <name>Judge</name> <inducement> <construction> <resourceRef oid="ef2bc95b-76e0-59e2-86d6-3d4f02d3ffff" type="c:ResourceType"/> </construction> </inducement> <exclusion> <targetRef oid="12345678-d34d-b33f-f00d-987987987988" type="c:RoleType"/> <policy>enforce</policy> </exclusion> </role>
This configuration is currently deprecated. However it still works. And while currently there are no specific plans to remove it we recommend to migrate to configuration based on Policy Rules at the earliest convenient moment. The policy rules are much more flexible mechanism.
Basic role exclusion with strict enforcement is available in midPoint since version 2.x. The definition based on Policy Rules is available since midPoint 3.5. However this is still limited to strict enforcement. The other policy actions are available since midPoint 3.6.