In our recent work on the World Bank’s Communicate intranet, we needed to integrate the Siteminder access system into the Open Atrium-based intranet “Communicate” to allow World Bank staff to use the same single sign-on credentials that they use to access all their internal web systems. To do this, we upgraded the Siteminder module for Drupal. You can download the new module from its Drupal project page and learn more about its API and how to write your own Siteminder plugin in its documentation and from reading the module’s code. First, here is a little more background on the changes.

The Siteminder system, from Computer Associates, is used by many enterprise-level organizations to authenticate signing on to their web resources. How it works is that you can designate a site — like an Open Atrium powered intranet — to be protected by the Siteminder system. Once a site is protected by Siteminder, all traffic to that site is routed through Siteminder first and then on to the actual site. Siteminder sets certain HTTP headers in the user’s request, and Drupal can then examine them to determine credentials. What the Drupal Siteminder module does is map the Siteminder header values to Drupal users and allow a user to login based on the headers they send.

In addition to authentication, the Siteminder system also stores other information about users. When the Siteminder system sends HTTP headers for authentication, it can also send information about a user — like her name, email address, phone number, and so on. We wanted to be able to pull this information into the intranet too. To achieve this, we re-wrote the Siteminder module in such a way that it’s easy to write a plugin module to provide the fields to which you’d like to map this extra Siteminder meta information and to determine how this information is processed and saved. To do this for the World Bank’s intranet, we built the Siteminder Profile module, which lets you pick a CCK node type to serve as the target content profile for a user as well as select a few taxonomy vocabularies. Then by using the main module’s administrative interface, you can choose which Siteminder headers should get mapped to which CCK fields and vocabularies based on the designated node type and vocabularies you selected in the Siteminder Profile settings page.

But what happens if a person’s information changes in the Siteminder database — for example if they change phone numbers or office buildings? The Siteminder module now has built-in capability and an API to check whether values in users’ profiles have changed in the Siteminder system. The Siteminder Profile module uses this API and saves a new version of a user’s profile if it detects that a value has changed in the Siteminder system database.

The last big change in the Siteminder module is that it now integrates with Chaos Tools’ exportable objects capabilities, which lets objects live in both code and the database, with the database versions overriding code versions. The original Siteminder module stored HTTP header-to-field mapping partly in code and partly in variables, which meant that there was no easy way to manage mapping, not to mention to create multiple mappings for testing purposes. The new version lets you create header-to-field mappings in the UI that you can then export and store in code, much like the way the Views module works.