You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Anubhav Sharma <as...@talend.com> on 2011/03/08 16:05:19 UTC
Re: STS Provider Contribution
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" <as...@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
Re: STS Provider Contribution
Posted by Daniel Kulp <dk...@apache.org>.
We chatted a bit via voice but wanted to follow up on list for benefit of
all...
On Wednesday 30 March 2011 3:14:07 AM Anubhav Sharma wrote:
> 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, but in a different way. If you have WSS4J properly configured and the
WS-SecPol properly defines the requirement of the UsernameToken, then WSS4J
will do the username token processing and authentication. If the
authentication fails, WSS4J will fail immedately and a generic "security
error" fault would get sent back immediately. The actual STS implementation
code would never get called. It's more of a "fail fast" scenario.
> 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.
OK. Perfect. I definitely had trouble figuring out what should be "example"
and what should be framework.
> 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.
Right. If it's part of the example, Maven can pull it in, no problem.
Thanks!
Dan
>
> Thanks and Cheers,
> Anubhav
>
>
>
> On 3/25/11 8:01 PM, "Daniel Kulp" <dk...@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" <dk...@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" <dk...@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" <as...@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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: STS Provider Contribution
Posted by Anubhav Sharma <as...@talend.com>.
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" <dk...@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" <dk...@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" <dk...@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" <as...@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
Re: STS Provider Contribution
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 24 March 2011 11:17:16 AM Anubhav Sharma wrote:
> 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" <dk...@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" <dk...@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" <as...@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
Re: STS Provider Contribution
Posted by Anubhav Sharma <as...@talend.com>.
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" <dk...@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" <dk...@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" <as...@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
Re: STS Provider Contribution
Posted by Daniel Kulp <dk...@apache.org>.
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" <dk...@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" <as...@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
Re: STS Provider Contribution
Posted by Anubhav Sharma <as...@talend.com>.
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" <dk...@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" <as...@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
Re: STS Provider Contribution
Posted by Daniel Kulp <dk...@apache.org>.
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" <as...@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