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 Wed, 30 Mar 2011 07:14:07 GMT
Hi Dan,

Sorry for the late reply, was caught up in fixing some Blocker issues.
Thanks for your changes!! Really appreciate your efforts on this.

I am not sure about point 7. Shouldn't it be the responsibility of the STS implementation
to authenticate
the incoming usernameToken? In such a case, users can implement authentication the way they
want in the IssueOperation implementation.

Yes, some of the stuff should be moved to examples, the IssueOperation implementation, it
should not be part of the framework impl. I will do that.

I would make the CRLVerifier not to be dependent on the bouncycastle classes, would be better
this way. However it should be a part of the example implementation so wont be a big deal.

Thanks and Cheers,
Anubhav



On 3/25/11 8:01 PM, "Daniel Kulp" <dkulp@apache.org> wrote:

On Thursday 24 March 2011 11:17:16 AM Anubhav Sharma w
rote:
> 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.

Definitely a step in the right  direction.   I want to start getting this
integrated into the builds, but it's not *quite* ready.   What I've done is
cloned the cxf repo on github and taken you patch and started integrating it
into the build.   See:

https://github.com/dkulp/cxf/

I've also added you as a contributor so it would be good if you can start
working with me on that copy there to get it ready to push it onto trunk at
Apache.

A list of major changes I made:

1) It's all part of rt/ws/security now which is likely where it should be.

2) I modified the code generation to generate everything in org.apache.cxf
namespaces which is where we would need it.  I also just code generate the
schemas.  I had some issues with the mapping when generating from the wsdl.
There's a bug in the code generator someplace relating to the ws-addressing
mapping we do.  I haven't had time to figure out what the bug is.  Doesn't
realy matter for this though.

3) Updated the STS provider/impl to throw an unsupported operation soap fault
for operations that are not configured in.   I definitely prefer only
configuring in the stuff you want/need and have a good exception thrown for
the others.

4) Removed all the *Delegate things from the operations package.  They aren't
really needed with (3).

5) Cleaned up the dispatching in the Provider so you can write an operation
that  implements multple interfaces and have it dispatch correctly.  It also
handles the requestCollection case that doesn't take the  same parameters as
the other operations.

6) I've added the WebServiceContext to all the operation methods.   This is
important as you may need the results of the WSS4J processing or the basic
auth principal or other.

7) I REMOVED the PasswordCallbackHandler thing you had  and the authentication
stuff you were doing in IssuedOperationDelegate.   The way it was being used
was definitely not thread safe.  Plus, with WSS4J 1.6, the authorization is
being handled by it.  By the time it gets into the STS, the username token
will be valid and authenticated already.  (that assume the WS-SecurityPolicy
for the STS is properly defined)   I then get the UsernameToken from the
context for the name.


My main question at this point has to do with the intentions.   I pretty much
took your entire "src" tree and moved into rt/ws/security.   I wasn't sure if
some of it is really the "framework" that should be there and possibly some of
it should be just part of an example.   The stuff for the tomcat-users that
was in there was obviously just example stuff, but with the removal of the
UsernameToken stuff, it's no longer there anyway.  Thus, it could probably
remain as is.

The other concern I have is the CRLVerifier depending directly on bouncycastle
classes.   Not a huge deal, but that does then make bouncycastle a stronger
requirement for using the STS.

In anycase, if you could start helping me out in my cxf repo clone at github,
that would be great.    I definitely think its getting close.

Dan


> Thanks and Cheers,
> Anubhav
>
>
>
> On 3/11/11 8:11 PM, "Daniel Kulp" <dkulp@apache.org> 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" <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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com

--
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