Security in Web-Based Work ow Management Systems ... - CiteSeerX

Security in Web-Based Work ow Management Systems John A. Miller, Mei Fan, Amit P. Sheth and Krys J. Kochut Large Scale Distributed Information Systems Lab (LSDIS) Department of Computer Science The University of Georgia Athens, GA 30602-7404 email: [email protected] URL: http://LSDIS.cs.uga.edu

Abstract Web-based work ows are increasingly becoming a viable choice for work ows that span multiple organizations. Until recently, Web technology has not been terribly secure. However, by utilizing appropriate encryption algorithms, digital signatures and access control (role-based/multilevel security), Web-based Work ow Management Systems can be made secure. Since these systems include many subsystems (Operating System, Database System, etc.) and may involve multiple organizations, complete security solutions are enormously complex. In this paper, we sort out some of the more promising security alternatives and organize them into a security architecture suitable for Web-based work ows. Research issues addressed include how to provide convenient, yet reliable work ow-wide authentication, how to share data objects which are under dierent authorizations, how to combine role-base access control and multilevel security, and how to provide high security without signi cantly reducing performance of a distributed WfMS. This security architecture is being implemented by enhancing the METEOR/WebWork Web-based Work ow Management System developed in the LSDIS lab at the University of Georgia to provide a testbed for comparing the alternatives presented in the paper.

1 Introduction As the popularity of work ow continues to grow and invade more and more application domains (healthcare, military, electronic commerce, etc.), security becomes an evermore vital concern. Since work ows can span multiple organizations and interface with all sorts of existing applications, security issues can become quite complex. As Web-based work ows may be rapidly deployed over large geographical areas and involve several organizations, they potentially represent a major security risk. This paper focuses on security for Web-based Work ow Management Systems (WfMSs) because of their importance and associated risk. In addition, security approaches useful for Web-based WfMSs will also be useful in other types of WfMSs. In the METEOR project, we have an ideal testbed with which to explore several security issues for Web-based work ows. We have devel1

oped a Web-Based WfMS, METEOR/WebWork [MPS+ 97, She96], which is commercially available through Infocosm, Inc. Two key aspects of security will be addressed in depth in this paper, secure communication and access control. Secure communication makes it impossible to intercept and make any sense out of messages sent across networks. It can also reliably establish the identity of the originator of the message and ensure the message was not tampered with. Access control is used to limit what users can do. Conventionally, access control is described in terms of subjects (who can access) and objects (what they can access). For work ow, it is natural to describe security in terms of subjects, verbs and objects. The subjects are the users, the verbs are the tasks, and objects are the data objects (e.g., work ow, le or database objects). We are developing and testing two types of security implementations for our Web-based Work ow Management System. Both implementations will encrypt messages sent over networks and will utilize digital signatures for authentication and data integrity. They dier in access control. 

The rst implementation will use Role-Based Access Control (RBAC). This implementation will provide the option of considering just subjects and verbs. This will implicitly involve objects, since as the work ow designer assigns roles to tasks, s/he will be aware of what the task does (i.e., what objects it accesses). Alternatively, the security of data objects may be explicitly dealt with.



The second implementation will deal with data objects and ow of information in a rigorous way. It will enforce Multilevel Security (MLS) needed in highly secure domains. Within a security domain or level, RBAC may be used.

In this paper, common security services and mechanisms for the Web and Web-based work ow will be discussed with alternatives considered for inclusion into a security architecture suitable for Web-based work ow. The main goal of the security architecture is to allow the degree of security to be adjusted to the requirements of the work ow at hand. Given a degree of security, performance and usability should be maximized. For example, performance and usability would suer if a complete user authentication process was performed for each individual task the user performs. Digital signatures make this unnecessary. Similarly, encrypting messages with public key algorithms trades o more security for less performance. Another example concerns administration of work ows. If a new user joins an organization and needs to participate in several work ows, the job of setting up his security pro le can be tedious and error prone. Today, the best general purpose solution to simplying security administration appears to be RBAC. This still leaves questions as to how to associate roles to work ows and multiple participating organizations. Should roles only be assigned to tasks or also to data objects? Is RBAC suitable for high security work ows, for example in military domains?

2

1.1 Overview of Web-Based Work ow Management Systems Work ow Management Systems (WfMSs) provide an automated framework for managing intra- and inter-enterprise business processes. According to the Work ow Management Coalition (WfMC), a Work ow Management System is a set of tools providing support for process de nition, work ow enactment, and administration and monitoring of work ow processes [Hol94]. Application domains where work ow technology is currently in use includes healthcare, education, telecommunications, manufacturing, nance and banking and oce automation. WfMSs are being used today to reengineer, streamline, automate and track organizational processes involving humans and automated information systems [JAD+ 94, GHS95, Fis95, SKM+ 96, SGJ+ 96]. The success of WfMSs has been driven by the need for businesses to stay technologically ahead of the ever-increasing competition in typically global markets. WfMSs are very complex pieces of software. Supporting advanced capabilities such as security, reliability, high performance and transactional capabilities in heterogeneous and distributed environments in a manner that facilitates interoperability with other WfMS as well as other software systems and tools almost demands the use of an appropriate and widely-used infrastructure. In the METEOR2 project, two principal infrastructures - Web (World Wide Web) and CORBA (Common Object Request Broker Architecture) - are used to build WfMSs, WebWork and OrbWork, respectively. These infrastructures were carefully chosen for their functionality, availability, popularity and reasonable cost structures. Web technology is an appropriate choice for two distinct and important reasons. First, the ubiquitous nature of Web browsers makes them a natural user interface. Web browsers satisfy one of the primary concerns in application deployment - it allows users with any of the popular computing platforms to be able to participate in a work ow without any additional hardware. A multitude of users (many of whom are not computer sophisticated) are already familiar with these browsers' easy-to-use interface. They presently see the interface as a way to access all sorts of information and perform simple tasks such as lling out forms. The uniformity, wide availability and simplicity of the interface makes Web browsers an ideal user interface for work ow applications. Second, Web technology provides a solid communications infrastructure for building WfMSs. For WebWork, it is the only communications infrastructure, while for OrbWork it plays a supporting role to CORBA. Today, most organizations have Web servers or at least access to a Web server, making deployment of Web-based work ows relatively easy. For this reason, METEOR2 can support work ows in a Web-only (CORBA-free) mode. The WebWork implementation relies on both client-side (Web Browsers, Dynamic HTML, JavaScript and XML) and server-side (Web Servers, CGI, Java Servlets) Web technology. In summary, the fact that WebWork has been implemented as a functionally complete Work ow Management System exclusively using Web technology as its communication infrastructure provides several advantages: familiar user interfaces, widely available and easy to use infrastructure, and evolving technology for supporting security. In the rest of this paper, we discuss security features relevant to Web-based WfMSs. From 3

a user's point of view, there are three principal elements to security. First, a user wishing to participate in a work ow must be identi ed and authenticated before being allowed to participate. In addition, the activities of an authenticated user must be tracked/audited. Second, once in the system, all communication involving the user must be secure (i.e., encrypted). Finally, access to each object (task or data object) must be checked to make sure that such usage is authorized. The next section discusses common security services. This is followed by a detailed examination of security solutions and issues relevant to Web-based work ow. From this foundation, a security architecture is proposed for Web-based WfMSs in general and WebWork in particular.

2 Security Services The International Standards Organization (ISO) has speci ed ve common security services that network-based information systems should provide [Opp98]. Each is discussed in the subsections below.

2.1 Authentication Service In most domains, it is critically important to limit access to data and tasks to authorized individuals. Before any subject (user/client) begins participating in a work ow they must be identi ed (who are they) and authenticated (it is really them). It is critical to be absolutely sure who the user is. Security mechanisms for authentication include passwords, biometrics (e.g., ngerprint or retinal scan), and digital signatures.

2.2 Access Control Service Only authorized users should be allowed to execute given tasks or access given data objects. Access control must be eective in the sense that no unauthorized users should be granted access, while at the same time, no authorized user should be denied access. Security mechanisms for access control include Access Control Lists (ACLs), Role-Based Access Control (RBAC) and Multilevel Security (MLS). In certain application areas (e.g., healthcare), security should not get in the way in a critical situation. In case of an emergency, certain authenticated users may temporarily assume greater privileges or a higher role. This is referred to a Break-Glass Procedure. Such unusual events should be recorded and the work ow administrator should be immediately informed. In addition, maximal auditing/tracking should be done until this user logs o from the higher role.

2.3 Data Con dentiality Service For most network-based information systems, it is important that messages not be stolen or snooped. Messages are likely to contain con dential information (e.g., medical patient records). To eectively guarantee this, suciently strong encryption should be used, so that no one will be able 4

to decipher data owing over the net, except intended recipients. In practice, there is a trade-o between the risk of an encrypted message being cracked and the performance of the system. Ideally, a WfMS should provide options suitable for dierent applications areas.

2.4 Data Integrity Service Even if stolen messages are useless because they are encrypted, a malicious user may still cause problems. If s/he intercepts a message, modi es it and then sends it along, the message will no longer be valid. To ensure the message was not tampered with, a hash function may be applied to the message to form a digest. This digest is sent along with message (e.g., in a digital signature). Upon receipt of the message, the message is assumed to have been tampered with if the same hash function applied to the received message disagrees with the digest.

2.5 Non-Repudiation Service In a work ow setting, it is important to keep track of all accesses. If a user gains access illegally or a user makes a signi cant mistake, administrators must be able to quickly nd out what has been done and by whom. Through suciently eective and reliable authentication and tracking, it should be possible to undeniably establish the identity of the individual responsible for executing a given task. The system must keep track of who executed each task and when it was executed. In general, WfMSs provide auditing, tracking and monitoring capabilities for purposes of evaluating the eciency and eectiveness of elements within a work ow (e.g., automated tasks, work ow participants (end-users) as well as the overall work ow design itself). Of course, this information is also useful for security as well. If a security or privacy violation is suspected, utilities available to work ow administrators should facilitate such investigations.

3 Security Issues and Solutions Having discussed common security services relevant to all network-based information systems in general and work ow in particular, security solutions and issues will now be examined. The most relevant security mechanisms or solutions for Web-based work ow are Encryption, Digital Signatures, Role-Based Access Control and Multilevel Security. In this section, we will discuss how these established mechanisms [P 97, GS97, Oak98, Knu98] can be used in Web-based work ows, discussing alternatives as we go. These mechanisms will be combined and organized in a security architecture in section 4.

3.1 Encryption Encryption can be used to secure both messages and stored data. An encryption key(s) is used to mathematically transform the bits in a message in such a way that reversing the process (decryption) without knowing the appropriate key is very hard to impossible. Eectively, messages can not be 5

stolen. There are two basic approaches to encryption in use today: single key (symmetric key) and dual key (asymmetric keys) approaches. These approaches are discussed in the next subsections.

3.1.1 Symmetric Key Encryption Symmetric Key Encryption involves the use of a "secret key" to both encrypt and decrypt messages. Both parties (sender and receiver) must agree to use the same secret key. Typically, this would be done by handshake procedure in which the secret key is sent over the network using public key encryption.

3.1.2 Public Key Encryption Public Key Encryption involves the use of a "public/private key pair". The public key is typically used to encrypt messages, while the private key is typically used to decrypt messages. A signi cant advantage of this approach is that private keys never need to be sent out over a network. Consequently, only the entity with the private key will be able to decrypt messages (i.e., messages will only be meaningful to their designated recipient). Public key encryption is also harder to crack than symmetric key encryption. Unfortunately, it is also more computationally expensive. Public key encryption systems with suciently large keys are uncrackable assuming the key generation algorithm is suciently random and unpredictable. For example, one should not use a well-known random number generator working o an obvious seed like 1. To increase the unpredictability of this process, one can generate key pairs using the user's name, ssn, and a random number generator seeded with the time of day. The Pretty Good Privacy (PGP) package [GS97] also uses several random keystrokes to increase unpredictability.

3.1.3 Secure Socket Layer (SSL) The most prevalent standard in use today for encrypting messages on the Web is the Secure Socket Layer, version 3 [FKK96, GS97]. For encrypting messages, it uses symmetric key algorithms for eciency reasons. The Web browser and server must agrees on an algorithm and on a set of secret keys. This is done using a handshake protocol in which secret messages are sent between the browser and server using public key encryption. Since the secret messages are used to generate secret keys, they must not be stolen. In addition to encryption, SSL also provides data integrity (detection of message tampering) as well as authentication services (see the Appendix for details).

3.2 Digital Signatures To assure the identity of the sender, a digital signature can be added to the message. Since message signing requires the sender's private key, the message could have only been sent by the designated sender. Eectively, forgery of messages is prevented. Since the digital signature is signed with the sender's private key, the recipient can verify the digital signature with the sender's public key and know that it could have only been signed by the designated sender. Furthermore, by including a 6

digest formed by applying a hash function to the message, it can be detected whether the message has been tampered with. Details on how digital signatures [NIS94] work may be found in the Appendix.

3.3 Role-Based Access Control Role-Based Access Control [BCF+ 97] is used to determine what role(s) a subject (user/client) may perform. The role then determines what tasks a user may execute. Having established the identity of the user, we need to ensure that the user can only perform the roles he is entitled to. A work ow designer de nes the roles for a particular work ow application using the graphical METEOR Designer. S/he then assigns one or more roles to each task in the work ow. A work ow administrator assigns users to speci c roles using simple forms provided by the work ow repository, allowing convenient granting or revoking of roles. At design time, tasks are assigned roles (e.g., AdmitClerk, TriageNurse). This approach is convenient in two distinct ways: (a) All users are not known at design time so it is infeasible to authorize users at this time. (b) A role groups together a collection of privileges (e.g., which tasks can be executed) so rather than assigning each user a long tedious list of privileges, e.g., an Access Control List (ACL), they are simply assigned one or more roles. Roles are de ned from a functional point of view (i.e., what needs to be performed by groups of users). Since roles (e.g., Doctor, Nurse) are related to organizational structures, management and administration of privileges is simpli ed. In addition, it is easier to adjust the privileges associated with a role, than it is to adjust the privileges of all aected users. Therefore, RBAC provides an excellent foundation for security and for many organizations will suce.

3.3.1 Role Hierarchies To make role de nition and assignment even more convenient, roles may organized hierarchically with one role (e.g., Doctor) subsuming the privileges of another (e.g., Nurse). In addition, role hierarchies also enhance the logical structuring of roles (e.g., a hospital wishes to ensure that doctors can do all the things that nurses can do). In general, role hierarchies can be designed to re ect the responsibilities, authorities and competencies of groups within an organization.

3.3.2 Roles and Rules The simple approach that we are proposing (i.e, focusing on subjects and verbs), could have limitations as illustrated by the following example. Suppose there is a task to GetPatientRecords which can be executed by ordinary doctors (Doctor role) or doctors that are heads of departments (LeadDoctor role). A hospital may have a policy that Doctors can browse records of patients they have treated, but LeadDoctors can browse all patient records. This policy can formalized as a rule. Using our approach to applying RBAC to work ow, the rule can be enforced in one of two ways. 7



Make the task, role aware. Then when querying the database, restrictions would be applied depending on the role executing the task. This approach could also allow branching (control

ow) to be role dependent.



Keep tasks, role unaware, but make two versions of the GetPatientRecords tasks, one for Doctors and another for LeadDoctors.

The rst approach allows greater exibility, while the latter maintains the logical separation of functionality from access rights/privileges. Since the latter has the advantage of allowing roles to be changed without aecting work ow dynamics and makes roles less dependent on a speci c work ow, we are taking this approach.

3.3.3 Role Ontologies Rather than de ning a set of roles for every new work ow designed, or having a set of roles that apply to all designed work ows, it is desirable to take the middle ground. A group of roles is collected into an ontology. This ontology may then be associated with one or more work ows. Support for mappings between role ontologies could also be supported for the purpose of integrating work ows using dierent role ontologies. Mappings may also be used to map a work ow ontology to a local ontology used by a subsystem (e.g., roles de ned for a local Oracle database).

3.3.4 Controlling Access to Data Objects Besides information stored by a WfMS, work ow applications themselves may access sensitive information stored in les and databases. Systems should ensure that sensitive information is not accidentally made available. The following security measures can be applied to help assure this. Securing Access in Subsystems. Care should be taken by application developers, task implementors, system administrators and database administrators to secure data in these component systems (e.g., Database Systems typically now provide role-based security). Security in work ows can be simpli ed if responsibilities can be divided between the work ow administrator and application task implementors. The work ow administrator authorizes execution of a task with checking being performed by its task manager, while access to data objects is the concern of the task implementor. For example, authorization to access database objects from a task is handled by the task implementor in conjunction with the database administrator. In particular, to access an Oracle database, a username and password must be passed as parameters to the connect function. These strings could be hardcoded in the task implementation. If they are hardcoded, source code should not be made available. Also, in order to make it more dicult for hackers to steal database passwords, executable les should not readable. An alternative to hardcoding passwords in tasks is discussed below. Linking Roles to Data Objects. When a task is designed, its data access patterns should be considered before a role(s) is assigned. There are two important issues to addressed here. They 8

suggest solutions of either adding capability lists to roles or assigning roles to data objects. A disadvantage of capability lists is they tend to make roles too work ow speci c and complex to specify. 



Accessible Objects. What data objects or subsystems is a role permitted to access? This

would suggest that a role be assigned a capability list. For example, to access a certain Oracle database, the required username and password would be stored in the capability list. Furthermore, capabilities can be analyzed to make sure that roles assigned to tasks can really achieve their mission.

Object Propogation. If Task Ti with role Rx sends data to Task Tj with role Ry , is Tj

allowed to see this data? If data objects as well as tasks have roleLists, then these roleLists may be compared to answer such questions. For example, suppose Ti sends data object Oa to Tj . Tj will be permitted to access Oa, if the transitive closure of Tj .roleList intersects Oa.roleList. In general, a feasibility analysis may be performed at design time to make sure that Tj is permitted to see any data sent to it by Ti .

3.4 Multilevel Security In domains (e.g., military) requiring higher security, RBAC can be augmented with Multilevel Security (MLS). 1 Multilevel security ensures that information does not ow downhill (from high clearance to low clearance personnel). Access to data objects is controlled based on security domains/levels (e.g., Unclassi ed, Secret or Top Secret). Data may be in the form of work ow data objects, les, databases, etc. Within a security domain RBAC may be used to control access. MLS kicks in when data crosses security domains.  

Upgrading Data. When a task accesses data from a lower security level or domain, the

process must be carefully tracked and recorded.

Downgrading Data. When a task accesses data from a higher security level or domain,

the the data must be carefully analyzed and ltered to make sure no unintended secrets are divulged. Such lters are typically custom coded.

If the WfMS and all application tasks are awlessly coded and executables are fully secure, the system can ensure that no un ltered data ows downhill (e.g., no unintended secrets get out). A safer, although more costly, approach is discussed below.

3.4.1 MLS via Partitioned Networks For maximum security, an organization may partition a work ow into multiple security domains [FK97]. Tight control of communication must be maintained when crossing security domains. Multilevel security (or Mandatory Access Control (MAC)) is the security standard for military domains. However, it may not be desirable, if not really needed, in other domains, because of its extra cost and complexity. 1

9

Ordinary network transports (e.g., TCP/IP) are used only within domains. Upgraded data is "pumped" up to a higher security domain using a highly secure channel in which bits are only propagated in one direction. Downgraded data results only from a careful " ltering" process. Because lters are custom coded and pose a potential source of leaks, this type of communication is kept to a minimum. From the point of view of Web-based work ow, a partition may be viewed as an extreme form of a rewall. When communicating with a Web server in another security domain, a special proxy server could intercept the HTTP request message. This proxy would check the message and forward it over a highly secure channel ("pumped up" or " ltered down") to a dual proxy in the other security domain. This dual proxy would then reform the HTTP request message and sends it to the logically intended Web server.

4 A Security Architecture for Web-Based WfMSs In this section, we discuss how the above security mechanisms and solutions can be eectively combined and organized into an architecture for security in Web-Based WfMSs. In particular, the architecture requires message encryption, digital signatures and Role-Based Access Control (RBAC). Optionally, Multilevel Security (MLS) may be added. Implementation of this architecture is proceeding using WebWork. Because of the use of RBAC, users (work ow participants) must log in and select an appropriate role. A Login Agent will consult a Security Agent to assist the user in selecting a role (and will make sure s/he is so authorized). After this, the user may execute tasks assuming the role permits it. Task managers must examine the user's digital signature and/or role information to decide whether to permit the task to execute. This may require a consultation with the Security Agent. To prevent messages from being stolen, communication is encrypted. The way in which these elements interact is shown in gure 1 and discussed further in the subsections below.

4.1 Security Agent In this subsection, we discuss the security agent and the security database. An Entity-Relationship (ER) model is developed for the security database supporting RBAC, optionally augmented with multilevel security. Both the Login Agent and Task Managers will consult the Security Agent in order to make security decisions. No other access to the security database is permitted. For performance reasons, multiple security agents may be utilized and agents may cache some security information. The security database needs to keep track of several types of entities which are richly connected in relationships. The entities are de ned below and their attributes and relationships are shown in gure 2.

Entities:

User

= set of authorized workflow users/participants

10

username workflow digital signature

User name-value pairs digital signature

roles

Login Agent

Task Manager

roles username workflow digital signature

digital signature

Task

Security Agent Application DB

Security DB

Figure 1: Security Architecture WorkFlow

= set of workflow applications (workflow type)

Role

= set of roles played by users

RoleOntology

= set of role ontologies (vocabulary of roles)

Task

= set of design-level tasks

DataObject

= set of data objects

SecDomain

= set of security domains/levels

The fundamental question to answer with the security database is the following: May user u logged in under role r execute task t which accesses the set of data objects o? The login will ensure that user u has been authenticated and has been assigned role r. t's task manager will ensure that role r is authorized to execute task t. Access to the set of data objects o will be granted either based on the credentials of task t and/or role r. RBAC will be adequate in many cases, (e.g., in commercial and civilian domains) assuming roles are well assigned by the work ow designer. However, in environments where high security is 11

ontoName

wfName m

WorkFlow

1

RoleOntology

uses

m 1 follows

m maps

1

1

m

DataObject

has m

m

collects

m

m

accesses

grants

m

Task

m

subsumes

m

m

m

m

Role

authorizes m

m

taskName m

roleName

excludes

m plays

operates-in 1

m

User

SecDomain

secLevel

userName

SSN

pubKey

Figure 2: ER Model of Security Database important, the additional work of creating security domains should be done. Another responsibility of the security agent is key management. Without appropriate key management to generate, disseminate and destroy keys, security will become either unwieldy or ineective. Each organization (or part of an organization) participating in work ows will need to disseminate keys, so ideally should also generate and destroy keys. The work ow administrator may use a utility provided by the security agent to produce unique keys for users. Smaller or technologically challenged organizations may wish to get their keys from recognized Certi cate Authorities (e.g., VeriSign) or from a trusted aliated organization. Tools such as the Netscape Certi cate Server allow organizations to conveniently generate keys.

12

4.2 Login Agent To participate in a work ow, a user carries out the following procedure. From a Web browser, the user enters the URL for the Login Agent. It is important that the Login Agent be authenticated by providing its own digital signature. Currently, the Login Agent, implemented as a Java applet, displays six buttons: Login, Select Work ow, Select Role, Perform Role, Logout and Help. 

 

Login. Reliable authentication of the user is absolutely necessary to have a secure system.

Unique identi cation in WebWork is based on the use of public/private keys. The login procedure grants the user access to his/her private key. If anyone else gets this key, the system will be insecure. To minimize this risk both physical and logical barriers should be set up to make stealing the private key dicult. Physical barriers include putting the private key on removable media (e.g., a oppy disk, CD or smart card). The user may then take the private key with them or lock it in secure place. Since these may be stolen, it may also be important to have logical barriers (e.g., combinations of passwords, identifying information (name, ssn, birth date), ngerprints, and/or retinal scans). Once user X is logged in, s/he will digitally sign messages using his/her private key. X 's public key will be available (or sent) to all recipients. Recipients will verify messages using X 's public key. This guarantees that the message came from X . Notice that this approach under no circumstances, requires a private key or login information like a password to be sent over the net.

Select Work ow. The user enters or selects the work ow s/he wishes to participate in. To

change work ows, the user simply clicks the Select Work ow button again.

Select Role. By consulting the Security Agent, the Login Agent will display a list of roles

the user is authorized to perform. The list is ordered by the frequency of prior selections (adapts to user preferences). To change roles, the user simply clicks the Select Role button again.



Perform Role. Once a user has selected a role, s/he may click on the perform role button.



Logout. Upon logout the memory image of the applet is cleared before exiting. The applet



This will display the list of user tasks this role is authorized to perform in the given work ow. When invoking a task manager, a digital signature identifying the user is sent along with all messages. This allows the task manager to uniquely identify the sender and make sure s/he is authorized to execute the task. Notice that once a user is logged in, they need not go through a full authentication process for each task that they execute. The use of digital signatures based on the user's private key makes repetitive authentication processes unnecessary. itself does not store anything persistently in les, databases, etc., except auditing information.

Help. The help button is simply a link to the WebWork hypertext documentation. 13

4.3 Secure Communication Most Web-based work ows will require all communication over networks to be secure (the most common exception is likely to be within intranets). Fortunately, this capability is available with current Web technology (servers and browsers). Vendors now support Secure Socket Layer (SSL), version 3. Use of SSL will assure that stolen messages will be useless to their recipients, since only the intended recipients will have the keys necessary to decrypt the messages. Figure 3 illustrates the use of SSL in WebWork. Typical task manager to task manager communication follows the route shown in gure 3. Networked/Encrypted Local/Unencrypted Web Browser

Dynamic HTML

HTTP

Request

XML

Web

Web

Server

Server

Dynamic XML HTML

Name-Value Pairs

CGI

Java

CGI

Java

Program

Servlet

Program

Servlet

Figure 3: Secure Communication using SSL In domains in which symmetric key encryption will not suce, public key encryption may be used as an alternative. For public key encryption, to send a message to a speci c recipient, simply encrypt the message with his/her public key. The message can only be decrypted with the private key which no one else has. We are exploring both approaches. Also in WebWork, automated tasks bypass browsers, so their task managers would need to encrypt messages they send directly to Web servers. One alternative to SSL is to perform encryption and decryption entirely by task managers (the sender encrypting and receiver decrypting). Any sensitive information stored by a WfMS must only be available to authorized individuals. It 14

is common for Web-based WfMSs to store data transmissions between task managers in worklists or logs. This data is often stored in les in some directory accessible to the Web server. At a minimum, these les should not globally readable. Typically, however, they will need to be encrypted.

4.4 Task Manager Responsibilities Before giving an incoming message to a task manager, the Web server will decrypt the message. Only the intended Web server will be able to accomplish this. Messages being sent to task managers consist of the task's attributes and control information both encoded as name-value pairs. Workflow_ID=&Flow_Name=&Task_Name=&...

For security, the following control information is added. Public_Key=&Digital_Signature=

In addition, one of the following is also included. Role_Name=

or

Role_Key=&Role_Signature=

The user's digital signature identi es the user, while the role's digital signature identi es the role. Using Java, digital signatures are easy to build. For example, a user's digital signature contains the user's name which is encrypted using the user's private key. Signature mySig = Signature.getInstance ("SHA/DSA"); mySig.initSign (privateKey); mySig.update ("Mei Fan"); byte [] byteSig = mySig.sign ();

Upon receiving a message, the task manager must make sure that message was not forged or tampered with. This is accomplished using the digital signature in the message. The task manager must now check to see if the user is authorized to execute this particular task. 

Identify the User. To authorize the user, the task manager must have a reliable way of identifying the user. Fortunately, the user is uniquely identi ed within the security database by his/her public key.



Role to Task Mapping. The task manager must check the role name (e.g., Nurse) to establish that this task may be executed by users permitted to perform that role. 15



User to Role Mapping. Next, the task manager must make sure that the user is indeed permitted to perform the indicated role. (a) If a digital signature for the role is included in the message, authorization is granted since the user has access to role's private key. (b) Alternatively, if only a role name is included in the message, the task manager must check the Security Agent to see if the role name is matched to the user's public key. For performance reasons, a task manager may maintain a cache of active validated users (their public keys) for each role. If the user is not found in this list, the Security Agent is consulted. Pseudocode for this user validation procedure is shown below.



Non-Repudiation. One may wonder at this point why authorization is not based on keys for roles. The reason is that we must guarantee non-repudiation. We must know which nurse administered the medications, not just that a nurse administered them.

bool validUser (String roleName, Key publicKey) { for (r in roleList) {

// role list for task manager

if (r.name == roleName) { for (k in r.keyList) {

// public keys approved for role

if (k == publicKey) { return true; }; // if }; // for if (inSecurityDB (roleName, publicKey)) { r.addKey (publicKey); return true; } else { return false; }; // if }; // if }; // for return false; }; // validUser

This approach assumes that CGI scripts/Java Servlets are run on the same host as the Web server. If a Web server executes CGI scripts/Java Servlets on remote hosts, then either this capability should be disabled or extra security measures should be used.

16

5 Conclusions For work ow to be useful in domains in which high security is essential (e.g., healthcare, electronic commerce and military applications), Web-based WfMSs must combine established approaches to security in ways that achieve the desired level of security while maximizing usability and minimizing cost. This paper discusses how encryption and digital signatures can provide the foundation for Webbased work ows which span multiple organizations. They provide Data-Con dentiality (maintain privacy), Authentication (reliably establish identity) Data-Integrity (detect tampering), and NonRepudiation (undeniably establish/record identity) services. The paper further considers combinations of Role-Based Access Control (RBAC) with Multilevel Security (MLS) for Access Control service. A security architecture was proposed that includes these four solutions (encryption, digital signatures, RBAC and MLS). Furthermore, standards are utilized when appropriate (e.g., SSL and DSS). (1) SSL is used for message privacy and authentication of Web browsers and servers. (2) DSS is used for creating METEOR Digital Signatures to authenticate work ow users/participants and optionally to authenticate roles. Checking data integrity using the digest included in METEOR Digital Signatures has an advantage over using SSL to do the checking. SSL will only detect tampering between the browser and server, while METEOR Digital Signatures will check from task manager to task manager. Authenticated users are authorized to perform tasks using RBAC. MLS is added in a compatible way for high-security work ows. Although no fundamentally new security measure is proposed in this paper, selection, tailoring and organizing existing security measures into an architecture suitable for Web-based work ows spanning multiple organizations is an enormously complex problem. We believe that the proposed architecture simpli es this problem.

Acknowledgements

This research was partially supported by grants from the National Institute of Standards and Technology (NIST) (under the HIIT ATP contract, number 70NANB5H1011), and the Naval Research Laboratory (NRL) (US Department of Navy, number N00173-98-2-L005). Additional partial support and donations have been provided by Visigenic, Informix, Iona, Hewlett-Packard Labs, and Boeing.

References [BCF+97] J. Barkley, A. Cincotta, D. Ferraiolo, S. Gavrilla, , and D.R. Kuhn. Role Based Access Control for the World Wide Web. Technical report, NIST, 1997. URL: http://hissa.ncsl.nist.gov/rbac. 17

[Fis95]

L. Fischer. The Work ow Paradigm - The Impact of Information Technology on Business Process Reengineering. Future Strategies, Inc., Alameda, CA, 2nd. edition, 1995.

[FK97]

J.N. Froscher and M.H. Kang. MLS Work ow on a MLS Distributed Architecture. Technical report, Naval Research Laboratory, 1997. URL: http://www.hokie.bs1.prc.com/ia/archnrl.htm.

[FKK96] A.O. Freier, P. Karlton, and P.C. Kocher. SSL 3.0 Speci cation. Technical report, Netscape Communications Corporation, November 1996. URL: http://home.netscape.com/eng/ssl3/index.html. [GHS95] D. Georgakopoulos, M. Hornick, and A. Sheth. An Overview of Work ow Management: From Process Modeling to Work ow Automation Infrastructure. Distributed and Parallel Databases, 3(2):119{154, April 1995. [GS97]

S. Gar nkel and G. Spaord. Web Security & Commerce. O'Reilly & Associates, Cambridge, MA, 1997.

[Hol94]

D. Hollingsworth. The Work ow Reference Model. Technical Report TC00-1003, Issue 1.1, The Work ow Management Coalition, Brussels, Belgium, November 1994.

[JAD+94] S. Joosten, G. Aussems, M. Duitshof, R. Humeijer, and E. Mulder. WA-12: An Empirical Study about the Practice of Work ow Management. University of Twente, Enschede, The Netherlands, July 1994. Research Monograph. [Knu98]

J. Knudsen. Java Cryptography. O'Reilly & Associates, Cambridge, MA, 1998.

[MPS+97] J.A. Miller, D. Palaniswami, A.P. Sheth, K.J. Kochut, and H. Singh. WebWork: METEOR2's Web-Based Work ow Management System. Journal of Intelligent Information Systems, Special Issue on Work ow, 10:185{215, 1997. [NIS94]

NIST. Digital Signature Standard. Technical report, NIST, May 1994. URL: http://www.itl.nist.gov/div897/pubs/ p186.htm.

[Oak98]

S. Oaks. Java Security. O'Reilly & Associates, Cambridge, MA, 1998.

[Opp98] Rolf Oppliger. Internet & Intranet Security. Artech House, 1998. [P 97]

C.P. P eeger. Security in Computing, Second Edition. Prentice Hall, Upper Saddle River, NJ, 1997.

18

[SGJ+96] A. Sheth, D. Georgakopoulos, S. Joosten, M. Rusinkiewicz, W. Scacchi, J. Wileden, and A. Wolf. Report from the NSF Workshop on Work ow and Process Automation in Information Systems. Technical report, University of Georgia, UGA-CS-TR-96-003, July 1996. URL: http:// LSDIS.cs.uga.edu/activities/NSFwork ow. [She96]

A. Sheth. Proc. of the NSF workshop on work ow and process automation in information systems. University of Georgia, May 1996. URL: http://LSDIS.cs.uga.edu/activities/NSF-work ow.

[SKM+96] A. Sheth, K. J. Kochut, J. Miller, D. Worah, S. Das, C. Lin, D. Palaniswami, J. Lynch, and I. Shevchenko. Supporting State-Wide Immunization Tracking using Multi-Paradigm Work ow Technology. In Proc. of the 22nd. Intnl. Conference on Very Large Data Bases, Bombay, India, September 1996.

Appendices: Relevant Security Standards Appendix A: DSS The Digital Signature Standard (DSS) proposed by the NIST refers to an optimized modi cation of the ELGamal crypto-system. It speci es a Digital Signature Algorithm (DSA) to generate a digital signature and verify it. The algorithm makes use of following parameters: 

DSA parameters: p, q are prime numbers, and g is an integer



Sender's private key: x is a random integer



Sender's public key y = gxmod p

We must make sure that the received message is the same as the one that was sent (i.e, maintain data integrity). If a message has been tampered with or changed in transient, the recipient must be informed. To detect tampering with messages, a digest is formed by applying a hash function (SHA1) to the original message. Then the sender uses his private key x to generate his digital signature by computing the following values:

r = (gk mod p)mod q s = (k?1(SHA(M ) + xr))mod q Both r and s are large integers (160 bits) and together form the digital signature (note, k is a random integer). To digitally sign a message M , prepend it with the digital signature as shown in gure 4. For convenience the sender's public key may also be prepended. 19

public key 128 bytes

digital signature 50 bytes

y

r

original message >=6 bytes

s

M

send complete message to recipient

y’

r’

s’

M’

Figure 4: Using Digital Signatures

The recipient uses the same hash function on the digitally signed message. Then s/he veri es the digital signature by using the sender's public key. If the signature is veri ed, the recipient is sure that the received message was sent by the identi ed person or entity and the message was not tampered with; otherwise, the message should be considered invalid.

Appendix B: SSL, Version 3 The Secure Socket Layer, version 3 is supported by most Web browser and server vendors and it provides three important security services. 

Authentication is provided using public-key certi cate exchange and digital signature.



Data Integrity is provided using Message Authentication Code (MAC). The MAC is analogous to a digest augmented with a secret key.



Data Con dentiality is provided using a symmetric encryption algorithm negotiated during SSL handshake.

The SSL handshake protocol consists two parts, server authentication and client authentication. The second part is optional, but for Web-based work ow may be desirable. When setting up a Web server, the Webmaster creates or obtains a public/private key pair (s). Key pairs may be certi ed by a Certi cate Authority (CA). The CA will assure the integrity of public keys across organizations. In a similar way a Web browser may be certi ed. 20

When a browser connects to a Web server, it sends the server a list of cryptographic algorithms it can support. The server chooses one of them and also sends its certi cate (including the server's public key) to the browser. The server's public key will be used to encrypt a secret message being sent to the Web server. This guarantees that only the intended Web server will be able to decipher this message using his private key. The secret message known only to themselves is used to generate session keys for encryption and MAC computations. Similarly, a client can authenticate itself to the server by sending its certi cate containing its digital signature. The server can verify the digital signature by using client's public key. After the handshake nishes, communication between browser and server is encrypted (in both directions) using the selected algorithms with the generated secret key for the session. In addition, data integrity is checked every time using the MAC.

21