On Tuesday 13 April 2010 11:14:33 am Brandon Richins wrote: > Dan, > > Thanks so much for the suggestion. I turned on addressing and I now have > the AppliesTo header in my outgoing message. Unfortunately the STS server > we use uses an arbitrary namespace for the endpoint address like the > request below. > > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust";> <soapenv:Header/> > <soapenv:Body> > <wst:RequestSecurityToken> > > <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:Re > questType> <wsp:AppliesTo > xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";> > <wsa:EndpointReference > xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing";> > <wsa:Address>http:/arbitrarynamespace/org/VER/ICM/SAML1.1</wsa:Address> > </wsa:EndpointReference> > </wsp:AppliesTo> > </wst:RequestSecurityToken> > </soapenv:Body> > </soapenv:Envelope> > > When I run my CXF sample, it looks like CXF uses the address of the > enclosing jaxws:client. Is there any way to coerce it to use an arbitrary > address?
Looking at the code, the only way would be to write an interceptor that would run before the IssuedTokenOutInterceptor and would call: message.put(Message.ENDPOINT_ADDRESS, newTarget); May need to set it back afterword as well. Well, you could also subclass the STSClient class and override the requestSecurityToken(String) to map the passed in address to a new value. That said, definitely a useful suggestion. I'm going to add a : ws-security.sts.applies-to property that can be used to set this. Should be in place for 2.2.8-SNAP in the next day or two. Dan > In my client code I execute the below code to set the service > endpoint. I wondered if there is something like > "provider.getRequestContext().put(STS_APPLIES_TO, target)"? > > BindingProvider provider = (BindingProvider)stub; > provider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY > , target); > > Thanks again, > > > Brandon Richins -- Daniel Kulp [email protected] http://dankulp.com/blog
