This is definitely a good start. As you said, the code needs some major cleanup which does make it a bit harder to really review.
My initial 2-minute thoughts: Code generation issues: 1) We really need to generate the code into org.apache.cxf namespace someplace. A jaxb binding file would take care of that. 2) Also, do we really need to generate for things like the xmldsig and policy namespaces? Seems a bit strange to me. Runtime: The provider is marked PAYLOAD and DOMSource. Thus, the DOM just contains the contents of the SOAP Body. However, the first thing you do is convert to a SOAPMessage. Why? I don't see the point in that and I think it's wrong as the envelop and body wouldn't be there. I'd recommend switching to just Source (instead of DOMSource). You can then return a JAXBSource object and eliminate the entire JAXB -> DOM step in there. It's a little trickier on the incoming side, but not by a lot. Most likely, I would just take the original incoming Source and feed it directly into JAXB to unmarshal, and then grab the RequestType out of the JAXB object. (or from the ws-a Action header that could be injected in via the WebServiceContext). Anyway, definitely a good start. Dan On Tuesday 08 March 2011 10:05:19 AM Anubhav Sharma wrote: > Hi All, > > I have attached an initial implementation of the STS provider framework and > the Issue operation. The eclipse project is attached to the following > Jira: > https://issues.apache.org/jira/browse/CXF-1940 > > I still need to refractor the code with regards to logging, exception > tracing, checkstyles etc. I would request you all to provide an initial > feedback while I proceed with the code cleanup. > > Thanks! > Anubhav > > > On 2/23/11 1:46 PM, "Anubhav Sharma" <[email protected]> wrote: > > > > > Hello Everyone, > > I would like to contribute an STS provider framework to the CXF project. > The idea would be to implement a provider based STS service, the obvious > reason being that it can support both WS Trust 1.3 and 1.4 versions. The > invoke method of this provider would convert the request into > corresponding JAXB objects and delegate the call to the right > implementation. The implementation of operations like Issue, Renew etc. > would be configured in spring. The users would just need to implement > their business logic for these operations and configure the implementation > class in spring. > > As an example I would also like to contribute a sample implementation for > the Issue operation. This sample would accept UsernameToken and X509Token > as inputs, use local file system for authentication and return back a SAML > Token. I would propose to support both, SAML 1.1 and SAML 2.0. In the RST, > user can use TokenType attribute to request either a SAML 1.1 or 2.0 > token. > > This would give the CXF users an opportunity to use and test the sts client > against the sample STS implementation, extend the STS with their business > implementations and in future we can enhance STS with a more sophisticated > and complete implementation. > > Would appreciate your views and inputs on this. > > Cheers, > Anubhav -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
