See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/47397222

Design of an Integrated Role-Based Access Control Infrastructure for Adaptive

Workflow Systems

Article  in  Journal of Computing and Information Technology · December 2003

DOI: 10.2498/cit.2003.04.04 · Source: OAI

CITATIONS READS

5 168

1 author:

Nanjangud Narendra
Ericsson, Bangalore, India
132 PUBLICATIONS   1,456 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Data Graph, Information Graph, Knowledge Graph and Wisdom Graph based Semantics Modeling, Synthesis and Analysis Approach View project

http://www.yucongduan.org/UMLabstraction/main/index.do View project

All content following this page was uploaded by Nanjangud Narendra on 20 May 2014.

The user has requested enhancement of the downloaded file.

Journal of Computing and Information Technology - CIT 11, 2003, 4, 293–308 293

Design of an Integrated Role-Based

Access Control Infrastructure
for Adaptive Workflow Systems

Nanjangud C. Narendra
IBM Software Labs, Bangalore, India

With increasing numbers of organizations automating a 3-tier adaptive workflow architecture (Naren-
their business processes by using workflow systems, dra, 2000), we define a similar 3-tier RBAC in-
security aspects of workflow systems has become a
heavily researched area. Also, most workflow processes frastructure that mirrors our adaptive workflow
nowadays need to be adaptive, i.e., constantly chang- architecture. We also describe the mappings be-
ing, to meet changing business conditions. However, tween them, and we show how this mapping can
little attention has been paid to integrating Security and be used to manage organizational RBAC con-
Adaptive Workflow. In this paper, we investigate this
important research topic, with emphasis on Role-Based straints when the workflows are being adapted
Access Control (RBAC) in Adaptive Workflow. Based continuously. In fact, we believe that ours is the
on our earlier work on a 3-tier adaptive workflow archi- first attempt at integrating Security and Adap-
tecture, we present the design of a similar 3-tier RBAC
infrastructure, and we show that it conceptually mirrors tive Workflow.
our adaptive workflow architecture. We also describe the
mappings between them, and we show how this mapping This paper is organized as follows. In the next
can be used to manage organizational RBAC constraints Section, we provide an introduction to Work-
when the workflows are being adapted continuously. We flow and Adaptive Workflow, where we present
illustrate our ideas throughout the paper with a simple
yet non-trivial example. our 3-tier adaptive workflow architecture. In
Section 3, we present the latest research re-
Keywords: security, role based access control, adaptive sults in Secure Workflow on which our work
workflow. is based. The main result of this paper, i.e.,
our 3-tier RBAC infrastructure, is presented in
Section 4. Section 5 concludes the paper with
1. Introduction directions for future research. We also illustrate
our ideas throughout the paper using, a simple
yet non-trivial example.
Increasing numbers of organizations are au-
tomating their business processes by installing
and using workflow systems. This has raised
several research issues regarding security as- 2. Workflow Preliminaries
pects of these workflow systems. Hence Se-
cure Workflow has become a fertile research
area Atluri, et.al., 2000; Bertino, et.al., 1999; 2.1. Introduction to Workflow
Cholewka, et.al,. 2000; Nyanchama and Os-
born, 1999). However, most workflow pro- Our basic workflow model is based on the
cesses nowadays need to be adaptive, i.e. con- graph-theoretic notions in the OpenPM (Shan,
stantly changing, to meet changing business et.al., 1997) process model. We assume that
conditions. In this paper, we address this impor- each workflow instance is a directed graph W
tant topic, with emphasis on Role-Based Access = <N,E>, where N is the set of nodes and E
Control (RBAC). Based on our earlier work on is the set of edges. Each edge e in E is a tuple
294 Design of an Integrated Role-Based Access Control

of the form < nbegin , nend >, where the edge is rect the flow of control to specific work nodes
directed from nbegin to nend . or route nodes.
We first define two unique nodes — START For each work node, we assume the existence
and END nodes; for each workflow, there will of specific data structures that capture the data
be only one of each kind. A START node has no flow information with the node. In other words,
predecessor, and an END node has no successor. each work node is assumed to perform certain
operations on data and artifacts (e.g., complete
The workflow graph is assumed to obey two
a form, collate and summarize data, etc.). These
simple conditions:
operations, together with the data flow, define
Every node in the graph is reachable from the flow of control throughout the workflow;
the START node, i.e., there is a path from the and this is a consequence of the workflow de-
START node to every other node in the graph sign.
The END node is reachable from every node In our workflow model, edges are of four kinds
in the graph, i.e., there is a path from the node — forward edge, loop edge, soft-sync edge and
to the END node strict-sync edge. Forward edges depict the nor-
mal workflow execution, which is in a forward
Nodes are of two kinds — work nodes and route direction. Loop edges are backward pointing
nodes. Work nodes are nodes that actually per- edges that are used to depict the repeated exe-
form the activities in the workflow. Route nodes cution of loops.
are nodes whose only function is to evaluate
rules (i.e., boolean conditions) and, depending The “sync” edges are quite different from for-
on the result of the evaluation, these nodes di- ward edges, in that these edges are used to

C
Route Node

E
B
Forward
Edge D

Soft-Sync
Edge
START A
H
Strict-Sync
Edge

F
G

Work Node

END

Loop Edge

Fig. 1. Workflow Graph.

Design of an Integrated Role-Based Access Control 295

support synchronizations of tasks from differ- 2.2. Adaptive Workflow

ent parallel branches of a loop. There are two
types: In (Narendra, 2000), we developed a 3-tier ap-
proach to adaptive workflow management. Es-
A “soft-sync” edge from n1 to n2 is used to sentially, we recognized that a workflow needs
signify a “delay dependency” between n1 and to have a schema, i.e., a basic definition of its
n2 , i.e., n2 can only be executed if n1 is ei- structure before it can be instantiated and ex-
ther completed or cannot be triggered any more. ecuted. Moreover, since workflow is typically
This type of synchronization does not require executed in business organizations, it is essen-
successful completion of n1 . tial that it meet certain business goals. There-
A “strict-sync” edge from n1 to n2 requires fore we see that business goals (essentially aris-
that n1 successfully complete before n2 exe- ing out of planning) lead to workflow schema
cutes. being defined, out of which a workflow in-
stance is generated for execution.
Clearly, the use of such edges must satisfy some
Hence we see that workflow adaptivity is basi-
conditions:
cally of three types:
Redundant control flow dependencies be- Adaptivity at instance level: here, only the
tween nodes and loops should be avoided workflow instances need to be modified, per-
A sync edge may not connect a node from haps to make them more efficient, or to make
inside a loop body with a node not contained them easier to execute, etc. The modules that
within that loop implement this are:

An example of workflow graph that illustrates
Basic Workflow Model — stores the instances
of our workflow model
all these definitions, is shown in Figure 1. The
arcs depict the flow of the data and artifacts
Workflow Change Model — stores the con-
from the START to the END node. structs for specifying dynamic workflow
changes
We can also define states for each node, de-
pending on where it is during the workflow ex-
Workflow Change Verifier — performs the
ecution. Hence we define the following states syntactic and semantic checking for work-
for nodes: NOT-ACTIVATED, ACTIVATED, flow adaptation
DONE, FAILED, SUSPENDED.
Workflow–Schema Interface Manager — in-
terface module that interacts with the Schema
The definition of these states naturally leads to
Layer
the conclusion that we can define the state tran-
sition diagram that each node has to obey. In- Adaptivity at schema level: here, the work-
deed, this means that the state of every node in flow schema will need to be modified – this
the workflow instance is governed by the tran- would arise if certain “ways of doing things”
sition rules in the state transition diagram. This change, and will necessitate radical modifica-
diagram is given in Figure 2. tions to all the workflow instances of the schema
in question. The modules that implement this
are:

Schema Handler — creates, versions and
ACTIVATED
CO
MM
stores the workflow schema
IT

Schema Migration Manager — handles mi-
T

DONE
AR

SUSPEND

RESUME
ST

gration of workflow instances between sche-

mas, and interfaces with the Schema Handler
NOT_ACTIVATED
Schema-Planning Interface Manager — in-
FAILED terface module that interacts with the Plan-
SUSPENDED
ning Layer
Adaptivity at planning/goal level: here,
Fig. 2. State Transition Diagram. the goals may themselves have to be modified
296 Design of an Integrated Role-Based Access Control

in response to changing environmental condi- either fully or partially — the goals that
tions – this could cause radical changes in the he/she has specified.
schema themselves, which could cause disrup-
tive changes in the workflow instances. The
Workflow Design Module — with this mod-
modules that implement this are: ule, and with the goal and workflow informa-
tion from the Goal Specification Module and

Organizational Workflow Repository — or- the Organizational Workflow Repository, the
ganization-wide repository of all workflow workflow designer can design the workflow
processes stored into the system; stores the
schema. He/she will then check it into the
workflow schemas and their instances, and
Organizational Workflow Repository. The
also stores the goals that led to the creation
of the workflow in the first place. schema will be transferred into the Schema
Handler via the Schema-Plannng Interface

Goal Specification Module — through this Manager where it will be appropriately ver-
module, the workflow designer first enters sioned and stored. The appropriate version
the goals that the workflow has to satisfy. number is then communicated to the user.
He/she can then look into the Organiza-
tional Workflow Repository, for reusing any The architecture is pictorially depicted in Figure
workflows from the past that can satisfy — 3.

User
s

PLANNING
WF Goal LAYER
Design Specification
Module Module WF
Repository

Schema - Planning Interface Manager

SCHEMA
Schema LAYER
Migration Schema
Manager Handler

Workflow - Schema Interface Manager

Workflow INSTANCE
Change LAYER
Verifier Basic Workflow
Workflow Change Model
Model

Fig. 3. Three-Tier Adaptive Workflow Architecture.

Design of an Integrated Role-Based Access Control 297

3. Role-Based Access Control (RBAC) in

Workflow RBAC3

3.1. Preliminaries

The most well-known approach towards secu-

rity administration has been the Role-Based RBAC1 RBAC2
Access Control (RBAC) model (Sandhu and
Samarati, 1994). This model allocates access
rights to users based on the Roles that they per-
form in the organization; these access rights are
also called “privileges”. Roles can also be orga-
nized in a hierarchy — typically a partial order. RBAC0

In this hierarchy, Roles at higher levels are as-

sumed to “inherit” the access rights of Roles at
lower levels in the hierarchy, in addition to the Fig. 4. RBAC Lattice.
access rights that they already possess.
In addition to this hierarchy, constraints can The notion of “direct” privileges (privileges
also be defined on how these access rights are that are owned solely by the Role) and “inher-
granted to particular Roles. Some of the most ited” privileges (privileges owned by Roles that
common constraints are Separation of Duty con- are junior to the Role in question)
straints, of which there are two types:
Algorithms for Role management, i.e., Role
Static Separation of Duty (SSOD) — these addition & Role deletion, and addition/deletion
constraints impose static restrictions such as /modification of privileges associated with a
“the role R cannot have access rights A1 and Role
A2 simultaneously”
The ideas of the conflicts that may arise in
Dynamic Separation of Duty (DSOD) —
this model and how they are handled:
these constraints impose dynamic restrictions
such as “if role R1 has executed task T1, then
Role-role conflicts — assigning two conflict-
R1 cannot execute task T2” ing Roles to a user
In other words, SSOD constraints can be eval-
Privilege-privilege conflicts — assigning two
uated without executing the workflow, whereas conflicting privileges to a Role
DSOD constraints evaluation can only be per-
formed at run time.
User-role assignment conflicts — assigning
a Role to a user who is not allowed to play
Hence in (Sandhu and Samarati, 1994), the that role
RBAC model has itself been modeled as a par-
tial order lattice depicted in Figure 4:
Role-privilege assignment conflicts — as-
signing a privilege to the Role which is not

RBAC0 — the basic RBAC model allowed to access that privilege

RBAC1 — RBAC0 with role hierarchies A sample Role Graph is presented in Figure

RBAC2 — RBAC0 with constraints 5. For the sake of completeness, every Role
Graph has two optional “dummy” roles, Max-

RBAC3 — combination of all of the above Role and MinRole, that are the senior and ju-
An RBAC3-compliant version of RBAC has nior, respectively, of all Roles. Numbers next to
been presented in (Nyanchama and Osborn, each role are the direct privileges of that Role.
1999), which also presents a 3-tier RBAC model, For example: for VP1, the direct privileges
consisting of User-Group assignments, User- are f9,10g, whereas the inherited privileges are
Role assignments and Role-Privilege assign- f1,2,3,4,5,6g, which consist of the direct privi-
ments. Unique features of this model are the leges of all Roles reporting directly or indirectly
following: to VP1.
298 Design of an Integrated Role-Based Access Control

MaxRole

VP1 {9,10} VP2{11}

L1 {3,4} L2 {4,5} L3 {5,6} L4 {7,8}

Employee1 Employee2
{1} {2}

MinRole

Fig. 5. Role Graph.

The following algorithms for Role management Privilege Deletion — a privilege is deleted
have been provided in (Nyanchama and Osborn, from a Role
1999): Edge Insertion — a new reporting relation-
Role Addition with only direct privileges — ship between a Role and one of its Senior Roles
a Role is added to the Role Graph along with its is added
direct privileges only Edge Deletion — a reporting relationship
between a Role and one of its Senior Roles is
Role Addition with inherited privileges — a deleted.
Role is added to the Role Graph along with its
direct and inherited privileges All Addition algorithms also contain steps for
checking for the 4 types of conflicts described
Role Deletion — a Role is deleted from the above, and will abort with an error message
Role Graph; this would also involve either dele- in case a conflict is detected. The algorithms
tion or re-allocation of the direct privileges as- also incorporate mechanisms for detecting cy-
sociated with the Role cles in the Role Graph, in which case they will
abort with an error message. For details, please
Privilege Addition — a privilege is added to see the original paper (Nyanchama and Osborn,
a Role 1999).
Design of an Integrated Role-Based Access Control 299

Please note that “negative authorizations” (for Munawer, 1997); however, this issue is out of
example, as specified in Damianou, et.al., 2001), the scope of this paper.
viz., that a Role cannot access a particular priv- A very good overall introduction to security is-
ilege, are implicitly incorporated into the Role sues in workflow can be obtained from (Atluri,
Graph by simply ensuring that the privilege in 2002).
question does not appear along with the Role
in the Role Graph. In other words, by default, Recently, the RBAC model has been extended to
a Role has only negative authorizations, unless include dynamic aspects, i.e., Temporal RBAC
and until any particular privileges are assigned (Bertino and Bonatti, 2001). This model sup-

to it. ports periodic enabling and disabling of roles,

possibly with individual exceptions for particu-
The real-life applicability of the RBAC model lar users.
has been validated in a real-life case study of
a large European bank, which is presented in
(Schaad, et.al., 2001). 3.2. Authorization Model for Secure
In (Thomas and Sandhu, 1997), an RBAC- Workflows
based model for workflow called Task-Based
Authorization Control (TBAC) is presented. A comprehensive authorization model for sup-
This model specifies, in a manner similar to that porting specification and enforcement of autho-
of RBAC, the tasks that each role is authorized rization constraints in workflows has been pre-
to perform. A lattice structure similar to that sented in (Bertino, et.al., 1999). Briefly, the
of RBAC, i.e., TBAC0 through TBAC3 is also model specifies a constraint specification lan-
presented. This is taken further in (Cholewka, guage through which the workflow designer can
et.al., 2000), where a mapping between RBAC specify, which roles and users are obliged or de-
and a similar TBAC-like model are presented. nied access to the workflow tasks, in the form of
In essence, TBAC works by setting users’ ac- static (specified at definition time) and dynamic
cess rights either at workflow definition time, or (specified at run time) constraints. These con-

at workflow execution time before the workflow straints can also include the DSOD and SSOD
task is executed. constraints as defined in Section 3.1.
A similar model is presented in (Huand and This model provides for both positive and nega-
Atluri, 1999). In this model, a Workflow Au- tive authorizations for roles (resp. users), which
thorization Template is attached to each task in are referred to as “Obliged Roles (resp. Users)”
the workflow. This template grants appropriate and “Denied Roles (resp. Users)”. The con-
authorizations only when the task starts and re- straint specification results in the creation of a
vokes it once the tasks has finished. More than Constraint Base, whose consistency is checked
one Template can be assigned to a task in case for ensuring that the roles (and users) belong-
more than one user needs to execute the task. ing to the “Obliged” category to execute a task,
if any, do not belong to the set of roles (and
The area of Multilevel Secure (MLS) Work- users) belonging to the “Denied” category for
flows is an offshoot of Secure Workflow, and that task, and vice versa.
is concerned with modeling workflows when
different tasks in the workflow are at different Hence the model proposes an algorithm for
security levels. More details can be found from user-task allocation, whose inputs are the fol-
Atluri, et.al., 2000; Kang, et.al., 1999); how- lowing:
ever, MLS workflows are out of the scope of The Global SSOD & DSOD Security Con-
this paper. straints are represented in the Constraint Base
(CB)
In this paper, we assume the existence of a sin-
gle Workflow Administrator who has the abil- The User-Role Mapping
ity and the authority to define/adapt and deploy
the workflows on the workflow system. This The Role Graph as described in Section 3.1,
would, of course, raise the issue of having a hi- which depicts the Role-Task Assignment
erarchy of workflow administrators, each with The output of the algorithm is the user-task
privileges over certain workflows (Sandhu and allocation for the workflow, which will be the
300 Design of an Integrated Role-Based Access Control

input to our algorithm to be described in Section the users in the organization. This assignment
4.4. is also based on an understanding of the overall
For our purposes, we redefine the “Obliged business goals of the organization, and also on
Roles (resp. Users)” as “Authorized Roles the kinds of tasks that each role would need to
(resp. Users)”, where Authorized essentially
execute.
refers to the direct privileges for tasks the Role Hence, actual role-task assignment is done
(resp. user) can access. Hence we redefine at the time of workflow instance definition, i.e.,
“Denied Roles (resp. Users)” as those that when instances are created out of the schemas.
do not belong to the “Authorized Roles (resp. This is similar in approach to the TBAC model
Users)” set. as described in (Thomas and Sandhu, 1997) and
In this section, we have only briefly introduced introduced in Section 3.1.
the algorithm; for more details, please refer to Hence, depending on the nature of the adapta-
the original paper (Bertino, et.al., 1999). We tion, the appropriate RBAC-related assignments
have also not described the SSOD and DSOD may need to be modified in order to ensure that
constraints more formally here, since they are the modified workflow process can be executed
already described in (Bertino, et.al., 1999); with the users available:
moreover, our emphasis is on the 3-tier RBAC
infrastructure itself. For changes at instance level, only role-task
assignments may need to be modified, in order
to ensure that all tasks in the modified work-
4. Our Approach to RBAC in Adaptive flow instance can be performed. For example,
Workflow junior managers can be temporarily provided
with permission to approve certain purchases
if the change in the workflow instance results
Major motivation behind our approach is to try in the non-availability of a senior manager to
to answer the following question: given our perform the approval task.
3-tier adaptive workflow architecture, what is
the appropriate RBAC infrastructure that would For changes at schema level, one of the two
“mirror” our adaptive workflow architecture? types of changes can be made:
In other words, for each level of adaptivity-
User-role assignments may need to be mod-
instance, schema, planning — what would be ified instead of mere role-task assignment
the appropriate RBAC-related modifications to changes. For example, a particular set of
make? individuals may be assigned the senior man-
To answer this question, we revisit the 3-tier ager role, so that they can (permanently)
model of (Nyanchama and Osborn, 1999) de- approve the purchases. This modification
scribed in Section 3.1. We recast this model as could also affect the role-task assignments,
the following 3-tier RBAC model: which may also need to be changed to reflect
the changed user-role assignments.
Global SSOD & DSOD Constraints

Global SSOD & DSOD constraints may need
User-Role Assignment to be modified.
Role-Task Assignment The reason why user-role assignments have
This model maps naturally onto our 3-tier adap- been mapped to the workflow schema level is
tive workflow architecture: that user-role assignments are typically more
radical and far-reaching than role-task assign-
When business goals are set for workflow ments in most organizations. For example, pro-
processes, the task of planning and scheduling moting a junior manager to the senior manager
these processes should take into account the role means that he/she automatically has access
global SSOD & DSOD constraints while the rights to all the tasks that the senior manager can
workflow schema is being defined perform in all future workflow instances deriv-
For workflow schema definition, the most ing from the adapted workflow schema. On the
crucial RBAC-related action that needs to be other hand, temporarily providing him/her with
performed, is to assign the appropriate roles to some of the senior manager privileges for only
Design of an Integrated Role-Based Access Control 301

a particular workflow instance, has much less limit. Such changes in constraints could also af-
impact on the organization. fect the user-role assignments, which could, in
turn, affect the role-task assignments.
The case is similar for SSOD & DSOD con-
straint modification. If either of the above two Of course, our model may be an over-simplifica-
types of changes is made, then the impact on tion in many cases, but it provides one way to
the organization will be far greater than merely effectively manage RBAC-related inconsisten-
changing role-task assignments. cies that could arise due to workflow changes.
For changes of business goals resulting in The example to be introduced later in this Sec-
widespread workflow schema changes, the glo- tion will illustrate these concepts and show the
bal SSOD & DSOD constraints may also need efficacy of our model.
to be modified, in addition to modifying the
user-role assignments. That is, these two types
of changes are far more disruptive than either
one of them acting alone. This is because, 4.1. Modified Adaptive Workflow
as explained above, global constraints typically Architecture
define the very basic constraints under which
the organization functions; changing these con- Based on the above mapping, the Planning
straints could lead to major changes in the or- Layer of our 3-tier adaptive workflow architec-
ganization structure itself. ture (depicted in Figure 3) is modified as shown
in Figure 6.
One example of change in a global constraint
is that approval for certain purchases below a Since global SSOD & DSOD constraints are es-
certain amount may no longer be required. Al- sentially limitations on how the workflow will
ternatively, an additional SSOD constraint may meet the user-specified goals, they are derived
be introduced that restricts a person from being from the goals via the Goal Specification Mod-
a junior manager and also from being granted ule, and are specified in the Security Mod-
permission to approve purchases above a certain ule. In this module, the Global Constraints

Users

Workflow Design Goal Specification Module

Module

WF
Repository
Security Module Global Constraint
Specification

User-Role Assignment

Role-Task Assignment

Schema - Planning Interface Manager

To Schema Layer

Fig. 6. Modified Planning Layer of Adaptive Workflow Architecture.

302 Design of an Integrated Role-Based Access Control

are specified in the Global Constraint Specifica- will be used only for the intended purpose, i.e.,
tion Module, which will also contain a consis- house building.
tency checker for ensuring consistency among This workflow is then adapted in order to pro-
the constraints. This will also involve setting duce the following workflow as depicted in Fig-
the User-Role and Role-Task assignments. ure 8.
Hence we see that the main adaptations are:
4.2. Our Example A Junior Manager’s initial approval is addition-
ally required, before additional processing can
We select a simple yet non-trivial example of be done on the loan application.
housing loan approvals at a bank (this is a sim- The document examination and assessor’s eval-
plified version of the process that the author uation tasks are parallelized for efficiency; there
himself had to go through while obtaining a is also a strict-sync edge from task #5 to task
housing loan at an Indian bank). We assume #4, signifying that House Assessment should be
the existence of the following roles in the Hous- completed successfully before Documents Ex-
ing Loans department: Department Manager, amination is executed.
Junior Managers, and Clerks. The initially fol-
lowed workflow for housing loan approval is The Role Graph for the Housing Loans Depart-
shown in Figure 7. ment is depicted in Figure 9 (the numbers next
to each role are the tasks of the workflows of
Please note that in the original workflow, route Figures 7 and 8 the role is allowed to execute,
nodes need to exist after work nodes #1, #3, #4 they are the privileges for the role).
and #5, to allow for the possibility of the cus-
tomer’s application being found unsuitable at One DSOD constraint in the Department is that
each of these nodes. For clarity, however, these the Clerk who has processed the customer’s ap-
have been elided from the diagram. plication, (i.e,. tasks #1, #2 and #3) cannot
approve the documents or perform house as-
Please also note that the task #5 has been intro- sessment for the same customer (i.e., tasks #3a,
duced since, as per regulations at most Indian #4 or #5). This constraint restricts the choice
banks, a portion of the house must already have of who will perform tasks #3a, #4 and #5 in
been constructed before a housing loan can be the event of a workflow adaptation if no Junior
granted. This is to ensure that the loan amount Manager or Department Manager is available.

Fig. 7. Initially Followed Housing Loan Approval Workflow.

Design of an Integrated Role-Based Access Control 303

Fig. 8. Adapted Housing Loan Approval Workflow.

Department
Manager

Junior Junior Junior

Manager Manager Manager
1 {3a, 4, 5, 7} 2 {3a, 4, 5, 7} 3 {3a, 4, 5, 7}

Clerk 1 {1, 2, 3} Clerk 2 {1, 2, 3} Clerk 3 {1, 2, 3} Clerk 4 {1, 2, 3}

Fig. 9. Role Graph for Housing Loans Department.

304 Design of an Integrated Role-Based Access Control

4.3. Modification Regions for Workflow Loops — all tasks belonging to the same
Changes loop as the task being added or deleted, also
need to be considered as candidates for inclu-
A typical workflow change is a combination of sion in the MR.
two basic actions: Hence, in our example, the tasks #4, #5, #6 and
Task deletion #7 form the MR, since they follow the added
task #3a. Since tasks #1, #2 and #3 are already
Task addition completed, they are in DONE state. Hence they
When a task is deleted, if the tasks following do not belong to the MR.
this task are not changed in any way, then there
is no impact on the rest of the workflow. How- 4.4. Re-assigning Roles and Users to a
ever, if the succeeding tasks in the workflow Task
are “brought forward” in order to take advan-
tage of the task deletion, then all these tasks are We assume the existence of the following:
potentially affected by this workflow change.
Role Graph as described in Section 3.1
Tasks can be added in one of the following two
ways: User-Role mapping, which maps users to
the roles they perform on the Role Graph (ac-
In parallel — this would mostly affect other cording to the algorithm of Section 3.2)
tasks only if the user who is supposed to work
on this new task is also needed for other tasks As per the previous sub-section, when a task is
in the rest of the workflow. either added or deleted, all tasks in the MR have
to be rescheduled. Hence for each task in the
Sequentially — all succeeding tasks are po- MR, we need to do the following:
tentially affected by this new task.
Determine whether there are users possess-
In any case, determining the tasks affected by ing the roles assigned to the task (by invoking
the workflow change, which we call Modifica- the algorithm of Section 3.2), who are available
tion Region (MR), is a heuristic procedure that to execute the task. If so, the user is allocated
needs to be implemented by the user based on to the task.
the semantics of the workflow. Moreover, as al- If not, we adopt the following approach:
ready mentioned in Section 3.1, we have already
assumed that the Workflow Administrator has
Let the role assigned to the task (as per the
the ability to understand the workflow seman- Role Graph) be R. We first search among the
tics so that he/she can identify the Modification seniors of R, in increasing order of senior-
Region for each workflow adaptation. ity in the Role Graph, as to whether any of
them are available to execute this task (via
The MR is therefore the only part of the work- inherited privileges). The search stops once
flow that needs to be rescheduled due to work- a senior is found who is available to execute
flow adaptation. In order to determine the MR, the task.
the Workflow Administrator can take advantage
of the following features of our workflow model  If not, then we check among the juniors of
(see Section 2.1):
each of the already checked seniors of the
user in question. This continues recur-
Sync edges — tasks that are connected (even sively upwards in the Role Graph, starting
transitively) by (soft or strict) sync edges to the at each of the seniors of the user in ques-
task being added or deleted, need to belong to tion, until the MaxRole role is reached.
the MR. Hence all other workflow tasks that Of course, at any time, the search ends if
are successors of the sync edge-connected task, an available user is found.
also need to be evaluated as potential candidates
to be included in the MR. If not, we search among the juniors of R, in
decreasing order of seniority in the Role Graph.
State Transitions — all tasks that do not This is basically a “mirror image” of the search
belong to either DONE or FAILED state are among the seniors, thus: at each junior, the se-
potential candidates to be included in the MR. niors of the junior are also checked, and this also
Design of an Integrated Role-Based Access Control 305

proceeds recursively down the Role Graph, until mental to the security of an organization. How-
the MinRole role is reached. Again, the search ever, temporary delegation of a task to a junior
stops once a junior is found who is available to employee due to the absence of a senior em-
execute the task. ployee is a common practice in most organiza-
tions.
In case the role of the available user cannot
execute the task (as per the current Role-Task The algorithm will then have to be implemented
assignments), then the user needs to be tem- for the other tasks in the MR, viz., #4, #5, #6
porarily allocated the privilege, so that he/she and #7.
can execute the task. If this allocation becomes
The overall algorithm is given in Fig. 10.
permanent, then the workflow change will be a
schema-level change.
Please note that at each candidate role in both 5. Conclusions and Future Work
senior and junior searches, we also need to en-
sure that the Global SSOD & DSOD Constraints
In this paper, we have presented our approach to
are obeyed. Otherwise, we move on to the next
enforcing Role-Based Access Control (RBAC)
role and alert the workflow administrator as to
in Adaptive Workflow. In line with our earlier
the exact violations that would occur.
work on a 3-tier adaptive workflow architec-
If neither search produces a satisfactory re- ture, we have presented a 3-tier RBAC infras-
sult, the workflow administrator will have to tructure for adaptive workflow, consisting of
take a decision manually. Alternatively, he/she Global Constraints, User-Role Assignments and
can relax/remove some of the Global SSOD Role-Task Assignment Layers; this mirrors our
& DSOD Constraints so that some user can be adaptive workflow architecture, which consists
found to execute the task. of Planning, Schema and Instance layers, re-
spectively. We have shown that temporary User
In our example, the task #3a is added, while
and Role allocation changes are sufficient for
tasks #4 and #5 are parallelized, along with a
instance level changes. Schema level changes
strict-sync edge between them. In case a Junior
demand that these allocation changes be made
Manager is not available to execute task #3a,
permanent, so that all future workflow instances
then the above algorithm needs to be invoked in
deriving from the new workflow schema are af-
order to find out whether any other Junior Man-
fected by the newly changed allocations. In ad-
ager or the Department Manager is available for
dition, Planning level changes require changes
this task.
in the Global Constraints that define how the
If not, then any available Clerk needs to be tem- business operates itself.
porarily given the privilege of executing task
We have also presented an incremental algo-
#3a. In this case, if the clerk in question hap-
rithm, leveraging off prior research in Role
pens to be the one who processed the customer’s
Based Access Control and Secure Workflow.
application, then the DSOD constraint operat-
With this algorithm, it is possible to imple-
ing on this Clerk has to be removed to allow the
ment re-allocations in the presence of workflow
Clerk to execute this task.
changes. The re-allocations need to be imple-
In case of a workflow schema change, this tem- mented only for those portions of the workflow
porary privilege addition will become perma- (also known as Modification Regions) affected
nent. In other words, even Clerks will have the by the workflow change. Indeed, we believe
ability to perform initial approval, documents that this is the first attempt at defining an RBAC
examination and house assessment for all fu- model and infrastructure for adaptive workflow.
ture workflow instances and, in essence, they
There are several opportunities for future work.
will become the equals in rank to Junior Man-
Firstly, our RBAC model needs to be specified
ager. If, in addition, the constraint removal is
in more detail, so that it can be implemented and
also made permanent, then this will become a
experimentally tested. In particular, safety and
planning level change.
correctness algorithms (Mathews, 2001) need
At first glance, such a re-assignment may seem to be incorporated into the model. Moreover,
to be rather unusual and may even appear detri- a formal definition of our workflow language
306 Design of an Integrated Role-Based Access Control

BEGIN
Assume an initial allocation of users and roles to tasks in the workflow as per the algorithm
of Section 3.2. Also assume that a workflow change has been introduced.
Determine MR = fAffected Tasksg as in Section 4.3;
for each Task in MR do
f
MR MRn fTaskg;/ The Task is removed from the set of Affected Tasks =
IF the Task CAN be executed by the currently allocated user
then
f
return; / i.e., go to the next affected task in the MR /
g
IF NOT
then
f
S: Implement Re-Assignment Algorithm from Section 4.4;
if the Re-Assignment Algorithm is successful
then
f
Assign the user and the role to the task as per the Re-Assignment Algorithm;
return; / i.e., go to the next affected task in the MR /
g
if NOT, then
f
Alert the Workflow Administrator, so that the Workflow Administrator can
modify the SSOD & DSOD constraints in order to re-execute this algorithm;
go to statement S;
g
g
g while (there is another Task in the MR)
END

Fig. 10. Overall Algorithm.

and execution model, along with formal work- gorithms specialized for specific workflow pat-
flow goal specification will also be necessary terns.
for implementation purposes. Formal specifica-
Our technique can also be extended for work-
tion of the SSOD and DSOD constraints, along flows running in distributed and heterogene-
lines of (Bertino, et.al., 1999), also need to be ous environments (Dellarocas and Klein, 1999;
incorporated into implementation. We should Herzberg, et.al., 2001; Kang, et.al., 2001; Na-
also incorporate more control-flow dependen- rendra, 2001), managed by intelligent agents.
cies (such as strict-sync and soft-sync) into our Also, the European bank case study as reported
workflow model, perhaps leveraging from the in (Schaad, et.al., 2001), has brought one possi-
ACTA (Chrysanthis and Ramamritham, 1990) ble interesting extension to the basic RBAC
transaction model. A (semi-) automatic algo- model used in this paper, viz., defining groups
rithm for MR determination can also be devel- of users for which roles can be assigned. The
oped and implemented. Using ideas from (van use of a general mechanism such as policy do-
der Aalst, et.al., 2001), we can also look at mains (Sloman and Twidle, 1994) needs inves-
efficient and automatic MR determination al- tigation. Other extensions of the RBAC model,
Design of an Integrated Role-Based Access Control 307

such as Team-Based Access Control (Geor-  8] CHRYSANTHIS P. K., AND RAMAMRITHAM K.,
giadis, et.al., 2001) and Set-Based Access Con- “ACTA: A Framework for Specifying and Rea-
soning about Transaction Structure and Behavior”,
trol (van den Akker, et.al., 2001), also need
to be investigated: In particular, the applicabil-
in Proceedings of the ACM SIGMOD International
Conference on Management of Data, pp. 194–203,
ity of TRBAC (Bertino and Bonatti, 2001) for 1990.
Adaptive Workflow needs to be investigated.
 9] DAMIANOU N., DULAY N., LUPU E., SLOMAN
M., “The Ponder Specification Language”,
Workshop on Policies for Distributed Systems
6. Acknowledgments and Networks (Policy2001), HP Labs Bris-
tol, 29–31 Jan 2001; also available from
http://www.doc.ic.ac.uk/ mss/Papers/
The author wishes to thank his manager, Srinidhi Ponder-Policy01V5.pdf
Srinath and the SES Director, Padma Ravichan-
ger, for their support.  10 ] DELLAROCAS C., AND KLEIN M., “Civil Agent
Societies: Tools for inventing open agent-
mediated electronic marketplaces”, Proceedings
of the Workshop in Agent-Mediated Electronic
References Commerce (co-located with IJCAI’99), Stock-
holm, Sweden, July 1999; also available from
http://ccs.mit.edu/dell/
civilagentsocieties.pdf
 1 ] VAN DER AALST W.M.P., HOFSTEDE A.H.M., KIE-
PUSZEWSKI B., AND BARROS A.P., “Workflow
Patterns”,2001, available from http://  11 ] GEORGIADIS C. K., MAVRIDIS I., PANGALOS G., AND
tmitwww.tm.tue.nl/staff/wvdaalst/ THOMAS R. K., “Flexible Team-Based Access Con-
Publications/p108.pdf trol Using Contexts”, ACM Workshop on Role
Based Access Control, Proceedings of the Sixth
 2 ] VAN DEN AKKER T., SNELL Q. O., AND CLEMENT M. ACM Symposium on Access Control Models and
J., “The YGuard Access Control Model: Set-Based Technologies, Chantilly, Virginia, USA, pp. 21–27,
Access Control”, ACM Workshop on Role Based 2001, ISBN:1-58113-350-2
Access Control, Proceedings of the Sixth ACM
Symposium on Access Control Models and Tech-  12 ] HERZBERG A., MASS Y., MIHAELI J., NAOR
nologies, Chantilly, Virginia, USA, Pages 75–84, D., AND RAVID Y., “Access Control Meets
2001, ISBN:1-58113-350-2. Public Key Infrastructure, Or: Assigning
 3] ATLURI V., “Security for Workflow Systems”, Roles to Strangers”, 2001, available from
Information Security Technical Report, Volume http://www.haifa.il.ibm.com/projects/
6, Number 2, 2001, Elsevier Science, 2002, software/e-Business/papers/
pp. 59–68; also available from http://cimic. Paper Trust.pdf
rutgers.edu/ atluri/workflow.pdf
 13 ] HUANG W-K., AND ATLURI V., “SecureFlow: A
 4] ATLURI V., HUANG W-K., AND BERTINO E., “A Secure Web-enabled Workflow Management Sys-
Semantic-Based Execution Model for Multilevel tem”, 4th ACM Workshop on Role-based Ac-
Secure Workflows”, Journal of Computer Security, cess Control, October, 1999; also available
Volume 8, Number 1, 2000, pp. 3–41; also available from http://cimic.rutgers.edu/ atluri/
from http://cimic.rutgers.edu/ atluri/ rbac99.ps
jcs00a.ps

 5] BERTINO E., AND BONATTI P.A., “TRBAC: A Tem-  14 ] KANG M. H., FROSCHER J. N., EPPINGER B. J., AND
poral Role-Based Access Control Model”, ACM MOSKOVITZ I. S., “A Multilevel Secure Work-
Transactions on Information and System Security, flow Management System”, 1999, available from
Vol. 4, No. 3, August 2001, pp. 191–223. http://www.itd.nrl.navy.mil/ITD/5540/
publications/CHACS/1999/
 6] BERTINO E., FERRARI E., AND ATLURI V., “An 1999kang-IFIP99.pdf
Approach for the Specification and Enforcement
of Authorization Constraints in Workflow Man-  15 ] KANG M. H., PARK J. S., AND FROSCHER J.
agement Systems”, ACM Transactions on Infor- N., “Access Control Mechanisms for Inter-
mation Systems Security, February 1999, Vol. Organizational Workflow”, 2001, available from
1, No. 1; also available from http://cimic. http://citeseer.nj.nec.com/438991.html
rutgers.edu/ atluri/tissec.ps

 7] CHOLEWKA D. G., BOTHA R. A., AND ELOFF J. H.  16 ] MATTHEWS M. G., “Supporting Adaptive Change
P., “A Context-Sensitive Access Control Model in B2B Coordination”, Proceedings of the
and Prototype Implementation”, Proceedings of International Conference on Artificial In-
IFIP/SEC 2000, August 2000; also available from telligence, Las Vegas, Nevada; 2001,
http://www.petech.ac.za/secwflow/images also available from http://mason.gmu.edu/
/papers/SEC2000Cholewka.pdf mmatthe1/Matthews ICAI 2001.pdf
 308 Design of an Integrated Role-Based Access Control

 17 ] NARENDRA N. C., “Adaptive Workflow Manage-

ment: An Integrated Approach and System Archi- Contact address:
tecture”, Applied Computing 2000, Proceedings of
Nanjangud C. Narendra
the 2000 ACM Symposium on Applied Computing, IBM Software Labs
Villa Olmo, Via Cantoni 1, 22100 Como, Italy, Golden Enclave
March 19–21, 2000. ACM, 2000, ISBN 1-58113- Airport Road
239-5, Volume 2. 560017 Bangalore
India
 18 ] NARENDRA N. C., “AdaptAgent: Integrated Ar- Phone: + 91 80 5094537
chitecture for Adaptive Workflow and Agents”, e-mail: [email protected]
it International Conference on Artificial In-
telligence 2001, Special Session on Agent-
oriented Software Architectures for B2B, Vol.
II, (Ed.) H. R. Arabnia, CSREA press, DR. NANJANGUD C. NARENDRA is a Software Architect at IBM Software
June 25–28, 2001, Nevada, Las Vegas, USA, Labs India, in Bangalore, India. He is the author of over 30 papers and
technical articles. His research interests are in the areas of information
ISBN: 1-892512-79-3; also available from systems, workflow, agent technology, security and e-service manage-
http://lists.w3.org/Archives/Public/ ment. He is a reviewer for IEEE Internet Computing, and has been a
public-ws-chor/2003Apr/att-0275/ reviewer for ACM Symposium on Applied Computing and numerous
adapt-agentB2B-ICAI.pdf other conferences on workflow and agents. The work for this paper was
done while he was working as a Software Architect at Hewlett-Packard
 19 ] NYANCHAMA M., AND OSBORN S., “The Role India Software Operations Ltd.
Graph Model and Conflict of Interest”, ACM
Transactions on Information and Systems Se-
curity, Vol.2, No.1, February 1999, pp. 3–
33; also available from http://www.csd.
uwo.ca/faculty/sylvia/conflict.ps

 20 ] SANDHU R. S, AND MUNAWER Q., “The RRA97

Model for Role-Based Administration of Role
Hierarchies”, 1997, available from http://
citeseer.nj.nec.com/sandhu98rra.html

 21 ] SANDHU R. S., AND SAMARATI P., “Access Control:

Principles and Practice”, IEEE Communications,
Volume 32, Number 9, September 1994; also avail-
able from http://citeseer.nj.nec.com/
687.html

 22 ] SCHAAD A., MOFFETT J., AND JACOB J., “The Role-

Based Access Control System of a European
Bank: A Case Study and Discussion”, ACM
Workshop on Role Based Access Control, 2001;
6th ACM Symposium on Access Control Mod-
els and Technologies (SACMAT 2001), May 3–4,
2001, Litton-TASC, Chantilly, Virginia, USA; also
available from http://citeseer.nj.nec.com/
schaad01rolebased.html

 23 ] SHAN M-C., DAVIS J., DU W., HUANG Y.,

“HP Workflow Research: Past, Present,
and Future”, HP Labs Technical Report
HPL-97-105, August 1997; available from
http://www.hpl.hp.com/techreports/97/
HPL-97-105.html

 24 ] SLOMAN M. S., AND TWIDLE K. P., “Domains: A

Framework for Structuring Management Policy”,
in Network and Distributed Systems Management,
Addison-Wesley, 1994.
 25 ] THOMAS R., AND SANDHU R. S., “Task-based Au-
thorization Controls (TBAC): A Family of Mod-
els for Active and Enterprise-oriented Authoriza-
tion Management”, IFIP WG11.3, 1997; also
available from http://citeseer.nj.nec.com/
thomas97taskbased.html

Received: March, 2003

Revised: December, 2003
Accepted: December, 2003

View publication stats