Use FIQL to query LDAP and OSGI containers

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 :-)

[OT] Just Say Yes to CXF

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 !

How to refresh OAuth2 access tokens in CXF

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.

Enjoy!