The current STS stuff in CXF is very Policy driven. It's really designed to be completely configured and used via a WS-SecurityPolicy policy, not really by manually using the STSClient to get the token and then passing it in someplace.
For the most part, you would have a WS-SecPol in the wsdl (or similar) that would say it needs an IssuedToken and have a bootstrap policy setup and such needed to talk to the STS to get the Token. When CXF sees that, it would automatically use the STSClient configured in Spring to get the token and then pass that into the rest of the security stuff to handle the encryption/sigs and such. If you have the full CXF distribution, you might want to look in the samples/ws_security/interopfest/ws-trust* directories for samples that use the WS-Trust specs to get the issued tokens and use them. That's probably the best starting point right now. Dan On Monday 21 June 2010 8:49:34 am Jan Kölling wrote: > Hi, > > I'm having a hard time writing a client that uses a SAML token from > a STSClient for authentication (ws-trust). I generated the client code > with wsdl2java but I don't know how or where to provide either a valid > token or the STS itself to the client. I found an example > where the STSClient was provided to a jaxws client as a property > with the key 'ws-security.sts.client' but I can't find the client code > for this example and I don't know how I get a client that works in > this way. > > I am able to get tokens from the STS by using the API but I would > prefer to do as much as possible in the spring config. > > I'm pretty new to the whole WS* specs and have not much experience with > cxf itself, so I may be missing out on some basics. The available > documentation on ws-trust in cxf is not really helpful (a few comments > in the examples would make them much more accessible). > > If you need more information on my use case or my current attempts > I'll try to provide them. I'm sorry for keeping my problem on such > general level. > > Thanks for your help, > > Jan Kölling -- Daniel Kulp [email protected] http://dankulp.com/blog
