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!