Access Control Mechanisms for Inter-organizational Workflow

Transcription

1 Access Contol Mechanisms fo Inte-oganizational Wokflo Myong H. Kang, Joon S. Pak and Judith N. Fosche Naval Reseach Laboatoy Infomation Technology Division 4555 Ovelook Ave. Washington, DC {mkang, jpak, ABSTRACT As moe businesses engage in globalization, inte-oganizational collaboative computing gos in impotance. Since e cannot epect homogeneous computing envionments in paticipating oganizations, heteogeneity and Intenet-based technology ae pevalent in inte-oganizational collaboative computing envionments. One technology that povides solutions fo data shaing and ok coodination at the global level is inteoganizational okflo. In this pape, e investigate the access contol equiements fo inte-oganizational okflo. We then pesent access contol solutions fo inte-oganizational okflo based on ou implementation. Many of the equiements and solutions in this pape addess the scalability of eisting secuity solutions, the sepaation of inte-oganizational okflo secuity fom concete oganization level secuity enfocement, and the enfocement of fine-gained access contol fo inte-oganizational okflo. the entepise needs Fleible IT esouces and infastuctue that allo apid configuation, Secue distibuted applications that can be easily constucted acoss entepise boundaies, and Entepise-level anomaly detection and ecovey. One technology that ties to povide solutions to the above poblems is inte-oganizational okflo. A okflo is a distibuted application that inteacts ith uses and othe applications to achieve common goals. Even though the above thee equiements ae equally impotant, e focus on the second item, especially access contol issues. In this pape, e use entepise application and inte-oganizational okflo intechangeably because an inte-oganizational okflo is an instance of entepise applications. Figue 1 shos to inteoganizational okflos. Keyods Access contol, Secuity, Oganizational secuity, Entepise, Wokflo Oganization1 Oganization2 1. INTRODUCTION The Intenet and business globalization have eplaced the sepaation that as typical of the taditional business paadigm. Unconventional coalitions among businesses and nations ae fomed to advance common goals. These coalitions then quickly dissolve as individual objectives change. Theats no lie in these essential connections among paticipating entepises, hich also enable pofitable coopeation. To facilitate these alliances, businesses and the militay ely on distibuted infomation technology (IT) fo most opeations. A secue computing infastuctue (e.g., secue netok, fieall) is needed to suppot thei missions. In addition to a secue computing infastuctue, Oganization3 : host : oganization bounday : inte-oganizational okflo Figue 1. To inte-oganizational okflos In figue 1, one okflo spans to (physical) oganizations hile the othe okflo spans thee (physical) oganizations. We can vie an inte-oganizational okflo as a vitual entepise that suppots a specific mission. Once a okflo is designed, each task [3, Appendi] should be assigned to a specific oganization and host (compute). In this eample, e assume that hosts ae connected via some netoking mechanisms (e.g., Intenet). Also note that multiple okflo tasks may be assigned to the same host. In this pape, e study the access contol equiements fo inteoganizational okflos. We then pesent access contol solutions fo inte-oganizational okflo based on ou 1

2 implementation. The est of the pape is oganized as follos. We biefly descibe a pototype inte-oganizational okflo management system (WFMS), SALSA, in section 2. Section 3 pesents access contol equiements fo inte-oganizational okflos. We evie elated access contol eseach in section 4. In section 5, e pesent access contol mechanisms that have been implemented in SALSA. Section 6 summaizes this pape. 2. AN INTER-ORGANIZATIONAL WORKFLOW MANAGEMENT SYSTEM An entepise application that suppots global, vitual entepises may span multiple oganizations and legal boundaies. Conventional WFMS cannot suppot such entepise applications due to its mostly centalized achitectue and functions. In most cases, the autonomy of uses and oganizations ae geatly esticted due to centalized achitectual and design consideations. Theefoe, e need ne inte-oganizational WFMSs. A WFMS, typically, consists of to pats; design-time and untime tools. We constucted an inte-oganizational WFMS, called SALSA [4], by implementing ne design-time tools and etending an eisting distibuted CORBA-compliant okflo untime engine, ObWok[6] fom Univesity of Geogia. Thee is no centalized okflo engine in Obok. Instead each task contains a potion of the okflo specification that petains to that task s inteaction ith othe tasks in the okflo. Data esouces that the task uses ae also knon as ok-items. Ou etension is based on one impotant equiement of inteoganizational okflos: the autonomy of paticipating oganizations should be honoed not only duing the design phase but also duing the untime (eecution) phase. In othe ods, diffeent okflo designes may ok on diffeent potions of an inte-oganizational okflo duing the design phase. Also, multiple okflo untime engines, hich ae managed by diffeent oganizations, may have to ok togethe to accomplish a mission. To suppot such autonomy among paticipating oganizations, e etended ObWok ith coopeative pocesses [3] that allo multiple independent autonomous okflos to coopeate based on the contact among them. To make the contact among paticipating oganizations igoous, e intoduce a okflo domain in ou design tool. A okflo domain is a geneic concept that can be used to epesent each oganization o even secuity domain [3]. A okflo in a okflo domain coesponds to an independent okflo duing untime. In othe ods, hen an inte-oganizational okflo is designed, it is a single okflo acoss multiple oganizations. Hoeve, this single inte-oganizational okflo design is split into multiple autonomous okflos, and they ae deployed to paticipating oganizations fo eecution. The numbe of independent okflos that ill be poduced is the same as the numbe of paticipating oganizations o okflo domains [3]. In this ay, e addess the autonomy of oganizations and thei concen fo mutual potection. In othe ods, each oganization maintains and eecutes its potion of okflo, and any data to and fom othe oganizations fo eceiving and sending should be echanged accoding to the oganization s secuity policies [3]. Any communication among okflo domains should follo the contact govening coopeation among independent okflos o oganizations. The contact may specify hat kinds of equests o data can be passed fom one entity to anothe, hen a esponse is epected. Since seveal potions of okflo design may be assembled to accomplish an entepise level mission, it is impotant to validate that the oveall design is consistent and sound. We povide tanslatos fo conveting an inteoganizational okflo design into inputs to an eisting Peti-net based analysis tool Woflan [11], and a model checking tool Spin [2], so that the consistency of the inte-oganizational okflo design can be validated. The oveall stuctue of SALSA is as follos: SALSA Design Tool XML Compile Runtime Specification & Code Figue 2. Intenal stuctue of SALSA Runtime Engine The SALSA design tool allos application designes to specify mission/application logic, and the contact govening inteactions among paticipating oganizations. In othe ods, the designe can specify the follos: okflo domains that may epesent oganizations task specifications (e.g., inputs, outputs, invocation method fo the undelying component) in each okflo domain, and contol logic and data flo among tasks. The SALSA design tool also allos application designes to hide compleity by poviding a ay to goup elated tasks into a moe abstact highe-level task (i.e., the level of abstaction) [3, see Appendi]. The SALSA design tool saves the design specification in XML. When the okflo design is completed, the compile eads the XML epesentation of the design, and geneates Woflan o Spin inputs fo design analysis and validation. Finally it geneates untime specification and code. Cuently, e ae using modified vesion of ObWok as ou untime engine. ObWok does not have a cental schedule; athe the schedule is distibuted ith each task containing the code petaining to it. Each schedule only knos its pedecessos and successos. Each ObWok schedule eads a task specification that as geneated by the compile and eecutes its ole in the oveall mission. Biefly, ObWok consists of the folloing CORBA seves: task seves, oklist seve, data seves, and a monito seve. Each task seve, hich is a pocess fom the opeating systems point of vie, may contain moe than one task [Appendi], hee each is a sepaate thead in a task seve. The oklist seve maintains the lists of pending ok fo human tasks. Data seves act as a epositoy fo data that is needed by tasks. A monito seve maintains the histoy of eecution and anses queies fom othe seves and monito clients. Since they ae CORBA seves, they communicate ith each othe though CORBA s IIOP. The task seve and oklist seve ae not only CORBA seves, but also HTTP seves. When a human opeato has to inteact ith oklist seve (e.g., human task), he can do so though the 2

3 HTTP potocol. Also hen a human okflo manage needs to intevene fo some easons, he can do so though the HTTP potocol. Figue 3 shos a simplified vie of ObWok. Human Opeato Woklist Seves Data Seves W D Tasks Human Manage Task Seves M Monito Seves : CORBA s IIOP : HTTP Figue 3. A simplified vie of ObWok 3. ACCESS CONTROL REQUIREMENTS FOR INTER-ORGANIZATIONAL WORKFLOW Thee ae many secuity equiements fo inte-oganizational okflos such as establishing secue communication among seves, and poviding diffeent vies of the okflo based on uses needs-to-kno and thei affiliated oganization. Hoeve, in this pape, e focus on access contol equiements fo inteoganizational okflos Sepaation of Application-level (Wokflo) Secuity Infastuctue fom Oganization-level Secuity Infastuctue Because thee ae seveal oganizations that suppot an inteoganizational okflo, the paticipants may change duing the life cycle of an inte-oganizational okflo. Fo eample, a ne oganization may eplace an old oganization o thee may be a mege o sepaation among oganizations. Since each oganization may suppot seveal inte-oganizational okflos, it is not ealistic fo each oganization to estuctue its secuity infastuctue fo inte-oganizational okflos. Theefoe, inteoganizational okflos need to be insulated fom oganization level changes so that okflos can continuously opeate ithout changing okflo specifications including secuity specifications Fine-gained and Contet-based Access Contol Taditionally, an access contol decision is made based on subjects and objects. The subjects may be uses o pocesses acting on behalf of uses. The objects ae data o esouces in the system; fo eample, objects may be files in the file system. Conventionally, a pocess, hich may be an application eecuting on behalf of a use, is the finest gained subject fo hich an access contol decision can be made by the opeating system. Inte-oganizational okflos tend to be lage scale and consist of many okflo tasks [Appendi], hich can be theads ithin a pocess. Hence, conventional access contol may be too coase fo okflos, in geneal. What e need is a fine-gained access contol that is based on a use s oking contet. Wokflo tasks povide uses oking contet. Even the same use may have diffeent data access needs and equiements based on the tasks the use is oking on Suppoting Dynamic Constaints Dynamic constaints ae equied in many inte-oganizational okflos. Dynamic constaints may be based on the uses of a specific task. Fo eample, if a use pefoms a task,, then that peson may not be alloed to pefom anothe task, (i.e., sepaation of duty [8]) in the same okflo instance. If thee is one centalized WFMS, then it is not too difficult to enfoce such constaints. Hoeve, inte-oganizational okflo may consist of seveal autonomous okflos that ok togethe to achieve an entepise-level mission. Theefoe, inte-oganizational okflos need some fameok fo shaing elevant eecution histoy among paticipating okflos. The above access contol equiements ae not only equiements fo inte-oganizational okflos but also those of entepise applications that have to be eecuted acoss multiple oganizations. In the folloing, e pesent access contol elated eseach. 4. RELATED RESERCH Taditionally, an access contol decision is made based on subjects and objects (see figue 4). The subjects may be uses o pocesses acting on behalf of uses. Conventionally, a pocess is vieed as a subject; hoeve, fo okflos, a pocess may include seveal okflo tasks, hich can act on behalf of diffeent uses. The objects ae data o esouces in the system. Fo eample, objects may be files in the file system. Pemission is a set of authoized inteactions that a subject can have ith one o moe objects in the system. Pemission may have a vaiety of intepetations in vaious access contol models. The basic idea is to contol ho can access hich esouces. Pocesses on behalf of uses Uses Subjects Access Contol Decision Pemissions Access contol module Resouces files Figue 4. A taditional access contol model Data Objects Objects 4.1. Role-based Access Contol (RBAC) Role-based access contol (RBAC, [7]) has apidly emeged in the 1990s as a technology fo managing and enfocing secuity in lage-scale systems. The basic notion of RBAC is that pemissions 3

4 ae associated ith oles, and uses ae assigned to appopiate oles. RBAC ensues that only authoized uses ae given access to cetain data o esouces. This simplifies secuity management and e can see that RBAC focuses on the management of subjects in figue 4 using uses oles instead of identities. In RBAC, a ole is a semantic constuct foming the basis fo access contol policy. System administatos can ceate oles, gant pemissions to those oles, and then assign uses to the oles on the basis of thei specific job esponsibilities and policy. Theefoe, ole-pemission elationships can be pedefined, making it simple to assign uses to the pedefined oles. RBAC helps (especially, in a lage entepise system) to detemine efficiently hich pemissions have been authoized fo hat uses. Constaints (e.g., sepaation of duties, [8]) can apply to elations and functions in an RBAC model. This is an effective mechanism fo establishing highe-level oganizational policy. Constaints ae pedicates, hich ae applied to the RBAC elations and functions and etun a value of acceptable o not acceptable Task-based Authoization Contols (TBAC) Task-based Authoization Contols (TBAC, [10]) is a taskoiented model fo access contol and authoization. It is an active secuity model that is ell suited fo distibuted computing and dynamic infomation pocessing activities, such as okflo management and agent-based distibuted computing. TBAC focuses on secuity modeling and enfocement fom the application and entepise pespective athe than fom a systemcentic subject-object vie. In the subject-object paadigm, the access decision function checks hethe a subject has the equied pemissions fo the opeation, but it does not cae about the contetual infomation about ongoing activities o tasks. In contast, in the TBAC paadigm, pemissions ae checked-in and checked-out in a just-in-time fashion based on activities o tasks Fine-gained Object Appoaches Conventionally, a file o a data object is a unit of objects fo hich an access contol decision can be made by the opeating system. To povide fine-gained access contol, pemissions can be based on DTD 1 [5] o IDL 2 [9] fo data objects. In othe ods, pemissions can be based on specific fields o methods of data objects. Fo instance, NAI (Netok Associates, Inc.) Lab s OO- DTE (Object Oiented Domain and Type Enfocement, [9]) povides elatively fine-gained access contol than typical object oiented appoaches. It can povide access contol based on individual fields o methods of an object in CORBA-based systems. These appoaches mainly focus on poviding finegained access contol to objects (figue 4). We efe to such appoaches as fine-gained object appoaches in this pape. 1 Document Type Definition that is used in Etensible Makup Language (XML). 2 Inteface Definition Language. 5. ACCESS CONTROL MECHANISMS FOR INTER-ORGANIZATIONAL WORKFLOWS Inte-oganizational okflos have to be eecuted on eisting computing esouces in paticipating oganizations. They may be Windos-based, UNIX-based, LINUX-based, etc. Eisting systems have thei on secuity mechanisms. It is not ealistic to epect paticipating oganizations to change thei computing esouces o secuity mechanisms to suppot inte-oganizational okflos. What is needed ae access contol mechanisms fo okflo that can ok ith eisting systems and secuity mechanisms. Thee ae many ays to povide access contol mechanisms fo inte-oganizational okflos. The access contol mechanisms that e evieed in section 4 ae all applicable to inte-oganizational okflos. The challenge is to satisfy access contol equiements that e specified in section 3 ithout changing the eisting secuity mechanisms and infastuctue of paticipating oganizations. Fom an oganizational-level access contol point of vie, a okflo is an odinay application pogam acting on behalf of uses. Fo eample, figue 5 shos an inte-oganizational okflo that consists of to autonomous okflos. In this eample, each autonomous okflo is just anothe application pogams. Hence, each autonomous okflo should follo its oganization s secuity policy. This implies that if e caefully hide additional access contol mechanisms ithin the WFMS, it does not affect the eisting access contol mechanisms that ee deployed by paticipating oganizations. In this section, e highlight access contol mechanisms that ae incopoated in ou WFMS, SALSA. Since these secuity mechanisms ae managed by SALSA, eisting oganizations secuity mechanisms ae not affected. Oganization1 okflo Oganization level access contol Uses Oganization2 Uses T4 T5 T7 T6 T8 T9 okflo Inte-oganizational okflo Pemissions Oganization level access contol Pemissions Resouces Files Resouces Files Data objects Data objects Figue 5. Inte-oganizational okflo fom conventional access contol point of vie Decoupling Wokflo and Oganization Secuity Infastuctues In SALSA, thee ae to types of tasks: human and automatic tasks. Human opeatos accomplish human tasks and automatic tasks ae accomplished by undelying components (e.g., database, 4

5 eecutables). Hence, no human opeatos ae needed fo automatic tasks. RBAC is a convenient ay fo a system administato to ceate oles, gant pemissions to the oles, and assign uses to the oles on the basis of thei job esponsibilities and the system policy. Theefoe, in the SALSA implementation, e use RBAC fo human tasks. Thee ae many oganizations that can suppot an inteoganizational okflo. Hence, an inte-oganizational okflo may have to inteact ith the secuity infastuctues of seveal paticipating oganizations. If thee is a change in paticipation, a pat of the inte-oganizational okflo has to be moved to othe oganizations, and the inte-oganizational okflo specification (especially secuity specification) may have to be changed. We ant to avoid changing inte-oganizational okflo specifications, including secuity specifications (e.g., ho can access a task). To avoid such disuptions, e need to decouple the okflo-specific secuity infastuctue fom an oganization s secuity infastuctues. Geneally speaking, an oganization s ole seve contains oganization-specific ole stuctues that specify available oles, ole hieachy, and use-ole assignments in the oganization. If a okflo accesses the oganization s ole seve diectly, e cannot achieve this decoupling beteen the okflo secuity infastuctue and oganization secuity infastuctue. To achieve this decoupling, e intoduce a ole domain, hich is a ole stuctue inteface fo okflo. Just like egula RBAC, each ole domain contains specific oles and the elationships among them. Any oganization that needs to paticipate in the coopeation should map its ole stuctue to the ole domain fo the okflo. Because of this indiect inteaction beteen a okflo and oganizations ole stuctue, the changes in the paticipating oganizations do not affect the okflo secuity infastuctue. Instead, these changes ae confined to modification of the mapping fom an oganization s ole stuctue to the ole domain. In this sense, the elationship beteen a ole domain and the ole stuctues of oganizations is simila to the elationship beteen an inteface and a seve implementation in client-seve inteactions. Role domains ae intefaces fo okflos, and each oganization povides a mapping beteen the ole domain and the oganization s specific ole stuctue. SALSA povides a ole edito [4] fo a okflo designe to define a ole domain, oles in the domain, and the elationship among the oles. When a okflo is designed, a okflo designe uses okflo domains, hich ee intoduced in section 2, instead of oganizations. The designe also specifies access contol equiements in tems of ole domains instead of oganizationspecific ole stuctues. Fo eample, an application designe may specify equied oles fo each task in the folloing ay, <Task n, Role>: [{oledomain, (oles)}, {RD_1, (A, B, C, )}, {RD_2, (X,Y, )} ] <Task n, Role> declaes that this is a equied ole assignment fo task n. In this eample, RD_1 is a specific ole domain and A,B,C,D ae specific oles in RD_1. If a use belongs to one of the ole domains in the equied ole set (epessed in [ ]) and has one of the oles in that ole domain o moe pivilege than one of the oles in the equied ole set, he is alloed to pefom the task. The ole assignment to each task duing design time is tuned into a secuity policy fo each task that has to be enfoced duing untime. When a use accesses a task duing untime, he pesents a cetificate 3 that eveals his identity and ole in his oganization. The ObWok s Woklist seve looks up the mapping beteen the ole stuctue of the use s oganization and that of the ole domain. If the use has the pope ole, he can eecute the task and thus access the necessay esouces Fine-gained and Contet-based Access Contol Conside a okflo that consists of 4 tasks:,,, and T4. Futhe, assume that all fou tasks ae in one pocess, and task needs pemission P1, task needs pemission P2, task needs pemission P3, and task T4 needs pemission P4. Using taditional access contol, even if a use needs only pemission P1 to eecute task, he ill get P1, P2, P3, and P4 because conventional access contol mechanisms cannot distinguish diffeent tasks ithin a pocess. Pocess Pemission P1 P3 P2 P4 Figue 6. Taditional access contol model To suppot fine-gained access contol in a okflo, e intoduce task-specific access contol modules (TACM). The pupose of the TACM is to povide fine-gained access contol fo both subject and object (see figue 2) in the folloing ays: 1. Divide a pocess (subject in figue 4) into many tasks, 2. Divide the data set (object in figue 4) that a okflo needs to access into many subsets. This is possible because the esouces that each task needs to access may be a subset of the esouces that the hole okflo needs to access, and 3. Povide access contol beteen divided, thus smalle, subject and divided object. Pocess Pemission P1 P3 P2 P4 Figue 7. Fine-gained access contol model Thus, e make use of fine-gained object appoaches that ee discussed in section 4.3 at the task level athe than the pocess level. We povide a mechanism fo a okflo designe to povide the task-data access specification that descibes hich fields of a data object can be accessed by a specific task. We povide a tool fo a okflo designe to specify a data access 3 In ou implementation, X.509 cetificate is used to povide use ID and ole/oganization infomation. We use Phaos JCA to geneate cetificates and Phaos SSLava fo SSL connection beteen Web bose and ObWok s Woklist seves. 5

6 policy fo each task. In othe ods, each task has its associated data access policy that has a seies of the folloing tiples, <Task n, Data>: [{Data object, field name, pemission}, { }, ] <Task n, Data> declaes that this is a data access contol assignment fo task n. The pemission in this statement can eithe be ead-only, full-contol, no-access, etc. The task data access specification is also tanslated into a untime specification fo ObWok to enfoce. Any violation of the specification causes ObWok to tho a data access eception. In this appoach, if a use has the coect equied ole, the use is alloed to access the task. Hoeve, data access by the use is futhe esticted by the task s contet. Conside a okflo that consists of to tasks, Task1 and Task2. Assume that the folloing access contol policy has been set: <Task1, Role>: [{GM, (Accountant)}, {Fod, (Accountant)}] <Task1, Data>: <Task2, Role>: <Task2, Data>: [{DataObj1, field1, ead-only}, {DataObj2, field3, full-contol}] [{GM, (Manage)}, {Fod, (Poject_leade)}] [{DataObj2, field3, ead-only}, {DataObj3, field2, ead-only}, {DataObj3, field3, fullcontol}] This means that only a use ho has the Accountant ole in GM o Fod ole domains can eecute Task1. When the use eecutes Task1, he has ead-only pemission on field1 in DataObj1 and full-contol pemission on field3 in DataObj2. Ecept field1 in DataObj1 and field3 in DataObj2, the use cannot ead no modify any othe fields o data object. In this sense, SALSA uses capability-based secuity. Figue 8 sho that each task maintains data access capabilities. Fo eample, task can ead fields and of data object D2, and ite to field of D2. In case of human tasks, a human opeato must have a equied ole to access a task. Once the access to the task is ganted, the opeato can access only the potion of data that is in the task s capability list. D1 D2 D3 capability Figue 8. Fine-gained secuity fo all tasks It is inteesting to compae the fine-gained and contet-based access contol that e intoduced in this section to TBAC [10]. As e evieed in section 4.2, TBAC activates and deactivates pemissions in a just-in-time fashion based on the contet associated ith pogessing tasks. If the TBAC is implemented in a centalized fashion (i.e., pemissions ae managed by a cental access contol module), it could intoduce unnecessay constaints (e.g., ace conditions) acoss okflos. In ou SALSA implementation, pemissions ae managed in a distibuted fashion; hence, it does not intoduce unnecessay constaints acoss okflos (i.e., SALSA can enfoce TBAC-like policies in a distibuted fashion). Fo eample, if a use ants to eecute a human task, the use must have the equied ole fo the task. This is enfoced by Access Contol List (ACL) based secuity (see section 5.1 and step1 of figue 9). Note that subjects S1, S2, ae {oledomain, ole} pais and,, ae tasks in step1 of figue 9. Step1: Step2: S1 S2 S3 S4 D1 Figue 9. To-step pocess fo SALSA secuity in tems of access contol matices Once a use is ganted to access a task, the use s access to data objects is futhe esticted by the capability of the task that the use is accessing (step2 of figue 9). Hence, the task povides a contet fo the use s data access. Since the data access is esticted by the capability of each task, thee is no need fo TBAC style activation and deactivation of pemissions in a justin-time fashion based on the contet associated ith pogessing tasks Suppoting Dynamic Constaints Wokflos sometimes equie dynamic constaints such as dynamic sepaation of duty [8] (e.g., 2-man ule). Conside the folloing eample: a simplified employee epense eimbusement scenaio (see figue 10). This eample consists of five tasks; fou human tasks and one automatic task. We assume that a equied ole is associated ith each human task. Fo simplicity, e also assume that all oles ae fom the same ole domain. Any human opeato ho has a ole that is in the equied ole set o has moe pivilege than any of the oles in the equied ole set can eecute the task. Note that the Issue_check and Sign_check tasks equie the same ole in this eample. D2 T4 Access to human tasks ae enfoced by access contol list (ACL) based secuity D3 All tasks have capabilities (Capability-based secuity) 6

7 Pepae Compae Appove Issue check Sign check Requied Role: Employee Pepae an itemized epense eimbusement equest Automatic Task Access database to etieve alloable epenses fo each item and make peliminay appoval Requied Role: Manage Appove the equest Requied Role: Accountant Issue a check Requied Role: Accountant Sign the check that allos untime tasks to quey eecution histoy fom the monito seve. The second aspect is untime suppot. Inte-oganizational okflos consist of seveal autonomous okflos. Hence, thee may be many monito seves. In SALSA, thee is a monito seve pe untime engine. Theefoe, e need some communication mechanisms that echange elevant infomation among monito seves. Each monito seve has its on database so that it can ecod events fom ObWok and anse any quey fom ObWok o monito clients. Monito clients can egiste thei topics of inteests to monito seves. Fo eample, one monito client may be inteested in all events in a specific okflo hile anothe monito client may be inteested in only events that have to do ith a specific task. The monito seve ecods clients inteests and dispatches only those events that each client is inteested in. The monito seve is not only a seve but also a client, so that it can egiste its topics of inteests to othe monito seves and eceive inteesting events fom othe monito seves (figue 11). Figue 10. An eample of a simplified employee epense eimbusement pocess Conside a scenaio hee an employee pepaes an epense eimbusement equest. An oganization may ant to enfoce a secuity policy that specifies that the employee ho pepaed an epense eimbusement equest should not appove the equest. This is a geneal application of the taditional 2-man ule (i.e., sepaation of duty) that can be applied to to diffeent tasks, Pepae and Appove, ith to diffeent equied oles. In othe ods, if the employee, ho initiates the eimbusement pocess, happens to be a manage, then the manage should not appove the epense eimbusement equest that he initiated even though he has both Employee and Manage oles. We can apply the 2- manuletothetoothetasks,issue_check and Sign_check that have the same equied ole, Accountant. In this case, the 2- man ule says that a peson ho issues a check should not sign the check. The Accountant ole can be split into to oles, Accountant1 and Accountant2, and assign Accountant1 to Issue_check task and Accountant2 to Sign_check task ith static sepaation of duty (i.e., uses cannot be assigned to both Accountant1 and Accountant2). Hoeve, that is a solution that educes the numbe of people ho can pefom the task. To ovecome these difficulties, e popose to use histoy-based access contol. We have intoduced the okflo monito seve in section 2. Since the monito seve keeps a log of eecution histoy (e.g., ho pefoms task A in okflo instance 5), a task that equies eecution histoy to make access contol decision can quey the monito seve. To implement this mechanism, e had to etend SALSA. The fist aspect is design-time suppot. We intoduce constaints fo each task. Suppose the folloing constaint must be enfoced: task1 and task3 should not be eecuted by the same peson fo the same okflo instance. A okflo designe can specify dynamic constaints on task1 as!pefome(task3), hich means that a use ho pefomed task3 cannot pefom this task, and!pefome(task1) fo task3. If thee is a dependency beteen task1 and task3, then only the task that is eecuted late may be constained. This ill geneate a untime specification ObWok othe Monito seves Monito Seve DB Monito clients Figue 11. The stuctue of SALSA monito seve Since each monito seve can act as a client e can aange monito seves in a hieachical fashion. Conside a scenaio hee oganization A is collaboating ith oganizations B, C, and D, and oganization A is acting as a coodinato. Assume that each oganization maintains its on okflo and monito seves due to secuity and autonomy issues. Even though they manage thei on okflos, oganization A may need to kno the status of the ok in pogess in oganizations B, C, and D. In this case e can configue monito seves so that oganization A can eceive specific events fom oganizations B, C, and D. 6. SUMMARY In this pape, e descibed okflo-specific access contol equiements such as dynamic constaints, fine-gained and contet-based access contol, and the need to insulate inteoganizational okflos fom oganization level changes. We pesented a ay to satisfy the above equiements. We have intoduced the ole domain as an inteface beteen okflos and oganization-specific secuity infastuctue. We also have intoduced histoy-based access contol fo dynamic constaints, and fine-gained and contet-based access contol. Even though e intoduced the access contol mechanisms in the contet of inte-oganization okflo, they can be applied in othe contets, such as applications ithin a system o an oganization. In ou implementation of these mechanisms fo SALSA, e caefully engineeed the mechanisms so that eisting secuity 7

8 infastuctues of paticipating oganizations ae not affected and the autonomy of each oganization is honoed. We can summaize the SALSA secuity achitectue and its inteaction ith oganizations secuity mechanisms as follos (see figue 12). Thee ae to kinds of access contol modules in the oveall secuity achitectue: An oganization-specific access contol module (OACM) that is contolled by each oganization and enfoces a secuity policy that as set by each oganization. The access contol module in Figue 4 is an eample of an oganizationspecific access contol module. The task-specific access contol module (TACM) that is contolled by each okflo and enfoces task-specific secuity policies. Only a peson ith intimate knoledge of the okflo can set the secuity policy of each task because, in geneal, a task-specific secuity policy depends on the semantics of the okflo. This module enfoces access contol mechanisms that ee intoduced in section 5.2. Since TACMs ae distibuted and autonomous, they cannot enfoce constaints that depend on the activities of othe tasks. To accommodate the needs fo coodinating access contol decision among tasks, e epand the capabilities of the okflo monito. The monito ecods okflo-specific events duing untime and esponds to queies fom the task-specific access contol modules of the okflo. TACMs need to suppot changes in paticipants because oganizations that suppot a specific mission may be changed even befoe the mission is ove. We can achieve this goal by educing the dependency of task-specific access contol modules on paticipating oganizations secuity infastuctue. The okflo secuity seve (WSS) is a tool fo achieving this goal. The okflo secuity seve povides okflo-specific secuity infastuctue infomation (e.g., okflo-specific ole domain) and the mapping infomation beteen the okflo-specific secuity infastuctue and the secuity infastuctues of paticipating oganizations. When the paticipants change, e need to update the mapping beteen the okflo-specific secuity infastuctue and that of paticipating oganizations. Role/ID WSS TACM Monito Events TACM T4 TACM TACM Wokflo Access Contol by Oganization Pemissions OACM Resouces Files TACM: Task-specific Access Contol Module OACM: Oganization-specific Access Contol Module WSS: Wokflo Secuity Seve Figue 12. The SALSA secuity achitectue Data objects Cuently, e have completed implementation of 90% of all the mechanisms that e descibed in this pape. The emaining ok is to modify ObWok to enfoce a histoy-based access contol fo dynamic constaints. We plan to elease the SALSA design tools to the public at the fist quate of CY REFERENCES [1] Etensible Makup Language (XML) 1.0, Wold-ide- Web Consotium, html. [2] G.J. Holzmann, The model checke Spin, IEEE T/SE, Vol. 23, No. 5, May 97, pp See also [3] M. H. Kang, J. N. Fosche, A. P. Sheth, K. J. Kochut, and J. A. Mille, A Multilevel Secue Wokflo Management System, Poceedings of the 11 th Confeence on Advanced Infomation Systems Engineeing, Heidelbeg, Gemany (1999). [4] M. H. Kang, B. J. Eppinge, and J. N. Fosche, Tools to Suppot Secue Entepise Computing, In Poceedings of 15 th Annual Compute Secuity Applications Confeence, Phoeni, Aizona, Decembe [5] D. L. Long, J. Bake, and F. Fung, A Pototype Secue Wokflo Seve, In Poceedings of 15 th Annual Compute Secuity Applications Confeence, Phoeni, Aizona, Decembe [6] K. Kochut, A. Sheth, and J. Mille, ORBWok: A CORBA- Based Fully Distibuted, Scalable and Dynamic Wokflo Enactment Sevice fo METEOR, UGA-CS-TR , Technical Repot, Depatment of Compute Science, Univesity of Geogia, [7] R. S. Sandhu, E. J, Coyne, H. Feinstein, and C. Youman, Role-Based Access Contol Models, IEEE Compute, 29(2): 38-47, Febuay [8] R. Simon and M. E. Zuko, Sepaation of Duty in Role- Based Access Contol Envionments, In Poceedings of Ne Secuity Paadigms Wokshop, Septembe [9] D.F.Stene,G.W.Tally,C.D.McDonell,D.L.Sheman, D. L. Sames, and P. X. Pastuel, Scalable Access Contol fo Distibuted Object Systems, In Poceedings of 8 th USENIX Secuity Symposium, Washington, DC, August [10] R. K. Thomas and R. S. Sandhu, Task-based Authoization Contols (TBAC): A Family of Models fo Active and Entepise-oiented Authoization Management, In Poceedings of the IFIP WG11.3 Wokshop on Database Secuity, August [11] H.M.W. Vebeek, T. Basten, and W.M.P. van de Aalst. Diagnosing Wokflo Pocesses using Woflan. Computing Science Repot 99/02, Eindhoven Univesity of Technology, Eindhoven, Appendi: An Inte-oganization Wokflo Model In ou inte-oganization okflo model, a task epesents an abstaction of an activity. A task can be egaded as a unit of 8

9 ok, hich is pefomed by a vaiety of pocessing entities, depending on the natue of the task. Thee ae to kinds of tasks: a netok task and a simple task. A simple task can be pefomed by (ealized by) a human, o by pefoming a computeized activity though eecuting a compute pogam, a database tansaction, etc. A netok task is pefomed by a netok of inteconnected tasks. Hence, a netok task povides one level of abstaction (vie) and its ealization povides a loe level of abstaction (vie). Since the ealization of a task may contain many tasks at diffeent levels of abstaction, a task is a ecusive efeence in the inte-oganization okflo model. In this model, each task belongs to a okflo domain hich may epesents an oganization o some othe domain (e.g., secuity domain). Figue A shos an inte-oganization okflo (i.e., Task1 that is a top-level netok task) that consists of thee levels of abstactions (vies). In Figue A, Task1 and Task 5 ae netok tasks that ee ealized by a netok of tasks. Othe tasks ae simple tasks that can be ealized by othe means (e.g., human, database, eecutable). Tansition T j epesents a tansition fom Task2 to Task3 (i.e., Task2 has been completed and Task3 can make use of esults that ee poduced by Task2). Tansition T j Task2 Task1 Task4 Task3 Task6 Realized by Task5 Task7 Task8 Realized by Task9 Figue A. An entepise application model A task may play the ole of a souce task o a destination task (e.g., Task2 is the souce task and Task3 is the destination task of the tansition t j in Figue A) fo a numbe of tansitions. All of the tansitions fo hich a task is the destination task ae called the input tansitions fo that task (e.g., tansition t j is an input tansition fo Task3). Likeise, all of the tansitions fo hich a task is the souce task ae called its output tansitions (e.g., tansition t j is an output tansition of Task2). A tansition may have an associated Boolean condition, called its guad. A tansition may be activated only if its guad is tue. The classes (i.e., types of objects) that ae associated ith an input tansition to a task ae called the task s input classes, and those appeaing on an output tansition ae called output classes of that task. A task's output class, hich is not its input class, is ceated by the task. A task's input class, hich is not its output class, is dopped (consumed). Note, that some input classes may be unused by the task. They ae simply tansfeed to the task s successo(s). A goup of input tansitions is called an AND-join if all of the paticipating tansitions must be activated fo the task to be enabled fo eecution. An AND-join is called enabled if all of its tansitions have been activated. All the input tansitions of a task may be patitioned into a numbe of AND-joins. A goup of input tansitions is called an OR-join if the activation of one of the paticipating tansitions enables the task. A goup of tansitions is said to have a common souce if they have the same souce task and all lead eithe fom: its success state, o its fail state A goup of common souce tansitions may fom eithe: 1. AND-split: Each of the tansitions in the goup has the condition set to tue. It means that all of the tansitions in the goup ae activated, once the task completes. 2. OR-split (selection): An odeed list of tansitions hee all but the last tansition may have abitay conditions (i.e., the last tansition on the list has the condition set to tue). The fist tansition hose condition is satisfied ill be activated. 3. Loop: A special case of an OR-split, hee the list is composed of eactly to tansitions: loopback and continue. Loopback implies banch taken and continue implies banch not taken (i.e., fall though). 9