Securing web service message flows using WebSphere DataPower, Part 1: Configuring the DataPower settings

This article series discusses securing web service message flows with the WS security policy to enforce and filter WSDL-defined WS policies using WebSphere® DataPower SOA Appliance with firmware 5.0.0.8 or later. Part 1 of this 3-part series presents the DataPower approach and explains high-level configuration steps.

Share:

Christophe Bouchet (christophe.bouchet@fr.ibm.com), IT Specialist, IBM

Photo of Christophe BouchetChristophe Bouchet is an IT Specialist with IBM Software Services for WebSphere. He has worked with the DataPower line of products since 2010, assisting many customers in their integration projects. Christophe has worked on service-oriented architecture and security requirements for more than 8 years.



18 September 2013

Introduction

This article is the first part of a 3-part article series that discusses securing web service message flows with WS-SecurityPolicy using WebSphere DataPower SOA Appliance with firmware 5.0.0.8 or later. The article covers a proof of concept that demonstrates the added value of DataPower appliances in terms of filtering and enforcing securities policies as defined in the WS-SecurityPolicy 1.2 specifications. The topology used in this article is relatively simple: it consists of a service consumer that consumes services exposed by a service provider.

To set the base to allow a security flow, the service consumer consumes through a DataPower appliance positioned at the edge of the network, and every incoming request intended to the service provider also flows through a DataPower appliance. In our case, the two participants are supposed to be partners or subsidiaries, communicating through an insecure network. We are listing a set of requirements that need to be matched in order to have an acceptable level of security.

Part 1 will describe the general configuration and different scenarios representing different topologies in which the appliance and the frontend and backend applications have different responsibilities. The requirement responsibility will be spread among the components to assess the capacity and performance of each component to address the requirements. DataPower SOA Appliances are a natural fit to serve as a gateway for web services exposition and consumption.

Part 2 describes the how the appliances handle the encryption part of the security policy. The signing is made by the service consumers and providers.

Part 3 explains all the security measures that are handled by the appliances (signature, encryption).

The appliance supports the WS-Policy, WS-SecurityPolicy, and WS-Security specifications, which are the focus of this article. This article is intended for technical specialists and architects who have a basic knowledge of DataPower concepts.

Prerequisites

The article is based on DataPower SOA Appliance XG45 firmware 5.0.0.5. The article also applies to other DataPower appliances models as long as the firmware is at least 5.0.0.5 (XI50, XI52, XB62, and so on). This article used the following versions of the WS-SecurityPolicy specifications and testing tool:


Architecture overview

Figure 1 provides an overview of the solution architecture. The service consumer and provider are applications that use a web services framework to consume or expose a web service. The flows go through the DataPower appliances that play the role of a service gateway.

Figure 1. Overall schema
Overall schema

Service provider

The service provider exposes a web. This web service has a set of operations that demonstrate the different scenarios. In some scenarios, the service provider has to implement some security requirements. The service provider is a business application that uses a web services framework to enable web service calls and invocation and to conform to the WS-* compliance.

Provider side: The provider side protects and offloads the service provider. In some scenarios, it handles the CPU intensive security operations.

Consumer side: The consumer side offloads the service consumer. In some scenarios, it handles the CPU intensive security operations.

Service consumer

The service consumer consumes a web service. As the service provider, it uses a web services framework to enable web service calls and invocation and conform to the WS-* specifications.

On top of that architecture, the goal is to enable flow security on the message in order that, at least between the two appliances where the unsecured network is located, the maximum level of security (in our case: mutual SSL plus message level signature and encryption) is always present. In this article, we will show three different scenarios for DataPower appliances when the security measures are applied either by the backend framework or by the appliance itself.

Requirements for the solution

This section lists the requirements for DataPower.

  • Requirement 1 (REQ1): Every communication to, from, and between appliances need to be made using mutual authentication over the SSL channel.
  • Requirement 2 (REQ2): To avoid message replay, the messages needs to contain a signed timestamp, as specified in the WS-Security specifications.
  • Requirement 3 (REQ3): To ensure message integrity and non-repudiation, the message flow applicative content need to be signed according to the WS-Security specifications.
  • Requirement 4 (REQ4): To ensure message privacy, the message flow of the applicative content need to be encrypted according to the WS-Security specifications.

Defined scenarios

Different scenarios are defined to demonstrate the configuration differences and the abilities of DataPower appliance to handle all or a part of the security measures. The differences between the scenarios only reside in which part of the end-to-end processing chain that has the responsibility of the requirements. Table 1 highlights the differences between the scenarios.

Table 1. Requirement repartition
Scenario Requirement repartition
Consumer sideProvider side
RequirementService consumerApplianceApplianceService provider
SC1 REQ1 X X
REQ2 X X
REQ3 X X
REQ4 X X
SC2 REQ1 X X
REQ2 X X
REQ3 (WSSE) X X
REQ4
(WSSE)
X X

In the first scenario shown in Figure 2, the security measures implementation is spread among the frameworks and the Datapower appliances. The consuming framework signs the outgoing messages. The Datapower appliance on the consumer side handles the message encryption and forwards the message to the service provider area. The provider appliance filters the incoming messages for those that do not match the WS-Security requirements. For others who do match, the provider appliance decrypts the message and forwards it to the backend framework that will verify signature and consume the message.

Figure 2. Scenario 1 overview
Scenario 1 overview

In that scenario, the backend frameworks are offloaded from the encryption and decryption task. It is supposed to accelerate the processing compared to the first scenario, as Datapower is purpose built in terms of cryptographic operations. The same happens for the responses.

In the second scenario shown in Figure 3, the security measures are all implemented by the Datapower appliances. The frameworks are exchanging messages without being aware that, later in the processing chain, some security measures will be enforced.

Figure 3. Scenario 2 overview
Scenario 2 overview

The consuming appliance gets clear messages from the consuming framework, and applies the signature and encryption to the message. It then targets the providing appliance that filters all incoming request to reject those that are not matching the WS-Policy requirements defined in the WSDL. It then processes the others to decrypt them, checks the signatures and timestamp, and forwards them to the providing framework. The same happens for the responses.

The use of web service proxy service

We will be using web service proxy services to perform the work on the appliances.

Web Service Proxy services are configured from the WSDL files and understand WS-Policies assertions that are defined, in our case, within the WSDL files. For security actions like signing and encrypting, the processing rules that are applicable at different levels (proxy, WSDL, service, port, operation) will allow you to perform the needed action at the corresponding level.

The use of certificates

The certificates used for encryption and signing are the same. We have one certificate-key pair for the consumer appliance, and one certificate-key pair for the provider appliance.

In terms of signing, no public certificate has to be deployed on remote appliances as the certificate will be included in the requests.

In terms of encryption, we have a policy parameter set (described below) that enables the use of certificate present in the request to perform the encryption in the response. This avoids deploying the certificates on the provider appliance. However, the provider certificate needs to be deployed on the consumer appliance to perform the encryption. An overview of the deployed certificate is shown in Table 2.

Table 2. Certificate deployment
Deployed on consumer applianceDeployed on provider appliance
Consumer private key X (for signing the request)
Consumer public certificate X (for decrypting the response) X (for encrypting the response)
Provider private key X (for signing response)
Provider public certificate X (encrypting the response for provider) X (for decrypting the request)
Consumer side certificate authority certificate X (for verifying the consumer's certificate)
Provider side certificate authority certificate X (for verifying the provider certificate)

Presenting WS-Policy

WS-Policy is a web services specification that allows web services to advertise their policies in XML inside or attached to the associated WSDL file. The policies can be different kinds, such as quality of service, security, run-time management, and so on.

An extension to the WS-Policy specification, WS-SecurityPolicy, extends the base assertions to include more specific security assertions. For instance, a WS-SecurityPolicy assertion can explicitly require a web service operation request to be signed with a particular signing and hash algorithm.

Policies can be specified inside the web service WSDL file or as an attached document to the WSDL file. Several policies can be advertised for a WSDL file, and in that case, the policy is arranged with WS-Policy keywords such as "at least one", "all", and so on.

Policies can apply to an entire binding (thus applying to several web services operations), or to only one operation's request or response. They can be referenced and reused across the operations contained in the WSDL.

WS-SecurityPolicy used in our scenarios

The following code listings show the different policies used in our scenarios.

Listing 1 shows the general binding-level WS-Policy that is attached to the policy-enabled WSDL.

Listing 1. General binding policy
<wsp:Policy wsu:Id="sign_chiffr_general_policy">
  <wsp:ExactlyOne>
		<wsp:Policy>
			<wsp:All>
				<sp:AsymmetricBinding>
					<wsp:Policy>
						<sp:InitiatorToken>
							<wsp:Policy>
								<sp:X509Token 
                                  sp:IncludeToken=
                                  "http://docs.oasis-open.org/ws-sx/
                                   ws-securitypolicy/200702/
                                   IncludeToken/
                                   AlwaysToRecipient">
                                    <wsp:Policy>
                                     <sp:WssX509V3Token10 />
                                    </wsp:Policy>
								</sp:X509Token>
							</wsp:Policy>
						</sp:InitiatorToken>
						<sp:RecipientToken>
                        <wsp:Policy>
                           <sp:X509Token sp:IncludeToken="
                             http://docs.oasis-open.org/ws-sx/
                             ws-securitypolicy/200702/
                             IncludeToken/Never">
								<wsp:Policy>
                                 <sp:WssX509V3Token10 />
                               </wsp:Policy>
							</sp:X509Token>
						</wsp:Policy>
					</sp:RecipientToken>
					<sp:Layout>
						<wsp:Policy>
							<sp:Strict />
						</wsp:Policy>
                    </sp:Layout>
					<sp:IncludeTimestamp />
					<sp:OnlySignEntireHeadersAndBody />
					<sp:AlgorithmSuite>
						<wsp:Policy>
							<sp:Basic256Sha256 />
						</wsp:Policy>
					</sp:AlgorithmSuite>
				</wsp:Policy>
			</sp:AsymmetricBinding>
			<sp:Wss10>
				<wsp:Policy>
					<sp:MustSupportRefKeyIdentifier />
					<sp:MustSupportRefIssuerSerial />
				</wsp:Policy>
			</sp:Wss10>
		</wsp:All>
	</wsp:Policy>
  </wsp:ExactlyOne>
</wsp:Policy>

In terms of requirements, this policy specifies assertions that must be fulfilled by all operations contained in the binding (in our case, all WSDL operations). It is a best practice to scope the policies at the right level. In our case, it avoids copying-pasting this policy in each operation.

It requires the following:

  • Use of X509 certificates by the sender and the recipient to perform cryptographic operations like signing and encryption.
  • All soap messages must conform strictly to the WS-Policy layout rules (defined in the WS-SecurityPolicy specifications).
  • Presence of a time-stamp conforming to WS-Security specifications.
  • Signing to be made on the root element of the body and header, when required
  • Use of the Basic256Sha256 algorithm for signature digest and message encryption.
  • Initiator and recipient to process key-specific identifier token references.
  • Initiator and recipient to process references using the issuer and token serial number.

The policies used for the web services operations are shown in Listing 2 and Listing 3.

Listing 2 shows the policy required for signing. This policy requires the body and the header of the soap message it is attached to (request, response, or both) to be signed. It is referred to in the first scenario.

Listing 2. Signing policy
<wsp:Policy wsu:Id="sign_policy">
    <wsp:ExactlyOne>
        <wsp:All>
             <sp:SignedParts
 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
	   <sp:Body />
	   <sp:Header Namespace="http://referentiel.ca.fr/soapHeaderV1" />
	</sp:SignedParts>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

Listing 3 shows the policy required for signing and encryption. This policy requires the body and the header of the soap message it is attached to (request, response or both) to be signed and encrypted. It is referred to in the second scenario.

Listing 3. Signing and encrypting policy
<wsp:Policy wsu:Id="sign_chiffr_policy">
<wsp:ExactlyOne>
        <wsp:All>
             <sp:SignedParts
 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
	   <sp:Body />
	   <sp:Header Namespace="http://referentiel.ca.fr/soapHeaderV1" />
	</sp:SignedParts>
	<sp:EncryptedParts
 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
	   <sp:Body />
	<sp:Header Namespace="http://referentiel.ca.fr/soapHeaderV1" />
            </sp:EncryptedParts>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

WSDL files used in our scenarios

Several WSDL files are used for this scenario. The variation between the WSDL files is the presence of the WS-Policy sections that require some security for incoming and outgoing messages.

The presence of WS-Policies in a WSDL file (or attached to the WSDL file) enables DataPower to understand the policies and to perform some out-of-the-box actions on incoming and outgoing messages, such as message filtering or automatic policy enforcement.

By adjusting the policies at different steps of the end-to-end processing flow, you can apply different levels of requirements. Figure 4 gives a visual representation of the WSDL use.

Figure 4. WSDL high level sequence
WSDL high level sequence

In terms of web services operations, the same WSDL file is exposed by the DataPower appliances and service provider. Only the WS-Policies requirements are adjusted. The schema shown in Figure 4 highlights the processing steps concerning the requests (for the responses, enforce and filter would be reversed) for a configuration where the security measures are all handled by DataPower SOA Appliances (encryption and signature).

Here are the details of the different WSDL version used:

  • Listing 4 shows a WSDL file with no WS-Policy requirements.
  • Listing 5 shows a WSDL file containing WS-Policy requirements for signature only.
  • Listing 6 shows a WSDL containing WS-Policy requirements for signature and encryption.
Listing 4. Policy free WSDL
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:serv="http://www.credit-agricole.fr/interop/POC1/"
	xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:ca_
     erreurs="http://referentiel.ca.fr/ErreursV1"
	xmlns:ca_header="http://referentiel.ca.fr/soapHeaderV1"
	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
     oasis-200401-wss-wssecurity-utility-1.0.xsd"
	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
	xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
    xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/
     optimizedmimeserialization"
	name="POC1" targetNamespace="http://www.credit-agricole.fr/interop/POC1/">
	<wsdl:types>
		<xsd:schema>
			<xsd:import schemaLocation="POC1.xsd"
				namespace="http://www.credit-agricole.fr/interop/POC1/" />
			<xsd:import schemaLocation="CA_Erreur.xsd"
				namespace="http://referentiel.ca.fr/ErreursV1" />
			<xsd:import schemaLocation="CA_groupHeader.xsd"
				namespace="http://referentiel.ca.fr/soapHeaderV1" />
		</xsd:schema>
	</wsdl:types>
	<wsdl:message name="getMsgSignChiffrRequest">
		<wsdl:part name="parameters" element=
         "serv:getMsgSignChiffrRequest"></wsdl:part>
		<wsdl:part name="CA_groupHeader" element=
         "ca_header:CA_groupHeader">
		</wsdl:part>
	</wsdl:message>
	<wsdl:message name="getMsgSignChiffrResponse">
		<wsdl:part name="parameters" element=
         "serv:getMsgSignChiffrResponse"></wsdl:part>
	</wsdl:message>
	<wsdl:portType name="Service_sec">
		<wsdl:operation name="getMsgSignChiffr">
			<wsdl:input message="serv:getMsgSignChiffrRequest" 
             name="getMsgSignChiffrRequest">
			</wsdl:input>
			<wsdl:output message="serv:getMsgSignChiffrResponse"
			name="getMsgSignChiffrResponse">
			</wsdl:output>
		</wsdl:operation>
	</wsdl:portType>
	<wsdl:binding name="Service_binding_sec" type="serv:Service_sec">
		<wsoap12:binding style="document"
			transport="http://schemas.xmlsoap.org/soap/http" />
		<wsdl:operation name="getMsgSignChiffr">
			<wsoap12:operation
				soapAction="http://www.credit-agricole.fr/interop/
                 POC1/getMsgSignChiffr" />
			<wsdl:input>
				<wsoap12:body use="literal" parts="parameters" />
				<wsoap12:header message="serv:getMsgSignChiffrRequest"
					part="CA_groupHeader" use="literal" />
			</wsdl:input>
			<wsdl:output>
				<wsoap12:body use="literal" parts="parameters" />
			</wsdl:output>
		</wsdl:operation>
	</wsdl:binding>
	<wsdl:service name="POC1_service_sec">
		<wsdl:port name="Service_port_sec" binding=
         "serv:Service_binding_sec">
			<wsoap12:address location="http://localhost/
             POC1/Service_sec" />
		</wsdl:port>
	</wsdl:service>
</wsdl:definitions>
Listing 5. WSDL with signing policy used
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:serv="http://www.credit-agricole.fr/interop/POC1/"
	xmlns:xmime="http://www.w3.org/2005/05/xmlmime" 
    xmlns:ca_erreurs="http://referentiel.ca.fr/ErreursV1"
	xmlns:ca_header="http://referentiel.ca.fr/soapHeaderV1"
	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
     oasis-200401-wss-wssecurity-utility-1.0.xsd"
	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
	xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
    xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/
     optimizedmimeserialization"
	name="POC1" targetNamespace="http://www.credit-agricole.fr/interop/POC1/">
	<wsdl:types>
		<xsd:schema>
			<xsd:import schemaLocation="POC1.xsd"
				namespace="http://www.credit-agricole.fr/interop/POC1/" />
			<xsd:import schemaLocation="CA_Erreur.xsd"
				namespace="http://referentiel.ca.fr/ErreursV1" />
			<xsd:import schemaLocation="CA_groupHeader.xsd"
				namespace="http://referentiel.ca.fr/soapHeaderV1" />
		</xsd:schema>
	</wsdl:types>
	<wsdl:message name="getMsgSignChiffrRequest">
		<wsdl:part name="parameters" element=
         "serv:getMsgSignChiffrRequest"></wsdl:part>
		<wsdl:part name="CA_groupHeader" element=
         "ca_header:CA_groupHeader">
		</wsdl:part>
	</wsdl:message>
	<wsdl:message name="getMsgSignChiffrResponse">
		<wsdl:part name="parameters" element=
         "serv:getMsgSignChiffrResponse"></wsdl:part>
	</wsdl:message>
	<wsdl:portType name="Service_sec">
		<wsdl:operation name="getMsgSignChiffr">
			<wsdl:input message="serv:getMsgSignChiffrRequest" 
             name="getMsgSignChiffrRequest">
			</wsdl:input>
			<wsdl:output message="serv:getMsgSignChiffrResponse"
				name="getMsgSignChiffrResponse">
			</wsdl:output>
		</wsdl:operation>
	</wsdl:portType>
	<wsdl:binding name="Service_binding_sec" type="serv:Service_sec">
	<wsp:PolicyReference URI="#sign_chiffr_general_policy" />
		<wsoap12:binding style="document"
			transport="http://schemas.xmlsoap.org/soap/http" />
			<wsdl:operation name="getMsgSignChiffr">
			<wsoap12:operation
				soapAction="http://www.credit-agricole.fr/interop/
                 POC1/getMsgSignChiffr" />
			<wsdl:input>
				<wsoap12:body use="literal" parts="parameters" />
				<wsoap12:header message="serv:getMsgSignChiffrRequest"
					part="CA_groupHeader" use="literal" />
				<wsp:PolicyReference URI="#sign_policy" />
			</wsdl:input>
			<wsdl:output>
				<wsoap12:body use="literal" parts="parameters" />
				<wsp:PolicyReference URI="#sign_policy" />
			</wsdl:output>
		</wsdl:operation>
	</wsdl:binding>
	<wsdl:service name="POC1_service_sec">
		<wsdl:port name="Service_port_sec" binding=
         "serv:Service_binding_sec">
			<wsoap12:address location="http://localhost/POC1/
             Service_sec" />
		</wsdl:port>
	</wsdl:service>
</wsdl:definitions>
	<wsp:Policy wsu:Id="sign_policy">
		<wsp:ExactlyOne>
			<wsp:All>
				<sp:SignedParts
					xmlns:sp="http://docs.oasis-open.org/ws-sx/
                     ws-securitypolicy/200702">
					<sp:Body />
					<sp:Header Namespace="http://referentiel.ca.fr/
                     soapHeaderV1" />
				</sp:SignedParts>
			</wsp:All>
		</wsp:ExactlyOne>
	</wsp:Policy>
Listing 6. WSDL with signing and encryption policy used
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:serv="http://www.credit-agricole.fr/interop/POC1/"
	xmlns:xmime="http://www.w3.org/2005/05/xmlmime" 
    xmlns:ca_erreurs="http://referentiel.ca.fr/ErreursV1"
	xmlns:ca_header="http://referentiel.ca.fr/soapHeaderV1"
	xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
     oasis-200401-wss-wssecurity-utility-1.0.xsd"
	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
	xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
    xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"
	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/
     optimizedmimeserialization"
	name="POC1" targetNamespace="http://www.credit-agricole.fr/interop/POC1/">
	<wsdl:types>
		<xsd:schema>
			<xsd:import schemaLocation="POC1.xsd"
				namespace="http://www.credit-agricole.fr/interop/POC1/" />
			<xsd:import schemaLocation="CA_Erreur.xsd"
				namespace="http://referentiel.ca.fr/ErreursV1" />
			<xsd:import schemaLocation="CA_groupHeader.xsd"
				namespace="http://referentiel.ca.fr/soapHeaderV1" />
		</xsd:schema>
	</wsdl:types>
	<wsdl:message name="getMsgSignChiffrRequest">
		<wsdl:part name="parameters" 
         element="serv:getMsgSignChiffrRequest"></wsdl:part>
		<wsdl:part name="CA_groupHeader" 
         element="ca_header:CA_groupHeader">
		</wsdl:part>
	</wsdl:message>
	<wsdl:message name="getMsgSignChiffrResponse">
		<wsdl:part name="parameters" 
          element="serv:getMsgSignChiffrResponse"></wsdl:part>
	</wsdl:message>
	<wsdl:portType name="Service_sec">
		<wsdl:operation name="getMsgSignChiffr">
			<wsdl:input message="serv:getMsgSignChiffrRequest" 
             name="getMsgSignChiffrRequest">
			</wsdl:input>
			<wsdl:output message="serv:getMsgSignChiffrResponse"
				name="getMsgSignChiffrResponse">
			</wsdl:output>
		</wsdl:operation>
	</wsdl:portType>
	<wsdl:binding name="Service_binding_sec" type="serv:Service_sec">
	<wsp:PolicyReference URI="#sign_chiffr_general_policy" />
		<wsoap12:binding style="document"
			transport="http://schemas.xmlsoap.org/soap/http" />
			<wsdl:operation name="getMsgSignChiffr">
			<wsoap12:operation
				soapAction="http://www.credit-agricole.fr/interop/
                 POC1/getMsgSignChiffr" />
			<wsdl:input>
				<wsoap12:body use="literal" parts="parameters" />
				<wsoap12:header message="serv:getMsgSignChiffrRequest"
					part="CA_groupHeader" use="literal" />
				<wsp:PolicyReference URI="#sign_chiffr_policy" />
			</wsdl:input>
			<wsdl:output>
				<wsoap12:body use="literal" parts="parameters" />
				<wsp:PolicyReference URI="#sign_chiffr_policy" />
			</wsdl:output>
		</wsdl:operation>
	</wsdl:binding>
	<wsdl:service name="POC1_service_sec">
		<wsdl:port name="Service_port_sec" 
          binding="serv:Service_binding_sec">
			<wsoap12:address location="http://localhost/POC1/
             Service_sec" />
		</wsdl:port>
	</wsdl:service>
</wsdl:definitions>
		<wsp:Policy wsu:Id="sign_chiffr_policy">
		<wsp:ExactlyOne>
			<wsp:All>
				<sp:SignedParts
					xmlns:sp="http://docs.oasis-open.org/ws-sx/
                     ws-securitypolicy/200702">
					<sp:Body />
					<sp:Header Namespace="http://referentiel.ca.fr/
                     soapHeaderV1" />
				</sp:SignedParts>
				<sp:EncryptedParts
					xmlns:sp="http://docs.oasis-open.org/ws-sx/
                     ws-securitypolicy/200702">
					<sp:Body />
					<sp:Header Namespace="http://referentiel.ca.fr/
                     soapHeaderV1" />
				</sp:EncryptedParts>
			</wsp:All>
		</wsp:ExactlyOne>
	</wsp:Policy>

DataPower support for WS-Policy

DataPower SOA Appliances support the interpretation of WS-Policy statements, and more specifically the WS-SecurityPolicy statements. You can embed policies in the WSDL files or attach them as one file or several policy files. In this article, the policies are embedded in WSDLs. Note that DataPower comes with a set of generic policies that are stored in the store, policies, and templates files system directory.

In terms of configuration, the first parameter to set is the enforcement mode that the webservice proxy has to use to apply policies to incoming messages. The Policy tab of the webservice proxy shows a WS-Policy section, as shown in Figure 5.

Figure 5. WS-Policy Framework
WS-Policy Framework

This section contains two major parameters: enforcement mode and policy parameter set, as shown in Figure 6.

Enforcement mode

"Filter" tells the appliance to reject any message that is not compliant to the defined WS-Policy. This will apply to request and response messages. It will be the case for requests and responses.

"Enforce" (see Figure 6) tells the appliance to enhance the security level of messages to fit the WS-Policy requirements. This works for response flows only. For the request flows, it is equivalent to the "Filter" mode.

Figure 6. WS-Policy Framework
WS-Policy Framework

As a summary, Table 3 shows the behavior of the DataPower SOA Appliances for the enforcement mode.

Table 3. DataPower behavior for enforcement mode
DataPower behavior if mode is set to "filter"DataPower behavior if mode is set to "enforce"
Signing requirement Rejects any message (both request and response) which is not signed. No verification is performed on the request message. Rejects any request if it is not signed. Verify the signature on the request message to make sure it conforms to the policy
Performs the signing on responses (using the "policy parameter set" object)
Encryption requirement Rejects any message (both request and response) which is not encrypted. No decryption is performed (* WSP will perform a decryption if the s:Body is encrypted before the request is dispatched to the operation, however this is done outside the policy framework) Rejects any request not encrypted, and decrypt the request message if necessary. Performs the encryption on responses (using the "policy parameter set" object)

You can see that the appliance supports automatic policy enforcement on responses (meaning that the developer has no configuration to set on the appliance). However, everything has to be set manually for the requests. The appliance does not sign and encrypt a request to match a remote service provider's policies requirement.


Policy parameter set

The policy parameter provides additional information to permit the WS-Policy framework on the appliance to perform some necessary actions to meet the policy requirement. A policy parameter set regroups the configuration items in the domains (in our case, the XML Namespace Document for WS-Security Policy 1.2) as we are working with the WS-SecurityPolicy 1.2 specifications.

Figure 7. Policy parameter set
Policy parameter set

In our scenarios, we are using the policy parameter set to configure the behavior of the WSPolicy framework in the policy enforcement when processing responses. On the provider appliance, we are letting DataPower auto-generate the response rules as it eliminates the manual process of creating processing rules with the corresponding crypto actions. Here are the parameters we can set, based on Figure 7.

  • Signing Key: When the SOAP response has a signing requirement defined in the WS-Policies, this parameter tells the framework which key to use to perform the sign action.
  • Signing Certificate: When the SOAP response has a signing requirement defined in the WS-Policies, this parameter tells the framework which public certificate to include in the response message.
  • DataPower Specific Features: The policy parameter use-dynamic-enccert present in the DataPower specific features section of the policy parameters tells the appliance that, for the reponse flow encryption, it needs to use the certificate included in requests. It works when the request was signed and was providing an embedded certificate.

Table 4 lists the behavior of the DataPower SOA appliance regarding the WS-Policy framework.

Table 4. Behavior of DataPower regarding the WS-Policy framework
Consuming applianceProviding appliance
Signature creation Manual for requests Enforce (auto) on responses (policy parameter set)
Signature check Auto on responses Enforce (auto) on requests
Encryption Manual for requests Enforce (auto) on responses
(policy parameter set)
Decryption Manual for responses Auto when valcred has been defined

Using validation credentials for message decryption

Validation credentials are crypto objects created on the appliance and configured by specifying one or more public certificates. They are typically used when setting up SSL connections so that an appliance playing the server role validates the presented identity by a connection client.

However, there is another use for those validation credentials in the scenarios that we are setting up: decryption of the requests received by a WS-Policy enabled web service proxy.

When a receiving web service proxy exposes WSDL containing encryption assertions, especially when the encryption concerns at least the whole SOAP message body, the appliance has to decrypt the request before processing it (for example, extract the SOAP operation, select the matching rule to apply, and so on). To do this, one method is to specify a decryption key in the web service proxy settings as shown in Figure 8.

Figure 8. Decryption key
Decryption key

However, we do not recommend this method. The best practice here is to create an identity credential object pointing to the related certificate and key pair that will be used for the decryption. No direct reference is created between the web service proxy and the identity credential object. The identity credential object has to exist in the current domain.

Note: The two-way SSL configuration is not described here as this is not the topic of this article.


Conclusion

The first part of this 3-part article series described general configuration settings and scenarios. It described a topology that was used in a proof of concept and showed the configuration of DataPower SOA appliances you can apply to WS-SecurityPolicy for policy enforcement, message signature, and encryption. The information given serves as the basis for the next two parts of the article series:

  • Part 2 describes the DataPower configuration necessary to run the first scenario: a service consumer and a service provider are applying message integrity while the DataPower appliances are applying privacy with a message encryption.
  • Part 3 describes the DataPower configuration necessary to run the second scenario: a service consumer and a service provider are not applying any security on the message, whereas the DataPower appliances are applying privacy with a message encryption and integrity with a message signature.

Acknowledgments

The author would like to thank to Shiu-Fun Poon and Joel Gauci for their help with the Proof of Concept that evolved in the creation of this article series.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=945501
ArticleTitle=Securing web service message flows using WebSphere DataPower, Part 1: Configuring the DataPower settings
publish-date=09182013