Access Control for Monitoring
System-Spanning Business Processes in Proviado
Sarita Bassil1, Manfred Reichert2, Ralph Bobrik3, Thomas Bauer4
1Computer Science Department, Marshall University, USA
2Institute of Databases and Information Systems, Ulm University, Germany
3Detecon AG, Switzerland
4Group Research and Advanced Engineering, Daimler AG, Germany
Abstract: Integrated process support is highly desirable in environments where data
related to a particular (business) process are scattered over distributed, heterogeneous
information systems (IS). A process monitoring component is a much-needed module
in order to provide an integrated view on all these process data. Regarding process data
integration, access control (AC) issues are very important but also quite complex to be
addressed. A major problem arises from the fact that the involved IS are usually based
on heterogeneous AC components. For several reasons, the only feasible way to tackle
the problem of AC at the process monitoring level is to define access rights for the
process monitoring component, hence getting rid of the burden to map access rights
from the IS level. This paper discusses requirements for AC in process monitoring,
which we derived from our case studies in the automotive domain. It then presents
alternative approaches for AC: the view-based and the object-based approach. The
latter is retained, and a core AC model is proposed for the definition of access rights
that meet the derived requirements. AC mechanisms provided within the core model
are key ingredients for the definition of model extensions.
1 Introduction
In order to streamline their way of doing business, today’s companies are dealing with a
number of processes involving different domains, organizations, and groups. As discussed
in [BRB05], an integrated process support is highly desirable in such an environment
where data (e.g., audit trails and reports) related to a particular process (instance), and with
different degrees of sensitivity, are often scattered over heterogeneous information systems
(IS) (cf. Fig. 1). A process monitoring component is a much-needed module in order to
provide an integrated view on all these data [JHBK04, Mue01]. Despite its importance,
many existing process-aware IS [Wes07] do not offer such a component. Specifically, a
process monitoring component is responsible for displaying the status of process instances,
for dispatching specific activities to corresponding actors, and so on.
Different user groups or roles (e.g., technicians, managers) usually have different per-
spectives over processes and related data. Therefore, adequate views need to be provided
[BRB07]. This is of particular importance when dealing with complex, long-running busi-
ness processes with dozens up to thousands activities. In the context of process data in-
tegration and process monitoring [JHBK04], in addition, access control (AC) issues are
very important to be addressed. However, a major problem is that involved IS are usually
based on different AC components implying facts such as 1) heterogeneity regarding the
meta-models based on which organizational models and related access rights are defined
(e.g., users/groups and actors/roles), 2) different notions for the same entity/entity type
(e.g., user and actor), and 3) non-registration of particular user(s) in all of the involved IS.
technicians manager
monitoring/visualization layer
entire process
Audit trails & reports
q
process A process B process C
AC module 1
CADWfMSPDM
Information systems AC module 2 AC module 3
Figure 1: Process Data Integration with Multiple Perspectives
To preserve integrity of AC information, AC constraints applied at the process monitoring
level should be consistent with the constraints set out by the different IS. However, it has
turned out that the integration of heterogeneous AC components is difficult to achieve for
several reasons: 1) Access rights are not always explicitly described, but might be “hard-
coded”, and hence difficult to retrieve; 2) AC modules do not always provide interfaces
(i.e., APIs) in order to facilitate the access to information about AC rules (“black-box”
AC modules); and 3) Rights at the IS level mainly deal with process definition and exe-
cution, and have been not designed for the monitoring of process data by different users.
Process definition and execution require administration rights, permissions to create new
instances, delegation rights, rights to work on specific activities, and rights to change pro-
cesses [WRWR05]. By contrast, monitoring requires rights to visualize specific process
activities, to display specific activity attributes, or to show different abstractions on a pro-
cess (cf. Fig. 2a+b). Taking this into account, the only feasible way to tackle the problem
of AC at the process monitoring level is to (re-)define AC rights for the process monitor-
ing component, hence getting rid of the burden to inherit AC rights from the IS level. Of
course, if possible, existing AC rights at the IS level should be automatically mapped to
the ones at the process monitoring level, but we cannot assume this in general. Explicitly,
specifying AC rights at the monitoring level also makes it possible to define them at a
finer-grained level when compared with what is already defined at the IS level.
This paper discusses requirements relevant for the definition of such AC rights. These re-
quirements have resulted from case studies we conducted in the automotive domain.1We
propose approaches for AC, mainly a view-based and an object-based one. The retained
solution (i.e., the object-based approach) is used as backbone in order to provide a com-
prehensive core AC model. This model allows for the (compact) definition of AC rights at
a fine-grained level. Moreover, AC rights are meant to meet the spectrum of confidential-
ity possibly defined on process data. Proposed AC mechanisms will be key ingredients in
future definitions of extended AC models for process monitoring.
Section 2 discusses basic notions by distinguishing between model and instance level.
Section 3 exposes the major requirements identified. Two alternative approaches for AC
are studied and compared in Section 4. In Section 5, we introduce our logical AC model.
Section 6 discusses related work and Section 7 concludes with a summary and an outlook.
2 Basic Considerations
Generally, we distinguish between model and instance level (cf. Fig. 2). The former gath-
ers different kinds of enterprise models such as organizational models, functional models,
data models, IT-system models, and process models. Each of the first four models gives
input to the process model defined as a set of one or more linked activities, which col-
lectively realize a business objective. Specifically, these activities are carried out, in a
coordinated way, by different processing entities (incl. humans and software systems) to
reach a goal, such as changing the design of a car, delivering merchandise, or operating
a patient. User- and pre-defined attributes may be associated with process models or ac-
tivities (e.g., costs, needed resources). Examples of frameworks supporting the integrated
modeling of the different enterprise aspects include ARIS and Adonis.
In Proviado [BRB05, BBR06, BRB07], at the model level, we focus on the secure visu-
alization of data related to a particular process model. Other kinds of models have not
been considered for visualization yet, but will be added later on. Different types of data
may be involved in a process model such as process relevant data and application data
[Wes07]. We are particularly interested in providing a secure way to visualize application
data. These data are in general strictly managed by the application(s) supporting the pro-
cess model. At the instance level, we focus on the secure monitoring of running process
instances. A process instance is defined as the representation of a single enactment of a
process model (i.e., a concrete business case) [Wes07]. Concepts such as user worklists
(i.e., lists of work items derived from process instance activities), activity execution state
(e.g., Running), and activity execution cost are associated with the instance level.
At model and instance levels, different kinds of rights need to be defined; e.g., administra-
tion rights, data access rights, permission to create instances from a given process model,
rights to execute a particular work item, or delegation rights. At the model (instance) level,
the visualization (monitoring) of user-adapted views derived from specific process models
1In the Proviado project [BRB05, BBR06, BRB07], we are aiming to propose a solution for visualizing in a
secure way data related to a particular process or to a collection of processes.
Mdll l
It l l
U
dtdi
M
o
d
e
l
l
eve
l
I
ns
t
ance
l
eve
l
Organizational model
U
se
r
-a
d
ap
t
e
d
v
i
ews
Access control on visualization:
_______
_______
Access
control
on
visualization:
(a) Abstraction at the state level.
(b) Restricted view on activity
instances and activity
attributes.
Worklists
Functional
model
_
__
(a)
Process instances
Process model
D
8
DD
21
3
2
(a)
(b)
And-split And-join
………
………
………
Data model
A
ctivit
y
attributes ………
………
……….
………
………
………
……….
S
y
D: completed activity
IT-
S
ystem model : running activity
Figure 2: Basic Considerations
(instances) is required. These views must take into account access rights of the involved
user. Access rights may be defined on different aspects related to the model and instance
levels; e.g., process model, activity, process instance, activity instance, data elements, pre-
and user-defined attributes, attribute current value, and attribute history.
3 Access Control Major Requirements
We conducted case studies in the automotive domain in which we studied processes like
car engineering,change management (cf. Fig. 3a) and release management. As fruit of
these case studies, we derived major requirements for AC in process monitoring.
Requirement 1 (Definition of AC rights at a fine-grained level). AC rights for process
monitoring should meet the spectrum of confidentiality defined on data related to a partic-
ular process. Moreover, they should be definable on different aspects/objects of the model
and instance levels (e.g., the process itself and its activities, attributes, and data elements).
•Requirement 1.1 (Meeting a spectrum of confidentiality). A distinction should be
made between at least three levels of confidentiality: a first level in which all avail-
able information can be accessed, a second one where only high-level information
can be accessed, and a third one where no information is available at all. Consid-
ering the process of managing change requests (cf. Fig. 3a), for example, we may
think about a (pre-defined) attribute e.g., activity cost) associated with a specific ac-
tivity (e.g., generate expertise). Such an activity may require a “two days
by person” cost to be accomplished. One may have the right to access this infor-
mation (i.e., the exact value of the attribute), to access abstracted information such
as “less than one week (i.e., less than five days by person)”, or to access nothing.
The spectrum of confidentiality may also be restricted to only two levels: “give” or
“don’t give information”. In change management for example, an external partner
may design part of the car; internally, a verification of this component may be done
before it is integrated with the overall design of the car. The external partner might
or might not have the right to know about the existence of the verification activities.
•Requirement 1.2 (AC rights definable on different objects of the model / instance
levels). We define “object” as entity of a process model / instance; e.g., an expertise
document produced as output of a generate expertise activity is considered
as data object. The generate expertise activity itself as well as the change
request (CR) process model are considered as two different objects. Moreover, a
group of objects is also an object; e.g., AC rights may be defined 1) on all running
CR process instances, or 2) on specific ones.
Figure 3: Automotive Domain – (a) Simplified Process of Dealing with Change Requests (CR), (b)
Different Views on CR Process
Requirement 2 (Definition of static AC rights). We distinguish between “static” AC
rights that are independent from the execution of a process instance, and “dynamic” AC
rights for which this is not the case. The latter are based on elements such as activity status
and control principles (e.g., separation of duties, dual control, and inter-case constraints)
[SM02, BE01]. Regarding our CR process, a person from a specific department (e.g., mo-
tor eng.) responsible for generating expertise might not be allowed to access the expertise
document generated by the other departments (car body eng. and electronic eng.) unless
she finishes generating her own expertise. This paper focuses on static AC rights.
Requirement 3 (Usability and maintainability of AC rights). AC rights should be sim-
ple to define and easy to maintain. As discussed in [TAP05], a challenge is to balance col-
laboration and flexibility; i.e., we need to ensure that the advantages provided by process-
aware IS are not reduced by AC rights too rigidly defined. For this purpose, abstractions
are required at the objects’ level. In order to specify AC rights at different levels of gran-
ularity, we need to define hierarchies on objects; e.g., it might be reasonable to authorize
a manager to access all running CR process instances. However, regular users might only
have access to specific CR instances (e.g., CR initiators only have the right to access CR
process instances that correspond to change requests initiated by them).
Table 1 gathers major requirements identified. The ones highlighted (i.e., R1, R2, and R3)
are addressed by the solution proposed in Section 5.
Table 1: Access Control Major Requirements
Requirements Requirements’ description
R1 Definition of AC rights at a fine-grained level
R1.1 Meeting a spectrum of confidentiality
R1.2 AC rights definable on diff. aspects of the mod./inst. levels
R2 Definition of static AC rights
R3 Usability and maintainability of AC rights
R4 Definition of dynamic AC rights
R5 Definition of AC rights on the visualization of a collection of processes
R6 Definition of AC rights for the look-ahead problem
R7 Completeness of the AC component
4 Candidate Solution Approaches for Access Control
Among a list of possible AC approaches, we feature two candidate solutions that we study
and compare: the view- and the object-based approach. In both approaches we follow
the main idea proposed by a generalized AC approach; i.e., RBAC (Role-Based Access
Control) [FSG+01], in which AC rights are not directly linked to concrete users, but to
roles. The view-based approach consists of defining one basic view per user role; this view
implicitly reflects the AC rights of the role over a process by only showing the information
to be accessed by users with the respective role. The object-based approach consists of
defining, for each role, AC rights on the different aspects of a process (e.g., activity, activity
attributes, process instance). Section 4.1 illustrates the two featured approaches. Section
4.2 then summarizes their advantages and drawbacks. This helps us to clearly motivate the
object-based approach as the one retained and elaborated in the following.
4.1 Description of Solution Approaches
View-based Approach. Considering a particular process model such as the CR process
(cf. Fig. 3a), a number of views could be (manually) defined on this process. Each of them
would then reflect the information accessible for users with a particular role. Access rights
over the process may be derived implicitly from each view. Suppose the following views
are defined on the CR process (cf. Fig. 3b): (View 1) High-level view on CR process,
(View 2) View on expertise activities of CR process, and (View 3) View on request
activities of CR process. Then one basic view per role may be defined: (“general man-
ager”, View 1),(“CR manager”, View 2), and (“engineer”, View 3). Each of the views
implicitly reflects the read access rights of the particular role:
•Ageneral manager may access high-level activities like initiation,expertise,
evaluation,commenting, and so on.
•CR managers may access activities request expertise,request evaluation,
request comments,instruct realization, and conclude CR.
•Engineers may access concrete activities request expertise and generate
expertise.
Object-based Approach. It consists of explicitly defining an extensible set of access
rights for each role:
•(“general manager”, {initiation,expertise,evaluation,commenting,
approval,realization,conclusion}, Read)
•(“CR manager”, {request expertise,request evaluation,request
comments,instruct realization,conclude CR}, Read)
•(“engineer”, {request expertise,generate expertise}, Read)
A view may then be generated for a specific user based on the access rights associated with
the role(s) played by this user. As an example, a view such as View 3 illustrated in Fig. 3b
would be generated for motor engineer John Smith.
4.2 Solution Approaches: Advantages and Drawbacks
View-based Approach. The most obvious advantage comes from the fact that an existing
concept (e.g., View Definition Language [Bob08]) can be explicitly reused in order to
reflect the access rights over processes. Hence, there is no need for defining a new AC
language assuming that the process-aware IS clearly supports a View Definition Language
[Bob08]). However, three drawbacks can be identified:
Costly maintenance of views: Consider a process model Ptogether with the views derived
from it. Suppose a modification is brought to P: (1) the views affected by this change have
to be identified possibly among a large number of existing views; (2) the identified views
have to be adapted to reflect the change of P. This adaptation should be done without any
failure; (3) the adapted views imply an implicit modification over AC rights.
Complexity of views combination: Since a user may play more than one role (e.g., John
Smith being a general manager as well as a motor engineer), we must be able to combine
multiple views (e.g., View 1 and View 3). The resulting view, automatically generated or
manually modeled out of multiple views, will be shown to the user. On the one hand, we
are facing a combinatorial problem (i.e., the different ways of arranging views in order to
combine them). On the other hand, conflicts may exist between access rights reflected by
the views to be combined. Such conflicts, first, must be detected, and second, be solved,
probably by applying specific conflict resolution policies [dVSJ05, JSSS01].
Occurrence of redundant information due to lack of abstraction: Suppose that a specific
role Rhas access, among other things, to a specific activity Ain all processes involving A.
Using the view-based approach, this access right would be reflected by showing Awithin
all the views respectively defined on the processes containing A. This leads to redundant
information due to the definition of access rights at the level of process models, not involv-
ing functional models (cf. Sect. 2). The redundancy of information is an issue not only for
the view-based approach, but for other approaches as well, as long as the notion of abstrac-
tion is missing (e.g., at the level of activities). However, redundancy has more impact in
conjunction with the view-based approach than in conjunction with the object-based one.
Object-based Approach. The main advantage of this approach is threefold. Indeed, the
drawbacks identified for the view-based approach appear to be advantages here. First,
there is no maintenance of views; the cost behind the maintenance operation is abolished.
Second, views have not to be combined and hence the complexity behind this operation
does not exist. Third, if it is possible to define different levels of abstractions on objects,
this will reduce redundancy when specifying access rights. The object-based approach
may be criticized for not being intuitive since AC rights, instead of basic views, are initially
defined for each role. However when compared with the drawbacks of the view-based
approach, we voluntarily accept this only criticism, and select the object-based approach
in order to elaborate the core solution for our logical AC model.
Table 2 summarizes the most important criteria that play either in favor of or against each
of the considered approaches. As we can see, among five criteria, three play in favor of the
object-based approach, while only one criterion plays in favor of the view-based approach.
Table 2: Comparison of the View-based and Object-based Approaches
Criteria/Approaches View-based Object-based
Ease of AC rights definition + -
Ease of AC rights maintenance - +
Ease of conflicts resolution - -
Ease of AC rights combination - +*
Redundancy-free - +
+ Criterion plays in favor of the approach
- Criterion plays against the approach
* This criterion is reduced to the “Ease of conflicts resolution” criterion
5 An Access Control Model
An AC model for process monitoring must allow to restrict access to authorized users
only. Sect. 5.1 presents our formal framework for defining and manipulating AC rights.
Sect. 5.2 and Sect. 5.3 discuss AC model extensions for coping with the problem of users
playing multiple roles, and for addressing usability and maintainability issues.
5.1 Core AC Model
The specification of an AC module at the process monitoring level requires, first and fore-
most, the definition of access rights. A first step towards meeting Req. R1 (cf. Table 1)
consists of defining access rights on attributes associated with specific process aspects that
we call objects. Activities, process models or process instances are examples of accessed
objects; attributes, indeed, reflect fine-grained characteristics of such objects. For this
purpose, we first formally define the link between an object and its associated attributes.
Definition 1 (Set of Attributes Associated with an Object) Let ObjSet and AttSet respec-
tively be the set of objects and the set of attributes involved in the process monitoring com-
ponent. Then function attributeSet determines all attributes associated with an object obj
∈ObjSet. Formally: attributeSet: ObjSet 7→ AttSetPwith ∀att ∈attributeSet(obj): att
is a valid attribute defined on obj.
We associate with every object involved in the process monitoring component a set of
attributes. Formally: ∀obj ∈ObjSet:attributeSet(obj)⊆AttSet
In order to illustrate Def. 1, we reconsider the process from Fig. 3a. For the sake of
simplicity, we only retain the concrete concept of activity instead of the generalized one
of object. Let ObjSet = {request expertise,generate expertise,request
evaluation,provide evaluation,request comments,provide comments}
be a set of activities involved in the CR process. Let further AttSet = {Att1,Att2,Att3,
Att4,Att5}be the set of attributes involved in the CR process. Taking into account Def.
1, suppose that the set of attributes associated with each activity is captured as follows: at-
tributeSet(req. expertise) = {Att1,Att3}; attributeSet(gen. expertise) =
{Att1,Att2,Att4,Att5}; attributeSet(req. evaluation) = {Att1,Att3}; attribute-
Set(prov. evaluation) = {Att1,Att2,Att5}; attributeSet(req. comments) =
{Att1,Att3}; attributeSet(prov. comments) = {Att1,Att2}. We may think of Att1
as the activity status that could take values from the set {NotActivated,Activated,
Running,Completed,Skipped}.Att2may be the starting date/time of an activity.
Att3could be the employee black list with possible values {Yes,No}specifying whether
this list should be taken into account (or not) when employees are chosen to work on a spe-
cific task (e.g., generate expertise). If this list is taken into account, employees on
black list may be excluded from those that may work on the task.
Based on Def. 1, we retain two types of information that may be checked/read: the exis-
tence and the value of an object’s attribute. We distinguish between two different spectra
of confidentiality defined on this information: 1) “Allow”/“don’t allow” to check existence
of an attribute within an object; 2) “Allow”/“don’t allow” to read the value of an attribute
within an object, or allow to read another form of the value. From this we derive Def. 2.
Definition 2 (Access Control on Existence/Value of Attribute) Let (obj, att) (obj ∈Ob-
jSet, att ∈attributeSet(obj)) denote an attribute att associated with object obj. Then
Existobj,att determines whether it is allowed for someone (or not) to check the existence
of attribute att within object obj; V alobj,att determines whether it is allowed for someone
(or not) to read the value of attribute att within object obj. Formally:
Existobj,att := 0if not allowed to check existence of att within obj
1if allowed to check existence of att within obj
V alobj,att :=
0if not allowed to read value of att within obj
1if allowed to read only another form of value
2if allowed to read value of att within obj
Back to our example from Fig. 3a, suppose role “engineer” has the following access
rights on the CR process: access to activities request expertise and generate
expertise, access to the value of Att1and to another form of the value of Att2, and
access to the existence of Att3within request expertise. Taking into account Def.
2, the AC on the existence/value of the different attributes can be captured as follows:
V algenerate expertise, Att1= 2, V algenerate expertise, Att2= 1,
V alrequest expertise, Att1= 2, Existrequest expertise, Att3= 1
By default, we may suppose that the closed policy, considered as a classical approach for
AC [Cas95], applies. If not specified otherwise:
V alobj,att = 0 and Existobj,att = 0, ∀obj ∈ObjSet, att ∈attributeSet(obj)
In this context, two classical approaches for AC are discussed in literature [Cas95]: closed
policy where positive rights need to be specified explicitly, and open policy where negative
rights need to be specified explicitly. The closed policy approach is known to ensure better
protection than open policy. In the latter, the need for protection is not strong: by default,
access is to be granted. Intuitively, we may also suppose that a specific operation prevails
on another (cf. Fig. 4); e.g., whenever it is allowed to read the value of an attribute, this
implies that it is also allowed to read another form of the value, and to check the existence
of the attribute. Note that positive rights prevail on negative ones, i.e., positive rights are
on bottom of the scale in Fig. 4. This is because of the closed policy adopted. Taking into
account this scale, the following set of access rights is retained:
V algenerate expertise, Att1= 2, V algenerate expertise, Att2= 1,
V alrequest expertise, Att1= 2, Existrequest expertise, Att3= 1,
Existgenerate expertise, Att4= 0, Existgenerate expertise, Att5= 0,
ExistActivity, Attribute = 0, ∀Activity ∈ObjSet \ {request expertise,
generate expertise},Attribute ∈attributeSet(Activity)
Figure 4: Prevailment of Access Rights
AC rights being clearly defined, we present now a mechanism consisting of two functions
that respectively return 1) whether or not an attribute is associated with an object, 2) the
exact value or an abstraction of the value of an attribute.
Definition 3 (Existence/Value of Attribute) Let (obj, att) (obj ∈ObjSet, att ∈attribute-
Set(obj)) be an attribute associated with an object. Let Val be a function on ObjSet ×
AttSet, Val: ObjSet ×AttSet 7→ DomAttSet ∪ {Undefined}. Val reflects for each (obj,
att) ∈ObjSet ×AttSet its current value from domain DomAttSet or the value “Undefined”
if att has not been written yet. Let FunctionSet be the set of functions that can be applied
on the value of an attribute in order to provide another form of this value. For defining the
specific function that can be applied on a specific attribute, we need the function:
fa: ObjSet ×AttSet 7→ FunctionSet ∪ {Undefined}which maps each couple (obj, att)
∈ObjSet ×AttSet to a specific function from FunctionSet or to “Undefined” if att 6∈
attributeSet(obj) or no function is defined.
Then, f returns either the name of attribute att within object obj, or “Undefined”; h de-
termines either the value or another form of the value of attribute att within object obj, or
“Undefined”. Formally:
f: ObjSet ×AttSet 7→ AttSet ∪ {Undefined}
with f(obj, att) := att if Existobj,att = 1 ∧att ∈attributeSet(obj)
Undefined otherwise
h: ObjSet ×AttSet 7→ DomAttSet ∪DomF unctionSet ∪ {Undefined}
with h(obj, att) :=
Undefined if V alobj,att = 0
fa(obj, att)(V al(obj, att)) if V alobj,att = 1
V al(obj, att)if V alobj,att = 2
DomAttSet =Satt∈AttSet Domatt
DomF unctionSet =Sfct∈F unctionSet Domfct
If we go back to our example, applying Def. 3 would lead to the following existence/value
of the different attributes:
h(generate expertise,Att1) = V al(generate expertise,Att1)
f(generate expertise,Att1) = Att1
h(generate expertise,Att2) = fa(generate expertise,Att2)
(V al(generate expertise,Att2))
f(generate expertise,Att2) = Att2
h(request expertise,Att1) = V al(request expertise,Att1)
f(request expertise,Att1) = Att1
h(request expertise,Att3) = Undefined
f(request expertise,Att3) = Att3
h(Activity,Attribute) = f(Activity,Attribute) = Undefined
for all other combinations of activities and attributes
The result of applying Def. 3 on our CR process, taking into account specific access rights
assigned to role “engineer”, is illustrated in Fig. 5.
electr. eng. 9
generate Activity status = “Completed”
Starting date
=“
Last week
”
Activity status = “Running”
Starting date
=“
This week
”
expertise
body eng.
generate
chief eng.
generate
CR-Mgr.
9
request
Starting
date
Last
week
Starting
date
This
week
Activity status = “NotActivated”
St ti d t “N t k”( t d)
generate
expertise
motor eng. 9
generate
generate
expertise
request
expertise
Activity status = “Completed”
Em
p
lo
y
ee black list
Activity status = “Completed”
Starting date = “Last week”
St
ar
ti
ng
d
a
t
e =
“N
es
t
wee
k”(
expec
t
e
d)
Activity status:
9
Completed
generate
expertise
py
9
Completed
Running
Figure 5: View on CR Process Provided to Role “Engineer”
5.2 Extended AC Model - Users Playing Multiple Roles
In this section, we recognize and point out the fact that a user may play more than one role
leading to inconsistencies between the AC rights associated with each of the different roles.
As example, a user may play roles “manager” and “engineer”. On the one hand, engineers
may not be given access to private information. On the other hand, managers may need
to access private documents, and access to such information may be given to them. In
this context, a number of conflict resolution policies are discussed in literature [dVSJ05,
JSSS01, FGS94, SD92]. None of them represents “the perfect solution”. Whichever policy
we take, we will always find one situation for which it does not fit. [dVSJ05] states some
problems of the different policies in conjunction with specific scenarios. Interestingly,
conflicts may result either from explicitly defining negative AC rights, or from applying
the closed policy. In the latter case, a simple solution approach may be to neglect negative
AC rights derived from the used policy. Conflict resolution policies should be applied in
the former case. For lack of space, we abstain from discussing this matter here.
5.3 Extended AC Model - Compact Definition of AC rights
So far, we have expressed that a certain attribute is allowed to be accessed (or not) within
a certain object, particularly a certain activity. However, we must also be able to state
within which processes this is allowed, i.e., what is the context of the AC to be defined.
Candidates for the context are the entire process monitoring component (All), a group
of process models, a particular process model, a group of process instances related to a
particular process model, and a process instance.
The example elaborated in Section 5.1 presents a set of AC rights defined on a spe-
cific process model: CRM. We may think of the following representation: (CRM,
V algenerate expertise, Att1= 2) stating that the value of Att1from activity generate
expertise is allowed to be read within process model CRM. Suppose that AC rights
are defined on a set of process models (e.g., M1,M2,M3). This would lead to a set of
couples: (M1,V algenerate expertise, Att1= 2), (M2,V algenerate expertise, Att1= 2), (M3,
V algenerate expertise, Att1= 2). Hence, we recognize the need for abstraction at the ob-
jects’ level in order to compact the definition of AC rights reducing redundancy as much
as possible. Therefore, one feasible way is to organize objects hierarchically (cf. Fig. 6):
“All” at the top level, “Group of process models” at the next level down, “Process model”
at the level just after, etc., and to propagate AC rights top-down. This allows us to meet the
AC rights usability and maintainability requirement (cf. R3 in Table 1). Going back to our
example, a group of process models GM={M1,M2,M3}would be defined, and the set of
three couples would be reduced to the following couple: (GM,V algenerate expertise, Att1
= 2). This approach would also simplify the definition of exceptions; e.g., it would be
easy to express that no restrictions exist at all regarding accesses within any of the defined
processes except the following: no accesses are allowed to activity approve CR within
the CR process model. This would be reduced to: (All,V alAll, All = 2) (i.e., access is
given to everything in order to bypass the closed policy), and (CRM,Existapprove CR, All
= 0) (i.e., access is retrieved from approve CR within CRM).
All
Group of
process
Group of
process
Instantiated from
Inherited from
process
models
process
instances
GM= {M1 ,M2 ,M3}
Note: Activities and Attributes
come down in the hierarchy
CRM
Process Model Process Instance
Figure 6: Objects’ Hierarchy
6 Related Work
The provision of adequate security mechanisms is indispensable for any IS. Particularly,
in the context of process-aware IS such as ADEPT [RDB03], approaches have been pro-
posed for dealing in a secure way with specific issues related to process management.
As an example, Weber et al. propose an extension to RBAC in order to support pro-
cess changes safely [WRWR05]. In the CEOSIS project, Rinderle and Reichert address
changes that may occur within organizational structures [RMR07]. They discuss how to
support such changes, and how to adapt access rules when the underlying organizational
model is changed [RMR08, RMR09]. However, to our best knowledge, no research work
has yet addressed the problem of fine-grained AC in conjunction with process data inte-
gration and process monitoring [Mue01, JHBK04]. This also applies in respect to existing
process performance management tools (e.g., ARIS PPM).
Some of the aspects retained in this paper have already been introduced by others. The
fine-grained control was discussed in [TAP05] as one of the collaborative environment
factors that determine the usability of a specific AC model. The authors argue that it is not
sufficient to define AC rules only for groups of users on clusters of objects. A user might
need a specific permission on an instance of an object at a particular point (i.e., time) in the
collaboration session. In our approach, we were more explicit when defining AC rights at
a fine-grained level: 1) we introduced the spectrum of confidentiality concept that would
reflect the “specific” permission to grant or to revoke, and 2) we hierarchized objects such
that AC rights may be defined in a compact way on the different aspects of the process
model and instances. In [TAP05], no details are given regarding time (i.e., a permission is
valid only for a specific time space). This is an interesting point to be further investigated.
In the context of adaptive process-aware IS, Weber et al. propose the definition of process
type dependent AC rights [WRWR05]. Only change commands that are useful within a
particular context are allowed. This idea can be compared to our approach of specifying
the context of an AC right. However, both approaches focus on different aims. [WRWR05]
provides assistance for users when performing a change, whereas in this paper, the context
notion is used for defining AC rights in a more focused way. We refer to [KR09, RMR09]
for discussions of other AC frameworks in process-aware IS.
7 Summary and Outlook
We identified AC requirements in the context of process monitoring. We then presented
possible solution approaches for major requirements, and we motivated the objects-based
approach that we used for proposing a core AC model for process monitoring. Two ex-
tensions to this model were also discussed: the first one deals with the problems that may
appear when a single user plays more than one role; the second extension introduces the
“context” notion and discusses the compact definition of AC rights taking into account
a defined objects’ hierarchy. Major requirements were addressed using the proposed AC
model and its extensions. In future work, we will address requirements R4-7 (cf. Table
1). Our research work will also include the investigation of advanced issues such as the
aggregation and the definition of AC rights on data elements and other process aspects.
References
[BBR06] R. Bobrik, T. Bauer, and M. Reichert. Proviado Personalized and Configurable Vi-
sualizations of Business Processes. In Proc. EC-WEB’06, LNCS 4082, pages 61–71,
2006.
[BE01] R.A. Botha and J.H.P. Eloff. Separation of Duties for Access Control Enforcement in
Workflow Environments. IBM Systems Journal, 40(3):666–682, 2001.
[Bob08] R. Bobrik. Konfigurierbare Visualisierung komplexer Prozessmodelle. PhD thesis,
University of Ulm, 2008.
[BRB05] R. Bobrik, M. Reichert, and T. Bauer. Requirements for the Visualization of System-
Spanning Business Processes. In Proc. DEXA’05 Workshops, pages 948–954, Copen-
hagen, August 2005.
[BRB07] R. Bobrik, M. Reichert, and T. Bauer. View-Based Process Visualization. In Proc.
BPM’07, LNCS 4714, pages 88–95, 2007.
[Cas95] S. Castano et al. Database Security. Addison Wesley, 1995.
[dVSJ05] S. De Capitani di Vimercati, P. Samarati, and S. Jajodia. Policies, Models, and Lan-
guages for Access Control. In Proc. Int’l Workshop DNIS’05, pages 225–237, Aizu-
Wakamatsu, March 2005.
[FGS94] E.B. Fernandez, E. Gudes, and H. Song. A Model for Evaluation and Administration
of Security in Object-Oriented Databases. IEEE ToKDE, 6(2):275–292, 1994.
[FSG+01] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, and R. Chandramouli. Proposed
NIST Standard for Role-Based Access Control. ACM ToISS, 4(3):224–274, 2001.
[JHBK04] S. Junginger, H. Huehn, F. Bayer, and D. Karagiannis. Workflow-based Business Mon-
itoring. In Workflow Handbook 2004. Future Strategies, Lighthouse Point, 2004.
[JSSS01] S. Jajodia, P. Samarati, M.L. Sapino, and V.S. Subrahmanian. Flexible Support for
Multiple Access Control Policies. ACM ToDS, 26(2):214–260, 2001.
[KR09] V. K¨
unzle and M. Reichert. Integrating Users in Object-aware Process Management
Systems: Issues and Challenges. In Proc. Business Process Management Workshops
2009. Springer, 2009.
[Mue01] M. zur Muehlen. Workflow-based Process Controlling. In Workflow Handbook 2001.
Future Strategies, Lighthouse Point, 2001.
[RDB03] M. Reichert, P. Dadam, and T. Bauer. Dealing with Forward and Backward Jumps in
Workflow Management Systems. Software and Systems Modeling, 2(1):37–58, 2003.
[RMR07] S. Rinderle-Ma and M. Reichert. A Formal Framework for Adaptive Access Control
Models. In Journal of Data Semantics, IX, LNCS 4601, pages 82–112, 2007.
[RMR08] S. Rinderle-Ma and M. Reichert. Managing the Life Cycle of Access Rules in CEOSIS.
In Proc. EDOC’09, pages 257–266, 2008.
[RMR09] S. Rinderle-Ma and M. Reichert. Comprehensive Life Cycle Support for Access
Rules in Information Systems: The CEOSIS Project. Enterprise Information Systems,
3(3):219–251, 2009.
[SD92] H. Shen and P. Dewan. Access Control for Collaborative Environments. In Proc.
CSCW’92, pages 51–58, November 1992.
[SM02] A. Schaad and J. Moffett. A Framework for Organisational Control Principles. In Proc.
ACSAC’02, pages 229–238, Las Vegas, December 2002.
[TAP05] W. Tolone, G.-J. Ahn, and T. Pai. Access Control in Collaborative Systems. ACM
Computing Surveys, 37(1):29–41, 2005.
[Wes07] M. Weske. Business Process Management: Concepts, Languages, Architectures.
Springer, 2007.
[WRWR05] B. Weber, M. Reichert, W. Wild, and S. Rinderle. Balancing Flexibility and Security
in Adaptive Process Management Systems. In CoopIS’05, LNCS 3760, pages 59–76,
2005.
