Wednesday, May 14, 2014

OAuth2 - the future of HTTP web services

If the only thing that you've heard about OAuth2 is that it is "insecure" then I'd like to say it is impossible to come up with the generic specification that will ensure the security of your application.
If you have invested some time into analyzing the specific OAuth2 flows and found the conditions under which the security can be breached then it is obvious that a care needs to be applied to whatever OAuth2 flow is deployed depending on how open the application, etc.
If you haven't subscribed yet to OAuth2 discussion lists then I'd like to encourage you to do it and follow up.
  
IMHO, OAuth2 will affect deeply the way we write secure web services in the years to come. A lot of innovation will be coming in in this space. OAuth2 will become much bigger than a classical 3-leg OAuth flow popularized so much by OAuth1. The complexity is already and will be there no doubt about it, but one should remember that OAuth2 can always be just a simpler and more effective evolution of OAuth1. It is difficult to beat the flexibility of it with respect to supporting all sort of grants, tokens and flows.

As far as the classical OAuth2 flow is concerned it is probably just a matter of time before the user authorizing 3rd party applications will have the optional legal effect and all communications with 3rd party intermediaries will move online. The browsers will probably support it the same way they support the certificates from the well known providers.

It is a natural fit for the current Big Thing: Cloud and Big Data. In fact OAuth2 is the next Big Thing.

Be positive about OAuth2 and get up to speed with it now :-). A healthy ecosystem of open source OAuth2 implementations is growing.  



  

Monday, April 28, 2014

The Tom EE Tribe Time

You do not have to have any specific experience with Tom EE to become a fan. You do not even have to download it. You only have to talk or listen to David Blevins, a long time EE practitioner and the leader of TomiTribe, the real business around Tom EE, to feel excited and realize Tom EE is coming near you if not now but very soon.

We are the fans of TomEE+ of course :-).

You can become the member of the Tom EE(i) Tribe too, play with Tom EE and support the movement !


Sunday, April 27, 2014

Observations about Apache Con NA 2014

It has been a while since I visited Apache Con last time, so I was happy I got a chance to go to Apache Con NA 2014 held in Denver, nice 'mile high' city, April 7-9.

It may be quite a cliche thing to say but the most rewarding thing about visiting Apache Con is about socializing with the fellow team mates, committers and visitors, seeing people you have talked with over the years but not realizing how impressive they look like in the real life :-). The buzz coming out of the conversations or simply observing the activity is difficult to 'measure'.

Some key notes have been quite inspiring. It is obvious the open-source edge is there, still and will be there.

I've seen some interesting presentations, and I regret I was not able to see a number of them, which I was keen to see.

"SSL State of the Union" was brilliantly presented, the speaker managed to make it quite entertaining. I really liked it, the only problem was that it was presented after lunch, on the 2nd day, when the time difference body clock adjustment was still under way, so at the end of the presentation I started feeling a bit sleepy :-), and then I heard 'CXF' being mentioned, it re-energized me, especially given that CXF came up as the only Web Service implementation in the list where a specific HTTPs issue was confirmed to be resolved.

"Choosing an HTTP Proxy Server" was very professionally presented.

We've had several presentations about Apache CXF. Dan did a nice overview of what is coming in Apache CXF 3.0.0, Colm, the industry security expert, had two presentations about Apache CXF security, Denis Sosnowski was talking about WS RM.

You can also check the slides of my own presentation, "JAX-RS 2.0 With Apache CXF". I talked mainly about JAX-RS 2.0: about the new cool features, about the positive effect new spec leads have had on the progress of JAX-RS 2.0 and JAX-RS in particular.

Finally, I'd like to talk about the presentation made by Paul Wilson, a long time Apache CXF user. Paul came all the way to Denver to talk about the way they use Apache CXF in a big and successful project. It was a developer to developer talk, where people had a chance to listen and decide for themselves if the approach described worked for them or not. The room was full. I thought it was very nice of Paul to talk so much about CXF, given that obviously
their project is much bigger than just CXF. Paul was very gracious in recognizing the input Apache CXF community provided over the time to his queries, though I think it was mainly the other way around, him reporting the bugs and helping improving CXF.

I'd like to encourage CXF users who can afford talking publicly about some cool projects they have done with Apache CXF follow Paul's lead and talk and blog about it. Apache Con EU 2014 will be held in November in Budapest, great opportunity to do a submission :-)

 

  







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.

Enjoy. 





  

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,
Enjoy.