Modeling of Task-Based Authorization

Constraints in BPMN

Christian Wolter and Andreas Schaad

SAP Research
Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany
{christian.wolter,andreas.schaad}@sap.com

Abstract. Workflows model and control the execution of business processes in

an organisation by defining a set of tasks to be done. The specification of work-
flows is well-elaborated and heavily tool supported. Task-based access control is
tailored to specify authorization constraints for task allocation in workflows. Ex-
isting workflow modeling notations do not support the description of authoriza-
tion constraints for task allocation commonly referred to as resource allocation
patterns.
In this paper we propose an extension for the Business Process Modeling No-
tation (BPMN) to express such authorizations within the workflow model, en-
abling the support of resource allocation pattern, such as Separation of Duty,
Role-Based Allocation, Case Handling, or History-Based Allocation in BPMN.
These pattern allow to specify authorization constraints, for instance role-task as-
signments, separation of duty, and binding of duty constraints. Based on a formal
approach we develop an authorization constraint artifact for BPMN to describe
such constraints.
As a pragmatic demonstration of the feasibility of our proposed extension
we model authorization constraints inspired by a real world banking workflow
scenario. In the course of this paper we identify several aspects of future work
related to verification and consistency analysis of modeled authorization con-
straints, tool-supported and pattern-driven authorization constraint description,
and automatic derivation of authorization policies, such as defined by the eXten-
sible Access Control Markup Language (XACML).
Keywords: Security in business processes, Business process modeling and
analysis.

1 Introduction

Process-aware information systems, such as workflow management systems, enterprise

resource planning applications, and customer relationship management systems are
used to control and monitor business activities [1]. In the application area of business
activity or workflow specification, modeling patterns have emerged assigned to different
business and organizational perspectives. The control flow perspective focuses on the
aspect of process control such as process flow, routing, synchronization, and merging.
Patterns related to the data perspective address issues, such as data visibility, data in-
teraction, data transfer, and data-based routing. A recent perspective is that of resource

G. Alonso, P. Dadam, and M. Rosemann (Eds.): BPM 2007, LNCS 4714, pp. 64–79, 2007.

c Springer-Verlag Berlin Heidelberg 2007
 Modeling of Task-Based Authorization Constraints in BPMN 65

allocation patterns. It focuses on the manner in which work is distributed and managed
by human resources associated with a workflow [2].
“The resource perspective centers on the modeling of resources and their interac-
tion with a process-aware information system” [1]. Resources can be differentiated into
human and non-human resources. Resource patterns were investigated with respect to
levering the interaction of humans with the information system beyond the assignment
and execution of tasks in an user’s task list. Especially, so called creation patterns deal
with the specification of task advertisement and allocation restrictions (i.e. who may
claim and execute a task) [2].
Control of work allocation and execution is a recognized fundamental principle of
human interaction in computer security originating from organisational theory enforced
by authorization constraints [3]. One of the earliest authorization constraints for hu-
man work allocation control is the four-eyes principle and first appeared in Saltzer and
Schroeder [4]. Later the term separation of duty was introduced in [5] as a principle
for integrity and a mechanism for error control and preventing fraud. In human-centric
workflows this is done by limiting an user’s work allocation statically and dynamically
[6]. In the former an user’s work allocation is limited a priori for instance by assigning
a role with a fixed set of tasks. In the latter an user’s work allocation is constrained
depending on the tasks the user recently performed. In [7], Botha gives a taxonomy for
different kinds of static and dynamic separation of duty and describes the conflicting
entities paradigm for tasks implying that the risk of fraud increases if the associations
with those tasks are not carefully controlled and monitored.

1.1 Problem Statement

Recent work has shown that existing modeling notations, such as BPMN, UML 2.0 AD,
or ORACLE BPEL provide poor support for most resource allocation pattern [1,2]. The
Separation of Duty, History-Based, Case Handling, and Role-Based resource alloca-
tion pattern address the aspect of defining authorization constraints, such as it is well
known in the application domain of task-based security administration for workflows.
Task-based authorization constraints express who is allowed or must perform a certain
task under specific circumstances in the context of a workflow, but most resource allo-
cation pattern are not supported by well elaborated modeling notations as stated in [2].
Therefore, it should be explored if the domain of business process modeling, resource
allocation patterns, and the specification of authorization constraints for workflows can
be united.
A possible approach would be to create a new workflow modeling notation with
a focus on task-based authorization specification or to extend an existing graphical
policy specification language, such as LaSCO [8], with control flow elements. In [2],
Aalst et al. claim to enhance existing process modeling notations to support the re-
source allocation perspective, rather then creating new notations that overlap with ex-
isting ones along the control flow perspective. From the domain of security engineering
Crampton stated “[..] that existing approaches to the specification of authorization con-
straints are unnecessarily complicated” [9] and not directly specified within the work-
flow model itself. This might lead to inconsistency issues in the case of model changes,
when the related authorization constraints are not changed as well. Recent extensions to
66 C. Wolter and A. Schaad

existing process execution languages such as RBAC-WS-BPEL [10] and BPEL4People

[11] indicate that the fusion of business process definition and related authorization
specification for manual tasks is at hand. One possible next step would be to leverage
the definition of authorization constraints into the process of workflow modeling.
Therefore, in this paper we propose a refinement of the Business Process Model-
ing Notation to enable a description of authorization constraints, without affecting the
control flow semantics of BPMN as desired in [12] and avoiding an overly complex
specification language. The extended notation allows the specification of task-based
authorization constraints and enhance the support of resource allocation patterns by
BPMN, such as the Separation of Duty pattern [1,2]. The extension enables the descrip-
tion of role hierarchies, separation of duty, and binding of duty constraints within the
BPMN model. We choose BPMN because of its capabilities to be mapped onto BPEL
[13,14] an emerging standard in workflow specification. On the other hand BPMN has
an appealing graphical notation. The basic flow elements of BPMN are extremely easy
to understand and grasp. Even security specialists who are not very familiar with the
details of BPMN are able to understand these diagrams.

In essence, the contributions of this paper are as follows,

– it is a formal definition of authorization constraints in the context of workflow
models.
– it provides example workflow constraints derived from the banking domain and
their formal representation.
– it is an evaluation of BPMN’s capabilities to express task-based authorization con-
straints in the context of resource allocation and defines a BPMN extension for the
specification of appropriate authorization constraints.
– it applies the proposed BPMN extension to a real world banking scenario to evalu-
ate its applicability.
The rest of the paper is organized as follows. In Section 2 we discuss a formal defini-
tion of authorization constraints for workflow environments and provide some prelim-
inary examples. A banking workflow is presented in Section 3 and several real world
authorization constraints for this example process are given along with their formal
representation. In the subsequent section we propose a BPMN extension based on our
formal definition to visualize the discussed authorization constraints. We apply our no-
tation to the example banking workflow in order to demonstrate the feasibility of our
proposal. In Section 4 we proceed with an overview of related work in the area of au-
thorization constraint modeling and specification. In Section 5 we discuss and conclude
our approach and outline some suggestions of future work, such as model consistency
and verification analysis.

2 Authorization Constraints for Workflows

The definition of organisational roles is a suitable concept for expressing elaborate and
fine-grained authorization control. Thus, it is not surprising that defining authorization
constraints received particular attention with the progress made in role-based access
 Modeling of Task-Based Authorization Constraints in BPMN 67

control [15]. The definition of authorizations that should not be owned by the same user
in order to make fraudulent acts more difficult to commit evolved into the principle
of conflict of interest. Conflict of interest in workflows can be expressed by defining
conflicting tasks in the context of task-based access control [16]. In [7], conflicting tasks
are characterized by an increased risk for potential misuse and fraud if a single user is
authorized to perform them all. Therefore, the authorization to allocate and perform
conflicting tasks has to be constrained carefully.
In [9], Crampton identified and formalized different authorization constraint types
for conflicting tasks in workflows. Namely, entailment constraints for defining autho-
rizations depending on already performed tasks and additional cardinality constraints
to express separation of duty and binding of duty requirements for workflow tasks and
tasks instances. He defined an entailment constraint as: “If the execution of a task t2 is
constrained by the execution of another task t1 , where t1 < t2 , then we say that t2 is an
entailed task of t1 ” [9]. Here “<” denotes a temporal dependence between the execution
of task t1 and t2 , meaning t1 was executed prior to t2 . According to his definition en-
tailment constraints are related to exactly two tasks. In [10], he identified this restriction
and outlined future work to extend the definition of entailment constraints. In what fol-
lows we develop a formalized authorization constraint that builds on previous work of
Crampton, but overcomes the existing limitations. Therefore, our proposed authoriza-
tion constraint specification can be applied to an arbitrary set of conflicting workflow
tasks and task instances, across role boundaries, and beyond simple task sequences.

2.1 Formalization of Authorization Constraints

To provide a formalized definition we will begin with defining user-role assignments
and task-role assignments. Further, we define conflicting tasks and present a general
definition of an authorization constraint. We consider a task assignment as the determi-
nation of a set of potential users allowed to perform a task. An allocation is the actual
claim to perform an assigned task by an user.

Task-Role Assignment
Tasks assigned to roles are a first approach to restrict task authorization according to
user roles. If there exists a set of tasks that imply a potential risk of fraud or misuse
when performed by the same user, such task authorizations can be distributed among
different roles at design time of the workflow. Therefore, a task-based assignment of
tasks according to an user’s role enforces separation of duty security requirements as
long as an user is restricted to a single role within a workflow instance. This is com-
monly referred to as static separation of duty [3].
We define T as the set of tasks {t1 , t2 , ..., tl } and R as a set of roles {r1 , r2 , ..., rm }.
We assume the existence of a partially ordered set of relations between roles R, ≤
that can be visualized as a role hierarchy. If r1 , r2 ∈ R and r1 < r2 , then we say r2
dominates r1 with respect to organisational role superiority (e.g., rClerk < rManager ).
Further, we define U as the set of users {u1 , u2 , ..., un }. Let T R ⊆ (T × R) be a
many-to-many task-role assignment relation and let U R ⊆ (U × R) be a many-to-
many user-role assignment relation. This means, users are associated with roles using
the user-role assignment relation and tasks are associated with roles using the task-role
68 C. Wolter and A. Schaad

assignment relation. Further, we will assume that a task is an atomic action within the
context of a workflow. According to [9] we define:
R(t) = {rm ∈ R : ∃(tl , rm ) ∈ T R(t)}
U (t) = {un ∈ U : ∃(un , rm ) ∈ U R, rm ∈ R(t)}.

In other words R(t) is the set of roles authorized to allocate a task tl . Thus, U (t) is
the set of users authorized to allocate and perform the task tl .

Conflicting Tasks
In some cases conflicting tasks cannot be assigned to different roles without segmenting
the existing roles in such a way that they become unmanageable with respect to the re-
ferred organisational role model. In addition, role hierarchies can be used to act in two
previously separated roles and thus regaining the authorization to allocate conflicting
tasks, e.g. a manager may act as a clerk and as his own supervisor. Hence, we have
to define additional constraints between tasks that do not depend on potential task-role
assignments.
For this reason we define a workflow model N as a tuple (T, ci , co , F ). A workflow
consists of a set of tasks T . Let ci be the start condition and co the end condition of the
workflow. The control flow relation (i.e., task sequence, splits, and joins) of all tasks in
T is defined by the relation F ⊆ (ci × T ) ∪ (T × co ) ∪ (T × T ). That means every task
in the workflow (T, F ) is on a directed path from ci to co .
We define a set of conflicting tasks of a workflow N as Tc ⊆ T . According to [9]
the set Tc contains tasks whose allocation depends on the allocation of previously per-
formed tasks of Tc . Such dependencies are described as an entailment between the tasks
of Tc [9]. We define tn ∈ Tc as an entailed task of tm ∈ Tc , when the allocation of tn
is constrained by the allocation of task tm , where tm < tn (i.e. on a direct path from ci
to co , tm is performed before tn ).

Task Authorization Constraint

With the definition of sets of conflicting tasks and the general understanding that the
authorization of an user to perform further conflicting tasks of the same set depends on
his and other users previous actions in a workflow we can define a task authorization
constraint c for a set of conflicting tasks as:
c = (Tc , nu , mth ), with nu , mth ∈ N.
The value nu defines the minimal number of different users that have to allocate a
task tk ∈ Tc . Let tki be an instance of the task tk . We define mth as the threshold value
of the sum of task instances tki , ∀t ∈ Tc an user un is allowed to allocate:

mth (un ) = (tki (un )), ∀t ∈ Tc ,
mth (un ) ≤ mth , ∀u ∈ U .
It should be mentioned that mth sums up the task instances of all tasks in Tc , while
nu dictates the number of different users that have to allocate at least one tasks instance
of tasks ∈ Tc . The following Table 1 gives some example constraints based on common
task allocation requirements.
 Modeling of Task-Based Authorization Constraints in BPMN 69

Table 1. Example Constraints

cn Workflow Separation of Duty Formal Constraint

Requirement (Tc , nu , mth )

c1 Task t1 and t2 must be per- c1 = ({t1 , t2 }, 2, 1)

formed by different users.

c2 Task t1 and t2 must be per- c1 = ({t1 , t2 }, 1, 2)

formed by the same user.

c3 Two users must be involved in c1 = ({t1 , t2 , t3 , t4 }, 2, 3)

performing t1 , t2 , t3 , and t4 . Here, the maximum value of
mth is implicitly dictated by
nu .

c4 Two users must be involved and c1 = ({t1 , t2 , t3 , t4 }, 2, 2)

each user may only perform Unlike c3 , mth = 2, otherwise
two out of four tasks. the 2-out-of-4 requirement can
not be expressed as a constraint.

c5 The same task can only be per- c1 = ({t1 , t2 }, 2, 2)

formed twice by the same user
and t1 and t2 must be per-
formed by different users.

Our definition of authorization constraints allows to specify constrained workflow

models that may encounter a deadlock situation due to shortage of different users or
inconsistencies between nested constraints at run time. In [9], an algorithm is presented
that is able to determine inconsistent workflow authorization constraints. This algorithm
is based on a simulation-based approach by exhaustively searching possible execution
paths of a constrained workflow without an occurring deadlock situation due to autho-
rization constraints. This approach is limited to constraints defined on a pair of tasks
and has to be expanded to an arbitrary set of tasks per constraint. We are aware of
this important consistency issue and are planning to apply the algorithm to our BPMN
models at design time, but refer to Section 5 and consider this topic as future work.

2.2 Conflicting Tasks in a Banking Workflow

In this section we present an example workflow inspired and in parts derived from
the banking application workflow that is given in [3]. We discuss several conflicting
tasks and their related task allocation constraints for this example workflow. For each
70 C. Wolter and A. Schaad

constraint we provide a formal description based on the authorization constraint defi-

nition of the last subsection. We keep the example workflow as simple and intuitive as
possible without losing ourself in routing, messaging, and exception details, but with
the idea in mind that our approach can be applied to a real world scenario.
The process describes the necessary steps for opening an account for a customer.
Therefore, the customer’s personal data is acquired. The customer is identified and the
customer’s credit worthiness is checked by an external institution. Afterwards, one of
several product bundles is chosen. A form is printed for the selected bundle that is
signed by the customer and the bank. The described process is illustrated in Figure 1.

Fig. 1. Example Banking Workflow

The following set of task assignment constraints is a subset of properties that were
discussed in [3] with SAP Banking solution architects:
1. A Clerk must interact with the customer
This constraint describes the role definition of a clerk according to task-role and
user-task assignment. There exists a direct relationship to the Role-Based Alloca-
tion discussed in [1]. This requirement can be expressed with the role definition:
T Rclerk = {t1 , t2 , t3 , t4 , t5 , t6 , t8 } (Role-Based)
2. A bank manager must sign the form as a clerk’s supervisor and can act as a clerk
regarding any other task
This is another role definition related to the Role-Based Allocation. Here, the
role manager inherits the set of task authorizations of the role clerk and extends
the set with task t7 . This requirement can be expressed with the role definition of a
manager:
T Rmanager = {T Rclerk ∪ t7 } (Role-Based)
 Modeling of Task-Based Authorization Constraints in BPMN 71

3. An user must not check the credit worthiness and rating for the same customer.
A separation of duty requirement that is related to the Separation of Duty resource
allocation pattern describing that the same user must not perform two conflicting
tasks [1]. In this example the resulting authorization constraint would be:
c3 = ({t3 , t4 }, 2, 1) (Separation of Duty, Role-Based, History-Based)
4. A bank manager may act as a clerk, but must not sign his own form.
This requirement is similar to the previous constraint, but this time the set of con-
flicting tasks spans two different roles (e.g. the role clerk and the role manager).
Thus, the same user capable of acting in two different roles for the same workflow
instance would still violate this requirement. For example, an user acts in the role
of a clerk and later changes to the manager role in order to sign his own form.
Therefore, the resulting authorization constraint preventing the exploitation of the
role hierarchy would be:

c4 = ({t7 , t8 }, 2, 1) (Separation of Duty, Role-Based, History-Based)

5. An user acquiring the customer data must identify the customer’s account.
This requirement is related to the binding of duty principle discussed in [9]. This
means the same user performing a previous task is automatically assigned to all
other tasks of the same set. In [1], additional patterns are discussed, such as Case
Handling, History-based Allocation, and Retain Familiar patterns. They are based
on the idea that further allocation is done automatically due to some previous activ-
ities. Hence, binding of duty requirements are related to those resource allocation
pattern. The resulting constraint is:

c5 = ({t1 , t2 }, 1, 2) (Case Handling, Role-Based, History-Based, Retain Familiar)

6. For a single customer an user must not perform more than five tasks.
This is a dynamic separation of duty constraint allowing a clerk to allocate any tasks
as long as he does not allocate more than five tasks for the same workflow. This
constraint is more flexible than the previous separation of duty constraints, because
it cannot be determined in advance which tasks an user will allocate, depending on
his allocation behaviour his authorized tasks vary for each workflow instance. The
according authorization constraint would be:

c6 = (T Rclerk , 2, 5) (History-Based)

3 Modeling of Authorization Constraints

Several authorization specification languages and modeling approaches can be found in
the literature [3,4,7,9,17,18,19]. None of these languages and approaches was applied in
the context of workflow modeling itself, but rather done in a separate specification and
modeling environment, sometimes even without access to the related workflow model
making the whole process error prone and inconsistent with the related workflow, when
it changes. In this section we address this problem by integrating the notation of an
authorization constraint into a strong visual and commonly used workflow modeling
notation, such as BPMN.
72 C. Wolter and A. Schaad

3.1 Extension of BPMN

The Business Process Modeling Notation (BPMN) has a general look-and-feel that
makes it easy to be understood by diagram modelers and any viewer of the diagram.
Besides its strong visual expressiveness, another important aspect of BPMN is its ex-
tensibility capabilities as stated by the creators of BPMN [12]. When extending BPMN
it is important to neither change the general footprint of any existing flow element, such
as events, activities and gateways. Nor should any new flow element be added, because
no specification will be available describing how it will be connected to existing flow
elements. Therefore, BPMN provides the concept of artifacts to extend the expressive-
ness of BPMN without affecting the basic sequence or message flow of a process model
or the mapping to execution languages, such as BPEL. The artifacts are designed to be
open to allow annotations and makers to convey specialized information [12].
To model task allocation constraints within the workflow model, according to our
formal definition, we need to express manual tasks and their assigned roles. It must
be possible to define a partial role order with respect to role hierarchies. Further, we
need the possibility to define groups of manual tasks we can apply constrains to. As
a last step, it is necessary to express the authorization constraint we discussed in the
last section. Most of the requirements can be already fulfilled in BPMN with an ex-
isting graphical element and we need to extend its semantic. In the case of the au-
thorization constraint itself we derive a new artifact from the textual annotation
element.
The entity relationship diagram depicted in Figure 2 shows an extract of the BPMN
metamodel [20] and highlights the entities, named according to the BPMN specifica-
tion, necessary to express authorization constraints within BPMN.

Fig. 2. Extract of the extended BPMN Metamodel

 Modeling of Task-Based Authorization Constraints in BPMN 73

Manual Tasks and Roles

An activity is a generic term for a task that someone performs. A task can be atomic
or non-atomic (here we restrict ourself to atomic tasks). Pools or lanes may contain
tasks. Each task in BPMN comes with a boolean attribute Manual Task that can be
used to specify a task as manual, i.e. it must be performed by an user. Lanes are used
to assign tasks to organisational roles of a rights management system and refer to the
classical role-task authorization. Nested lanes are used to represent the role-based task
authorization inheritance and role hierarchy. For example in Figure 3 the Manager role
inherits the task authorizations for task t1 and t3 from the nested role Clerk. Note that
we consider the Pool entity a functional unit, such as a department or an institution,
rather than an organisational role.

Fig. 3. Manual Tasks and Roles in BPMN

Grouping of Tasks
Grouping of activities does not affect the sequence flow. Groups can be used for docu-
mentation or analysis purposes. They can be defined by using the group artifact, lanes,
or multiple and looped tasks. Unlike lanes, groups do not map to roles or groups in the
context of rights management systems, but are used to define a group of activities and
assign a dedicated authorization constraint to this group. We consider multiple instance
tasks and looped tasks as a group with exactly one task, but an arbitrary number of task
instances. Therefore, the following Figure 4 shows BPMN elements that we consider
as a mechanism to define groups of tasks:

Fig. 4. Task Groups in BPMN

Authorization Constraint Artifact

Without an authorization constraint a group of tasks has no semantic in the sense of
conflicting tasks associated with it. In the context of conflicting tasks definition we
74 C. Wolter and A. Schaad

derive the authorization constraint from the textual annotation as a new entity. Text
annotations are a mechanism for a modeler to provide additional information for the
reader of a BPMN diagram. The authorization constraints contains the two values of
our formal authorization constraint definition, namely nu and mth :

Fig. 5. Allocation Constraint Artifact

A single allocation constraint can be associated with a group artifact defining a set
of (manual) tasks, a lane (i.e., a special kind of task group), and as a third option, an
allocation constraint can be added to a single manual task. This is necessary in the
case of multiple instances or loops. Because an organisational role is defined by a lane,
the complete set of authorization constraints for each lane is based on the assigned
constraints for this lane, nested lanes, and all constraints assigned to groups and single
manual tasks embedded within the corresponding lane.

3.2 Revisited Banking Constraints

To demonstrate the applicability of our approach we apply our proposed BPMN ex-
tension to the example banking workflow and model the discussed authorization con-
straints. The constrained workflow model is illustrated in Figure 6.
The role-based authorization constraint c1 is expressed by assigning the set of tasks
{t1 , t2 , t3 , t4 , t5 , t6 , t8 } to the role clerk. The second role-based authorization constraint
c2 is expressed by combining the tasks of the role clerk with the task t7 . The nesting
of the lane clerk within the lane manager expresses the role hierarchy requirement and
task authorization inheritance postulated in c2 and c4 .
The separation of duty requirements c3 and c4 are visualized by defining a set of
conflicting tasks {t3 , t4 } and {t7 , t8 } and by adding the related authorization constraint
for both groups. In the same way we expressed the binding of duty constraint c5 . The
separation of duty constraint c6 , limiting the executive power of a single clerk over the
whole workflow to five tasks, is directly assigned to the clerk lane.

4 Related Work
In the area of security constraint and requirement modeling most work concentrates
on the expression of application security and access control for their exposed services.
There exists little related work in the domain of specifying task-based authorization
constraints within the context of workflow models. This observation is supported by
research done by Aalst et al. in [1,2] outlining that existing modeling notations only
 Modeling of Task-Based Authorization Constraints in BPMN 75

Fig. 6. Constrained Banking Workflow

sparsely support the resource perspective, especially the Separation of Duty pattern
that is directly related to the expression of task-based authorization constraints within
process and workflow models. Therefore, most related work in the area of security
modeling can be found in the extension of UML-based notations:
Jürjens presented in [21] the UMLSec extension for UML to express security rel-
evant information within a system specification diagram. The focus of UMLSec lies
primarily on the modeling of communication-based security requirements for software
rather than on the modeling of authorization constraints for task-based access control
in workflow environments.
Dobmeier and Pernul defined an UML-based model for modeling attribute-based au-
thorization constraints. They provided an expressive fine-grained access control model
for accessing services in open systems, such as Web Services. Because their model lack
the specification of dependencies between service calls, it is not possible to express en-
tailment constraints for workflows, such as we follow in our task-based approach with
a direct relation to workflow tasks and their flow relation.
Basin et al. proposed SecureUML a model-driven security approach for process-
oriented system in [22]. They characterized a process by its possible states and specify
authorization constraints for allowed state transitions. Their security constraints are not
directly defined within a process model, but rather on potential states. Within their UML
constraint model a process is included as an abstract stereotype and the security spe-
cialist has to know all potential process states, while we provide an intuitive perspective
on the model and define authorization constraints in the model itself.
76 C. Wolter and A. Schaad

Chang et al. [23] proposed VTBAC, a visual business centric task-based security
specification language to express authorization constraints for hyperlink paradigm
based e-Business workflows. While VTBAC could be used to express authorization
constraints within the workflow model itself, it is not possible to express entailment
constraints, such as separation of duty or binding of duty.
In [24], Huang and Atluri presented SecureFlow, an implementation of their Work-
flow Authorization Model with a browser-based interface. Authorizations can be de-
fined for users, roles, and workflow tasks. In contrast to our worfklow model approach
they do not use a graph notation. Instead, tasks are selected from a list of tasks, thus
the flow relation between the tasks is getting lost resulting in a less intuitive approach
compared to ours.
Knorr and Stromer presented in [18] an approach for modeling separation of duty
constraints for Petri-Net-based workflow descriptions. They developed a modeling en-
vironment for defining an organisational model with roles and users, a workflow de-
scription as a Petri Net, and authorization constraints. Unlike our proposed approach,
the organisational model, the workflow model and the constraints were defined sepa-
rately in three different perspectives at the cost of transparency of dependencies be-
tween the different models. In addition, their Petri-Net notation is rudimentary and has
a weak visual expression.
One aspect of the European research project Serenity [25] is the definition of secu-
rity patterns for workflows and the development of security tools. The provision of a
graphical interface for security analysis and design, the use of formal verification meth-
ods, and the ability to handle complex workflows are desired properties. Unlike our
approach, their current focus lies on the specification of security pattern and constraints
for automatic business processes. In contrast, it seems the description of authorization
constraints for manual tasks is not a primary concern in Serenity.
Hoagland et al. developed LaSCO [8] a graph-based specification language of se-
curity policies. In LaSCO, a security policy is stated by specifying that if a system is
in a certain state, a specific access constraint must hold for that system. LaSCO poli-
cies are specified as expressions in logic and as directed graphs, giving a visual view
of the policy. A LaSCO specification can be automatically translated into executable
code that checks an invocation of a Java application with respect to a policy. LaSCO
can be used to define task authorizations in a graph-based notation. Nevertheless, the
application domain of the graphical notation is restricted to the specification of au-
thorization controls without considering any control flow related modeling aspects for
workflows.
There exist a broad area of business rules languages that define the behaviour of
processes within a company. Such rules can be divided into dispositive rules affect-
ing the design of processes, for instance according to compliance regulations, and
operative rules describing and steering the process flow itself. Nevertheless, business
rules are mainly applied in the context of automated business processes [26]. Their
practicability in the context of human-centric workflows needs some further
investigation.
 Modeling of Task-Based Authorization Constraints in BPMN 77

5 Conclusion

In this paper we presented a novel approach to describe authorization constraints for

manual tasks within the Business Process Modeling Notation. Our primary concern is
to find an user-centric approach to specify task-based authorization constraints within
the context of the related workflow model. Therefore, we propose a method to define
authorization constraints, such as role-task assignments, role hierarchies, separation of
duty and binding of duty constraints with a strong graphical notation language. By
starting with a formalized description of expressing such constraints, we added security
relevant semantics to the group and lane elements of BPMN and derived a new textual
artifact from the textual annotation element. We used example constraints from a bank-
ing workflow as a pragmatic approach to demonstrate the feasibility of our proposed
graphical extension. There exists several areas of potential future work, such as BPMN
model checking for consistency of authorization constraints, automatic generation of
access control policies, and modeling patterns for authorization constraints with tool
support.

5.1 Future Work

We consider this paper as a primer for future related work in three different areas:
As stated in Section 3 the verification of consistent authorization constraints is not
in the scope of this paper. As shown in our banking example authorization constraints
can be nested (cf. c3 and c5 ) potentially resulting in contradicting policies and deadlock
situation when these constraint are evaluated and applied to the task assignment at run-
time. In [9], Crampton already proposed an algorithm to conduct consistency checks
and reveal potential deadlock situations. We plan to further investigate this problem and
are going to propose an extended algorithm that can be applied to our definition of con-
flicting tasks and plan to use model checking languages such as Alloy [3] to provide
constraint verification and consistency at design time.
From the modeling perspective it is possible to develop a collection of task-based
authorization constraint patterns, such as they are commonly used for the control flow
perspective. Further we may apply our approach to sub-processes and more complex
workflows, e.g workflow with complex gateways, compensation, and cancellation ac-
tivities. It is also interesting to investigate to what degree delegation, revocation and
supervision constraints can be modeled within the workflow [27]. We also intend to
apply authorization constraints to other workflow modeling notations, such as XPDL
[28] and BPEL4People, to regain model exchangeability. From an usability perspective
we plan to apply a user-centric design approach based on prototype iteration to fur-
ther enhance the proposed notation extension by empirical studies considering end-user
feedback.
A third direction of future work would be to develop a prototype implementation
based on a model-driven approach [29] to derive machine readable authorization
policies. Therefore, we suggest to develop a model transformation from our BPMN
extension to XACML [30] or RBAC-WS-BPEL [10] to automatically derive task au-
thorization policy sets that can be deployed in an enterprise environment.
78 C. Wolter and A. Schaad

References

1. Russell, N., van der Aalst, W.M.P., ter Hofstede, A.H.M., Edmond, D.: Workflow Resource
Patterns: Identification, Representation and Tool Support. In: Pastor, Ó., Falcão e Cunha, J.
(eds.) CAiSE 2005. LNCS, vol. 3520, Springer, Heidelberg (2005)
2. Wohed, P., van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M., Russell, N.: On the
Suitability of BPMN for Business Process Modelling. In: Proceedings of the 4th International
Conference on Business Process Management (BPM) (2006)
3. Schaad, A., Lotz, V., Sohr, K.: A Model-checking Approach to Analysing Organisational
Controls in a Loan Origination Process. In: SACMAT ’06: Proceedings of the eleventh ACM
symposium on Access control models and technologies
4. Saltzer, J.H., Schroeder, M.D.: The Protection of Information in Computer Systems. In: 4th
ACM Symposium on Operating System Principles (1975)
5. Clark, D., Wilson, D.: A Comparison of Commercial and Military Security Policies. In: IEEE
Symposium on Security and Privacy (1987)
6. Nash, M., Poland, K.: Some Conundrums Concerning Separation of Duty. In: IEEE Sympo-
sium on Security and Privacy, Oakland, CA pp. 201-209 (1990)
7. Botha, R.A., Eloff, J.H.P.: Separation of duties for access control enforcement in workflow
environments (2001)
8. Hoagland, J.A., Pandey, R., Levitt, K.N.: Security Policy Specification Using a Graphical
Approach. Technical Report (1998)
9. Tan, K., Crampton, J., Gunter, C.: The consistency of task-based authorization constraints
in workflow systems. In: CSFW ’04: Proceedings of the 17th IEEE workshop on Computer
Security Foundations (2004)
10. Bertino, E., Crampton, J., Paci, F.: Access control and authorization constraints for WS-
BPEL. In: Proceedings of IEEE International Conference on Web Services (2006)
11. Kloppmann, M., Koenig, D., Leymann, F., Pfau, G., Rickayzen, A., von Riegen, C., Schmidt,
P., Trickovic, I.: WS-BPEL Extension for People - BPEL4People (2005)
12. Object Management Group: Business Process Modeling Notation Specification (2006),
http://www.bpmn.org
13. Stephen, A.: White. Using BPMN to Model a BPEL Process. BPTrends (2005)
14. Recker, J., Mendling, J.: On the translation between bpmn and bpel: Conceptual mismatch
between process modeling languages
15. Ahn, G., Sandhu, R.: Role-based authorization constraints specification. ACM Trans. Inf.
Syst. Secur. 3(4), 207–226 (2000)
16. Thomas, R.K., Sandhu, R.S.: Task-Based Authorization Controls (TBAC): A Family of Mod-
els for Active and Enterprise-Oriented Autorization Management. In: IFIP Workshop on
Database Security, pp. 166–181 (1997)
17. Bertino, E., Ferrari, E., Atluri, V.: The Specification and Enforcement of Authorization Con-
straints in Workflow Management Systems. ACM Transactions on Information and System
Security 2, 65–104 (1999)
18. Knorr, K., Stromer, H.: Modeling and Analyzing Separation of Duties in Workflow Environ-
ments. In: Sec ’01: Proceedings of the 16th international conference on Information security:
Trusted information, pp. 199–212 (2001)
19. Dobmeier, W., Pernuk, G.: Modellierung von Zugiffsrichtlinien für offene Systeme.
In: Tagungsband Fachgruppentreffen Entwicklungsmethoden für Informationssysteme und
deren Anwendung (EMISA ’06) (2006)
20. Kalnins, A., Vitolins, V.: Use of UML and Model Transformations for Workflow Process
Definitions. TECHNIKA 3 (2006)
 Modeling of Task-Based Authorization Constraints in BPMN 79

21. Jürjens, J.: UMLsec: Extending UML for Secure Systems Development. In: UML ’02: Pro-
ceedings of the 5th International Conference on The Unified Modeling Language, pp. 412–
425 (2002)
22. Basin, D., Doser, J., Lodderstedt, T.: Model Driven Security for Process-Oriented Systems.
In: SACMAT ’03: Proceedings of the eighth ACM symposium on Access control models and
technologies, pp. 100–109 (2003)
23. Chang, S.K., Polese, G., Cibelli, M., Thomas, R.: Visual Authorization Modeling in E-
commerce Applications. IEEE MultiMedia 10(1), 44–54 (2003)
24. Huang, W.-K., Atluri, V.: SecureFlow: A Secure Web-enabled Work ow Management Sys-
tem. In: Proceedings of the fourth ACM workshop on Role-based access control (1999)
25. Kostaki, P., Kokolakis, S., Pandolfo, C.: Serenity - System Engineering for Security & De-
pendability WP A2.D4.1 (2006), http://www.serenity-project.org
26. Iwaihara, M.: Access Control of XML Documents and Business Rule Processing for Ad-
vanced Information Exchange. In: Second International Conference on Informatics Research
for Development of Knowledge Society Infrastructure (ICKS’07), pp. 177–184 (2007)
27. Schaad, A.: An Extended Analysis of Delegating Obligations (2004)
28. Shapiro, R., Marin, R.N.M.: XML Process Definition Language Version 2.0. Workflow Man-
agement Coalition (2005)
29. Kleppe, A., Warmer, J., Bast, W.: MDA Explained: The Model Driven Architecture: Practice
and Promise. Addison Wesley, Reading (2003)
30. Moses, T.: eXtensible Access Control Markup Language Version 2.0. OASIS Standard
(2005)