Hi Dan, I have attached a new version of the STS Provider impl to the Jira issue. It contains some defect fixes we found in the sample Issue implementation during our testing. Thanks for your suggestion regarding the response marshalling, I have incorporated it in the new version. Would be nice if you can have a look again.
Thanks and Cheers, Anubhav On 3/11/11 8:11 PM, "Daniel Kulp" <[email protected]> wrote: On Friday 11 March 2011 11:26:56 AM Anubhav Sharma wrote: > Hi Dan, > > Thanks for your inputs. I have cleaned up the code and attached a new > version of the STS provider to the JIRA issue. I have incorporated your > inputs regarding DOMSource and JAXB, you are right, it is much simpler > that way. I still need to check for the code generation issue. Definitely looking a lot better. The response part could still use some work. Instead of doing a DOMSource, you could do: RequestSecurityTokenResponseCollectionType tokenResponse = (RequestSecurityTokenResponseCollectionType) methods[x] .invoke(operationImpl, rst); if (tokenResponse == null) { throw new Exception("Error in implementation class."); } return new JAXBSource(jaxbContext, new ObjectFactory() .createRequestSecurityTokenResponseCollection(tokenResponse)); There are two advantages: 1) The QName on the element is correct. :-) 2) Completely avoids the DOM creation. CXF can directly write the JAXBSource out from the events it would generate. Dan > > Thanks and Cheers, > Anubhav > > On 3/9/11 3:42 AM, "Daniel Kulp" <[email protected]> wrote: > > > > 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 -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
