WORKFLOW ACCESS CONTROL FROM A BUSINESS

PERSPECTIVE

Dulce Domingos

, António Rito-Silva

, Pedro Veiga

Informatics Department, University of Lisbon, Faculty of Science, Lisbon, Portugal

INESC-ID Software Engineering Group, Technical University of Lisbon, Lisbon, Portugal

Keywords: workflow access control, business modelling

Abstract: Workflow management systems are increasingly being used to support business processes. Methodologies

have been proposed in order to derive workflow process definitions from business models. However, these

methodologies do not comprise access control aspects.

In this paper we propose an extension to the Work Analysis Refinement Modelling (WARM) methodology,

which also enables to determine workflow access control information from the business process model. This

is done by identifying useful information from business process models and showing how it can be refined

to derive access control information.

Our approach reduces the effort required to define the workflow access control, ensures that authorization

rules are directly related to the business and aligns access control with the information system architecture

that implements the business process.

1 INTRODUCTION

Business models help us to better understand the

actual business and its goals, process (activities),

resources (such as people, machines and material)

and rules, providing a good basis for identifying the

correct requirements of information systems that

support the business.

Several approaches (Eriksson & Penker, 2000;

Sharp & McDermott, 2002) use business models to

determine information systems requirements by

identifying system use cases (Bittner et al., 2002)

directly from business process models. Although

workflow management systems (WfMSs) are

increasingly being used to support business

processes, this strategy cannot be applied to

workflow applications because, that way, important

human intervention information captured during

business modelling is lost.

In (Vieira & Rito-Silva, 2003), the authors

propose the Work Analysis Refinement Modelling

(WARM) methodology, a first approach to derive

workflow process definitions by using business

process models. They introduce an intermediate step

between business modelling and system modelling,

whose main purpose is to classify process activities

as manual activities, accomplished by human

workers, or automatic activities, executed by

information systems. As a result of this step, they get

a lower level description of the business process

model (a WARM model), which can be executed by

a WfMS. However, the WARM methodology

focuses on functional aspects, neglecting non-

functional aspects, such as access control. Indeed,

we can observe that, while we can find in the

literature a good amount of work defining access

control models and mechanisms for workflow

(Bertino et al., 1999; Casati et al., 1999; Kang et al.,

2001; Miller et al., 1999; Botha & Eloff, 2001b;

Thomas & Sandhu, 1997; Kandala & Sandhu, 2001;

Atluri & Huang, 1996), there is no work on how

workflow access control information can be

determined from business models.

In this paper we propose a methodology to

determine workflow role-based access control

information from business process models. We

extend the WARM methodology with access control

concepts; we identify the information provided by

the business process model and by the WARM

model that could be useful from an access control

perspective and we refine it to derive authorization

rules. Additionally, we also show how our

methodology can be used to derive authorization

rules for the information systems that support the

business process.

Our approach reduces the effort required to

define the workflow access control, ensures that

Domingos D., Rito-Silva A. and Veiga P. (2004).

WORKFLOW ACCESS CONTROL FROM A BUSINESS PERSPECTIVE.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 18-25

DOI: 10.5220/0002598500180025

 SciTePress

authorization rules are directly related to the

business, aligns access control with the information

system architecture that implements the business

process and guarantees the least privileged principle

by ensuring that each role has the needed

authorizations to perform its functions and no more.

The remainder of this paper is structured as

follows: in the next section we introduce business

modelling, emphasizing business process models.

The WARM methodology is overviewed in section 3

and our approach to derive workflow access control

information from business process models is

described in section 4. Considering that the WARM

methodology can also be useful to determine use

cases of information systems that support business

processes, in section 5 we show how their

authorization rules can be derived, as well. Section 6

summarizes some implementation issues and,

finally, the last section presents some conclusions

and provides a brief look of our future work. We

illustrate our approach with an example of a loan

workflow application.

2 BUSINESS MODELS

A business model is an abstraction of a complex

reality that captures the core functions of the

business. It provides a simplified view of the

business structure that can be used to better

understand the key mechanisms of a business, to

radically change the business or to identify new

business opportunities (Eriksson & Penker, 2000).

In this section we introduce the main concepts of

business modelling, emphasizing business process

models since they are used as the starting point of

the WARM methodology.

Although each business has specific goals and

internal structures, they use similar concepts to

describe concepts. According to (Eriksson & Penker,

2000), the concepts used to define a business are:

Process: a collection of steps performed within the

business during which the state of business resources

changes. Processes describe how the work is done

within the business and are governed by rules;

Step: a piece of work to be done within the context

of a business process;

Goal: the purpose of the business or the outcome

the business is trying to achieve. A goal can be

broken down in sub-goals and allocated to individual

parts of the business;

Event: some happening that triggers the business

process execution and that can be generated within

the process;

Resource: the objects within the business, such as

people, material, information, and products, which

are used or produced in the business;

Rule: a statement that either defines or constrains

some aspect of the business. Rules govern how the

business should be run.

All of these concepts are related to each other: a

rule can affect the way some resources are

structured; a resource is allocated to a specific

process; a goal is associated with the execution of a

specific process. The goal of business modelling is

to define these concepts and show the relationships

and interactions among them. A simplified meta-

model describing the concepts used in business

modelling and their relationships is shown in

Figure1.

Figure1: A simplified meta-model of business modelling

concepts

Business models can be described according to

several formats. In this paper we adopt the

Eriksson_Penker Business Extensions to Unified

Modelling Language (UML) (Eriksson & Penker,

2000). They propose a set of UML extensions to

accommodate business concepts. Considering the

focus of our work, we concentrate our business

model overview on business process models.

Business process models describe the steps

performed within the business, their logical flow,

and the value created and consumed by each one.

Within Eriksson_Penker Business Extensions, they

are represented with UML activity diagrams. These

extensions define a set of new tagged-values that

could contain additional information about the

process. One of them is:

Process actors: a textual value that defines the

actors needed to run the process. Typically, their

skill levels are described.

Additionally, resource objects can be used to

define the resources involved in the process. One

type of these objects is:

Supplying objects: are used to define who is

involved in performing steps, i.e., the resources that

participate in the process. These objects are drawn

below the process with a dependency (a dashed line)

from the object to the process. The dependency is

stereotyped to «supply».

Process models can also include swimlanes.

Swimlanes are a technique used to insert information

about where a specific process or step belongs.

Resource

Event

Goal

Process

Rule

Step

affects

generates

achieved by

affects

produces/consumes

governs

WORKFLOW ACCESS CONTROL FROM A BUSINESS PERSPECTIVE

Normally, swimlanes are used to describe where the

step is performed in terms of the organization of the

business (i.e., in which division or department of the

company). Moreover, a swimlane can show objects

other than the organization to illustrate which object

is responsible for a specific step or process. It could,

for example, show which resource is responsible for

performing a specific step.

According to the Eriksson_Penker Business

Extension, business rules are specified using the

Object Constraint Language (OCL).

Figure 2 illustrates a simplified business process

model represented with a UML activity diagram,

which will be used to exemplify the WARM

methodology. Firstly, a clerk receives the loan

request and produces a document with the request

information. Then, the score is determined and is

added to the request information. Based on this

information, if the requestor is a bank client, an

account manager evaluates the loan and produces an

answer; otherwise, this activity is done by a bank

manager. Finally, the requestor is informed about the

answer. As stated before, using Eriksson_Penker

Business Extensions, information about which

resources can perform each process step can be

shown using different types of techniques. Figure 2

illustrates the use of supply objects to define who is

involved in performing steps. This example also

illustrates the use of OCL to define constraints on

supply objects.

In summary, business process models provide

extensive information about steps performed within

the business, which can be used to derive low-level

workflow process definitions, as shown by (Vieira &

Rito-Silva, 2003) and described in the next section.

Moreover, they also provide information about who

is involved in performing these steps. Although this

information is not modelled within a security

perspective, we explain in section 0 how it can also

be useful to derive workflow access control

information.

3 WORK ANALYSIS

REFINEMENT MODELLING

The WARM methodology uses business process

models to derive workflow process definitions

described in a lower level language suitable to be

executed by a WfMS. WARM refines business

process concepts and creates an intermediate step

between business and workflow modelling.

Business process concepts are refined within the

WARM methodology in the following way:

Process: a collection of steps performed within the

business during which the state of business resources

changes. Processes describe how the work is done

within the business; they are governed by rules. This

definition was inherited from former business

modelling concepts.

Step: an activity performed within a business

process which may involve the execution of several

tasks;

Task: unit of work which cannot be further

decomposed;

Human Task: a specific type of task representing

the smallest piece of work that may be performed by

a human worker without IT support;

Tool Task: a specific type of task representing the

smallest piece of work that may be performed by a

human worker assisted by a system tool.

System Task: unit of work which cannot be further

decomposed. A system task is completely automated

by a software system and consequently does not

need any kind of human intervention.

Message: type of business resource which

represents the information that flows across the

entire business

process and that is produced and

consumed by tasks.

Figure 3 illustrates the WARM concepts meta-

model, which extends the business concepts meta-

model according to the concepts introduced

previously.

To derive workflow process definitions from

business process models, the WARM methodology

introduces an intermediate step between business

modelling and workflow modelling. Incrementally,

Figure 2: Loan request business process model with supply objects

Determine Score Evaluate Loan Inform Requestor

Receive Loan

Request

«resource»

Request + Score

«resource»

Request

«resource»

Answer

«resource»

Bank Manager

«resource»

Account Manager

«resource»

Bank Manager

«supply»

(not Request.isClient)

«supply»

(Request.isClient)

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

this intermediate step refines business concepts by

supplying additional information to the WARM

concepts described above, as follows:

– Steps are decomposed into smaller units of

work, named tasks;

– Tasks are classified as human task, tool task or

system task.

– Input and output messages are defined as data

resources.

In the following, we exemplify the use of the

WARM methodology, applying it to the loan request

business process model shown in Figure 2.

Within our example, firstly, we decompose each

step into tasks. Then we classify the Determine

Score and the Inform Requestor tasks as system

tasks, and the others as tool tasks. Finally, input and

output messages are defined. At last, we obtain the

WARM model presented in Figure 4.

As stated in (Vieira & Rito-Silva, 2003), the

lower level model obtained by the WARM

methodology is used to generate a workflow process

definition, which can be executed by a WfMS.

In the next section we propose an extension to

the WARM methodology, which also uses business

process model information to derive workflow

access control information.

4 WORKFLOW ACCESS

CONTROL

In this section we explain how we refine business

model process information, through an extension of

the WARM methodology, in order to get workflow

role-based access control information.

Role based access control models (Sandhu et al.,

1996) have been widely applied to both commercial

and research workflow systems (Casati et al., 1999)

in order to meet workflow access control

requirements. The central notion of RBAC models is

that permissions are associated with roles rather than

individual users. Users are assigned to roles and

acquire permissions by being members of roles. The

main advantage of the role concept is the

simplification of the administration of permissions.

Within WfMSs, permissions are interpreted as

authorizations to execute tasks. A typical workflow

RBAC authorization rule is represented as a tuple (r,

t, execute, p) and states that a user u playing role r

can execute task t if the predicate p holds true

(where p is optional).

Roles can be defined statically, by enumerating

the users that belong to a role, or dynamically, as an

expression on user attributes.

Therefore, we need to relate business process

model information to workflow authorization rules.

To accomplish this, we base our approach on the

WARM methodology. Firstly, we extend the

WARM methodology with four new concepts,

which refine business process concepts, as follows:

User: type of business resource, a human being

that can act in the process.

Role: type of business abstract resource, which can

be organizational units, human jobs, organizational

positions or workflow functions (Botha & Eloff,

2001a). Within workflows, a role associates users to

a collection of workflow tasks.

Authorization Rule: type of business rule, which

relates a role with a task, stating that a user playing

this role can execute this task, if the predicate holds

true. Predicates of authorization rules can be defined

using the Object Constraints Language (OCL).

Predicates can use any of the following attributes:

– Attributes of the system, such as time and

location of access;

– Attributes of the user, for instance, his age;

– Attributes of the task, such as execution time;

– Process execution history, i.e., information about

tasks already executed, such as the username of

the executor; and

– Values of resources used as input data of tasks.

Figure 3: Work analysis refinement modelling meta-model

Step

Process

Task

Message

Tool Task

System Task

Human Task

produces

consumes

Tool

Service

System

ure 4: Loan re

uest WARM model

«system task»

Determine Score

«tool task»

Evaluate Loan

«system task»

Inform Requestor

«tool task»

Receive Loan

Request

«message»

Request + Score

«message»

Request

«message»

Answer

WORKFLOW ACCESS CONTROL FROM A BUSINESS PERSPECTIVE

Assignment Rule: type of business rule, which

relates users to roles by defining which users can

play given roles.

Additionally, we also take into account that

system tasks and tool tasks invoke information

systems and, within these information systems,

invocations might need to be authenticated in order

to be authorized. By this way, system tasks and tool

tasks can be enriched with information for

authentication purposes:

Authentication Info: information used to

authenticate (identify) tool tasks or system tasks

when they invoke information systems.

Figure 5 represents the WARM meta-model

extended with these concepts.

In the following, we explain how we use

business process model and WARM model

information to derive workflow access control

information.

To define authorization rules, firstly we identify

the tasks that need these rules: human and tool tasks.

Both these type of tasks are performed by human

workers, which have to own the needed

authorizations so they can perform them.

Then, we have to identify the roles that can

perform each of these tasks. In business process

models, swimlanes and supplying objects can be

used to define resources that are responsible for

performing steps. So, we analyse swimlanes and

supplying objects to identify if they are being used

with this semantic and we use them to derive roles

and, consequently, authorization rules by mapping

steps into their corresponding refined WARM tasks.

Additionally, business rules can also provide

information about who can perform steps. This

information is also analysed to identify and refine

authorization rules.

According to the type of roles we identify

(organizational units, humans job, organizational

positions or workflow functions), we derive role

assignment rules. To derive these rules we also use

descriptions of actor skill levels that we can find in

the tagged-value process actor.

Finally, we define authentication information for

tool tasks and system tasks. It includes:

– User identification,

– Information to authenticate the user (for

instance, a password or a certificate), and

– Information about the roles the user will assume

when the information system will be invoked

(optional).

The user, whose identification is used to invoke

the information system, can be:

– The workflow, or

– A workflow user (for instance, considering a tool

task, the workflow user that is performing it).

Considering our illustrative example, we define

authorization rules for both WARM tool tasks:

Receive Loan Request and Evaluate Loan. Analysing

the process model presented by Figure 2, we

determine three roles: Clerk, Bank Manager and

Account Manager. As we can see in this figure,

Clerk can perform the step Receive Loan Request,

which is refined on the tool task Receive Loan

Request, using the WARM methodology. A similar

mapping can be done for the other step.

To exemplify how we can define authentication

information, we suppose that the system task Inform

Requestor invokes a tool of the Mail Information

System, which implements user-based access

control. On the other hand, the system task

Determine Score and the tool tasks invoke tools of

the Evaluate Loan Information System, which

implements role-based access control.

Therefore, within the loan workflow application,

the authentication information can be defined as

follows:

– Tool tasks invoke information system tools using

the identification of the users that are performing

them and their corresponding roles;

– The system task Determine Score invokes an

information system tool using a specific user

identification (LoanWfApp) and assuming the

role ScoreCalculator; and

– The system task Inform Requestor also invokes

an information system tools using a specific user

identification (LoanWfApp).

In Figure 6 we present the loan request WARM

model extended with role information (information

about which roles can perform WARM tasks) and

authentication information, which is showed

between parentheses.

ure 5: WARM meta-model extended with access control conce

Step

Process

Task

Message

Tool Task

System Task

Human Task

produces

consumes

Tool

Service

System

Role

User

Expression

Permission

acc essT ype: exec ute

predicate

authorizationRule

assignmentRule

AuthInfo

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

Considering this information, we generate the

following workflow authorization rules:

Figure 7: Loan request workflow authorization rules

As we explain in the next section, authentication

information can be used to derive authorization rules

for information system.

Within this approach, we show how business

process model information can be used to derive

workflow authorization rules and we guarantee that

all roles have their needed authorizations so they can

perform their tasks and no more than their tasks.

5 USE CASES

As we show in the previous section, our WARM

methodology extension can be used to derive

authorization rules for workflow tasks (tool and

human). Additionally, considering that the WARM

methodology can also be used to find system use

cases, we explain how authorization rules for

information systems that implement these use cases

can be generated, as well.

Indeed, in (Vieira & Rito-Silva, 2003), the

authors also explain how WARM models can be

used to find system use cases of the components that

will implement the work logic of the business

process. The classification of tasks as human, tool

and system tasks enables the system modeller to

clearly distinguish in the WARM model different

kinds of system use cases: purely human tasks, tool

use cases and system services use cases.

Regarding human tasks, they represent tasks that

are performed by human workers without any

information system support. Therefore, they do not

have any link to system use cases and they are

mapped into the WfMS architecture as work items.

Tool use cases are identified in the WARM

model as tool tasks, which represent pieces of work

to be performed by humans assisted by a system

tool, while system services use cases are identified

in the WARM model as system service tasks and

represent functionality required to an information

system.

The actors of tool use cases and system services

use cases are determined using the authentication

information defined in their corresponding tasks. If

tasks include information about the roles the user

will assume when the information system will be

invoked, this role information is used to derive the

use case actors, as exemplified in Figure 8. Within

this picture, we point out that use case Evaluate

Loan can be done by one of the roles: Bank

Manager or Account Manager.

Evaluate Loan

Information System

ReceiveLoan

Request

ScoreCalculator

DetermineScore

EvaluateLoan

AccountManager

Clerk

BankManager

Figure 8: Three use cases of evaluate loan information

system

Otherwise, if tasks do not include role

information, the user identification is used to derive

use case actors, as illustrated in Figure

Mail

Information System

InformRequestor

ScoreCalculator

Figure 9: Inform requestor use case diagram

Based on the method proposed in (Fernandez &

Hawkins, 1997), we can determine the needed

authorizations for the information systems that

support business process from the use cases that we

obtain using the WARM methodology.

Considering our illustrative example, we derive

the following role based authorization rules for the

Evaluate Loan Information System:

Figure 10: Authorization rules for the evaluate loan

information system

Additionally, considering that the Mail

Information System uses a user-based access control

(Clerk, Receive Loan Request, execute)

(ScoreCalculator, Determine Score, execute)

(Account Manager, Evaluate Loan, execute)

(Bank Manager, Evaluate Loan, execute)

(Clerk, Receive Loan Request, execute)

(Account Manager, Evaluate Loan, execute, Request.isClient)

(Bank Manager, Evaluate Loan, execute, not Request.isClient)

Figure 6: Loan request extended WARM model

«system task»

Determine Score

(UserId=LoanWfApp

AsRole=ScoreCalculator

)

«tool task»

Evaluate Loan

Role=A.Manager if Request.isClient

Role=B.Manager if not Request.isClient

(UserId=thisTask.UserID

AsRole=thisTask.ActivRole)

«system task»

Inform Requestor

(UserId=LoanWfApp)

«tool task»

Receive Loan Request

Role=Clerk

(UserId=thisTask.UserID

AsRole=thisTask.ActivRole)

«message»

Request + Score

«message»

Request

«message»

Answer

WORKFLOW ACCESS CONTROL FROM A BUSINESS PERSPECTIVE

model, we derive the following authorization rule

for it:

Figure 11: Authorization rules for the mail information

system

In summary, with our approach, we show how

business process model information can be used to

derive not only workflow authorization rules but

also authorization rules of information systems that

support the business, while ensuring that all roles

have their needed authorizations so they can perform

their work, and no more. Additionally, we point out

that, during the workflow execution, the workflow

assumes different roles according to the task that it is

executing.

6 ENFORCING WORKFLOW

ACCESS CONTROL

The Workflow with Separation of Concerns

(WorkSCo) project is being developed based on the

new workflow architecture presented in (Manolescu,

2001) designated by micro-workflow. The WorkSCo

framework was developed using techniques specific

to object systems and compositional software reuse.

It targets software developers and provides the type

of workflow functionality necessary in object-

oriented applications. WorkSCo has a lightweight

kernel that provides basic workflow functionalities

and offers advanced workflow features as

components that can be added to the kernel.

Software developers select the features they need

and add the corresponding components to the kernel

through composition.

Access control information is added to the core

classes using the property pattern (Foote & Yoder,

1998) and authorizations are saved using access

control lists mechanism. This access control

information is generated by the described WARM

extension methodology and saved in two access

control files using the eXtensible Markup Language

(XML). One file saves roles definitions, while

authorizations rules are saved in another one. Figure

12 presents, in XML, the workflow authorization

rules generated within our request loan illustrative

example.

7 RELATED WORK

In (Fernandez and Hawkins, 1997), the authors

propose a method to determine the needed

authorizations for roles in a system by considering

use cases and sequences of use cases. They extend

use cases using security stereotypes to indicate

access constraints. Since use cases represents all the

possible functions of the system, with this approach

we can determine all the needed role authorizations

by considering the methods that need to be invoked

by corresponding actors. This approach cannot fulfil

all workflow access control requirements, since, for

instance, use cases do not represent workflow

human intervention. Moreover, our methodology

takes a step forward by ensuring that access control

information is directly related to the business.

Transaction based business process models are

used by Holbein et al. (Holbein et al., 1996a;

Holbein et al., 1996b) to derive role based access

control for workflow data, i.e., information

exchanged during the process execution. Their

approach has been used in the MobiMed project

(Nitsche et al., 1998), which aims to provide access

control to data in a clinical environment. However,

their work focuses on workflow data access control

while we approach the workflow service

perspective.

8 CONCLUSIONS AND FUTURE

WORK

WfMSs are increasingly being used to support

business process. Considering that business models

provide a good understand of the business and,

consequently, a good basis to identify information

system requirements correctly, the WARM

methodology shows how they can be used to derive

low level workflow process definitions. However,

this methodology restricts its applicability to

functional aspects.

In this paper we extend the WARM

(LoanWfApp, Inform Requestor, execute)

<Operations>execute</Operations>

<Roles>Clerk</Roles>

</ACRule>

</ACWorkflowActivityPolicy>

<Operations>execute</Operations>

<Roles>AccountManager</Roles>

<Constraint>request.isClient</Constraint>

</ACRule>

<Operations>execute</Operations>

<Roles>BankManager</Roles>

<Constraint>not request.isClient</Constraint>

</ACRule>

</ACWorkflowActPolicy>

</ACWorkflowPolic

ure 12: Workflow authorization rules

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

methodology to derive workflow access control

information from business process models.

Additionally, we show how this methodology can

also be used to derive authorization rules for

information systems that support the business.

Our approach reduces the effort required to

define the workflow access control because it can be

derived from business process and WARM models,

which are not developed, but only used with access

control purposes. Therefore, we ensure that

workflow authorization rules are directly related to

the business, instead of being added to the workflow

as an afterthought based on the application

perspective. Similarly, authorization rules for

information systems that implement business

process are related to the workflow process

definition and, consequently, to the business.

Finally, our approach also guarantees the least

privileged principle by ensuring that each role has

the needed authorizations to perform its functions

and no more.

We are evaluating and developing a prototype

implementation of our methodology in the context of

the COMBINE (COMponent-Based Interoperable

Enterprise system development) project funded by

the V Framework IST-1999-20893, where it is being

tested in more real situations.

REFERENCES

Atluri, V., & Huang, W. (1996). An authorization Model

for workflows. In Proceedings of the 5th European

symposium on research in computer security. Rome,

Italy, pp 44-64.

Bertino, E., Ferrari. E., & Atluri, V. (1999). The

specification and enforcement of authorization

constraint in workflow management systems. ACM

Transactions on Information and System Security, vol.

2, nº1, pp. 65-104.

Bittner, K., Spence, I., & Jacobson, I. (2002). Use Case

Modeling. Addison Wesley Professional.

Botha, R.A., & Eloff, J.H.P. (2001a). Designing Role

Hierarchies for Access Control In Workflow Systems.

In Proceedings of the 25th Annual International

Computer Software and Applications Conference

(COMPSAC'01), Chicago, Illinois.

Botha, R.A., & Eloff, J.H.P. (2001b). Separation of Duties

for Access Control in Workflow Environments. IBM

Systems Journal. vol. 40, no. 3, pp. 666-682.

Casati, F., Castano, S. & Fugini, M. (1999). Managing

Workflow Authorization Constraints through Active

Database Technology. Information Systems Frontiers,

3, 3.

Eriksson, H., & Penker, M. (2000). Business Modeling

with UML, Business Patterns at Work. John Wiley &

Sons.

Fernandez, E.B., & Hawkins, J.C. (November 1997).

Determining role rights from use cases. In Proceedings

of the 2nd ACM Workshop on Role-Based Access

Control, pp. 121-125.

Foote, B., & Yoder, J. (August 1998). Metadata and

Active Objects-Models. In Proceedings of the Fifth

Conference on Pattern Languages of Programs (PLOP

98). Illinois, USA.

Holbein, R., Teufel, S., & Bauknecht, K. (1996a). A

Formal Security Design Approach for Information

Exchange in Organisations. In proceedings of the 9th

annual IFIP TC11 WG11.3 working conference on

Database security IX : status and prospects. 267-285.

Holbein, R., Teufel, S., & Bauknecht, K. (1996b). The use

of business process models for security design in

organisations. In Proceedings of 20th International

Conference on Information Security (IFIP SEC96 TC

11), Samos, Greece, Chapman & Hall, London, UK,

13-22.

Hollingsworth, D. (1995). The Workflow Reference

Model. Document Number TC-00-1003. Issue 1.1.

Kandala, S., & Sandhu, R. (2001). Secure Role-Based

Workflow Models. In Proceedings of the 15th Annual

IFIP WG 11.3. Canada.

Kang, M., Park, J. & Froscher, J. (2001). Access Control

Mechanisms for Inter-Organizational Workflow. In

Proceedings of the 6th ACM Symposium on Access

Control Models and Technologies, Chantilly, VA, 66–

74.

Manolescu, D. (2001). Micro-workflow: a workflow

architecture supporting compositional object-oriented

software development. PhD Thesis. University of

Illinois at Urbana-Champaign.

Miller, J., Fan, M., Wu, S., Arpinar, I., Sheth, A. &

Kochut, K. (1999). Security for the METEOR

Workflow Management System. Technical Report

#UGA-CS-LSDIS-TR-99-010, University of Georgia,

33 pages.

Nitsche, U., Holbein, R., Morger, O., & Teufel, S. (1998).

Realization of a Context-Dependent Access Control

Mechanism on a Commercial Platform. In Proceedings

of the 14th Int. Information Security Conf. IFIP/Sec'98,

part of the 15th IFIP World Computer Congress, pp

160-170.

Sandhu, R., Coyne, E., Feinstein, H. & Youman, C.

(1996). ‘Role-Based Access Control Models’. IEEE

Computer, vol. 29, no. 2.

Sharp, A., & McDermott, P. (2002). Workflow Modeling:

Tools for Process Improvement and Application

Development. Artech House.

Thomas, R., & Sandhu, R. (1997). Task-based

Authorization Controls (TBAC): A Family of Models

for Active and Enterprise-oriented Authorization

Management. In proceedings of the IFIP WG11.3

Workshop on Database Security, Lake Tahoe,

California.

Vieira, P., & Rito-Silva, A. (2003). Work Analysis

Refinement Modeling. INESC-ID Technical Report.

WORKFLOW ACCESS CONTROL FROM A BUSINESS PERSPECTIVE