An Activity-Based Model for Separation of Duty

This paper offers several contributions for separation of duty (SoD) administration in role-based access control (RBAC) systems. We first introduce a new formal framework, based on business perspective, where SoD constraints are analyzed introducing the activity concept. This notion helps organizations define SoD constraints in terms of business requirements and reduces management complexity in large-scale RBAC systems. The model enables the definition of a wide taxonomy of conflict types. In particular, object-based SoD is introduced using the SoD domain concept, namely the set of data in which transaction conflicts may occur. Together with the formalization of the above properties, in this paper we also show the effectiveness of our proposal: we have applied the model to a large, existing organization; results highlight the benefits of adopting the proposed model in terms of reduced administration cost.

💡 Research Summary

The paper addresses the longstanding scalability and semantic problems of Separation of Duty (SoD) enforcement in large Role‑Based Access Control (RBAC) deployments. Traditional approaches define conflicts directly among permissions or roles, which becomes unmanageable when thousands of roles and hundreds of thousands of permissions are present, and often fails to capture the true business intent behind a conflict. To overcome these limitations, the authors introduce an activity‑centric model that shifts the focus from technical RBAC entities to business activities – the elementary tasks derived from decomposing organizational processes.

An activity is formally defined as a set of permission groupings (GRPS ⊆ 2 PERMS) that must be collectively possessed by a user to execute that activity. Activities are organized in a single‑rooted hierarchy (ACTVT, ACTVT‑H) using an “is‑a” partial order, allowing generalization and inheritance of permission requirements. The model adds three new constructs to the classic RBAC universe: ACTVT (the set of activities), GRPS (permission groupings), and ACTVT‑G (the relation linking activities to groupings). This separation enables business analysts, who lack deep technical knowledge, to specify which activities conflict, while IT staff only need to map the appropriate permission groups to each activity.

Crucially, the paper extends SoD to the object level through the introduction of SoD domains. A domain represents a specific data set (e.g., a particular accounting ledger). Conflict specifications take the form conflict(a₁, a₂, d), where a₁ and a₂ are activities and d is an optional domain. Thus, two activities may be mutually exclusive only when they operate on the same domain, supporting fine‑grained, object‑based separation such as “the same invoice cannot be both created and approved by the same user.”

Conflict detection is performed by checking whether a user’s effective permission set (derived from role assignments, role hierarchies, and session activation) simultaneously contains all permission groups required by two conflicting activities within the same domain. Because activities are far fewer than roles or permissions (typically a few hundred versus thousands), the computational overhead of conflict checking is dramatically reduced. Moreover, the model naturally integrates with dynamic SoD policies that rely on session activation, as the activity‑to‑permission mapping can be evaluated per session.

The authors validate the approach with a real‑world case study in a large Italian enterprise. They migrated existing role‑based SoD policies to the activity‑based framework, defined activity hierarchies, mapped permission groups, and identified conflict pairs with domain annotations. Empirical results show a reduction of more than 60 % in policy definition time, conflict verification time, and overall administration cost. Additionally, the number of policy violations observed after deployment decreased, indicating that the model not only eases management but also improves security posture. Business units were able to directly edit SoD constraints without involving the IT security team, demonstrating the practical benefit of separating business logic from technical implementation.

In summary, the paper makes four major contributions: (1) a formal activity‑centric SoD model that abstracts away from the explosion of roles and permissions; (2) a permission‑grouping mechanism that ties activities to concrete access rights; (3) the SoD domain concept that enables object‑level separation; and (4) an empirical evaluation confirming substantial cost savings and security improvements in a large organization. By aligning SoD enforcement with business processes rather than technical artifacts, the proposed model offers a scalable, expressive, and administratively efficient solution for modern enterprises.