Wednesday, December 22, 2010

CXF/Metro WS-Trust interop

Glen Mazza has done some excellent work on creating and documenting an example of how to use CXF to obtain a SAML token from a Metro STS and use it to invoke on a Metro endpoint. Unfortunately, it didn't work for a number of reasons:
  1. The Metro endpoint objected to the fact that the CXF client was using a wsse:Reference to the SAML Assertion instead of a wsse:KeyIdentifier. This was a bug in WSS4J, and was fixed as part of WSS-238.
  2. The CXF client could not decrypt the response from the Metro endpoint. As part of the fix for WSS-238, support was added for processing an EncryptedKey that points to a SAML Assertion containing an X509Certificate, and an EncryptedData token that points to a SAML Assertion containing an EncryptedKey. 
  3. The CXF client could not handle a reference to a SAML Assertion which was not in the SOAP request. This scenario occurred as the endpoint had the "AlwaysToRecipient" policy configured. This was fixed as part of WSS-260.
The good news is that using the latest WSS4J 1.5.11-SNAPSHOT the interop test-case works. This is an important initial milestone in the improving interoperability with third party WS-Trust implementations.

This kind of interop testing is vital and we have a lot of work planned in this regard.


  1. Hello,
    I have the same problem with cxf 2.4 and wss4j 1.6.0 (see

  2. I just merged a fix for CXF-3482...