Securing web service message flows using WebSphere DataPower, Part 3: Exchanging messages

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. The last part of this article series, Part 3, dives into the encryption and signature part of the security policy and explains how to configure the appliance to enforce and filter encryption and signature requirements.

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 third 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 is relatively simple: it consists of a service consumer that consumes services exposed by a service provider.

To set the base for the security flow, the service consumer consumes through a DataPower appliance positioned at the edge of the network. 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 for an acceptable level of security.

Part 1 of the series describes 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 designed to serve as a gateway for web services exposition and consumption.

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

This article, Part 3, explains 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:


Scenario 2: Enforcing confidentiality, integrity, and non-repudiation

In Figure 1, the consuming and providing frameworks will handle the signing of messages. DataPower SOA appliances will apply encryption to the exchanged messages and will handle the decryption before delivering it to the service provider. The appliances will ensure the enforcement and will ensure the policies are applied correctly.

Figure 1. Scenario 2 overview
Scenario 2 overview

Roles and responsibilities of each actor

Table 1 shows the responsibilities of each actor in the processing flow.

Table 1. Actor's roles and responsibilities
ActorRole
Service consumer This consumes a service exposed by the service provider. The web service operation is getMsgSignChiffr(). The consumer is not applying any security on the message. The consumer appliance that exposes the service seen by the service consumer does not embed any WS-Policy requirements.
DataPower consumer appliance This serves as a gateway for the service consumer. It exposes the same WSDL than the service provider. That is, a WSDL free of WS policies. However, in its processing instructions, it will sign and encrypt the messages to satisfy the WS-Policy requirements required by the provider appliance.
DataPower provider appliance This serves as a reverse gateway for the service provider. It exposes a WSDL with the "highest" level of security. It will reject incoming messages that are not correctly signed and encrypted. It will also ensure applying security to the responses coming for the service provider because it is not aware of WS-Policy. This will be performed by the "enforce" policy mode specified at the WSDL level.
Service provider This provides a service. In this scenario, it serves the getMsgSignChiffr() operation. No WS-Policy requirements are present in that the WSDL and messages requests and responses are exchanged with no security.

WSDLs used

Two WSDL files will be used in this scenario. They are referred to in the WSDL section at the beginning of this article. The consuming appliance and the service provider will expose the WSDL clean of any WS-Policy definition. The providing appliance will expose the WSDL with all the security requirements


DataPower appliances configuration

This section describes the configuration of the appliances on the consumer side and on the provider side.

Consumer appliance configuration

This section describes the configuration of the consumer appliance. We will describe the configuration of the wsp_casa_cons WebService proxy. Figure 2 shows a web service proxy with a static backend pointing to the provider appliance. In our example, the provider appliance is simulated locally on a separate application domain.

Figure 2. Web Service Proxy consumer
Web Service Proxy consumer

WS-Policy enforcement mode

The WS-Policy enforcement mode is set to "filter" at the WSDL level, as shown in Figure 3.

Figure 3. WS-Policy enforcement mode
WS-Policy enforcement mode

The appliance rejects any requests that are not conforming with the WS policy. In our case, any request that was not signed by the service consumer or that does not contain a non-matching signature will be rejected.

The web service proxy has the rules shown in Figure 4, which are described in Table 2.

Figure 4. Web service proxy processing rules
Web service proxy processing rules
Table 2. Processing rules
RuleDirectionDescription
_ruleChiffr Client > Server This rule matches the requests concerning the getMsgSignChiffr webservice operation. The rule signs, then encrypts the message header and body, so that at the end of the processing rule, you get a signed and encrypted request to be forwarded to the provider appliance.
_response-rule Server > Client This response rule matches the response of the getMsgSignChiffr webservice operation. It decrypts the response, as the response decryption is not performed automatically by DataPower. It also applies a few XSL transformations to clean the response message. The signature and encryption leaves some WS-Security headers and signature values that are not automatically stripped out.

Figure 5 shows the processing rules that apply to the requests, which are described in Table 3.

Figure 5. Rule 1
Rule 1
Table 3. Actions defined in Rule 1
ActionTypeParametersDescription
Match icon Match Xpath matching the getMsgSignChiffr webservice operation. This matches the right web service operation.
Validate+transform icon Validate+transform The validation and logging action is performed for the business need of the POC.
Sign icon Sign See below This action signs the SOAP message header and body.
Encrypt icon Encrypt The configuration is described in Scenario 2. This action encrypts the SOAP message header and body.

For the sign action to comply to the WS-Policy requirements of the provider appliance, the configurations to apply are shown in Figures 6 to 8.

Figure 6. Signing configuration (Screen 1 of 3)
Signing configuration (Screen 1 of 3)
Figure 7. Signing configuration (Screen 2 of 3)
Signing configuration (Screen 2 of 3)

In Figure 8, the used cryptomap object specifies the header and body of the request.

Figure 8. Signing configuration (Screen 3 of 3)
Signing configuration (Screen 3 of 3)

Specifying the certificate in the sign action makes the appliance include the signer public certificate in the message, thus avoiding any extra certificate deployment on the remote appliance.

The Wsp_casa_cons_noWSS_default response rule is shown in Figure 9 and described in Table 4.

Figure 9. Response rule
Response rule
Table 4. Actions defined in the response rule
ActionTypeParametersDescription
Match icon Match Xpath matching the getMsgSignChiffr web service operation This matches the right web service operation.
Decrypt icon Decrypt The incoming message arrives encrypted in response to the HTTP connection. Decryption is not performed automatically by the appliance.
Transformation icon Transformation Store://strip-wssec-signature.xsl This stylesheet removes the signature from the message.
Transformation icon Transformation Store://strip-security-header.xsl This stylesheet removes the WSSecurity headers from the message.
Transformation icon Transformation This stylesheet removes the wsu:id attributes from the message added by the WS framework. The presence of this attribute will make the XML validation fail.

At the policy level, the schema validation of response messages has been deactivated, as shown in Figure 10. This is because the incoming response message contains signing and encryption specific XML items that have to be removed if you want the XML validation to be successful.

Figure 10. Disable response validation
Disable response validation

Provider appliance configuration

Figure 11 shows a web service proxy with a static backend pointing to the provider appliance. In our example, the provider appliance is simulated locally on a separate application domain.

WebService proxy wsp_casa_four

This section describes the configuration of the wsp_casa_four WebService proxy.

Figure 11. Web Service Proxy provider
Web Service Proxy provider

WS-Policy enforcement mode

The WS-Policy enforcement mode is set to "enforce" at the WSDL level to reject any requests that do not comply to the policy requirements. Figure 12 shows the configuration of the enforcement mode and the policy parameter set.

Figure 12. WS-Policy enforcement mode
WS-Policy enforcement mode

The web service proxy has the rules defined in Figure 13, which are described in Table 5.

Figure 13. Processing rules
Processing rules
Table 5. Description of the processing rules
RuleDirectionDescription
_request-rule Client > Server This rule matches the requests concerning getMsgSignChiffr Web service operation. The rule will perform cleanup of the request (strip headers, attributes, signatures) and perform some other actions of of scope here (SLM, validation, routing)
_response-rule Server > Client This response rule matches the response of getMsgSignChiffr Websservice operation. No action are configured on this rule as the policy enforcement is performed by the framework.

wsp_default_request-rule

Figure 14 shows the default request rule, which is described in Table 6.

Figure 14. Request rule
Request rule
Table 6. Actions defined in Rule 1
ActionTypeParametersDescription
Match icon Match Xpath matching the getMsgSignChiffr webservice operation. This matches the right web service operation.
Transformation icon Transformation Store://strip-wssec-signature.xsl This stylesheet removes the signature from the message.
Transformation icon Transformation Store://strip-security-header.xsl This stylesheet removes the WSSecurity headers from the message.
Transformation icon Transformation This stylesheet removes the wsu:id attributes from the message (added by the WS framework). The presence of this attribute will make the XML validation fail.
Call Rule Call Rule This performs some specific actions that are out of scope here.

Demonstrating the execution flow

In this section, using soapUI and the debug probes, we will describe how the messages flow and get modified from the service consumer to the service provider.

  1. Listing 1 shows the request submitted by the service consumer. The message does not contain any WS-Security information.
    Listing 1. Request message submitted by the service consumer
    <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
     xmlns:soap1="http://referentiel.ca.fr/soapHeaderV1" 
     xmlns:poc1="http://www.credit-agricole.fr/interop/POC1/">
       <soap:Header>
            <m:CA_groupHeader IDPortail="" Reseau="" Terminal="" 
             idSessionPortail="" IDPOFO="abcdefghij" IDPTVE="" IDELSTCO="" 
             NMAPPU="" IDOCAP="" TYPRME="" IDOCPM="" NUMCRT="12345" 
             NUMCRE="12345" xmlns:m="http://referentiel.ca.fr/soapHeaderV1">
             <m:Consumer nomApplication="" version="1"/>
             <m:userInformation userType="01" userId="" userEntity="12345" 
              userProfile="" userIsVIP="N" lastName="" givenName=""/>
          </m:CA_groupHeader>
       </soap:Header>
       <soap:Body>
          <poc1:getMsgSignChiffrRequest>
             <poc1:numCompte>10255</poc1:numCompte>
          </poc1:getMsgSignChiffrRequest>
       </soap:Body>
    </soap:Envelope>
  2. Listing 2 shows the request after security enforcement by the consumer appliance. You can see the encrypted value included in the message, which is as long as the signature. This was performed by the processing rule by the request of the consuming appliance.
    Listing 2. Request message as output by the consumer appliance
    <soap:Envelope xmlns:poc1="http://www.credit-agricole.fr/interop/POC1/" 
     xmlns:soap1="http://referentiel.ca.fr/soapHeaderV1" 
     xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Header>
          <xenc:EncryptedData Id="G0xb90c90b0-5D" Type="http://www.w3.org/
           2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
             <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
              xmlenc#aes256-cbc"/>
             <xenc:CipherData>
                <xenc:CipherValue>RwxiyK8BS5iuD5DN6FtxAIjEBljBB86Zy5/l9NwY/
                  qdu9Prog/DCM+XwhKmlDLqjKFCPWAPDkFk0svVROfmIN3lVhAqUOARceGukEc4IvM+
                  FTUKKJnbbpYMbkMtGB8jSpacQHhxiLHskj9U2Fljtd9turTH2Dl087Z7uGBvWIGdA48
                  xhcwmH59R510/fvksxYwS5PWR5cZpnqKJkScSzbZn1Eqn8Gp6m3Tmy7F83VK3zuBW8
                  CrHhLVn3FekUDVRjjdmkskSporIgz07P54oAW/XBgHcRZQXFgxJWuy17QASPmcc3Uw
                  X1AT524ha68gU9dQZBuXPnHSOg2kNaJZSdld5lz1C17/LEFv5prqrPkuleCLysVhu5Zl
                  mdNwrYUMGNHY3whaSvEMs0euROLVS3E0H071zBB5xLsQYK/gaUp3jLLfJTBHARvBWUe
                  44iAt6VMLbgPPuakF2ZzMzAuIdpCa3OWOhzT5KxZCQLVWAX9oNCdmjE40DFH8qeHX1E4
                  eBVUIlCgkhAAaOFNRKGElnoqXeddeGg9Gq6eCQ1cXye6hgMmt5cXyRYWGNVOEsFF92E4
                  uI9YA4SebLKMHUOCP8E9oYRsF0Qb7ys9V0+65nUEow/rIOyAft6/YBz1DDxjAYMuwKaE
                  RY7FgyeVP/9a7USgg5B8QPDbn6EyMk5szsIVuSl0UE/g08sYRo+yDw9XST7AGFT02L2VK+
                  a8CqFTxndiIkGBXf4tAIqJTE1/RyCQMkSFizDuIZqEG/X6YjhN2nFi5oynhF9BTjsVmsgg
                  VaAt5FzpVkn4U/Bn6GWFXspb8VqSqOUN3ig4JEV/R/6TEjlxWaHkNa2pZOkHegE8u4/
                  bqYu/L3EdobPllpW0FduCMs02rTrgShez3w1yUQa5aEWuFJm5K61yGRz1rzmfEy+1UsXbY
                  D58PXan0wFH4rgM6eOjKOhWQs222SIgEO2yRxITRJf/26U/idIQIWmA+GAADtKVOntAlG3
                  W1XeKBS2bgQl5KFR/2K0fHVEgcR4ZaA/Q+qhBKBIk59aJOI7ADg6HnMTtd9A2aXK0IXZdV
                  DF4hmUjuem1PLTlPeOjHumjf34</xenc:CipherValue>
             </xenc:CipherData>
          </xenc:EncryptedData>
          <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/
           wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
             <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
                 xmlenc#rsa-oaep-mgf1p" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/
                    xmldsig#sha1"/>
                </xenc:EncryptionMethod>
                <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <wsse:SecurityTokenReference>
                      <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/
                       2004/01/oasis-200401-wss-x509-token-profile-1.0#X509Subject
                       KeyIdentifier" EncodingType="http://docs.oasis-open.org/wss/2004/
                       01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                       >2U7VibA3eDNHoMltReOjaWmu8tI=</wsse:KeyIdentifier>
                   </wsse:SecurityTokenReference>
                </dsig:KeyInfo>
                <xenc:CipherData xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <xenc:CipherValue>BZ3EigIOkGfxadN7+sg/sI8Am9X5RdSRtJPZMJz4LXQxRPhV
                    vlhPOpGnEEo1v6kT/RVuxmPrnCGVcY7zyUn1W2zdRtvN5INfSRBMiAuLqEnEybcCCPE4
                    ZI4wK+iSOc0GKwIG7MIf6vAsf5FbH1ixx3ZAQY/LbSqy2wWWtTsFvmnCHE8jJ9N+R86Fc
                    EC+XvcpH863LUEAqnZ1m3VaC3sHHOucZMcsq+/7vtRyy7aXsY9aTycab5oPTfL5My5dpD
                    PfjBARGZ3I7WfItMEsyqV43tlAlqxploTYhK6A1yO5ghVy2cAreisVThdojOwypM5YEfC
                    plrcCcWE73JvrwLIN8Q==</xenc:CipherValue>
                </xenc:CipherData>
                <xenc:ReferenceList>
                   <xenc:DataReference URI="#G0xb90c90b0-5D"/>
                </xenc:ReferenceList>
             </xenc:EncryptedKey>
             <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
                 xmlenc#rsa-oaep-mgf1p" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/
                    xmldsig#sha1"/>
                </xenc:EncryptionMethod>
                <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <wsse:SecurityTokenReference>
                      <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/
                       01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKey
                       Identifier" EncodingType="http://docs.oasis-open.org/wss/2004/01/
                       oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                       >2U7VibA3eDNHoMltReOjaWmu8tI=</wsse:KeyIdentifier>
                   </wsse:SecurityTokenReference>
                </dsig:KeyInfo>
                <xenc:CipherData xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <xenc:CipherValue>Td0zy8uuQgxmM7BAkG/GWCDZ/0CQJp+gmGpNSE2q1R2mKWK
                    jlKSGebwbcUNgNd3HanJbSgHboVy6iyZT+kpJh6C0yDro0UhaEAN0uZycNhCciuc4+
                    JOn3NUJRYDJP/tQ2LCXEQrmMBYKl83SGAhFt8fRbiAdbW7WlCKQPBR2uC22cjrHQ0J
                    gyKBXH1KbLbjUZ6bQw9yHfVrJP8g9fqieoCBrPZc054sta+mYvwCDgTgUyQvugVpEA
                    U2M7tpeSdDvhwZOW7cBkM++8iUO2cgcGtjfxxRVme50byob2tPXapc68ql7WaY5Rt0/
                    9eLKVycd6YL/gQazWAo22VyB9C6goA==</xenc:CipherValue>
                </xenc:CipherData>
                <xenc:ReferenceList>
                   <xenc:DataReference URI="#G0xb6feeb38-72D"/>
                </xenc:ReferenceList>
             </xenc:EncryptedKey>
             <wsu:Timestamp wsu:Id="Timestamp-d9971f40-ccf3-4609-9fb6-9de5cb4da313" 
              xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
              wssecurity-utility-1.0.xsd">
                <wsu:Created>2013-07-01T14:54:44Z</wsu:Created>
                <wsu:Expires>2013-07-01T14:59:44Z</wsu:Expires>
             </wsu:Timestamp>
    <wsse:BinarySecurityToken wsu:Id="SecurityToken-1373e0a9-2669-4ced-b924-d32109f0c
     43a" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
     message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/
     01/oasis-200401-wss-x509-token-profile-1.0#X509v3" xmlns:wsu="http://docs.oasis
     -open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIIDLDCCAh
     SgAwIBAgIIVuY+cZ/zyf0wDQYJKoZIhvcNAQELBQAwIjEgMB4GA1UEAwwXQUMgRW50aXTDqSBDb25zb21
     tYXRldXIwHhcNMTIxMTI4MjIyODI0WhcNMTUxMTI4MjIyODI0WjAoMSYwJAYDVQQDDB1TaWduQ2hpZmZy
     IERQVyAtIGNvbnNvbW1hdGV1cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYAXrCMCnEb
     WPS95ERb91pYSozs8Rj0n1rBqEIrllsmb5+rB5bGaKE+UIJs2xHtmZLm+yTumun5cPLhsQMrr6LsqaO0J
     6sOM0DUn+MrrGPRZy2gZSEaNwWsx0kwh2t+xlo4yiL8ioAKA+Q5B0BcAw6KlJoSmzUljuMP73sLFsatbT
     6hfNPB4x6uSHYfCB3wmvKnKmgmrF9Ipz/C6Dput8DG6+VPjWdY3fLktrY8areqMZDpmQW9hae/qP1heXO
     HChKRTyNs9kou60uCZ+i+R0bxgQvNZC9Mr2Sc9oR2AiEGVtgV724QWUoKKSJw0unRTYUQvd4oL3ywscg6
     6M2SBLMCAwEAAaNgMF4wHQYDVR0OBBYEFPfyrUQgGcW4m/PQhsah6ZODSwU1MAwGA1UdEwEB/wQCMAAwH
     wYDVR0jBBgwFoAUeg0LmyL6h6/7yAZMQ+f8li2/cQkwDgYDVR0PAQH/BAQDAgRQMA0GCSqGSIb3DQEBCw
     UAA4IBAQBrHta4DWju/PTC+9PbDSff0qlIUqux4Bbs0BKI4pYLbKLzsidyGZ8IShVX1nDoS4YXRdx/Z1cL
     086yCtv2WrjNyqkiH50zdhn8O7pvAuc9PPtH+USql0C4tu9z3BMzqMsaEVJSJQCKJiPfgihX5jsAm1Pup+
     BJFELBfKvPL9ab3/9PNttMJaOkyWc/7lPzbfnNp4H+8ANUAvn18xEt/rj6JM1Xl+HS9cp/P5DUY5YxwvPX
     WtbFC6H1NxEQ/LkqvcWFOdwJQeG5eKst5Vi3N6cVdZ6pLzxCHwrAJDlRZXzQRCTDzhShvS483MT/E0+owv
     eY81Twsh4lED7ITf5Mxll1</wsse:BinarySecurityToken>
             <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
                <SignedInfo>
                   <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/ 
                    xml-exc-c14n#"/>
                   <SignatureMethod Algorithm="http://www.w3.org/2000/09/
                    xmldsig#rsa-sha1"/>
                   <Reference URI="#Id-5b1d0cc6-a462-4122-9b9f-195670097599">
                      <Transforms>
                         <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                      </Transforms>
                      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                      <DigestValue>/PBTFRLw1hExmpF9UY9IlevHv7zDFB78hinoRhEoFz4=</
                       DigestValue>
                   </Reference>
                   <Reference URI="#Id-9cd0197b-0118-4125-98b6-b01a361691bb">
                      <Transforms>
                         <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                      </Transforms>
                      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                      <DigestValue>U6QX+Ph+GxAq9QEdPzB4QGwydb04nTPhdjnhoSCDXLk=</
                       DigestValue>
                   </Reference>
                   <Reference URI="#Timestamp-d9971f40-ccf3-4609-9fb6-9de5cb4da313">
                      <Transforms>
                         <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                      </Transforms>
                      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                      <DigestValue>xyT4D43gjBpE7eB2s08g8zglJHDKiA2IR96nYOD/uWU=</
                       DigestValue>
                   </Reference>
                </SignedInfo>
                <SignatureValue>hluEewlY4TJM5BhMicGi65ngnhkDuah6456yaDp2x7emtMD+scW+
                 wH6lEZxsb2w51+AjQtqXG7W4cjz9fnkfDCGlfcQ89R7YDLkyCg0mh2M0vE0czYrzz820pcru
                 VMdNsVS63GKvAaadCfNhUHcUZ4KK7txQmbcJmTlwnf2KcEELlJ4xkNI4uFOZmgQ9MUK42uVD
                 mB7PWbcRCwwtdmLT/sYE1rRXHPe1R9FnROMvWvUHZhzBzhLXcYW8xiw5oltE7UaurZ8+BlGi
                 05zf8v5I3P4aqssJQGS9hZ0NGtGIsCIEsBB+xzpLhrgk78m/AO+1OGpCzkn/h5ICn5wzf1V5
                 oQ==
                 </SignatureValue>
                <KeyInfo>
                   <wsse:SecurityTokenReference xmlns="">
                      <wsse:Reference URI="#SecurityToken-1373e0a9-2669-4ced-b924-
                       d32109f0c43a" ValueType="http://docs.oasis-open.org/wss/2004/01/
                       oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
                   </wsse:SecurityTokenReference>
                </KeyInfo>
             </Signature>
          </wsse:Security>
       </soap:Header>
       <soap:Body wsu:Id="Id-9cd0197b-0118-4125-98b6-b01a361691bb" xmlns:wsu=
        "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
        utility-1.0.xsd">
          <xenc:EncryptedData Id="G0xb6feeb38-72D" Type="http://www.w3.org/2001/
           04/xmlenc#Content" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
             <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
              xmlenc#aes256-cbc"/>
             <xenc:CipherData>
                <xenc:CipherValue>pxWJ5GsuX5Vh5WaBP0WP+8kUflmu2YBtkUtAgin0lF
                 wO80RcPFWrKtGrybaR27ss4a7zi83f2RS/53FT7d0P394Sg8NDbZDER2JeTZt/
                 ZUSzzcDkmATdjbZcntg6whQMJAZcAqP5XHT+7bxFIWbDl0JPTM9x6O0Go5UXoaVst
                 GJfx+n/FtmsbyLtXG+pBG5MY6hcoVQheZ6bK8hv1SmaSoGEqHPWSzYycxKmnQEZ/+/
                 sptojDXwaRZwpU+iqwfRbYxpZdDufItP45CzUzDUGGWMdmpn2HuyiBu/qJNxLCDPhn
                 bNrFm2o3/T0duZ2FvxDENvPOvutKTLG3pukoaamyqjlX8Vzl3IRqsgvHPmdFGAAfOP
                 9s0e97LvNFUxi0YlHM9O+e7gP18r/qgI000xqnlyBHe2DKzJGOBxANPoA16/FNI1oPZ
                 NofCpbhWMY2TFko75IDs1y7NpmkDRouv+4d53HpErIhF+IP7Qatc2kzIQUG8s+W444S
                 NnKtUWjmZVVU0WKQhROj/5KL+rUMj0kYvbecjayczz44u/33u5fTYI=</
                 xenc:CipherValue>
             </xenc:CipherData>
          </xenc:EncryptedData>
       </soap:Body>
    </soap:Envelope>
  3. Listing 3 shows the response message as submitted by the service provider. This response message has been signed and encrypted by the WS Policy framework of the providing appliance by the enforce mode.
    Listing 3. Response message as submitted by the service provider
    <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
     xmlns:ca_erreurs="http://referentiel.ca.fr/ErreursV1">
       <soap:Header/>
       <soap:Body>
          <poc1:getMsgSignChiffrResponse xmlns:poc1=
           "http://www.credit-agricole.fr/interop/POC1/">
             <poc1:solde date_effet="2001-12-17T09:30:47Z" montant="3.14159E0"/>
          </poc1:getMsgSignChiffrResponse>
       </soap:Body>
    </soap:Envelope>
  4. Listing 4 shows the response message as output by the providing appliance. This response message has been signed and encrypted by the WS Policy framework of the providing appliance by the enforce mode.
    Listing 4. Response message as output by the providing appliance
    <soap:Envelope xmlns:ca_erreurs="http://referentiel.ca.fr/ErreursV1" 
     xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Header>
          <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/
          2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
             <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
                  xmlenc#rsa-oaep-mgf1p" 
                  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/
                    xmldsig#sha1"/>
                </xenc:EncryptionMethod>
                <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <wsse:SecurityTokenReference>
                      <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/
                       2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKey
                       Identifier" EncodingType="http://docs.oasis-open.org/wss/2004/01/
                       oasis-200401-wss-soap-message-security-1.0#Base64Binary">9/
                       KtRCAZxbib89CGxqHpk4NLBTU=</wsse:KeyIdentifier>
                   </wsse:SecurityTokenReference>
                </dsig:KeyInfo>
                <xenc:CipherData xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                   <xenc:CipherValue>eRcuspfGr6Bzmw8Tna1VQlYfMAewP9YcGR5Y/UjBURonyLwo
                    75K86VgVorQqbpWkjmp03eHecm6P1yEaSijM5e/Jx75JNhz4HWwCtJVfmkw5HMdJ+is396q
                    SIWTgzNJQ0qAwZPM+DJ4Upl5XYVplSvYVjbFI8d+E2wOtGoWHcaFhQb8ISUd5eyxNDRk+/
                    pPi5dHbawrn7r4nciNDsd7RButGhDr2GQFVnyCLj0woNh9OZn1UAmkndtMgfM5ixyBoiVx/
                    wsfDNc0eSGnhrJ9GyhhD3ifklfoebrixkxD4jQGwrhN6E/hNdXs8xbxKnwnUWADp1ZY+
                    o8FaiLkozt0cHw==</xenc:CipherValue>
                </xenc:CipherData>
                <xenc:ReferenceList>
                   <xenc:DataReference URI="#G0xb71b2d80-3fD"/>
                </xenc:ReferenceList>
             </xenc:EncryptedKey>
             <wsu:Timestamp wsu:Id="Timestamp-82973452-bd56-4f7c-a83b-1cea75765e9b" 
              xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
              oasis-200401-wss-wssecurity-utility-1.0.xsd">
                <wsu:Created>2013-07-01T14:54:45Z</wsu:Created>
                <wsu:Expires>2013-07-01T14:59:45Z</wsu:Expires>
             </wsu:Timestamp>
             <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
                <SignedInfo>
                   <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/
                    xml-exc-c14n#"/>
                   <SignatureMethod Algorithm="http://www.w3.org/2000/09/
                    xmldsig#rsa-sha1"/>
                   <Reference URI="#Id-ba5ab806-4de6-4ef7-9fbd-ab43056c23ff">
                      <Transforms>
                         <Transform Algorithm="http://www.w3.org/2001/10/
                          xml-exc-c14n#"/>
                      </Transforms>
                      <DigestMethod Algorithm="http://www.w3.org/2001/04/
                       xmlenc#sha256"/>
                      <DigestValue>yh0nCWPbRZ0tw2AyyGz0xryI0vFCwkAd1xa71F3DxfU=
                       </DigestValue>
                   </Reference>
                   <Reference URI="#Timestamp-82973452-bd56-4f7c-a83b-1cea75765e9b">
                      <Transforms>
                         <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                      </Transforms>
                      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                      <DigestValue>O7sIWPLINSS9006/6chtd1W65mupv/Rhwt0XaxwDskE=</
                       DigestValue>
                   </Reference>
                </SignedInfo>
                <SignatureValue>Y0GY7SYut/JcY1uA8b4+THJhhiy4zt3Ddl6YgHUOuacXZ9KQW8Iw
                 ZDyjxDR/eRWG8xtGyd0CTpMIwOAMN2BoSYwMws9Q2nWyPE+K/Zj2P8YgnWT2IdUhbjaj4ZJR
                 tRcB3SPRxcmN31Dg9PUvfbD4m9vOuIkPlAYPWGKyHzdZGdBqkTBiusjRzSuK1ZO4Tgq8kIlRtv/
                 1eG/fbU0tJH4MA3RP4NSpjKgIZ2kC45RjyxJyQ2Iq3LKOEgO07s2BFiPuV7SLQ/dLSyZDyw4D4
                 nEz1LzSDGr1pkZVbskPuEN9GVRFSt6jpP0UNQRsoFF/9h2F7EPcZP/AJ7OAWSBLG2h8rQ==
                 </SignatureValue>
                <KeyInfo>
                   <wsse:SecurityTokenReference xmlns="">
                      <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/
                       01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier" 
                       EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                       soap-message-security-1.0#Base64Binary">2U7VibA3eDNHoMltReOjaWmu8tI=
                       </wsse:KeyIdentifier>
                   </wsse:SecurityTokenReference>
                </KeyInfo>
             </Signature>
          </wsse:Security>
       </soap:Header>
       <soap:Body wsu:Id="Id-ba5ab806-4de6-4ef7-9fbd-ab43056c23ff" 
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
         wssecurity-utility-1.0.xsd">
          <xenc:EncryptedData Id="G0xb71b2d80-3fD" Type="http://www.w3.org/2001/
           04/xmlenc#Content" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
             <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/
              xmlenc#aes256-cbc"/>
             <xenc:CipherData>
                <xenc:CipherValue>P3TC5cL+dNDn8TEBoCxvAjyTB6Hhv+jMHqJkCduw
                 Uhm2aK1Ucxr9sjS6SiHBoTpoWWwsk8M4uUev8Ac4ZPiJbX3MINR8OCTlI2lJ/
                 lp/1hk8H02wOV+O+6dpWsIv5xFIxY5ID7RXeSlYyEOpB07DvASQ76PbIXXQYap
                 simsQVLi8DfyXup9HfsLEfJbXw6YNWQkt1NE94vQwKmP7fiSfGFCQ4q0a6HK4O
                 pDqJ7hDcL4efb4KSLQDxJppF5abcbStpxghgZ+8pkgCuWbCJlQVh4kNvk9n1Mn
                 YlasWtCsQizrDDcFHIWv1OEuUV5zsjFW1+qlZZMVqSnL5YoTUNiuDet3Pn/
                 qLI3l3QeffvGoh2Mms87ABK6nXVGNoBgr+wpAjgQHnszuBWK7lWUeC0aM++GB2Mn
                 CToprtYpGh7z8J9tNVPG6tyIu4GIzUxlHnk4XuCxF+Sd5W/cYFFUX6eBbj3Ko5ga
                 ojI9BCNFQleqZhPg0tfq+puZnH2ehAyBPkQPgazDyjXtWLSQn3jwTN7ygvuPwhyv
                 KhY0GdN5x3hGwyTLzUzrcsRE/umuTAKFfEpthm</xenc:CipherValue>
             </xenc:CipherData>
          </xenc:EncryptedData>
       </soap:Body>
    </soap:Envelope>
  5. Listing 5 shows the response message received by the service consumer. This message has been decrypted and the signature checked by the consuming appliance.
    Listing 5. Response message received by the service consumer
    <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
     xmlns:ca_erreurs="http://referentiel.ca.fr/ErreursV1">
       <soap:Header/>
       <soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
        oasis-200401-wss-wssecurity-utility-1.0.xsd">
          <poc1:getMsgSignChiffrResponse xmlns:poc1="http://www.credit-agricole.fr/
           interop/POC1/">
             <poc1:solde date_effet="2001-12-17T09:30:47Z" montant="3.14159E0"/>
          </poc1:getMsgSignChiffrResponse>
       </soap:Body>
    </soap:Envelope>

Conclusion

The third part of the article described how to configure DataPower SOA Appliances to implement a scenario involving two parties that are exchanging messages. Part 3 described the DataPower configuration necessary to run the first scenario described in Part 1. The service consumer and service provider are not applying any security measures on the message exchange, while the DataPower appliances are applying integrity and privacy with message signature encryption.

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. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. 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=945547
ArticleTitle=Securing web service message flows using WebSphere DataPower, Part 3: Exchanging messages
publish-date=09182013