On Tuesday 09 December 2008 6:03:02 am Mayank Mishra wrote: > Hi, > > I am working on WS-Trust support for CXF. The requirement is like, while > creating a secured request from client to service, client requires to > communicate with STS to get required token. Depending on the security > requirements of the STS service specified in the wsdl and ws-trust spec, a > client may require to secure the STS communication. > > Now, I am already in a requesting phase (client-server), how can I create > another nested request-response (client-STS and STS-client). Currently, I > am relying on the jax-ws Dispatch api to achieve this. I will use the wss4j > api to do the required security processing. Having a bootstrap > communication between client-sts is not a solution for this, right? Or Can > I use reentrant property of PhaseInterceptorChain to achieve this, I am not > sure about this option. > > Does above sounds sensible? Any pointers/suggestions on how to achieve the > same by some better way will be appreciated.
I've gone ahead and committed what I had started onto trunk. First off, the Dispatch API probably won't work for you right now. It needs some refactoring to get it to work with the standard Ws-Addressing and Security stuff which you may need for this. There is a JIRA for that someplace. What I committed uses some pretty low level API's to setup a Service. It COULD use a WS-Trust wsdl, but that would then require wsdl parsing and such which didn't seem worth it for just a couple operations. For the security stuff, it uses the new WS-SecurityPolicy stuff that is on the 2.2/trunk. Basically, if you have a policy to describe the requirements of the STS server, you just set it inot the STSClient and it should use it. (currently requires the policy stuff turned on on the Bus, will fix that shortly as it should be able to turn it on explicitely for itself) The start of the MS interopfest stuff for the trust10 stuff is at: http://svn.apache.org/repos/asf/cxf/sandbox/interopfest/wstrust10/ I'm not getting a token back from their sts right now, but I think it's a problem on there end. It's getting this error back right now: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs. The Axis2/WSO2/Rampart clients are also getting an error back. Since I assume they worked at one point, I'll assume it's a problem on the MS side. Anyway, tomorrow I hope to start actually flushing out the requestSecurityToken method to actually create a proper response based on the trust policies. -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
