OpenID with OpenASelect - Part 3

Now that my OpenASelect server is running it's time to make it a bit more attractive and robust. Apart from creating flashy JSPs based on our corporate CSS style this means:

• Make the user URL as short as possible, something like openid.domain.com/username
  
• Better yet, instead of the full User Principal Name (UPN) (which includes as a domain @domain.com) I want users to be able to use firstname.lastname
  
• Allow users to also use firstname.lastname (without the domain) when they use openid.domain.com as URL (the OAS server asks the user to enter both the user name and the password in that case)
  
• Secure the server with a certificate (our authentication is password based, after all)
  

Most of these issues can be resolved by placing a regular httpd server in front of the Tomcat server (using mod_proxy). The advantage is that mod_rewrite can then be used to allow user to be sloppy with their UPN in omnidirectional identifiers.

The regular httpd server accepts connections on port 80 and proxies these to the Tomcat server which has an AJP connector on port 8009:

ProxyPassReverse /openaselect/ ajp://localhost:8009/openaselect/
ProxyPass /openaselect/ ajp://localhost:8009/openaselect/

Clients can remain unaware of the fact that pages under openaselect/ are actually served by the Tomcat server and not by the httpd server they are connected to. On top of that I used mod_rewrite to get prettier URLs:

RewriteRule ^/([A-Za-z0-9]+\.[A-Za-z0-9]+)$ http://openid.novay.nl/openaselect/profiles/openid/users/$1@domain.com [P,L]

The rewriting trick works well for omnidirectional identifiers in which the username is part of the OpenID URL. When the user merely enters http://openid.novay.nl at an RP and the actual OpenID URL is established through discovery things get a bit more complex. The rewriting needs to be done at a slightly deeper level. The configuration file links to Java classes for many of the sub-processes. In my oa.xml most of these classes are standard Alfa & Ariss classes, for example I used a StandardTranslator inside the user provisioning process. I replaced the reference to this class with my own SloppyUPNTranslator so that users can leave out the domain part of their UPN. Deploying is done by adding the class to a jar file and dropping it inside the lib/ directory within WEB-INF. My translator simply wraps a StandardTranslator and overrides the translate(String) method by adding a "@novay.nl" to the argument before calling the wrapped translator.

Am I finished playing with OAS as OpenID provider? For now. But there are plenty of loose ends that I intend to investigate later on:

• Session identifiers when the user merely uses https://openid.novay.nl with an RP, the discovered URL can be used to track the user. I'd like to see if OAS can be tweaked to use a per-RP, or even per-session, pseudonym here.
  
• Other, innovative, authentication methods. Perhaps smart card based.
  
• Deploy OAS in Google App Engine. Not connected to our AD, of course. Just to see if it's possible: Looks like the server uses some threads, not sure if these are necessary.

Acknowledgment: Joost Reede of Alfa & Ariss was of invaluable help configuring the server and explaining OpenASelect basics. Thanks!

OpenID with OpenASelect - Part 1

OpenID is a popular online identity management framework (standard?). In an attempt to get some hands-on experience with it I decided to see if I could provide our company's Active Directory server (an LDAP like service which authenticates users for access to their Windows desktops and also contains identity attributes available to email clients such as Outlook) with an OpenID interface so that it can be used as an OP towards external RPs. Sort of like Sun's OP, but for Novay employees.

How to become an OP? There's a list of open source APIs and libraries for different languages and servers. Alfa & Ariss' OpenASelect server seemed appropriate for my purposes as it can talk OpenID and LDAP and runs on top of Tomcat. Also, since Alfa & Ariss is just around the corner from our office it's easy to ask for help (thanks Joost!).

I set up a box with Fedora, postgreSQL, and Tomcat and deployed the OpenASelect war based app. After restarting Tomcat I ran the database creation scripts and my OpenASelect server was up and running.

Configuring is done by editing the oa.xml file whose format is described extensively on the OpenASelect website. The configuration file roughly consists of three sections (roughly, because these do not correspond logically one-to-one with the top-level elements in the file):

• User (and attribute) provisioning
• Authentication method
  
• Protocol profiles (such as OpenID)

Obviously, I wanted to start with a minimal configuration file. I was thinking of using the file based user provisioning (which uses a users.xml file containing user names and additional attributes) with htpasswd based password authentication (which, yes, uses a htpasswd file). Get that to work first and add OpenID and LDAP later.

A problem I ran into at that point: there's no other way to test the freshly installed OpenASelect server than to have some external service (the RP) use the identity server. So, it actually turned out to be easier to install the OpenID profile (a seperate download, unzip it on top of the deployed OpenASelect, run some database creation scripts, restart). Since our AD server is behind the corporate firewall I had to install an OpenID RP locally to test against (OpenID, though user-centric, apparently needs the RP to be able to communicate directly with the OP). The simple PHP OpenID RP is great for this purpose.

Also, there's an authentication method called identifying method which is much easier for testing than password based authentication.

Part 2 describes how I got OpenID to work and how I connected the OpenASelect server to the AD back-end.