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.
Posts
