Sergey Beryozkin

Subscribe to Sergey Beryozkin feed
Sergey Beryozkinhttp://www.blogger.com/profile/06251894780466207746noreply@blogger.comBlogger220125
Updated: 17 hours 32 min ago

RESTful Data Updates with Talend Studio

Fri, 06/01/2012 - 15:21
I created a presentation few months ago which showed how one can create a simple DB browser for exploring the arbitrary databases using Talend Open Studio for ESB.

The Customers DB explorer we created last time was supporting GET queries allowing to return the list of all the customers and the individual customer records.

I've worked recently on enhancing the job that we created last time for supporting more involved GET queries as well as data updates with POST, PUT and DELETE verbs. The presentation is available here.

The demo shows the original ReadCustomers DB job, as well as ReadCustomersAndOrders one which additionally manages GET requests for all the orders of the individual customers and the individual orders only.

The CRUDOrders  job shows how to create the new orders for specific customers, update and delete the existing orders, and query the list of all the orders for all the customers. Check how easy it is to configure the job to return a status like 400 in case of attempting to add an order for a non-existent customer.

Note that in this demo I did not really focus on showing how the individual jobs can be created from scratch, in order to keep it shorter in time. There are many other presentations available from Talend Channel, in series like this one, which show how various Talend components can work together, please follow one of those presentations or this one to get more information about it.

In this demo I really wanted to highlight that REST components can manage different HTTP requests (queries, updates, etc), with different, possibly overlapping URI paths and data payloads.

The tRESTRequest component linking HTTP verbs and URI templates is based on the JAX-RS matching algorithm and you can see how flexible the configuration can be, with as many capturing templates as needed added to the relevant HTTP mappings.

More work will be needed for it to support the richer set of media types, in addition to XML, JSON and forms. More flexible support for identifying newly created resources will be needed too.  We will be showing the relevant presentations in time.

I'd like to encourage those who are interested to play with creating RESTful jobs and provide us with the feedback.

In meantime I'll work on creating a demo showing how a RESTful job can be packaged as an OSGI bundle and deployed into Karaf with HTTPS and Basic Authentication supported by the container.

Stay tuned !
Categories: Sergey Beryozkin

Controlling Large Payloads in CXF

Wed, 04/25/2012 - 12:11
You may have already read that so called hash-collision attacks may affect many of the existing Web applications. A massive form, XML or JSON payload with specially constructed keys can be posted to the service and cause the denial of service situation due to the fact many of XML, JSON or form payload processors depend internally on the map implementations that are not capable of dealing with such data effectively.

It does not have to be a specially ill-prepared payload. Huge XML or say multipart/form-data application payloads with open-ended list of child elements or parts may significantly slow down the services too.

There has been a number of announcements from the major projects on the workarounds that may need to be taken, for example, please check this Tomcat issue.

Security has always been and going to be  a major story in Apache CXF and obviously we spent some time on making sure CXF endpoints can be adequately protected in such cases too.

For a start, we followed the Tomcat's lead and introduced a "maxFormParameterCount" endpoint property then can be used to restrict a number of form name/value pairs passed in the HTTP POST body.

We also introduced a DepthRestrictingStreamInterceptor that can be used to enforce a number of limits on the incoming XML payloads such as: the total number of elements, the maximum number of child elements and the maximum stack level. More fine-grained, element-specific limits may be supported in the future. Note it was already possible to protect CXF WS endpoints with the relevant system properties before the introduction of this interceptor.

Additionally, CXF JAX-RS endpoints and JAXB-based providers can be individually configured with the limits that will be imposed on the incoming payloads. Note that even JSON payloads can be controlled by the default Jettison-based JSONProvider.

HTTP 413 will be returned whenever the limit is reached.

Finally, as has already been mentioned on this blog, we had a high-quality contribution which made it possible to control the attachment limits by using an "attachment-max-size" property.

Please check the CXF Security and JAX-RS DataBinding sections for more information, test with the recently released CXF 2.6.0, 2.5.3, 2.4.7 and 2.3.10 distributions and provide the feedback.

Categories: Sergey Beryozkin

Custom JAX-RS Contexts in CXF 2.6.0

Fri, 03/30/2012 - 10:49
CXF 2.6.0 is due to be released soon, with several new features likely to get the developers interested.

CXF is about to become much more OSGI-friendly which will open the way for many new interesting enhancements to come thanks to Dan and Christian leading this major refactoring effort.

The JAX-RS frontend has benefited (as usual :-)) from the core CXF improvements. One of the positive side-effects was that the initial go at splitting the fairly big JAXRS module was attempted.

Most of the optional JAX-RS providers were moved with all their optional dependencies to the new cxf-rt-rs-extension-providers module, Christian's refactoring of the clustering feature helped to drop the JAX-RS specific extension with JAX-RS clients now being able to use same fail-over feature configuration as their JAX-WS brothers :-), and the code to do with the WADL to Java code generation made its way to its real home, the cxf-tools-wadlto-jaxrs module. The CORS code now lives in cxf-rt-rs-security-cors, it needs to as enforcing the CORS across multiple servers will very likely require more enhancements to the current filter and the couple of annotations.

Finally the FIQL search extension code got moved to the new cxf-rt-rs-extensions-search module. I think this extension has a lot of offer and more enhancements will start coming in sooner or later due to the power and simplicity of FIQL.

Moving the FIQL code presented a challenge, how to get the core JAX-RS frontend to populate the SearchContext offering an optimized access to the FIQL queries ? The name of this custom JAX-RS Context class is hard-coded within the frontend in the earlier CXF versions but with the extension now moving away it was not an option any more.

The new ContextProvider extension was to be the answer I was looking for and here is the implementation which creates a SearchContext instance by relying on the CXF Message class which has all the information about the current request. The last thing that needs to be done is to get the ContextProvider registered with JAX-RS endpoints.

It is actually quite a major enhancement, now the users can inject whichever contexts they like. For example, JAX-RS 1.1 HttpHeaders context offers a number of utility methods for accessing the HTTP headers. Lets say you'd like to help the application developer to handle Origin headers but HttpHeaders can not help. Well, write a custom OriginHeader ContextProvider, extract the Origin out of the message and make it really easy for the application developer to access various Origin parameters. You can use ContextProviders whenever you'd like to offer an optimized access to some of the information available in the current request.

I believe Jersey was offering a similar extension probably from the very early start. One can not deny Jersey was an absolute star :-) at the start of the JAX-RS, and they continue to be the major JAX-RS implementation, but CXF just keeps catching up even though it took us a bit of time to get to the ContextProvider.

Note ContextProvider looks similar to JAX-RS ContextResolver but they actually serve different purposes with the latter meant to simplify processing the data possibly involving the custom media types, see this method. I believe it was originally introduced to handle custom JAXBContexts. After thinking a bit about reusing ContextResolver I decided not to in order to avoid possible conflicts.

Finally, having to register the ContextProvider providing SearchContext instances led to another enhancement request. In CXF one needs to explicitly register custom JAX-RS providers and I believe it works well most of the time due to the flexibility offered by the explicit configuration approach. However, having an option to get simple basic providers auto-discovered would be useful too - thus a new enhancement request to support the optional class scanning is now pending.

It is always useful to refactor and simplify code - more often than not it has the positive side-effect of the new features added :-)
Categories: Sergey Beryozkin

All Roads Lead to Mainz

Tue, 03/27/2012 - 17:36
They say all the roads lead to Mainz. Indeed, this year it is the home to JAX-2012, a very popular conference for Java developers in Germany.

The Talend team which includes Bernd Trops, Principal Consultant with Talend, Christian, Oliver and myself will be there. We are going to present few sessions during the Apache Integration Day on 18th April, so be there if you can :-)

I'm a bit nervous given that my German is not perfect :-), but with Bernd, Christian and Oliver all talking German I should be fine :-)
Categories: Sergey Beryozkin

Simple DB Browser in Talend Open Studio

Tue, 02/14/2012 - 18:19
The screen-cast showing how to create a basic DB browser within Talend Open Studio is now available on the Talend Channel.

This presentation is more involved than the one showing how to create a simple REST endpoint. This time a basic database containing a list of customer records is exposed via HTTP and we go through a number of steps showing how the task of creating an arbitrary DB browser can be approached.

Initially the complete list of records is returned and then the optimized one containing smaller records but with links pointing back to complete individual records is returned.

What are we going to present next is the job which also supports the various data updates with a bit more complex database involved. Some options for dealing with exceptions will be shown. I haven't mentioned that JSON is also supported by default so we'll show the way it is supported out of the box too.

As I've already mentioned before our REST Tooling project is an ongoing effort and there will be quite a few things enhanced and improved over the near future. We are brainstorming with my colleagues various ideas such as how to make it feasible to bind the data to views in the most transparent way, how to secure the services, how to make the integration with other Talend components more complete, etc.

So I expect us producing quite a few exciting demos over the time :-)

In meantime, please view the presentation and provide us with the feedback.
Categories: Sergey Beryozkin

Distributed OSGi RI 1.3 is out!

Tue, 02/07/2012 - 13:37
The signs are that the fortunes of Distributed OSGI are looking good.

Distributed OSGI RI based on Apache CXF (Apache CXF DOSGi RI) has been around for a while, and quite a few OSGI developers have experimented with and built custom applications on top of it successfully.

However, it's been more than a year since DOSGi RI 1.2 has been released and this project has been inactive recently. In meantime, two more Distributed OSGi implementations have been announced by two OSGI heavyweights, one by my colleague JB, and another one by Guillaume Nodet.

Now, as far as Apache CXF DOSGi RI is concerned, we are seeing users asking the questions quite regularly and this is a sign this implementation and the whole idea of the Distribured OSGI is of interest to some OSGI developers, more on it below.

So after getting some of issues reported against DOSGi RI 1.2 for the last couple of months, we have released Apache CXF DOSGi 1.3. Please see the release notes for more information (note there is a minor typo in the release notes, it is CXF 2.5.2 which this release is based upon, not CXF 2.5.1).

The major improvement in this release is that it is now possible to register custom CXF interceptors (pre-configured if needed) as service properties with the underlying JAX-WS and JAX-RS frontends.

WSDL-first approach is also supported now which is a good news for SOAP developers, see this project for an example. Of course, the JAX-RS frontend was trying to offer something similar :-), so a new org.apache.cxf.rs.wadl.location property has been added. Please see this updated page for more information on all the new properties.

If you are an existing user of the DOSGI RI then please try this new release.

If you have never tried it and wonder what is the story with DOSGI then try it too. DOSGI RI is quite sophisticated in that not only the basic endpoint and consumer creation is supported but also a mechanism for the distributed discovery is wired in.

But it is this fact that the OSGI programming model is used to drive the creation of the web service endpoints and consumers which is appealing to some developers and that is what one should focus upon first when experimenting with DOSGi.

If you think about it, the way to create a new web service endpoint or stop the old one in OSGI is typically to deploy a new bundle or stop the existing one from the shell or possibly from the UI management console. I guess it is quite rare that the custom application bundle will deal with updating the bundles itself.

In DOSGI, the creation if web services endpoints and consumers is actively driven by the typical OSGI BundleContext and ServiceTracker calls. If this style of managing the web services indirectly by the custom application registering or looking for OSGI services does appeal to you then DOSGI could become a perfect fit for your project.

In DOSGI 1.3 we fixed some basic blockers to get the project active again. The future releases will likely focus on making the distributed discovery working really well and also on improving the way the custom configuration can be applied.

One more thing which I'd like to mention is that if you are interested in OSGI in general and possibly in DOSGi and looking for a way to get involved in the open-source project and make a difference then please think of contributing to this project.
Categories: Sergey Beryozkin

OAuth without the end user explained

Mon, 01/30/2012 - 18:13
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.
Categories: Sergey Beryozkin

Make your Application Server CXF JAX-RS friendly

Thu, 01/26/2012 - 13:06
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.
Categories: Sergey Beryozkin

CORS Support in CXF

Fri, 01/20/2012 - 11:07
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.
Categories: Sergey Beryozkin

RESTful endpoint in 60 seconds in Talend Open Studio

Wed, 01/11/2012 - 14:42
I briefly mentioned in the end of this 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 !
Categories: Sergey Beryozkin

Maven archetype for creating CXF JAX-RS applications

Fri, 01/06/2012 - 12:42
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.
Categories: Sergey Beryozkin

Jettison 1.3.1 has been released

Thu, 12/29/2011 - 16:48
Jettison 1.3.1 has just been released, please see this page and the Download page for more information about the latest fixes.

The two updates which would be of interest to CXF users (or those who rely on other stacks that ship the providers wrapping Jettison) are to do with making it possible to create formatted JSON outputs and making sure that the ignorable (empty) text content (reported by JAXB when processing the mixed content data) is blocked. The latter update, among other things, will make the WADL JSON representations look nicer given that they are produced from the wrapped XML payload.

Few other improvements made it into this release too, particularly those JIRAs which had the patches attached to them have been resolved.

I'd like to encourage the Jettison community to continue providing patches and as far as I'm concerned I can say that the patches will be eventually applied and the fixes will make it into the the future Jettison releases.

Happy New Year !
Categories: Sergey Beryozkin

Associating user login names with OAuth Access tokens

Mon, 12/12/2011 - 18:25
The classical OAuth flow involves the authorized 3rd-party client magically accessing the end user's resources without even specifying a user name or id, for example:

GET /user/calendar

How can the server figure out which resource to return ? The answer is that the request will have an Authorization header with an access token key and in OAuth 1.0 the token needs to get the information about the end user authorizing a given 3rd party consumer associated with it at the authorization time.

With this association in place, the server will have an easy way to get to the name or id of the user used to authorize the client, and the way to do it in soon to be released CXF 2.5.1 is documented here.

I'd like to thank Glen for helping me with getting this enhancement done.

We are continuing working on the demo which will show most of the CXF OAuth support in practice. Please stay tuned to see how you can write secure OAuth applications with CXF :-)
Categories: Sergey Beryozkin

Locator Support For RESTful Services in Talend ESB

Wed, 12/07/2011 - 11:26
Back in June I blogged about CXF JAX-RS providing a fail-over support for RESTful Java clients and mentioned some relevant work started in Talend.

Things are happening in the Talend land where all the interesting new features in Apache projects that our Coders team is contributing to are taken on board, analyzed and wired in the products real fast. And the newly released Talend ESB 5 brings a Locator support for RESTful endpoints and clients with the client-side Locator feature built on top of the CXF fail-over mechanism. Kudos to the ESB team for implementing it.

If you get a working HTTP-centric code then having such a code not hard-coding the endpoint address of the RESTful server which is part of the large WEB application and seeing it working even after a given server or the HTTP connection to it goes down will be encouraging.

Are you all into writing large RESTful applications end-to-end ? Have problems answering to your friends who like working with SOAP (they are still your friends though :-)) and tell you that with REST it's not possible to write Locator-aware fail-over capable clients ? If the answer to either of those 2 questions is yes then go to a new Talend web site, download Talend ESB v5, get to /examples/talend/tesb/locator-rest and proceed from there.

One thing I should mention is that Talend Open Studio for ESB is also available for download, it builds on top of Talend Data Integration suite and offers a second-to-none UI support for developing web services and routes. If you work with CXF SOAP Web Services or Camel then you probably won't be able to get back to your old UI tools after trying Talend Open Studio for ESB.

And the good news is that we are working on bringing the users a tooling for developing RESTful applications. It is a work in progress but it's happening, stay tuned !
Categories: Sergey Beryozkin

Observations about Maven Central Search URIs

Wed, 11/23/2011 - 14:30
I was using a Maven Central Search Engine to find a Google GWT artifact. The search engine is very useful, no doubt about it. I then somehow got focused on the actual URI which identifies the specific GWT artifact I was after:

"http://search.maven.org#search|gav|1|g%3A'com.google.gwt'%20AND%20a%3A'gwt'".

I'm using single quotes just to keep the whole URI expression inside double quotes.

That does not seem like a user-friendly URI to me, and I guess it does not have to be, but I'd just like to analyze it a bit more.

I'm not sure what "|gav|1|" is about, but the main expression (encoded), is really this one:

"g%3A'com.google.gwt'%20AND%20a%3A'gwt'" which reads like this: "find resources with a group 'com.google.gwt' and artifact 'gwt'".

Now compare it with this equivalent FIQL expression which CXF will happily help to handle:
"g=='com.google.gwt';a=='gwt'"

thus giving us

"http://search.maven.org?_s=g=='com.google.gwt';a=='gwt'".

This query a bit simplistic but FIQL does start 'scaling' when we want to use composite queries, for example:

"http://search.maven.org?_s=g=='com.google.com';(a=='gwt',a=='gwt-inject');(v=gt=2.0;v=le=3.0)"

which reads "Find all the modules with a given group, with artifact set to 'gwt' or 'gwt-index' and having versions greater than 2.0 but less or equal to 3.0". It's impressive how FIQL can capture so complex queries in a compact way with a URI which humans can understand. FIQL simply rocks and I encourage users to experiment with it more. By the way, check out the client-side FIQL support, can be handy for building FIQL queries inside the HTML forms.
Categories: Sergey Beryozkin

[OT] CXF- Even Better Than The Real Thing

Wed, 11/23/2011 - 11:03
Listening to U2 for a long time seems to start affecting me, so much that I can't stop 'producing' my own 'mix' (the Title line of this post) of the fantastic U2's "Even Better Than The Real Thing".
Those who follow this blog for a while will notice I'm getting a bit repetitive by mixing 'CXF' with phrases from some songs I've heard, sorry :-). But if you are working with CXF you may probably agree with the title :-). Have Fun.
Categories: Sergey Beryozkin

Complex WADL Processing in CXF

Tue, 11/22/2011 - 13:56
We have seen a number of JIRA issues opened against a WadlToJava generator since it was added to CXF 2.4.1. Seeing the community experimenting with it was really reassuring and it confirmed there was some genuine interest toward working with WADL. WADL was a really fine effort from Marc Hadley and it does seem to have nearly all it needs to move from a submission to a final recommendation.

One of the major contributions to the CXF WadlToJava code generator came from Christos Fragoulides who did help to push it to the next level by providing a lot of feedback and fixes while working with a more up-to-date WADL document describing Rackspace Cloud Servers API. They have a complex WADL document which utilizes most of the WADL capabilities and it is in such cases where one can start seeing the advantages of being able to get a document and start testing the server in a matter of minutes. By the way, Rackspace, hope we can see a more up-do-date WADL document live soon :-).

Then, when I already thought that our WADL code generator was flying high, came another very good contribution from Lars Weber which should make it possible to get a useful code from WADL descriptions like this one. Now the generator supports local references for all the WADL elements, in addition to external resource references.

Note that the AtomPub example relies on a WADL link element which can be used to identify a portion of the representation. How one can get to a portion of the representation in CXF JAX-RS ? Easy, use an XPathProvider.

So please try the WADL code generator in CXF 2.5.0, stress it more and provide the valuable feedback.
Categories: Sergey Beryozkin

Lets make OAuth go mainstream with CXF JAX-RS

Thu, 11/10/2011 - 11:17
OAuth 1.0 offers a fairly complex HTTP-centric solution to a classical problem of "how a resource owner (end user) can allow a third-party consumer to access some of the resources this user owns on the resource server".

I recall being quite confused about OAuth and what exactly it was supposed to help with, when starting to look into it about 2 years ago. I guess it was a typical reaction of someone trying to grasp a given technology without having any prior experience in the area. What was the story with that redirection, and then with yet another one, and how all the pieces were supposed to be wired together ? Was it about the authentication or authorization, and where would something like OpenId come in ? I was asking myself those kind of questions.

It takes a bit of time to realize how elegant OAuth actually is. OAuth 1.0 has been supported by major players such as Google, Facebook and many others. Jersey and RestEasy are offering their support. And OAuth 2.0 is going to make a massive impact real soon.

CXF 2.5.0 is joining the OAuth game. And we have tried our best to make it possible for users to write complete, functional, secure OAuth applications the way they write their HelloWorld demos.

Before providing more information, I'd like to thank Lukash Moren for providing a high-quality OAuth 1.0 implementation as part of his GSOC 2009 project, and Bill for asking me to work on OAuth during my brief spell at JBoss - it all kind of happened at the same time...

Now, please review this documentation providing a comprehensive overview of what it takes to create and deploy an OAuth server, with a lot of examples and hints on various approaches one may need to choose from when building a complete OAuth solution.

Much depends on how the resource server manages the user resources and provides an access the the end users and third-party consumers. Many options are available but the message we'd like to send is that you don't need to create a WEB application similar to those provided by Google or Facebook or Twitter in order to get working with OAuth. CXF JAX-RS provides the ingredients one may need to apply OAuth to all sort of problems requiring the end user authorizing a 3rd party access. Obviously we will be improving what is already there as time goes by.

So lets make OAuth go mainstream with CXF JAX-RS, start building OAuth applications and enjoy it all the way.
Categories: Sergey Beryozkin

SAML Claims-Based Authorization for JAX-RS endpoints

Wed, 11/09/2011 - 12:20
SAML has been around for a while and is used in real-world applications. CXF WS-Security framework is already offering a second-to-none support for SAML, especially with the introduction of the CXF's own STS, please check Colm's and Oliver's blogs and have some exciting read if you work with WS. Actually, STS can become quite important even for the advanced RESTful security - so follow those blogs even you don't work with WS :-).

The good thing about SAML is that SAML-based solutions do not have to be WS-* based only. SAML is an extensible and rich language and all sort of SAML profiles can be utilized for RESTful applications too. Arguably SAML is complex but the fact it's being used around is critical.

CXF JAX-RS is 'keen' to help users start working with SAML. CXF 2.5.0 offers an initial support for including SAML assertions in the HTTP request payloads and using them to enforce the Claims-Based or legacy Role-Based Access Control rules on the deployed JAX-RS endpoints.

One can get a SAML Assertion posted to the server inside a wrapper XML element which will include the actual application payload such as Book and the assertion itself, with the complete envelope being signed only or with both the application payload and the assertion itself being signed individually. All of it is done by registering a couple of client and server side handlers which will transparently add an envelope, signatures and then validate it all on the server side with the application payload (Book) becoming a root XML node in the end, ready to be processed by the JAX-RS runtime.

With REST we do not always post the XML data so what you can also do is easily add an optionally deflated and then base64-encoded assertion either to the Authorization header or a form field. Such encoded values might also be signed - something we may support in due time.

Having a SAML assertion available as part of the application payload raises a question as to what can actually be done with it. SAML is often used to provide SSO solutions for RESTful services, but we are not there yet, so the best thing that we could come up with at this initial stage is to let JAX-RS users utilize SAML claims in order to enforce the access control rules.

SAML claims are much richer than those which can be asserted with the RBAC rules. However @RolesAllowed and friends are still used a lot and probably will be so it was important to make sure that the legacy rules can work with SAML assertions having claims which are actually representing roles and also offer the way to assert much richer rules which are possible with SAML claims.

Have a look please at this sample code fragment and the follow-up comments. One have a lot of flexibility in the way the claim-based rules can be expressed and also complement the existing RBAC rules without even modifying the code which can also be important.

Before such rules can be enforced, the assertion needs to be validated. The SAML handler will do its own validation, and if you have STS deployed them you may actually want to delegate to it to do some validation too (recall the advice at the start of this post :-)). See also how you can setup an STS client.

The question which has not been seriously addressed yet is how one will create SAML assertions in the first place. At this stage one can start experimenting with using a callback approach and I think we can offer a support for utilizing a WS STSClient on the client side for getting the assertions and transparently adding them to the payload easily enough - please note, the fact that STSClient is a WS client is the least important fact here, it's a perfect mediator between the client code and STS and it does not matter if a SAML assertion which will make it into a non-SOAP payload was actually fetched using a SOAP client.

Note that supporting other interesting SAML-based solutions is of interest to us, that involves the possibility of supporting a WEB Browser SSO profile, etc.

In meantime, please write your simple SAML callback implementation which will generate SAML assertions and start stressing your endpoints secured by claim-based rules, or even invent a new SAML profile along the way :-)

Stay tuned !
Categories: Sergey Beryozkin

Simple XML Security with CXF JAX-RS

Mon, 11/07/2011 - 11:50
Enhancing the security support for JAX-RS services was a major theme during the CXF 2.5.0 development. CXF already offers a good support for users to create secure RESTful services relying on HTTPS and it also offers a number of useful utility classes for enforcing the authentication and authorization rules.

But the security can be a much richer subject, it is indeed and it is the right time now for us to start working on the advanced security features for CXF JAX-RS users to start experimenting and working with the message level security, tapping into the richness of SAML, deploying OAuth solutions. And we will be analyzing and providing a support for the most interesting and useful security features which are already being or will be used by the community.

As far as the message level security is concerned, XML Signature and XML Encryption are the two prominent W3C specifications which have been used as the basis for providing the message integrity and confidentiality without relying on HTTPS mainly for SOAP XML services, with the help of WS-Security related specifications.

In REST, XML is only one of the many formats which can be supported, but XML is still a very major format which is used a lot. Given the popularity of XML and also to simplify the integration with SOAP-based solutions, it does make sense to get the message-level security supported well for XML services and get to supporting other relevant efforts allowing to sign all sort of payloads next.

And this is what we did in CXF 2.5.0. We put a lot of effort in providing a solution that will make working with XML Security a child's play yet practical and able to deliver for users relying on JAX-RS.

XML Signature and XML Encryption are complex specifications but I hope you can agree after reading this section that working with these specifications and making them protect the messages can be interesting, simple and a real fun.

Note that all what is needed to get an XML signature applied to a given application payload is to register a single handler on client and server sides. By default, a signature will be enveloped as a last child inside a given XML instance such as Book. On the server side, the signature will be validated, removed from the payload and made available on the current Message for other handlers to use it if needed, for example, for optional SAML handlers be able to verify SubjectConfirmation methods such as "sender-vouches".

After the payload has become 'free' of its enclosed signature, it's wrapped in a useful CXF DOM-aware STAX reader and passed along to the JAX-RS runtime.

Making CXF JAX-RS produce enveloping or detached signatures is as easy as setting a signature style property on a client-side handler with the server side one capable of reading all types of signatures.

And now that we have a signed payload, isn't it tempting to get it encrypted too ? So here you go, all you need to get a self-contained EncryptedData with an embedded EncryptedKey capturing an encryption key is to register a single handler on client and server sides which will help CXF encrypt a payload (possibly signed) and then decrypt it on the server side.

One thing which is worth noting is that WSS4J is relied upon by this feature - this is an internal implementation detail and should be of no concern to users building advanced secure RESTful services. WSS4J has a lot of useful code and it makes sense at this stage to reuse it under the hood.

Give it a try please and as usual, please help us with the feedback. If you are a security expert - let us know what may need to be improved and if you are not - learn new advanced security concepts with CXF and become the one :-) Enjoy !
Categories: Sergey Beryozkin

Pages