> Basically it seems the problem is that I would have to meddle around with the config of the WSS4JOutInterceptor all the time (per > request), I guess, changing the 'action' configuration from UsernameToken to SAMLTokenSigned and all that.
Could you have a different interceptor for both Issue + Validate? I don't see a way around this to be honest... > Regarding issue #2: you got it, they don't want a ValidateTarget element at all (although I don't know what would happen if it was > provided anyway). Since the token is in the security header, I guess it's all they need. The WS-Trust spec says that the ValidateTarget Element is required for the Validate operation... /wst:RequestSecurityToken/wst:ValidateTarget Colm. On Wed, Apr 24, 2013 at 4:24 PM, David Mansfield <[email protected]> wrote: > Hi Colm: > > Basically it seems the problem is that I would have to meddle around with > the config of the WSS4JOutInterceptor all the time (per request), I guess, > changing the 'action' configuration from UsernameToken to SAMLTokenSigned > and all that. > > I'm not sure I understand how to do that except for via spring > configuration files which are static - also it's not "my" web service > client object, it's a web service client object held by the STSClient > instance. > > Regarding issue #2: you got it, they don't want a ValidateTarget element > at all (although I don't know what would happen if it was provided anyway). > Since the token is in the security header, I guess it's all they need. > > On 04/24/2013 11:04 AM, Colm O hEigeartaigh wrote: > >> Hi, >> >> What's stopping you from meeting the requirements for (1)? If you have >> access to the SecurityToken object from the issue call, it should be >> possible to set the STSClient up accordingly. >> >> In respect to (2), I'm not sure I follow exactly. You want to call the >> Validate operation without passing a ValidateTarget Element at all? >> >> Colm. >> >> >> On Wed, Apr 24, 2013 at 2:42 PM, David Mansfield <[email protected]> >> wrote: >> >> Hi All, >>> >>> I've been working trying to get the CXF STSClient to work with a >>> partner's >>> almost-compliant implementation, and so far (with help from you all) >>> gotten >>> the "issue" (requestSecurityToken) to work perfectly. Now I'm looking at >>> "validate" >>> >>> Note: there is no security policy so everything is configured manually >>> (including adding and configuring the WSS4JOutInterceptor to the bus used >>> by the sts client). >>> >>> The default validateSecurityToken is not working because with CXF >>> STSClient: >>> >>> 1) the same UsernameToken (with different nonce etc). that was used in >>> the >>> issue request is used in the validate request inside the wsse:Security >>> header in the soap:header (and used for signing) >>> >>> 2) the previously issued security token is placed in the soap:body inside >>> the wst:ValidateTarget element. >>> >>> But our partner's STS wants: >>> >>> 1) to authenticate with the previously issued security token (which is a >>> signed saml:Assertion) in the wsse:Security and use the BinarySecret >>> provided in the "issue" to sign the various required signed elements in >>> the >>> document >>> >>> 2) elide the ValidateTarget element in the body completely. >>> >>> I don't know if #2 is necessary or not, but it's what their documentation >>> shows. >>> >>> Is this behavior anything like any implementation seen anywhere "in the >>> wild'? Is there any reasonably direct way to make this happen with cxf >>> STSClient? >>> >>> >>> >>> >> > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
