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 :-)
Friday, November 30, 2012
Thursday, November 29, 2012
[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 !
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 !
Thursday, November 22, 2012
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!
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!
Friday, October 12, 2012
Latest WADL To Java enhancements in CXF
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:
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.
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:
<resource> <param name="id" style="template"/> <method name="GET"> </method> <resource> <resource> <method name="POST"> </method> </resource> </resource> </resource>
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.
Friday, September 21, 2012
OAuth2 MAC Access Token support in CXF
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.
Enjoy!
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.
Enjoy!
Sunday, August 12, 2012
OAuth2 Demo in Talend ESB
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 Social.com 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 Social.com 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 :-)
Enjoy.
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 Social.com 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 Social.com 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 :-)
Enjoy.
Thursday, August 2, 2012
Master Kerberos Security with Apache CXF
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 :-)
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 :-)
Subscribe to:
Posts (Atom)
