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
