Support for Dynamic Security Policy in Service-Oriented Architecture
Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed services that may be under the control of different ownership domains [1].
SOA provides a uniform means of offering, discovering, and interacting with and using services to produce desired effects consistent with measurable preconditions and expectations. Being service-oriented requires services to be only loosely coupled to operating systems and other technologies that underlie applications. SOA separates functions into distinct units, or services [8], which developers make accessible over a network so that users can combine and reuse them when producing applications. These services communicate with each other by exchanging data or by coordinating an activity between multiple services.
The SOA can be implemented by a software system such as Web services [8].
Web services make functional building blocks accessible over standard Internet protocols independently of platforms and programming languages. These services can be new applications or wrapped around existing legacy systems to make them network-enabled. One of the goals of SOA is to allow users to combine various functionalities to form ad-hoc applications that are almost entirely developed from existing software services. Orchestration is normally required to produce a new application [9]. A high-level language such as the BPEL extends the service concept by providing a method for defining and supporting the orchestration of fine-grained services into more coarse-grained business services [10]. Orchestration involves ensuring that Web services interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under
the control of a single endpoint. This involves an executable business process that may result in a long-lived, transactional, multi-step process model. In fact, the BPEL incorporates a workflow model to describe the orchestration of Web services.
As SOA services are opened up, it is necessary to consider how to combine these services securely [11]. In many business domains, Web services must exhibit quality attributes such as robustness, security, and maintainability. Several emerging technologies and standards address different aspects of the problem of security of services in SOA. For example, standards such as WS-Security [12], SAML [13], WS-Trust [14], WS-SecureConversation [15], and WS-SecurityPolicy [16] focus on the security and identity management of SOA implementations that use Web services.
These standards have been created to address message-level security and provide the ability to satisfy security requirements within an SOA environment. However, these standards only support the static specification or description of the security requirements in an SOA environment.
As mentioned above, services require orchestration to produce a new application.
The BPEL demonstrates that a workflow model is necessary when performing the orchestration. However, the execution of a workflow-based system is intrinsically dynamic. For example, the branching that occurs during workflow execution may depend on the values of certain variables in a process instance, and the presence of branching in a previous execution may influence the subsequent execution. This makes it necessary to investigate if statically specifying the security policy requirement fulfills the requirements of the workflow-based SOA environment.
In this chapter we first present several motivating examples to demonstrate that if the security policy requirement cannot be specified according to dynamic behavior in a workflow-based SOA system, then the resulting overly tight coherence between the
Security policy requirement and the flow structure will increase the difficulty, overhead, and cost of system development and maintenance. According to the separation-of-concerns principle, implemented Web services should only provide the core required functionality. Herein we (1) propose the concept of dynamic policies for SOA systems, (2) describe the architecture to support dynamic policies in the BPEL, and (3) define a language called the dynamic policy specification language (DPSL) to support the proposed architecture. Although the DPSL is designed to cooperate with previously proposed standards for SOA architecture, such as the WSDL, the BPEL, WS-Security, WS-Policy, WS-SecurityPolicy, and WS-ReliableMessaging, we believe the method of incorporating dynamic policies into SOA using the DPSL can be applied to any SOA architecture. Therefore, we can separate the specification of the security policy requirement and service orchestration so as to reduce the software development and maintenance cost of an SOA system. The implementation and experimental results presented here demonstrate the feasibility of the proposed architecture.
This chapter is organized as follows. In Section 2-1 we present examples to show that statically specifying the security policy requirement is insufficient. Section 2-2 surveys previous work on Web-services framework and related work which tried to extend it. In Section 2-3 we present the syntax and semantics of DPSL. The architecture to support DPSL in BPEL is given in Section 2-4. In Section 2-5 we show the implementation and experimental results.
2-1. Motivating examples
In this section we present examples to demonstrate that statically specifying the security policy requirement is insufficient. Without loss of generality, we use the BPEL, WS-Security, and WS-SecurityPolicy to construct our demonstration example.
Figure 2-1 shows the first example, which is a BPEL process. Assume that it is part of the military supply system. The “Client”, “Inventory Query Service”, and
“Registration Service” are external Web services. The basic security requirement in preliminary system development is that the communication between the process and external Web services should be protected by the mechanism supported by WS-SecurityPolicy. Assume that the security policies between the three external Web services are defined by SP1, SP2, and SP3 as shown in Figure 2-1. SP1, SP2, and SP3 define the communication security requirements for Web-services transaction in WS-SecurityPolicy, and are bound to the three bindings of the three Web services separately. The process consists of several activities:
Activity A1. This receives the supply requirement from the “Client”, and contains the amount and number of items.
Activity A2. This checks the inventory of the item received in activity A1 by invoking an external Web service.
Activity A3. This sends the actual supply requirement to the supply depot and registers it.
Activity A4. This replies to the “Client”.
The original BPEL for the first motivating example.
Client
portType A1
A2
A3
WSDL BPEL : partnerLink
: partnerLinkType A4
Inventory query Service binding
SP3
binding SP1
Register service binding
SP2 portType
Figure 2-1. The original BPEL process in the first motivating example
Assume that the security requirement has to be changed after its first deployment.
Since inventory information is confidential in a military supply system, the authority decides that activity A2 should not communicate with “Inventory query services” with security policy SP1 directly. The new requirement is that the security policy should be selected according to the category of the item obtained in activity A1. The items are classified into two categories, each with different security policies in communicating with the “Inventory query service”. Assume that the two security policies are SP1 and SP1. Different security policies have different cryptographic algorithms and keys.
WS-Policy supports policy alternatives, which allows us to specify a set of policies from which the service client can choose one policy arbitrarily [17]. However, since WS-Policy does not support switching security policies according to the dynamic behavior of the BPEL process directly, the system developer needs to change the original BPEL process according to the new security requirements. Figure 2-2A shows the modified BPEL process, which adds an “if” activity B1 that decides how to pick the security policies according to the item category obtained in activity A1. If the appropriate security policy is SP1, B1 controls the flow to execute activity C1;
otherwise B1 controls the flow to proceed to C2. Note that C1 and C2 are activities that specify the corresponding binding1 of the partnerLink of A2. Furthermore, if the authority needs to add more security policies for the communication to the “Inventory query service”, the system developer needs to add more activities to the BPEL process, as shown in Figure 2-2B. We can see that the security requirement depends on the dynamic behavior of the BPEL process since it depends on the data received in activity A1. Also, the structure of the BPEL process itself needs to be modified when the
1 Actually, it specifies the endpoint reference to the partner of the partnerLink. The endpoint reference belongs to a port and the port belongs to a binding that is associated with the portType of the partner [18-21].
security requirement changes. The resulting tight coherence between the structure of the BPEL process and the security requirement makes the system difficult to design and maintain. Below we give another example to demonstrate another kind of dynamic behavior that the security requirement may depend on.
Client A1
BPEL WSDL
The modified BPEL for the first motivating example.
If
The worst-Case BPEL for the first motivating example.
If
Figure 2-2. The modified (A) and worst-case (B) BPEL processes in the first motivating example
The second example is similar to the first example. However, we now have two
“Inventory query service” Web services for different items received in activity A1.
Referring to Figure 2-3, the process consists of several activities:
Activity A1. This receives the supply requirement from the “Client”, and contains the amount and number of items.
Activity D1. This checks the inventory of the item received in activity A1 and decides to branch to either A2 or A3 to invoke the applicable external Web service.
Activities A2 and A3. These invoke different external Web services.
Activity A4. This sends the actual supply requirement to the supply depot and registers it.
Activity A5. This replies to the “Client”.
Similar to the previous example, assume that the security requirement has to change after its first deployment. The new requirement is that activity A4 can communicate with the register services using different security policies according to the previous flow control of the BPEL. This depends on the execution of activity D1.
If activity A2 was executed, then activity A4 uses security policy SP2; otherwise it should use policy SP2. Figure 2-4 shows the modified BPEL process. Note that C1 and C2 in D2 are used to select an appropriate binding of the partnerLink for A4.
The original BPEL for the second motivating example.
Client A1
Figure 2-3. The original BPEL process in the second motivating example
The modified BPEL for the second motivating example.
Client
Figure 2-4. The modified BPEL process in the second motivating example In the two motivating examples, the appropriate security policy cannot be determined until after the BPEL starts executing. In the first example, applying the security policy depends on the parameters received in activity A1, whereas in the second example the security policy should be enforced according to the flow control of the BPEL process. The situation is more complicated since the security policy depends on the computation result of the BPEL process, given that activities can perform sophisticated computations. An intuitive solution is to encode the security requirement in the implementation of the BPEL process, but then the BPEL process would have to be modified when the security requirement changes, and vice versa. This tight coherence between the BPEL process and its security policy increases the cost of implementing and maintaining the SOA application.
2-2. Related work
The main work related to the present study is the Web-services policy framework (WS-Policy) [17], which is an industrial specification standardized by the World Wide Web Consortium (W3C). WS-Policy defines a policy as a collection of policy
alternatives, each of which is a collection of policy assertions. New policies can be defined to satisfy the needs of specific domains if these are not already included. Tosic et al. extended WS-Policy by introducing WS-Policy4MASC, which uses four new types of policy assertions: “goal”, “action”, “utility”, and “meta” [22]. The primary intent of this approach is to specify monitoring and control policies. The policy assertions define actions to be taken—such as the removal, addition, replacement, skipping, or rerunning of a subprocess, or process termination—as soon as certain conditions are met. However, it does not support controlling policies according to the dynamic behavior of process execution in SOA. Liang et al. proposed a set of customized policy assertions in WS-Policy, called WS-CustomizationPolicy, which do not provide for the management of dynamic properties [23].
WS-Policy can only specify static properties, and hence it is implicit that these properties will never change when the service is defined. Several proposals had been published to support dynamic policies in Web services. Yee and Korba proposed a flexible security personalization approach that allows the Web-service provider and customer to derive the desired security policy via negotiation [24]. They also discussed how to extend the proposed approach to WS-Policy. Mathes et al. proposed WS-TemporalPolicy, which allows the service developer to attach a validity period to the properties described in WS-Policy [25]. Hollunder proposed a new WS-Policy operator, the if-operator, to enable conditional assertions [26]. This operator can choose assertions dynamically according to the value of a service parameter, the response time, or the cost of services. Baresi et al. proposed the Web-service constraint language (WS-CoL), which specifies user requirements for the execution of certain Web services. WS-attachment and WS-Policy are extended so that applying a policy can be constrained by the WS-CoL expression [27]. The original syntax and semantics
of WS-Policy have also been extended by others [25, 26, 27], but the disadvantage that the standard Web-services engine is unable to carry out the new policy or assertion remains. Our work avoids this limitation by not needing to extend WS-Policy; instead, we employ the standard Web-services engine and the BPEL engine to support dynamic policies according to DPSL documents in the BPEL run-time system.
2-3. The DPSL
To separate the implementation of the BPEL and the setting of its security policy, Web services, the BPEL, WS-Security, and WS-SecurityPolicy are standalone standards. Web services and the BPEL are proposed first, followed by the corresponding standards for their security such as WS-Security and WS-SecurityPolicy.
Since Web services and the BPEL can operate without considering security requirements, WS-Security and WS-SecurityPolicy cannot interfere with the operation of Web services and the BPEL. Thus, the application designer always first defines the Web services and the BPEL required for the application, and then tests the semantics of the defined application without adding the security mechanism. Finally, after the semantics is tested, the designer defines general security policy assertions and applies Web-Services security, including SOAP Message security, WS-Trust, and WS-SecureConversation. WS-SecurityPolicy can define only a static security policy, and hence the most flexible way to include multiple security policies in WS-SecurityPolicy is to specify them as possible alternatives [17]. The client can then choose one of these policies to make a particular Web-service transaction. It is obvious that statically providing policy alternatives is not sufficient to implement the motivating examples presented in Section 2-1, since in a real application the security policy may depend on the dynamic behavior of the BPEL execution. In the first
motivating example, the security requirement depends on the category of the item obtained in activity A1, which is represented as a variable in the BPEL process. In the second example, the security policy changes according to the result of branching in activity D1. Our goal is to separate the BPEL process implementation and security policy, which means that the system designer should not need to change the implementation of BPEL processes when the security policy is altered.
Here we consider an SOA application to be a software system consisting of multiple BPEL processes and standalone Web services. Also, we define the dynamic behavior of a workflow process like the BPEL to be the dynamic state under actual operating conditions that is described by various parameters, including variables, the execution history, and the control flow. To synchronize the enforcement of security policies with the dynamic behaviors of an SOA system, the system designer has to embed detectors of the dynamic behavior into the workflow system of an SOA application. The detectors recognize specified behaviors and then instruct the workflow system to perform appropriate tasks to implement certain security policies.
Thus, the semantics of the security requirement is closely related to the implementation of the SOA application, and so changing the security requirement always requires the implementation of the SOA application to be modified. This makes the maintenance both difficult and expensive, and so it would be preferable to separate the implementation of the SOA application and the security requirement. Furthermore, an SOA application usually contains multiple workflow systems. For example, the BPEL is designed to implement an SOA application with multiple processes, and the security requirement in one BPEL process may depend on the dynamic behavior of another BPEL process. In this case the dynamic behavior of one BPEL process needs to be detected by another BPEL process.
BPEL0, BPEL1, …,BPELN-1
A DPSL document D
WSDL0, WSDL1, …,WSDLN-1
A BPEL-based SOA application without security consideration
A BPEL-based SOA application with dynamic security policy
Figure 2-5. An SOA application with dynamic policies
In this chapter we propose the concept of dynamic policies, where the enforcement of service policies can depend on the dynamic behavior of the workflow systems in the SOA application. Although here we only discuss how to implement this concept in the BPEL-based SOA architecture, it can be applied in any SOA system. A BPEL-based SOA application initially consists of some BPELs and their corresponding WSDLs (note that a standalone Web service is considered to be a BPEL process that only receives requests and replays the execution result). Referring to Figure 2-5, BPELi and WSDLi, 0i<N, consist of an SOA application without considering security requirements. During software development we usually first design an application without a security policy requirement. After its functionality is tested, we then attempt to add the security policy requirement to the application. We need to consider how to define the security policy requirement in the DPSL.
Before we provide the details of the DPSL syntax, we first present the general syntactic form of a DPSL document (Figure 2-6). A DPSL document, which is defined as being an XML document, consists of the following three sections:
Namespaces Declaration
WS-Policy Description (Policy 1 - n)
Designated portType name Dynamic behavior descriptor and
corresponding WS-Policy link
Dynamic behavior descriptor and corresponding WS-Policy link
Dynamic policy specifier
Figure 2-6. The architecture of a DPSL document
1.
The header section. Since a DPSL document is also an XML document, a
DPSL document should begin with an XML declaration that specifies the version of XML being used (e.g., <?xml version="1.0"?>). This section also contains required namespace declarations.2.
The WS-Policy description section. This section defines certain policies
according to WS-Policy defined by the W3C. These policies are set to be activated dynamically.3.
The dynamic policy specifier section. This section contains many dynamic
policy specifiers, each of which has a designated portType name that is the
portType name in the original SOA application. According to the WS-Policy attachment [20], we can associate a policy to a binding, a portType, an operation, or even an input/output message of an operation. Note that the original SOA application does not specify a WS-Policy. Without loss of3.