Deliverable Open Source software and documenta- tion ......13 Intalio UK INT Partner 14 Risaris IR...

SEVENTH FRAMEWORK PROGRAMMEChallenge 1Information and Communication Technologies

Document Type: Deliverable

Title: Open Source software and documenta-tion implementing the design

Work Package: WP3

Deliverable Nr: D3.2

Editor: Jutta Mülle, KARL

Dissemination: PU

Preparation Date: December 31, 2009

Version: rev. 10 (1.0)

Legal NoticeAll information included in this document is subject to change without notice. The Members of the TAS3 Consortium make no warrantyof any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for aparticular purpose. The Members of the TAS3 Consortium shall not be held liable for errors contained herein or direct, indirect, special,incidental or consequential damages in connection with the furnishing, performance, or use of this material.

Open Source software and documentation implementing the design, rev. 10 (1.0)December 31, 2009

The TAS3 Consortium

Beneficiary Name Country Short Role1 K.U.Leuven BE KUL Coordinator2 Synergetics nv/sa BE SYN Partner3 University of Kent UK KENT Partner4 University of Karlsruhe DE KARL Partner5 Technische Universiteit Eindhoven NL TUE Partner6 CNR/ISTI IT CNR Partner7 University of Koblenz-Landau DE UNIKOLD Partner8 Vrije Universiteit Brussel BE VUB Partner9 University of Zaragoza ES UNIZAR Partner10 University of Nottingham UK NOT Partner11 SAP Research DE SAP Project Mgr12 Eifel FR EIF Partner13 Intalio UK INT Partner14 Risaris IR RIS Partner15 Kenteq BE KETQ Partner16 Oracle UK ORACLE Partner17 Custodix BE CUS Partner18 Medisoft NL MEDI Partner19 Symlabs PT SYM Partner

Contributors

Name Organisation1 Jutta Mülle KARL2 Jens Müller KARL3 Thorsten Haberecht KARL

TAS3-D3p2-v1p0.pdf-v-rev. 10 (1.0) of 44

Software for secure business processes, rev. 10 (1.0) December 31, 2009

Contents

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 EXECUTIVE SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 READING GUIDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 T3-BP-ENGINE-ODE - APACHE ODE BUSINESS PROCESS EXECUTION EN-GINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 INTRODUCTION TO THE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.3 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4 Available Releases and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 INSTALLATION GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 Hardware and Software Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.2 Installation and Configuration Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.3 Running the Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 HOW TO USE THE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5 API AND LIBRARY INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 T3-BP-MGR - BUSINESS PROCESS MANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1 INTRODUCTION TO THE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.3 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14





4.3 ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 T3-BP-PIP-IR - POLICY INFORMATION POINT FOR ROLES IN PROCESS IN-STANCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


5.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1.3 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16









5.3.1 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.4 ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.4.1 Component Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.4.2 Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


5.5.1 API - Javadoc description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 T3-BP-PPM - PROCESS PERMISSION MANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.1 INTRODUCTION TO THE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.1.3 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23







6.3.1 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4 ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4.1 Component Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4.2 Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


6.5.1 API - Javadoc description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 T3-BP-SM - PROCESS SECURITY CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.1 INTRODUCTION TO THE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.1.3 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29









7.3.1 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.4 ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31


8 T3-PEP-RQ - POLICY ENFORCEMENT POINT FOR THE ODE BPEL ENGINEAS A SERVICE REQUESTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33


8.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.1.3 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33



8.2.1 Compiling the source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36





8.3.1 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.4 ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


9 LICENSE INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

10 CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

ANNEX A: CONFIGURING TOMCAT JNDI DATASOURCE SETTINGS . . . . . . . . . . . . . . . . . . 42



List of Figures

Figure 2.1: Overview of the business-process-specific security components . . . . . . . . . . . . . . . . . . . . . . 9

Figure 3.1: Ode – Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 5.1: T3-BP-PIP-IR – interacting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 5.2: soapUI screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 5.3: T3-BP-PIP-IR – component communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 5.4: T3-BP-PIP-IR – Database class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 5.5: T3-BP-PIP-IR – Database model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 6.1: T3-BP-PPM – interacting components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 6.2: T3-BP-PPM – component communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 6.3: T3-BP-PPM – Database class diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 6.4: T3-BP-PPM – Database model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 7.1: Classes of the BPMNSec package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 7.2: Hierarchical structure of BPMN process description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Figure 8.1: Conceptual sequence flow involving the T3-PEP-RQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 8.2: Example SOAP payload of a request to the T3-PEP-RQ, illustrating the XML structure . 35

Figure 8.3: Test of the PEP-RQ: Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Figure 8.4: Test of the PEP-RQ: Expected response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37



1 Executive SummaryIn TAS3, any communication is subject to specified policies. Compliance is checked for every request

and every reply, both at the service requester and at the service provider side.Business process management provides a flexible approach for defining and running applications in

service oriented architectures with web services as basic building blocks. A business process orchestratesweb service calls, human interactions via web service interfaces and reactions of external events providinga separate specification of the flow. The security aspect in business processes relates to policy enforcementpoints which will intercept any web service call to or from the business process and enforce any applicablepolicy. These policies are specific to business processes in that way that they can refer to properties ofthe process model or the process instance in question. Such properties may be the execution status ofthe process instance (such as activities waiting for execution, values of internal variables or the executionhistory), the security context of the process instance, the roles and resources assigned to the process, orthe description of the process model, e.g., its privacy policy.

Further on, activities in processes can explicitly cause modifications of their security context, e.g.,assign users to a process role. These modifications need to adhere to policies as well otherwise users couldillegally enhance their privileges. Therefore, we develop business-process-specific security components,which will both support the generic policy enforcement infrastructure by providing attributes necessaryto evaluate policies and evaluate and enforce the process-specific policies. Deliverable D3.1 describes theiterative conceptual design of those components.

This report describes the implementation of components described in Deliverable D3.1. The implemen-tation follows the iteration steps of the conceptual design with time shift. So the reported implementationmostly focus on the status of the conceptual design half a year before. But there also exist interrela-tionships between implementation and conceptual design, so that implementation influences partly theconceptual design and on the other hand the ongoing conceptual design and possible changes affect theimplementation task.

The current status of the implementation contains first versions of components of all categories of taskswhich we identified to establish security for business processes in the TAS3 context:

• Capturing and storing security-relevant information about instances of business processes.

• Runtime enforcement of security policies by inspecting incoming and outgoing messages.

• Management of configuration changes in other parts of the TAS3 infrastructure.

• Creation of security configuration based on process models.

1.1 Reading GuideThe software describes the components which are designed in Deliverable D3.1. Chapter 4 in D3.1

provides the theoretical background and Chapter 5 of D3.1 details about the implementation design. D3.1also contains a detailed description of he relationship with the TAS3 architecture described in D2.1. Ofparticular interest is chapter 4.1 and 5.1 of D3.1.

The described software components contribute to the integrated implementation of the first Nottinghamdemonstrator. The validation will be described in a next version of Deliverable D3.3.



2 OverviewIn TAS3, any communication is subject to specified policies. Compliance is checked for every request

and every reply, both at the service requester and at the service provider side. This model is genericand is not specific to business processes. Policy enforcement points will, accordingly, intercept any webservice call to or from the business process and enforce any applicable policy. Again, these policies arenot specific to business processes, except that they can refer to properties of the process model or theprocess instance in question. Such properties may be the execution status of the process instance (such asactivities waiting for execution, values of internal variables or the execution history), the security contextof the process instance, the roles and resources assigned to the process, or the description of the processmodel, e.g., its privacy policy.

On the other hand, activities in processes can explicitly cause modifications of their security context,e.g., assign users to a process role. These modifications need to adhere to policies as well otherwise userscould illegally enhance their privileges. The business-process-specific security components, as describedin the next section, will both support the generic policy enforcement infrastructure by providing attributesnecessary to evaluate policies and evaluate and enforce the process-specific policies.

We can broadly categorise the tasks of the components needed to establish security for business pro-cesses in the TAS3 context into the following categories:

• Capturing and storing security-relevant information about instances of business processes.

• Runtime enforcement of security policies by inspecting incoming and outgoing messages.

• Management of configuration changes in other parts of the TAS3 infrastructure.

• Creation of security configuration based on process models.

Accordingly, we can group the components developed by WP3 as follows:

• Components managing instance-specific security information:

– T3-BP-PIP-IA – Policy information point for instance attributes (following in the next release):Determines and stores attributes of running process instances.

– T3-BP-PIP-INTERVAL – Policy information point for intervals (following in the next release):Determines which sections of a running process instance are currently active.

– T3-BP-PIP-IR – Policy information point for instance roles: Manages the instance-specificassignment of users and service endpoints to the roles of a process.

• Components enforcing security policies on messages exchanged:

– T3-PEP-RQ – Service-requester policy enforcement point for the BPEL execution engine:Acts as a policy enforcement point for outgoing requests made by a business process.

– T3-BP-MGR – Business process manager: Manages user interactions and ensures human tasksare only handled by properly authenticated (by single-sign-on) and authorized users.

• Components managing the security configuration in the infrastructure:

– T3-BP-PPM – Process permission manager: Manages permissions assigned to the businessprocess and handles permission assignment according to predefined permission assignmentrules.

– T3-BP-DR – Process role delegation service (following in the next release): Handles delega-tion of assigned instance-roles.

• Components Creating Security Configuration:



– T3-BP-SM – Process security configuration: Extracts security properties from graphical pro-cess models.

Figure 2.1 gives an overview of the components and their relations. The edges stand for possiblecommunication between components.

T3-BP-PIP-INTERVAL

Process Modeling Tool(Designer)

T3-BP-SM

User / Webservice

Process, resource and security model (policies)

generates

Current role-user assignments

Process roles

Request currently enabled interval

Resource access attempt

Process EngineOde

Request current instanceexecution state to determine

currently enabled interval

Process interval model

generates

Interval modelProcess model incl. roles

BusinessProcess Manager

T3-BP-MGR

T3-BP-PIP-IR

RoleDelegation Service

T3-BP-DR

PDP

PEP

Request resourceaccess permission

Process

Intended role-userassignment

Execution of tasks

Request current role-user assignments todetermine appropriate tasks for users.

Resource access permissions on the process model

ProcessPermission Manager

T3-BP-PPM

Resource access rules

PEP

Policies

Request permission for intendedrole-user assignment

T3-BP-PIP-IA

Update credentials

Delegation of roles

Figure 2.1: Overview of the business-process-specific security components

• Process models are developed using a process modelling tool. Security aspects are extracted fromthese models using the Security Configuration Tool (T3-BP-SM).

• Resource access roles are handed over to the Process Permission Manager (T3-BP-PPM), informa-tion on process roles to the Instance-role PIP (T3-BP-PIP-IR), the process model to the business pro-cess engine (T3-BP-ENGINE) and the interval model to the Interval Monitor (T3-BP-INTERVAL).

• The business process engine makes a request to the PIP-IR in order to register an intended instance-specific role-user assignment.

• The PIP-IR forwards the request to the PDP.

• For authorized role-user assignments the Process Permission Manager matches the assignmentswith the resource access rules of the process model. For every match it causes access to be grantedto the user in question.

• Incoming and outgoing (payload) messages to and from the process pass through an policy enforce-ment point (PEP), respectively. The PEP examines the messages and asks the PDP, via the AI-PEP,



whether the message is allowed. This authorization contains necessary context, as determined bythe PEP. If the messages are allowed, they are passed on to the process or its communication partner.

• The PDP may apply process-specific policies (among others). In some cases, for example usingsticky policies, the PEP passes the applicable policies to the PDP.

• If policies refer to process-specific attributes, the PDP requests and receives these attributes fromthe PIP-IA.

• When permissions constrained by an interval are used, the PDP contacts the Interval Monitor todetermine whether the interval is currently active.

• The Interval Monitor requests the state of running process instances from the process engine inorder to determine the intervals currently active.

• Explicit requests from the business process to the PIP-IR or the PPM in order to assign users toprocess roles or to register permissions delegated to the process, respectively, must contain contextinformation about the process instance making the request.

• A user’s dashboard can request delegation of process-roles held by that user.

• Before it records the assignment of a process role, the PIP-IR requests the PDP to authorize theassignment.

• The PPM monitors changes of the process-role assignments recorded in the PIP-IR and of the dele-gated permissions recorded in the PPM.

• When a policy refers to attributes of a process-instance, the PDP requests the attribute value fromthe PIP-IA.

• The process can call the PIP-IA to explicitly set attributes. We also see the possibility that theinstance attribute is bound to a BPEL variable. In that case, the PIP-IA calls the BPEL executionengine to determine the current value and answer the request from the PDP.



3 T3-BP-ENGINE-ODE - Apache ODE Business Pro-cess Execution Engine

3.1 Introduction to the Software

3.1.1 Purpose

Business processes are executed on a process engine. The engine coordinates the execution of the tasks,the handling of events and communication for all running process instances.

3.1.2 Scope

Apache Ode [1] is an open source (see 9) workflow engine with support for BPEL4WS 1.1 [2] andWS-BPEL 2.0 [3]. Communication of services can be performed via http transport of SOAP messages.Apache Ode is also used as bpel engine in the Intalio|Works BPMS, an Open Source Business ProcessPlatform1.

3.1.3 Functionality

Apache Ode controls the instantiation and execution of BPEL4WS 1.1 and WS-BPEL 2.0 processmodels. Execution is completely standard-compliant.

3.1.4 Available Releases and Components

Three distributions of Apache Ode are available: A WAR (Web Archive) distribution, a JBI (JavaBusiness Integration) distribution and a source code package.

The current stable release is 1.3.3, but there is also a second beta of version 2.0 available.

3.2 Installation Guidelines

3.2.1 Hardware and Software Prerequisites

Apache Ode requires a usual workstation with a JDK 5.0 (Java Developer Kit) installation on it. Thecore components of Ode are designed for embedment on different software environments. The ready-to-use distributions available on the web site can be installed in a Java servlet or a JBI container.

3.2.2 Installation and Configuration Instructions

We built Ode as described on the project website2 and deployed it in a Tomcat 6 application serverrunning on a Ubuntu Linux 9.10 operation system.

It is also sufficient to download the WAR distribution and deploy it directly into a Tomcat server.

3.2.3 Running the Tests

Ode is software released by the Apache Software Foundation. We have not yet made any modificationsto its source code. Accordingly, the tests contained in the source distribution are still valid. They areautomatically applied when executing the build process.

1http://www.intalioworks.com/products/bpm/2http://ode.apache.org/building-ode.html



3.3 How to Use the Software

3.3.1 Tutorial

Ode is started automatically by the servlet container (Apache Tomcat) on deployment. In order toexecute a BPEL process, that process must be deployed.

Each deployment is a directory with all relevant deployment artifacts. At the minimum it will containthe deployment descriptor, one or more process definitions (BPEL or .cbp), WSDL and XSDs (excludingthose compiled into the .cbp). It may also contain other files, such as SVGs or XSLs. The deploymentdescriptor is a file named deploy.xml (see the next paragraph for its description).

During deployment, the process engine loads all documents from the deployment descriptor. Loadingdocuments allow it to reference processes, service and schema definitions using fully qualified names, andimport based on name spaces instead of locations.

To deploy in Ode, just copy the whole directory containing your artifacts (the directory itself, not onlyits content) in the path

Further information is available athttp://ode.apache.org/user-guide.html#UserGuide-DeployingaProcessinOde.

3.4 ArchitectureApache Ode consists of four main components: A BPEL compiler, which translates the BPEL process

definition into a representation form executable by the Ode BPEL runtime engine. The BPEL runtimeengine handles the instantiation and execution of the deployed processes. It also handles the routing ofincoming messages. States of process instances are stored in a persistent manner. The Ode Data AccessObjects (DAOs) act as a mediation component between the process engine and the data store and provideinterfaces for accessing persistently stored instance data and messages. The Ode Integration Layers (ILs)embed the runtime in an execution environment, for example Axis2 or a JBI environment. It providescommunication channels for the runtime.

Figure 3.1: Ode – Architecture

Figure 3.1 gives a high level overview of the architecture. The execution of the business processes



itself takes place within the Java Concurrent Objects (Jacob) framework, which provides an application-level concurrency mechanism and mechanisms for interrupting process instance execution and persistenthandling of execution states.

3.5 API and Library InformationApache Ode has a BPEL Management API which is described in detail at

http://ode.apache.org/bpel-management-api-specification.html.



4 T3-BP-MGR - Business Process Manager


4.1.1 Purpose

In common workflow management systems tasks ready for execution are offered to all users holdingappropriate organisational roles. Within the TAS3 architecture we want to enhance this functionalitytowards an assignment of tasks only to users, which are holding instance specific roles.

4.1.2 Scope

The Business Process Manager (MGR) ensures that only authenticated and authorised individuals canaccess process instances. Authentication is accomplished by integrating single sign-on into the IntalioTempo [4] component, which provides a graphical user interface for assigned tasks in business processes.Additionally, it determines the users allowed to access tasks (based on the user-role-assignment stored bythe PIP-IR and possibly on the decision of a PDP).

4.1.3 Functionality

The Business Process Manager provides the following functionality:

• User authentication via single sign-on integration.

• Instance specific task assignment to authorized users.

• Provision of a graphical user interface for task selection and delegation.


The T3-BP-MGR distribution in the TAS3 Pool includes the following components:

• The Java source code of the Business Process Manager.

• The Manager component in form of a servlet (MGR.war), ready for deployment on an ApacheTomcat servlet container.

• The Javadoc description of the component.



The T3-BP-MGR component doesn’t require any special hardware resources. The workstation must beable to run an Apache Tomcat 6 application server.

The MGR is written in Java. The component is available as a servlet (MGR.war). It requires a servletcontainer1 to be deployed on.


Installation and Configuration Instructions will be available in the further course of the software devel-opment process.

1We tested it on a Tomcat 6 application server only.



4.3 ArchitectureThe open source Intalio Tempo framework is the main component of the T3-BP-MGR. Tempo is a

set of runtime components supporting human workflow interactions we take as a basis for developingextensions.

The major architectural components of Tempo are:

• The XForms Manager (XFM) uses XForm definitions to create a GUI for the performance of work-flow tasks by human users.

• The User Interface Framework (UIFW) provides login functionality and a task list.

• The Task Management Process (TMP) handles the lifecycle of tasks.

• The Task Management Service (TMS) provides an interface to change and retrieve the state of tasksand persists tasks in a database.

• The Security Framework (SFW) provides authorization and authentication. The basic implemen-tation in the open-source edition of Tempo compares credentials (username and password) with asimple XML file, and provides authorisation based on roles provided in that file.

• The Task Attachment Service (TAS) persists ad-hoc attachment linked to tasks.

• The Form Dispatcher Service (FDS) is a simple wrapper to translate messages between the applica-tion business process and TMP.

• The Workflow Deployment Service (WDS) allows for remote deployment of task descriptions andXForm definitions.

• The Task Object Model (TOM) is a data-access layer for task definitions and instances.

Relevant components for us are UIFW and SFW. Enhancements to these components will include sup-port for role delegations, instance-specific role assignments and single-signon.



5 T3-BP-PIP-IR - Policy Information Point for Rolesin Process Instances


5.1.1 Purpose

Tasks in business processes are assigned to roles. Roles act as a layer of indirection between the tasksand actual actors (humans or web-services).

This component keeps track of the humans and services assigned to the roles in a business-processinstance. It controls the assignment by relaying assignment requests to a PDP before actually performingthem.

5.1.2 Scope

The T3-BP-PIP-IR component handles the assignment of actors to roles in business-process instances.It stores role definitions (originating from the modelling tool) for each business-process model as config-uration.

Actors are identified by persistent SAML NameIDs (for humans) and endpoint references (for web-services). Discovery of suitable actors is not part of the functionality of this component. Currently, anexplicit request (by the business process) is necessary to execute the assignment of an actor to a role. Weare planning to extend this by a mechanism which calls a discovery component if needed.

The T3-BP-PIP-IR component keeps part of the security-relevant state information of business-processinstances. It is not involved in the execution of business processes or in the presentation of the userinterface.

5.1.3 Functionality

The T3-BP-PIP-IR is running as a web service and provides its functionality via a web service interface(SOAP over HTTP). It keeps its state in an embedded database.

When deploying a process model to the process engine, the PIP-IR gets the role definitions of theprocess model. When an instance of a business process is being created the PIP-IR receives a messagefrom the process engine with an intended role-user assignment. It calls the PDP to check if this assignmentis permitted according to policies of the process model. If this is the case the PIP-IR stores the assignmentand forwards this information to the T3-BP-PPM component.

Figure 5.1 shows the components the PIP-IR is interacting with.


The distribution of the T3-BP-PIP-IR component, which is available from the TAS3 Pool repositorycontains the following elements:

• The Java source code of the component.

• The T3-BP-PIP-IR component in the form of a web service file (PIPIR.aar), ready for deploymenton an Axis2 container.

• A ZIP file (database.zip) containing an empty Apache Derby1 database, which is required by theT3-BP-PIP-IR component.

• A derby.jar file containing a Java library necessary for accessing Derby databases.

• A folder with the Javadoc description of the component.1http://db.apache.org/derby/




T3-BP-SM


generates


Process roles

Data storage:

Process model specific:- Roles

Process instance specific:- Current role-user assignments

Process engine(Ode)

Process model incl. roles


T3-BP-MGR

T3-BP-PIP-IR

PDP

ProcessIntended role-user assignment

Request current role-user assignments todetermine appropriate tasks for active users.

ProcessPermission Manager

T3-BP-PPM

Policies


Figure 5.1: T3-BP-PIP-IR – interacting components



The T3-BP-PIP-IR component can operate on an ususal workstation. No special hardware requirementshave to be fulfilled.

On the software side a servlet container is required including an Axis2 running in it. In the following weassume a Linux operating system with an Apache Tomcat 6 installation and an Axis2 1.5 servlet runningon it. We have not tested the PIP-IR with other configurations sufficiently.

In default configuration the component expects an embedded Derby database named PIP-IR to be avail-able as a global resource of the Tomcat installation. This database is being accessed via JNDI (JavaNaming and Directory Interface).


For installing the T3-BP-PIP-IR webservice the following tasks have to be performed:

1. Copy the PIPIR.aar file to the services folder of your Axis2 container.2 The webservice will bedeployed automatically if the Tomcat server is running or when it is started for the next time.

2. The database.zip file has to be unzipped and copied to the folder, where the global databases of yourTomcat installation are stored (usually this is the databases folder within your Tomcat installationfolder).

2Usually the full path is webapps/axis2/WEB-INF/services within your Tomcat installation folder.



3. Configure the database as a global accessible JNDI resource. This is done via the Tomcat JNDIdata source configuration in conf/server.xml. Step by step configuration instructions for the JNDIconfiguration are provided in Annex 10.

4. Copy the derby.jar file into the lib folder of your Tomcat installation.


The T3-BP-PIP-IR component awaits inputs as SOAP messages over HTTP. It generates outputs asSOAP messages as well. All persistent data is stored in an embedded Derby database, named PIP-IR bydefault. Status and error notifications are written to the local Tomcat console.

For manual testing purposes we use the soapUI3 web services testing tool (see screenshot on Figure5.2). This tool offers the possibility to import WSDL documents which are locally available or acces-sible by an URL. It automatically generates SOAP message templates for all interfaces specified in theWSDL document. The user enters method argument values, sends the message to the service and gets animmediate reply message.

Figure 5.2: soapUI screenshot

When testing the functionality of the PIP-IR state-related issues are fundamentally important. The PIP-IR stores the current state of role-user assignments in a persistent database. The state of the database has tobe considered when testing the service. Before starting to run a set of test cases we first delete all databaseentries and restart the tomcat server.

Within a test case set, at first methods with write access to the database are called, then service interfaceswith read and modification access.

For automated testing we plan to use a unit test framework.

3http://www.soapui.org/




5.3.1 Tutorial

The PIP-IR web service (PIPIR.aar) can be deployed on an Axis2 container as described above. Theuser can access the component via web service calls or inspect the interfaces and the functionality of theservice using the soapUI web services testing tool.

5.4 Architecture

5.4.1 Component Interactions

Figure 5.3 shows a formalised illustration of the communication taking place between the components.

Process Modeling Tool

T3-BP-PIP-IR

T3-BP-PPM PDP

Process engine

UI-Framew./Task manager

1: createModel(int modelID, String roleID, String roleType) :boolean

1.1: createRole(int modelID, String roleID, String roleType) :boolean

1.2: createProcessInstance(int instanceID, int modelID) :boolean

1.3: assignHumanRole(int instanceID, String roleID, String idToken) :boolean1.4: assignServiceRole(int instanceID, String roleID, String serviceEndpointURL) :boolean

1.5: authorizeUserRoleAssignment(int modelID, int instanceID, String roleID, String userID) :boolean

1.6: setRoleUserAssignment(int modelID, String roleID, int instanceID, String userID, String userType) :boolean

1.7: getAssignedHuman(int instanceID, String roleID) :String

1.8: getAssignedService(int instanceID, String roleID) :String

Figure 5.3: T3-BP-PIP-IR – component communication

The business process modelling tool handles the role definitions of the process model over to the PIP-IRcomponent (1). When creating an instance of a model, the process engine notifies the PIP-IR (1.1) andrequests the assignment of process roles to humans or to web services (1.2 and 1.3). These assignmentsneed authorisation by a PDP. The PDP checks if the intended assignments comply with the policies of thebusiness process (1.4). If this is the case the assignment becomes final and the T3-BP-PPM gets notifiedon that (1.5). During the progression of the process instance the task manager has to identify the tasksevery participating user has to perform. For that, on each upcoming task the task manager requests theuser presently assigned to the process role to which the task is attached (1.6 and 1.7).

5.4.2 Data Management

5.4.2.1 Database

We use an embedded Derby database for persistently storing the role-user assignments. The PIP-IRweb service accesses the database via a JNDI interface.

5.4.2.2 Database Model

The database stores references to all deployed process models, all roles defined therein and all activeinstances of these models. For all process instances and all involved process roles the database storesthe assignments of human users or services to these roles. It may happen that the assigned user changesduring the process flow, so the current assignment is marked distinguishable from out-dated assignments.Nevertheless all assignments that ever have occured, can be retraced. This is a significant security issue.Figure 5.4 shows the UML class structure of the stored data.

From the class structure we derived the following relational data model:



Model

- modelID: int

Instance

- instanceID: int

Role

- roleID: int- roleName: char- roleType: char

User

- userID: int- userName: char- userType: char

has associated

user

model of the given role = model of the given instance

1..*

0..*

1..*

1..*

0..*

0..*1

Figure 5.4: T3-BP-PIP-IR – Database class diagram

Model (modelID)Model_Role (modelID, roleID)Role (roleID, roleName, roleType)Instance (instanceID, modelID)User (userID, userName, userType)Instance_Role_User (modelID, roleID, instanceID, userID, isCurrentAssignment)

Figure 5.5 depicts the detailed schema of the database.



model

«column»*PK modelID: INTEGER

«PK»+ PK_model(INTEGER)

instance

«column»*PK instanceID: INTEGER*FK modelID: INTEGER

«FK»+ FK_instance_model(INTEGER)

«PK»+ PK_instance(INTEGER)

role

«column»*PK roleID: INTEGER* roleName: VARCHAR(100)* roleType: VARCHAR(100)

«PK»+ PK_roleID(INTEGER)

user

«column»*PK userID: INTEGER* userName: VARCHAR(100)* userType: VARCHAR(10)

«PK»+ PK_user(INTEGER)

model_role

«column»*pfK modelID: INTEGER*pfK roleID: INTEGER

«FK»+ FK_model_role_model(INTEGER)+ FK_model_role_role(INTEGER)

«PK»+ PK_model_role(INTEGER, INTEGER)

instance_role_user

«column»*FK modelID: INTEGER*pfK roleID: INTEGER*pfK instanceID: INTEGER*pfK userID: INTEGER* isCurrentAssignment: BOOL

«FK»+ FK_instance_role_user_instance(INTEGER)+ FK_instance_role_user_model(INTEGER)+ FK_instance_role_user_role(INTEGER)+ FK_instance_role_user_user(INTEGER)

«PK»+ PK_instance_role_user(INTEGER, INTEGER, INTEGER)

constraint:model of the given role = model of the given instance

+FK_instance_role_user_role

(roleID = roleID)«FK»

+PK_roleID

+FK_instance_role_user_user

(userID = userID)«FK»

+PK_user

+FK_model_role_model

(modelID = modelID)«FK»

+PK_model

+FK_instance_role_user_instance

(instanceID = instanceID)«FK»

+PK_instance

+FK_model_role_role

(roleID = roleID)«FK»

+PK_roleID

+FK_instance_model(modelID = modelID)«FK»

+PK_model

+FK_instance_role_user_model

(modelID = modelID)«FK»

+PK_model

Figure 5.5: T3-BP-PIP-IR – Database model



5.5 API and Library Information

5.5.1 API - Javadoc description

For web services the API of a component is defined by a WSDL file. The WSDL document for theT3-BP-PIP-IR is contained in the component package in the Pool.

Additionally, a part of the Javadoc description of the PIP-IR is listed below. Although you cannot usethis form of documentation for direct access, we think it is quite easier accessible to the reader than aWSDL document and it might be helpful when working with client stubs to access the PIP-IR web ser-vice. The full Javadoc description is provided as part of the T3-BP-PIP-IR package in the TAS3 Pool.

Method Summary

boolean assignHumanRole(int instanceID, java.lang.String roleID,java.lang.String idToken)

Assigns the given human to the given role in the given process instance.boolean assignServiceRole(int instanceID, java.lang.String roleID,java.lang.String serviceEndpointURL)

Assigns the given service endpoint URL to the given role in the given process instance.void createModel(int modelID, String roleID, String roleType)

Creates a process model including one role in the PIP-IR database.boolean createRole(int modelID, String roleID, String roleType)

Creates an additional role for a process model in the PIP-IR database.void createProcessInstance(int instanceID, int modelID)

Creates the instance role storage for a new business process instance.java.lang.String getAssignedHuman(int instanceID, java.lang.String roleID)

Gets the user currently assigned to a human role.java.lang.String getAssignedService(int instanceID, java.lang.String roleID)

Gets the service currently assigned to a service role.java.lang.String[] getHumanRolesForProcessModel(int modelID)

Gets all human roles of a process model.java.lang.String[] getServiceRolesForProcessModel(int modelID)

Gets all service roles of a process model.int getModelForInstance(int instanceID)

Get the ID of the process model for an instance ID.



6 T3-BP-PPM - Process Permission Manager


6.1.1 Purpose

Within the TAS3 framework it is undesirable that users involved in a process have access to all processresources at any time. The Process Permission Manager ensures that resource access is only granted tousers currently holding a role within a process instance. Further, the access permissions are restricted tospecific resources of the process instance the user is involved in.

6.1.2 Scope

The Permission Manager keeps track of permissions assigned to process instances. These permissionswill apply to specific resources (e.g., data sources) involved in the process and may change during processexecution. E.g., the PPM controls delegation of permissions to users holding roles in the process instance,according to rules defined for the each process instance. It will revoke the permissions if the conditions ofa rule no longer is valid, e.g. if a person no longer holds a process role.

6.1.3 Functionality

The T3-BP-PPM is implemented as a web service. It provides its functionality via a web serviceinterface (SOAP over HTTP) and stores its state in an embedded database.

The Process Permission Manager has interfaces for two kinds of data input: From the modelling tool itgets resource access permission rules extracted from the process policies. At runtime of a process instanceit gets the current role-user assignments in addition. The PPM matches these data sets and updates theaccordant credentials for user access permissions on process resources. Figure 6.1 shows the integrationof the PPM into the business process part of the TAS3 architecture.


The T3-BP-PPM distribution in the TAS3 Pool includes the following components:

• The Java sourcecode of the Process Permission Manager.

• The PPM in the form of a webservice file (PPM.aar), ready for deployment on an Axis2 container.

• A ZIP file with an empty Derby database. The database is required by the T3-BP-PPM component.

• A derby.jar file containing a Java library necessary for accessing the Derby database.

• The Javadoc description of the component.



The T3-BP-PPM component can operate on an ususal workstation. No special hardware resources areneeded.

The PPM is written in Java. The component is available as a webservice-package (PPM.aar) and re-quires a servlet container1 and an Axis2 installation the webservice can be deployed on.

The component expects an embedded Derby database to be available as a global resource of the Tomcatinstallation. As default the database is expected to be named PPM. The component accesses the databasevia the JNDI interface.

1We tested it on a Tomcat 6 application server only.




T3-BP-SM


generates


Process roles

Process engine(Ode)

Process model incl. roles


T3-BP-MGRT3-BP-PIP-IR

PDP

ProcessIntended role-user assignment

T3-BP-PPM

Policies


Resource access rules

RoleDelegation Service

T3-BP-DR

User / Webservice

PEP

Resource access attempt

Request Access Permission

Delegation of roles

Update credentials

Execution of tasks

Figure 6.1: T3-BP-PPM – interacting components


Four steps have to be performed for installing the T3-BP-PPM webservice component:

1. Copy the PPM.aar file to the services folder of your Axis2 installation. At the next start of theservlet container, the PPM service will be deployed automatically.

2. Unzip the database.zip file and copy the contained folder to the databases folder of your Tomcat 6installation or to another appropriate folder where the global databases of your Tomcat server arestored.

3. The database resource must be set accessible for the PPM component by configuring the TomcatJNDI datasource settings. A step by step configuration instruction is provided in Annex 10.

4. Copy the derby.jar library to the lib folder of your Tomcat installation directory.


The T3-BP-PPM component awaits inputs as SOAP messages over HTTP. It generates outputs as SOAPmessages as well. All persistent data is stored in an embedded Derby database, ususally named PPM.Status and error notifications are given as output to the local Tomcat console.

For manual testing purposes we use the soapUI2 web services testing tool. We already described theusage of the tool in section 5.2.3.

2http://www.soapui.org/




6.3.1 Tutorial

The PPM webservice can be installed as described above. The interfaces and the functionality of theserver can be inspected using the soapUI web services testing tool.

6.4 Architecture

6.4.1 Component Interactions

Figure 6.2 shows the communication taking place between the Process Permission Manager and otherinvolved components.

T3-BP-PPM

Process Modeling Tool

T3-BP-PIP-IR

PDP

1: setResourceAccessPermissionRule(int modelID, int roleID, String resourceID, String accessPermission) :boolean

1.1: setRoleUserAssignment(int modelID, int roleID, int instanceID, String userID, String userType) :boolean

1.2: updateRoleUserAssignment(int modelID, int roleID, int instanceID, String userID, String userType) :boolean

1.3: updateCredentials() :boolean

1.4: revokeRoleUserAssignment(int modelID, int roleID, int instanceID, String userID, String userType) :boolean

Figure 6.2: T3-BP-PPM – component communication

The PPM gets the resource access rules from the process modelling tool, where they have been definedbefore (1). The current role-user assignments are handed over from the PIP-IR. This happens at runtime,when an new assignment is made or an existing one is updated (1.1 and 1.2). For incoming assignmentsthe PPM performs a lookup in the rules table trying to find matching rules. For every match credentialsof the PDP are updated (1.3). The PIP-IR is also capable of initiating revokations of access permissions.Revokations take place when role-user assignments change or process instances are ended. Then thePIP-IR passes the information, that a role-user assignment is no longer valid, on to the PPM (1.4).

6.4.2 Data Management

6.4.2.1 Database

We use an embedded Derby database for persistent storage of the role-user assignments. The PPMwebservice accesses the database via the JNDI interface.

6.4.2.2 Database Model

Figure 6.3 shows the UML class structure of the data we need to store.



ResourceAccessPermissionToken

- tokenID: int- modeID: int- roleID: int- instanceID: int- userID: char- resourceID: char- accessPermissionType: char

RoleUserAssignment

- modeID: int- roleID: int- instanceID: int- userID: char- userType: char

ResourceAccessPermissionRule

- modelID: int- roleID: int- resourceID: char- accessPermissionType: char

dependent on a matching rule/assignment-tupel

0..1

0..10..1

Figure 6.3: T3-BP-PPM – Database class diagram

From the class structure we deduced the data model mentioned below:

ResourceAccessPermissionRule (modelID, roleID, resourceID, accessPermissionType)RoleUserAssignment (modelID, roleID, instanceID, userID, userType)ResourceAccessPermissionToken (tokenID, modelID, roleID, instanceID, userID, resourceID, accessPer-missionType)

The database stores the incoming resource access permission rules and the role-user assignments. Forevery matching pair a resource access token is generated which is also stored.

Figure 6.4 depicts the detailled data structure of our database.



ResourceAccessPermissionToken

«column»*PK tokenID: INTEGER*FK modelID: INTEGER*FK roleID: INTEGER*FK instanceID: INTEGER*FK userID: VARCHAR(255)*FK resourceID: VARCHAR(255)* accessPermissionType: VARCHAR(10)

«FK»+ FK_ResourceAccessPermissionToken_resourceAccessPermissionRule(INTEGER, INTEGER, VARCHAR)+ FK_ResourceAccessPermissionToken_roleUserAssignment(INTEGER, INTEGER, VARCHAR)

«PK»+ PK_ResourceAccessPermissionToken(INTEGER)

resourceAccessPermissionRule

«column»*PK modelID: INTEGER*PK roleID: INTEGER*PK resourceID: VARCHAR(255)* accessPermissionType: VARCHAR(10)

«PK»+ PK_resourceAccessPermissionRule(INTEGER, INTEGER, VARCHAR)

roleUserAssignment

«column»* modelID: INTEGER*PK roleID: INTEGER*PK instanceID: INTEGER*PK userID: VARCHAR(255)* userType: CHAR(10)

«PK»+ PK_roleUserAssignment(INTEGER, INTEGER, VARCHAR)

+FK_ResourceAccessPermissionToken_roleUserAssign...

(roleID = roleIDinstanceID = instanceIDuserID = userID)

«FK»

+PK_roleUserAssignment

+FK_ResourceAccessPermissionToken_resourceAccess...

(modelID = modelIDroleID = roleIDresourceID = resourceID)

«FK»

+PK_resourceAccessPermissionRule

Figure 6.4: T3-BP-PPM – Database model



6.5 API and Library Information

6.5.1 API - Javadoc description

boolean setResourceAccessPermissionRule(int modelID, java.lang.String roleID,java.lang.String resourceID, java.lang.String accessPermission)

Hands a resource access permission rule over to the PPM.boolean setRoleUserAssignment(int modelID, java.lang.String roleID, int instanceID,java.lang.String userID, java.lang.String userType)

Hands a role-user assignment over to the PPM.boolean updateRoleUserAssignment(int modelID, java.lang.String roleID, int instanceID,java.lang.String userID, java.lang.String userType)

Hands an updated role-user assignment over to the PPM.boolean revokeRoleUserAssignment(int modelID, java.lang.String roleID, int instanceID,java.lang.String userID, java.lang.String userType)

Revokes a role-user assignment from the PPM.



7 T3-BP-SM - Process Security Configuration


7.1.1 Purpose

The process security configuration component will allow stakeholders on the application level, e.g.business analysts and security engineers, to design security properties related to applications which arespecified as business processes in parallel to the business process modeling. These security properties of abusiness process then will be transformed to security rules, mechanisms and properties on the enforcementlevel working during business process execution. The current version of the component focus on handlingsecurity annotations of the BPMN model of the business process.

7.1.2 Scope

The current version contains a component that provides access to the output of the graphical BPMNmodelling tool, namely the standards-based Eclipse STP BPMN modeler. This BPMN modeler is alsoused in the Intalio|Works BPMS, an Open Source Business Process Platform1 and was originally devel-oped by Intalio.

7.1.3 Functionality

The current version of the component provides access to the output of the graphical BPMN modellingtool, namely the standards-based Eclipse STP BPMN modeler. The component collects the security anno-tations of a process BPMN diagram and relates each annotation to the related BPMN element. This set ofsecurity annotations is the basis for transforming the security properties to the security enforcement levelduring the business process execution, which will be part of the next iteration of the implementation. Thecomponent already uses the designed categories of business process security annotations and generatesfor each annotation a call to a specific transformation class with required parameters.

The module provides the following classes:

• ResourceLoad: reads a BPMN business process model, which is output of the graphical BPMNmodeling tool of Intalio and provides access information to the registered resource element of theprocess mode.

• DiagramHandling: offers functions to read and traverse the graphical description of the BPMNmodel which is provided in a graph structure in the BPMN modeler output modeler.bpmn-diagram.It allows to extract additional relevant information of the security annotations and their context, e.g.related BPMN element.

• RoleManagement: reads roles defined as descriptors of human workflow pools from the BPMNgraphical diagram representation and delivers the list of roles.

• SecurityAnnotation: extracts the security annotations and generates calls to the transformations foreach of the developed categories of security annotations, e.g. binding of duty in a group of tasksor authorization policies for web service calls or offering of trust feedback. The realisation of thetransformation methods is subject to next iteration of the implementation.

Figure 7.1 depicts the interfaces of the classes.The XML schema (BPMN.xsd) resulting from the graphical modelling step shows the business process

in a graph structure, see 7.2. With help of the Eclipse Modeling Framework (EMF) we generated theorg.eclipse.stp.bpmn package. The EMF framework supports the handling of this models and transfor-mations between three different representation forms, i.e. UML BPMN diagram, Java interfaces and the

1http://www.intalioworks.com/products/bpm/



Figure 7.1: Classes of the BPMNSec package

XML schema. With that using one of the models, in our case the XML schema, we are able to generateJava classes in order to generate an instance of the model which is queryable and updatable. This is usedfor the transformation of the security annotations on process model level to the security enforcement andbusiness process execution level.


The first release that is available contains the component that provides access to the output of thegraphical BPMN modelling tool, namely the standards-based Eclipse STP BPMN modeler and collectsthe security annotations of a process BPMN diagram together with the related BPMN element.

The distribution of the T3-BP-SM component, which is available from the TAS3 Pool repository con-tains the following elements:

• The Java sourcecode of the component.

• A number of libraries (JAR files) needed to build and run the component.

• The T3-BP-SM component in the form of a JAR file.

• Documentation in JavaDoc format.

7.2 Installation GuidelinesThe Eclipse project contains all necessary libraries and has a properly configured build path

src/eu/tas3/kit/SM.java. If compiling by hand, the build path must include all JAR files in /lib.


The software has no specific hardware requirements. The current implementation uses Java SE 1.6.0and Eclipse SDK 3.5.0.



Figure 7.2: Hierarchical structure of BPMN process description.


The executable JAR file can be used directly on the Eclipse platform. Another possibility is to start thecomponent from the command line with:java -jar SecConfComponent.jar modeler.bpmn


For test in the software component there is an example BPMN process containing a set of typical se-curity annotations in the file /resource2/modeler.bpmn which will produce the list of the detected securityannotations and the related BPMN elements. For testing it is possible to use the start of the component inthe command line.


7.3.1 Tutorial

The component belongs to the business process modelling phase and handles static business processmodels resulting from a graphical BPMN Modelling tool. The present version of the component is still astand-alone application. Input is an annotated BPMN description, output the list of security annotations.In the next version we will provide the binding with the security enforcement framework and the dynamicbusiness process management system.

7.4 ArchitectureFor the embedding of the BP-SM into the overall architecture, see the description in Chapter 2.



7.5 API and Library InformationImported libraries are org.eclipse.stp.bpmn, org.eclipse.emf.*, org.eclipse.emf.ecore.*, org.eclipse.emf.ecore.xmi.*,

org.eclipse.gmf.runtime.notation.



8 T3-PEP-RQ - Policy Enforcement Point for the OdeBPEL Engine as a Service Requester


8.1.1 Purpose

The service requester PEP enforces applicable policies for outgoing requests. As the BPEL engine andthe BPEL processes running on it act as service requesters, i.e., make outgoing requests, as well, we needa service requester PEP for business processes.

Additionally, the T3-PEP-RQ for BPEL processes performs logging to the audit bus and looks up end-points to be used in service calls.

8.1.2 Scope

The T3-PEP-RQ is an external PEP component for the BPEL engine. It is not yet integrated into theengine (e.g., as a Axis2 module acting as a filter step in the stack). Adapting BPEL processes so that theyuse the T3-PEP-RQ is not a task of this component.

8.1.3 Functionality

Figure 8.1 describes the usual flow of messages involving the T3-PEP-RQ, in a setting where no erroroccurs. The steps are as follows:

1. The BPEL process sends the request to the PEP-RQ. In addition to the payload, it contains theinstance identifier of the process, an identifier for the abstract endpoint to be called, and the actionto be invoked on the target service.

2. The T3-PEP-RQ logs the fact that it is now handling a request to the audit bus (service requesterchannel).

3. The T3-PEP-RQ looks up to which process model the given instance belongs (call to the BPELexecution engine).

4. It logs the result to the audit bus (service requester channel).

5. It retrieves the applicable policies for that process model.

6. It sends a request to the T3-PIP-IR to retrieve the current endpoint assignment for the given endpointidentifier and the given process instance. The T3-PIP-IR replies.

7. It logs the determined endpoint to the audit bus (service requester channel).

8. It sends an authorization request to the PDP, encompassing the model ID, the instance ID, theendpoint identifier and actual endpoint URL, and possibly the payload or parts of the payload.

9. After receiving the decision from the PDP, it logs it to the authorization channel of the PDP.

10. The T3-PEP-RQ forwards the request (stripping all data except the payload) to the actual payloadservice at the endpoint URL previously determined, invoking the specified SOAP action. Then itwaits for the reply of that service.

11. It logs the successful payload call to the audit bus (service requester channel).

12. It sends another authorization request to the PDP, inquiring whether the reply may be forwarded tothe application (=the business process).



Business Process T3-PEP-RQ Secure Audit WebService

PDPBPEL Engine PIP-IR Payload service

Webservice call(Payload, Process Instance ID, Endpoint ID)

Log(TOPIC = SRQC, Started request handling)

getModelForInstance(InstanceID)

Log(TOPIC =SQRC)

getPolicies(modelID)

getCurrentEndpointAssignment(instanceID, endpointID) :endpointURL

Log(TOPIC=SRQC)

authorize(modelID, instanceID, endpointURL, payload)

Log(TOPIC=AC)

invoke(payloadData)

Log(TOPIC=SRQC)

authorizeReply(modelID, instanceID, endpointURL, payload)

Log(TOPIC=AC)

Figure 8.1: Conceptual sequence flow involving the T3-PEP-RQ



<pep:request xmlns:pep="http://bpel.pep-rq.kit.tas3.eu/"><pep:instance-id>12345</pep:instance-id><pep:endpoint-id>matchingService</pep:endpoint-id><pep:action>match</pep:action><pep:payload>

<m:matchingRequest xmlns:m="http://services.tas3.eu/"><m:portfolio>...</m:portfolio><m:programme>...</m:programme>

</m:matchingRequest></pep:payload>

</pep:request>

Figure 8.2: Example SOAP payload of a request to the T3-PEP-RQ, illustrating the XML structure

13. After receiving the decision from the PDP, it logs it to the authorization channel of the PDP.

14. It returns the reply to the business process.

The flow given in the figure only addresses a situation without errors. Taking errors into account, thefollowing deviations can occur:

1. The request in step 3 might not succeed. The T3-PEP-RQ logs this to the audit bus and returns afault to the calling process.

2. The request to the PIP-IR in 6 might not succeed, or the endpoint is not yet assigned. The T3-PEP-RQ logs this to the audit bus and returns a fault to the calling process.

3. When the PDP does not authorize the request or the reply in steps 9 and 13, respectively, the T3-PEP-RQ returns a fault to the calling process.

4. In step 10, a timeout can occur. In this case, the T3-PEP-RQ logs the error situation and returns afault to the calling process.

An example of the SOAP payload of a request to the T3-PEP-RQ is given in Figure 8.2. The actualpayload is encapsulated inside the <pep:payload> element.


The distribution of the T3-PEP-RQ component, which is available from the TAS3 Pool repository con-tains the following elements:

• The Java sourcecode of the component.

• A number of libraries (JAR files) needed to build and run the component. This includes ApacheMuse (needed to interface with the Audit Bus), and some Axis2 and XML libraries.

• The T3-BP-PIP-IR component in the form of a Axis2 webservice archive (PEPRQ.aar), ready fordeployment on an Axis2 container.

• A services.xml file.

• A web-service used for testing as an Axis2 archive (Concat.aar), ready for deployment on an Axis2container.




8.2.1 Compiling the source

The Eclipse project contains all necessary libraries (as JAR files) in and has a properly configured buildpath. src/eu/tas3/kit/PEPRQ.java is the only source code file. If compiling by hand, the build pathmust include all JAR files in /lib. The AAR needs to be built manually. Create a folder with the followingcontent:

• eu/tas3/kit/PEPRQ.class (with the full path),

• A folder lib/ with all JAR files.

• A folder META-INF with the file services.xml

Then, execute jar cvf PEPRQ.aar ./* in that folder. The Axis2 archive of the component will becreated and is ready for deployment.


T3-PEP-RQ has no specific hardware requirements. However, the system must be able to run a Axis2web-service engine.

We use Tomcat 6 and Axis2 1.5.1 running as a servlet/web-application (packaged as a WAR) on top ofTomcat.


The software contains hard-coded URLs for components called by it, namely the Audit Bus and thePIP-IR. We will improve this in the next version by allowing such parameters to be set in a configurationfile.

The T3-PEP-RQ can be installed by copying the PEPRQ.aar file to the services folder of your Axis2container.1 The PEPRQ.aar file will be deployed automatically when the Tomcat server is running or whenit is started for the next time.


For testing, it is important to understand that the PEP-RQ itself is a stateless component. However, itrelies on other components that are stateful. For now, this is only the PIP-IR, but we will add other statefulcomponents as dependencies in the future.

8.2.4.1 Live testing as a web-service

We test the T3-PEP-RQ in a "‘live"’ web-service environment. This requires some prerequisites:

• External components must be in a state required for successfully testing the PEP-RQ.

• The PEP-RQ is a proxy involved when the business process calls external services. Thus, at leastone such service must be available.

The following steps lead to a suitable state of the PIP-IR:

• Start with a fresh setup of the PIP-IR (i.e., empty database).

• Create a process model with ID 5 and a role named concatService of type service: createModel(5,"concatService", "service")

1Usually the full path is webapps/axis2/WEB-INF/services within your Tomcat installation folder.



<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"xmlns:kit="http://kit.tas3.eu">

<soap:Header/><soap:Body>

<pep:request xmlns:pep="http://bpel.pep-rq.kit.tas3.eu/"><pep:instance-id>29</pep:instance-id><pep:endpoint-id>concatService</pep:endpoint-id><pep:action>concat</pep:action><pep:payload>

<kit:concat xmlns:kit="http://kit.tas3.eu"><kit:a>ff</kit:a><kit:b>gg</kit:b>

</kit:concat></pep:payload>

</pep:request></soap:Body>

</soap:Envelope>

Figure 8.3: Test of the PEP-RQ: Request

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body>

<ns:concatResponse xmlns:ns="http://kit.tas3.eu"><ns:return>ffgg</ns:return>

</ns:concatResponse></soapenv:Body>

</soapenv:Envelope>

Figure 8.4: Test of the PEP-RQ: Expected response

• Create a process instance with ID 29 of the model with ID 5: createProcessInstance(29,5))

• Assign the endpoint for the service of role concatService: assignServiceRole(29,"concatService", "http://taipei.ipd.uka.de:8082/axis2/services/Concatenator.ConcatenatorHttpSoap12Endpoint/") (of course, this endpoint URL depends on where theservice is deployed).

The service to be called is provided as Concat.aar and can be deployed on the same Axis2 installationas the PEP-RQ.

The test is performed by sending the SOAP request shown in Figure 8.3 to the endpoint of the PEP-RQ(http://taipei.ipd.uka.de:8082/axis2/services/PEPRQ.PEPRQHttpSoap12Endpoint/ in our case),addressed to the invokeService action. The expected response is shown in Figure 8.4. This is the sameresponse as the payload service itself would provide.


8.3.1 Tutorial

From the perspective of the BPEL process running on T3-BP-ENGINE-ODE, the T3-BP-PEP replacesthe actual payload web-services to be used. Every payload call must be wrapped into an XML container,which also contains additional context information.

The SOAP body of the request to the PEP-RQ has the following structure:



• All elements use the XML name space http://bpel.pep-rq.kit.tas3.eu/.

• The top-level element is request. All other elements are children of request.

• The element instance-id contains the ID of the process instance that caused the request.

• The element endpoint-id contains the role of the service to be called. This role must be definedfor the process model, and an endpoint URL must be actually assigned at the time of the request.

• The element action contains the SOAP action to be performed by the payload service.

• The element payload contains the actual payload, which is passed on to the payload service. Thiscan be arbitrary XML data, including elements defined in arbitrary XML name spaces.

8.4 ArchitectureThe PEP-RQ is a stateless and monolithic component, which allows to keep the architecture simple.

However, a number of libraries is used. The following functionality deserves attention in this respect:

• Audit Bus logging: Communication with the Audit Bus uses the Apache Muse libraries and is basedon sample code provided by Nottingham.

• Configuration: Currently, configuration (e.g., locations of the audit bus and the PDP) is hard-coded.We plan to use a configuration file for this, based on Java properties.

• PDP communication: Communication with the PDP (XACML request/response pattern) will usethe zxid_az() function or a similar XACML client library.

• XML and SOAP processing: The PEP-RQ is deployed in Axis2 (as described in the services.xmlfile) as a RawXMLINOutMessageReceiver. Accordingly, the PEP-RQ receives the XML payloadof SOAP messages as a data structure according to Axis2’s AXIOM library. For constructing therequest to the payload service, it relies on the AXIOM libraries, as well.

8.5 API and Library InformationThe PEP-RQ does not have a dedicated API. It processes SOAP messages invoking the invokeService

operation that encapsulate payload messages. The format of these is described above in section 8.1.3.



9 License InformationThe external components we use have the following licenses:

• Apache Ode uses the Apache License, version 2.0.

• Apache Derby is available under the Apache License, version 2.0, as well.

• Intalio Tempo (including all components) is licensed under the Eclipse Public License, version 1.0.

All newly developed software presented in this deliverable is made available under the BSD license.



10 ConclusionsThis report describes the implementation of components described in Deliverable D3.1 providing a

framework for secure business processes. The reported implementation mostly focus on the status of theconceptual design half a year before, contained in the first iteration of D3.1. But there also exist interre-lationships between implementation and conceptual design, so that implementation influences partly theconceptual design and on the other hand the ongoing conceptual design and possible changes affect theimplementation task.

The current status of the implementation contains first versions of a subset of the components of allcategories of tasks which we identified to establish security for business processes in the TAS3 context asfollows:

• Capturing and storing security-relevant information about instances of business processes: TAS3-BP-PIP-IR.

• Runtime enforcement of security policies by inspecting incoming and outgoing messages: TAS3-PEP-RQ, TAS3-BP-MGR, and the engine to run business processes, namely TAS3-BP-ENGINE-ODE.

• Management of configuration changes in other parts of the TAS3 infrastructure: TAS3-BP-PPM.

• Creation of security configuration based on process models: TAS3-BP-SM.

The next iteration step will refine and enhance these component implementations according to the re-sults of the conceptual design and implement further components, i.e. the interval monitor which controlstime-restricted authorisations due to business process semantics and the process-instance-specific handlingóf security attributes.



Bibliography[1] Apache, “Apache Ode (Orchestration Director Engine).” [Online]. Available: http://ode.apache.org/

[2] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith,S. Thatte, I. Trickovic, and S. Weerawarana, “Business Process Execution Language for WebServices, Version 1.1,” May 2003. [Online]. Available: http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

[3] OASIS, “Web Services Business Process Execution Language Version 2.0,” OASIS Standard., April2007. [Online]. Available: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

[4] Intalio, “Intalio Tempo.” [Online]. Available: http://tempo.intalio.org


http://ode.apache.org/

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

http://tempo.intalio.org


Glossary• B4P or BPeL4People: enhancement of the BPEL standard to support human activities

• BPEL: Business Process Execution Language

• BPEL4WS: BPEL for Webservices, name of the BPEL specification up to version 1.1

• PIP-IA: Policy Information Point for Attributes of Process Instances

• PIP-IR: Policy Information Point for Roles in Process Instances

• JBI: Java Business Integration, a SOA (service-oriented architecture) integration standard

• JNDI: Java Naming and Directory Interface, a Java directory service

• PEP: Policy Enforcement Point

• PIP: Policy Information Point

• SOAP: lightweight protocol for XML-based message exchange

• WAR: Web Application Archive, a web application container format

• WS-BPEL: Web Services Business Process Execution Language, current name of the BPEL speci-fication

• WSDL: Web Services Description Language, an XML-based language for describing webserviceinterfaces


Annex A: Configuring Tomcat JNDI datasource set-tings

In the following we describe how to configure a database as a JNDI resource of an Apache Tomcatinstallation.

The easiest way to make a data resource accessible for servlets or webservices running within servletson a Tomcat application server is to configure the database as a global resource. (In this context "global"means "accessible from all servlets running in the Tomcat container".)

To achieve this you just have to put this code block into the <GlobalNamingResources> section of theserver.xml file in the conf folder of your Tomcat installation. The code block shows the default configura-tion for the PIP-IR Derby database.

<Resource name="jdbc/PIP-IR"

type="javax.sql.DataSource" auth="Container"description="Derby database for PIP-IR component"maxActive="100" maxIdle="30" maxWait="10000"username="" password=""driverClassName="org.apache.derby.jdbc.EmbeddedDriver"url="jdbc:derby:databases/PIP-IR"/>

Username and password have to be specified for the respective database. (For the databases we provideon the TAS3 Pool there is no access restriction set by default). The URL points to the databases/PIP-IR folder in the Tomcat directory. This path must also be adjusted if the database has been depositedelsewhere.


Amendment History

Ver Date Author Description/Comments1.0 31.12.2009 Jutta address review comments of Jeroen0.8 29.12.2009 Jutta refine component descriptions0.7 23.12.2009 Jens, Jutta,

Thorstenaddress review comments of Michael

0.6 21.12.2009 Jutta Add executive summary, conclusions, refine intro, uploadfor review

0.5 19.12.2009 Jens add PEP-RQ0.4 17.12.2009 Thorsten, Jens further elaboration0.2 30.11.2009 Jens, Thorsten refinement of description of components0.1 6.11.2009 Thorsten First draft out of blue


Deliverable Open Source software and documenta- tion ......13 Intalio UK INT Partner 14 Risaris IR...

Documents

Transcript of Deliverable Open Source software and documenta- tion ......13 Intalio UK INT Partner 14 Risaris IR...