cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anubhav Sharma <asha...@talend.com>
Subject Re: STS Provider Contribution
Date Fri, 11 Mar 2011 16:26:56 GMT

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.

Thanks and Cheers,
Anubhav

On 3/9/11 3:42 AM, "Daniel Kulp" <dkulp@apache.org> 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" <asharma@talend.com> 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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message