One is the most confusing things in OAuth is a so-called 2-leg OAuth flow where an explicit authorization step involving the end user pressing an Allow or Deny button is not taken.
There are many resources on the web explaining what is an OAuth 2-leg flow. Most of those explanations are effectively describing the process where the 3rd party consumer accesses its own space on the resource server, possibly with the end user itself 'hiding' behind such a consumer.
But the classical OAuth is about the 3rd party consumer being able to access one way or another the resources of the end user. How does a 2-leg flow gets into the picture ?
Please read this blog entry. This is the best explanation I've seen so far and it was so good I had to stop doing my current task immediately and quickly update the CXF OAuth 1.0 code to be able to handle all the variations of the 2-leg flows better.
I think this 'pure' 2-leg flow described by Andrew is really close to a client credentials flow in OAuth 2.0. Without a pre-authorized access token (authorization code) the options are limited for a 2-leg flow.
Please see the updated documentation for more information on how CXF supports OAuth and its 2-leg flows in particular.
Monday, January 30, 2012
Thursday, January 26, 2012
Make your Application Server CXF JAX-RS friendly
Now and then I'm seeing users reporting issues on the forums to do with deploying web applications with CXF JAX-RS libraries into some of the popular Java EE application servers.
So I thought, while investigating a problem reported on the CXF users list to do with using a CXF Redirection feature in WebLogic, that it was also worth giving it a try and experimenting with deploying a complete OAuth demo web application packaged as a war archive that we are working upon into several popular application servers.
Initially I focused on testing Glassfish, JBoss and WebLogic and you can see the notes on how to overcome various deployment issues here.
It was a rather interesting exercise and I had few observations at a time.
WebLogic was the simplest to work with, as far as deploying the application was concerned without having to tweak anything at the container level. The management console of WebLogic is quite sophisticated and seems like this application server is still very capable. I only had to tweak the servlet configuration to get a CXFServlet using a wildcard URI pattern redirecting to WebLogic specific JSP engine properly as advised by the user who reported the issue.
Glassfish is OSGI-enabled and it was interesting to see Apache Felix serving as the default OSGI framework, which is a good news for the OSGI community at large, as it should drive the fixes back to this Apache project.
I had hard time though getting past the Jersey filter trying to deal with this application - it was failing eventually due to it not able to inject a CXF-specific JAX-RS Context instance. I only managed to get it work after removing one of Jersey jars from the available libs - one would only have to do it or may be something simpler :-) if the war has JAX-RS Application implementations and the OAuth demo has 5.
JBoss 7 was easy enough to deploy to. RestEasy also tries to load Applications but it was much easier to deal with it in JBoss. As a side note I thought the way JBoss 7 managed to move away from having to dump all the libs into common folders was very impressive. It is somewhat similar to the Apache Karaf's features mechanism, with Karaf having the repository of libraries and features linking those libraries together. In JBoss the repository itself has some additional metadata.
One thing I thought about after finishing this exercise was that the fact that the deployed applications are eagerly scanned for JAX-RS interfaces exposes a possible issue with these scanners. And the issue is that these scanners need to check if a deployed war contains a /META-INF/services/javax.ws.rs.ext.RuntimeDelegate resource or not and if it points to some alternative implementation then just leave this web application alone.
It would make it simpler not only for CXF JAX-RS users who may want to work with Glassfish or JBoss but for Jersey and RestEasy users too who may want to try the containers where either of this popular implementations is not natively supported. Besides, it would meet the general expectation that a self-contained war should be deployable to any Java EE container.
In meantime, please consider contributing the tips to this section. The tips in the WebLogic section have been provided on the CXF users list, so please keep them coming.
So I thought, while investigating a problem reported on the CXF users list to do with using a CXF Redirection feature in WebLogic, that it was also worth giving it a try and experimenting with deploying a complete OAuth demo web application packaged as a war archive that we are working upon into several popular application servers.
Initially I focused on testing Glassfish, JBoss and WebLogic and you can see the notes on how to overcome various deployment issues here.
It was a rather interesting exercise and I had few observations at a time.
WebLogic was the simplest to work with, as far as deploying the application was concerned without having to tweak anything at the container level. The management console of WebLogic is quite sophisticated and seems like this application server is still very capable. I only had to tweak the servlet configuration to get a CXFServlet using a wildcard URI pattern redirecting to WebLogic specific JSP engine properly as advised by the user who reported the issue.
Glassfish is OSGI-enabled and it was interesting to see Apache Felix serving as the default OSGI framework, which is a good news for the OSGI community at large, as it should drive the fixes back to this Apache project.
I had hard time though getting past the Jersey filter trying to deal with this application - it was failing eventually due to it not able to inject a CXF-specific JAX-RS Context instance. I only managed to get it work after removing one of Jersey jars from the available libs - one would only have to do it or may be something simpler :-) if the war has JAX-RS Application implementations and the OAuth demo has 5.
JBoss 7 was easy enough to deploy to. RestEasy also tries to load Applications but it was much easier to deal with it in JBoss. As a side note I thought the way JBoss 7 managed to move away from having to dump all the libs into common folders was very impressive. It is somewhat similar to the Apache Karaf's features mechanism, with Karaf having the repository of libraries and features linking those libraries together. In JBoss the repository itself has some additional metadata.
One thing I thought about after finishing this exercise was that the fact that the deployed applications are eagerly scanned for JAX-RS interfaces exposes a possible issue with these scanners. And the issue is that these scanners need to check if a deployed war contains a /META-INF/services/javax.ws.rs.ext.RuntimeDelegate resource or not and if it points to some alternative implementation then just leave this web application alone.
It would make it simpler not only for CXF JAX-RS users who may want to work with Glassfish or JBoss but for Jersey and RestEasy users too who may want to try the containers where either of this popular implementations is not natively supported. Besides, it would meet the general expectation that a self-contained war should be deployable to any Java EE container.
In meantime, please consider contributing the tips to this section. The tips in the WebLogic section have been provided on the CXF users list, so please keep them coming.
Friday, January 20, 2012
CORS Support in CXF
Cross-Origin Resource Sharing (CORS) is a W3C specification (Working Draft) which "defines a mechanism to enable client-side cross-origin requests". Please see the Introduction for more information.
We had several users asking questions about how CORS could possibly be supported in CXF. Then at some point of time a mysterious :-) sergkorney offered his help with prototyping an initial code for a CORS filter, and the process moved forward.
Benson took charge and wrote a comprehensive and well-documented filter implementation which follows the specification very closely.
This filter can do the preflight and simple request checks. It interacts with the JAX-RS runtime by relying on its selection algorithm to confirm that an application has a resource method which is capable of dealing with the current request in cases when the filter does not block. If a JAX-RS resource method which can handle the HTTP OPTIONS verb indicates via a dedicated annotation that it will handle the preflight check, then the filter will delegate to it. JAX-RS root resources and individual methods can be customized for them to take part in the CORS process.
It is likely to grow into a more complex security feature in time.
Please review this initial documentation (with the link to the package.html), start experimenting and provide the feedback.
We had several users asking questions about how CORS could possibly be supported in CXF. Then at some point of time a mysterious :-) sergkorney offered his help with prototyping an initial code for a CORS filter, and the process moved forward.
Benson took charge and wrote a comprehensive and well-documented filter implementation which follows the specification very closely.
This filter can do the preflight and simple request checks. It interacts with the JAX-RS runtime by relying on its selection algorithm to confirm that an application has a resource method which is capable of dealing with the current request in cases when the filter does not block. If a JAX-RS resource method which can handle the HTTP OPTIONS verb indicates via a dedicated annotation that it will handle the preflight check, then the filter will delegate to it. JAX-RS root resources and individual methods can be customized for them to take part in the CORS process.
It is likely to grow into a more complex security feature in time.
Please review this initial documentation (with the link to the package.html), start experimenting and provide the feedback.
Wednesday, January 11, 2012
RESTful endpoint in 60 seconds in Talend Open Studio
I briefly mentioned in the end of this post that we are working on the tooling for creating RESTful endpoints in Talend Open Studio for ESB.
I'd like to offer to your attention my first screen-cast available on the Talend Channel. It shows how one create and test a basic HTTP Service endpoint echoing the POST payload back to the client. I timed it all for some fun, so it actually did took me 60 seconds to create a service and about 60 seconds to test it.
Of course one would spend much more time on developing a more involved service but the idea was to give you a glimpse of how easy you can create a RESTful service as well as to point to the flexibility of the tooling as far as wiring the extra components in is concerned.
Future presentations will show how to create more involved services, those supporting multiple HTTP verbs, with more components facilitating the access to the real data.
Please listen to this short presentation, download the Studio and try creating your own HTTP service and also check what it offers with respect to working with SOAP services and Camel routes.
Oh yes, one more thing, if you are into languages and you'd like to hear what an Irish-Belorussian accent is about :-), then please listen indeed to this screen-cast
Enjoy !
I'd like to offer to your attention my first screen-cast available on the Talend Channel. It shows how one create and test a basic HTTP Service endpoint echoing the POST payload back to the client. I timed it all for some fun, so it actually did took me 60 seconds to create a service and about 60 seconds to test it.
Of course one would spend much more time on developing a more involved service but the idea was to give you a glimpse of how easy you can create a RESTful service as well as to point to the flexibility of the tooling as far as wiring the extra components in is concerned.
Future presentations will show how to create more involved services, those supporting multiple HTTP verbs, with more components facilitating the access to the real data.
Please listen to this short presentation, download the Studio and try creating your own HTTP service and also check what it offers with respect to working with SOAP services and Camel routes.
Oh yes, one more thing, if you are into languages and you'd like to hear what an Irish-Belorussian accent is about :-), then please listen indeed to this screen-cast
Enjoy !
Friday, January 6, 2012
Maven archetype for creating CXF JAX-RS applications
A number of Maven plugins that CXF JAX-RS users could try for generating the initial code they could build upon for creating working applications was close to zero not too long ago, in fact it was actually 0.
Then we added a wadl2java plugin so the numbers started to look better :-).
And now starting from CXF 2.5.1 an archetype plugin for creating Spring-based JAX-RS applications is also available, all thanks to Benson.
Please see this page for more information.
The generated project will get the integration tests running too, so having a simple end-to-end application created and tested in less than a minute is really cool.
Then we added a wadl2java plugin so the numbers started to look better :-).
And now starting from CXF 2.5.1 an archetype plugin for creating Spring-based JAX-RS applications is also available, all thanks to Benson.
Please see this page for more information.
The generated project will get the integration tests running too, so having a simple end-to-end application created and tested in less than a minute is really cool.
Subscribe to:
Posts (Atom)
