Wednesday, December 24, 2014
[OT] U2: "We were pilgrims on our way"
"The Miracle (of Joey Ramone)" from the last U2 "Songs of Innocence" album is a refreshing song. The actual album's content is strong. Not necessarily easy to listen though but it is been played in my car's CD player more or less every time I go driving for the last few weeks. The trick is, after listening to it for the first time, do a few days pause, and then listen again with a volume much higher than last time. It's a blast.
I still do like U2 even though I've learned not all in Ireland are the fans of them for various reasons. I was surprised, the same as I was when I was working in Manchester many years back, loving Manchester United and hearing people mentioning some other team, Manchester City :-).
The reason I still like U2 is because they are a team. These are the people in their 50s who still talk to each other :-), continue to support each other, still have the drive and ability to create something as strong and relevant as "Songs of Innocence". I disagree it is entirely down to the financial aspect.
It is an off-topic post but as usual a link to CXF is about to be explored :-). It is in the "The Miracle (of Joey Ramone)" text.
Some of CXF users might recognize they were "pilgrims on their way" before they settled on working with CXF :-). If you read it and say, yeah, this is relevant to me, then you know where CXF is. And as U2 conclude, "your voices will be heard".
Finally, here is a link to a New Year song you won't hear in a local shopping centre starting from early September: New Year's Day from U2.
Happy Christmas and New Year !
Tuesday, December 23, 2014
No Data No Fun !
Continuing with the theme of T-shirts, I'd like to let you know "No Data No Fun" is a cool line printed on my T-shirt I got at a Talend R&D summit organized at a second-to-none level back in early October. I guess having a collection of good T-Shirts is one of the real perks of the developers involved into the open source development :-)
"No Data No Fun" is also one of the themes behind Talend's continued investment into the tooling which facilitates the interaction with Big Data ecosystems. Getting such a tooling done right is hard. I'm impressed seeing companies like Lenovo liking it.
From my point of view, I'm interested to see how an apparent gap between the world of a typical HTTP service application and that of a Big Data one can be bridged. Ultimately web applications are about exploring the data and feeding them back to the users. We've done the first baby step, provided a FIQL to HBase query client that can be used to query massive amounts of data from HBase databases. JAX-RS StreamingOutput would very neatly fit in there.
However, it is also interesting to see how CXF services can be run natively in Hadoop, to save on a data delivery from HBase or other Hadoop-bound database to a query client running in scope of the CXF server, much cheaper to get it straight from Hadoop and send it back immediately. This is something I'm hoping to find some time for investigating next year. Propagating Kerberos or OAuth2 tokens into Hadoop/etc is also of interest.
I hope CXF will help you get a lot of data from Hadoop and have a lot of fun along the way :-)
"No Data No Fun" is also one of the themes behind Talend's continued investment into the tooling which facilitates the interaction with Big Data ecosystems. Getting such a tooling done right is hard. I'm impressed seeing companies like Lenovo liking it.
From my point of view, I'm interested to see how an apparent gap between the world of a typical HTTP service application and that of a Big Data one can be bridged. Ultimately web applications are about exploring the data and feeding them back to the users. We've done the first baby step, provided a FIQL to HBase query client that can be used to query massive amounts of data from HBase databases. JAX-RS StreamingOutput would very neatly fit in there.
However, it is also interesting to see how CXF services can be run natively in Hadoop, to save on a data delivery from HBase or other Hadoop-bound database to a query client running in scope of the CXF server, much cheaper to get it straight from Hadoop and send it back immediately. This is something I'm hoping to find some time for investigating next year. Propagating Kerberos or OAuth2 tokens into Hadoop/etc is also of interest.
I hope CXF will help you get a lot of data from Hadoop and have a lot of fun along the way :-)
Get into OAuth2 with Client Credentials Grant
One of the possible barriers toward OAuth2 going completely mainstream is the likely association of OAuth2 with what big social media providers do and the assumption OAuth2 is only suitable for their business, for the way their users interact with these providers.
In fact, OAuth2 is more embracing. Client Credentials grant, one of several standard OAuth2 grants, provides the easy path for the traditional clients toward starting working with security tokens.
The client, instead of doing the authentication with a name and a password (or some other client credentials) against the target service endpoint on every request (and thus having to keep these secrets for a long time) does it only once, against OAuth2 AccessTokenService which accepts various grants and returns manageable tokens with a restricted lifetime. Such tokens can be obtained out-of-band, with the client applications initialized with the tokens. The client will use the token only when authenticating against the endpoint. It is still a secret in its own way but it is a transient one that can be revoked by the administrator or by the client itself.
The client credentials grant provides for an easy and fast way into the OAuth2 ecosystem. Consider experimenting with it sooner rather than waiting for another 5 years :-), discover the OAuth2 world along the way, find how OAuth2 can positively affect your applications, and never look back again !
In fact, OAuth2 is more embracing. Client Credentials grant, one of several standard OAuth2 grants, provides the easy path for the traditional clients toward starting working with security tokens.
The client, instead of doing the authentication with a name and a password (or some other client credentials) against the target service endpoint on every request (and thus having to keep these secrets for a long time) does it only once, against OAuth2 AccessTokenService which accepts various grants and returns manageable tokens with a restricted lifetime. Such tokens can be obtained out-of-band, with the client applications initialized with the tokens. The client will use the token only when authenticating against the endpoint. It is still a secret in its own way but it is a transient one that can be revoked by the administrator or by the client itself.
The client credentials grant provides for an easy and fast way into the OAuth2 ecosystem. Consider experimenting with it sooner rather than waiting for another 5 years :-), discover the OAuth2 world along the way, find how OAuth2 can positively affect your applications, and never look back again !
Sunday, November 23, 2014
Observations about ApacheCon EU 2014
You may be thinking now, after reading my previous post, that all I was doing at ApacheCon EU 2014 was looking at T-shirts people were wearing :-). This post is an attempt to convince you it was not the case.
First of all, ApacheCon EU 2014, as it is usually the case with Apache conferences, was a great opportunity to meet the fellow open source developers.
Chatting to the guys I work with at Apache CXF and other projects, sharing a joke or two along the way :-), was really great.
Some people there are great advocates of doing the software for the good of the world. You do see people there who spend their own free time to make Apache and various projects it hosts succeed and help others.
It was nice to see Talend, my employer, being mentioned as one of Apache sponsors. Even though Apache has great sponsors which contribute much more, it was good to see Talend being recognized. Every contribution counts. The companies involved in the open source have a positive vibe about them, the more they are involved the more recognized and respected in the community at large they become. The world is a small place. Customers would be positive about working with such companies, going the business with such companies, as this post posted awhile back suggested.
Those of us who did the presentations about CXF were lucky to do it on the very first day in a beautiful Corinthia Hotel Ballroom. I kept thinking, there were times people were dancing there accompanied by the music by Franz Liszt and here we are talking the cryptic things about CXF. The times change. But the beauty of the room is there today.
The other thing I noticed was the visibility of Hortonworks. They had a strong team presenting a number of interesting talks. To be fair to them, their T-shirts are also not bad at all :-), may be they should have some sort of the competition with Tomitribe.
Overall, it was a well organized, great event ! I'm feeling positive and energized after attending it.
First of all, ApacheCon EU 2014, as it is usually the case with Apache conferences, was a great opportunity to meet the fellow open source developers.
Chatting to the guys I work with at Apache CXF and other projects, sharing a joke or two along the way :-), was really great.
Some people there are great advocates of doing the software for the good of the world. You do see people there who spend their own free time to make Apache and various projects it hosts succeed and help others.
It was nice to see Talend, my employer, being mentioned as one of Apache sponsors. Even though Apache has great sponsors which contribute much more, it was good to see Talend being recognized. Every contribution counts. The companies involved in the open source have a positive vibe about them, the more they are involved the more recognized and respected in the community at large they become. The world is a small place. Customers would be positive about working with such companies, going the business with such companies, as this post posted awhile back suggested.
Those of us who did the presentations about CXF were lucky to do it on the very first day in a beautiful Corinthia Hotel Ballroom. I kept thinking, there were times people were dancing there accompanied by the music by Franz Liszt and here we are talking the cryptic things about CXF. The times change. But the beauty of the room is there today.
The other thing I noticed was the visibility of Hortonworks. They had a strong team presenting a number of interesting talks. To be fair to them, their T-shirts are also not bad at all :-), may be they should have some sort of the competition with Tomitribe.
Overall, it was a well organized, great event ! I'm feeling positive and energized after attending it.
[OT] The best T-shirt I've seen at Apache Con EU 2014
This is the first post about Apache Con EU 2014 held in beautiful Budapest I've been lucky to attend to.
One of the nice things about being an ApacheCon visitor is that one can see lots of cool T-shirts. The official T-shirts (I do treasure them) and other T-shirts with some great lines or digits printed on them. The T-shirts that many software geeks would be happy to wear. And indeed the visitors at ApacheCon EU 2014 had a lot of different T-shirts to demonstrate.
It was at the presentation about TomEE that I realized that while the rest of the room were glued to the presentation screen and being impressed by what TomEE could do I was looking at the T-shirts of TomEE experts doing the presentation and thinking how unfair it was I did not have a T-shirt like that too.
You can see Romain wearing it here.
Tomitribe, the company which did it right once again :-) !
One of the nice things about being an ApacheCon visitor is that one can see lots of cool T-shirts. The official T-shirts (I do treasure them) and other T-shirts with some great lines or digits printed on them. The T-shirts that many software geeks would be happy to wear. And indeed the visitors at ApacheCon EU 2014 had a lot of different T-shirts to demonstrate.
It was at the presentation about TomEE that I realized that while the rest of the room were glued to the presentation screen and being impressed by what TomEE could do I was looking at the T-shirts of TomEE experts doing the presentation and thinking how unfair it was I did not have a T-shirt like that too.
You can see Romain wearing it here.
Tomitribe, the company which did it right once again :-) !
Wednesday, November 12, 2014
Meet the CXF team at ApacheCon EU
ApacheCon EU will be held next week in Budapest, the nice capital of Hungary, and a number of my Talend and CXF colleagues will be there talking about CXF, Fediz, Syncope.
Please check the schedule.
Apache will be starting celebrating its 15th anniversary at the conference too, it is amazing that the organization is relatively young, I thought it has been around for much longer given how popular and visible Apache is.
It is going to be exciting though I'm already getting a bit nervous as I usually do when I'm about to present :-).
Here is some information about the presentations I will do.
The first one is called JAX-RS 2.0 with Apache CXF Continued - I did a similar presentation in Denver in April and hence it has a "Continued" in the title but I'd like to confirm it is not a copy and paste of the original presentation, I tried to rework the slides and update the examples. Check the link and see if it can be of interest - I will talk about JAX-RS, JAX-RS 2.0, with plenty of code examples to be shown along the way.
The second one is called From OAuth1 to OAuth2 with Apache CXF and Hawk. I hope people who are interested in OAuth will find the presentation being entertaining enough. Note it will not be about "OAuth2 being not good enough, Hawk is to the rescue till OAuth3 arrives", nothing like that. The presentation will be about the extensibility of OAuth2, while giving the due credit to OAuth1 and indeed Hawk which can serve as a neat bridge for OAuth1 developers wondering if it makes sense to move to OAuth2 or not. The latest OAuth2 Proof-Of-Possession (POP) effort will be briefly described too.
See you at the conference !
Please check the schedule.
Apache will be starting celebrating its 15th anniversary at the conference too, it is amazing that the organization is relatively young, I thought it has been around for much longer given how popular and visible Apache is.
It is going to be exciting though I'm already getting a bit nervous as I usually do when I'm about to present :-).
Here is some information about the presentations I will do.
The first one is called JAX-RS 2.0 with Apache CXF Continued - I did a similar presentation in Denver in April and hence it has a "Continued" in the title but I'd like to confirm it is not a copy and paste of the original presentation, I tried to rework the slides and update the examples. Check the link and see if it can be of interest - I will talk about JAX-RS, JAX-RS 2.0, with plenty of code examples to be shown along the way.
The second one is called From OAuth1 to OAuth2 with Apache CXF and Hawk. I hope people who are interested in OAuth will find the presentation being entertaining enough. Note it will not be about "OAuth2 being not good enough, Hawk is to the rescue till OAuth3 arrives", nothing like that. The presentation will be about the extensibility of OAuth2, while giving the due credit to OAuth1 and indeed Hawk which can serve as a neat bridge for OAuth1 developers wondering if it makes sense to move to OAuth2 or not. The latest OAuth2 Proof-Of-Possession (POP) effort will be briefly described too.
See you at the conference !
Thursday, October 30, 2014
JSR-370: Even Better JAX-RS on the way
No doubt JAX-RS 2.0 (JSR-339) has been, is and will be a success - a lot has been written about the top features JAX-RS 2.0 offers. It is still very much a relevant story for many developers who have their REST services being migrated to JAX-RS 2.0, it is not always easy for a given production to switch to a new specification's API fast.
But JAX-RS 2.0 is not the end of JAX-RS as such. So the fact JSR-370 (JAX-RS 2.1) is now active is a very good news for all of us working with or interested in JAX-RS.
Have a look at the "Request" section and check the list of the improvements and new features that the specification will cover. Good stuff. Note the effort will be made to have JAX-RS applications much better prepared for supporting Web-based UI frontends. Another thing to note is the fact it will be Java 8 based so expect Java 8 features making themselves visible in JAX-RS 2.1 API, Marek and Santiago will come up with some very cool API ideas.
All is great in the JAX-RS space. Explore it and enjoy !
But JAX-RS 2.0 is not the end of JAX-RS as such. So the fact JSR-370 (JAX-RS 2.1) is now active is a very good news for all of us working with or interested in JAX-RS.
Have a look at the "Request" section and check the list of the improvements and new features that the specification will cover. Good stuff. Note the effort will be made to have JAX-RS applications much better prepared for supporting Web-based UI frontends. Another thing to note is the fact it will be Java 8 based so expect Java 8 features making themselves visible in JAX-RS 2.1 API, Marek and Santiago will come up with some very cool API ideas.
All is great in the JAX-RS space. Explore it and enjoy !
Wednesday, October 15, 2014
CXF becomes friends with Tika and Lucene
You may have been thinking for a while: would it actually be cool to get some experience with Apache Lucene and Apache Tika and enhance the JAX-RS services you work upon along the way ? Lucene and Tika are those cool projects people are talking about but as it happens there has never been an opportunity to use them in your project...
Apache Lucene is a well known project where its community keeps innovating with improving and optimizing the capabilities of various text analyzers. Apache Tika is a cool project which can be used to get the metadata and content out of binary resources with formats such as PDF, ODT, etc, with lots of other formats being supported. As a side note, Apache Tika is not only a cool project, it is also a very democratic project where everyone is welcomed from the get go - the perfect project to start your Apache career if you think of starting involved into one of the Apache projects.
Now, a number of services you have written may be supporting uploads of the binary resources, for example, you may have a JAX-RS server accepting multipart/form-data uploads.
As it happens, Lucene plus Tika is what one needs to be able to analyze the binary content easily and effectively. Tika would give you the metadata and the content, Lucene will tokenize it and help search over it. As such you can let your users search and download only those PDF or other binary resources which match the search query. It is something your users will appreciate.
CXF 3.1.0 which is under the active development offers a utility support for working with Tika and Lucene. Andriy Redko worked on improving the integration with Lucene and introducing a content extraction support with the help of Tika. It is all shown in a nice jax_rs/search demo which offers a Bootstrap UI for uploading, searching and downloading of PDF and ODT files. The demo will be shipped in the CXF distribution.
Please start experimenting today with the demo (download CXF 3.1.0-SNAPSHOT distribution), let us know what you think, and get your JAX-RS project to the next level.
You are also encouraged to experiment with Apache Solr which offers an advanced search engine on top of Lucene, with Tika also being utilized.
Enjoy!
Apache Lucene is a well known project where its community keeps innovating with improving and optimizing the capabilities of various text analyzers. Apache Tika is a cool project which can be used to get the metadata and content out of binary resources with formats such as PDF, ODT, etc, with lots of other formats being supported. As a side note, Apache Tika is not only a cool project, it is also a very democratic project where everyone is welcomed from the get go - the perfect project to start your Apache career if you think of starting involved into one of the Apache projects.
Now, a number of services you have written may be supporting uploads of the binary resources, for example, you may have a JAX-RS server accepting multipart/form-data uploads.
As it happens, Lucene plus Tika is what one needs to be able to analyze the binary content easily and effectively. Tika would give you the metadata and the content, Lucene will tokenize it and help search over it. As such you can let your users search and download only those PDF or other binary resources which match the search query. It is something your users will appreciate.
CXF 3.1.0 which is under the active development offers a utility support for working with Tika and Lucene. Andriy Redko worked on improving the integration with Lucene and introducing a content extraction support with the help of Tika. It is all shown in a nice jax_rs/search demo which offers a Bootstrap UI for uploading, searching and downloading of PDF and ODT files. The demo will be shipped in the CXF distribution.
Please start experimenting today with the demo (download CXF 3.1.0-SNAPSHOT distribution), let us know what you think, and get your JAX-RS project to the next level.
You are also encouraged to experiment with Apache Solr which offers an advanced search engine on top of Lucene, with Tika also being utilized.
Enjoy!
Tuesday, August 19, 2014
[OT] Wake Up To CXF Revolution !
It's the end of the summer, still warm outside, and your friends from the Big Data team have millions of millions of records processed per second with Hadoop and give the happy smiles of those who are doing something new and cool. And you have GET, POST, may be PUT, then again GET. Occasional DELETE and if you are really lucky, you've got PATCH in the logs. You are starting wondering, is it really still cool, be a web service developer, does anyone care, what is new here ? Apache CXF has been around for so many years. What is next ?
Keeping a project such as Apache CXF alive and healthy for a long time is not an easy task. Dan, the lead, gave a nice presentation about Apache CXF in Denver, about the work we have done to keep CXF relevant and up-to-date. Dan did not mention it during the presentation: Apache CXF dependencies are always up to date, with the project being constantly aligned, optimized and having the workarounds in place should a given underlying module prove too rigid in supporting CXF in doing what it should do. CXF is a well-oiled, fast web services engine thanks to Dan.
This is all good you may say, but what is next ? What revolution am I talking about ? JAX-WS is not evolving, JAX-RS is not exactly new either. You can even say, CXF is old ? Well, the CXF fire is as alive as ever, the revolution is brewing, CXF is going to get to the next level where it will become one of the de-facto choices for writing new, secure, user-centric HTTP services. The need for such services will only keep growing.
The industry is not sleeping, lots of new exciting technologies are being developed: OAuth2, JOSE, WebCrypto, OpenId-Connect. It's all incredibly cool. It's new. It's only a beginning of the long development life-cycle. Apache CXF wants to be there.
And finally to the [OT] moment: Arcade Fire is fantastic group. Wake Up. Wake Up to the Next CXF Revolution, be part of it, and give your friends that happy smile again ! Tell your grandchildren you were there when it started (LOL while I'm typing it).
Have Fun !
Keeping a project such as Apache CXF alive and healthy for a long time is not an easy task. Dan, the lead, gave a nice presentation about Apache CXF in Denver, about the work we have done to keep CXF relevant and up-to-date. Dan did not mention it during the presentation: Apache CXF dependencies are always up to date, with the project being constantly aligned, optimized and having the workarounds in place should a given underlying module prove too rigid in supporting CXF in doing what it should do. CXF is a well-oiled, fast web services engine thanks to Dan.
This is all good you may say, but what is next ? What revolution am I talking about ? JAX-WS is not evolving, JAX-RS is not exactly new either. You can even say, CXF is old ? Well, the CXF fire is as alive as ever, the revolution is brewing, CXF is going to get to the next level where it will become one of the de-facto choices for writing new, secure, user-centric HTTP services. The need for such services will only keep growing.
The industry is not sleeping, lots of new exciting technologies are being developed: OAuth2, JOSE, WebCrypto, OpenId-Connect. It's all incredibly cool. It's new. It's only a beginning of the long development life-cycle. Apache CXF wants to be there.
And finally to the [OT] moment: Arcade Fire is fantastic group. Wake Up. Wake Up to the Next CXF Revolution, be part of it, and give your friends that happy smile again ! Tell your grandchildren you were there when it started (LOL while I'm typing it).
Have Fun !
Friday, August 15, 2014
Learn JOSE and become a better Web Service Developer
The work around OAuth2 and JOSE in particular has inspired me.
So much that I've ordered several books from Amazon.co.uk - and it's been quite a while since the idea of buying a book occurred to me; and several books in the age of Google ? - see, it did inspire me.
Sometimes we the developers think that we know all and if not all then we think we won't need that extra piece of knowledge, being the experts we are. The software engineering is not easy. We have the deadlines and our regular work to be well taken care of. No time for reading the books: the more busier and older we become the less time we have.
This is why I like OAuth2 and JOSE. JOSE, specifically, is a very fine effort, it represents a set of nicely aligned specifications tackling the various issues related to signing and encrypting the arbitrary payloads and using simple and effective JSON metadata to describe the signature and encryption operations. It's led by the people who understand what they do. JOSE deals only with the best/most trusted/most understood signature and encryption algorithms. It's a set of 'books' about the latest in the cryptography.
It is already starting and will affect the way we do secure HTTP services. I already claimed it in the earlier post about OAuth2 and repeat it again here.
Learn JOSE, understand it, start using it, become a better engineer !
So much that I've ordered several books from Amazon.co.uk - and it's been quite a while since the idea of buying a book occurred to me; and several books in the age of Google ? - see, it did inspire me.
Sometimes we the developers think that we know all and if not all then we think we won't need that extra piece of knowledge, being the experts we are. The software engineering is not easy. We have the deadlines and our regular work to be well taken care of. No time for reading the books: the more busier and older we become the less time we have.
This is why I like OAuth2 and JOSE. JOSE, specifically, is a very fine effort, it represents a set of nicely aligned specifications tackling the various issues related to signing and encrypting the arbitrary payloads and using simple and effective JSON metadata to describe the signature and encryption operations. It's led by the people who understand what they do. JOSE deals only with the best/most trusted/most understood signature and encryption algorithms. It's a set of 'books' about the latest in the cryptography.
It is already starting and will affect the way we do secure HTTP services. I already claimed it in the earlier post about OAuth2 and repeat it again here.
Learn JOSE, understand it, start using it, become a better engineer !
JAX-RS is not only about REST
I've been planning to post this 'philosophical' piece for a while.
The JAX-RS specification (Java API for RESTful services) has really got off the ground long time ago. JAX-RS 2.0 with its new brilliant features, with three JAX-RS 2.0 frameworks around (there will possibly be more, we never know), is and will further contribute to the popularity of JAX-RS.
JAX-RS 2.1 work will go ahead soon enough and it will be another great specification, I've no doubt the spec leads will take care of making that happen, same way they did for 2.0 :-).
The central line of this blog though is that JAX-RS is actually not only about REST. It may sound like a shock to some people but the beauty of this specification is that it has completely re-opened the HTTP web service development space and will continue doing so for quite a few more years to come.
It's an important fact: developers always want to do something new, even though it's a fact that existing Web service technologies has proven to be able to deliver: many many people have written SOAP endpoints that work, many many people have designed endpoints according to REST style, the WEB rules. But REST is not the end of the web services road, it is only a set of proven rules.
We all know many JAX-RS endpoints are not necessarily that RESTful, in a a nutshell they support simple HTTP endpoints, often with 2 HTTP verbs only max - and it is absolutely OK: JAX-RS does and will help no matter how far one would like to go in their HTTP endpoint design.
The JAX-RS specification (Java API for RESTful services) has really got off the ground long time ago. JAX-RS 2.0 with its new brilliant features, with three JAX-RS 2.0 frameworks around (there will possibly be more, we never know), is and will further contribute to the popularity of JAX-RS.
JAX-RS 2.1 work will go ahead soon enough and it will be another great specification, I've no doubt the spec leads will take care of making that happen, same way they did for 2.0 :-).
The central line of this blog though is that JAX-RS is actually not only about REST. It may sound like a shock to some people but the beauty of this specification is that it has completely re-opened the HTTP web service development space and will continue doing so for quite a few more years to come.
It's an important fact: developers always want to do something new, even though it's a fact that existing Web service technologies has proven to be able to deliver: many many people have written SOAP endpoints that work, many many people have designed endpoints according to REST style, the WEB rules. But REST is not the end of the web services road, it is only a set of proven rules.
We all know many JAX-RS endpoints are not necessarily that RESTful, in a a nutshell they support simple HTTP endpoints, often with 2 HTTP verbs only max - and it is absolutely OK: JAX-RS does and will help no matter how far one would like to go in their HTTP endpoint design.
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.
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 !
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 :-)
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.
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...
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.
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.
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.
Subscribe to:
Posts (Atom)
