Modeling and Executing Business Processes with Annotated Security

2011 IEEE International Conference on Web Services

Modeling and Executing Business Processes with Annotated Security Requirements in the Cloud J. Damasceno, F. Lins, R. Medeiros, B. Silva, A. Souza, D. Aragão, P. Maciel and N. Rosa

B. Stephenson and J. Li Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 USA {bryan.stephenson, jun.li}@hp.com

Centre of Informatics Federal University of Pernambuco Recife, Brazil {jcd, faal2, rwam, blbs, arss, da, prmm, nsr}@cin.ufpe.br

waiting for the IT artifacts to be created or modified and put into operation in a test or production environment.

Abstract— The design, deployment and execution of business process models and their associated security models is expensive and time consuming. This is because these activities usually involve multiple stakeholders that include business domain experts, security experts, web service developers and IT operations teams, and there is no streamlined development environment to allow these stakeholders to work collaboratively on a business process. We have developed a cloud-based modeldriven development and execution environment called SSC4Cloud to provide a shared business process modeling workspace and a business process execution environment. More specifically, with the shared modeling workspace, business process models can be developed, refined and shared. Within the shared execution environment, a business process model is translated into a WS-BPEL based executable model, which is then assigned for execution in a virtual machine container from a shared machine cluster. The common model execution environment supports both business process execution and enforcement of the security requirements attached to the business process models.

To address the lack of a BPM streamlined development environment and the difficulty of running and testing the BPMs, we created a cloud-based model-driven development and execution environment, SSC4Cloud, which enables users to work together to model, execute, and test BPMs. An Eclipse Plugin runs on a user’s local machine to enable model creation and interacts with remote model repositories, work spaces, and a virtual machine based model deployment environment in the cloud. Each user is assigned with a workspace to hold his or her models and model execution artifacts. With respect to business process execution, SSC4Cloud provides support to produce executable artifacts and configurations from the BPM and allocate a user-isolated BPM execution environment. The SSC4Cloud environment provides the following unique capabilities: •

A shared business process modeling workspace from which the stakeholders from different organizations can work together to define a BPM and its associated security model, using BPMN [16] and our own BPMN modeling extensions [21]. The environment supports sharing of BPMs and their security models.

•

A business process execution environment that is constructed out of a shared computing resource pool, which allows a business process to be easily tested by translating the BPMN model into an executable service composition, and automatically deploying that service composition into a shared virtual machine (VM) pool managed by the Eucalyptus virtualization infrastructure controller [9]. The cloud-based common execution environment supports the execution of business process models (such as via the WS-BPEL [14] orchestration engine) and enforcement of security requirements [21].

Keywords: Cloud Computing; Business Process Modeling; Business Process Execution; Web Service Composition; Security.

I. INTRODUCTION It is expensive and time-consuming to perform iterative refinement of business process models (BPMs) and their associated security models, and to deploy and run the resulting business processes in an execution environment. This is because the development process involves multiple stakeholders that include domain experts to define the BPM, security experts to specify security requirements and governance policies for the BPM, developers to develop the service composition to realize the BPM, and finally the IT operations team to deploy the IT artifacts (which include the executable business process, OS images, and configuration files for the BPM execution engines) onto computing resources in a production or test environment. Currently there is no streamlined BPM development environment to allow these stakeholders to work collaboratively. Furthermore, such a production or test environment requires a sufficient number of computing resources that the IT organization needs to prepare and are often subject to financial budget constraints. As a result, business domain experts cannot validate the BPMs (using User Acceptance Testing [12], for example) without

978-0-7695-4463-2/11 $26.00 © 2011 IEEE DOI 10.1109/ICWS.2011.78

The rest of this paper is structured as follows. Section II presents a motivating application example. Section III briefly introduces our previous work on which this paper is based. Section IV introduces the cloud-based environment SSC4Cloud, whilst Sections V and VI present key technologies that we have developed. Section VII presents the prototype implementation of the proposed SSC4Cloud and experimental results on the prototyped model execution environment. 137

capabilities, security constraints or services may be added. This iteration allows users to test and enrich the business process.

Section VIII discusses related work. Section IX concludes the paper. II.

III.

ILLUSTRATIVE SCENARIO: VIRTUAL TRAVEL AGENCY

In this section, we present a use case to illustrate how a business process model can be defined and executed in our SSC4Cloud environment.

SEC-MOSC FOR SECURE SERVICE COMPOSITION

In our previous work, we developed Sec-MoSC to allow business processes to be annotated with high-level security requirements and executed in a local machine. Such security requirements are specified via a set of modeling abstractions. The three key modeling elements are NF-Attribute, NFStatement, and NF-Action [20]. NF-Attribute models nonfunctional characteristics that can be quantified and measured (such as performance) and qualitative non-functional characteristics that may be defined at a certain level (such as Security). NF-Attributes may be primitive or composite (composed of two or more primitive NF-Attributes). For example, the NF-Attribute Security may be composed of the primitive NF-Attributes Confidentiality and Availability. NFAction models either software or hardware mechanisms that affect or provide the NF-Attribute. One example of an NFAction is encrypting data. NF-Statement is a high-level constraint often described in terms of levels (e.g. High, Medium and Low) defined on the top of the NF-Attributes. In practice, the NF-Statement defines a specific set of NF-Actions that must be taken to achieve a particular goal. For example, the NF-Statement High Confidentiality puts a constraint on the NFAttribute Confidentiality and demands a specific set of NFActions to realize High Confidentiality.

Suppose a company named Virtual Travel Agency (VTA), needs to rapidly create and deploy its business process by using existing web services available in the Internet. At the same time, VTA does not plan to heavily invest in its own IT infrastructure and wishes to use as much as possible existing services (e.g. a service for booking hotels) developed by third parties and up-to-date security solutions (e.g. the middleware communication protocol that enforces WS-Security [15]).

The Sec-MoSC model-driven methodology [21] defines (1) the high-level specification of functional and security requirements at the business level (using BPMN), (2) the translation of these requirements into executable resources (e.g. configuration files and WS-BPEL executable models) and (3) the enforcement of the specified functional and non-functional requirements at the execution level. The methodology is supported by a toolset and its architecture is shown in Figure 2.

Figure 1. Business process and its security requirements.

With SSC4Cloud, VTA designs its business process either from scratch, or reusing one defined by another company and shared in the cloud. In both situations, VTA defines its own business process model (e.g. in BPMN) as shown in Figure 1. This business process shows the workflow on how to buy a flight ticket. The first BPMN task (Receive Customer Data) receives the VTA customer’s data that is processed by three other tasks (Check Flight Availability, Process Payment and Send SMS Confirmation) before its completion. Two tasks of this process (Receive Customer Data and Process Payment) have been annotated with the security requirement Confidentiality to indicate that such sensitive data must be protected when the business process executes in the cloud. VTA may fully adopt, customize or merge existing security solutions which have been made available in the cloud. After the definition of the business process and its security requirements, the business process must be deployed, which can make use of other Internet services (e.g. flight booking services, credit card payment services and short message services) developed by the other companies that satisfy functional and security requirements defined by VTA. Again, SSC4Cloud further allows VTA to find these services and execute the business process (now converted into a service composition) directly in the cloud by using the business process execution environment offered by SSC4Cloud.

Figure 2. Architecture of Sec-MoSC model-driven development environment.

The Sec-MoSC Model Editor provides capability used at development time to define a business process using the standard BPMN notation along with our own service and security extensions. The Model Editor interacts with the Model Repositories to store and retrieve modeling information about pre-registered services and security NF-Actions supported by these services. The CIM to PIM Translator maps the annotated BPMN model into platform independent WS-BPEL, service

This cycle may be repeated several times. In each iteration, the business process may be modified and new functional

138

Sharing Experience: Users may share their expertise by creating and sharing business process and security models with others. For example, a security expert can create a security profile which maps high-level security requirements to a set of detailed configuration requirements for security mechanisms in an application domain such as payment processing. A user at another company, such as a travel industry expert at VTA, can obtain that security profile and apply or customize it to a business process model which they are creating. Keeping and managing the knowledge such as security profiles in the cloud enables the business to leverage worldwide expertise to create and deploy business processes.

and security descriptions. The Auxiliary Engine generates the platform-specific WS-BPEL and security configurations from the corresponding platform-independent counterparts. Such platform-specific configurations are deployed to the WS-BPEL orchestration engine at runtime for execution of the service composition and enforcement of security requirements. IV.

SSC4CLOUD: CLOUD-BASED ENVIRONMENT TO MODEL AND EXECUTE BUSINESS PROCESSES In this paper we present an extension of the Sec-MoSC toolset called SSC4Cloud, a cloud-based environment for modeling, sharing, deploying and executing annotated business processes. The Sec-MoSC methodology (see Section III) still applies in SSC4Cloud. Figure 3 presents a general overview of the SSC4Cloud environment.

Rapid Prototyping Experience: Users may iteratively and rapidly create and refine business processes, and the service compositions that realize the business processes, by having the involved users share the same workspace. Integrated Experience: Users may create an annotated business process, translate it into a service composition, deploy the service composition in the cloud and execute it solely from the commands issued from the Model Editor. This running instance of the process model can be tested in a staged environment with real users and real Internet services. Rapid scaling based upon real-time business demands: The business may use the infrastructure capabilities and services offered by several providers to execute their processes. No backend IT infrastructure needs to be purchased. Common and trusted business process execution runtime support: The cloud-based execution environment provides a common and trusted platform for the translation of the business process models to their executable counterparts, the execution of the process models, and the enforcement of the security requirements annotated to the business process models. Specific to security enforcement, it provides the trusted implementation for a set of the supported NF-Actions. We took the Sec-MoSC architecture (in Section III) that we previously developed, re-designed and then re-packaged the key architectural components, i.e. the Model Editor, the Translator, and the Auxiliary Engine, into different scalable service components. Towards building this cloud based framework, we have developed two key technologies, to support the five unique features identified above. The first technology is on collaborative model definition and sharing. The second technology is on management of cloud-based execution environments. These two technologies are described in detail in the next two sections.

Figure 3. Modeling, sharing, deploying and executing a business process with security requirements in the cloud.

A Model Editor runs locally to create and share models, and interacts with remote model repositories and a virtual machine based deployment environment in the cloud (Model Execution Management Service and VM Manager). Each user is assigned with a workspace in the cloud to hold modeling and execution artifacts produced by the tools. The Model Editor produces models, the Translator produces security configurations and executable compositions, and the Auxiliary Engine produces the execution and monitoring results. In the multi-tenant environment, a workspace contains the tenant’s execution files such as the WS-BPEL business process configuration and security enforcement module configuration files.

V.

CLOUD-BASED COLLABORATIVE MODEL DEFINITION AND SHARING SSC4Cloud provides a cloud-based collaborative environment that allows different stakeholders to work together to define business processes and security profiles, and supports different organizations or groups of users to share their business processes and security knowledge.

Compared to the on-premise environment from our earlier Sec-MoSC work, the cloud-based environment of SSC4Cloud supports the following unique capabilities and experiences:

A. Overall Cloud-Based Modeling Architecture Figure 4 shows the main elements of the proposed cloudbased modeling environment, which consists of an editor

139

(Model Editor), a set of scalable cloud services, and repositories (Repositories).

textual descriptions of the service functionalities are stored in this repository.

The Model Editor is an extension of an existing BPMN editor [8] to support definition and sharing of business process and security models. The Model Editor consists of the following components: BPMN Editor, Service Editor, Security Editor and Authentication Module. The BPMN Editor is responsible to enable the functional specification of the business process (following the BPMN standard). Using the Service Editor, a user is able to identify and bind services to the business process. The Security Editor enables the user to model security aspects at the business level. The entire Model Editor is run on a user local computer environment.

(b) Service information. Additional information about the services is needed to enable a better form of organization and search. Service business type, organization and so on may be stored in this context. The Tenant Repository holds the information on each registered user (user credentials and personal information), and the access policies regarding which user groups are allowed to access which resources (that include modeling artifacts, security knowledge and service information). The Workspace is the repository that stores user-private information regarding the active modeling and execution environments. More specifically, it holds the information on: (a) Active modeling environment, which includes the business process models that the users have accessed in the current modeling session. (b) Active execution environment, which includes artifacts derived from the business process models, such as the executable process model described in WS-BPEL and the associated configuration files for workflow orchestration engines and security enforcement modules. The runtime monitoring logs produced from the running of the business process models are also preserved. The business process models defined in the Model Editor are stored in the repository Artifacts and accessed through operations of saving (Save), retrieving (Retrieve) and updating (Update). These models become immediately available to be shared with other organizations depending on the sharing policy of the model owners. Meanwhile, business processes may also be deployed (Deploy), started (Start) or stopped (Stop) by using the Model Editor.

Figure 4. The SSC4Cloud Modeling Environment.

The Authentication Service and User Account Management Service provide identity-based tenant authentication and authorization in the collaborative environment respectively. The collaborative environment also contains five repositories as presented in Figure 4. More specifically, the Model Artifacts Repository stores the information of:

B. Business Process Model Sharing There are three types of such model sharing. A security expert can define a security profile to capture high-level security requirements in a particular application domain (such as an online travel agency), and allow the security profile to be shared with other organizations that may be involved in the same application domain. Once the security profile is shared and stored in the repository Model Artifacts, it can serve as the guideline for the recipient organization to follow, merge and apply it to different business processes that belong to the recipient organization. The second kind of sharing is the sharing of business process model and its security model. If the shared security model uses security profiles imported from other organizations, the involved security profiles are shared accordingly. Sharing of both the business process model and the security model allows business partners to understand whether the business process that involves different services contributed from different organizations can work together, and whether compatible security requirements for data governance are supported when data flows from one organization to other organizations. The third kind of sharing is restricted to the sharing of only business process models, and no security models and security profiles are shared.

(a) Business process models. The BPMN models generated in the modeling phase are stored in the cloud to allow the collaborative and iterative design of the business process by multiple parties. (b) Security Profiles. A security profile can be shared with other partners. It is also possible that a specific tenant wants to access a security profile from a partner. This profile is stored in the Artifacts Repository. The Security Repository holds the Security Knowledge Information that is used in the modeling phase. Security NFAttributes (e.g. confidentiality), NF-Statements (e.g. “high”), NF-Actions (e.g. UseCryptography) and NF-Properties (e.g. algorithm type) are stored in this repository. In this work, services are selected by the business or service expert and linked to the BPMN diagram at modeling time using the SSC4Cloud Editor. The expert searches for these services in the internal service repository. This Service Repository holds the information on: (a) Service interface and functionality definition. Information related to the WSDL interface and high-level

140

This security profile is an example that can be defined for a virtual travel agency introduced in Section II. As can be observed in this code example, three NF-statements were defined for the NF-Attribute Confidentiality (7): low, medium and high. The NF-Statement low (8-14) only requires the implementation of the NF-Action UseAuthentication (9-13); NF-Statement medium (15-26) requires the implementation of NF-Actions UseCryptography and UseAuthentication; and the NF-statement high (27-42) has three required NF-Actions, namely UseAuthentication, UseCryptography and RestrictAccess. Finally, each NF-Action has a set of NFProperties (value pair) such as (34) and (35).

A security profile belongs to a tenant (a user or organization), has a usage context, and is defined in terms of the abstractions introduced in Section 3, i.e. NF-Statement, NFAttribute, NF-Action and NF-Property. The tenant is the creator of the profile and may share it with other tenants. A modeling context allows the security expert to document contextual information about the profile, including the application domains in which the profile is applicable, any corporate policies considered (e.g., data encryption and data retention), as well as the compliance and regulatory policies considered (such as HIPAA for storing medical records [11] and PCI DSS for credit card processing [17]). The context helps a user decide if the profile is one they would like to use. Under the defined context, a security profile can contain a set of NF-Attributes. Each NF-attribute can then be refined into a collection of primitive NF-Attributes. The next level is to define a collection of NF-Actions required to satisfy the NFAttribute. Note that an NF-Action can be assigned with some specific NF-Properties to meet detailed requirements such as specifying the encryption key size. An NF-Statement defines the set of NF-Actions that must be implemented to be achieved.

Once a security profile becomes sharable, it can be imported by other users to model security requirements in their business process models. By importing a profile, the user may fully reuse it, customize it, or merge it with other profiles. VI.

CLOUD-BASED EXECUTION

The cloud-based model execution environment (Execution Environment for short) is responsible to create an isolated execution environment from a shared resource pool to execute a business process defined by the user.

A hierarchical specification of the security profile can be expressed in an XML tree representation, as shown in the following: (1) (2)