An Extension for Combination of Duty Constraints in Role-Based Access Control

Among access control models, Role Based Access Control (RBAC) is very useful and is used in many computer systems. Static Combination of Duty (SCD) and Dynamic Combination of Duty (DCD) constraints have been introduced recently for this model to handle dependent roles. These roles must be used together and can be considered as a contrary point of conflicting roles. In this paper, we propose several new types of SCD and DCD constraints. Also, we introduce strong dependent roles and define new groups of SCD constraints for these types of roles as SCD with common items and SCD with union items. In addition, we present an extension for SCD constraints in the presence of hierarchy.

💡 Research Summary

The paper addresses a gap in Role‑Based Access Control (RBAC) research: while most work focuses on separating conflicting roles through Separation of Duty (SD) constraints such as SSD, DSD, and their hierarchical extensions, modern organizations also need to enforce the opposite – that certain roles must be used together because they are functionally dependent. To this end, the authors extend the previously introduced Combination of Duty (CD) concept, which comprises Static Combination of Duty (SCD) and Dynamic Combination of Duty (DCD) constraints, by defining several new variants that capture a broader range of dependency policies.
First, the authors review the NIST RBAC model, its core components (users, roles, objects, operations, permissions, sessions) and the standard SD constraints. They then recall the original CD definition as a pair (rs, rn) where rs is a set of dependent roles and rn is a threshold. Building on this, they propose three distinct types of static constraints.

• SCD I requires that each individual user either holds none of the dependent roles in rs or holds more than rn of them. This forces a single user to be assigned a sufficient number of dependent roles to execute a complete business task.
• SCD II relaxes the per‑user requirement by allowing a user to hold ≤ rn dependent roles provided that together with a set of other users (us) the combined assignment exceeds rn. In other words, dependency can be satisfied collectively across a group of users.
• SCD III further refines SCD II by demanding that the groups of users that satisfy the constraint be mutually exclusive; no user may belong to two different satisfying groups. This eliminates overlapping collaborations and clarifies responsibility boundaries.
  The paper then introduces “common‑item” constraints, a stricter subclass of SCD. For each dependent role set, the policy may specify a non‑empty set of common objects, common operations, or common permissions that must be present in every role of the set. Four variants are defined: common objects only, common operations only, both objects and operations, and common permissions. By requiring these shared items, the model guarantees functional uniformity among dependent roles, ensuring that they truly represent a cohesive business function.
  A complementary “union‑item” variant is also defined. Instead of demanding that every role share the same items, the union of all items across the roles must contain a predefined minimum set. This provides a more flexible yet still controlled way to express partial overlap among dependent roles.
  Recognizing that many RBAC deployments employ role hierarchies, the authors extend SCD to the hierarchical context. They redefine the relevant RBAC functions (AuthorizedRoles, RoleHPrms, RoleHObs, etc.) to include inherited roles and permissions, and they adapt the SCD definitions so that the hierarchy‑aware role sets satisfy the same rn thresholds. This ensures that a user who inherits dependent roles through seniority still complies with the dependency policy.
  On the dynamic side, five types of DCD are presented. The basic DCD limits the number of dependent roles that can be activated within a single session. The additional variants consider multiple sessions, user‑session combinations, and hierarchical activation, allowing administrators to control not only static assignments but also runtime activation patterns of dependent roles.
  The authors argue that these extensions enable organizations to express powerful, precise, and flexible policies for dependent roles—policies that are impossible to capture with traditional SD constraints alone. They illustrate each constraint type with concrete examples, showing how users and sessions can be grouped to satisfy the new rules.
  In conclusion, the paper’s contributions are: (1) a comprehensive taxonomy of static and dynamic dependency constraints for RBAC; (2) the introduction of strong dependency via common‑item constraints; (3) hierarchical extensions that preserve dependency semantics across role inheritance; and (4) a set of DCD variants that manage runtime activation. The work opens avenues for future research, including implementation and performance evaluation of the proposed constraints, integration with policy‑automation tools, and empirical studies in real‑world enterprises.