Observations about Maven Central Search URIs

I was using a Maven Central Search Engine to find a Google GWT artifact. The search engine is very useful, no doubt about it. I then somehow got focused on the actual URI which identifies the specific GWT artifact I was after:

"http://search.maven.org#search|gav|1|g%3A'com.google.gwt'%20AND%20a%3A'gwt'".

I'm using single quotes just to keep the whole URI expression inside double quotes.

That does not seem like a user-friendly URI to me, and I guess it does not have to be, but I'd just like to analyze it a bit more.

I'm not sure what "|gav|1|" is about, but the main expression (encoded), is really this one:

"g%3A'com.google.gwt'%20AND%20a%3A'gwt'" which reads like this: "find resources with a group 'com.google.gwt' and artifact 'gwt'".

Now compare it with this equivalent FIQL expression which CXF will happily help to handle:
"g=='com.google.gwt';a=='gwt'"

thus giving us

"http://search.maven.org?_s=g=='com.google.gwt';a=='gwt'".

This query a bit simplistic but FIQL does start 'scaling' when we want to use composite queries, for example:

"http://search.maven.org?_s=g=='com.google.com';(a=='gwt',a=='gwt-inject');(v=gt=2.0;v=le=3.0)"

which reads "Find all the modules with a given group, with artifact set to 'gwt' or 'gwt-index' and having versions greater than 2.0 but less or equal to 3.0". It's impressive how FIQL can capture so complex queries in a compact way with a URI which humans can understand. FIQL simply rocks and I encourage users to experiment with it more. By the way, check out the client-side FIQL support, can be handy for building FIQL queries inside the HTML forms.

[OT] CXF- Even Better Than The Real Thing

Listening to U2 for a long time seems to start affecting me, so much that I can't stop 'producing' my own 'mix' (the Title line of this post) of the fantastic U2's "Even Better Than The Real Thing".
Those who follow this blog for a while will notice I'm getting a bit repetitive by mixing 'CXF' with phrases from some songs I've heard, sorry :-). But if you are working with CXF you may probably agree with the title :-). Have Fun.

Complex WADL Processing in CXF

We have seen a number of JIRA issues opened against a WadlToJava generator since it was added to CXF 2.4.1. Seeing the community experimenting with it was really reassuring and it confirmed there was some genuine interest toward working with WADL. WADL was a really fine effort from Marc Hadley and it does seem to have nearly all it needs to move from a submission to a final recommendation.

One of the major contributions to the CXF WadlToJava code generator came from Christos Fragoulides who did help to push it to the next level by providing a lot of feedback and fixes while working with a more up-to-date WADL document describing Rackspace Cloud Servers API. They have a complex WADL document which utilizes most of the WADL capabilities and it is in such cases where one can start seeing the advantages of being able to get a document and start testing the server in a matter of minutes. By the way, Rackspace, hope we can see a more up-do-date WADL document live soon :-).

Then, when I already thought that our WADL code generator was flying high, came another very good contribution from Lars Weber which should make it possible to get a useful code from WADL descriptions like this one. Now the generator supports local references for all the WADL elements, in addition to external resource references.

Note that the AtomPub example relies on a WADL link element which can be used to identify a portion of the representation. How one can get to a portion of the representation in CXF JAX-RS ? Easy, use an XPathProvider.

So please try the WADL code generator in CXF 2.5.0, stress it more and provide the valuable feedback.

Lets make OAuth go mainstream with CXF JAX-RS

OAuth 1.0 offers a fairly complex HTTP-centric solution to a classical problem of "how a resource owner (end user) can allow a third-party consumer to access some of the resources this user owns on the resource server".

I recall being quite confused about OAuth and what exactly it was supposed to help with, when starting to look into it about 2 years ago. I guess it was a typical reaction of someone trying to grasp a given technology without having any prior experience in the area. What was the story with that redirection, and then with yet another one, and how all the pieces were supposed to be wired together ? Was it about the authentication or authorization, and where would something like OpenId come in ? I was asking myself those kind of questions.

It takes a bit of time to realize how elegant OAuth actually is. OAuth 1.0 has been supported by major players such as Google, Facebook and many others. Jersey and RestEasy are offering their support. And OAuth 2.0 is going to make a massive impact real soon.

CXF 2.5.0 is joining the OAuth game. And we have tried our best to make it possible for users to write complete, functional, secure OAuth applications the way they write their HelloWorld demos.

Before providing more information, I'd like to thank Lukash Moren for providing a high-quality OAuth 1.0 implementation as part of his GSOC 2009 project, and Bill for asking me to work on OAuth during my brief spell at JBoss - it all kind of happened at the same time...

Now, please review this documentation providing a comprehensive overview of what it takes to create and deploy an OAuth server, with a lot of examples and hints on various approaches one may need to choose from when building a complete OAuth solution.

Much depends on how the resource server manages the user resources and provides an access the the end users and third-party consumers. Many options are available but the message we'd like to send is that you don't need to create a WEB application similar to those provided by Google or Facebook or Twitter in order to get working with OAuth. CXF JAX-RS provides the ingredients one may need to apply OAuth to all sort of problems requiring the end user authorizing a 3rd party access. Obviously we will be improving what is already there as time goes by.

So lets make OAuth go mainstream with CXF JAX-RS, start building OAuth applications and enjoy it all the way.

SAML Claims-Based Authorization for JAX-RS endpoints

SAML has been around for a while and is used in real-world applications. CXF WS-Security framework is already offering a second-to-none support for SAML, especially with the introduction of the CXF's own STS, please check Colm's and Oliver's blogs and have some exciting read if you work with WS. Actually, STS can become quite important even for the advanced RESTful security - so follow those blogs even you don't work with WS :-).

The good thing about SAML is that SAML-based solutions do not have to be WS-* based only. SAML is an extensible and rich language and all sort of SAML profiles can be utilized for RESTful applications too. Arguably SAML is complex but the fact it's being used around is critical.

CXF JAX-RS is 'keen' to help users start working with SAML. CXF 2.5.0 offers an initial support for including SAML assertions in the HTTP request payloads and using them to enforce the Claims-Based or legacy Role-Based Access Control rules on the deployed JAX-RS endpoints.

One can get a SAML Assertion posted to the server inside a wrapper XML element which will include the actual application payload such as Book and the assertion itself, with the complete envelope being signed only or with both the application payload and the assertion itself being signed individually. All of it is done by registering a couple of client and server side handlers which will transparently add an envelope, signatures and then validate it all on the server side with the application payload (Book) becoming a root XML node in the end, ready to be processed by the JAX-RS runtime.

With REST we do not always post the XML data so what you can also do is easily add an optionally deflated and then base64-encoded assertion either to the Authorization header or a form field. Such encoded values might also be signed - something we may support in due time.

Having a SAML assertion available as part of the application payload raises a question as to what can actually be done with it. SAML is often used to provide SSO solutions for RESTful services, but we are not there yet, so the best thing that we could come up with at this initial stage is to let JAX-RS users utilize SAML claims in order to enforce the access control rules.

SAML claims are much richer than those which can be asserted with the RBAC rules. However @RolesAllowed and friends are still used a lot and probably will be so it was important to make sure that the legacy rules can work with SAML assertions having claims which are actually representing roles and also offer the way to assert much richer rules which are possible with SAML claims.

Have a look please at this sample code fragment and the follow-up comments. One have a lot of flexibility in the way the claim-based rules can be expressed and also complement the existing RBAC rules without even modifying the code which can also be important.

Before such rules can be enforced, the assertion needs to be validated. The SAML handler will do its own validation, and if you have STS deployed them you may actually want to delegate to it to do some validation too (recall the advice at the start of this post :-)). See also how you can setup an STS client.

The question which has not been seriously addressed yet is how one will create SAML assertions in the first place. At this stage one can start experimenting with using a callback approach and I think we can offer a support for utilizing a WS STSClient on the client side for getting the assertions and transparently adding them to the payload easily enough - please note, the fact that STSClient is a WS client is the least important fact here, it's a perfect mediator between the client code and STS and it does not matter if a SAML assertion which will make it into a non-SOAP payload was actually fetched using a SOAP client.

Note that supporting other interesting SAML-based solutions is of interest to us, that involves the possibility of supporting a WEB Browser SSO profile, etc.

In meantime, please write your simple SAML callback implementation which will generate SAML assertions and start stressing your endpoints secured by claim-based rules, or even invent a new SAML profile along the way :-)

Stay tuned !

Simple XML Security with CXF JAX-RS

Enhancing the security support for JAX-RS services was a major theme during the CXF 2.5.0 development. CXF already offers a good support for users to create secure RESTful services relying on HTTPS and it also offers a number of useful utility classes for enforcing the authentication and authorization rules.

But the security can be a much richer subject, it is indeed and it is the right time now for us to start working on the advanced security features for CXF JAX-RS users to start experimenting and working with the message level security, tapping into the richness of SAML, deploying OAuth solutions. And we will be analyzing and providing a support for the most interesting and useful security features which are already being or will be used by the community.

As far as the message level security is concerned, XML Signature and XML Encryption are the two prominent W3C specifications which have been used as the basis for providing the message integrity and confidentiality without relying on HTTPS mainly for SOAP XML services, with the help of WS-Security related specifications.

In REST, XML is only one of the many formats which can be supported, but XML is still a very major format which is used a lot. Given the popularity of XML and also to simplify the integration with SOAP-based solutions, it does make sense to get the message-level security supported well for XML services and get to supporting other relevant efforts allowing to sign all sort of payloads next.

And this is what we did in CXF 2.5.0. We put a lot of effort in providing a solution that will make working with XML Security a child's play yet practical and able to deliver for users relying on JAX-RS.

XML Signature and XML Encryption are complex specifications but I hope you can agree after reading this section that working with these specifications and making them protect the messages can be interesting, simple and a real fun.

Note that all what is needed to get an XML signature applied to a given application payload is to register a single handler on client and server sides. By default, a signature will be enveloped as a last child inside a given XML instance such as Book. On the server side, the signature will be validated, removed from the payload and made available on the current Message for other handlers to use it if needed, for example, for optional SAML handlers be able to verify SubjectConfirmation methods such as "sender-vouches".

After the payload has become 'free' of its enclosed signature, it's wrapped in a useful CXF DOM-aware STAX reader and passed along to the JAX-RS runtime.

Making CXF JAX-RS produce enveloping or detached signatures is as easy as setting a signature style property on a client-side handler with the server side one capable of reading all types of signatures.

And now that we have a signed payload, isn't it tempting to get it encrypted too ? So here you go, all you need to get a self-contained EncryptedData with an embedded EncryptedKey capturing an encryption key is to register a single handler on client and server sides which will help CXF encrypt a payload (possibly signed) and then decrypt it on the server side.

One thing which is worth noting is that WSS4J is relied upon by this feature - this is an internal implementation detail and should be of no concern to users building advanced secure RESTful services. WSS4J has a lot of useful code and it makes sense at this stage to reuse it under the hood.

Give it a try please and as usual, please help us with the feedback. If you are a security expert - let us know what may need to be improved and if you are not - learn new advanced security concepts with CXF and become the one :-) Enjoy !

Capturing the info about roles with JAASLoginInterceptor

CXF ships a useful utility JAASLoginInterceptor which greatly simplifies the process of interacting with the JAAS subsystem and creating a current SecurityContext encapsulating the information about a user principal and roles which will be used for making authorization decisions. See this post for some more information.

When working with Apache Karaf, the simple way to get roles distinguished from a user principal is to configure the Karaf JAAS context such that role names start from a prefix such as "role_" and then let JAASLoginInterceptor know about it using a now deprecated "rolePrefix" property.

However when the existing stores containing the info about roles are used this simple technique may not work given that all sort of naming conventions can be used which may not 'managed' by a rolePrefix property. It makes it trickier to capture roles given that in Karaf the classes representing roles and user principals implement only a single Principal marker interface.

So in 2.5.0 what you can do in such cases is to use new roleClassifier and roleClassifierType properties to let JAASLoginInterceptor know how to get to the roles. Please see this section for an example (the updated content will be visible shortly). This enhancement came after the conversation with my Talend colleague Andrei Shakirin.

Additionally, Aki Yoshida enhanced the interceptor to better cope with the containers providing custom callbacks, for example, it will work perfectly with Jetty providing ObjectCallback instead of javax.security.auth.callback.PasswordCallback.

Finally note that SecurityContexts set by JAASLoginInterceptor on the current CXF message implement LoginSecurityContext. This one can be very handy for getting say Spring SecurityContexts populated, for doing the custom authorization based on the list of provided roles and using the underlying Subject returned from the JAAS subsystem as needed.

If you are asking at this stage, hmm, do I really need to continue using the servlet security, then you are most likely on the right track :-)

Enjoy!

Better support for big attachments in CXF 2.5.0

Dan had a high quality patch from Sam Meder applied just in time before CXF 2.5.0 has been released which is to do with limiting the max size of the incoming attachments - which is a very good improvement indeed. Whether you use WS and MTOM or depend on JAX-RS, a new "org.apache.cxf.io.CachedOutputStream.MaxSize" system property can be your friend, see this page for more info.
And virtually at the same time Dan did another fix for the runtime to cope better with attachments bigger than 2 GB, how about that :-) ?

It's great to see the CXF Runtime core delivering extremely well as far as working with attachments is concerned

All you need to get HTML views is RequestDispatcherProvider

While working on the new OAuth demo for the soon to be released Talend TSF distro based on Apache CXF 2.5.0 (see Dan's announcement), I relied a lot on RequestDispatcherProvider.

As you know a typical OAuth flow may involve a lot of interacting with the user and a complete demo should also show the user going to or being redirected to the 3rd party provider site, as well as approving the 3rd party accessing one or more of its private resources.

I was amazed, I really was, how simple and easy it was to get multiple RequestDispatcherProvider instances configured to redirect all sort of responses to JSP views handlers while still being able to return alternative representations such as XML ones.

I highly encourage people to try RequestDispatcherProvider, say goodbye to complex views integrations and never look back.

CXF Transform Feature and Redirection

The Transform feature is proving to be useful to CXF users, given that dynamically changing or dropping the incoming or outbound namespace(s) as well as updating the element names is often required when the changes have not been propagated across or are not even possible. The fact that all the modifications are done at the STAX level is critical as far as the performance is concerned.

The feature has been enhanced recently thanks to Aki Yoshida. The incoming payloads can get new elements added in a number of ways which can be very useful when the services validating the data using the close content schemas are in operation. Multiple updates (example, adding some elements, dropping another one, changing the name and or namespace of yet another one - all on the same payload) are better supported too.

There will be more enhancements coming in in time but I've been actually planning to highlight one of the lesser known tricks which one can use with the Transform feature, something that we demonstrate in our Talend distributions.

Consider the case where you have an endpoint deployed with hundreds or many thousands of clients consuming in. Those could be some long-running clients executing the code, possibly embedded in browsers, and that code is aware of the way this endpoint can be consumed. The time has come to deploy an updated endpoint. The more open the environment is - the fewer options are there to get the clients updated at the same time when the old endpoint goes down and the new one gets deployed.

This is not a new problem per se, but Transform Feature, in combination with the servlet redirection, offers its own simple way to tackle the cost of upgrading all the clients:

Keep the servlet serving the endpoint which is now down around but only have it redirecting all the requests from the old clients to the new servlet serving the new updated endpoint. This will keep the old clients happy for a while and the process of upgrading them can become less 'stressful'.

So now we will have a new endpoint serving the new clients but it will also get the requests redirected to it from the older clients. How will the new endpoint figure out how to handle a given request without resorting to a low-level XML or JSON manipulation ?

Yes, you are right - Transform Feature will help - it will ensure the old requests are recognized by the new endpoint and the responses from this new endpoint are recognized by the old clients still unaware of the fact they are talking to the new endpoint.

Here is how the relevant part of web.xml may look like:

<!-- Old Servlet -->
<servlet>
 <servlet-name>CXFServletV1</servlet-name>
 <display-name>CXFServletV1</display-name>
 <servlet-class>
   org.apache.cxf.transport.servlet.CXFServlet
 </servlet-class>
 <init-param>
  <param-name>redirect-servlet-path</param-name>
  <param-value>/v2</param-value>
 </init-param>
</servlet>

<!-- New Servlet -->
<servlet>
 <servlet-name>CXFServletV2</servlet-name>
 <display-name>CXFServletV2</display-name>
 <servlet-class>
   org.apache.cxf.transport.servlet.CXFServlet
 </servlet-class>
</servlet>

<servlet-mapping>
 <servlet-name>CXFServletV1</servlet-name>
 <url-pattern>/v1/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
 <servlet-name>CXFServletV2</servlet-name>
 <url-pattern>/v2/*</url-pattern>
</servlet-mapping>

CXFServletV1 will redirect all the requests to the servlet listening on /v2 which is CXFServletV2.

Next we configure the Transform feature like this:

 
<bean id="transform" 
 class="org.apache.cxf.feature.StaxTransformFeature">
 <property name="contextPropertyName" 
              value="http.service.redirection"/>
 <!-- the rest of the feature config -->     
</bean>

The feature is configured to do the transformations only if a boolean property identified by the "contextPropertyName" is set on the current message. In this case, if the request has been redirected then the message will have an "http.service.redirection" set to true. It won't be the case for the requests coming from the new clients and thus the feature won't affect them.