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.

Security in the workspace - Part 3

It seems that we will have to learn to live and work in a de-perimeterized world. Acceptance of the problem is often the first step towards a solution. So, what alternatives to perimeter defense are there? And what is the impact of these alternatives on the future workspace and vice versa? Below are some thoughts. I hesitate to call these conclusions. Please consider these as starting points for a discussion.

• Defense in depth is the complete opposite of perimeter defense (when considering the location where controls are implemented). This security principle advises to apply multiple layers of security controls, so that if one layer fails other layers take over.
  
  • Unfortunately, complete defense in depth is increasingly expensive as it is difficult to maintain,
  • and because too many layers of security get in the way. (Is there a usabilty vs security trade-off? I'm not sure. But usability is probably not helped with adding multiple layers of security.)


• Most experts see a shift from perimeter defense (and other location based defenses) to data oriented security. (Perhaps that should be information oriented security?)
  
  • Because of the multiple contexts in which employees now process data, this requires some sort of watermarking of sensitive and valuable data. If, for example, lost information can be tracked back to employees responsible for that information than those employees can be held accountable for the loss. But wasn't DRM declared dead?
  • Moreover, data oriented security makes valuation of information necessary: relative sensitivity and value to the organization should be made explicit. Valuation of assets should be done anyway (as part of information risk management), but that doesn't mean that it is easy, cheap or common practice today!
  • Related to the above point: information should be stored and processed with a clear goal in mind (for reasons of Governance, Regulations, Complicance). This is at least as difficult as valuation.


• Accountability (the other A-word) may be an alternative to access control. Access control is somewhat problematic in the absence of a perimeter after all. Access control is expensive in the future workspace since employees join and leave the organization on a more regular basis (access credentials management is costly). Accountability certainly seems to be more compatible with the greater responsibility given to employees as part of the future workspace trends.


• Identity management is necessary, as accountability usually means a great deal of logging (of actions of employees). Logging obviously requires the capability to distinguish between employees (try holding individuals accountable for their actions when you can't tell them apart). However, since we left the perimeter behind us, we can't rely on the classical identity management process which involves provisioning, authentication, and authorization.
  
  • The provisioning problem could be overcome if we could use an established identity provider's infrastructure which extends beyond the bounds of the organization. The existing identity provider (I'm thinking of national governments) has the infrastructure for issuing authentication means to individuals already in place. If such a global identity provider is not (yet) possible, federated identity management and user-centric identity management may be alternatives (in the mean time).
  • Authentication has to be done decentralized (in absense of a perimeter with check points) and preferably as often as possible yet also as unobtrusive as possible. Perhaps context-information could help here?
  • Authorization, on the other hand, is better done centralized so as to achieve consistent rules which are easy to manage. Well-defined roles could be useful here
    

Other points? Leave a comment!