An Authorization and Access Control Model
for Workflow
Sodki Chaari
1
, Chokri Ben Amar
1
, Frederique Biennier
2
, Joel Favrel
2
1
Ecole Nationale d’Ingénieurs de Sfax, TUNISIE
2
Institut National des Sciences Appliquées de Lyon, FRANCE
Abstract. A workflow is a coordinated arrangement of related tasks in an
automated process, the systematic execution of which, ultimately achieves
some goal. Workflow Management Systems (WFMSs) are becoming very
popular and are being used to support many of the day to day workflows in
large organizations. Security is an essential and fundamental part of workflows,
the WFMS has to manage and execute the workflows in a secure way. Security,
in a workflow context, involves the implementation of access control security
mechanisms to ensure that tasks are performed by authorized subjects only. In
this paper we propose a workflow authorization model capable of specifying
authorization in such a way that subjects gain access to required objects only
during the execution of the task. We build our model over the well known
RBAC framework, and that in addition extends RBAC by including new rules
in order to be adaptable with workflow context.
1 Introduction
Workflow (or workflow process) is the computerised facilitation or automation of a
business process involving the coordinated execution of multiple tasks performed by
different processing entities. A workflow can be abstracted as a network with task
(i.e., activity) nodes and flows (i.e., transitions between task nodes). A task defines a
logical unit of work in a workflow that related to a specific commitment, adding value
to a product or service of an organization. A workflow also defines task dependencies
(transitions) that specify how tasks in a workflow are coordinated for execution in a
semantically correct order [5]. Workflow Management Systems (WFMS) are used to
coordinate and streamline business process in numerous applications domains
including office automation, banking, healthcare, telecommunications and
manufacturing. WFMS are used for critical and strategic applications, they often use
heterogeneous and distributed hardware and software systems to execute a given
workflow. This gives rise to decentralized security policies and mechanisms that need
to be managed. Since security is an essential and fundamental part of workflows, the
WFMS has to manage and execute the workflows in a secure way. The security
service of authorization (access control) is of primary relevance in the context of
workflows. Access control security mechanisms need to ensure that task are
Chaari S., Ben Amar C., Biennier F. and Favrel J. (2004).
An Authorization and Access Control Model for Workflow.
In Proceedings of the 1st International Workshop on Computer Supported Activity Coordination, pages 31-40
DOI: 10.5220/0002663400310040
Copyright
c
 SciTePress

performed by authorized subjects only. An appropriate authorization model for
workflows must provide the notion of just-in-time authorization. It enables the
granting, usage tracking and revoking of authorization to be automated and
coordinated with the progression of various tasks. Otherwise, a subject may process
authorization for time periods longer than required, which may compromise security.
The model has to prevent any unauthorized modification of data and to enforce the
legitimate pattern of operations in data accesses by the subject(s) for executing a task.
In this paper, we propose an authorization and access control model that is able to
specify authorization in such a way that subject gain access to required object during
the execution of the task. We build our models over the well-known role-based access
control (RBAC) framework. In our authorization model we try to inject RBAC into an
existing workflow system. We extend the RBAC model by adding some new rules
and definitions to meet our needs and to be able to deal with the workflow context. In
the rest of the paper, section 2 describes some related work, section 3 describes the
basic elements of the model, section 4 presents the global workflow authorization
model and finally section 5 discusses the conclusions and some perspectives.
2 Related work
Security is a critical and essential part of workflows, and it has become an important
topic in the research community as well as the industry especially authorization and
access control have been widely discussed and many methods have been proposed to
model the authorization and access control properties. Many researchers are working
on workflow standards. The Workflow Management Coalition (WfMC) is a non
profit organization that focuses on the advancement of workflow management
technology in industry. WfMC summarizes a number of security services [9] for a
conceptual workflow model that includes authentication, authorization, access
control, data privacy, audit…
For workflow security, previous research has been done mainly on several aspects,
which include task assignment constraints, inter-workflow security, and multilevel
secure workflow systems [7]. Using task assignment constraints, assignment methods
for the workflow systems are specified in terms of constraints on the permissible
assignments of users to tasks and roles. Because the role-based model is a natural
choice for implementing security in workflow systems, most of the discussions are
based on that.
Bertino, Ferrari, and Atluri [2] propose an interesting and powerful constraint
based security model also based on logic predicates, that allows for somewhat
different expressivity than the one presented here. Predicates in constraint expressions
include predicates over a role graph and predicates over history.
The Workflow Authorization Model (WAM) [1] presents a conceptual, logical and
execution model which concentrates on the enforcement of authorization flow in task
dependency and transaction processing by using Petri Nets (PN). The workflow
designer defines the static parameters of the authorization using an Authorization
Template (AT) during the build-time of the workflow. When the task starts execution,
the AT is used to derive the actual authorization. In a Multilevel Secure (MLS)
workflow environment, tasks are assigned to different security levels.
32

WAM discusses the synchronization of authorization flow with the workflow and
specification of temporal constraints in a static approach, it is not sufficient to support
workflow security. This is because workflows need a more dynamic approach to
synchronize the flow of authorizations during the workflow execution. For example,
the privileges will be granted/revoked to/from the users according to the events
generated during the task execution. WAM only concentrates on the authorization in a
task’s state and primitives.
Previous studies focus either on Inter-workflow security is concerned with the
security of the communication and cooperation of autonomous workflow systems,
running at different units of the same organizations or at different organizations.
Some related work can be found in [8].
3 Basic elements of the model
This section describes our basis elements for the access control that uses the roles like
a means to classify several permissions under the same name. We give the precise
definition of a role and of other entities that form the basis of a Role Based Access
Control (RBAC) model that is presented in this work.
3.1 Permissions
The security of a computer system in an access control model generally accepts that
permission describes an approval of a particular access right to an object.
Definition 1
A permission pr is a pair
()
Objtr, where tr is the transaction that operates on the set
of objects Obj.
Let entities namely, sets of permissions (P), transactions (Tr) and objects (Obj)
respectively, be:
{
}
,...,
21
prpr
P =
the set of permissions,
{
}
,...,
21
trtr
Tr
=
the set of
transactions and
{
}
objects ofset theis ,...,
21
objobj
Obj
= .
The relationships among these entities are the following:
•
TrPTrP →: , gives the transaction associated with the given permission.
•
2
:
Obj
PObjP → , gives the set of objects associated with the given permission.
3.2 Roles
A role is a job function or job title within the organization with some associated
semantics regarding the authority and responsibility [6]. A role is formed by the
grouping of permission according to logical and functional needs.
33

Definition 2
A role r is a pair
()
rpsetrname, where rname is the role name, and rpset is the set of
role permissions.
Let
{}
,...,
11
rr
R
= denote the set of roles we express the mapping between roles and
permissions with:
2
:
P
RPR → , gives the set of permissions for the given role r.
3.2.1 Role-user authorizations
The permissions associated with a role are administered as a single unit such that
authorization to access a role puts all the role’s permissions at the disposal of an
authorised user and thus confers access rights grouped in the role to the user.
Definition 3
A user authorization list UAL is of the form , where is the user identifier.
Let
{}
,...,
11
rr
U
= denote the set of users identifiers then a user authorization list can
also be defined as the mapping function between roles and users:
•
2
:
U
RUR → , which enumerates the users associates with the given role r.
3.2.2 Role hierarchy
Tracking the distribution of such permissions among roles can become a very
complex task. In order to simplify administration and analysis of permission
distribution, it is important to have some means for organising the various roles. Such
structures of roles, defined by [3] as role hierarchies, are often discussed alongside
roles.
Definition 4
An inheritance relation
→ is defined between two roles and , denoted if
and only if
()
(
)
r
PR
r
PR
ji
⊆
.
In this relation role is seen as a senior role, whereas is a junior role. In addition to
directly assigned permissions role indirectly contains the permissions of the junior
role . Thus, the function
()
rPR returns not only all direct permissions of the role, but
also all indirectly contained (inherited) permissions.
3.2.3 Role graph
The hierarchies of roles with inheritance relations among them are combined to form
a directed acyclic graph, such that with the roles as nodes for a given directed edge.
Definition 5
A role graph is an inheritance relation on the set of roles, defined as
(
)
→Χ= RRRG
.
The nodes are the roles from the set R, and the edges are defined with
→ relation.
r
j
r
j
r
i
u
i
r
i
r
i
r
j
rr
ji
→
[
]
uuu
n
,...,
11
34

3.3 Authorization State
While assembly the described elements until now we can form an authorization state
that can be generated in the organization, formed by the following elements:
(
)
RoleGraphlistionauthorizatuserrolesUsers ,,,
Therefore if a user belongs to the list of the users allowed for the role, or he has a
senior role according to the graph of the roles, then he can execute the permissions
that constitute the role and manipulate the different accessible objects with these
permissions. This authorization can be judged with static. The name static comes
from the fact that these authorization do not depend on the execution of any tasks,
once it is defined by the system administrator it cannot be modified later taking into
account the evolution of the system. Seen the dynamic behaviour of the workflow,
this type of authorization cannot be used in the model of security that must be
proposed. Indeed, for the workflow, we must insure that the authorization is only
guaranteed during the execution of a task and revoked at the end of.
The roles authorised to a user have to be activated, so that he can use the associated
permissions. An active role set is associated with each user, defined as the following
mapping function:
2
:
R
UARS → , which gives the set of roles active for user.
The activation of the roles adds a dynamic character to the above authorization
state, because the user is obliged to activate the adequate role in order to use the
permissions associated with this role and we can verify the nature of the role activated
as well as the date of the activation. This date is going to be very useful since we will
compare it with authorized time for the execution of a task in the workflow.
3.4 Access Granting Rules
It is necessary to make some extensions to respond to the context of the workflow.
The rules listed below can be assimilated to a gateway between the static behaviour of
the role based access control and the dynamic one of the workflow.
Firstly, a user has to activate one or more roles authorised to him.
Rule 1
A user can activate a role if and only if the user is authorised to this role:
()
(
)
ruactivatecanrURuRrUu ,_:, ⇒∈∈∈∀
Just when the roles are activated, the user has the right to make all permissions that
are associated with the activated role, including those that are inherited.
Rule 2
A user can exercise permission if and only if the permission is an effective permission
in the activated roles:
:, PpUu ∈∈∀
()
(
)
(
)
puexercisecanrPRpuARSr ,_: ⇒∈∈∃
Since the permission is defined as the right to execute a transaction on one or several
specific objects, the last rule can be rewritten like follows:
35

Rule 3
A user can execute a transaction on an object if and only if a role exists on the set of
the activated roles, and he possesses the permission that allows the execution of the
transaction on this object:
(
)
(
)
(
)()
()
objtruexecutecan
pObjPobjpTrPtrrPRpuARSrObjobjTrtrUu
,,_
:,,
⇒
∈∧∈∈∃∧∈∃∈∈∈∀
4 Authorization model for workflow
The different elements presented in the previous section have been specified with
respect to users, roles and permissions, and granting access rights to users. This
section contains the global description of the authorization model of the workflow.
We are going to model the previous elements so that we can use them in the workflow
context and present the rest of element that constitute our model.
4.1 Workflow model
Formally, a workflow is represented as a partially ordered set of tasks that is
coordinated by task dependencies [1]:
Definition 6
A workflow W can be defined as a directed graph whose nodes are the tasks in the
workflow
{}
twtwtw
W
n
,...,
21
=
and edges are the task dependencies
twtw
j
x
i
⎯→⎯ ,
where,
tw
i
,
tw
j
∈W and x denotes the type of dependency.
Each task can be defined as a partially ordered set or totally of transactions
{}
trtrtr
set
Tr
n
i
,...,_
21
= that involve manipulation of objects [4].
Let
{
}
,...,
21
objobj
Obj = the set of the objects manipulated by the tasks of the
workflow and
{
}
,...,
21
objtobjt
ObjT =
the set of objects types. We define the mapping
function:
ObjTObjF →: , which associate a type to the object.
We use to denote the set of objects of type
objt
i
4.1.1 Workflow task
Definition 7
A workflow task is defined as:
where:
tw
set
Tr
i
i
in performed be toons transactiofset theis _ ,
ObjT
ObjT
IN
i
⊆
is the set of
object types allowed as inputs,
ObjT
ObjT
OUT
i
⊆ is the set of object types expected
as outputs, is the time interval during which
tw
i
must be executed.
⎥
⎦
⎤
⎢
⎣
⎡
TT
i
i
sup
,
inf
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
⎥
⎦
⎤
⎢
⎣
⎡
TT
execplan
ObjT
OUT
ObjT
IN
Trens
i
i
ii
i
sup
,
inf
,_,,,
_
tw
i
O
objt
i
36

Accordingly, we introduce the following mapping functions:
•
2
:
Tr
WTrW →
, gives the transactions in the given task.
•
2
:
Objt
WTypeW → , gives the set of object types that can be processed in the
given task.
4.1.2 Task instance
A task is a logical and abstract unit that assembly the particularities of an activity to
achieve. Really, at the run time of a workflow, tasks instances are generated for all
tasks that constitute the workflow. A task instance is a representative of the task. Any
task may have several instances.
Definition 8
We can define a task instance as follows:
where:
TRANS
i
is the set of the transactions accomplished during the execution of the task,
such that toobjectsinput ofset theis
twIN
ii
,
OUT
i
the set
of output objects from
tw
i
such that ,exec_plan specifies
the order of transactions execution in the task and is the
time interval during which has been executed.
We define a function:
2
:
_ INSTT
WWInst → that gives the set of task instances.
4.2 Authorization generator (AG)
The major problem of a workflow is that the times of the beginning and the end of
execution of one task cannot be predefined, they depend on the evolution state of the
workflow. To solve this problem, it’s important that the authorization must be
assigned or revoked by the task according to its constraints. Therefore the task must
be able to know when the authorization can be affected and when it must be revoked.
The AG is the mean that allowed us to concretize this idea. It equipped the tasks by a
certain "kind of intelligence" that made them able to manage their own authorizations.
Definition 9:
Given a task
tw
i
, an authorization generator
(
)
tw
AG
i
is defined as follows:
()
[
]
⎟
⎠
⎞
⎜
⎝
⎛
TT
objt
type
r
p
i
i
i
i
i
sup
,
inf
,_,,,
where:
executingfor enabled be to role of permission thedenotes
r
p
i
i
transaction in the task:
(
)
()
tw
TrW
p
TrP
i
i
∈ ,
(
)
_,
objt
type
i
is the function that verifies if the object is of type
∈
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
⎥
⎦
⎤
⎢
⎣
⎡
T
f
T
s
planexec
OUTIN
TRANS
i
i
ii
i
,,_,,,
()
⎭
⎬
⎫
⎩
⎨
⎧
∈∈=
Obj
IN
xFOx
IN
i
i
()
⎭
⎬
⎫
⎩
⎨
⎧
∈∈=
Obj
OUT
xFOx
OUT
i
i
⎥
⎦
⎤
⎢
⎣
⎡
T
f
T
s
i
i
,
⎥
⎦
⎤
⎢
⎣
⎡
TT
i
i
sup
,
inf
tw
i
37

objt
i
(objects able to reach the task), and is the time interval during
which the task must be executed.
The authorization generators are attached to the tasks in a workflow. A new
authorization is generated on a specific object if the type of this object is the same that
the one in the function type of the generator. A task can have more that one generator.
An (AG) gives reference as to what permissions of which roles can be used during
execution of a task. When a task starts the permissions of roles defined in a generator
are enabled for the objects of the indicated type. Users that can use these permissions
are not defined in an (AG), since the user’s access to permissions is controlled via
roles. Users must activate necessary roles in order to execute transactions of a task.
4.3 Authorization state
Every time that a transaction is programmed by the planner of the task and if there is
presence of an object then an authorization is generated by the (AG).
Definition 10
An authorization is represented by:
This authorization indicates that the permission p of the role r can be used with the
object obj in the task instance task_ins during the interval of time .The set
of executors represent user that have already used the permission.
An Authorization permits to affect a certain permission belonging to some role to a
user in order to use it in a task instance. Parameters of an authorization are derived
from the task authorization generator.
Definition 11
Every generated authorization is added to an authorization base (AB):
{}
,...,
21
AA
AB =
the set of the authorization generated by the (AG).
For each authorization we also define the following mapping functions:
•
2
:_
AB
WInstABWInst → , gives the set of authorization generated for a task
instance.
•
()
PABAPAB →: , gives the permission enabled with authorization A.
•
()
RABARAB →: , gives role name for which the permission is enabled.
•
()
ObjABAOAB →: , gives the object on which the action authorized.
•
(
)
2
:
U
ABAExecutors → , gives users that finally used the enabled permission.
We can formulate the authorization rule that is adapted from the Authorization
Derivation Rule for WAM [1] that was briefly discussed earlier. This rule will specify
the granting and revoking of authorizations.
⎥
⎦
⎤
⎢
⎣
⎡
TT
i
i
sup
,
inf
⎥
⎦
⎤
⎢
⎣
⎡
T
e
T
b
,
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
⎥
⎦
⎤
⎢
⎣
⎡
=
executors
T
e
T
b
instaskobjrpA ,,,_,,,
38

Definition 12 [Authorization Derivation Rules]
Given an authorization generator:
An authorization is derived as
follows: Suppose that the object O arrives to a transaction, chosen by the planner of a
task instance
tw
i
, to the instant
T
a
i
(arrival time)
Grant Rule:
if (
O
objt
O
i
∈
()
(
)
trueis ,O
objt
type
i
and
T
a
i
≤
T
i
sup
) then
O
obj
i
←
;
()
AG
p
P
i
i
← ;
r
i
←
(
)
GA
r
i
;
T
e
i
←
T
i
sup
;
if (
TT
a
i
i
inf
≤
) then
TT
b
i
i
inf
←
;
else
T
a
T
b
ii
←
;
Revoke Rule:
Suppose that the transaction ends to the instant
T
f
i
(final time)
if (
T
f
i
≤
T
i
sup
) then
T
e
i
←
T
f
i
;
Some new properties and rule are added to this algorithm so that it can adjust with our
security model. When an authorization is initially generated the set of executors is
empty, but fills in whenever an enabled permission is being used.
Property 1
A permission enabled in an authorization token can be used only by a user that is
authorised to the role defined in the token, or to the role senior to it.
()
(
)
(
)
()()()
rURurARAB
RrARABURuAExecutorsuABA
∈∧→
∈∃∨∈∈∀∈∀ thatsuchthen,
Property 2
A permission is an enabled permission of role r on object obj if there exists a valid
authorization token within some task instance that authorises the permission of the
role to be used on the object.
()
(
)
(
)
() ( )
() () ()
AOABobjARABrAPABp
instaskABAWinstAtwWInstinstaskWtw
objrPREnabledppObjobjrPRpRr
∈∧∈∧∈
∈∃∈∃∈∃
⇒∈∈∀∈∀∈∀
that such__,_,
,_then,,
Rule 4
A user can use a permission of the user’s active role on the specific object only if the
permission is enabled for this role.
(
)()
objpuexercisecanobjrPREnabledpObjobjARSrUu ,,_,_,, ⇒∈∈∀∈∀∈∀
()
()
[
]
⎟
⎠
⎞
⎜
⎝
⎛
=
TT
objt
type
r
p
tw
GA
i
i
i
i
i
i
sup
,
inf
,_,,,
[
]
⎟
⎠
⎞
⎜
⎝
⎛
=
exécutors
T
e
T
b
instask
obj
r
p
A
i
i
i
i
i
i
ii
,,,
_
,,,
39

5 Conclusion
In this paper, we develop an authorization and access control mechanism to support
workflow applications that is capable of synchronizing the authorization flow with the
workflow. Several important aspects, such as task, role, permission, object,
authorization generator, authorization base and authorization were introduced and
considered in the model presented. We defined a model that mixes concepts of
RBAC and Workflow with a different expressive power than previous models, which
allow simpler specification of real life business processes.
The work presented in this paper can be extended along several directions. First,
future work should be focused the proving of integrity and completeness of the model
and on the improvement of the model. Second, incorporating issues related to the
access control requirements for inter-organizational workflow into these models is
also a challenging research goal.
References
1. Atluri, V., Huang, W.-K., Bertino, E.: An Execution Model for Multilevel Secure
Workflows, in Proceedings of the 11th IFIP Working Conference on Database Security
(1997) 151-165
2. Bertino, E., Ferrari, E., Atluri, V.: An Approach for the Specification and Enforcement of
Authorization Constraints in Workflow Management Systems, ACM Transactions on
Information Systems Security, Vol 1, No 1 (1999)
3. Ferraiolo David, F., Richard Kuhn, D., Cugini, J.: A. Role Based Access Control: Features
and Motivations In Proceedings of Computer Security Applications Conference (1995)
4. Georgakopoulos, D., Hornick, M., Sheth, A.: An Overview of Workflow Management:
From Process Modelling to Workflow Automation Infrastructure. Distributed and Parallel
Databases (1995) 119 –153
5. Krishnakumar, N., Sheth, A.: Managing Heterogeneous Multi-system Tasks to Support
Enterprise-wide Operations. The Journal on Distributed and Parallel Database Systems, 3
(2) (1995)
6. Sandhu, R.: Engineering Authority and Trust in Cyberspace: The OM-AM and RBAC Way.
Fifth ACM Workshop on RBAC (2000) 111 – 119
7. Shengli, W., Zongwei L.: Authorization and Access Control of Application Data in
Workflow Systems, Journal of Intelligent Information Systems, 18 (1), Kluwer Academic
Publishers (2002) 71-94
8. Valia, R., Al-Salqan, Y.: Secure workflow environment. In: Sixth IEEE Workshops on
Enabling Technologies: Infrastructure for Collaborative Enterprises (1998) 269 – 276
9. Workflow Management Coalition (WfMC): Workflow Security Considerations White
Paper, Document Number WFMC-TC- 1019, Document Status - Issue 1.0 (2001)
40