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.

This entry was posted in Uncategorized. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.