Question

I’m writing a JAXWS-RI client that must call a .NET Web Service that is using WS-Security. The service’s WSDL does not contain any WS-Security info, but I have an example soap message from the service’s authors and know that I must include wsse:Security headers, including X:509 tokens.

I’ve been researching, and I’ve seen example of folks calling this type of web service from Axis and CXF (in conjunction with Rampart and/or WSS4J), but nothing about using plain JAXWS-RI itself. However, I’m (unfortunately) constrained to using JAXWS-RI by my gov’t client. Does anyone have any examples/documentation of doing this from JAXWS-RI?

I need to ultimately generate a SOAP header that looks something like the one below – this is a sample soap:header from a .NET client written by the service’s authors. (Note: I’ve put the ‘VALUE_HERE’ string in places where I need to provide my own values)

<soapenv:Envelope xmlns:iri="http://EOIR/IRIES" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401- wss-wssecurity-secext-1.0.xsd">
     <xenc:EncryptedKey Id="VALUE_HERE">
       <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
       <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
          <wsse:SecurityTokenReference>
             <wsse:KeyIdentifier 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">
             VALUE_HERE
            </wsse:KeyIdentifier>
         </wsse:SecurityTokenReference>
       </ds:KeyInfo>
       <xenc:CipherData>
          <xenc:CipherValue>VALUE_HERE</xenc:CipherValue>
       </xenc:CipherData>
       <xenc:ReferenceList>
         <xenc:DataReference URI="#EncDataId-8"/>
       </xenc:ReferenceList>
    </xenc:EncryptedKey>
  </wsse:Security>

Answer 1

After working on this for quite a while, our team of developers here has determined that we couldn’t do this. We simply could not write a Metro(JAXWS-RI+WSIT) client that would correctly call & process a response from the .NET WSE 3.0 web service that used WS-Security. I wanted to write up our different approaches, though, for those who might try something like this in the future.

To recap:
1. Our first pass: WSE 3.0 web service with MutualCerticates11 Security (WS-Addressing, encryption, signing, secure conversation (ws-trust)). We reverse engineered a WS-Policy snippet to place in our local copy of the WSDL to hande this, but could not get the secure conversation initial handshake request to be accepted by WSE.

2. Next, they downgraded to WSE 3.0 MutualCerticates10, as there is some chatter about it being ‘more interoperable’. Again, we could not get the secure conversation handshake to work.

3. We asked the .NET team to turn off the SecureConversation (WS-Trust) layer (the encyption & signature requirements where still there). Again, we reverse engineered the WS-Policy file (essentially, just removed the ‘BootstrapPolicy’ section that deals with WS-Trust/SC). At this point, we were able to send an encrypted, signed message to them, and they recieved it and sent a message back. We thought this was a victory, but unforunately, WSIT choked on their response message with a canonicalization error. At this point, I think we hit the limitations of WSIT, as it does not claim to be interoperable with WSE 3.0 (only WCF), so we talked to the WSIT guys on their forum and logged an issue with them. Here’s that link.

4. So, we concluded that it wouldn’t be possible for the .NET team to leave the encryption/signature layer on (for the moment, anyway – the WSIT team may fix the bug at some point). From their side, you can’t turn off just the signature and leave encryption, unfortunately.

5. We also asked them to turn off the WS-Security settings on their (.NET) side completely, and at that point, were are able to send requests & receive responses from their service using JAXWS-RI just fine. However, they may not be able to deploy this way in production.

6. So, now we are at the point where the .NET team must determine if they will be allowed to run the web service in production w/o the WS-Security settings. If not, then we will not be able to connect to their service until they upgrade to WCF. And, in fact, that has been our recommendation to them all along – that they upgrade to WCF – and now we’re more familiar than we’d like to be about the reasons why!