User Authentication with Thrift Service: Comparing Different Approaches
We’ve covered Apache Thrift in last few articles from simple HelloWorld sample, Python Thrift client, to the securing Thrift traffic. Here I am going to discuss more on user authentication, which is a must for protecting the services and user authorization. This is in general a weakness of Thrift, but could be solved with different approaches. Having said that, if you have chosen Thrift, you probably build internal system where user access control is not important.
When using normal protocol for the Thrift service, there is not much choice but to implement a login method for a token that should be passed back to every other normal service calls. It’s quite easy to implement such a login method/service which takes in user name and password, or any other types of credentials, and return a string token. An example of this approach is the Evernote API.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
The problem is that passing a token back in every method just make the APIs a bit awkward. This is somewhat similiar to the vSphere API method where the first parameter is always “_this”. Usage wise, there is no problem at all. Because the problem is similar the one vijava API solves, you also copy the design I had to hide the token for higher level and cleaner APIs.
Another approach is to insert another layer, for example, HTTP, below the typical Thrift layer, just to take care of the user authentication. For every Thrift message, it’s wrapped in a HTTP message as HTTP body. The HTTP headers can have special headers for different HTTP authentication, for example, the BASIC authentication. If the authentication is successful, the Thrift message is passed along; otherwise it’s blocked. In this case, the upper level Thrift service interfaces do not need to change at all, making it an ideal solution.
Of course, every approach has its pros and cons. For the thrift over Http approach, the clean interfaces are its biggest pros. However, it does introduce a bit more traffic than the pure binary approach as introduced above. In most of the cases, the traiffic overhead is not a big deal given the broader bandwith these days. Making the APIs cleaners to use and therefore resulting in higher productivity is far more important than a bit traffic overhead.