I've accomplished this goal using a WSS4JInInterceptor as well as with
PolicyBasedWSS4JInInterceptor using CXF's WS-P support.
Regardless of the approach, the underlying WSS4J implementation code will
unmarshall your SAML assertion and make it available in the results. WSS4J
currently only supports OpenSAML 1.x so you are tied to SAML 1.x assertions.
The following code can be used to retrieve the parsed assertion in an
interceptor after the WSS4J interceptors complete:
final Vector<WSSecurityEngineResult> samlResults =
new Vector<WSSecurityEngineResult>();
// Note: when the outbound action is ST_SIGNED (SamlTokenSigned), the
// results list is a ST_UNSIGNED because the SAML processor and
// signature processors don't indicate if the assertion was used to
// sign the message or not so you get signature results and ST_UNSIGNED
// results even if the assertion was used to sign the message.
WSSecurityUtil.fetchAllActionResults(wsHandlerResult.getResults(),
WSConstants.ST_UNSIGNED, samlResults);
final WSSecurityEngineResult result = samlResults.get(0);
(SAMLAssertion) result.get(WSSecurityEngineResult.TAG_SAML_ASSERTION);
Note that there can be more than one value in samlResults depending on the
incoming message.
As far as I know, the CXF WS-P and WS-Trust support on the inbound side does
not actually validate the assertion against an STS or in any other manner. I
think you are on your own as to the validation processing. It should be noted
that STSClient does contain code to make the validation request, but I don't
think it is currently integrated into the IssuedTokenInterceptor (I'm a couple
versions behind though).
If you also need to produce or acquire the SAML assertion in a CXF client, you
should first consider the following questions before you can decide which route
is best for your scenario:
1) Do you intend to create your own assertions or retrieve them from a WS-Trust
STS?
2) How familiar are you with WS-Trust?
3) How familiar are you with SAML?
4) Do you need to use the SAML assertion as the signing token (initiator token)
in the message or as a supporting/signed supporting token only?
Both CXF's WS-P/WS-T support and WSS4J's SAML issuing APIs have their
limitations on the client side so my recommendation depends on your objectives
and comfort level more than anything. If you answer the above questions, I can
provide you with some additional advice based on my personal experiences.
-----Original Message-----
From: John Hite [mailto:[email protected]]
Sent: Thursday, March 04, 2010 10:28 AM
To: [email protected]
Subject: SAML and WS-Security
I'm trying to create a web service in CXF that is secured using WS-Security
with SAML tokens. Looking through the documentation, and briefly at the
WSS4JInInterceptor, it appears that this is not implemented. I want to modify
WSS4JInInterceptor to handle SAML tokens. Can anyone provide me with some
information about how the WSS4JInInterceptor works to help me get started?
Also, I'm wondering if I need to modify the PolicyBasedWSS4JInInterceptor?
Thanks,
John
