Monday Nov 16, 2009

Managed Smartcard Services for VDI

One of our partners is offering Managed Smartcard Services. This means that an enterprise is able to outsource all of their smartcard and PKI services to a 3rd party. Part of their card lifecycle management service is the whole enrollment, personalization and issuance of the smartcards. This means that a new employee will get an invitation to visit one of a chain of certified professional photographers in his or her hometown neighborhood to take a picture to go on the card. The smartcard is then printed with the company's and personal information including the employee's photo and is provisioned with the user's certificates. The certificate will contain the user's UPN that will also need to get into the company's Active Directory so that the employees can use smartcard login to their desktop. For this to happen, many scenario's can be thought off including a fully automated provisioning of AD by tools like Sun Identity Manager up until manually adding new users from a batch csv file. After this is all done the card is then sent to the employee's home address together with a PIN letter, ready to activate and use.

Recently I have been investigating how this Managed Smartcard Service could be used to easily give employees access to their Windows desktops via strong authentication using our partner's Managed Smartcard Service. The basis for this setup is a customer using Citrix XenApp (formerly known as Presentation Server) to access its desktops using Sun Ray thin clients.

The entire demo environment has three servers, two clients and a live Internet connection. Clients are a fat laptop client and a Sun Ray thin client. The servers are a Sun Ray server (with PCSC lite software), a Citrix XenApp server with AET middleware software (used by our partner) installed on it, and a AD Domain Controller that is setup to trust certificates issued by our Managed Smartcard Service Provider's CA. This environment is connected to the Internet so the validity of certificates can be checked via OCSP at the Managed Smartcard Service OCSP responders. As can be seen in the short demonstration video (02:27) below both fat and thin clients can be used interchangeably without any problem.

Since the issued smartcards are sent directly from the 3rd party (our partner) to the company's employees, we needed to find a way to register the cards in the company's Sun Ray (or VDI) environment. The Sun Ray token ID is composed from several characteristics of the card being fabricator, type, batch and serial number of the card. Within the Sun Ray server software, this token ID is composed automatically by the corresponding smartcard config file. Composing this token ID beforehand through a script is theoretically possible but is easily broken since e.g. type and batch numbers could change without notice. Another idea would be to register the smartcard when it is used for the first time by the customer's employee.

However, even more simple is to make the Sun Ray services layer completely 'transparent' to all the backend services (like with VDI). This is what is used in this setup where just the certificates are read and transferred to the backend Citrix XenApp servers which have the AET middleware on it and where all the OCSP checking and final authentication based on the UPN in the certificate will take place.

All in all, we found that Managed Smartcard services can be used very easy together with Sun VDI and Citrix where both fat and thin clients can be used together...

Have fun, Rene.

Sunday Nov 08, 2009

Is it a card...? a token...? no wait, it's a Smart DisplayCard Token!

Recently I received some 'fairly new' smartcards from ActivIdentity which are called Smart DisplayCard Tokens. I decided to integrate the Smart DisplayCard Token with VDI. The idea here is that we use the smartcard functionality for accessing our VDI desktop from a Sun Ray thin client (e.g. from our workplace at the office) and access the same desktop from a fat client through Secure Global Desktop by using the OTP token functionality in the exact same card (e.g. at home or traveling).

Smart DisplayCard Token"The ActivIdentity Smart DisplayCard Token combines the security of a token with public key infrastructure (PKI) features for online authentication in a smart card form factor. The ActivIdentity Smart DisplayCard Token is embedded with a smart chip that supports standard smart card PKI capabilities such as email encryption and digital signatures. The token supports two user authentication modes: connected smart card mode for corporate-issued machines or disconnected Smart DisplayCard mode for authentication using a kiosk or mobile device."

This integration builds on work done some time ago (see my previous blog entry "Integrating Sun Secure Global Desktop with Radius Authentication"). There I had integrated Sun Secure Global Desktop with ActivIdentity 4TRESS AAA Server in order to get Radius Authentication.

As outlined before, the card can be used as a true "smart" smartcard where it will hold the user's certificates for smartcard logon to his or her desktop (see my previous blog entry "UZI-card VDI integration" for an example of how this could work). However, in this integration demo I use it more as a "dumb" smartcard that is assigned to a desktop or user in VDI and where the authentication is done against AD by username / password. This will be sufficiently secure for many scenario's where people access their desktops within the company network. And we do still have all the benefits of using a card like easy session mobility and such.

Again, while traveling or at home, we access our desktop by logging in to Secure Global Desktop and enter a one-time-password (OTP) for Radius Authentication. Although the card does not have a keypad we can still use it for multi-factor authentication (something you have, something you know). For each card we can generate a server-side PIN code which the user can enter right after (configurable) the OTP in the password field.

Please have a look at the short demo video (02:50) below which should give you an impression about how this could work...

All in all, I believe this ActivIdentity Smart DisplayCard Token is a great card with many possibilities, especially in combination with Sun VDI. It's a great thing to have if you are going for a multi-channel authentication strategy.

Have fun, Rene.

Sunday Sep 20, 2009

Portrait mode Sun Ray

Having a rotated, portrait mode desktop with Sun Ray is something that has been frequently asked for. With the Xnewt X Server for Sun Ray and its support for the RandR (Resize and Rotate) extension this is now possible.

To test this, I installed the latest Sun Ray Software 5 EA 2. Next to a fairly standard installation and configuration I made sure that for every session (both for pseudo tokens and normal tokens) xrandr is called. This utility takes several options. In my case I used it as:

/usr/X11/bin/xrandr -o left

Not having a fancy portrait mode monitor at hand, I decided to just turn my monitor 90 degrees. What you can see in the very short (1m20s) video below is that both the login screen and also the desktop itself shows up in portrait mode. This is of course exactly what I want! All the information displayed from the firmware itself, is of course still in landscape mode. As far as I know this is something that can not be changed right now.

Have fun, Rene.

Tuesday Sep 15, 2009

UZI-card VDI integration

Triggered by one of our integration partners I recently worked on integrating the Dutch UZI-card ('UZI-pas') with Sun VDI and Sun Ray. The aim of the UZI-card is to uniquely identify and authenticate healthcare providers. The UZI-card is provided by the Unique Healthcare Practitioner Identification Register which is better known by its Dutch acronym: UZI-register.

What is the UZI-register?

"The UZI-register is the organisation that provides unique identification for healthcare practitioners in the Netherlands. The unique form of identification is provided by the UZI-register to healthcare practitioners in the form of an UZI-card, a kind of electronic passport. The UZI-register processes the application, production and issue of the UZI-card. The UZI-register is part of the Central Agency for Information on Healthcare Professions, an agency of the Dutch Ministry of Health, Welfare and Sports."

What is the UZI-card?

"The UZI-card constitutes a key condition for secure electronic communication and consultation of confidential information by healthcare practitioners. Just like the regular passport, it is an important individual ‘value document’. The UZI-card looks like a bank pass. It contains the electronic identity of a healthcare practitioner, which is protected against misuse. That is why the UZI-card, just like a bank pass, is provided with a unique pin code."

More information about the UZI-register and the UZI-card can be found at the website of the UZI-register.

The integration steps - an overview

To start with, inserting the card into a Sun Ray thin client immediately showed that the smartcard was recognized as a known smartcard type. This was a good start since this meant I didn't have to configure a new smartcard config file. To be specific, the card issued for the user 'Kees Test44' (see the picture of the UZI-card above) was recognized as token 'OpenPlatform.40708533474701566491'. For demo purposes I configured this card in the Sun Ray environment to start a new Terminal Server session to the PDC but this could easily be changed to start an RDP session to the user's desktop as managed by Sun VDI.

Next thing I needed to do is install the PC/SC-lite software on the VDI or Sun Ray server so that the Sun Ray's smartcard reader becomes a PC/SC compliant reader. Software and instructions on installing the PC/SC-lite software can be found here.

Furthermore, in order to be able to do smartcard logon, I had to install an Active Directory (AD) Primary Domain Controller (PDC). Several need to be taken care of on this AD PDC. All of these steps are outlined in the document 'Handleiding configuratie smartcard logon' that can be found on the website of UZI-register. First of all, I had to add the user 'Kees Test44' to the list of AD users and configure this user for smartcard logon. After this, I had to map this user to the UPN on the smartcard by configuring an alternative UPN suffix (equal to the 'Abonneenummer') and defining his user logon name to be the UZI-number ('UZI-nummer'). As an example, for our demo UZI-card this results in a UPN of 900001168@00000509. Next to installing (generating) a Domain Controller certificate that needs to be present on the DC to be able to do smartcard login I had to import and trust the CA certificates of all of the issuing CA's in the trust hierarchy all the way up to the root CA. More on this hierarchy (for the test UZI environment) can be found here. Finally, I had to install the smartcard middleware software (in this case that of AET Europe) on the desktop for the user 'Kees Test44'. Since I was using a TS connection to the PDC I had to install it on the PDC itself. In the VDI desktop case we will have to install it on each desktop (template).

After all these steps, a smartcard logon was possible as can be seen in the video below.

Demonstration of UZI-card smartcard logon

The following video shows a demonstration of smartcard logon using the UZI-card for user 'Kees Test44'. In this video Kees logs on to his desktop and visits one of the specific healthcare web applications using one of the certificates on his smartcard.

Have fun, Rene!

PS. to be complete, more than one certificate could be found on the UZI-card. Next to the certificate used for authentication in the demonstration above, the card also contained certificates for confidentiality and digital signing purposes.

Thursday Jul 16, 2009


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

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!


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.


« August 2016