SUPPORTING AUTHENTICATION REQUIREMENTS IN

WORKFLOWS

Ricardo Martinho

School of Technology and Management, Polytechnic Institute of Leiria

Morro do Lena, Alto do Vieiro - 2411-901 Leiria, Portugal

Dulce Domingos

Faculty of Sciences, University of Lisbon

Campo Grande, Edif

ıcio CS - 1749-016 Lisboa, Portugal

Ant

onio Rito-Silva

INESC-ID Software Engineering Group, Technical University of Lisbon

Rua Alves Redol 9, 6.

◦

- 1000-029 Lisboa, Portugal

Keywords:

Workﬂow authentication requirements, authorization constraints, Role-based access control.

Abstract:

Workﬂow technology represents nowadays signiﬁcant added value to organizations that use information sys-

tems to support their business processes. By their nature, workﬂows support the integration of different in-

formation systems. As organizations use workﬂows increasingly, workﬂows manipulate more valuable and

sensitive data. Either by interoperability issues or by the value of data manipulated, a workﬂow may present

several and distinct authentication requirements. Typically, information systems deal with their authentication

requirements once, within their authentication process. This strategy cannot be easily applied to workﬂows

since each workﬂow activity may present its own authentication requirements. In this paper we identify au-

thentication requirements that workﬂows present and we propose to meet these requirements by incorporating

authentication constraints into workﬂow authorization deﬁnitions. With this purpose, we extend a generic

Role-Based Access Control (RBAC) model and we deﬁne an access control algorithm that supports and en-

forces authorization decisions constrained by authentication information.

1 INTRODUCTION

Due to the increasing need of being digitally enabled,

organizations often adopt workﬂows and Workﬂow

Management Systems (WfMSs) to model and exe-

cute their main business processes. Digital workﬂows

have reduced the cost of operations in many compa-

nies by displacing paper and related manual routines.

By using workﬂow technology many corporations not

only cut costs signiﬁcantly but also improve customer

service.

In (Workﬂow Management Coalition, 1999) the

WfMC deﬁnes workﬂow as a concept that is usu-

ally associated with the automation of a business

process where documents, information and activities

are passed among participants according to some set

of rules. The business process is modeled under a

process deﬁnition, also called a workﬂow deﬁnition.

A workﬂow deﬁnition may be composed of other

sub-workﬂow deﬁnitions, activities (manual or auto-

mated), rules and control data.

A WfMS is an information system that interprets

workﬂow deﬁnitions and creates and manages work-

ﬂow instances as they are executed. The enactment

of a workﬂow deﬁnition may derive in one or more

workﬂow instances, which in turn include one or

more activity instances. Activity instances are the

runtime representation of the activities identiﬁed in

the workﬂow deﬁnition, and may include work items

(activitiesallocated to a workﬂow user) or invoked ap-

plications (information systems used to support activ-

ity execution). A workﬂow user is a resource which

performs the work represented by a workﬂow activity

instance. This user is usually associated with a human

being, but it may also be a group of human beings, an

automated process or a computer system.

Typically, authentication is the initial security step

for users who want to interact with information sys-

tems, in general, as well as WfMSs and their work-

ﬂow activities. The goal of authentication is to con-

ﬁrm a user’s asserted principal identity with a spec-

iﬁed, or understood, level of conﬁdence. Different

181

Martinho R., Domingos D. and Rito-Silva A. (2006).

SUPPORTING AUTHENTICATION REQUIREMENTS IN WORKFLOWS.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 181-188

DOI: 10.5220/0002465701810188

 SciTePress

authentication mechanisms provide different levels of

conﬁdence. For instance, an authentication mecha-

nism that uses ﬁngerprints provides typically a higher

level of conﬁdence than another one that uses a pass-

word (Kent and Millett, 2003).

However, for some workﬂow scenarios, users need

to have several principal identities with different lev-

els of conﬁdence and/or authenticated by different

means. Indeed, workﬂow activities may present dif-

ferent levels of conﬁdence requirements depending on

their functionality and/or the sensitiveness of the data

they manipulate.

On the other hand, a workﬂow may model within

its activities the invocation of different information

systems (Hung and Karlapalem, 2003) and those sys-

tems may require distinct authentication mechanisms

and protocols. For example, a workﬂow activity may

invoke a web service that requires a user principal to

be authenticated under the WSSecurity protocol.

Additionally, if authentication requires workﬂow

history information, this information cannot yet ex-

ist when the initial authentication process occurs. For

instance, if a workﬂow has an activity that requires

a user principal to have a higher level of conﬁdence

than the user principal that has executed a previous

activity, this constraint can only be evaluated if the

previous activity has already been executed.

In this paper we ﬁrstly systematize authentica-

tion requirements that workﬂows present: workﬂows

present authentication requirements involving user

principals’ context authentication; information that is

already used for authorization purposes; and work-

ﬂow history authentication information. To meet

these authentication requirements, we propose to in-

clude authentication constraints into the deﬁnition of

workﬂow authorizations. As WfMSs often use a

Role-based Access Control (RBAC) model to protect

workﬂow activities, we extend it to support authoriza-

tions with authentication-based constraints. Finally,

to evaluate authorizations with authentication-based

constraints, we also propose an algorithm for an ac-

cess decision function. By implementing this algo-

rithm, the access decision function is capable of in-

forming the WfMS that it needs additional informa-

tion to support an authorization decision, upon a re-

quest made to a workﬂow activity with authentication

requirements.

The remainder of this paper is organized as follows:

in section 2 we present related work. In section 3 we

describe a workﬂow example with authentication re-

quirements. In section 4 we systematize workﬂow au-

thentication requirements, we deﬁne an RBAC exten-

sion that supports authorizations with authentication-

based constraints and an algorithm to enforce these

authorizations. Finally, in section 5 we present some

conclusions and future work.

2 RELATED WORK

The idea of meeting authentication requirements

within access control models is not new. In (Wang

et al., 2004), the authors propose an RBAC model that

includes authentication information in order to dy-

namically assign users to roles in an operating system

environment. Access rights are determined through

the concept of a user’s authentication trustworthiness,

which is bounded to the strength of the authentica-

tion mechanism used. In (Moodahi et al., 2004) the

authors present a workﬂow access control model that

also uses authentication information to constrain the

assignment of users to roles (UA relationship). These

approaches handle authentication information in the

initial authentication process, not solving the prob-

lem of meeting various workﬂow authentication re-

quirements that may emerge as workﬂows are loaded

and instantiated after that initial process. Another

disadvantage is that constraining the UA relationship

based on authentication information may lead to role

proliferation (like having “password manager” and

“certiﬁcate-based manager” roles).

In (Tzelepi and Pangalos, 2001) the authors pro-

pose an extension to the RBAC model to protect med-

ical imaging ﬁles stored on a database. They sup-

port the deﬁnition of authorizations that include con-

straints with domain and location authentication at-

tributes. In our work we go one step forward by

supporting generic authentication attributes as well as

workﬂow speciﬁc authentication information (the his-

tory information).

As RBAC models are widely used in WfMSs, our

purpose is to incorporate authentication-based con-

straints into the deﬁnition of RBAC authorizations.

In the following, we overview the RBAC model and

how some authors have extended this model to sup-

port constraints.

The basic notion of RBAC is controlling access to

resources accounting for the roles that users under-

take, rather than on an individual user basis. This way

complexity is reduced because roles are usually less

than users in an organization. Furthermore, revoking

and re-granting authorizations are avoided when users

change their roles within the organization.

Important contributions to standardize a generic

RBAC model may be found in (Ferraiolo et al., 2001).

The generic architecture of this model is presented in

Figure 1.

The main components depicted are users, ses-

sions, roles, roles hierarchy (RH), permissions, user-

assignment (UA) relationships and permission assign-

ment (PA) relationships. It also comprises separation

of duty constraints, either being static (SSD) between

users and roles, or dynamic (DSD) between sessions

and roles.

In general, to increase authorizations’ expressive-

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

182

User Role

Session

SSD

DSD

session_roles

user_sessions

Operation Resource

Permission

Figure 1: Generic RBAC model.

ness, access control models support the deﬁnition of

authorizations with constraints to restrict their valid-

ity (Samarati and di Vimercati, 2000). Constraints

may refer to different kinds of information, such as

(Beznosov, 1998):

• User attributes, like age or nationality;

• Object attributes (content-based access control);

• External conditions like access time and location

(context-based access control);

• Access history (history-based access control); and

• Component relationships.

In (Kandala and Sandhu, 2002) the authors extend

the RBAC model to WfMSs. They interpret the per-

mission concept by identifying the objects of the sys-

tem that need protection (activities and activity in-

stances) and the operations that can be executed on

them. The main purpose of workﬂow access con-

trol models is to increase authorization expressive-

ness with constraints that are workﬂow speciﬁc: con-

straints that support dynamic separation and junction

of duty policies. These constraints deﬁne security

policies that prevent or force a certain user to execute

two or more correlated activities (Casati et al., 1998;

Bertino et al., 1999; Casati et al., 2001). However,

these approaches do not address authentication-based

constraints inferred from workﬂow authentication re-

quirements.

3 WORKFLOW

AUTHENTICATION

REQUIREMENTS: AN

EXAMPLE

In this section we exemplify different types of au-

thentication requirements that may be presented by a

workﬂow and related activities, by using a simpliﬁed

Loan Approval workﬂow (Figure 2).

Authorizations are deﬁned taking into account the

roles that users play in the bank. Each role has the fol-

lowing authorizations: Branch clerks may a

) receive

Loan Approval

Branch Manager General ManagerBranch Clerk

<<work item>>

Calculate Total

Rate

<<work item>>

Evaluate Loan

<<work item>>

Receive Loan

Request

a11

<<work item>>

Inform Client

<<work item>>

Submit for

Approval

<<invoked app>>

Get indexed

rates

<<work item>>

Perform Final

Credit Analysis

<<invoked app>>

Get Client Data

from other Banks

<<work item>>

Perform Preliminary

Credit Analysis

<<invoked app>>

Get Client

Data

a10

<<work item>>

Figure 2: Loan Approval workﬂow example.

loan requests from clients and check the correspond-

ing data; and a

) inform clients about the result of

their loan requests. Branch managers may a

) per-

form preliminary credit analysis; launch invoked ap-

plications to a

) retrieve data from clients and a

) get

indexed international rates; a

) calculate the total loan

rate; a

) submit loans for approval; and a

) register

loan approval answers. General managers may a

)

perform ﬁnal credit analysis on clients; a

) invoke an

application to retrieve data from other ﬁnancial insti-

tutions; and a

) evaluate the loan viability.

Now lets consider the following authentication re-

quirements for the workﬂow shown in Figure 2:

• R

- All workﬂow activities require that users pos-

sess an authenticated principal identity belonging

to a bank.org domain;

• R

- Activity a

requires a user princi-

pal identity authenticated by an identity

provider iDP, with an authentication service

at http://www.idp.org/authnService, and with a

stronger mechanism than the one of the user

principal identity which executed activity a

• R

- Activity a

requires a user principal iden-

tity authenticated with a password over an Secure

Sockets Layer (SSL) protected session;

• R

- If the loan value involved in the workﬂow in-

SUPPORTING AUTHENTICATION REQUIREMENTS IN WORKFLOWS

183

stance is higher than $100,000 then activity a

re-

quires a user principal identity authenticated under

a two-factor authentication mechanism, being com-

posed by a smartcard and an activation PIN;

• R

- Activity a

requires the same user principal

identity on which behalf was granted access to ac-

tivity a

As illustrated by this example, workﬂows may

present authentication requirements based on differ-

ent types of information. In the next section we sys-

tematize workﬂow authentication requirements and

propose an access control model that supports the

deﬁnition of authorizations with authentication-based

constraints. We also present an access control algo-

rithm that is capable of identifying additional needed

information, in order to evaluate authorization deci-

sions that include authentication requirements.

4 DEFINING AND SUPPORTING

WORKFLOW

AUTHENTICATION

REQUIREMENTS

Our approach to support workﬂow authentication re-

quirements includes three correlated issues:

1. Systematizing workﬂow authentication require-

ments - this includes identifying and categorizing

requirements by the type of information that they

can use;

2. Deﬁning an extended RBAC model to support au-

thorizations that include authentication-based con-

straints; and

3. Enforcing authorization decisions that include

authentication-based constraints.

In the next sections we expand and propose solutions

for each of these items.

4.1 Systematizing Workﬂow

Authentication Requirements

To systematize workﬂow authentication requirements

we take the following approach:

1. We identify generic authentication context in-

formation - this refers to pure technical authen-

tication context information that a user principal

identity must meet in order to access a workﬂow

activity. This information may expand on (OASIS,

2005):

• User principal information - information about

the principal identiﬁer (e.g. foo), domain (e.g.

bar.net) and group membership from where a

user’s digital entity is registered (e.g. an LDAP-

enabled identity provider). Examples include a

workﬂow activity a

with an authentication re-

quirement stating that authorization permissions

are only granted to a principal with the identi-

ﬁer foo@bar.net; or a workﬂow w

that requires

users to possess principal identities from domain

bar.net (like the R

requirement deﬁned in sec-

tion 3);

• Identity provider information - information

about the identity provider and corresponding

authentication services that are supposed to have

authenticated the user’s principal identity. This

can include the identity provider’s name, loca-

tion (e.g. an URL), and authentication service

bindings and locations;

• Authentication context information - character-

istics about the processes, procedures and mech-

anisms by which a principal identity must have

been authenticated by the identity provider, in

order to access a workﬂow activity. These char-

acteristics may be categorized as follows:

– Identiﬁcation mechanism - characteristics of

the processes and mechanisms used by the

identity provider to initially create an associa-

tion between a user and the identity by which

he will be known. Examples include face-to-

face, online and shared secret identiﬁcation;

– Credential protection - characteristics that de-

scribe how the “secret” (the knowledge or pos-

session of which allows the user to authenticate

to the authentication authority) is kept secure;

– Authentication method - characteristics that de-

ﬁne the mechanisms by which the user authen-

ticates to the authentication authority (for ex-

ample, a password versus a smartcard, or even

multifactor authentication, requiring more than

one mechanism). The R

requirement deﬁned

in section 3 is an example of an authentication

method requirement.

2. We identify access control context information -

this includes information that can be derived from

the access request context, and that is already used

to constrain authorizations to workﬂow activities,

namely:

• Generic access control information:

– User attributes, like age or nationality;

– Object attributes (content-based access con-

trol);

– External conditions like access time and loca-

tion (context-based access control);

– Access history (history-based access control);

and

– Component relationships.

For example, an authentication requirement

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

184

may be deﬁned stating that, if a workﬂow ac-

tivity is accessed from a workstation in a public

location, then users are required to present an

extra authenticator (for example, a Social Se-

curity Number identiﬁer);

• Workﬂow access control information - this refers

to information used to deﬁne an authentication

requirement that may be based on:

– Workﬂow history, i.e., information about activ-

ity instances already executed;

– Values of their input data - the R

requirement

deﬁned in section 3 deﬁnes a condition for the

authentication mechanism to use if the loan re-

quest to approve surpasses a determined value.

3. We identify workﬂow speciﬁc authentication in-

formation - this refers to authentication informa-

tion used in the execution of workﬂow activities.

The R

and R

requirements deﬁned in section 3

are examples of authentication requirements that

refer to authentication contexts used on previous

activities. The R

requirement presents also a kind

of a junction of duty constraint, as it forces the

same user principal identity to be used in access-

ing both a

and a

workﬂow activities.

4.2 Deﬁning RBAC Authorizations

with Authentication Constraints

Deﬁning an authentication requirement for a work-

ﬂow activity may be accomplished by extending

corresponding authorization deﬁnitions in the work-

ﬂow deﬁnition, adding it authentication-speciﬁc con-

straints.

WfMSs have limited advance planning, i.e., work-

ﬂows can be loaded and instantiated at any moment,

and users cannot foresee with which activities are they

supposed to interact. Thus, in an RBAC model, pre-

vious authorizations are given by assigning roles to

users, based on principal identities authenticated in

a reference domain (like the bank.org domain in our

workﬂow example described in section 3). For ex-

ample, even if a user u

does not possess a principal

identity that satisﬁes a workﬂow activity authentica-

tion requirement, the roles associated with his refer-

ence domain principal identity may allow him to see

and begin an interaction with his role-based assigned

activities. This can be accomplished by manipulating

visibility properties of workﬂow activities (Muehlen,

2004). After picking up an activity for interaction, the

access control manager may then evaluate if that user

has principals that can satisfy a pre-deﬁned activity

authentication requirement.

This is a kind of lazy authorization decision-

making evaluation that complies with most WfMSs’

poor advanced planning. Therefore, we present in

Figure 3 our proposed extended workﬂow RBAC

User Role

Session

session_roles

user_sessions

Activity

Permission

Principal

Operation

Constraint

SSD

DSD

Figure 3: An extended RBAC workﬂow model for support-

ing authentication constraints.

model for supporting authentication requirements as

authorization decision constraints that restrict the per-

mission assignment (PA) relationship.

Differences between this model and the generic one

referred in Figure 1 include:

• Principal - represents information about a user

principal identity. Users may have several princi-

pals in order to interact with workﬂow activities,

and authentication constraints may refer to speciﬁc

principals or principal authentication contexts;

• Constraint - represents constraints that restricts

a role-permission (PA) relationship and can also in-

clude authentication information.

An authentication constraint may be modeled into

a workﬂow RBAC authorization rule as a tuple (r, a,

execute, cn) that states that a user principal u playing

role r can execute activity a if the constraint cn is met.

We present in Appendix A an XML

deﬁnition for

the workﬂow example of Figure 2, including formal

deﬁnitions of the authentication requirements identi-

ﬁed. Activity deﬁnition details were omitted. We in-

clude access control rules to specify role-permission

assignments (XML <actACRule> elements), and

authorization constraints for those assignments (XML

<actACConstraint> elements). We deﬁne au-

thentication requirements as authorization constraints

under the child XML <authConstraint> ele-

ment. For size reasons, only activities with authen-

tication constraints are deﬁned.

4.3 Enforcing Authorization

Decisions that Include

Authentication Constraints

Enforcing authorization decisions that include au-

thentication constraints present two correlated chal-

lenges:

We use the XML language to enhance reading and

comprehension. The speciﬁcation or adoption of a stan-

dard schema to deﬁne authentication requirements is rec-

ommendable, yet out of the scope of this paper.

SUPPORTING AUTHENTICATION REQUIREMENTS IN WORKFLOWS

185

1. What to do when authentication requirements

are not met by lack of information - we con-

sider that authorization decision results may have

three different values: REJECT , ACCEP T and

ADDITIONAL. The ADDI T I ONAL value

means that the access control decision function

could not resolve the authentication constraints,

and needs more information to do so. How to han-

dle this ADDI T I ONAL result is somehow a par-

ticular security policy decision that can be solved

by the WfMS opting from:

• Rejecting or accepting the access request; or

• Getting the additional information required to

support the authorization decision.

2. How to request for additional authentication infor-

mation to support authorization decisions - when a

user requests access to a workﬂow activity with au-

thentication requirements, the context information

available in the request might not be sufﬁcient to

make an authorization decision. Regarding a user’s

authentication context, the WfMS must identify the

required additional information and communicate

it to the requesting user agent (e.g. a web-based

application). For the speciﬁc workﬂow history in-

formation, the WfMS must save the authentication

context with which each workﬂow activity is ex-

ecuted, in order to consult and compare that in-

formation when evaluating an authentication con-

straint for a subsequent workﬂow activity access

request.

In Algorithm 1 we present an algorithm for an ac-

cess decision function that processes an access re-

quest made on behalf of a user u with a role r to up-

hold permission p on a given workﬂow activity a with

a list of authentication constraints cntList.

We consider the ADDI T I ONAL return state as

a set of attribute identiﬁers gathered along the evalua-

tion of each authentication constraint, corresponding

to additional information needed to evaluate the

access request. For example, when a user’s principal

identity u, authenticated with a password authen-

ticator through a web-based client application and

authorized to play the Branch manager role, wants

to execute activity a

from our workﬂow scenario,

the WfMS receives an access request containing the

user’s principal authentication context information.

That information is then compared with the authenti-

cation constraint deﬁned for activity a

(see element

<authConstraint> for a

in Appendix A). If the

user’s principal authentication context information

does not refer the authenticator’s transport proto-

col used in the authentication process, the access

control decision function returns ADDI T IONAL.

This ADDI T I ONAL state refers to a set of

attribute identiﬁers containing, in this case, the

Algorithm: Access control decision function

Input: an access request from user u with role r

to uphold permission p over activity a

with a list of constraints cntList

Output: [1] REJECT , [2] ACCEP T ,

[3] ADDIT IONAL - Set of attribute identiﬁers

begin

if userRole(u,r) and

rolePermission(r,a,p) then

foreach cnt in cntList do

result ← evalCnt(u,cnt)

switch result do

case 0 return RE JECT

case 1 continue

otherwise

put result in

ADDITIONAL

end

if ADDI T IONAL is empty then

return ACCEP T

else return ADDIT I ONAL

else return RE JECT

end

userRole(u,r) returns TRUE if a user u is

authorized to play role r, else returns FALSE

rolePermission(r,a,p) returns TRUE if

role r has permission p over activity a, else

returns FALSE

evalCnt(u,cnt) returns 0 if the constraint was

not satisﬁed, 1 if the constraint was satisﬁed, and

an attribute identiﬁer if an additional user

attribute is needed to evaluate the constraint.

Algorithm 1: Algorithm for processing a constrained ac-

cess decision on a workﬂow activity.

identiﬁer, as the constraint demands for the use of

the SSL protocol and there is no way for the access

control decision function to know which one was

used to obtain the user’s principal identity. Other-

wise, the access control decision function returns

REJECT on the ﬁrst constraint not met by the

user’s authentication context, or ACCEP T if all

constraints are met.

5 CONCLUSIONS AND FUTURE

WORK

As organizations use workﬂow technology increas-

ingly, many problems cannot be ignored anymore nei-

ther solved with ad-hoc solutions. In this paper we

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

186

identify and systematize workﬂow authentication re-

quirements. We propose to meet these requirements

by supporting authorizations with authentication-

based constraints. With this purpose we deﬁne an

extension to the RBAC model and propose an algo-

rithm that enforces these authorizations. With our ap-

proach, users do not need to satisfy, in the initial au-

thentication process, all workﬂow authentication re-

quirements, since they are only evaluated when they

request access to activities. Moreover, when a user

does not possess all the required authentication infor-

mation, the access control decision function notiﬁes

the WfMS, that can choose how to proceed.

We are implementing workﬂow authentication re-

quirements in a WfMS called WorkSCo (Workﬂow

with Separation of Concerns) (INESC Lisboa Soft-

ware Engineering Group, 2004). WorkSCo already

uses an RBAC model that needs to be extended in

order to provide evaluation and enforcement of au-

thentication constraints. As to communications be-

tween WorkSCo and exterior identity providers, we

intend to adopt a standard called Security Assertion

Markup Language (SAML)(OASIS, 2005). SAML

is an XML-based framework for communicating user

authentication, entitlement and attribute information.

SAML-enabled systems may exchange authentication

information on users, independently of their hetero-

geneous software and hardware environments. Mes-

sages exchanged must obey to SAML deﬁned XML

schemas and protocols that will enable the WorkSCo

WfMS to query different identity providers and con-

sume produced SAML authentication assertions, in

order to produce and enforce authorization decisions

that include authentication constraints.

REFERENCES

Bertino, E., Ferrari, E., and Atluri, V. (1999). The Speciﬁ-

cation and Enforcement of Authorization Constraints

in Workﬂow Management Systems. ACM Trans. Inf.

Syst. Secur., 2(1):65–104.

Beznosov, K. (1998). Requirements for access control: Us

healthcare domain. In RBAC ’98: Proceedings of the

third ACM workshop on Role-based access control,

page 43, New York, NY, USA. ACM Press.

Casati, F., Castano, S., and Fugini, M. (2001). Manag-

ing workﬂow authorization constraints through active

database technology. Information Systems Frontiers,

3(3):319–338.

Casati, F., Castano, S., and Fugini, M. G. (1998). Enforc-

ing workﬂow authorization constraints using triggers.

Journal of Computer Security, 6(4):257–285.

Ferraiolo, D. F., Sandhu, R. S., Gavrila, S. I., Kuhn, D. R.,

and Chandramouli, R. (2001). Proposed NIST Stan-

dard for Role-based Access Control. Information and

System Security, 4(3):224–274.

Hung, P. C. K. and Karlapalem, K. (2003). A secure

workﬂow model. In CRPITS ’03: Proceedings of

the Australasian information security workshop con-

ference on ACSW frontiers 2003, pages 33–41, Dar-

linghurst, Australia, Australia. Australian Computer

Society, Inc.

INESC Lisboa Software Engineering Group (2004).

WorkSCo: Workﬂow with Separation of Concerns.

http://sourceforge.net/projects/worksco/.

Kandala, S. and Sandhu, R. (2002). Secure Role-Based

Workﬂow Models. In DAS’01: Proceedings of the ﬁf-

teenth Annual Working Conference on Database and

Application Security, pages 45–58, Niagara, Ontario,

Canada. Kluwer Academic Publishers.

Kent, S. T. and Millett, L. I., editors (2003). Who goes

There? Authentication Through the Lens of Privacy.

National Academies Press, Washington, DC, USA.

Moodahi, I., Gudes, E., Lavee, O., and Meisels, A. (2004).

A Secure Workﬂow Model Based on Distributed Con-

strained Role and Task Assignment for the Inter-

net. In ICICS’04: Proceedings of the sixth In-

ternational Conference on Information and Commu-

nications Security, pages 171–186, Malaga, Spain.

Springer-Verlag.

Muehlen, M. Z. (2004). Organizational Management in

Workﬂow Applications – Issues and Perspectives. Inf.

Tech. and Management, 5(3-4):271–291.

OASIS (2005). SAML V2.0 Executive Overview. Technical

report, Organization for Advancement of Structured

Information Standards.

Samarati, P. and di Vimercati, S. D. C. (2000). Access Con-

trol: Policies, Models, and Mechanisms. In FOSAD

’00: Revised versions of lectures given during the

IFIP WG 1.7 International School on Foundations of

Security Analysis and Design, pages 137–196, Berti-

noro, Italy. Springer-Verlag.

Tzelepi, S. and Pangalos, G. (2001). A ﬂexible access con-

trol model for multimedia medical image security. In

PCM ’01: Proceedings of the Second IEEE Paciﬁc

Rim Conference on Multimedia, pages 1030–1035,

Beijing, China. Springer-Verlag.

Wang, L., Wei, L., Liao, X., and Wang, H. (2004).

AT-RBAC: An Authentication Trustworthiness-Based

RBAC Model. In GCC Workshops, pages 343–350,

Wuhan, China. Springer-Verlag.

Workﬂow Management Coalition (1999). Terminology &

Glossary. Technical report, Workﬂow Management

Coalition.

SUPPORTING AUTHENTICATION REQUIREMENTS IN WORKFLOWS

187

APPENDIX A

An XML Workﬂow Deﬁnition Example with Authentication Constraints

<wfDefinition workflowID="w1" name="Loan Approval">...

<user>

</principalID>

</user>

</authConstraint>

</wfACConstraint>...

<actDefinition activityID="a3" type="invoked app" name="Get Client Data">...

<actRole>Branch manager</actRole>

<actOperation>execute</actOperation>

</actACRule>

<location>http://www.idp.org/authnService</location>

<binding>HTTP-binding</binding>

</authenticationService>

</provider>

</principalAuthnMech>

</authConstraint>

</actACConstraint>

</actDefinition>

<actDefinition activityID="a4" type="invoked app" name="Get Indexed Rates">...

<actRole>Branch manager</actRole>

<actOperation>execute</actOperation>

</actACRule>

<authenticatorType>password</authenticatorType>

</authMethod>

</authConstraint>

</actACConstraint>

</actDefinition>...

<actDefinition activityID="a9" type="work item" name="Evaluate Loan">...

<actRole>General manager</actRole>

<actOperation>execute</actOperation>

</actACRule>

<keyActivation>ActivationPin</keyActivation>

</privateKeyProtection>

</techProtection>

<principalAuthnMech>smartcard</principalAuthnMech>

<authenticator>asymmetricKeyDecryption</authenticator>

</authnConstraint>

</actACConstraint>

</actDefinition>...

<actDefinition activityID="a11" type="work item" name="Inform Client">...

<actRole>Branch clerk</actRole>

<actOperation>execute</actOperation>

</actACRule>

<user>

</principalID>

</user>

</actACConstraint>

</actDefinition>

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

188