Last weekend I decided to put some effort around integrating Sun VDI and strong authentication based on One-Time-Passwords (OTP). During my visit to the European Identity Conference in May 2009 I had received a YubiKey at the booth of Yubico and I was still thinking about setting up some meaningful demonstration with it. During the same period I had received a request from a partner of ours whether it would be possible to have OTP integrated into Sun VDI. So finally this weekend the two ideas came together and I decided to extend the standard VdaClient used in VDI3 with YubiKey authentication.

So what is a YubiKey?

According to Wikipedia the YubiKey, manufactured by Yubico, is a device that acts as a USB keyboard and provides secure authentication by a one-time password algorithm.YubiKey From the manufacturer's website: "The Key generates and sends unique time-variant authentication codes by emulating keystrokes through the standard keyboard interface. The computer to which the Key is attached receives this authentication code character by character just as if it were being typed in from the keyboard – yet it's all performed automatically. This process allows the Key to be used with any application or Web-based service without any need for special client computer interaction or drivers." And in a nutshell, that's what it is. The Key is in fact very small and lightweight (18 x 45 x 2 mm and only 2 grams) and doesn't require a battery. Again, since it is presenting itself as a USB keyboard, you don't need any special device drivers or such. That's why this works also out-of-the-box on a Sun Ray device. So, the Yubikey is a USB device and has one button. If you push the button, it generates an authentication code (consisting of a unique identity code and an OTP). With the identity code it is possible to check if the used Key is really the one assigned to this user. The complete authentication code can be checked either locally with a validation server or over the Internet with a Web Services API that Yubico is offering. This is extremely neat since integrating this way is almost just a matter of minutes. Also a lot of Web Services clients have been written in various languages and these are all open sourced.

For more information on the YubiKey please visit Yubico.com.

Initially I had extended the UI with an additional field where a user can have their generated OTP put in as a visible string. This obviously works fine but after browsing some sites and applications that also integrate with the YubiKey it appears that it is more common to just have the OTP typed in right after the regular password (at least, in the case of "two-factor authentication with username"). In that case it is easy to separate the two since the OTP is a long fixed length string. Anyway, I decided to go back to the more common design which you can see in the demonstration video below. My original design and application you can see here:

So how does it work?

As you can see in the demonstration, a user types in his or her username in the regular Username field and the password (in my case I use the AD password for the user) in the Password + .YubiKey field. I use the AD username and password so the user can be authenticated also against AD. Furthermore, via e.g. a lookup in AD it can be established if this is the key for the user. For this to work, the YubiKey unique identity code needs to be in the user profile. Of course, it is also possible to store these in a separate database.

After the user puts in the username and password, we keep focus in the Password + YubiKey field and press the button on the YubiKey so the OTP code gets typed in right after the regular password for the user...

At that point, the YubiKey identity is verified for this user, the OTP is validated via the Yubico Web Services API, and the username and password are also checked against AD. If this all succeeds, the user is logged in and is either shown its default desktop or the desktop selector frame as can be seen in the demonstration. If either one of these pieces of information is wrong or we try to replay an old OTP, we get the appropiate error messages as can again be seen in the short video.

Have fun!


Nice integration, Rene! I think, though, in a real world deployment, you would want to return the same error for all three cases that you showed. Giving any more detail than 'username or password incorrect' leaks information to a potential attacker - e.g. "I have the right password for this account, but this isn't the right Yubikey".

Posted by Andrew Patterson on July 17, 2009 at 04:23 PM CEST #

Hi Pat... absolutely couldn't agree more. Consider these 'log messages' that I write to console just for demonstration purposes. Cheers, Rene.

Posted by Rene Klomp on July 25, 2009 at 03:33 PM CEST #

It may be smart to implement your own authentication server for the key as well. Not every system is connected to the Internet and you may not want to rely on a third party for authentication.

Posted by Homme Bitter on September 01, 2009 at 04:36 AM CEST #

Again, absolutely agree, normally you probably would want to do that. However, for a prototype this was the easiest to do...

Posted by Rene Klomp on September 01, 2009 at 04:55 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog covers exciting things I encounter about Oracle's software and related; that is Identity & Access Management, SOA, Security, Desktop, etc. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« February 2017