OpenID with OpenASelect - Part 2

The OpenID profile is configured from the main OpenASelect oa.xml configuration file. The default OpenID profile (from the OpenASelect site) only needed minor changes. There are two parameters which need to be set:

• The <endpoint>: http://localhost:8080/openaselect/profiles/openid/
• The <idtemplate>: http://localhost:8080/openaselect/profiles/openid/users/[username]

They both look too ugly to be used by actual users, but changing them requires hiding the Tomcat server behind a regular httpd, which I'll cover in part 3 of this post. For testing I left them as they are since my Tomcat runs at port 8080.

I first tried to get OpenID to work with the identifying authentication method and file based user provisioning. This basically means that when the user goes to the RP and enters an OpenID with a user name that is present in users.xml then this should result in an authentication that is accepted by the RP. If he enters a user name that is not present in the file then it should fail.

Next step was to replace the user provisioning and the identifying authentication method with something that actually checks with our corporate AD server to see if a user can present valid credentials. For testing I configured OpenASelect to use my personal credentials to get access to LDAP (in an actual deployment one would probably create a dedicated user, called Security Principal in oa.xml, for this). The settings I needed to know were:

• The server, something like "ldap://host:389"
• The base, something like "OU=Intitute,DC=Corporate,DC=domain,DC=com"
• The user name and the password of the security principal

There are several sections in oa.xml where these credentials have to be repeated, so it's a good idea to define them as <!ENTITY> elements somewhere near the top of the file.

I introduced JNDI authentication in two steps: first, change the user provisioning to use JNDI (JNDI is the Java interface to LDAP) and keep the identifying authentication method, although replacing the identifying authentication method with a JNDI password authentication method actually proved to be completely trivial. The userPrincipalName field with a so-called "exist-converter" is what I used in the translator part of the userfactory. This means that the identifiers for users look something like firstname.lastname@domain.com. You can get rid of the @domain.com part in several ways. I'll cover this in part 3.

Now that authentication works, it's time to look at attribute release. OpenID has two extensions which deal with this: SREG and AX. I wanted support for both of them.
Then AX. There's an <extensions> section in the OpenID profile bit of oa.xml. I needed to set param_signing to true.

The attribute gathering process is configured in the <attributegatherer> section of oa.xml. I made a processor for SREG (SREG uses a fixed set of attribute names: nickname, email, fullname, postcode, country are the names for which I found an equivalent in our AD) and several processors for AX (AX attribute names are identified using schema URLs, there are actually a couple of schemas with good RP support, so I included a processor for each of: http://axschema.org, http://openid.net/schema, http://schema.openid.net, and http://verify.sxip.com/schema). Each processor maps LDAP attributes (the external name) to SREG or AX attributes (the internal name). A small problem I ran into here is that the mapping characteristic of this part of the configuration makes it rather hard to export, for example, the telephone number found in our AD to two distinct AX attribute names (default and business phone number).

The result, besides a rather lengthy configuration file is an OpenASelect server that talks to our AD and acts as an OP. The PHP based OpenID RP I had running locally can be used to test the authentication and SREG functionality (it doesn't seem to support AX yet).

In part 3 I'll hide tomcat behind a regular httpd and try to improve the overall end-user experience.

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.