logoITSphoto
fds-is

IAM Software Design Alternatives

Introduction

It is unusual to specify software development costs for a project that has not yet had its formal Requirements Definition approved or its Design Alternatives examined.  It is presumed that the reader is fully aware of the service requirements for this project, so they will not be repeated here. There are circumstances that constrain the  choice of software design so this document will explain:

Specification

Scope of IAM

As there is still no agreed industry-wide definition  of precisely where IAM begins and ends in an enterprise, consider the required components for the service at Exeter:
  1. A single sign on service to issue "tickets" to users requesting access to secure systems after authenticating them. These tickets are then used by SSO client modules fitted into the secure systems applications. An example is Moodle, where you select the SSO module to use during its configuration (CAS, Shibboleth, LDAP, IMAP, POP, etc). The user's password is sent once only to the SSO server and subsequent issued tickets are used to automatically log in to all subsequent SSO-enabled applications.
  2. A Person Registry or Enterprise Directory that stores key data about every current and past user to whom the university has ever issued credentials. There are two types of registry: a "fat" registry that also contains information from all "Systems of Record" (Staff, student, associate) or a "thin" registry that only contains pointers (reference numbers) that point to the data within those systems of record.
  3. An LDAP service that contains information about all active users who are able to access university services. This is obviously a subset of the data in the Person Registry, but each user has much more detail (attributes and their values) stored for them.
  4. Administration servers that add, change and delete the contents of the Person Registry and LDAP system. To effectively manage this user data, groups need to be defined and managed, and the privileges of those groups and users defined and mapped onto the applications. There are also many custom program to synchronise, reformat and audit data every hour or day as it is mapped from one system to the next.
  5. Specialist secure servers to handle secondary applications such as Shibboleth Identity Provider or inter-university service provision with Peninsula College of Medicine and Dentistry. These offer the additional authorization checks where required.
  6. System management services to backup and restore the above data, to audit its accuracy, to log and report on its activity and to provide real-time service load monitoring.
  7. Security management to lock down the core secure network, manage certificates, key exchange, monitor for denial of service attacks, detect login abnormalities and escalate issues depending on their severity.

Scope of applications

The list of Exeter systems that are to be integrated into a SSO system must be clarified. The complete list is impractical because some application manufacturers will never be able to adapt their product. Furthermore, the quantity of applications means that high priority ones must be integrated first and future reviews will decide on the order to implement the next sets.

Software Selection

IAM software deployment consists of two components:
  1. The core middleware infrastructure of databases, directory servers, secure login authentication, group and privilege management, data synchronising, formatting and auditing.
  2. Developing the SSO modules to hook into the existing campus applications so that they will accept SSO tickets as well as userIDs and passwords.
Consider these two components in more detail.

1. Core Middleware Infrastructure

Commercial off the shelf (COTS) systems to provide integrated solutions for IAM are targeted at businesses where all the users are employees and usually generate revenue. The costs of these systems are proportional to the number of users (employees). There are at least a dozen quality products to choose from implementing clever designs and demonstrating very high security.

The security threat to the university network will only ever increase, so the IAM security methodology must not only be as strong as possible, but capable of being scaled upwards in the future. An example of this would be a move from the current single-factor authentication (password) to a two-factor level (password and USB token).

Universities are also curious from a security perspective in that the bulk of their potential intruders are from within the network, rather than externally.

The university also has to to take on the differing demands of every school who have a different set of security requirements. Some may want multiple levels of authentication, while others could see IAM as a barrier to openness and flexible working from home or other campuses.

Universities have a markedly different user base to industry. Not only are campuses responsible for the authentication of tens of thousands of students, but the "churn" at start-of-term where many thousand students are added in one or two days places a huge surge on the system and requires batch processing rather than the traditional manually keyed entry in Personnel Departments. The growth of university systems to handle huge data lists, such as all alumni, who have authorisations to perform actions such as email, means that commercial solutions to manage this scale of user base are financially unrealistic.

Internet2, funded by the National Science Foundation in the USA, has pioneered the coordinated development of scalable solutions to tackle core middleware infrastructure at universities. An early success was the standardisation of  the eduPerson schema to support the correct identification of university staff and students. The integration of the eduPerson schema into the LDAP directory service is key to rapid and successful service deployment. This feature really pinpoints the main debate in university-level IAM software specifications. Are additional schema like eduPerson able to be incorporated or must be they be run in parallel directory services as adjuncts to the main service? Some commercial LDAP systems, such as Microsoft AD, do not allow the addition of schema, without invalidating support contracts. Additional SQL databases are introduced and before the service is launched, IAM managers are having to cope with one of the core database components being split into two.

Exeter, like all UK universities, has additional requirements. The UK Access Management Federation's (UKAMF) implementation of the Shibboleth protocol in 2008, means that more of the eduPerson schema attributes are going to be used. Also IAM data processed at Exeter must conform to the eight data protection principles in Schedule 1, Part 1 of the 1988 Data Protection Act.

As every university in the world is facing the same dilemma of implementing IAM, Internet2 has coordinated the development of a NSF Middleware Initiative for Higher Education (NMI-EDIT). They are developing all the key components needed for large-scale IAM and also producing a road-map for campus IAM management to follow. Because they work closely with Educause and JA-SIG, good prototype products to solve IAM are already in use.

2. SSO Module development

Every system that is SSO-enabled requires a SSO software module to be added to its login authentication handler. With potentially fifty or more applications to integrate with the Exeter SSO system, the range of software solutions that Exeter has to tackle is best illustrated by examples:
  1. Recent campus applications such as Moodle or Sakai illustrate one end of the market. They offer a clickable menu of SSO modules for use and the application is configured to use a chosen module. SSO implementation is immediate and costs nothing.
  2. Other popular open source software such as uPortal or SquirrelMail are written in Perl and accept the addition of Perl modules written by the SSO service author. Typically, the SSO offers modules for Apache, Oracle, SunOne, Tomcat, Outlook, PHP, C and Perl. An experienced programmer can add a module to an application in two or three days. This has been demonstrated at Exeter with Project SWISh.
  3. Proprietary applications such as WebCT, obviously do not make their source code public. Vendors can offer a SSO method where they describe how to implement a private protocol to exchange information and achieve SSO. Once again an experienced programmer can develop the SSO interface but it takes perhaps two weeks to complete.
  4. Closed applications such as SITS, APTOS, Alta HR, Laminex and Innovative were written without any expectation of supporting SSO. In these cases, vendors have to be convinced to update their product and support popular SSO products. The cost of these solutions is the delay waiting for the upgrade and its purchase cost.

Summary

Recommendation

Exeter should review universities who have already successfully implemented IAM on the scale that has been defined and assess the costs, risks, development, timetables and resources to achieve a workable solution. This will focus on institutions utilizing Internet2-associated products. Candidate institutions are Stanford University, Yale University, Cornell University, University of California (Berkeley), Newcastle University and University of Bristol.

Information Services should formalise its Software Development Management. Instead of allowing perhaps a dozen Perl (mainly) programmers to develop their own code, they should be introduced to software version control with a repository such as Subversion, software release management, documentation standards, peer code reviews, standard library module development and coding standards. This will at least protect the organisation from departing staff taking all remaining knowledge of an application or feature away with them. The main benefits are well-documented: what is required is a high level commitment that software development is a key part of Information Systems and will always remain so.
 
Nick Johnson
Version 1.0
7 November 2006