The Web Services Security standard offers versatile means to protect the authenticity, integrity and confidentiality of SOAP messages. This post demonstrates some of the interesting capability for achieving security at a sub-message level granularity through the use of X.509 certificates.
We present a walkthrough of a simple scenario that can be implemented in IBM Integration Bus Version 10 Fix Pack 10, demonstrating a Web Services invocation in which part of the request message is signed and encrypted. The example is implemented as two message flows, a service consumer and a service provider, interconnected through a SOAP/HTTP interface. The consumer creates a request message, encrypts and signs the appropriate sections, then invokes the provider. The provider, in turn, receives and decrypts the message, verifies the signature, applies a trivial transformation to the message body, and sends an unsigned response to the consumer in cleartext. No transport level security is used to allow inspection of the SOAP/HTTP message interchange.
Details of the SOAP Request Message
The web service will use the following SOAP request message structure, and this is the message that would get passed from consumer to provider had we not been using WS-Security:

<?xml version="1.0" encoding="utf-8"?>
<NS1:Envelope xmlns:NS1="http://schemas.xmlsoap.org/soap/envelope/">
  <NS1:Body>
    <io:NewOperation xmlns:io="http://perf.ib.ibm.com/WSSecTestService/">
      <in>John Smith</in>
    </io:NewOperation>
  </NS1:Body>
</NS1:Envelope>

However, as we are encrypting and signing the request, the actual message sent will look very different, with roughly the following structure (simplified here for brevity):

<?xml version="1.0" encoding="utf-8"?>
<NS1:Envelope xmlns:NS1="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <wsse:Security [...]>
      <wsse:BinarySecurityToken [...]>
        [...]
      </wsse:BinarySecurityToken>
      <ds:Signature [...]>
        <ds:SignedInfo>
          [...]
          <ds:SignatureMethod [...] />
        </ds:SignedInfo>
        <ds:SignatureValue>[...]</ds:SignatureValue>
        <ds:KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference [...] />
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
      <enc:EncryptedKey [...]>
        <enc:EncryptionMethod [...] />
        <ds:KeyInfo [...]>
          <wsse:SecurityTokenReference>
            <wsse:KeyIdentifier [...]>[...]</wsse:KeyIdentifier>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
        <enc:CipherData>
          <enc:CipherValue>[...]</enc:CipherValue>
        </enc:CipherData>
        <enc:ReferenceList>
          <enc:DataReference [...] />
        </enc:ReferenceList>
      </enc:EncryptedKey>
    </wsse:Security>
  </soapenv:Header>
  <NS1:Body>
    <io:NewOperation xmlns:io="http://perf.ib.ibm.com/WSSecTestService/">
      <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
                         Id="wssecurity_encryption_id_20"
                         Type="http://www.w3.org/2001/04/xmlenc#Element">
        <enc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
        <enc:CipherData>
          <enc:CipherValue>[...]</enc:CipherValue>
        </enc:CipherData>
      </enc:EncryptedData>
    </io:NewOperation>
  </NS1:Body>
</NS1:Envelope>

Note the following security elements:

  • There is a ds:Signature element under wsse:Security in the SOAP header to hold the digital signature. Also note that the ds:KeyInfo element within ds:Signature contains a reference to the X.509 certificate that can be used to verify the signature (it is the certificate of the private key that was used to sign the message). This certificate is normally included in a wsse:BinarySecurityToken below the wsse:Security element.
  • The SOAP body includes the NewOperation element, but the in sub-element specified by the WSDL file (and included in the unencrypted request) is not present. However, an enc:EncryptedData element carries the payload in encrypted form. The element also contains a reference to the encryption algorithm (in our case the aes128-cbc symmetric key method). The enc:EncryptedKey element in the header includes the AES symmetric key encrypted with the recipient’s public key, as well as references under enc:ReferenceList to all the message parts that were encrypted using this symmetric key.
Getting Started
The following is a step-by-step guide to getting the web services invocation with WS-Security message part signing and encryption running in IBM Integration Bus Version 10 Fix Pack 10.

  1. Start the Integration Toolkit with a clean workspace, and create a new Integration Application called WSSecurityTest.
  2. Create a WSDL file in the WSSecurityTest application called WSSecTestService.wsdl, using http://perf.ib.ibm.com/WSSecTestService/ as the target namespace; in the wizard, enable Create WSDL skeleton and use SOAP as protocol. The result will have defined NewOperation with an xsd:string field called in, and NewOperationResponse with an xsd:string field called out. There should be 2 workspace errors that we are fixing in the next step.
  3. Create new message model: XML / SOAP XML
    • Select I already have WSDL for my data
    • Select the WSDL file created in the previous step, as well as the application in the first dropdown list
    • After the message model is created, the workspace errors should disappear.
Fig. 1.a: Service consumer message flow
Fig. 1.b: Service provider message flow
  1. Create a flow called consumer in the WSSecurityTest application, with the structure shown in Figure 1.a.
    • Apply the previously created WSDL file to the SOAP Request node, and set the Web service URL on the HTTP Transport panel to http://localhost:7800/.
    • Set the Path suffix for URL option on the Basic configuration panel of the HTTP Input node to /WSSecurityTest
    • Implement the following mapping from the BLOB message model on the input side to the SOAP_Domain_Msg model on the output side (both models are located under the IBM supplied message models folder in the Select map inputs and outputs panel of the New Message Map wizard), using SOAP as the output domain, by casting the SOAP_Domain_Msg/Body/any output element to the NewOperation type, then assigning an arbitrary string to the in element. Note that in this map, we are essentially discarding the input message received through HTTP, only making use of the fact that a message was received, and generating an appropriate SOAP message to be propagated to the provider flow.
      Fig. 2: Mapping procedure
  2. Create another flow called provider in the application, with the structure in Figure 1.b.
    • Apply the WSDL file to the SOAP Input node, and set the Path suffix for URL on the HTTP Transport panel to /.
    • Implement the following mapping in the SOAP_Domain_Msg message model on both the input and output side, using SOAP as the output domain, by casting the SOAP_Domain_Msg/Body/any input element to the NewOperation type and the counterpart at the same location on the output side to NewOperationResponse, then concatenating the input string with another arbitrary string, and assigning the result to the out element:
      Fig. 2: Mapping procedure
  3. Although WS Security has not been set up yet, the application can now be deployed to an integration server to make sure everything so far is in place.
    • Create a new Integration Node, or use the test environment automatically created by the Integration Toolkit.
    • Once the application is deployed, open a web browser on the host running the integration server, and request the http://localhost:7800/WSSecurityTest URL. IBM Integration Bus should return a response similar to the following. Note that this is not a well-formed SOAP message as we’re essentially capturing an internal representation of the SOAP response that came back from the provider flow over HTTP.

      <SOAP_Domain_Msg>
        <Context operation="NewOperation"
                 operationType="REQUEST_RESPONSE"
                 portType="WSSecTestService"
                 portTypeNamespace="http://perf.ib.ibm.com/WSSecTestService/"
                 port="WSSecTestServiceSOAP"
                 service="WSSecTestService"
                 fileName="WSSecTestService.wsdl">
          <SOAP_Version>1.1</SOAP_Version>
          <Namespace />
        </Context>
        <Header />
        <Body>
          <io:NewOperationResponse>
            <out>Hello John Smith!</out>
          </io:NewOperationResponse>
        </Body>
      </SOAP_Domain_Msg>

    • Change the Web service URL setting on the HTTP Transport configuration panel of the SOAP Request node in the consumer flow to http://localhost:7900/; save, then re-deploy the application. Use a TCP monitoring tool such as NetTool to intercept the consumerprovider message exchange by configuring a TCP tunnel listening on port 7900 and forwarding to 7800. If you now re-submit the request in the browser, you can observe the message exchange. Both the request and the response are sent in plaintext, without any signatures; the request message should match the example given near the top of this post, and the response should essentially contain the same information as the message shown in the browser, but in a well-formed SOAP message.
  4. Open the consumer flow in the WSSecurityTest application again, navigate to the WS Extensions tab of the SOAP Request node, and define a WS-Security entry with alias user_part and the following XPath Expression:
    /*[namespace-uri()=’http://schemas.xmlsoap.org/soap/envelope/’ and local-name()=’Envelope’]/*[namespace-uri()=’http://schemas.xmlsoap.org/soap/envelope/’ and local-name()=’Body’]/*[namespace-uri()=’http://perf.ib.ibm.com/WSSecTestService/’ and local-name()=’NewOperation’]/in
    • Open the provider flow, and select the SOAP Input node. On the WS Extensions tab, define a WS-Security entry with alias user_part and the same XPath expression as used in the SOAP Request node of the service consumer flow.
  5. Create a BAR file called wssecuritytest.bar, and include in it the WSSecurityTest application only.
    • Under the Manage tab of the BAR file editor, select the consumer.msgflow message flow, and navigate to the Configure panel of its Properties page. Set Consumer Policy Set to WSSecTestConsumerPolicySet, Consumer Policy Set Bindings to WSSecTestConsumerPolicySetBinding, and Security Profile Name to Default Propagation as follows:
      Fig. 3.a: Consumer flow configuration
    • Select the provider.msgflow message flow, and go to the Configure panel of the Properties page. Set Provider Policy Set to WSSecTestProviderPolicySet, Provider Policy Set Bindings to WSSecTestProviderPolicySetBinding, and Security Profile Name to Default Propagation as follows:
      Fig. 3.b: Provider flow configuration
  6. The project structure will have the following appearance in the Application Development view:
    Fig. 3: Project structure
  7. Create the Java keystore and truststore with the keys and certificates to be used for encryption and signing. For a more comprehensive explanation of generating keys, X.509 certificates, trust stores and key stores, see Creating an X.509-Based Public Key Infrastructure for Testing Integration Applications.
    • Use the Java keytool program to create a JKS key store called wssTestKeyStore.jks with a self-signed certificate and its respective private key:

      keytool -genkeypair -dname "cn=Geza Geleji, ou=MQESB, o=IBM, c=GB" -alias mykey -keypass P4s5w0rd -keystore wssTestKeyStore.jks -storepass P4s5w0rd -validity 7305 -keyalg RSA -keysize 1024 -sigalg SHA256withRSA

      keytool -list -keystore wssTestKeyStore.jks -storepass P4s5w0rd

    • The output of the last command should indicate that the key store contains a key entry called mykey.
    • Copy the certificate from mykey to mycert in the same key store, as well as to a separate JKS trust store called wssTestTrustStore.jks:

      keytool -exportcert -alias mykey -keystore wssTestKeyStore.jks -storepass P4s5w0rd -file temp.crt

      keytool -importcert -alias mycert -keystore wssTestKeyStore.jks -storepass P4s5w0rd -file temp.crt -noprompt

      keytool -importcert -alias mycert -keystore wssTestTrustStore.jks -storepass P4s5w0rd -file temp.crt -noprompt

      keytool -list -keystore wssTestKeyStore.jks -storepass P4s5w0rd

      keytool -list -keystore wssTestTrustStore.jks -storepass P4s5w0rd

      del /s /q temp.crt

    • The output of the keytool -list commands should indicate that the trust store contains one trusted certificate entry, mycert, whose fingerprint should match that of the corresponding key entry in the key store. The key store should now also contain the mycert trusted certificate entry, with a fingerprint identical to that of the mykey key entry.
  8. Run the following IIB administrative commands to install the newly created key store and trust store in IBM Integration Bus (update the NODE and SERVER environment variables as appropriate):

    set NODE=TESTNODE_jms

    set SERVER=default

    mqsistart %NODE%

    mqsichangeproperties %NODE% -e %SERVER% -o ComIbmJVMManager -n keystoreFile -v %CD%\wssTestKeyStore.jks

    mqsichangeproperties %NODE% -e %SERVER% -o ComIbmJVMManager -n keystorePass -v %SERVER%Keystore::password

    mqsichangeproperties %NODE% -e %SERVER% -o ComIbmJVMManager -n truststoreFile -v %CD%\wssTestTrustStore.jks

    mqsichangeproperties %NODE% -e %SERVER% -o ComIbmJVMManager -n truststorePass -v %SERVER%Truststore::password

    mqsistop %NODE%

    mqsisetdbparms %NODE% -n %SERVER%Keystore::password -u ignore -p P4s5w0rd

    mqsisetdbparms %NODE% -n %SERVER%Truststore::password -u ignore -p P4s5w0rd

    mqsistart %NODE%

  1. Create the Policy Sets and Policy Set Bindings required to support the security configuration in the Integration Node.
    • In the Integration Toolkit, open the Policy Set Editor by right-clicking on the Integration Node in the Integration Nodes view, and selecting Open Policy Sets from the pop-up menu.
    • Create a new policy set by selecting Policy Sets in the left-hand tree view, and clicking the Add button near the bottom left corner.
      • Select the new policy set and rename it to WSSecTestConsumerPolicySet.
      • Press the Add WS-Security button, and expand the newly created WS-Security subtree, then the Message Level Protection subtree under the new policy. Tick the Message level protection checkbox on the corresponding panel.
      • In the Asymmetric tokens section of the Tokens list item, add the following two tokens:
        Token Name Token Type WS-Security Version X.509 Type
        WSSTestX509SignToken Initiator 1.0 X.509 Version 3
        WSSTestX509EncryptToken Recipient 1.0 X.509 Version 3
      • Select the Basic128Sha256Rsa15 algorithm suite on the Algorithms panel.
      • On the Message Part Protection panel, define the following two names:
        Name Security Type SOAP Message Message Body
        WSSTestX509Sign Signature Request No
        WSSTestX509Encrypt Encryption Request No
      • Finally, on the Aliases panel, assign the following aliases to the names:
        Name Alias
        WSSTestX509Sign user_part
        WSSTestX509Encrypt user_part

        We will use these aliases to specify on the SOAP nodes the exact elements to be signed and encrypted.

    • Create another policy set called WSSecTestProviderPolicySet with an identical configuration.
    • Create a new policy set binding by selecting Policy Set Bindings in the left-hand tree view, and clicking the Add button.
      • Select the new policy set binding and rename it to WSSecTestConsumerPolicySetBinding.
      • Set WSSecTestConsumerPolicySet as the associated policy set of the new binding.
      • Set the option “This Policy Set Binding configuration will be used with:” to Consumer
      • Navigate to the Message Part Policy branch of the WS-Security subtree under the new policy set binding, and note the request:WSSTestX509Encrypt message part encryption policy as well as the request:WSSTestX509Sign message part signature policy listed therein. Configure them as follows:
        Encryption Protection Time­stamp Nonce Encryp­tion Token Token Type Order
        request:WSSTestX509Encrypt No No Data WSSTestX509EncryptToken KEYID 1
        Signature Protection Token Token Type Order
        request:WSSTestX509Sign WSSTestX509SignToken STRREF 1
      • Navigate to the Key Information panel, and define the following:
        Token Key Name Key Alias Trust
        WSSTestX509ESignToken cn=Geza Geleji, ou=MQESB, o=IBM, c=GB mykey N/A
        WSSTestX509EncryptToken cn=Geza Geleji, ou=MQESB, o=IBM, c=GB mycert N/A
      • Note that as the key aliases refer to entries in the key store, both the mykey private key, and the corresponding mycert certificate needs to be present in the key store.
    • Create another policy set binding called WSSecTestProviderPolicySetBinding, and
      • Set WSSecTestProviderPolicySet as the associated policy set of the new binding.
      • Set the option “This Policy Set Binding configuration will be used with:” to Provider
      • Navigate to the Message Part Policy branch of the WS-Security subtree under the new policy set binding, and note the request:WSSTestX509Encrypt message part encryption policy as well as the request:WSSTestX509Sign message part signature policy listed therein. Configure them as follows:
        Encryption Protection Time­stamp Nonce Encryp­tion Token Token Type Order
        request:WSSTestX509Encrypt No No Data WSSTestX509EncryptToken N/A N/A
        Signature Protection Token Token Type Order
        request:WSSTestX509Sign WSSTestX509SignToken N/A N/A
      • Navigate to the Key Information panel, and define the following:
        Token Key Name Key Alias Trust
        WSSTestX509ESignToken Any Any TrustStore
        WSSTestX509EncryptToken cn=Geza Geleji, ou=MQESB, o=IBM, c=GB mykey TrustAny
    • Hit the Finish button to save the configuration and close the editor.
  1. At this point, the wssecuritytest.bar file can be deployed to the integration server. Once deployed, its behavior can be verified by pointing a Web browser at http://localhost:7800/WSSecurityTest (or whatever URL the HTTP Input node is listening on). When everything is working correctly, IBM Integration Bus returns a response similar to the following.

    <SOAP_Domain_Msg>
      <Context operation="NewOperation"
               operationType="REQUEST_RESPONSE"
               portType="WSSecTestService"
               portTypeNamespace="http://perf.ib.ibm.com/WSSecTestService/"
               port="WSSecTestServiceSOAP"
               service="WSSecTestService"
               fileName="WSSecTestService.wsdl">
        <SOAP_Version>1.1</SOAP_Version>
        <Namespace />
        <_XmlDeclaration Version="1.0" Encoding="utf-8" />
      </Context>
      <Header />
      <Body>
        <io:NewOperationResponse>
          <out>Hello John Smith!</out>
        </io:NewOperationResponse>
      </Body>
    </SOAP_Domain_Msg>

  2. To verify that the structure of the SOAP request passed from the consumer to the provider is indeed as expected, you may intercept the SOAP interaction with a TCP monitoring tool such as NetTool.
    • Edit the BAR file, change the SOAP Request node in the consumer flow to send the SOAP request to http://localhost:7900/ instead of the original http://localhost:7800/, then save and re-deploy it.
    • Configure a TCP tunnel in NetTool, listening on port 7900 and forwarding to 7800.
    • Make the same request as before from a web browser, and inspect the intercepted request and response messages.
    • Note that both the request and the response are well-formed SOAP messages. The latter does not contain security features, as we have not configured any for the response. The security elements in the request message, however, should be similar to those presented near the beginning of this post.

17 comments on"Message Part Integrity and Confidentiality Using WS-Security with X.509 Certificates in IBM Integration Bus V10"

  1. Hi to all… I’ve found the problem:

    the XPath expression in the article use the character UNICODE 0x2019 instead of the ASCII 0x27 as single quotation mark:

    /*[namespace-uri()=’http://schemas.xmlsoap.org/soap/envelope/’ …

    copyng and pasting the text “as-is” causes the problem at deployment time.
    Fabrizio

  2. Hi Geza, I have the same problem with your example and with another application I developed.
    I am not able to understand wich step of the developement process generate the invalid char.
    Thank for your attention
    Fabrizio

  3. Hi,

    Thanks again for the blog. This example binds a specific signer certificate per request node, but is it possible to do security bindings dynamically in message flow?
    For example – Customer x sends a message and we add signature to that using Customer x’s certificate & send the signed request ahead. Customer y sends also message and we sign it using Customer y’s certificate. etc.
    I have tried to find sollution to the above but there is not much information available…

    • Hi Vesa,
      currently the signature and encryption key is determined by the policy set and the policy set binding, which are statically tied to the input node or the message flow. Please feel free to submit a Request for Enhancement if you need them to be dynamically assignable. Note that even with them being only statically configurable, it may still be possible to build solutions that use different policy sets and/or policy set bindings based on, e.g., message content.

  4. Hi again, I got it working now, the error must be somewhere in xpath
    /*[namespace-uri()=’http://schemas.xmlsoap.org/soap/envelope/’ and local-name()=’Envelope’]/*[namespace-uri()=’http://schemas.xmlsoap.org/soap/envelope/’ and local-name()=’Body’]/*[namespace-uri()=’http://perf.ib.ibm.com/WSSecTestService/’ and local-name()=’NewOperation’]/in

    • Geza Geleji January 24, 2018

      Thanks for letting me know — I must note that the XPath I posted in the article has worked for me.

  5. Hi,

    I have opened a new case for IBM support about this. I got the same error in two different workstations, one running Windows 10 & another Windows server 2012 R2. Just to be curious, are you running on Windows or Linux?

  6. vinoth kumar January 15, 2018

    Hi… I am trying to implement WS-Security following the above article using IIB V10.0.0.9, but, I am facing the same exception as “Thanga|” . Please find below my configurations

    PolicySet
    =======
    PolicySets
    ConsumerPolicySet
    config=”
    ws-rm=”
    ws-security=’

    *MQSIALIASuser_partALIASMQSI*

    *MQSIALIASuser_partALIASMQSI*

    PolicySetBinding
    =============
    PolicySetBindings
    ConsumerPolicySetBinding
    associatedPolicySet=’ConsumerPolicySet’
    config=”
    ws-security=’

    Please help us in sorting the issue

  7. vinoth kumar January 15, 2018

    Hi Geza… I have followed the same steps and facing issue while my flow sets up SOAP request node with the same invalid XML character error in IIB V10.0.0.9 Please advise

  8. Hi Geza Geleji, Thanks for the blogs and its very useful. I have tried as explained in this Blog using IIb 10.0.0.11, however got the error during the deployment as below.

    ( MQNode.Earth ) A Java exception was thrown whilst calling the Java JNI method ”method_com_ibm_broker_axis2_Axis2NodeRegistrationUtil_registerSyncRequestNode”. The Java exception was ”BIP3726E: com.ibm.broker.axis2.MbSoapException: Failed to setup Axis2”. The Java stack trace was ”Frame : 0 com.ibm.broker.axis2.MbSoapException: Failed to setup Axis2
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.(Axis2NodeRegistered.java:369)
    @: com.ibm.broker.axis2.Axis2NodeRegistered.(Axis2NodeRegistered.java:163)
    @: com.ibm.broker.axis2.Axis2EngineManager.registerNode(Axis2EngineManager.java:91)
    @: com.ibm.broker.axis2.Axis2NodeRegistrationUtil.registerSyncRequestNode(Axis2NodeRegistrationUtil.java:356)
    Frame : 1 com.ibm.broker.axis2.MbSoapException: Configuration using PS and binding failed
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.setupSOAPPipeline(Axis2NodeRegistered.java:959)
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.(Axis2NodeRegistered.java:322)
    @: com.ibm.broker.axis2.Axis2NodeRegistered.(Axis2NodeRegistered.java:163)
    @: com.ibm.broker.axis2.Axis2EngineManager.registerNode(Axis2EngineManager.java:91)
    @: com.ibm.broker.axis2.Axis2NodeRegistrationUtil.registerSyncRequestNode(Axis2NodeRegistrationUtil.java:356)
    Frame : 2 org.apache.axis2.AxisFault: Failure during load of PolicySet configuration
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.policySetConfiguration(Axis2NodeRegistered.java:2359)
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.setupSOAPPipeline(Axis2NodeRegistered.java:917)
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.(Axis2NodeRegistered.java:322)
    @: com.ibm.broker.axis2.Axis2NodeRegistered.(Axis2NodeRegistered.java:163)
    @: com.ibm.broker.axis2.Axis2EngineManager.registerNode(Axis2EngineManager.java:91)
    @: com.ibm.broker.axis2.Axis2NodeRegistrationUtil.registerSyncRequestNode(Axis2NodeRegistrationUtil.java:356)
    Frame : 3 javax.xml.bind.UnmarshalException: An invalid XML character (Unicode: 0x19) was found in the element content of the document.
    @: com.ibm.xml.xlxp2.jaxb.msg.JAXBMessageProvider.throwUnmarshalExceptionWrapper(JAXBMessageProvider.java:93)
    @: com.ibm.xml.xlxp2.jaxb.unmarshal.impl.JAXBDocumentScanner.produceFatalErrorEvent(JAXBDocumentScanner.java:297)
    @: com.ibm.xml.xlxp2.scan.DocumentScanner.reportFatalError(DocumentScanner.java:4871)
    @: com.ibm.xml.xlxp2.scan.DocumentScanner.reportFatalError(DocumentScanner.java:1212)
    @: com.ibm.xml.xlxp2.scan.DocumentScanner.scanContent2(DocumentScanner.java:1949)
    @: com.ibm.xml.xlxp2.scan.DocumentScanner.scanContent(DocumentScanner.java:1869)
    @: com.ibm.xml.xlxp2.runtime.VMContext.scanContent(VMContext.java:502)
    @: com.ibm.xml.xlxp2.scan.DocumentScanner.nextEvent(DocumentScanner.java:1283)
    @: com.ibm.xml.xlxp2.scan.DocumentScanner.parseDocumentEntity(DocumentScanner.java:1175)
    @: com.ibm.xml.xlxp2.jaxb.unmarshal.impl.JAXBDocumentScanner.unmarshal(JAXBDocumentScanner.java:125)
    @: com.ibm.xml.xlxp2.jaxb.unmarshal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:107)
    @: com.ibm.ws.wssecurity.handler.WSSecurityPolicyTypeLoaderImpl$2.run(WSSecurityPolicyTypeLoaderImpl.java:119)
    @: java.security.AccessController.doPrivileged(AccessController.java:694)
    @: com.ibm.ws.wssecurity.handler.WSSecurityPolicyTypeLoaderImpl.load(WSSecurityPolicyTypeLoaderImpl.java:117)
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.policySetConfiguration(Axis2NodeRegistered.java:2266)
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.setupSOAPPipeline(Axis2NodeRegistered.java:917)
    @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.(Axis2NodeRegistered.java:322)
    @: com.ibm.broker.axis2.Axis2NodeRegistered.(Axis2NodeRegistered.java:163)
    @: com.ibm.broker.axis2.Axis2EngineManager.registerNode(Axis2EngineManager.java:91)
    @: com.ibm.broker.axis2.Axis2NodeRegistrationUtil.registerSyncRequestNode(Axis2NodeRegistrationUtil.java:356)”.

    Correct the error, and if necessary redeploy the flow.

    Here is the Consumer PolicySet and its binding configurable services reports.Also confining that the alias MyKey-cert and MyKey are exists in the keystore file.

    PolicySets
    WSSecTestConsumerPolicySet
    config=”
    ws-rm=”
    ws-security=’

    *MQSIALIASuser_partALIASMQSI*

    *MQSIALIASuser_partALIASMQSI*

    BIP8071I: Successful command completion.

    PolicySetBindings
    WSSecTestConsumerPolicySetBinding
    associatedPolicySet=’WSSecTestConsumerPolicySet’
    config=”
    ws-security=’

    BIP8071I: Successful command completion.

    Appreciate your reply..

    • Geza Geleji January 02, 2018

      Your policy set configuration doesn’t look right. Note the ‘An invalid XML character (Unicode: 0x19) was found in the element content of the document.’ error in the stack trace.

      • Hi Geza & thanks for good article!

        I got exactly the same error as Thanga. I tried to solve that by trying various configurations but hit the same error every time.
        Lastly I tried only the message sign part (same error again):

        WSSecTestConsumerPolicySet

        *MQSIALIASuser_partALIASMQSI*

        WSSecTestConsumerPolicySetBinding

        Exceptions:
        WS-Security configuration requires correctly initialised policy set and policy set binding information in order to succeed. An error has occurred whilst attempting to use policy set ”WSSecTestConsumerPolicySet” and policy set binding ”WSSecTestConsumerPolicySetBinding”. Common causes are:
        1: Either the policy set name or policy set binding name is missing from the node (or flow) configuration.
        2: If X.509 tokens are being used, including implicit usage such as signing or encryption, the keystore and/or truststore is not be set correctly.


        ( SECTEST_NODE.secsrv ) A Java exception was thrown whilst calling the Java JNI method ”method_com_ibm_broker_axis2_Axis2NodeRegistrationUtil_registerSyncRequestNode”. The Java exception was ”BIP3726E: com.ibm.broker.axis2.MbSoapException: Failed to setup Axis2”. The Java stack trace was ”Frame : 0 com.ibm.broker.axis2.MbSoapException: Failed to setup Axis2
        @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.(Axis2NodeRegistered.java:369)
        @: com.ibm.broker.axis2.Axis2NodeRegistered.(Axis2NodeRegistered.java:163)
        @: com.ibm.broker.axis2.Axis2EngineManager.registerNode(Axis2EngineManager.java:91)
        @: com.ibm.broker.axis2.Axis2NodeRegistrationUtil.registerSyncRequestNode(Axis2NodeRegistrationUtil.java:356)
        Frame : 1 com.ibm.broker.axis2.MbSoapException: Configuration using PS and binding failed
        @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.setupSOAPPipeline(Axis2NodeRegistered.java:959)
        @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.(Axis2NodeRegistered.java:322)
        @: com.ibm.broker.axis2.Axis2NodeRegistered.(Axis2NodeRegistered.java:163)
        @: com.ibm.broker.axis2.Axis2EngineManager.registerNode(Axis2EngineManager.java:91)
        @: com.ibm.broker.axis2.Axis2NodeRegistrationUtil.registerSyncRequestNode(Axis2NodeRegistrationUtil.java:356)
        Frame : 2 org.apache.axis2.AxisFault: Failure during load of PolicySet configuration
        @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.policySetConfiguration(Axis2NodeRegistered.java:2359)
        @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.setupSOAPPipeline(Axis2NodeRegistered.java:917)
        @: com.ibm.broker.axis2.Axis2NodeRegistered$SOAPConfig.(Axis2NodeRegistered.java:322)
        @: com.ibm.broker.axis2.Axis2NodeRegistered.(Axis2NodeRegistered.java:163)
        @: com.ibm.broker.axis2.Axis2EngineManager.registerNode(Axis2EngineManager.java:91)
        @: com.ibm.broker.axis2.Axis2NodeRegistrationUtil.registerSyncRequestNode(Axis2NodeRegistrationUtil.java:356)
        Frame : 3 javax.xml.bind.UnmarshalException: An invalid XML character (Unicode: 0x19) was found in the element content of the document.
        @: com.ibm.xml.xlxp2.jaxb.msg.JAXBMessageProvider.throwUnmarshalExceptionWrapper(JAXBMessageProvider.java:93

        –> There is no special characters (End Of Medium(^Y)) as far as the policy dump would show those…

        Do you have any clue what would be the root cause for this? I’m out of ideas :/

        Thanks & regards,
        Vesa

        • Hi Geza, thanks for a good article!

          I received the same error as Thanga and Vesa … could you find out what is the problem with this?

          • Geza Geleji October 19, 2018

            I’m suspecting the quote characters in the XPath expression — see comments. Unfortunately this is done by autoformatting that I can do little about.

Join The Discussion

Your email address will not be published. Required fields are marked *