Wednesday, February 12, 2014

Feeling Hawkish about OAuth2 ?

You all know the recent OAuth history of course, Eran Hammer, the author of  popular OAuth1 specification, leaving the OAuth2 work group, with OAuth2 not getting much of a praise from Eran afterwards.
Eran has started several projects afterwards, Hawk and Oz in particular.  The former is the evolution of the MAC draft Eran and others authored as part of the OAuth2 work, the latter is the alternative to OAuth2.

Now, I do like the OAuth2 model, I think it's very flexible and allows for all sort of flows, grants and tokens being supported. I think it is next to impossible to write a perfect specification where the security risks can be ignored or forgotten about as such. I'll be happy to see Oz evolving, good luck to it, I guess it will be very healthy if it also gets the momentum, but for now OAuth2 is what I'm interested in mostly.

That said, I really liked that draft. May be because I could read it without feeling like I needed to become a security pro and even implement it in a couple of days (with the major help from Sasi. M) ? IMHO the draft was the closest to the original OAuth1 text describing how the temporary request token affects the signature, the details differ, but the idea is very similar, where the request token acquisition step is replaced by AS returning a Mac key to the client who becomes the holder of the key. I thought that draft was paving a direct path for OAuth1 users migrating to OAuth2.

As it happens, the OAuth2 group has initiated a new MAC token draft effort. This is a good news in itself but it just takes a different approach toward getting the MAC mechanism supported. I think it is fair to say the text is much more involved; it is written by the top experts who I happen to learn a lot from by hanging at the OAuth2 list, but the truth is, without going into the detailed analysis, is that the CXF MacAccessToken implementing the draft written by Eran and others has become lost in the translation. The draft is abandoned, the OAuth2 MAC effort  will require a completely different implementation.

Throwing the CXF MacAccessToken code away to avoid getting into the 'conflict' with the OAuth2 MAC approach has not been an option, IMHO it's still useful as a custom token mechanism and custom tokens and authentication schemes are proper OAuth2 citizens. And as I said, I do like the simplicity of the original text, as well as the fact that a distribution of the symmetric key is left unspecified, recommending TLS, etc, and what can be simpler to a key exchange over a 2-way TLS ? 

So I've looked at Hawk in more detail. It is indeed the evolution of the draft. But the core of it did stay, the simplicity of it is there. So what I just did, rather than throwing the CXF MacAccessToken code away, I simply replaced 'Mac' with 'Hawk' in the class and package names and the name of the HTTP scheme they understand, this is all I did. For example, this code implements the Hawk scheme without me changing anything (well, I added one extra space to indicate the extension data is missing in the normalization function which was required by the draft) from the original CXF code.

The Hawk documentation goes at some length clarifying it is nothing to do with OAuth. I think it is a bit off-topic given that Hawk is a proper HTTP authentication scheme, and as such it is kind of immaterial which HTTP servers rely on it to secure its resources. I guess some of its extensions are better utilized as part of Oz, but I see no problems in getting a custom OAuth2 token supporting the clients authorizing via Hawk, the new HTTP scheme.

So I'm happy that the draft has not died after all and got resurrected in the form of Hawk. Please check the documentation and contribute to the Hawk project.
And in meantime we will keep an eye on the OAuth2 MAC effort too, we can have Hawk and OAuth2 Mac tokens coexisting happily.



You're gonna be a star with CXF !

I've happened to listen to one of my favorite songs, All the Way to Reno from R.E.M, just recently, which probably shows me being not exactly very young :-).

Apparently the text has a lot of subtle meanings but one really can't beat its gentle rhythm leading to the listener having a kind of 'life is good' feeling, being optimistic.

"You're gonna be a star", you really can and you will...Feeling the excitement has gone out of the web services development work a bit ? You know what you need to do...

Friday, February 7, 2014

Use OAuth2 tokens to protect CXF SOAP endpoints

So you are a happy Apache CXF developer working with its second-to-none WS SOAP front-end, creating SOAP endpoints protected by WS-Security. Your friends from the other team have deployed few CXF JAX-RS endpoints protected by the OAuth2 filter validating the incoming OAuth2 tokens with the remote OAuth2 server.

Now, you really, really, really want to get your SOAP client code use OAuth2 tokens too, the same tokens non-SOAP RS clients use to access RS endpoints,  because it is something new to try.

So how complex can it be ? The answer: it is a child's play with Apache CXF. Follow these steps:

- Get CXF WS client code use WS-Security Binary Token mechanism as a transport for passing OAuth2 Bearer tokens to the server - easy
- If you work with WS-Policy, add one more WS-Policy alternative allowing for WS-Security Binary Tokens, in addition to the existing security alternatives, no code changes
- Add a basic OAuthRequestInterceptor extension immediately after CXF WSS4JInInterceptor which will make the extracted binary token available on the current message. All this custom interceptor will do is get the token from the message and pass it over to the super-class as suggested in the commented code.
- Make sure your OAuthRequestInterceptor does not interfere with other WS-Security authentication mechanisms if they are supported - if it is non a binary token then simply let the request continue

"Now you are talking", I can hear you saying. Give it a try please, and tell your friends from the other team how easy it was for you to join the OAuth2 game.

Monday, February 3, 2014

Stateless OAuth2 providers in CXF 3.0.0

Writing a proper OAuth2 data provider typically involves persisting the data such as access token, refresh token and transient authorization code representations in the storage of some sort (relational database, etc).

It is also a well-known fact that major OAuth2 providers often have the access token state encrypted - the clients effectively keep the token state, the server does not need to worry about persisting and looking up the tokens. It is assumed the cost of the encryption and decryption work is smaller, especially when a lot of clients are stressing the OAuth2 server.

CXF 3.0.0-milestone2, to be released shortly, introduces the dedicated utility classes to help users experimenting with encrypting and decrypting the token state.

Please check this introduction and proceed from there. Get your stateless OAuth2 server up and running in no time.

The feedback will be highly appreciated,

Friday, November 29, 2013

CXF 3.0.0 Milestone1 is out !

CXF 3.0.0 Milestone1 has been released this week.  We have all worked very hard on getting this new major release out.

Here is what is new:

- CXF has become more modular. For example, CXF JAX-RS frontend in CXF 2.7.x or earlier has WSDL4J library dependency. Removing it completely proved very hard earlier, but Dan got involved and now the JAX-RS frontend has a minimum number of strong dependencies.

- JAX-RS 2.0 has been completely implemented. Users are encouraged to work with the 3.0.0 Milestone1, the JAX-RS 2.0 work has been completed for several months and only minor issues are expected to be found in Milestone1 - lets find and fix them all before 3.0.0 Final !

- Major WS-Security refactoring has been done, with Colm  doing a lot of work in CXF. It is mainly about the streaming features of WSS4J 2.0 supported at the CXF level, and it is going to be a massive feature for CXF WS users. CXF WS Security code will fly.

- Bean Validation 1.1 API has been wired in thanks to Andriy Redko. This is what is great about Open Source: I was not planning to do this work for 3.0.0 Milestone 1, but then Andriy offered his expert help and now all of CXF frontends, JAX-RS and JAX-WS ones can get the Bean Validation activated.

 - LocalTransport has been optimized to become much more suitable as a mechanism for the integrated testing -  this approach is superior to using mocks.

- Many other fixes, optimizations and improvements. Example, users can get their client-side auto-redirection done in a much more secure fashion.  Freeman has added an optional Swagger feature for  documenting REST endpoints. Netty transport has been added by Willem. The exceptions escaped from the native CXF interceptors can also be mapped to registered JAX-RS exception mappers which gets JAX-RS applications better integrated with the core CXF features. I just have to stop typing, so many things I'd like to mention here...

CXF 3.0.0 Milestone 1 is out and it is one more step toward asserting Apache CXF as the leading framework for the development of WS and RS applications.

Get On Board and Enjoy !

Thursday, August 29, 2013

CXF 3.0 Trunk is JAX-RS 2.0 Ready

It took us some time to get the core JAX-RS 2.0 API completely implemented.

As I mentioned in my previous post the API is rich and powerful, so indeed it required quite a bit of effort to get it all supported but I'm happy to confirm that after resolving a CXF JIRA issue two days ago to do with supporting 2.0 Fluent Client API it is done now, CXF 3.0 Trunk is JAX-RS Ready.

As far as supporting new Client API is concerned, for the most part it has been implemented by delegating to CXF WebClient API, so those of you who work with CXF WebClient can continue using it, it won't be dropped. Besides, IMHO WebClient API offers a somewhat different approach toward writing a code to do with consuming HTTP services so it is good to say that in CXF we will offer several API flavors for users to experiment with.

Note that CXF 2.7.x supports JAX-RS 2.0 m10 - there are some minor differences between m10 and final 2.0 API supported on the trunk, but I'm hoping that users migrating to CXF 3.0 will see very few migration issues.

Now, as far as 2.0 API is concerned, I'd like to encourage users to actively experiment with the new features, with CXF 2.7.x and CXF 3.0.0-SNAPSHOT and report the issues if any; I'd like to thank those users who have already done so.

In meantime I will work on the proper documentation and stressing a bit the Client 2.0 API module against the early 2.0 TCK. Once this is all done we will turn our attention to getting Bean Validation feature supported across all CXF frontends.

Stay tuned !

Thursday, June 13, 2013

JAX-RS 2.0 is out !

You may have already heard JAX-RS 2.0 (JSR-339) has been released. This is a very good news for Java developers building their RESTful HTTP applications and here are the reasons why.

The 2.0 API  offers a lot of new enhancements on top of already very capable JAX-RS 1.1 (JSR-311) API and spec. It has really been a very serious push to the next level across all the API and the specification text. And what is really good is that the community can now rest assured: the JAX-RS effort started by Paul Sandoz and Marc Hadley is very alive and is led by a new super team, Marek Potociar and Santiago Pericas-Geertsen who worked extremely hard to get JAX-RS 2.0 out. 

As I said the new API offers a lot of enhancements: client and server filters and interceptors, new Client API, client and server asynchronous invocation support, a lot of new context classes, new exception classes, a lot of API updates. A lot of new things to try and learn, but what I personally like most is the new asynchronous API and the fact that JAX-RS 1.1 Response class can be reused by Client API - it seems like a minor thing but IMHO it's one of the major points.

I've enjoyed taking part in the JAX-RS 2.0 development process. Talking to all the participants, 'fighting to death' on the subject of very trivial issues, running never ending threads - it has all happened and it has been great :-). As every developer out there knows sometimes one has to forget about the disappointment of having your great point of view rejected :-), and move on with the team toward making something good happen - this is what this spec effort has been about.

Talking to one of my former team leads, Bill, has been super too :-). As a side note, a lot of API enhancements have their origin in the work Bill and his team did.

JAX-RS 2.0 is out and about to take over and fly high. It is only a start, MVC support, some new useful features will hopefully and likely be in in the next major releases. Is it perfect ? Probably not - I can name few API and spec features I'm still not feeling exactly happy about, but overall JAX-RS 2.0 is great.  
In Apache CXF we are going to have JAX-RS 2.0 completely implemented by the end of the year. As it happens 2.0 server-side API is already completely implemented on the trunk. Some of the features like the integration with Bean Valdation API is required by the EE profile only but I think we can wire that into CXF too.
It is also validated against the early TCK 2.0 build (with Andrei helping a lot).

Client API is 50% done - CXF WebClient API has been enhanced to support new Client interceptors and filters, Response and even Asynchronous Invocations (with thanks to Dan).  Still some work to do on the actual new Client API. We are getting there.

So try JAX-RS 2.0 API and enjoy !