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.

Monday May 25, 2009

Integrating Sun Secure Global Desktop with Radius Authentication

Last week I have been looking at the integration of SGD (4.41.907) with Radius One-Time-Password (OTP) Authentication. Inspired by some projects that are being done by some of our partners at customer sites and a wiki page on the same subject I decided to setup a similar environment in our lab. The wiki page material is based on an earlier version of Sun Secure Global Desktop and therefore based on an earlier version of Apache web server (version 2.x vs. 1.3.36).

I decided to install ActivIdentity (AI) AAA Radius Server 6.6 next to an already existing installation of VDI3 and Active Directory DC. The Active Directory is integrated with both AAA and VDI. The AAA server will use Active Directory to lookup users and also store serial number information for the token cards that are used by these users. The integration with VDI is for the Kerberos Authentication of Sun Ray users and also for looking up user profiles by SGD after a successful third-party authentication has taken place (all user profiles are provisioned to AD by means of Sun Identity Manager but this is less relevant at this point).

AI Pocket TokenThe authentication within SGD / AAA is based on OTP's generated by ActivIdentity Pocket Tokens. After setting the PIN these can be used in various ways. We will use them in synchronous way which means that after typing in our PIN and clicking OK, the token will generate and present an OTP. Other ways these tokens can be used is through a challenge-response OTP generation.

The integration of SGD (Apache) and Radius authentication can be done in various ways as well. One of them is based on a piece of code (mod_auth_radius) from the open source project. This is what is described on the wiki mentioned above and is also described in this blog. Another way is through a similar piece of code (mod_auth_xradius) from another website called The last option and probably the most sophisticated is through a solution like Sun OpenSSO Enterprise.

Where possible I have followed the wiki mentioned above. However, there are some steps that need some adjustments and some other things need to be changed. I will focus mainly on the differences and other things that I encountered...

Step 1. Obtain and install, (if necessary) CVS

I also downloaded and installed CVS to get to the latest version of mod_auth_radius. However, through a conversation I had with the author of this module, the most recent source code can now be found at git:// so to get to the latest version from now on this would require the installation and use of e.g. git-

Step 2. Retrieve and Build mod_auth_radius

First of all, since we are using Apache 2.x underneath SGD 4.41, we need to get the right mod_auth_radius. As can be easily found on this version is called mod_auth_radius-2.0.c. From the CVS we checkout module mod_auth_radius which contains mod_auth_radius-2.0.c (v 1.5.7). Therefore the 3 last bullets should read:

# cp mod_auth_radius-2.0.c /opt/tarantella/webserver/apache/{version}
# cd /opt/tarantella/webserver/apache/{version}
# bin/apxs -i -a -c mod_auth_radius-2.0.c

However, the last command will generate the following error on a default Solaris x86 installation platform:

  line 1279: gcc4: command not found
apxs:Error: Command failed with rc=65536 

This can of course be fixed by installing gcc4 (e.g. from or also by just creating a link gcc4 that points to gcc (which is gcc3 on my Solaris 10 x86 platform) like this (there are of course more ways to get this right):

# cd /usr/sfw/bin
# ln -s gcc gcc4
# PATH=/usr/sfw/bin:/usr/ccs/bin:$PATH
# bin/apxs -i -a -c mod_auth_radius-2.0.c

This should have added a line in the Apache /opt/tarantella/webserver/apache/{version}/httpd.conf file:

LoadModule radius_auth_module modules/

Step 3.  Configure Apache for RADIUS Authentication

We add the following lines to the end of httpd.conf:

# radius_auth_module add
Alias /sgd "/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd"
<IfModule radius_auth_module>
AddRadiusAuth RadiusServer:1812 ActivPack 5:3
AddRadiusCookieValid 0

SetEnvIf Request_URI "\\.(cab|jar|gif|der|class)$" sgd_noauth_ok
<LocationMatch "/sgd">
    Order Allow,Deny
    Allow from env=sgd_noauth_ok
    AuthType Basic
    AuthName "Radius Authentication"
    AuthBasicAuthoritative off
    AuthRadiusAuthoritative on
    AuthRadiusCookieValid 0
    AuthRadiusActive On
    Require valid-user
    Satisfy any

Step 4.  Test RADIUS Authentication (optional)

Least thing to do here is to restart the webserver:

/opt/tarantella/bin/tarantella restart webserver

Step 5.  Configure Tomcat to Trust Webserver Authentication
Step 6.  Configure SGD to Allow Webserver Authentication
Step 7.  Allow Administrators to Login via Webserver Authentications (optional)

See wiki for steps 5, 6, and 7.

An additional note is that after all these steps, things worked fine for Internet Explorer but not for Firefox. Investigating the HTTP traffic in more detail revealed that not always the RADIUS cookie (that is set after successful authentication) is send back to the server properly. Also it appeared the cookie had a very strange path and also the expiration date was off. E.g., the cookie path contained "/ expires=...". Looking more closely at the source code I ended up with these lines of code:

static void
add_cookie(request_rec \*r, apr_table_t \*header, char \*cookie, time_t expires)
    apr_snprintf(new_cookie, 1024, "%s=%s; path=/ expires=%s;",
                cookie_name, cookie, buffer);
  } else {
    apr_snprintf(new_cookie, 1024,
                "%s=%s; path=/; expires=Wed, 01-Oct-97 01:01:01 GMT;",
                cookie_name, cookie);

It looks like there is a ';' missing in the line in red. I added a ';' in this line right after 'path=/' and recompiled. After this things also worked for Firefox. Checking the HTTP traffic, I could see the cookie being sent correctly.

Another thing to note is that I have set the lifetime of the cookie to indefinite (AddRadiusCookieValid 0). This is of course an arbitrary choice but I wanted to prevent having to regenerate an OTP every 5 minutes to keep working in SGD. This way the session is tied to the SGD session and will end when we logoff (see the end of this blog of how we can do this).

After these steps the end result should look similar to what you see in the following demonstration...

Basic demonstration of SGD and Radius OTP Authentication

To get a single logoff experience, logging out from SGD should also clear the authentication "session" so trying to log back in will confront us again with a Radius Authentication prompt. For this we have changed the logged-out.jsp file that can be found at the default path: /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/webtops/standard/webtop/logged-out.jsp. The line that I put in is the following:


This will clear the HTTP authentication cache for the browser. Unfortunately, this is browser dependent and only works for Internet Explorer. There is no straightforward way to get the same behavior with Firefox. Googling around I have found that this is a long standing RFE that apparently has not been implemented. Also some workarounds / hacks are described at various websites (e.g. that supposedly will give a similar behavior with Firefox. However, I have not really tried to get this working.

Finally, I have also used mod_auth_xradius to get a similar result. It took more work to get this module built. Apparently this code is less straghtforward to compile on Solaris 10 with gcc. It took some tweaking (not detailed here) to get this compiled. As, said the end result is similar. It is different in the sense that mod_auth_xradius does not use cookies for its sessions. As far as I can tell it is also not possible to set the lifetime of a session to indefinite.

All in all, it seems possible to get this working with the mod_auth_radius module. A much nicer solution would possible be the integration with Sun OpenSSO. This will get away from using Basic Authentication and give us some better session management (in my opinion) and also the possibility of SSO to other back end applications. I have not tried this but it should be fairly straightforward since OpenSSO supports Radius authentication. Might be something interesting to work on for a next "proof-of-concept" :-)


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.


« March 2015