60 An XML Based Approach to Enforcing History-Based Separation of Duty Policies in Heterogeneous Workflow Environments Carl Papenfus and Reinhardt Botha Faculty of Computer Studies, Port Elizabeth Technikon, Port Elizabeth, South Africa rbotha@computer.org Abstract In the computing world a new technology occasionally comes along, promising to make dramatic changes to the way computing tasks are performed. The Extensible Markup Language (XML) has been heralded as one such technology. XML promises to provide a universal metadata mechanism for defining, understanding and interchanging information between possibly heterogeneous systems. This paper exploits this powerful promise of XML by examining how it can be used to enforce history-based separation of duty policies across heterogeneous workflow environments. A very brief overview of separation of duty policies is provided, whereafter the need for history-based separation of duty is motivated through an extensive case study. A solution based on XML baggage is proposed and it is shown how the solution would operate in the context of the case study. Keywords: Workflow, Separation of duty, Access Control, XML, Systems Integration Computing Review Category: H4.1, K6.5 1 Introduction Separation of duty (SoD) is a security principle used to formulate multi-person control policies. In essence it stipulates that two or more different people must be responsible for the completion of a business process. It would thus, in principle, discourage fraud by requiring a conspiracy, thereby increasing the risk to the potential perpetrators [10]. Two basic variations of separation of duty exist, namely static separation of duty and dynamic separation of duty [10]. Static SoD requires that the membership to a set of roles must be strongly exclusive [7]. Business reality, however, may require the same user to belong to two roles in the set. This shortcoming of static SoD led to the introduction of various forms of dynamic SoD policies. Dynamic SoD policies provide increased flexibility by controlling the activation and usage of roles. It thus removes the primary deficiency of static SoD by allowing users to act in multiple roles [12]. Dynamic SoD in its initial form simply prohibits a user to have more than one role active at any time. It, however, does not restrict the potential of a user to belong to another role. Several variations of dynamic SoD were proposed to meet some of the shortcomings of this basic form. Object-based SoD allows a user to belong to multiple exclusive roles, but no user may act upon an object he has previously acted upon [5]. This strategy has the limitation of only allowing a user to act on a particular object once in a business process. Operational SoD, on the other hand, allows a user to perform multiple actions while adopting multiple roles. However, this is only allowed if the union of the privileges of all roles with common users is not enough to complete an entire business process [3]. Operational SoD, furthermore, does not allow one user to perform all the actions in a business process, even if on different objects. History-based SoD essentially combines the ideas behind object-based SoD and operational SoD. It allows one user to have multiple roles and also allows the union of the actions of those roles to span an entire business task. However, no user is allowed to perform all the actions in a business task on the same object. History-based SoD thus requires a detailed access history on each object [10]. The case study provided below will utilize various SoD policies to illustrate that a need for maintaining SoD policies across heterogeneous systems exists. 2 Business Scenario The business scenario utilizes two heterogeneous workflow systems. The workflow systems are used by a motor vehicle manufacturing company to allow Dealers to claim back capital from the manufacturer’s Warranty Department for repairs done to cars that are still under warranty. Although closely linked in the business scenario the two workflow systems were developed independently