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
