Sergey Beryozkin

Subscribe to Sergey Beryozkin feed
Sergey Beryozkin
Updated: 10 hours 9 min ago

Stateless OAuth2 providers in CXF 3.0.0

Mon, 02/03/2014 - 19:00
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,
Categories: Sergey Beryozkin

CXF 3.0.0 Milestone1 is out !

Fri, 11/29/2013 - 17:34
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 !
Categories: Sergey Beryozkin

CXF 3.0 Trunk is JAX-RS 2.0 Ready

Thu, 08/29/2013 - 11:45
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 !

Categories: Sergey Beryozkin

JAX-RS 2.0 is out !

Thu, 06/13/2013 - 23:14
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 !

Categories: Sergey Beryozkin

[OT] Apache CXF is more than just a library, you know!

Thu, 04/04/2013 - 22:46
Those of you living in Ireland who tune to listen to a brilliant NewsTalk team will recognize where I've got the idea for this regular, first half of the year, off-topic post :-), indeed, it is from NewsTalk being "more than just news, you know!".

So I got inspired and decided to do this short entry and suggest to you, the developers of web services, that CXF is more just a library,

It is the home, blueprint for developing the modern, secure web service applications.

Categories: Sergey Beryozkin

On the way to making CXF JAX-RS run easily in your application container

Thu, 04/04/2013 - 22:32
Awhile back I posted an entry on how to get CXF JAX-RS loaded successfully within your favorite Java EE application container, and specifically within the containers like JBoss or Glassfish which have their preferred JAX-RS implementations actively supported.

I think it was a good enough initial step but it proved to be quite incomplete, with users reporting CXF failing to handle the objects of some of JAX-RS core types like Response.

In this rather technical post I will give an update on the situation.

What typically happens is that when Glassfish or JBoss loads a CXF-enabled application, the active subsystem (Jersey or RestEasy based) will still intercept the runtime  or application code doing a code like "Response.ok().build()" - this static sequence of calls will end up being processed by this subsystem which leads to a somewhat unusual case, where the CXF runtime ends up processing 'foreign' JAX-RS Response objects - attempting to cast to the CXF-aware Response object breaks the application.

So what we've decided to do now is to start working on making CXF JAX-RS completely isolated from the loaded third-party JAX-RS libraries, by minimizing and when possible completely removing the calls like "Response.fromResponse" which lead to the 3rd party subsystems intercepting the control. This makes CXF JAX-RS more robust when loaded alongside other JAX-RS runtimes, and also marginally faster - the cost of getting from the static code sequence to the actual Response builder implementation capable of producing Response is not completely negligible.

This is not possible to avoid completely - for example, you custom filter, exception mapper or indeed the user code will inevitably create a JAX-RS Response instance which will be 'foreign' to the CXF runtime.  In these cases CXF will simply copy such Responses into its own Response implementation. 

I hope it will make it very easy eventually to get CXF JAX-RS up and running in the latest JBoss and Glassfish distributions, due to it becoming effectively self-contained. Some more runtime code modifications may prove to be required but IMHO we are on the right path.

It is very well understood that for a given container it makes a lot of sense to optimize around a selected JAX-RS implementation, specifically in case of JBoss and Glassfish we are talking about well-known and recognized implementations.

This effort is all about helping those users who have decided to work with CXF JAX-RS in these containers continue doing so - this is all to it really :-).

Categories: Sergey Beryozkin

Use SAML2 Assertions as OAuth2 Token Grants or Authenticators with CXF

Tue, 03/05/2013 - 12:07
OAuth2 allows third-party clients to use different types of grants in order to request access tokens. The specification defines a number of grant types to get some specific flows supported, but also allows for extensions - one can use whatever custom grant is required in a particular scenario.

SAML2 Bearer Assertion Profiles  and JWT Bearer Token Profiles standardize  two such extension grants, SAML2 Bearer Assertions and JWT Bearer Tokens grants, which can be used like any other OAuth 2.0 grants in order to request new access tokens. In addition, these documents specify how SAML2 Bearer Assertions and JWT Bearer Tokens can be used as client authentication credentials, irrespectively of the actual token grant type.

The use of SAML2 Bearer Assertions in particular is likely to get more immediate traction given that SAML2 Identity Providers are deployed in many productions, though no doubt JWT is going to be become much more visible going forward.

I think it is fare to say that it is the introduction of SAML2 into an OAuth 2.0 'space' that led some experts to start talking about the increased complexity of OAuth 2.0 compared to OAuth 1.0. One can definitely agree that working with SAML is more complex than with simple tokens.That said it is not a default token type after all - it is really about getting the Identity Providers which are already deployed be 'involved' which is always important - if that is not something that is needed for your case then no SAML2 assertions have to be used at all.

You may want to check SalesForce and PingIdentity documentation for more information on how to get SAML2 assertions utilized with OAuth2 servers.

Apache CXF OAuth2 module introduces an initial support for using SAML2 Bearer Assertions as grants and authenticators. Please check the documentation, see how easy it is to get the client code to use SAML2 assertions, start experimenting with the code and plan moving your OAuth2 project to the next level :-)

Categories: Sergey Beryozkin

FIQL explained in JAX Magazine tutorial

Mon, 02/18/2013 - 13:16
JAX magazine for Java developers features articles and tutorials which can help to get the most of all the new and cool technologies and developments happening in the Java land today.

The latest issue offers, among other features, the tutorial introducing FIQL and how it is currently supported in Apache CXF. Please download the issue as a PDF or get it over your preferred channel (on iTunes, etc), and see what you can do with FIQL - and provide the valuable feedback.

Categories: Sergey Beryozkin

Jettison 1.3.3 is out

Tue, 01/29/2013 - 23:41
Jettison 1.3.3 has been released earlier this month, please check the Download page.

This release ships a better MappedXMLStreamReader: arrays to be mapped to primitive collections in JAXB beans can be correctly processed without the loss of the data, some if its methods dealing with text will work properly as expected and the callers can identify an absolute position of the first illegal JSON character after XMLStreamException has been thrown.

As usual, I'd like to thank the users who have reported the issues against Jettison and would like to encourage to get the patches provided.

I think over the time it has become clearer to me why Jettison is still being used, at least by some of CXF users, even though such powerful and popular processors as Jackson exist. Jettison is a very lightweight library, it has just few basic STAX XMLStreamReader and XMLStreamWriter implementations: this alone is not sufficient to produce a perfect JSON. But in CXF at least Jettison can be customized a lot to make it produce if not perfect but close enough JSON sequences.

This is what keeps it visible really in CXF land at least IMHO - the fact that the users can use it to write or read simple sequences (with many JSON consumers actually expecting simple enough sequences) but also nearly completely control the way a given sequence is produced or consumed. For example, people are talking about backward and forward compatibility with respect to processing XML - same can be achieved for JSON in CXF, all without code-related changes.

This is where its niche is, a bridge between JAXB and JSON, simple to medium complexity sequences, the possibility of the easy enough customization.

If you work with Jettison: please test the latest release and provide the feedback, thanks     
Categories: Sergey Beryozkin

Say Goodbye to HTTP URI Query Parameters

Fri, 12/28/2012 - 17:41
New Year is approaching fast but there is still some time to make one more New Year resolution.

Traditionally, when it comes to expressing the search requirements with HTTP URI, one uses URI query name and value, for example:

1. "/search/people?age=30&age=40"
2. "/search/people?ageFrom=30&ageTill=40"

First query can be read like this: "Find all people who are either 30 or 40 years old", the second - "Find all people older than 30 but younger than 40".

Plain query parameters are very widely used and actually very 'capable', one can invent a query parameter such as "ageFrom" to indicate the conditional requirement. It is not quite perfect in that the actual operator is "=" but the name implies it is not "equal to" but "greater or equal to", but it works, and probably reads better in some cases.

That said, the bigger the number of terms, the more tedious it can become to support creating the parameters like "ageFrom" and writing the actual code for figuring out which parameter means whether it is indeed the equality check as in "age=30" or say a "greater than" check as in "ageFrom=30". Supporting the finer-level checks such as "greater or equal to", as well as combining multiple type of checks can indeed become difficult to manage at the code level.

Consider always using FIQL expressions:

1. "/search/people?_s=age==30;age=40"
1.1 "/search/people?age==30;age=40"
1.2 "/search/people/age==30;age=40"

2. "/search/people?_s=age=ge=30;age=lt=40"
2.1 "/search/people?age=ge=30;age=lt=40"
2.2 "/search/people/age=ge=30;age=lt=40"

Does it look more complex ? I don't think it does but I can agree it may look a bit unusual at first, though the syntax is actually very easy to understand after typing it  just for a bit of time.

Note a number of possible variations - in fact I guess I like options 1.2 and 2.2 most, the "optionality" aspect of URI query components does not make the whole URI represent a specific application state very cleanly (options 1, 1.1, 2, 2.1).

Also note the fine-level checks in 2.1/2.2 which are tricky to express with the plain queries, example, in this case it is "Find all people 30 years old or older but younger than 40 (exclusive)".

If you think about it, you have nothing to lose by starting using FIQL, for many cases it is nearly as simple and primitive as using plain query name and value pairs but the bonus comes immediately once you start expressing something more involved. As noted at the beginning of this post, plain queries are also capable in this regard - but the more complex the search requirements are - the less easy it becomes working with the plain queries.

Those Apache CXF users who have started experimenting with FIQL can utilize the existing FIQL converters, which is another plus point, consider the task of writing the code for converting plain query parameters to JPA2 expressions - it can be an involved task indeed - but with CXF JPA2 converter it is a walk in the park; as a side note - JPA2 converter now supports "count" extensions, for example, "find all the people living in London with more than 6 children".

Well, you may not be convinced that it is time to drop plain query name and value pairs. Never mind, just get CXF converting them internally to FIQL (which is very easy to do for CXF given that FIQL is a richer language, and still rely on the handy FIQL converters of your choice to interact with the data stores and completely generalize the search processing logic along the way. Offer different search endpoints for your users to enjoy working with, one accepting the traditional queries and another one accepting FIQL queries, with both endpoints using the same FIQL converters.

Still plenty of options to innovate in this well-explored space :-)!

Update: See also this earlier post from Abhishek Jain.

Happy New Year !

Categories: Sergey Beryozkin

FIQL and JPA2 Queries In Action

Wed, 12/12/2012 - 12:55
I've been focusing quite a lot recently on enhancing CXF Search extension module, by improving the existing converters and creating the new ones, making sure the parser is configurable, flexible and capable of mapping arbitrary property names to the properties of the bean capturing the search expression, and improving the documentation.

Andy Michalec created a FIQL parser quite a long time ago, it's been around for a while really, but it is only since Jeff Wang provided an initial FIQL to JPA2 converter patch that it kind of struck me how important it was to ensure the utility converters for mainstream and most popular technologies for querying the data stores were available. 

With all the documentation and code improvements, it is still not quite good till it is actually demonstrated somehow, and this is exactly what I've spent the last few days upon, on enhancing the existing Talend ESB jaxrs-advanced demo to show how the client can type the queries with SearchConditionBuilder without having to type FIQL expressions manually and get the expressions seamlessly converted to JPA2 TypedQuery and CriteriaQuery, with Tuple mixed in, and the matching data returned to the client, all with the help of FIQL to JPA2 converter.

Let me comment on the actual demo enhancements in more detail.

First check the client code, the "useSearchService" function, starting from the line 194 and more specifically from line 205. IMHO expressing the query with the help of the fluent query builder (also created by Andy) is quite cool, it is definitely more descriptive with respect to what is actually expected, and it is the specific query language agnostic, it is FIQL by default but can be something else.
The builder can build whatever advanced query expression is needed, though practically speaking I would not expect massive expressions being created.

Now lets move to the server code. SearchService is one which actually handles the client requests and all it does it delegates to PersonInfoStorage which deals with querying the data. Note, SearchService works with CXF SearchContext  by expecting it to extract the search expression from the current URI query component (default mode) or getting the expression from URI path and submitting it to SearchContext.

The main and in fact the single demo domain entity is Person but it is the one which is recursive, with children and parents, ancestors and descendants linked to. I haven't modified these relationships to get CXF JPA2 converter working properly, the only thing I did I added a couple of missing Person setters, added JPA2 annotations and also a hack required for JAXB RI capable of dealing with recursive structures (see the end of Person code).

The Person model is initialized in PersonInfoStorage init method (see the end of the file), where the injected JPA2 EntityManager is used - it could've been done elsewhere but was good enough for me for the purpose of the demo.

Next check getTypedQueryPerson (line 68) - see how straightforward it is  to get the FIQL expression transparently converted to JPA2 TypedQuery, the comments in the code should make it very easy to understand.

Note, Person is a recursive and possibly a very deep structure and one may not necessarily want to fetch all the Person representation back to the client. A number of options exists for dealing with this issue including using the intrusive JAXB XmlTransient annotation but using JPA2 Tuple is one of the most elegant ones.

Using Tuple is one of JPA2 options for having the response shaped into simpler or different structures and getCriteriaQueryPerson  method shows how it can be easily done by having the query returning the data sufficient for initializing a simple PersonInfo representation. One needs to get OpenJPA auto-generating the
metamodel classes for the tuple selections working and you can see how it can be done here, this tip helped me a lot. 

Also note that PersonInfoStorage has the injected bean properties passed to SearchContext. Why this may have to be done is explained here but in short it lets to get the property names used in query language completely decoupled from the corresponding properties of the capturing bean, for example, in the demo case, the client can type "'childName').equalTo('Fred')" and have it working with the 'childName'  correctly mapped to "", where "children" points to a Person collection of children. This makes it simpler and easier to work with for the client, while keeping the internals of how the properties are actually linked to each other completely opaque. That is cool, I can hear you saying :-)

Finally have a look at how JPA2 EntityManager is initialized and injected. I started with arguably a simpler approach, I basically used Spring ORM module to get the entity manager wired in, see this beans.xml.  This actually back-fired on me when I tried to make the demo working in Karaf - Spring ORM needs to see persistence.xml and is not capable on its own of inspecting OSGI Meta-Persistence property set up in the common module's pom.xml so I just ended up duplicating persistence.xml in both common and service modules.

On the TODO list is to follow an excellent tutorial from Christian and make the demo working with OSGi JPA Service. Perhaps someone from the community will be interested in doing a related pull request ?
So this is it and hope you'll find something interesting in this demo, enjoy !  
Categories: Sergey Beryozkin

Use FIQL to query LDAP and OSGI containers

Fri, 11/30/2012 - 17:47
It has taken me about 90 minutes to write an initial FIQL to LDAP converter which outputs the query formatted according to RFC 4515 and document it here.

I have copied most of the boiler-plate code from the FIQL to SQL converter and given how simple the LDAP query is it was very easy to finish it off fast. The point is that other custom converters (example FIQL to CQL) can likely be written even faster by copying and pasting the LDAP converter :-).

More work will likely need to be done to get RFC-4515 supported completely, but the converter should already be capable to support many simple or composite LDAP queries which do not use complex characters, etc.

You may want to ask why would not one support LDAP query language by directly encoding it into request URIs. There are two issues here, first, the LDAP language is not quite URI friendly, the second one is that it will leak the details about the data technology supporting a given REST endpoint.

This is why FIQL or other dedicated language like OData is the way to go for doing medium complexity queries over HTTP. It is easy to read and it lets the users completely encapsulate the data source details.

I think with this latest update CXF Search extension has enough 'material' for users to start experimenting with using FIQL on top of the well-known and traditional data sources.

I can nearly see some of you starting thinking of creating some cool UI search module which will let users do more interesting search queries over the containers such as LDAP stores or OSGI runtimes with this new converter and may be even sharing the tested queries with the other users who may find it useful.

The next phase is to get FIQL a bit closer to all those No SQL data stores and it should be quite interesting.

Watch this space :-)

Categories: Sergey Beryozkin

[OT] Just Say Yes to CXF

Thu, 11/29/2012 - 23:05
This is a regular, once or so per year, totally off-topic post dedicated to linking the music I listen to to CXF :-)

The New Year is coming soon, time to start thinking about the next year, about the decisions which will make the professional life of developers working with web services front-ends something to really look forward to.

It has never been easy to choose which framework to use to get web services up and running. It is tough. At a decision time like this one, when it is cold outside, it is good to listen to Snow Patrol, which is one of my favorite bands.

Some of their music is absolutely brilliant. Listen to it, think about it, and Just Say Yes to CXF.

I've had some fun writing this post :-), hope you'll have some fun too !
Categories: Sergey Beryozkin

How to refresh OAuth2 access tokens in CXF

Thu, 11/22/2012 - 14:40
OAuth2 Refresh Token grant lets OAuth2 clients owning an access token refresh it with a new access token if the current attempt to access the end user's resources has failed.

Refresh tokens offer an advanced support for the OAuth2-protected applications to force the clients to re-authenticate regularly without forcing them to go via the re-authorization step involving the end user which may not always be practical. 

They can also help with effectively getting the original access tokens revoked and replaced with the modified access tokens, example, with the new opaque scopes limiting or extending the current client permissions or even replacing the token type itself, example, replacing Bearer with MAC, all dynamically.

During the refresh process, the actual refresh token may also be 'renewed' with the new value by having the so-called key-rotation scheme implemented.

One possible approach is to have a short-lived access token and long-lived refresh token. Whenever the access token expires the client is forced to refresh with a valid refresh token and re-authenticate along the way.

I'd like to encourage developers to check OAuth2 archives on some interesting insights from the security experts on why using refresh tokens might benefit a particular OAuth2 application.

All this sounds good but you may want to ask, how to actually work with the refresh token in practice, specifically with CXF ?

It is a child's play though I guess I should not refer to such an advanced feature like that :-).

Whenever your custom  OAuthDataProvider returns a new ServerAccessToken, a client-centric ClientAccessToken representation is returned to the client. At this point of time the data provider may choose to offer a refresh token too, which will be made available to the client.

On the server the refresh tokens are bound to a specific Client instance,  I'm considering updating the Client model class to actually keep a list of refresh tokens, I'm not exactly sure yet if it will make it easier for the implementers or not, but in meantime one would need to keep a dedicated table joining client id plus the refresh and access token pairs.  

So, the client will use the access token to access the end user's resources and at some point the access request will fail due to the access token expiring. All one needs to do now is to issue a Refresh Token grant request to OAuth2 Access Token Service, and then do a single retry using a newly obtained access token.
This is all to it.

Please check the Client-side support section for the new example showing this retry attempt pseudo code, as well as review on how well-known OAuth2 grants can be currently supported in CXF.

Categories: Sergey Beryozkin

Latest WADL To Java enhancements in CXF

Fri, 10/12/2012 - 14:17
Dan has released CXF 2.7.0 which has some major enhancements including the addition of the asynchronous HTTP conduit and initial support for most parts of JAX-RS 2.0 (the topic of the next post on this blog).

What I'd like to mention in this post is the few enhancements to CXF wadl-to-java code generator, added thanks to the colleagues from Talend ESB team who have been stressing the generator to the limits :-).

One of the issues with processing complex WADL documents is that it is not obvious whether (URI) path parameters attached to one of the parent resource elements have to be inherited when generating the method signatures for descendant resources, for example:

<param name="id" style="template"/>
<method name="GET">
<method name="POST">

Does the user want a generated method signature corresponding to "POST" contain an 'id' parameter or only have it added when a "GET" method available directly under the parent resource is processed ?  By default CXF does not add the current parameters to all the descendant methods. Note, WADL provides a mechanism to link to global parameter declarations from within individual methods but if restructuring a given document is not ideal then a new "inheritResourceParams" property will help.

Here is another issue one may face. Suppose you have an XML representation in the schema and the generated code will reference a JAXB-generated class name, say, "books.Book" class. What if you'd like a JAXP Source be used instead ? And what if you have a representation which has "multipart/form-data" payload, it is not 'fair' having no reference to whatever class may be able to handle this payload added to the generated code.

No problems, it is going to be easy with a new "repMap" (the representation map) property, for example, it may have pairs like "application/xml : javax.xml.transform.Source" and "multipart/form-data : org.apache.cxf.jaxrs.ext.multipart.MultipartBody". Note this property is effective when a given representation has no actual reference to a schema element, which is the case for all non-XML representations.

Now, suppose you have a jaxb binding document overriding the name of the class to be generated by JAXB and the generator missing on it,  or you have to 'override' an XML representation linking to the scheme element for the latter be handled by JAXP Source. This is where a new "tMap" parameter will become handy.

Please experiment with the above options, I know some users have already tried them and hope they will be of real help.

As far as WADL itself is concerned...As you know it has not been made a standard yet. However with the original wadl-to-java project at Oracle being under the active development and the CXF generator being regularly enhanced it is likely to become more and more useful tool for testers and for users of WADL-'aware' RESTful endpoints. Don't be concerned too much that WADL is not going to accepted at the universal mechanism for describing and working with RESTful services - it has its niche and hopefully it will make it into becoming a final recommendation one day.


Categories: Sergey Beryozkin

OAuth2 MAC Access Token support in CXF

Fri, 09/21/2012 - 14:27
OAuth2 offers a clear differentiation between token grants and token types. Grant is what Access Token service will verify before issuing a token, and the best thing about it is that the same code path is used irrespectively of whatever grant or token is used.

OAuth2 mentions simple bearer tokens as default token types, but of course the bearer is not the only token type possible.

Eran Hammer-Lahav wrote a MAC Access Authentication draft  which introduces a MAC authentication scheme and describes how it can be used in OAuth2.

OAuth2 experts are considering whether this effort has to be completed or not. I'd like to encourage those who are interested to check OAuth2 mail archives for different opinions expressed regarding the MAC scheme.

Here is my opinion for whatever it is worth:

- What is important is that OAuth2 offers a pluggable mechanism for different token types so I think users should be encouraged to experiment with new token types, MAC in this case, and see if it makes the flows more secure, and 'contribute' to the idea of completing the effort from Eran by talking about possible issues or advantages of this scheme (such as: is it simpler to operate than tokens like JWT, or is it a reasonable alternative to JWT, etc) - remember, it is still the same code path for client and server applications, only a different token type.

- Having it completed will encourage OAuth1.0 users migrate to OAuth2.0, because OAuth2.0 with MAC is a much simpler version of OAuth1.0 - MAC scheme offers a simple holder-of-key support and combined with HTTPS it makes the exchanges between clients and OAuth2 services more secure.

- It will be a good idea to complete the effort any way, some implementers will ignore it but some will like.

Sasi M. has contributed the initial MAC Token implementation to Apache CXF, thanks! The documentation is available here.  Please try this token type in the applications, it is really easy to work with. Also, we'd be open to contributing the MAC-specific code to a dedicated 3rd party module if it will be useful to have the one - the details can be discussed at the CXF dev list. That said - it is just a couple of utility classes that are needed to get a MAC token created and validated. Sasi also provided a patch for a MAC nonce validator - this is not at the trunk yet but will make it there in time.


Categories: Sergey Beryozkin

OAuth2 Demo in Talend ESB

Sun, 08/12/2012 - 22:42
Talend ESB ships many interesting, advanced examples demonstrating CXF and Camel in action. The demos attempt to show something interesting, something that one may try to do in the production.

JAX-RS OAuth2 demo has been evolving as a POC demo with the main goal to stress  CXF OAuth2 services and make sure that they can cope with what one might want to consider as a medium complexity OAuth2 deployment.

The demo shows 4 parties cooperating with or depending on each other, where service offers the registered users an option to reserve a table at the favorite restaurant with the help of Restaurant Reservations service (with the latter depending on its own partner).  A classical 3-leg OAuth flow (Authorization Code Flow in OAuth2) is demonstrated with most of the demo depending on CXF alone to do most of the work (OAuth2, Presentations, etc).

The end user (individual resource owner) can approve or disapprove a client (Restaurant Reservations) request to read and possibly update the user's calendar.  The demo can be run as a simple OAuth2 demo with all the endpoints running within the same container or as an advanced demo showing how a user can interact with the application supported by many application containers, with the SAML SSO feature introduced to improve the user experience - this advanced option will be covered in detail in one of the future posts.

Please check this presentation I did at JAX-2012 in Mainz for more information.
I'd like to encourage users to try the demo, provide the feedback and git pull requests :-)


Categories: Sergey Beryozkin

Master Kerberos Security with Apache CXF

Thu, 08/02/2012 - 13:22
Kerberos is a well-known security protocol, originally developed at MIT and has been a major authentication protocol on Windows.

Why would you want to learn about or experiment with Kerberos today, when developing web services ?

One may want to do it if we have a web service which needs to expose the information available from the internal Kerberos-protected store or when a Single Sign-On service needs to use  Kerberos servers to keep the principal details or when Kerberos is deemed to be the best authentication protocol which can protect the given complex application exposed as a web service. 

The decision by Hadoop developers to support Kerberos will undoubtedly make it more important for developers to understand what Kerberos is about, due to the fact the Big Data is becoming so important these days.

In Apache CXF, Kerberos has been supported on a number of levels for a while. Colm has published a two-part series about the way WS-Security Kerberos is supported and tested in CXF, and Christian has implemented a client-side support for the HTTP Negotiate authorization scheme. 

Starting from CXF 2.6.2 (to be released soon), the JAX-RS frontend offers an additional server and client side support for making it very easy to support the Kerberos authentication for RS endpoints and clients. 

After installing Kerberos packages, the next thing you can do is to run JAXRSKerberosBookTest or add server and/or client Kerberos handlers to your own application as documented at the wiki and see what actually happens.

Have you been thinking of getting started with Kerberos for Web Services ?
Do it today with Apache CXF :-)

Categories: Sergey Beryozkin

Jettison 1.3.2 is out

Fri, 07/27/2012 - 17:23
Jettison 1.3.2 has been released this week, please check the Download page.

Those who try to customize the way Jettison works should find it easier to override various Jettison classes, for example, in CXF I've been able to remove about 50 lines of code I had to copy earlier on to get large Jettison sequences optionally restricted.

Jettison will no longer require a namespace map set up for the serialization to work, in cases when it is not configured to ignore namespaces, as I moved a fix provided by Benson from CXF to Jettison.

A number of minor performance enhancements have also been implemented thanks to the proposals from Fabian Lange.

During the next  few interactions we will continue minimizing a number of outstanding issues, however I'd also like to encourage the community to provide patches - they will get an immediate attention during the release, as it's been the case during the last few releases. I haven't resolved one issue with the available patch to do with treating XML attributes as elements, in CXF we can manage it by providing a custom XML writer, so I needed more time on investigating if that issue can be resolved at the current Jettison implementation level effectively or not.

At some point in the future an optional streaming support will have to be introduced, either on read or write sides, even if certain restrictions will have to be there.

In meantime, please keep stressing Jettison and provide the patches :-) 

Categories: Sergey Beryozkin

CXF Log Browser Demo

Thu, 07/19/2012 - 14:41
A Log Browser demo has been available in the CXF distributions  for more than a year now. This demo is based on the brilliant contribution from Thomasz Opanovicz done as part of his GSOC project.

What I would like to do is explain what exactly the CXF Log Browser can do right now, and suggest some ideas on how it can be enhanced.

At the moment, the browser can be used to poll the Atom-enabled management endpoints and display the available log entries, this can be done per every CXF service, JAX-WS or JAX-RS one. The Atom endpoints can be set up as described in this section and shown in the demo. Have a look at this image on how the browser can show the log entries, I think it is quite cool.  Note the entries are paged, example, one can go to the next, previous, first or last pages, from the current page.

At the moment the browser polls every time the "refresh" button is pressed - this is one minor thing that can be customized further, example, a browser can be asked to poll every 60 seconds.

The browser offers an option to restrict which log entries are displayed by letting users to set FIQL search queries.

Typically, the Atom endpoint (which handles the browser queries) captures the log events, transforms them to Atom feeds and keeps them in memory or overflows to a registered ReadWriteLogStorage if needed but what is interesting it can also be configured from the start  to read the log entries from the existing log files.

For example, it can be configured to check the directory where Karaf gets the log files created. CXF offers a file-based ReadableLogStorage interface implementation  which can check the existing log files matching a given naming pattern, figure out which log file is newer or older and get the log entries in whatever format is used to format them using the simple configuration involving no regular expressions at all. For example, have a look at this test which works with the log files available here as well as this configuration file (check the bean with id "storage3").

All of it needs to be more extensively tested but Log Browser is already offering a fairly involved support for working with the available log entries.

However, quite a few enhancements can be done which can make it more useful and eventually turn the browser into a management console of its own.

One obvious thing which is missing is the ability to capture events immediately, with a browser acting as a receiver. For example, it would be good to get Atom push endpoints sending the events to it too. Implementing an enhancement like this one would very likely lead to Web Sockets supported in CXF. The browser would be configured to support either push or pull style on the startup or perhaps it would keep the pull  style by default and get the real-time events displayed in the running line at the bottom of the window.

The browser can also offer an option to get the log files from the selected location downloaded to the local disk. 

We can also have at least two more tabs available. One would show the JMX statistics related to CXF, another one would show the message exchange details.

I'd like to encourage users to try the demo, and consider helping us with enhancing the browser further.  

Categories: Sergey Beryozkin