Seediscussions,stats,andauthorprofilesforthispublicationat:http://www.researchgate.net/publication/221142053

EngineeringPoliciesforSecureInterorganizationalInformationFlow

CONFERENCEPAPER·JANUARY2011

DOI:10.1109/EDOCW.2011.31·Source:DBLP

CITATIONS

2

DOWNLOADS

43

VIEWS

94

4AUTHORS,INCLUDING:

BenjaminFabian

Humboldt-UniversitätzuBerlin

69PUBLICATIONS344CITATIONS

SEEPROFILE

SebastianMüller

FreieUniversitätBerlin

9PUBLICATIONS17CITATIONS

SEEPROFILE

Availablefrom:BenjaminFabian

Retrievedon:01July2015

Engineering Policies for Secure Interorganizational Information Flow

Steffen Kunz, Benjamin Fabian, Daniel Marx, Sebastian MullerInstitute of Information SystemsHumboldt-Universitat zu Berlin

10178 Berlin, Germanysteffen.kunz, bfabian, daniel.marx, sebastian.mueller.4@wiwi.hu-berlin.de

Abstract—Information flow between organizations has in-creased tremendously in recent years, for example in infor-mation federations of closely cooperating partners in a valuechain. With this intensified exchange, information securitybecomes a major issue. In particular, coordinated accesscontrol policies must be derived by multiple organizations in asystematic fashion. However, current access-control modelingmethodologies do not sufficiently address interorganizationalinformation flow. In order to close this gap, we provide amethodology for engineering access control policies betweenmultiple organizations, which is motivated and exemplified bya case study on information federation in the industrial servicesector. Furthermore, we present a tool-supported approachfor semi-automatic generation of interorganizational role-basedaccess control policies derived from graphical business processmodels.

Keywords-Access Control Policies, RBAC, Interorganiza-tional Processes

I. INTRODUCTION

Increased cooperation between organizations through net-worked information systems via the Internet raises the needfor cross-domain security mechanisms [1][2]. This is ofeven higher relevance with emerging trends like the futureInternet of Services [3] and the Internet of Things [4][5]. Animportant example is the increased information exchange inclosely cooperating value chains where information secu-rity is a major issue [6]. Current access-control modelingmethodologies do not sufficiently consider interorganiza-tional cooperations, which present new challenges for thecontrol of economic value exchange [7] and for security[8][9]. Besides technological issues, many organizationaland management challenges need to be resolved to estab-lish a secure information flow where access is limited toauthorized employees and partners . Especially the design ofinterorganizational authorization and access control policiesis an important and difficult challenge due to the complexityof cross-company relations.

A comprehensive approach for reducing the complexityin access control policy design was recently presented in[10] by Strembeck. Extending earlier work, he describesscenario-driven role engineering, an approach that resultsin a ”[...] system- or organization-specific Role-Based Ac-cess Control (RBAC) model [...]” (cf. [10], p. 30) as a

methodology for reducing the complexity for the generationof access control policies. However, this approach is nottaking relations between multiple companies and globalinformation exchange into consideration, which is also thecase for less prominent approaches described in the RelatedWork Section (Section II).

Addressing this gap in security research and managementpractice, we extend the methodology of [10] to multi-domainenvironments using federations of heterogeneous informa-tion systems. Through this paper, we intend to answer thequestion how companies can improve security in interorga-nizational information exchange – involving partners suchas suppliers or customers – by deriving RBAC policiesfrom business process models. We assume that corporatemanagers modeling access control policies, in general, haveonly local process knowledge about their own domains.This implies that the policy creation process has to bedesigned as a dialog between access control policy modelersof different domains. As declarative policy language andexchange format, we apply the eXtensible Access ControlMarkup Language (XACML) [11] (see Section IV).

The rest of the paper is structured as follows. We discussrelated work to our research in in Section II. Section IIIpresents a real world case study in the industrial servicesector. Then, in Section IV, we introduce our methodologyfor modeling interorganizational process-driven role engi-neering. Section V focuses on our BPAX converter, whichwas developed to provide tool support for our methodology.In Section VI, we apply our methodology to the industrialservice sector case study. Section VII gives an overview onlimitations and discusses future work. Finally, in SectionVIII, a conclusion is provided.

II. RELATED WORK

Related work to our research can be generally be foundin two major areas: (a) access control models in general,and specifically (b) methodical engineering of access controlpolicies. In the research area (a), a variety of differentapproaches exist. In their early stage, mandatory and dis-cretionary access control models were built for operatingsystems (see [12]), where the latter involved an accesscontrol list or matrix, mapping subjects to permissions

for objects based on the decision of the object owner.Discretionary access control turned out to be more flexibleand prevailed in most application settings. Later on, accesscontrol was extended to whole organizations, though theaccess control matrix approach turned out to be not suitablefor large companies with thousands of users due to highmanagement and maintenance efforts and costs. This leadto the development of Task Based Access Control (TBAC)[13] and RBAC [14], which are providing active and passiveaccess control, respectively. According to [13], active accesscontrol refers to activities and task-based modeling andenforcement of security permissions during the lifetime ofthe workflow. Passive access control implies that subjectsare provided with more permanent access to objects in asystem, independent of a particular task at hand.

Since both approaches have various shortcomings, newaccess control models have been developed by the researchcommunity, but are so far rarely used in practice. [15] givesa general comparison of RBAC and TBAC and points outthe weaknesses of both approaches. They provide a newapproach, which is Task-Role-Based Access Control (T-RBAC), a hybrid approach of RBAC and TBAC. However,they focus on company-based access control and do nottake interorganizational information flow and access controldesign into account. In fact, they explicitly state this asone of the shortcomings of their approach. [16] provide aTask-Activity Based Access Control (TABAC) model forcollaborating environments, which is based on the earlyapproaches of TBAC. They especially focus on dynamicpermissions related to tasks in processes in order to meetthe special requirements of collaboration scenarios. In ourpaper, we explicitly focus on RBAC because it is a de-facto standard in security practice (see for example [17][18])and can be implemented in XACML [11], which is widelyaccepted in industry and is integrated in many securityarchitectures.

As far as the specific research area (b) on methodicalengineering of access control policies is concerned, [10]describes scenario-driven role engineering, which also offerstool support [19]. This comprehensive approach breaks downthe complexity in corporate processes. Scenario-driven roleengineering is similar to our approach since scenarios consti-tute of tasks and work profiles, which can also be regarded asprocess steps. [20] proposes a goal-driven role engineeringprocess, which represents a research line with a considerablydifferent point of view compared to our approach (goalsvs. processes) and which should be further investigated infuture work. [21] provides a model-driven approach forthe specification and analysis of access control policies. Incontrast to our approach, it does not focus on processes buton organizational structures, which is also reflected in thechoice of their SI* modeling notation – originally developedfor modeling socio-technical systems. The same is true forthe work by [22] who applied Model Driven Security as

methodology for developing secure systems. They definedtheir own modeling language named SecureUML, providinga well defined framework for security design. As the authorsmention in their work, the approach does not provide anyguidelines how roles and access control policies can beidentified.

Based on the scenario-driven role engineering approachby [10], [23] provides a methodology for integrating RBACand the Business Process Execution Language (BPEL) on ameta-model. They define a mapping from RBAC to BPELenabling the extraction of RBAC elements from BPEL.However, since BPEL is per se not a graphical modelinglanguage, this approach does not improve the usability forend-users. In their work [24] define a mapping betweenXACML and BPMN in order to enable model-driven ex-traction of security policies from a business process model.As a proof of their concept, they applied their methodologyto a banking domain business process.

All presented approaches do not address interorganiza-tional information flow, which is the main focus of our work.This problem is addressed by [25], though not for accesscontrol engineering but for BPEL. In their approach, theyapply the UN/CEFACT Modeling Methodology (UNM) formodeling top-down interorganizational business processes.They use agreements made in a global choreography formodeling a local orchestration or a choreography of businessprocesses.

III. CASE STUDY AND REQUIREMENTS

In this Section an industrial service sector case study fromAletheia [26], a research project on information federation, ispresented [27][8], motivating our research on access controlfor interorganizational information flow. The focus of thecase study is the maintenance and repair of a defectivedevice in a power plant.

The service process is supported by a semantic federationsystem where access on resources is granted based onidentifiers, here the common concept of URI [28], whichis also used as a unique reference to identify resources ina semantic datastore. The connection between the differentdomains is established by gateway servers called AletheiaService Hubs (ASH).

As depicted in Figure 1, four different parties are involved:The Service Provider (SP) is selling, integrating, and main-taining the devices (e.g., dynamos, voltage converters, andturbines). The Logistics Provider (LP) is responsible for thewarehousing and shipping of spare parts and devices of theservice provider. In this specific case study the Customeruses the devices in an power plant, which is located in aremote and scarcely populated area. Due to the fact that theservice provider does not have any local branches in thisarea, the service job is accomplished by a sub-contractedPartner Company (PC). Though the service provider and thepartner company should be able to provide an equivalent

Service

Provider

Service

DispatcherASH

Process Flow

Service

Partner

TechnicianASH

Customer

2. Dispatch and Prepare Service Job

3. Identify Defective Device4. Repair Defective Device5. Update Service History6. Order Spare Part8. Schedule Delivery9. Send Delivery Updates10. Send Confirmation

Plant Manager

Logistics

Provider

ASH

7. Check Stock Information of Spare Part

9. Send Delivery Updates

1. Report Problem

8. Schedule Delivery

9. Send Delivery Updates

10. Send Confirmation

Forward

Figure 1. Process Flow between Different Domains of an Industrial Service Job [9]

service, the access rights of a partner company employee toproduct- or customer-related information are restricted.

The first step in an industrial service job is initiated by thecustomer plant manager (1) connecting to the ASH and pro-viding a detailed problem description for a defective devicein the power plant. Then, (2) the service dispatcher of theservice provider assigns a partner company technician to theservice job. In addition, she provides the partner technicianwith important information about the service job. In the nextstep, the partner technician drives to the customer’s powerplant and (3) identifies the defective device. This process aswell as the (4) repair of the defective device is supported byinformation from the Aletheia system. After the problemhas been solved, (5) the service history of the device isupdated with information gathered during the service job– e.g., test and calibration measures. In this specific usecase, we assume that a spare part is required in order tosolve the problem. This spare part (6) needs to be orderedfrom the logistics provider warehouse. Aleteia supports theordering process by (7) checking the availability of the sparepart and by (8) scheduling the delivery date and locationwith the plant manager and the partner company technician.In addition, (9) Aletheia provides delivery updates duringthe shipping process which are used for rescheduling themeeting of the partner technician and the plant manager, ifnecessary. Finally, after the successful delivery of the sparepart, the partner company technician and the plant manager(10) confirm the delivery.

Based on the case study and interviews with the projectpartner domain experts, we were able to identify the fol-lowing requirements: The individual stakeholders may havedifferent access-control policies and therefore different rolestructures. Accordingly, the engineering methodology shouldbe generic and applicable to different domains, informationsystems, and resources. The modeler should be able to modelthe policies without global knowledge of all domains, i.e.,

local process knowledge must be sufficient. Further, themethodology should be flexible enough to support central-ized as well as federated access control engineering. Thisalso implies that the methodology should provide scalabilityfor different types of organizations – small versus multi-national. A common standard and vocabulary for interoper-ability between the different information systems is required.Another major requirement is the usability for end-users –ideally business users with domain and process knowledgeshould be able to model and define the access rights. Inaddition, the methodology should support dynamic changesin order to change access-control policies at runtime.

IV. POLICY-ENGINEERING METHODOLOGY

The goal of our approach is to methodically engineertailored RBAC policies for interorganizational informationexchange. A major assumption is that process and policyengineers from different stakeholders collaborate to establisha common understanding on cross-organizational informa-tion exchanges and are willing to establish a commonterminology for information resources and access actions.Our methodology does not require a global knowledgeon all internal processes of the involved stakeholders thusrespecting the confidentiality of the processes. Further, themethodology is aimed to be conducted between equal peers,without a central supervising coordinator.

As standard notation for defining access control policies,we decided to use the XACML, which is a declarativeaccess control policy language implemented in the extensibleMarkup Language (XML). XACML policies consist of aset of rules and a rule combining algorithm. Every rulehas its rule target with subjects, resources, and actions. Asubject could be an entity like an user, a resource couldbe a document, and an action could be reading or writingaccess. The generation of the corresponding XACML poli-cies is conducted through a conversion of interorganizational

processes notated in Business Process Modeling Notation(BPMN, [29]) by our BPAX toolset (see Section V).

Figure 2 depicts our policy-engineering methodology. Itconsists of the two choreography tasks of type A and B. Themethodology can be regarded as a continuous improvementcycle where each iteration can be considered as one processinstance.

(A2) Update

Terminology

for the Action Word

Glossary

Information Owner

Information Requester

(B) Convert Process

Model to XACML

Policy

Information Requester

Information Owner

(A1) Define

Terminology

for the Action Word

Glossary

Information Owner

Information Requester

+

Figure 2. Policy-Engineering Methodology

In order to engineer access control policies, a commonterminology of actions on resources must be establishedbetween the participating stakeholders. The so-called actionword glossary of a domain contains action words that de-scribe an action executed on information or system resources([11], p. 50). The glossary has to be consistent with all accessforms of each information system in the domain. Actionwords themselves are part of the rules in XACML policies,and describe the access request that is sent to the informationsystem. It is important to standardize and to define themin the action word glossary in order to be syntacticallyconsistent between different domains.

Table IEXAMPLE OF ACTION WORD GLOSSARY

Action Word DescriptionInformation System 1

request Reading the content of the information sourcewrite Reading and changing the content of the infor-

mation sourceInformation System 2

read Reading the content of the information sourcewrite Reading and changing the content of the infor-

mation source

An example action word glossary is displayed in Table I.It contains two different information systems with both casesof a common and a divergent semantic of the action words.In both information systems, write has the same meaning,but reading of information is either expressed by request orread, depending on the specific system.

After the execution of step (A1) or step (A2), the in-formation requester initiates step (B), which is described in

the interorganizational process models displayed in Figure 3.Step B consists of three phases and involves the informationowner as well as the information requester in their disjointdomains. The three phases are the initiation phase, theupdate phase, and the submission phase.

The initiation phase is triggered by one of two followingsteps. Either the information requester chooses an alreadyexisting interorganizational process (1a), or she starts tomodel a new interorganizational process (1b). Then, sheenters the update phase, which involves step (2) to step (4).These steps can be followed serially, or if a need for changearises, a loop back to a prior step can take place.

The information requester initiates step (2). She has toanalyze the whole interorganizational process and has tosearch for tasks that access information sources in theexternal domain. She updates all tasks according to theaction words of the glossary, which were created by theinformation owner. Then, in step (3), again initiated by theinformation requester, all necessary resources have to beinvestigated and integrated into the process model. Eachtask needs associated connections between the task itselfand a data object representing the information resource inboth domains. The information owner is the initiator of thelast step (4) of the update phase. She has to investigate theinterorganizational process draft for resources in the domainto which the information requester needs access. Dependingon the information system, she has to determine the exactlinks to the requested resources, such as Uniform ResourceIdentifiers (URI) that are used in semantic datastores asidentifiers for resources (cf. Section VI).

In the submission phase, both participants submit their en-gineered BPMN models. The information requester assuresthat she is content with all the privileges she was granted.Vice versa, the information owner declares that she agreesto offer the information requester access to the requestedinformation resources. In the last step, the information ownergenerates the XACML access control policies with BPAX(see Section V).

Common modeling rules are necessary that describe howto use the methodology in accordance to the BPMN standard(see also Figure 4):

1) A glossary of the action words must exist before theupdate phase is reached.

2) An information system is modeled as BPMN lane.3) If more than one information system is affected in one

domain, the task has to be connected to the correctinformation system ensuring the right action wordglossary.

4) The processes have to be modeled from the informa-tion requesters point of view.

5) The information requesters external role has to bemodeled as BPMN lane.

6) The verb, in this case the action verb, has to be thefirst word of the task in the infinitive (or imperative)

(1b) Create new

Interorganizational

Process

Information Requester

Information Owner

(2) Update Activity

Syntax of Inter-

organizational

Processes

Information Requester

Information Owner

(1a) Use Existing

Interorganizational

Process

Information Requester

Information Owner

(3) Update

Requested Resources

of Interorganizational

Processes

Information Requester

Information Owner

(4) Update

Requested Resources

Information Owner

Information Requester

(5b) Submit Inter-

organizational

processes

Information Requester

Information Owner

(5a) Submit Inter-

organizationaln

Processes

Information Owner

Information Requester

Initiation Phase Update PhaseSubmission Phase

Figure 3. Step (B): Conversion of Process Models to Policies

form.7) The task has to be connected with the information

system lane by a message flow connection indicatingan interorganizational message flow.

8) Each data object – as input or output of the interor-ganizational message flow – has to be connected viaunidirectional associations with the task.

If these assumptions are fulfilled, a mapping can beconducted between the graphical BPMN model and theXACML policies.

Exte

rna

l R

ole

Na

me

Read Data Write Data

Rule 5

Rule 8

Rule 6

Do

ma

in A

Do

ma

in B

Info

rma

tio

n

Syste

m 1

IS 2 Rule 7

Rule 2

Figure 4. Fundamental Modeling Rules

V. BPAX CONVERTER

The following section presents our developed tool whichconverts the interorganizational BPMN process into anXACML policy or an XACML policy set. Our methodology

assumes that all parties involved have access to the interorga-nizational process model, implying that a basic user-accessmanagement is required in the BPMN modeling tool. Fur-ther, connectivity to other software components is necessary.This can comprise a simple, standardized export feature(e.g., through an XML file) or a Web service. These features– user-access management and connectivity to other softwarecomponent environments – are two important requirementsprovided by the open-source process modeling tool Oryx[30].

Oryx requires a so-called OpenID to login, i.e., a thirdparty identification and authentication (cf. [31]). The ownerof the BPMN process can control the implemented useraccess rights and role management by adding other users’OpenIDs, either as contributors or readers. The supportedroles are owner, contributor and reader. Besides the exportfunctionality via standardized XML files and the essentialBPMN 2.0 implementation, Oryx supports older BPMNversions and other graphical process notations [30].

The structure and functionality of our BPMN to XACMLConverter (BPAX) are presented in Figure 5. The converterconsists of both a Web frontend for the interaction withthe user and a backend, which is responsible for the wholeconversion process. The fundamental aim of the Web toolis to generate an XACML policy or an XACML policy setfrom the interorganizational BPMN process.

The Web frontend is an extension of the converter andconsists of two JavaServer Pages. One of them offers thepossibility to upload the Oryx XML file of the interorganiza-tional business process. The other concerns the configurationof the web-tool.

Conversion Process – From BPMN to XACML. Oncethe user initiates the file upload, she triggers the wholetransformation process from an interorganizational BPMN2.0 process to an XACML access control policy, resultingin the corresponding XACML policy (or policies). Thedifferent steps of the aggregated conversion are explained

in the following lines (see also Figure 5).

Loop

(2) Initiation

(5) Sending XACML

Target Elements

(1) Initiation

(4) Querying XACML

Target Elements

(3) Sending XACML

Target Elements

Identify()

6. Sending XACML

Policy/Policies

save()

Extract()

Merge()

Web-Frontend

XACMLPolicyBuilder XACMLElementParser

Figure 5. BPMN to XACML Converter – UML Sequence Diagram

First, the web frontend saves the uploaded XML filelocally on the webserver using the save() method. The webfrontend initializes the main class XACMLPolicyBuilder (seestep (1)), which controls the data flow.

Then the XACMLPolicyBuilder initiates the XACMLEle-mentParser by providing the file location of the tempo-rary saved, interorganizational process (see step (2)). TheXACMLPolicyBuilder is responsible for building all possibleand necessary XACML policies within the loop while theXACMLElementParser is responsible for extracting all thecharacteristic BPMN 2.0 information (see method extract()),step (3)). In the next step, the characteristic process infor-mation are mapped to the XACML target elements (subject,resources, and actions), whereas the XACMLElementParsermerges all data objects of all interorganizational tasks (seenext paragraph). Then, the XACMLPolicyBuilder contin-ues by identifying all interorganizational actions with theidentify() method. It builds the final XACML policies byquerying the XACMLElementParser for detailed informationabout subject, resources, and actions (see step (4) and (5)).Finally, the frontend receives the results of the processedXML file of the XACMLPolicyBuilder (see step 6) and offersall XACML policies for downloading.

Merging Algorithm. One of the most important tasksof the XACMLElementParser is to reduce the complexityand to limit the number of XACML policies. This isachieved by joining all referenced resources for all uniqueand interorganizational elements from the action word glos-sary. The merging avoids the generation of more than oneXACML policy per unique action. The algorithm is executed

independently for every information system, i.e., if there aretwo different information systems and one identical actionperformed in each of them, the final outcome will be thatthese actions are not merged.

In the following example (cf. Figure 6) the task writeoccurs two times in a row. Since it occurs in the sameinformation system, the XACMLElementParser maps allreference resources to a single write task.

Dom

ain

A

Information System1

1

Write Merging

2

Write

1

Write

2

Dom

ain

AD

om

ain

B

Information System1

Dom

ain

B

Figure 6. Process Merging

There are two approaches how the merging of thosetasks could be implemented: the all-task approach and thecollaborative-task approach. The difference between themis either to check all tasks within the process or just tocheck collaborative tasks, respectively. Since the standard-ized XML document offers the required information for theidentification of collaborative tasks, the BPAX converter ana-lyzes only the actions that are linked within the collaborationdata. Even if there are only unique and interorganizationaltasks that cannot be merged, this approach will be less orequal time consuming than the all-task-approach.

Structure of an XACML Policy. Every XACML policycontains two rules. The first rule covers its own targetconsisting of an XACML subject, resource(s) and an action,where the subject is the name of the information requester’sBPMN lane and the action is derived from the affectedBPMN process task. The connected BPMN data object(s)are derived from the task form(s) of the XACML resources.This rule allows the subject to access all mentioned resourceswith the given action. The second rule denies each accessof further subjects, resources, and actions, if not allowedin another XACML policy. The structure of the XACMLpolicies guarantees the least privilege paradigm (cf. [32]).

VI. PRACTICAL APPLICATION

In the following section, the individual steps of ourmethodology are exemplified based on the case study pre-sented in Section III. For brevity, only one interorganiza-tional process is investigated in detail in this paper: theservice partner - service provider relationship that in theordering of spare part process – see the sequence diagramin Figure 7. Here, a partner technician who belongs to theservice partner domain, was subcontracted by the serviceprovider to conduct a service job. She has to order a spare

part, which involves interorganizational processes betweenthe service partner domain and the service provider domain.

Service Provider

(6) Order Spare Part

(8.4) Request Confirmation of Delivery Date

(8.5) Confirm Delivery Date

(9) Send Delivery Updates

(10) Confirm Delivery

Service Partner

Technician

Figure 7. Scenario: Ordering of Spare Part [9]

First, in step (A1) the information owner has to definewhich kind of actions the involved partner is generallyallowed to do in her domain of the information system. Thiscase study covers only one information system, accordinglythe single action word glossary contains the actions read,write, and create, which is displayed and briefly explainedin Table II – only three possible actions are allowed, allothers are denied (cf. [11] and Section IV).

Step (B) of our methodology (Figure 2) is described indetail in the following.

Table IIACTION WORD GLOSSARY FOR THE SERVICE PROVIDER DOMAIN

Service Provider Information SystemAction Word Descriptionread Reading the content of Service Provider infor-

mation sourcewrite Reading and changing the content of Service

Provider information sourcecreate Creating a new content instance at Service

Provider information source, e.g., a new order

Step (1b): Create New Interorganizational Processes.Step (1b) in Figure 8 shows the BPMN diagram derived fromthe sequence diagram in Figure 7. BPMN message flow arcsconnect information requester and information system.

Step (2): Update Task Syntax of the Interorganiza-tional Process. There are three tasks that fulfill the conditionof user access to resources in the external domain. Thedescription of these tasks have to be updated according to theaction word glossary (cf. Table II). The outcome is displayedin step (2) in Figure 8. In particular, the three tasks initiatedby the partner technician were updated so that every taskbegins with an element of the action word glossary (createoder spare part, write confirmation of delivery date, writeconfirmation of delivery).

Order Spare Part

Request Conf. of Delivery

Date

Confirm Delivery

Date

Receive Delivery Updates

Confirm Delivery

Step (1b)

Create Order

Spare Part

Receive Request of

Conf. of Del. Date

Write Conf. of Delivery

Date

Receive Delivery Updates

Write Conf. of Delivery

Step (2)

Step (3)

Create Order

Spare Part

Receive Request of

Conf. of Del. Date

Write Conf. of Delivery

Date

Receive Delivery Updates

Write Conf. of Delivery

Order Spare Part

Order Spare Part

Order Spare Part

Step (4)

Create Order

Spare Part

Receive Request of

Conf. of Del. Date

Write Conf. of Delivery

Date

Receive Delivery Updates

Write Conf. of Delivery

http://www.sp.com/order/spare_part/#DeliveryDate

http://www.sp.com/order/spare_part/# http://www.sp.com/order/spare_part/#

Serv

ice

Part

ner

Technic

ian

Serv

ice

Pro

vid

er

IS

Serv

ice

Part

ner

Technic

ian

Serv

ice

Pro

vid

er

IS

Serv

ice

Part

ner

Technic

ian

Serv

ice

Pro

vid

er

IS

Serv

ice

Part

ner

Serv

ice

Pro

vid

er

Technic

ian

IS

Figure 8. Interorganizational Process between Partner Company andService Provider

Step (3): Update Requested Resources of the In-terorganizational Process. After correcting the informationrequester’s task description, the information requester hasto connect the affected tasks with data objects includingmeaningful data descriptions (step (3) in Figure 8) so thatthe information owner can determine the necessary datadefinition of the semantic data sources in the next step (4).It is important to model the directions of the data objectconnectors correctly [29].

Step (4): Determine Exact Links (URIs) of RequestedResources. In the fourth step, only the information owneris active. She has to determine what kind of resources theinformation requester is querying. The result is printed inFigure 8 (step 4) and contains URIs that refer to entities ofan ontology – as assumed at the beginning of the section,the information owner uses a semantic database.

Steps (5a, 5b): Submit Interorganizational Process.Assuming that no further changes have to be done, thegenerated XACML policy set contains the policies for therole partner company technician in the domain serviceprovider (cf. Listing 1). For brevity only the permit policy

for the action created is displayed. These XACML policieswere generated with the BPAX converter (Section V).

1 <? xml v e r s i o n = "1.0" e n c o d i n g = "UTF-8"?>

2 <P o l i c y . .3 P o l i c y I d ="aletheia:sp:policyid:1"4 RuleCombingAlgId="

urn:oasis:names:tc:xacml:1.0:rule-

combining-algorithm:first -applicable

" >5 <P o l i c y D e f a u l t s>6 <XPathVers ion>h t t p : / /www. w3 . org / TR/ 1 9 9 9 /

Rec�xpath �19991116 < /7 XPa thVers ion>8 < / P o l i c y D e f a u l t s>9 <T a r g e t />

10 <Rule R u l e Id ="aletheia:sp:ruleid:1"E f f e c t ="Permit">

11 <D e s c r i p t i o n>P a r t n e r Company T e c h n i c i a n</ D e s c r i p t i o n>

12 <T a r g e t>13 <S u b j e c t s>14 <S u b j e c t>15 <S u b j e c t M a t c h MatchId="

urn:oasis:names:tc:xacml:1.0

:function:string-equal">16 <A t t r i b u t e V a l u e DataType="http://www.

w3.org/2001/XMLSchema#string">17 P a r t n e r Company T e c h n i c i a n18 < / A t t r i b u t e V a l u e>19 <S u b j e c t A t t r i b u t e D e s i g n a t o r20 A t t r i b u t e I d ="

urn:oasis:names:tc:xacml:2.0

:subject:role"

21 DataType="http://www.w3.org/2001/XMLSchema#string" />

22 < / S u b j e c t M a t c h>23 < / S u b j e c t>24 < / S u b j e c t s>25 <R e s o u r c e s>26 <Resource>27 <ResourceMatch MatchId="

urn:oasis:names:tc:xacml:1.0

:function:string-equal">28 <A t t r i b u t e V a l u e DataType="http://www.

w3.org/2001/XMLSchema # string">29 h t t p : / /www. sp . com / o r d e r / s p a r e p a r t / #30 < / A t t r i b u t e V a l u e >31 <R e s o u r c e A t t r i b u t e D e s i g n a t o r32 A t t r i b u t e I d ="

urn:oasis:names:tc:xacml:1.0

:resource:target-namespace"

33 DataType ="http://www.w3.org/2001/XMLSchema#string" />

34 < / ResourceMatch >35 < / Resource>36 < / R e s o u r c e s>37 <A c t i o n s>38 <Ac t i o n>39 <Act ionMatch MatchId="

urn:oasis:names:tc:xacml:1.0

:function:string-equal">40 <A t t r i b u t e V a l u e DataType ="http://

www.w3.org 2001/XMLSchema#string

">41 c r e a t e42 < / A t t r i b u t e V a l u e >43 <A c t i o n A t t r i b u t e D e s i g n a t o r44 A t t r i b u t e I d ="

urn:oasis:names:tc:xacml:1.0

:action:action-id"

45 DataType="http://www.w3.org/2001/XMLSchema#string" />

46 < / Act ionMatch >47 < / A c t i o n>48 < / A c t i o n s>49 < / T a r g e t>50 < / Rule>51 <Rule R u l e Id ="aletheia:sp:ruleid:2"E f f e c t

="Deny">52 < / Rule >53 < / P o l i c y >

Listing 1. XACML Policy for the Action Create

VII. DISCUSSION AND FUTURE WORK

The represented approach fulfills most of the requirementsinitially identified: It is generic and applicable to differentdomains, can be applied for central as well as decentralaccess control engineering, provides the possibility to definea common vocabulary for cross-company collaboration, andoffers the required scalability for various types of organi-zations. Further, no global modeler knowledge is requiredand the presented approach allows, theoretically, dynamicchanges at runtime, though this also depends on the under-lying authorization infrastructure.

However, in this paper the issue of usability was notaddressed: The approach involves several manual tasks thathave to be executed by the users, which may involve coor-dination difficulties when executed in real world settings,especially if more than two domains and two stakehold-ers are involved. Therefore, the choreography between thedifferent stakeholders should be somehow automated. Aworkflow engine in the background would be a solutionto this problem. Ideally, such an workflow engine wouldbe integrated into the Oryx framework, guiding the userthrough the interacting modeling tasks of our methodology.Such a guided modeling approach is the focus of our futureresearch. In the long run, we intend to facilitate the modelingof access control policies for normal business managers.Accordingly, additional user studies and expert interviewsare necessary for improving the usability of the proposedapproach.

Another issue that has to be addressed in future workis the question where to store access control policies andwhere to manage access control policies. In our applicationscenario, we assumed a decentralized storage and manage-ment of access control policies, due to the natural lack oftrust between stakeholders of different domains. Future workshould also investigate the possibility of an administrationpoint managed by an independent and trustful authority,where roles and policies are stored and maintained. Thisalso involves studies on practical complexity of human andtechnical interaction patterns of interorganizational accesscontrol design and on trade-offs involved when the numberof domains and interactions increase. A globally providedontology for roles and resources could support addressing

of information sources and management of action wordglossaries. Also update or synchronization mechanisms fordecentralized access control policies, identified as require-ment in the case study, should be further investigated.

At the moment, only interorganizational processes mod-eled with BPMN 2.0 can be handled by BPAX. Since oneaim of the converter design is to be flexible, it can be ex-tended to other languages and environments by implement-ing their parsing engines, too. Furthermore, the adaptationof BPAX with Web services is an important goal in orderto reduce manual steps for the end user and to offer SOAintegration.

We intend to integrate the BPAX converter into the inte-grated Aletheia security architecture and combine it with ouralso newly developed enforcement components for semanticrepositories in order to provide a comprehensive securitysolution for information federations.

VIII. CONCLUSION

In this paper, we presented an approach for semi-automatic generation of interorganizational policies frombusiness process diagrams. Though various research onmodeling access control policies exists, few researchersaddressed interorganizational aspects that become increas-ingly important for cooperating organizations and businessespartners. The main contribution of this paper is to providea methodology for structuring the complexity of accesscontrol for interorganizational information flows betweenbusiness partners. Our methodology does not require globalprocess knowledge of the individual stakeholders, which isespecially important considering the natural lack of trustbetween organizations. This approach was illustrated by acase study from the industrial service sector. Furthermore,we developed a corresponding tool support called BPAXthat facilitates the interactive conversion of business processmodels into XACML policies.

REFERENCES

[1] Coetzee, M. and Eloff, Jan H. P., “Virtual Enterprise AccessControl Requirements,” in Annual Conference of the SouthAfrican Institute of Computer Scientists and InformationTechnologists (SAICSIT ’03), 2003, pp. 285–294.

[2] D. Harris, L. Khan, R. Paul, and B. Thuraisingham, “Stan-dards for Secure Data Sharing Across Organizations,” Com-puter Standards & Interfaces, vol. 29, no. 1, pp. 86–96, 12007.

[3] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio,“Interacting with the SOA-based Internet of Things: Discov-ery, Query, Selection, and On-Demand Provisioning of WebServices,” IEEE Transactions on Services Computing, vol. 3,pp. 223–235, 2010.

[4] S. Haller, S. Karnouskos, and C. Schroth, “The Internet ofThings in an Enterprise Context,” in Future Internet – FIS2008, ser. LNCS, J. Domingue, D. Fensel, and P. Traverso,Eds. Springer, 2009, vol. 5468, pp. 14–28.

[5] B. Fabian and O. Gunther, “Security Challenges of theEPCglobal Network,” Communications of the ACM, 2009.

[6] R. Sarathy and K. Muralidhar, “Secure and Useful DataSharing,” Decision Support Systems, vol. 42, no. 1, pp. 204–220, 10 2006.

[7] V. Kartseva, J. Gordijn, and Y.-H. Tan, “Inter-OrganisationalControls as Value Objects in Network Organisations,” inAdvanced Information Systems Engineering, ser. LNCS,E. Dubois and K. Pohl, Eds. Springer, 2006, vol. 4001,pp. 336–350.

[8] S. Evdokimov, B. Fabian, and S. Kunz, “Challenges forAccess Control in Knowledge Federations,” in InternationalConference on Knowledge Management and InformationSharing, 2009.

[9] S. Kunz, S. Evdokimov, B. Fabian, B. Stieger, and M. Strem-beck, “Role-Based Access Control for Information Feder-ations in the Industrial Service Sector,” in 18th EuropeanConference on Information Systems, 2010.

[10] M. Strembeck, “Scenario-Driven Role Engineering,” IEEESecurity and Privacy, vol. 8, pp. 28–35, 2010.

[11] T. Moses, “eXtensible Access Control MarkupLanguage (XACML) Version 2.0,” http://docs.oasis-open.org/xacml/2.0/access control-xacml-2.0-core-spec-os.pdf, 2005.

[12] M. Harrison, W. Ruzzo, and J. Ullman, “Protection in Oper-ating Systems,” Communications of the ACM, vol. 19, no. 8,pp. 461–471, 1976.

[13] R. Thomas and R. Sandhu, “Task-Based Authorization Con-trols (TBAC): A Family of Models for Active and Enterprise-oriented Authorization Management,” Database Security,vol. 11, pp. 166–181, 1998.

[14] D. Ferraiolo, J. Cugini, and D. Kuhn, “Role-Based AccessControl (RBAC): Features and Motivations,” in 11th AnnualComputer Security Application Conference, 1995, pp. 241–248.

[15] Sejong Oh and Seog Park, “Task-Role-Based Access ControlModel,” Information Systems, vol. 28, no. 6, pp. 533–562,2003.

[16] Y. Lu, L. Zhang, and J. Sun, “Task-Activity Based AccessControl for Process Collaboration Environments,” Computersin Industry, vol. 60, no. 6, pp. 403–415, 2009.

[17] D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli, Role-Based Access Control. Artech House, 2007.

[18] M. Petrovic, M. Grossniklaus, and M. Norrie, “Role-BasedModelling of Interactions in Database Applications,” inAdvanced Information Systems Engineering, ser. LNCS,E. Dubois and K. Pohl, Eds. Springer, 2006, vol. 4001,pp. 63–77.

[19] M. Strembeck and G. Neumann, “An Integrated Approachto Engineer and Enforce Context Constraints in RBAC En-vironments,” ACM Transactions on Information and SystemSecurity (TISSEC), vol. 7, no. 3, pp. 392–427, 2004.

[20] Q. He and A. Anton, “A Framework for Modeling PrivacyRequirements in Role Engineering,” in 9th InternationalWorkshop on Requirements Engineering: Foundations of Soft-ware Quality (REFSQ ’03), vol. 3. Citeseer, 2003, pp. 137–146.

[21] F. Massacci and N. Zannone, “A Model-Driven Approach forthe Specification and Analysis of Access Control Policies,”On the Move to Meaningful Internet Systems: OTM 2008,pp. 1087–1103, 2008.

[22] D. Basin, J. Doser, and T. Lodderstedt, “Model Driven Secu-rity: From UML Models to Access Control Infrastructures,”ACM Transactions on Software Engineering and Methodology(TOSEM), vol. 15, no. 1, p. 91, 2006.

[23] J. Mendling, M. Strembeck, G. Stermsek, and G. Neumann,“An Approach to Extract RBAC Models from BPEL4WS Pro-cesses,” in 13th IEEE International Workshops on EnablingTechnologies: Infrastructure for Collaborative Enterprises,2004. WET ICE 2004, 2004, pp. 81–86.

[24] C. Wolter, A. Schaad, and C. Meinel, “Deriving XACMLPolicies from Business Process Models,” in Web InformationSystems Engineering–WISE 2007 Workshops. Springer,2007, pp. 142–153.

[25] B. Hofreiter and C. Huemer, “A Model-Driven Top-DownApproach to Inter-Organizational Systems: From GlobalChoreography Models to Executable BPEL,” in Proceedingsof the 2008 10th IEEE Conference on E-Commerce Technol-ogy and the Fifth IEEE Conference on Enterprise Computing,E-Commerce and E-Services, 2008, pp. 136–145.

[26] “Aletheia Project Website,” http://www.aletheia-projekt.de/,2010.

[27] S. Kunz, F. Brecht, B. Fabian, M. Aleksy, and M. Wauer,“Aletheia – Improving Industrial Service-Lifecycle Manage-ment by Semantic Data Federations,” in IEEE InternationalConference on Advanced Information Networking and Appli-cations, 2010.

[28] T. Berners-Lee and R. Fielding and L. Masinter, “RFC3986: Uniform Resource Identifier (URI): Generic Syntax,”http://tools.ietf.org/html/rfc3986, 2005.

[29] Object Management Group (OMG), “Business ProcessModel and Notation (BPMN) Version 2.0 - Beta 2,”http://www.omg.org/spec/BPMN/2.0/Beta2/PDF/, June 2010.

[30] The Oryx Team, “Oryx: WebHome,” http://bpt.hpi.uni-potsdam.de/Oryx/WebHome, 2010.

[31] OpenID Foundation, “OpenID Foundation Website,”http://www.openid.net/, 2010.

[32] David Ferraiolo and Richard Kuhn, “Role-Based AccessControl,” in In 15th NIST-NCSC National Computer SecurityConference, 1992, pp. 554–563.

ACKNOWLEDGEMENTS

This research was funded by the German Federal Ministryof Education and Research under grant number 01IA08001Eas part of the Aletheia project. The responsibility for thispublication lies with the authors.