The short answer is that there is no concrete use case yet (you can thank
agile development for that). The longer answer is that I was tasked with
building a WS-Trust 1.4 compliant STS to issue SAML assertions that relying
parties external to the OSGI container hosting the STS might consume. These
might be SOAP web services or RESTful web services (or even something else).

Thus, it made sense in my mind to write functional tests that produced a RST
and validated the RSTR. And since our functional tests are deployed as OSGI
bundles I was looking for a  nice way of simply duplicating a subset of the
CXF system tests in an OSGI bundle.

I see your point about letting CXF create an embedded STS client. Certainly,
that's the expected pattern in the only other implementation of WS-* that I
have ever seen (i.e. WCF). However, in the end an STS is just a service that
produces tokens and what we are building is not necessarily to support
WS-SecureConversation. We're more interested in the generation and
consumption of SAML assertions. You could argue (and so would I) that a
simpler token granting service might be more appropriate for such a nebulous
use case (e.g. OAuth) but the ask was for a WS-Trust complaint STS and we
all take our orders from someone.

Of the solutions you suggested, I like using BusFactory.getDefaultBus() and
BusFactory.getThreadDefaultBus() static methods the most. Is there something
specific I have to do in Spring to set the DefaultBus() or the
ThreadDefaultBus()? Does Spring initialization and other code in the OSGI
bundle run on the same thread?

Thanks very much for the help.



--
View this message in context: 
http://cxf.547215.n5.nabble.com/Code-only-STSClient-tp5724575p5724704.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to