Valves, Filters and Interceptors
Recently I had the requirement to authenticate incoming requests to a CXF webapp. The options I had were to write application specific logic at the application to do the authentication or using either a valve, filter or an intercepter to access the content of the incoming request before it reaches the actual application / service and do required authentication.
I preferred the second option and there were few reasons behind the decision. One of them was to avoid binding authentication logic and mechanism towards application logic. For an example suppose my application uses basic authentication where the request contains HTTP “Authorization Basic” header. Based on the content of the header I should do the client authentication. Now the problem is what if I want to change this authentication mechanism to JWT authentication where I send a singed JWT to prove who the user / application is.
If my authentication logic is bind towards the application, then I have no other option than changing my application logic to support JWT authentication. ie going and embedding more logic inside application logic to support JWT authentication.
One of the other reason is, suppose this is my application X and later I come up with a another application named Y which has a totally different business logic but still needs client authentication. Then I should again implement the client authentication using JWT to the Y application as well.
In contrast if I had a layer where I can do the authentication and then pass the result to the application, then it would be perfect for a reusable authentication mechanism.
The solution is to use either a tomcat valve, tomcat filter, cxf filter or a cxf interceptor. Each of these interception points has different purposes and usages. (my container is tomcat)
If we take a tomcat valve, it intercepts all the requests which come to the container (server). Simply it’s globally engaged. If we take a tomcat filter, it has a slightly less scope where you can register it to a certain context like /mycontext.
CXF filters are at a more finer level where they only filters requests which comes to a specific JAX-RS service.
CXF interceptors are at the finest level. Those interceptors will only come into action once all above levels are surpassed. One of the important characteristics of interceptors is that they have phases. ie more finer levels. These phases defines more and more finer levels if interception. In [1] you can find a set of phases. According to this phase receive is the very first phase where an intercepter can be engaged.
As per these information a CXF interceptor would be ideal for the work. Below are some reasons for it.
- I don’t want each and every request to be intercepted by a valve which is unnecessary and which does not follow proper separations. ie client authentication is not a server wide concept.
- Client credentials or any of the ingredients which are used for client authentication can come in the request body. If I were to consume the body of all incoming requests it’s not gonna work !!. It’s too costly and also when I consume the message at valve level CXF webapps doesn’t work properly since they expect to have the body unconsumed when actually JAX-RS starts to build the message. Hence I also have to re inject input stream to request in order to work rest of the things properly.
- Tomcat filters also has the same trade off more or less. ie building the request body and setting a backed stream instead of consumed stream is required. (which are very cumbersome).
- When using JAX-RS filters I do not need to worry about building the request body in order to identify body parameters. ie JAX-RS does it in one of the phases of their filters. Hence when I engage the filter in a certain phase I do have all these information without any cost at all.
Considering all above options, advantages and disadvantages going with a CXF filter would be the optimal and best solution. If you are interested about how I enforced client authentication through CXF filter, you can refer to [2] which is the actual interceptor. [3] is a sample client authenticator which will be invoked by the interceptor. [3] is just a single sample authenticator. Likewise you can write and engage number of authenticators on demand.
[1] http://cxf.apache.org/docs/interceptors.html
[2] https://github.com/wso2/samples-is/tree/master/oauth-sample-client-authenticator