On the Controlled Evolution of Access Rules in
Cooperative Information Systems
Stefanie Rinderle1, and Manfred Reichert2
1Department Databases and Information Systems, University of Ulm, Germany
2Information Systems Group, University of Twente, The Netherlands
Abstract. For several reasons enterprises are frequently subject to or-
ganizational change. Respective adaptations may concern business pro-
cesses, but also other components of an enterprise architecture. In par-
ticular, changes of organizational structures often become necessary.
The information about organizational entities and their relationships
is maintained in organizational models. Therefore the quick and cor-
rect adaptation of these models is fundamental to adequately cope with
changes. However, model changes alone are not sufficient to guarantee
consistency. Since organizational models also provide the basis for defin-
ing access rules (e.g., actor assignments in workflow management systems
or access rules in document–centered applications) this information has
to be adapted accordingly (e.g., to avoid non-resolvable actor assign-
ments). Current approaches do not adequately address this problem,
which often leads to security gaps and delayed change adaptations.
In this paper we present a comprehensive approach for the controlled
evolution of organizational models in cooperative information systems.
First, we introduce a set of operators with well-defined semantics for
defining and changing organizational models. Second, we present an ad-
vanced approach for the semi-automated adaptation of access rules when
the underlying organizational model is changed. This includes a formal
part concerning both the evolution of organizational models and the
adaptation of related access rules.
1 Introduction
Enterprise-wide, cooperative information systems (IS) comprise a variety of ap-
plication and system components. Important tasks to be accomplished include
the support of business processes, the management of enterprise documents and
the integration of enterprise applications. For the implementation of such ser-
vices different middleware components exists, like workflow systems, document
management systems, and tools for enterprise application integration [1,2,3].
The controlled access to its application services as well as to the applica-
tion objects managed by them (e.g., business processes, business documents,
This research work was conducted during a postdoc stay at the University of Twente
R. Meersman and Z. Tari (Eds.): CoopIS/DOA/ODBASE 2005, LNCS 3760, pp. 238–255, 2005.
c
Springer-Verlag Berlin Heidelberg 2005
On the Controlled Evolution of Access Rules 239
Organizational Model OM’: Organizational Model OM:
OU = medical clinic
OU = administrationOU = treatment area
A = Dr. Smith A = Black A = Hunter
R = internist R = secretary
is subordinated is subordinated
belongs to
belongs to
R = assistant
belongs to
has
R = medical staff
has
specializes
specializes
has
OU: OrgUnit
A: Agent
R: Role
OU = medical clinic
OU = patient services
A = Dr. Smith A = Black
R = internist R = secretary
is subordinated
belongs to
R = assistant
belongs to
hashas has
has '
'=
(JoinEntities(OM, (treatment area, OrgUnit), (administration, OrgUnit), (patient, services, OrgUnit),
DeleteRelation(OM, ((patient services, OrgUnit), (Hunter, Agent), belongs to)),
DeleteRelation(OM, ((Hunter, Agent), (secretary, Role), belongs to)),
DeleteEntity(OM, (Hunter, Agent)), CreateRelation(OM, (Black, Agent), (secretary, Role), has)))
R = medical staff
specializes
specializes
join two
org. units
delete
org. unit
insert new
relation
Fig. 1. Example of an Organizational Model and a Model Change (simplified)
resources, application systems, etc.) constitutes an important task for any co-
operative IS. Usually, this results in a large number of access rules covering
different system aspects and user privileges. Furthermore, these rules have to
be frequently adapted due to changes of organizational structures [4,5,6]. Such
organizational changes become necessary, for instance, when an organizational
unit is split into two sub-units, two existing units are joined, a group of users is
reassigned to a new unit, or simply an employee leaves the organization.1As a
consequence, the access rules whose definition is based on organizational entities
may have to be adapted as well. So far, the controlled evolution of access rules
in cooperative IS has not been addressed in sufficient detail, which has led to
severe security gaps when organizational changes are introduced.
Typically, information about organizational entities (e.g., organizational
units, roles, and users) and the relations between them (e.g., assignment of a
user to a role or an organizational unit) is kept in an organizational model.
Based on such a model, access rights and user privileges can be defined (e.g.,
actor assignments in a workflow management system or access rules in document-
centered applications). Consequently, when organizational changes occur, both
the organizational model and the related access rules have to be adapted in a
consistent manner.
Another (practical) problem arises from the fact that the (middleware) com-
ponents used to build the application services of cooperative IS often maintain
their own organizational model and security component; i.e., the information
about organizational entities (and their relations) as well as the access rules
1For respective results from one of our case studies in the clinical domain see [4].
240 S. Rinderle and M. Reichert
based on them may be scattered over different system components. On the
one hand this has led to functional redundancy, on the other hand (hetero-
geneous)information about organizational structures is kept redundantly in dif-
ferent security components. The latter very often results in inconsistencies, high
costs for system maintainability, and inflexibility when dealing with organiza-
tional change.
But even if the organizational model is kept in a central repository, the prob-
lem of maintainability remains. The correct and consistent adaptation of the
organizational model is only one side of the coin when dealing with organiza-
tional changes; the other is to correctly and efficiently adapt the access rules
defined on basis of this model. Note that in large environments hundreds up to
thousands of access rules may exist, each of them capturing different privileges
of the cooperative IS. This, in turn, makes it a hard job for the system adminis-
trator to quickly and correctly adapt these rules to changes of the organizational
model(s).
Current approaches do not sufficiently deal with this issue. They neither make
use of the semantics of the applied model changes nor do they provide any auto-
mated support for rule adaptation. In practice, this often leads to problems like
non-resolvable actor assignments, unauthorized access to business documents, or
inconsistent user worklists. Assume, for example, that two organizational units
are joined in order to make the enterprise more efficient (cf. Fig. 1). If this
change is performed in an uncontrolled manner, it may result in non-resolvable
access rules referring to one of these two units (no longer present in the new
organizational model).
Facing these challenges we need a logically centralized component which man-
ages the organizational model and its changes in a consistent and efficient man-
ner. Furthermore, model changes have to be propagated to access rules (used
within different system components) in a correct and efficient manner. Finally,
we have to consider both, access rules which are checked when a certain privilege
is applied (e.g., when a user wants to access a document) and rules which are
used to determine a set of authorized users (e.g., the set of actors who may work
on a certain workflow activity).
In this paper we present a comprehensive approach for the controlled evo-
lution of organizational models in cooperative IS. This approach complements
our previous work on the controlled evolution of process models and process
instances in adaptive process management systems [7,8,9,10,11]. First, we in-
troduce a set of operations with well-defined semantics for defining and changing
organizational models. Second, we present an advanced approach for the semi-
automated adaptation of access rules when the referred organizational model
is modified. For selected organizational changes we show how they can be re-
alized in our formal framework and how their effects on access rules look like.
We then try to derive migration strategies for affected access rules. Thereby
we make use of the semantics of the applied model changes and we introduce
formally sound migration concepts. For this purpose, we introduce a formal
meta model for defining and changing organizational models and related ac-
On the Controlled Evolution of Access Rules 241
cess rules. Altogether this paper includes a formal part concerning the evolu-
tion of organizational models and related access rules as well as a discussion of
practical issues.
Section 2 discusses related work. In Section 3 we present a sample meta
model for defining organizational models and access rules. Section 4 deals with
the evolution of organizational models and the (semi-automated) adaptation of
related access rules. Use cases and practical issues are sketched in Section 5. We
conclude with a short summary and an outlook on future work.
2 Related Work
The provision of adequate access control mechanism is indispensable for any co-
operative IS. In the literature many approaches exist dealing with corresponding
issues (e.g., [6,12,13,14]). Most of them use Role–Based Access Control (RBAC)
models for defining and managing user privileges [15,16,12,17], e.g., for ensuring
the controlled access to business documents when using document management
technology [18] or for resolving the set of actors that qualify for a certain task
in a workflow management system [19,20,21,13,14]. Regarding workflow–based
applications, in addition, dynamic constraints (e.g., separation of duties) have
been considered [20,21]. So far, however, only few approaches [22,23] have ad-
dressed the problem of organizational change (see below).
Issues related to the modeling of organizational structures have been consid-
ered by different groups [5,13,24]. Most of them suggest a particular meta model
for capturing organizational entities and their relations. Model changes and the
adaptation of access rules, however, have not been studied by these approaches
in sufficient detail.
In [25] several issues related to changes of process and organizational struc-
tures have been discussed. In this work the authors also motivate the need for
the controlled change of organizational models. In particular, they discuss dif-
ferent kinds of adaptations that have to be supported (e.g., to extend, reduce,
replace, and re-link model elements). However, no concrete solution approach is
provided (like, for example, formal change operators with well–defined semantics
or mechanisms for adapting access rules after model changes).
In[6,26]theauthoridentifieseightdifferentcategoriesforstructuralchangesof
organizationalmodels. Examplesof such changecategoriesinclude the splitting of
organizationalunits, the creationof neworganizationalentities, and the re-linkage
of a user to a new unit. In principle, all these cases can be captured by our change
framework as well. As opposed to [6], however, we have followed a rigorous formal
approach in order to be able to derive the effects of organizational changes on re-
lated access rules as well. This issue has not been addressed in [6].
Other approaches have introduced role–based access control model for adap-
tive workflows [14,23]. In [23] the authors additionally address issues related to
the evolution of access rights in workflow management systems. However, no for-
mal considerations are made and only simple cases are managed when compared
to our approach.
242 S. Rinderle and M. Reichert
Organizational
Unit Actor Role
is subordinated
has
specializes
belongs to
(
0,1
)
(
0,n
)
(
0,n
)
(
0,1
)
(
0,n
)
(
0,n
)
(
0,n
)
(
0,1
)
Fig. 2. Organizational Meta Model
3 Organizational Models and Access Rules
In order to be able to reason about organizational changes and their concrete
impact on access rules we need a formalization of organizational structures.
For this purpose, first of all, we introduce an (organizational) meta model,
which is comparable to existing RBAC models (e.g., [15]) and which can be
used for describing organizational entities and the relations between them (cf.
Fig. 2). Due to lack of space, in this paper we restrict our considerations to
the basic entity types organizational unit,role and actor, and to the particu-
lar relation types existing between them (e.g., actor A1belongs to organiza-
tional unit O1,roleR1specializes role R0,etc.).Inourcompleteframework
currently implemented in the ADEPT2 project, we also consider entity types
like position,group or capability when defining and changing organizational
models [24].
Regarding the meta model OMM assumed in this paper (cf. Fig. 2) we
specify the set of valid entity types and the set of valid relation types as follows:
–EntityTypes := {OrgUnit, Actor, Role}
–RelationTypes := {(OrgUnit, OrgUnit, is subordinated), (Role,
Role, specializes), (Actor, OrgUnit, belongs to), (Actor, Role,
has)}
We further denote
–E:= EId:= {(entId, entType) |entId ∈Id, entType ∈EntityTypes)}as the
set of all entities definable over a set of identifiers Id and
–RE:= {(e1,e
2,relType)|e1=(eId
1,eType
1), e2=(eId
2,eType
2)∈E,
(eType1,eType
2,relType)∈RelationTypes}as the set of all relations de-
finable over E
Actors are users (or resources) who need privileges to work on certain tasks
(e.g., workflow activities) or to access certain data objects (e.g., documents).
Generally, access rules are not directly linked to actors, but to the more abstract
concept of a role. Roles group privileges and are assigned to actors based on
their capabilities and competences. Generally, an actor can play different roles:
A physician in a hospital, for example, may play the two roles ward doctor and
radiologist. Actors possessing the same role are considered as being interchange-
able. Furthermore, roles can be hierarchically organized, i.e., a role may have
On the Controlled Evolution of Access Rules 243
one or more specialized sub–roles. Thereby a sub–role inherits all privileges of
its super–role and may extend this set by additional privileges. Finally, each
actor can be assigned to an organizational unit. Like roles, organizational units
can be hierarchically structured; i.e., a particular unit may have one or more
subordinated units (e.g., a medical hospital may have an intensive care unit and
an emergency laboratory).
Based on the introduced meta model we can now define the notion of or-
ganizational model. For the sake of simplicity, in this paper we do not con-
sider the cardinalities associated with the relation types of our meta model
(cf. Fig. 2).
Definition 1 (Organizational Model). For the organizational meta model
OMM let Ebe the set of all entities over a given set of identifiers and let REbe
the set of all relations over E(see above). Then: An organizational model OM is
defined as a tuple (Entities, Relations) with Entities ⊆Eand Relations ⊆R
E.
The set of all org. models definable on basis of OMM is denoted as OM.
Let OM =(Entities, Relations) be an organizational model. Based on the
organizational entities and relations described by OM we can define rules in
order to control the access to tasks, services, documents, or other objects. Since
the structuring and semantics of the access rules is fundamental for the (semi-)
automated derivation of rule adaptations, we consider this issue in more detail.
We distinguish between elementary and complex access rules.
An elementary access rule consists of a simple expression that qualifies a set
of entities from OM (i.e., a subset of Entities) for this rule. The elementary
access rule Actor = ’Hunter’, for example, expresses that exactly one entity,
namely the actor with name ’Hunter’, qualifies for this rule and therefore owns
the privileges associated with it. As a second example consider the elementary
access rule OrgUnit = clinic. For this access rule we denote the organizational
unit clinic as the qualifying entity. Furthermore, all actors belonging to this
unit own the privileges associated with this rule (e.g., getting access to a cer-
tain business document). For entities that can be hierarchically organized (i.e.,
for organizational units and roles in our meta model) we further allow for the
definition of transitive elementary access rules. As an example consider the el-
ementary access rule OrgUnit = clinic(+). For this rule the set of qualifying
entities comprises the organizational unit clinic itself and all of its directly
or indirectly subordinated units (i.e., the transitive closure with respect to the
’is-subordinated’ relation). All actors belonging to one of these qualifying units
own the privileges associated with this rule. Similar considerations can be made
regarding the ’specializes’ relation between entities of type Role.
Definition 2 (Elementary Access Rule).
Let OM = (Entities, Relations) be an organizational model based on OMM. Then
an elementary access rule EAR on OM is defined as follows:
EAR ≡(EAR1←− (EntityType = el)) |(EAR2←− (OrgUnit = el(+))) |(EAR3 ←− (Role = el(+)))
The set of entities qualifiying for one of the elementary access rules EAR1,EAR2
or EAR3 can be determined as follows:
244 S. Rinderle and M. Reichert
–EAR1 ←− (EntityType = el)
QualEntities(OM, EAR1)={(el, EntityType)}:(el, EntityType)∈Entities
∅:otherwise
–EAR2 ←− (OrgUnit = el(+))
QualEntities(OM, EAR2)={(el, OrgUnit)}∪Sub(OM, el):(el, OrgUnit)∈Entities
∅:otherwise
with
Sub(OM, el):= el:(el,el,issubordinated)∈Relations {(el,OrgUnit)}∪Sub(OM, el)
–EAR3 ←− (Role = el(+))
QualEntities(OM, EAR3)={(el, Role)}∪Spec(OM, el):(el, Role)∈Entities
∅:otherwise
with
Spec(OM, el):= el:(el,el,specializes)∈Relations {(el,Role)}∪Spec(OM, el)
In order to enable the definition of more complex access rules we allow for
the composition of existing rules (cf. Definition 3). For this purpose the following
operators can be used: negation, conjunction, and disjunction.
Definition 3 (Access Rule).
Let OM = (Entities, Relations) be an organizational model based on OMM. Then
an access rule AR on OM is defined as follows:
AR ≡EAR |NEAR |CAR |DAR with
–NEAR ←− (NOT (EAR)) where EAR is an elementary access rule
–CAR ←− (AR1 AND AR2) with AR1 and AR2 are access rules
–DAR ←− (AR1 OR AR2) with AR1 and AR2 are access rules
Consider the organizational model OM depicted in Fig. 1. An example for a
composed access rule on OM is AR ←− (OrgUnit = medical clinic(+) AND
Role = assistant). Regarding the first part of this rule (i.e., the elementary
access rule EAR1 ←− (OrgUnit = medical clinic(+)) we obtain QualEnti-
ties(OM, EAR1)={medical clinic, treatment area}as the set of qualifying
entities. For the second elementary rule EAR2 ←− (Role = assistant) the set
of qualifying entities is QualEntities(OM, EAR2)={assistant}.
We can use Definition 2 and Definition 3 in order to determine the set of
actors qualifying for access rule AR (cf. Definition 4). Corresponding actors then
own the privileges associated with this rule.
Definition 4 (Valid Actor Set). Let OM = (Entities, Relations) be an or-
ganizational model. Let Act(OM) := {(a, Actor)|(a, Actor)∈Entities}be the
set of all actors defined by OM, and let AR be an access rule on OM. Then:
VAS(OM, AR) denotes the set of all actors (from OM) who qualify for AR (i.e.,
who own the privileges associated with rule AR). Formally:
–AR ←− (EntityType = el) =⇒
VAS(OM, AR)=⎧
⎪
⎪
⎪
⎨
⎪
⎪
⎪
⎩
{(el, Actor)|(el, Actor)∈Act(OM)}ifEntityT ype =Actor
{(a, Actor)|(a, Actor)∈Act(OM)∧
∃(a, el, belongsto)∈Relations)}ifEntityT ype =OrgUnit
{(a, Actor)|(a, Actor)∈Act(OM)∧
∃(a, el, has)∈Relations)}ifEntityT ype =Role
–AR ←− (EntityType = el(+))=⇒
On the Controlled Evolution of Access Rules 245
VAS(OM, AR)=⎧
⎪
⎪
⎪
⎪
⎪
⎨
⎪
⎪
⎪
⎪
⎪
⎩
{(a, Actor)|(a, Actor)∈Act(OM)∧
∃el∈QualEntities(OM, AR):
∃(a, el,belongsto)∈Relations)}ifEntityT ype =OrgUnit
{(a, Actor)|(a, Actor)∈Act(OM)∧
∃el∈QualEntities(OM, AR):
∃(a, el,has)∈Relations)}ifEntityT ype =Role
–AR ←− (NOT (AR1))withAR1 is EAR =⇒
VAS(OM, AR)=Act(OM)\VAS(OM, AR1)
–AR ←− (AR1 AND AR2) with AR1 and AR2 are access rules =⇒
VAS(OM, AR)=VAS(AR1)∩VAS(AR2)
–AR ←− (AR1 OR AR2) with AR1 and AR2 are access rules =⇒
VAS(OM, AR)=VAS(AR1)∪VAS(AR2)
Finally, we provide a criterion which allows us to decide when an access rule
AR is valid with respect to a given organizational model OM. We call an access
rule valid if the following two conditions hold:
(1) AR does not contain dangling references, i.e., it does not refer to entities
which are not present in OM. Formally:
DanglingRef(OM,AR)=False if∀EAR in AR :QualEntities(OM, EAR)=∅
True otherwise
(2) AR is resolvable, i.e., the set of valid actors VAS(OM, AR) does not become
empty. Formally:
Resolv(OM, AR)=True ifV AS(OM,AR)=∅
False otherwise
Note that dangling references and/or non-resolvable access rules might occur
when changing organizational models in an uncontrolled manner.
Criterion 1 (Valid Access Rule) Let OM = ( Entities, Relations) be an or-
ganizational model and let AR be an access rule on OM. Then AR is valid regarding
OM if and only if there are no dangling references within the elementary access
rules contained in AR and AR is resolvable over the set Entities, formally:
Valid(OM, AR)=True ⇐⇒ (DanglingRef(OM, AR)=False ∧Resolv(OM, AR)=True)
4 Organizational Evolution and Effects on Access Rules
How do changes of an organizational model OM affect the access rules based
on it? In order to find a precise and satisfactory answer to this question, first
of all, we must be able to formally define a model change ∆and its semantics
(i.e., its effects on OM). Based on this information it should be possible to
determine which access rules (on OM) are affected by the model change, how
the effects of ∆on these rules look like, and which rule adaptations become
necessary.
In the following we assume the scenario depicted in Fig. 3: A (correct) or-
ganizational model OM is transformed into another (correct) model OMby
applying change ∆=op1, ..., opnto it. The challenge then is to adapt valid
246 S. Rinderle and M. Reichert
'
AR1
AR2
AR3
.
?
OM: OM’:
Fig. 3. Changing Organizational Models and Migrating Access Rules
OU1
OrgUnit
SubOU2
OrgUnit
subordinated
SubOU1
OrgUnit
subordinated
OU2
OrgUnit
A1
Actor
belongsto
A2
Actor
belongsto
A3
Actor
belongsto
OUNew
OrgUnit
SubOU2
OrgUnit
SubOU1
OrgUnit
A1
Actor
A2
Actor
A3
Actor
belongsto belongsto
subordinated belongsto
JoinEntities(OM, OU1, OU2, OUNew)
OM OM’
Fig. 4. Joining Organizational Units
access rules on OM in a way that they remain valid on OMas well; i.e., to
migrate these access rules from OM to OM, but without causing errors or
inconsistencies (e.g., dangling references).
In order to be able to express all kind of changes on an organizational model
OM, we provide a complete set of basic change operations to the user (e.g., for
creating / deleting entities and relations). For each change operation we define
formal pre– and post–conditions, which preserve the correctness of OM when
applying the operation(s) to it (assuming that OM has been a correct model
before). In addition to these basic change operations we provide frequently used,
high–level operations in order to facilitate change definition and to capture more
semantics about changes. Examples include operations for joining two entities
(e.g., organizational units; cf. Fig. 4) to a new one or for splitting an existing
entity (e.g., a role) into two new entities. Formally:
Definition 5 (Change Framework for Organizational Models). Let Ebe
the set of all entities over a set of identifiers and let REbe the set of all relations
over E. Let further OM = (Entities, Relations) be a (correct) organizational
model. Table 1 defines basic change operations ∆, which transform OM into
another (correct) organizational model OM’:=(Entities’, Relations’). In Table 2,
in addition, two high–level change operations are given, whose definition is based
on the basic change operations from Table 1.
On the Controlled Evolution of Access Rules 247
Table 1. Basic Change Operations on Organizational Models
CreateEntity:OM × Identifier ×EntityT ype →OMwith CreateEntitiy(OM, eId, entType) = OM’
Preconditions: •(eId, entType) ∈ Entities
Postconditions: •Entities’ = Entities ∪{(eId, entType)}
•Relations’ = Relations
DeleteEntity: OM × E →OMwith DeleteEntity(OM, e) = OM’
Preconditions: •e∈Entities
• ∃ rel = (e1, e2, relType) ∈Relations with e1 = e ∨e2 = e
Postconditions: •Entities’ = Entities \{e}
•Relations’ = Relations
CreateRelation: OM×E×E×RelT ype →OMwith CreateRelation(OM, e1, e2, relType) = OM’)
Preconditions: •e1 := (eId1, eType1), e2 := (eId2, eType2) ∈Entities
•(e1, e2, relType) ∈R
•(e1, e2, relType) ∈ Relations
Postconditions: •Entities’ = Entities
•Relations’ = Relations ∪{(e1, e2, relType)}
DeleteRelation: OM × RE→OMwith DeleteRelation(OM, relation) = OM’
Preconditions: •relation ∈Relations
Postconditions: •Entities’ = Entities
•Relations’ = Relations \{relation}
ReAssignRelaton: OM × RE×E×E→OMwith ReAssignRelation(OM, r, e, eNew) = OM’
Preconditions: •r = (e1, e2, relType) ∈Relations
•e=e1∨e=e2
•eNew := (eIdNew, eTypeNew) ∈Entities
•e = e1:=(eId1, eType1) =⇒eTypeNew = eType1
•e = e2:=(eId2, eType2) =⇒eTypeNew = eType2
•e = e1:=(eId1, eType1) =⇒(eNew, e2, relType) ∈ Relations
•e = e2:=(eId2, eType2) =⇒(e1, eNEw, relType) ∈ Relations
Postconditions: •e=e1=⇒Relations’ = Relations ∪{(eNew, e2, relType}\
{(e1, e2, relType}
•e=e2=⇒Relations’ = Relations ∪{(e1, eNew, relType}\
{(e1, e2, relType}
A new relation (of type relType) between two entities e1ande2 of an organi-
zational model to OM =(Entities, Relations), for example, can be created by
applying the basic operation CreateRelation(OM, e1, e2, relType) to OM.
The pre–conditions associated with this operation then ensure that both entities
e1ande2 are actually present in OM and that the relation (e1,e2,relType)is
a valid relation not yet present in OM. The post–condition of this operation,
in turn, describes the effects resulting from the application of the operation to
OM (in our example, relation (e1,e2,relType) is added to the set Relations,
whereas the set Entities remains unchanged).
When transforming an organizational model OM into another model OM
one must be able to decide which access rules defined on OM can be directly
migrated to OM, i.e., which rules can be immediately re–linked to the new
model version without need for adaptation. Intuitively, this is the case for access
rules which are also valid on OM(cf. Theorem 1).
Theorem 1 (Direct Migration of Access Rules). Let OM = (Entities, Re-
lations) be a (correct) organizational model. Let further AR be a valid access rule
based on OM (i.e., Valid(OM, AR)=True)andlet∆be a (basic or high–level)
change operation which transforms OM into another (correct) organizational
model OM’. Then AR can be directly migrated to OM’ if Valid(OM’, AR)=True.
248 S. Rinderle and M. Reichert
Table 2. High–Level Change Operations on Organizational Models
JoinEntities: OM×E×E×Identifiers →OMwith JoinEntities(OM, e1, e2, nId) = OM’
Preconditions: •e1= (eId1, eType), e2 = (eId2, eType) ∈Entities
•(nId, eType) ∈ Entities
•eType =Actor
Basic Change Operations: •CreateEntity(OM, (nId, eType)), eNew := (nId, eType)
•∀(e, e1, relType) ∈Relations: ReassignRelation(OM, (e, e1,
relType), e1, eNew)
•∀(e, e2, relType) ∈Relations: ReassignRelation(OM, (e, e2,
relType), e2, eNew)
•∀(e1, e, relType) ∈Relations: ReassignRelation(OM, (e1, e,
relType), e1, eNew)
•∀(e, e2, relType) ∈Relations: ReassignRelation(OM, (e, e1,
relType), e2, eNew)
•DeleteEntity(OM, e1)
•DeleteEntity(OM, e2)
SplitEntity: OM×E×E×E→OMwith SplitEntity(OM, eOld, e1, e2) = OM’
Preconditions: •(eIdOld, eType) := eOld ∈Entities
•(e1Id, eType) := e1, (e2Id, eType) := e2 ∈ Entities
•eType =Actor
Basic Change Operations: •CreateEntity(OM, e1)
•CreateEntity(OM, e2)
•Reassigment of Relations −→ manually done by users
•DeleteEntity(OM, eOld)
The post conditions of the high–level changes result from the aggregation of the
post conditions of the applied basic change operations.
Table 3. Preliminary Considerations – Adaptation of Access Rules
Let ∆be a change operation (cf. Def. 5) which transforms a (correct) org. model OM
into another (correct) org. model OM’.
∆Necessary Adaptations
CreateEntity(OM, e, eType) I, none
CreateRelation(OM, e1, e2, relType) II, VAS may become bigger for EAR or
smaller for NEAR (= ∅); no dangling ref-
erences within AR
DeleteRelation(OM, rel) II, VAS may become smaller for EAR (=
∅) or smaller for NEAR ; no dangling ref-
erences within AR
ReassignRelation(OM, rel, e, eNew) II, VAS may become smaller (= ∅)orbig-
ger; no dangling references within AR
DeleteEntity(OM, e) IV, VAS may become smaller (= ∅)for
EAR or bigger for NEAR; dangling refer-
ences within AR possible
joinEntities(OM, e1, e2, eNew) IV, actor set changes, dangling references
possible
splitEntity(OM, e, e1, e2) IV, distribution of actor set is user depen-
dent, dangling references possible
Regarding basic change operations the direct migration of access rules from
OM to OMis only possible in connection with the operation CreateEntity(OM,
...), i.e., when adding new entities to OM (cf. Lemma 1).
On the Controlled Evolution of Access Rules 249
Lemma 1 (Direct Migration of Access Rules). Let OM be a (correct) or-
ganizational model and let AR be a valid access rule on OM (i.e., Valid(OM, AR)
=True). Let further ∆be a change operation which transforms OM into another
(correct) organizational model OM’. Then AR can be directly migrated (re-linked)
to OM’, i.e., Valid(OM’, AR )=True if ∆=CreateEntity(OM, ...).
When creating a new entity, we can always guarantee that there will be no dan-
gling references within existing access rules and that this change is invariant
regarding the set of valid actors (cf. Table 3). If an access rule AR cannot be di-
rectly transferred to the changed organizational model there may be two reasons
for that. Either there are dangling references (e.g., due to the fact that an entity
to which AR refers has been deleted from OM) or the set of valid actors becomes
empty for AR on OM. The following lemma states for which basic change opera-
tions we can guarantee that there will be no dangling references within existing
rules after a change (cf. Table 3).
Lemma 2 (No Dangling References). Let OM be a (correct) organizational
model and let AR be a valid access rule on OM (i.e., Valid(OM, AR)=True).
Let further ∆be a change operation which transforms OM into another (correct)
organizational model OM’. Then:
DanglingRef(OM’, AR)=False if
∆∈{CreateEntity(OM,...), CreateRelation(OM,...), DeleteRelation(OM,...),
ReAssignRelation(OM,...)}.
For all other basic and high–level change operations, i.e., for changes ∆∈
{DeleteEntity(OM,...), JoinEntities(OM,...), SplitEntity(OM,...)},
their application to an organizational model OM may result in dangling refer-
ences within the set of existing access rules (cf. Table 3).
In order to keep the total set of access rules consistent and the respective
security component correctly running after applying model changes, we have to
adapt those access rules that are no longer valid. Due to the potentially high
number of rules that may exist in the system we want to assist the user as
much as possible in accomplishing this task. In particular, we aim at the (semi–)
automated migration and transformation of access rules in order to adapt them
to model changes (if possible and meaningful). With ’semi-automated’ we mean
that the system shall assist the user in an adequate way, e.g., by exploiting the
semantics of the applied change operation(s) and by making suggestions about
potential rule transformations.
Theorem 2 indicates which rule adaptations can be automatically derived and
suggested to the user in connection with the two high–level change operations
presented before (cf. Table 2). In particular, Theorem 2 summarizes adaptation
policies that can be applied to access rules containing dangling references. Doing
so, our approach makes use of the semantics of the applied changes operations.
Note that the derived policies only constitute suggestions, i.e., users may apply
another strategy if more favorable.
250 S. Rinderle and M. Reichert
Theorem 2 (Adaptation of Access Rules).
Let OM = (Entities, Relations) be a (correct) organizational model and let AR
be a valid access rule on OM. Let further ∆be a change operation which trans-
forms OM into another (correct) model OM’. Then: AR can be transformed into
a valid access rule AR’ on OMby applying adaptation rule δAR (see below)
if ∆∈{JoinEntities(OM, ...), SplitEntity(OM, ...)}.Forrespective∆
adaptation rule δAR turns out as follows:
–∆=JoinEntities(OM, e1, e2, newE) =⇒δAR:
∀EAR in AR with EAR:= (EntityType = e1) ∨EAR:= (EntityType = e2)
replace EAR by EAR’:= (EntityType = newE))∧
∀EAR in AR with EAR:= (EntityType = e1(+)) ∨EAR:= (EntityType = e2(+))
replace EAR by EAR’:= (EntityType = newE(+)))
–∆=SplitEntity(OM, e, e1, e2) =⇒δAR:
∀EAR in AR with EAR:= (EntityType = e)
replace EAR by EAR:= ((EntityType = e1) OR (EntityType = e2)))∧
∀EAR in AR with EAR:= (EntityType = e(+))
replace EAR by EAR:= ((EntityType = e1(+)) OR (EntityType = e2(+))))
As an example consider the change scenario depicted in Fig. 1. Take access
rule AROM:= ((OrgUnit = treatment area) AND (Role = assistant)) and
change ∆. For the first change operation joinEntities(PM, (treatment area,
OrgUnit), (administration, OrgUnit), (patient services, OrgUnit))
the transformation described by Theorem 2 is applied and the access rule is trans-
formed into AR’OM= ((OrgUnit = patient services) AND (Role =
assistant)). According to Theorem 2 deleting the two relations does not have
any effect on the access rule. The deletion of entity (Hunter, Actor) is uncrit-
ical since the set of valid actors for AR’ on OMis non-empty.
Note that for join, split, and delete operations access rule transformations
do not always become necessary. If an access rule does not refer to any entity
joined, deleted, or splitted, the rule can stay unaltered after the respective model
transformation. Finally, in addition to the described rule transformations in our
current implementation we apply a number of other rule optimizations when
migrating rules to a new version of the organizational model. The treatment of
these optimizations, however, is outside the scope of this paper.
Our approach also deals with the challenging question of how to adapt access
rules when entities are deleted from OM. As already mentioned this might lead
to dangling references depending on the nature of the respective access rules. In
certain cases no automatic strategy for adapting a particular access rule can be
provided; the system then only reports the problem to the user and asks him
for an adequate solution strategy. However, there are also many cases where
automatic adaptations become possible, and thus users can be assisted in trans-
forming rules in a way such that they become valid on the new model version
OMas well. In particular, this possibility exists in connection with the migra-
tion of composed access rules. As an example take access rule (AR ←− Role =
R1 ∨Role = R2).IfroleR2 is deleted from the underlying organizational model
this causes a dangling reference in AR. However, a suggestion for an automatic
On the Controlled Evolution of Access Rules 251
adaptation would be to delete EAR ←− Role = R2 from AR which results in the
following rule: AR ←− Role = R1. This access rule does note contain dangling
references and it remains resolvable on OM’.
5 Practical Issues
To illustrate our results we apply them to an important use case of cooperative
information systems – the adaptation of actor assignments in workflow manage-
ment systems. More precisely we sketch how organizational changes are handled
in the ADEPT2 process management system (PMS) [27] and how the different
system components interact with each other to cope with model changes. Besides
dynamic adaptations of organizational models ADEPT2 provides sophisticated
support for process schema evolution [28] and process instance changes [7]. These
kinds of process changes have been subject of previous publications on ADEPT
and are outside the scope of this paper.
In the ADEPT2 buildtime environment, organizational models can be cre-
ated and modified by the use of a graphical editor. This tool, whose visualiza-
tion component is based on SVG (Scalable Vector Graphics), supports users in
graphically defining organizational models. Model changes can be accomplished
with the same tool and are based on the operations presented in this paper. All
changes are logged by a respective system component. Besides this organization
modeling component another tool exists, which allows users to define elemen-
tary and complex access rules based on the current version of the organizational
model. Only such rules can be expressed which are syntactically and semanti-
cally correct. Furthermore, this rule editor is realized as plug-in which can be
used within different client applications (in our case, for example, the workflow
editor makes use of this component for defining actor assignments).
Consider the scenario depicted in Fig. 5. When an organizational change oc-
curs authorized users can adapt the organizational model accordingly. In this
case a new version of the organizational model is created which, in turn, trig-
gers the migration and adaptation of related access rules. Rules which can be
directly accessed by the change manager are immediately checked and migrated
to the new model version. Rules which are kept outside the ADEPT2 system
(e.g., access rules within a document management systems), however, require
lazy migration techniques and more advanced mechanisms as well. In ADEPT2,
any change of the organizational model immediately triggers the migration and
adaptation of the access rules maintained within the ADEPT2 system. These
rules include, for example, actor assignments for process activities (i.e., execu-
tion rights for working on these activities [24]) as well as privileges for changing
process models and/or process instances [14].
In our scenario from Fig. 5, for example, a change of the depicted organiza-
tional model may require the adaptation of actor assignments within a process
model. ADEPT2 indicates necessary adaptations to the process engineer who
then can perform the respective changes at the process model level. Thereby we
make use of the conceptual framework presented in this paper.
252 S. Rinderle and M. Reichert
Organizational Model OM:
OU = medical practice
OU = treatment
A = Dr. Smith A = jon
R = internist R = secretary
is subordinated
belongs to
R = assistant
hashas has
A = Adam A = Black
OU = adminitration
is subordinated
belongs to belongs to belongs to
has has
Process Models:
P1
P2
I1
I2
I3
Process Instances
V
V
V
Actor assignment Rule:
SAR := (Org.Unit = treatment
AND Role = assistant)
work lists
M3
Fig. 5. Change Scenario in Process Management Systems
The needed rule adaptations (i.e., adaptations of actor assignments) are
first carried out at the process model level. For long-running processes it might
also become necessary to propagate these model changes (i.e., the adaptations
of activity actor assignments) to already running process instances. This is
only possible for process instances that are compliant with the current pro-
cess model change. For example, when activities with modified actor assignment
have not yet been activated such a change propagation is possible in ADEPT2.
Finally, the described model and instance changes may also require the update
of user worklists. This is one of the biggest challenges when thinking of realistic
scenarios with ten thousands up to millions of work items. Worklist adapta-
tions, however, are outside the scope of this paper. An overview of the scenar-
ios supported in connection with changes of organizational models is given in
Table 4.
Fig. 6 gives an overview of the different system components of ADEPT2
and also indicates the complexity arising from the design and implementation of
adaptive process management technology. In the scenario described above the
following components are involved: Editor, ChangeMgr, WorklistMgr, OrgMod-
elMgr, AccessControlMgr, and LogMgr. Due to lack of space we omit a descrip-
tion of the architecture of this system and refer the interested reader to [27].
Table 4. Possible Scenarios when Changing the Organizational Model
Valid Actor Set
Access Rule unchanged changed
not directly affected I II (adapt worklists)
directly affected III IV
On the Controlled Evolution of Access Rules 253
Fig. 6. ADEPT2 system architecture (abstract view)
6 Summary and Outlook
Both the controlled evolution of organizational models and the correct adapta-
tion of access rules will be key ingredients of next generation enterprise security
systems, ultimately resulting in highly adaptive access control models. Together
with our complementary work on process evolution and dynamic process changes
[7,9,29,28] the presented concepts contribute to a platform enabling the real-
ization of highly flexible and adaptive, cooperative information systems.
In this paper we have focussed on the common support of changes on or-
ganizational models and on the necessary adaptations of related access rules.
We have discussed important challenges and requirements for the evolution of
organizational models as well as the limitations of current approaches. The very
important aspect of our work is its formal foundation. We have given precise def-
initions and formal theorems which are fundamental for the correct handling of
model changes and adaptations of corresponding access rules. The treatment of
both elementary and composed access rules adds to the overall completeness of
our approach. Finally, in our ADEPT2 project a powerful proof-of-concept pro-
totype has been implemented, which demonstrates the feasibility of the presented
concepts. This prototype even uses a more expressive meta model to describe
organizational structures in a compact and user-friendly way. Furthermore it
considers the dynamic adaptation of actor assignments in process management
systems and necessary worklist updates as well.
There are many other challenging issues related to changes of organizational
models and of related access rules. First, we believe that respective changes must
be closely linked with other components of cooperative information systems.
For example, actor assignments in workflow–based applications may have to be
adapted on–the–fly in order to cope with organizational changes. This, in turn,
may require change propagation to hundreds up to thousands of in-progress
254 S. Rinderle and M. Reichert
process instances as well as to related user worklists. Doing this in a correct and
efficient manner is a non-trivial problem that will be investigated by us in more
detail in future. Finally, changes may not only concern the process model or
the organizational model but other components of the cooperative information
systems as well. As an example take resource models or data models, which may
be also subject of change.
References
1. v.d. Aalst, W., van Hee, K.: Workflow Management. MIT Press (2002)
2. Sutton, M.: Document Management for the Enterprise: Principles, Techniques and
Applications. John Wiley (1996)
3. Linthicum, D.: Enterpise Application Integration. Addison-Wesley (1999)
4. Konyen, I.: Organizational structures and business processes in hospitals. Master’s
thesis, University of Ulm, Computer Science Faculty (1996) (in German).
5. Jablonski, S., Schlundt, M., Wedekind, H.: A generic component for the computer–
based use of organizational models (in german). Informatik Forschung und En-
twicklung 16 (2001) 23–34
6. Klarmann, J.: A comprehensive support for changes in organizational models of
workflow management systems. In: Proc. 4th Int’l Conf. on Inf Systems Modeling
(ISM’01). (2001) 375–387
7. Reichert, M., Dadam, P.: ADEPTflex - supporting dynamic changes of workflows
without losing control. JIIS 10 (1998) 93–129
8. Rinderle, S., Reichert, M., Dadam, P.: On dealing with structural conflicts between
process type and instance changes. In Desel, J., Pernici, B., Weske, M., eds.: Proc.
2nd Int’l Conf. on Business Process Management (BPM’04). LNCS 3080, Potsdam,
Germany (2004) 274–289
9. Rinderle, S., Reichert, M., Dadam, P.: Disjoint and overlapping process changes:
Challenges, solutions, applications. In: Proc. Int’l Conf. on Cooperative Informa-
tion Systems (CoopIS’04). LNCS 3290, Agia Napa, Cyprus (2004) 101–120
10. Rinderle, S., Reichert, M., Dadam, P.: Correctness criteria for dynamic changes in
workflow systems – a survey. Data and Knowledge Engineering, Special Issue on
Advances in Business Process Management 50 (2004) 9–34
11. Reichert, M., Rinderle, S., Dadam, P.: On the common support of workflow type
and instance changes under correctness constraints. In: Proc. Int’l Conf. on Co-
operative Information Systems (CoopIS’03). LNCS 2888, Catania, Italy (2003)
407–425
12. Bertino, E.: Data security. DKE 25 (1998) 199–216
13. zur Muehlen, M.: Resource modeling in workflow applications. In: Proc. of the
1999 Workflow Management Conference (Muenster). (1999) 137–153
14. Weber, B., Reichert, M., Wild, W., Rinderle, S.: Balancing flexibility and security
in adaptive process management systems. In: Proc. Int’l Conf. on Cooperative
Information Systems (CoopIS’05), Agia Napa, Cyprus (2005)
15. Ferraiolo, D., Kuhn, D., Chandramouli, R.: Role–Based Access Control. Artech
House (2003)
16. NIST: Proposed Standard for Role-Based Access Control.
http://csrc.nist.gov/rbac/rbacSTDACM.pdf (2004)
17. Ferraiolo, D., Kuhn, D.: Role based access control. In: 15th National Computer
Security Conference. (1992)
On the Controlled Evolution of Access Rules 255
18. Sutton, M.: Document Management for the Enterprise – Principles, Techniques,
and Applications. Wiley Computer Publ., New York (1996)
19. Botha, R., Eloff, J.: A framework for access control in workflow systems. Informa-
tion Management and Computer Security. 9(2001) 126–133
20. Bertino, E., Ferrari, E., Alturi, V.: The specification and enforcement of autho-
rization constraints in wfms. ACM Trans. on Inf. and Sys. Sec. 2(1999) 65–104
21. Wainer, J., Barthelmess, P., Kumar, A.: W–RBAC – a workflow security model
incorporating controlled overriding of constraints. International Journal of Collab-
orative Information Systems 12 (2003) 455–485
22. Klarmann, J.: A comprehensive support for changes in organizational models of
workflow management systems. In: Proc. Int’l Conf. on Information Systems Mod-
eling (ISM’01), Hradec nad Moravici, Czech Republic (2001)
23. Domingos, D., Rito-Silva, A., Veiga, P.: Authorization and access control in adap-
tive workflows. In: Proc. Europ. Symposium on Research in Computer Science
(ESORICS’03), Gjovik, Norway (2003) 23–28
24. Berroth, M.: Design of a component for organizational models. Master’s thesis,
University of Ulm, Computer Science Faculty (2005) (in German).
25. v.d. Aalst, W., Jablonski, S.: Dealing with workflow change: Identification of issues
an solutions. Int’l Journal of Comp. Systems, Science and Engineering 15 (2000)
267–276
26. Klarmann, J.: Using conceptual graphs for organization modeling in workflow man-
agement systems. In: Proc. Conf. Professionelles Wissensmanagement (WM’01).
(2001) 19–23
27. Reichert, M., Rinderle, S., Kreher, U., Dadam, P.: Adaptive process management
with adept2. In: Proc. 21st Int’l Conf. on Data Engineering (ICDE’05), Tokyo
(2005) 1113–1114
28. Rinderle, S., Reichert, M., Dadam, P.: Flexible support of team processes by
adaptive workflow systems. Distributed and Parallel Databases 16 (2004) 91–116
29. Rinderle, S., Weber, B., Reichert, M., Wild, W.: Integrating process learning and
process evolution - a semantics based approach. In: 3rd Int’l Conf. on Business
Process Management (BPM’05), Nancy, France (2005)
