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.