cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anubhav Sharma <>
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,

On 3/9/11 3:42 AM, "Daniel Kulp" <> 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.

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.


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:
> 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" <> 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
Talend -

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