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:
- What software is required to achieve a full IAM service.
- What existing campus applications will have to integrate with the
SSO service.
- How IAM software is split into core services and SSO client
application integration.
- Whether commercial software packages are suited to a university
campus requirements.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
- The core middleware infrastructure of databases, directory
servers, secure login authentication, group and privilege management,
data synchronising, formatting and auditing.
- 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:
- 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.
- 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.
- 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.
- 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
- Exeter should take advantage of the fact that every university is
looking to achieve secure IAM. The successful implementations at other
institutions should be examined to assess what lessons have been
learned.
- Commercially available IAM software is designed for enterprises
where there is a steady low churn of employee turnover, and it is
costed according to the number of users it manages.
- Directory services for universities require special schemas to
extend attributes for staff, students and associates. They also need to
support Shibboleth in the UKAMF. Adding these schemas should not cost
more, nor invalidate support or divide the infrastructure into separate
components.
- If it is not possible to convince all University of Exeter
schools to adopt a single IAM solution, then it may be necessary to
implement separate products.
- Although the choice of software seems to fall into a "COTS vs.
open source" debate, this is not true. Rather it is the peculiar
requirements of numbers of staff and students that have driven many
universities to solve the problem themselves.
- The main message from conferences that have been attended in the
past year has been that COTS systems appear to fill a niche, but are
incapable of adapting to the diverse proprietary needs of legacy
products at most universities. Closed commercial systems restrict
interoperability and result in customised workarounds, unsanitary and
inflexible screen-scraping short cuts and inevitable loss of system
security.
- In industry, management can restrict application, operating
system and architectures choices to reduce support costs. However,
universities like Exeter have a diversity of service and systems that
have been purchased or built because of tight budgets, specialist
requirements, personal bias and narrowness of knowledge.
- Commercial IAM vendors do not agree on what a full IAM service
provides. Most offer a secure core service, but the SSO-enabling of the
enterprise's applications becomes a separately funded contractual
assignment.
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