Hi David, Thank you for your reply. That interceptor will prove invaluable. I'll explain what I am trying to do and answer your questions. Any advice you could give would be greatly appreciated.
I'm developing a set of services that may be distributed (i.e. running on different hosts or different networks). These services should only accessible by authorized users, but I don't want to have each service handle authenticating the user (in fact, it's possible that some of the services may not be able to authenticate the user). To me this sounded like a good scenario for WS-Trust. I can have an STS that the services trust handle authenticating users. The STS would issue a signed SAML assertion to the user that can be used to access the other services. Now, to answer your questions. 1) Do you intend to create your own assertions or retrieve them from a WS-Trust STS? I intend to retrieve the assertions from the STS. 2) How familiar are you with WS-Trust? I'm somewhat familiar with WS-Trust. It's still fairly new to me, but I've read through the spec several times during the last week. I used the spec build my STS which is issuing a more or less hard coded SAML token for now. 3) How familiar are you with SAML? I'm less familiar with SAML than with WS-Trust. I've been reading the SAML Token Profile trying to figure out which type of SAML assertion I need to issue from my STS. 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? I'm pretty sure I need to use the assertion as the signing token. If I am not mistaken, I would need a trust relationship between the client and the web service if I was using the SAML assertion as a supporting token. I can't have that. My client is pretty much not trusted. I've understood the overall picture of WS-Trust, WS-Security, SAML, etc. for a while, but only since last week have I been digging down into the details of the specifications and trying to get things to work. It's been very frustrating trying to translate what I read in the spec to an actual implementation using CXF. If I can get this done I'll try to contribute some docs. Thanks, John -----Original Message----- From: David Valeri [mailto:[email protected]] Sent: Thursday, March 04, 2010 11:18 AM To: [email protected] Subject: RE: SAML and WS-Security 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
