Identity Management Roadmap

superfluitysmackoverΑσφάλεια

23 Φεβ 2014 (πριν από 3 χρόνια και 4 μήνες)

66 εμφανίσεις

LONDON’S GLOBAL UNIVERSITY








Identity Management
Roadmap










Version:

1.0

Date:

13
h

May
2009

Status:

Draft

Author:

Simon Farrell


Version History

Version

Date

Comment

0.1

17
th

April 2009

First draft to inform brainstorming sessions

0.2

23
rd

April 2009

Second draft fo
r internal review

0.3

28
th

April 2009

Third draft for feedback from Design Authority

1.0

13
th

May 2009

First public version, incorporating feedback from DA




UCL Identity Roadmap
v1.0


Status:
Published

Contents

1

Introduction

................................
................................
................................
................................
....

1

1.1

Definitions

................................
................................
................................
...............................

1

2

Background

................................
................................
................................
................................
.....

3

2.1

Synchronised Identity

................................
................................
................................
.............

3

2.2

Federated Web SSO

................................
................................
................................
................

3

2.3

Hosted Email

................................
................................
................................
...........................

4

2.4

Funding

................................
................................
................................
................................
...

4

2.5

Resourcing

................................
................................
................................
...............................

4

3

Problems and Opportunities

................................
................................
................................
...........

5

3.1

Problem Statements

................................
................................
................................
...............

5

3.2

Opportunities

................................
................................
................................
..........................

6

4

Projects

................................
................................
................................
................................
...........

7

4.1

Email

................................
................................
................................
................................
........

7

4.2

Authentication

................................
................................
................................
........................

8

4.3

Identity Lifecycle Management

................................
................................
............................

10

4.3.1

Identity and Attributes

................................
................................
................................
..

11

4.3.2

Services System

................................
................................
................................
.............

11

4.3.3

UPI and Types of Identity

................................
................................
..............................

14

4.4

D
irectory Convergence

................................
................................
................................
.........

14

4.5

Role Rationalisation

................................
................................
................................
..............

16

A.

Weighted Benefits

................................
................................
................................
........................

18


Table of Figures

Figure 1: ILM Synchronisation with Microsoft Live.com

................................
................................
.........

7

Figure 2: Email Project Candidate Indicative Timeline

................................
................................
...........

8

Figure 3: Authentication Indicative Timeline

................................
................................
........................

10

Figure 4: UPI High Level View

................................
................................
................................
...............

11

Figure
5: User creation

................................
................................
................................
..........................

12

Figure 6: Service
-
based user creation

................................
................................
................................
...

13

Figure 7: Services System Identity Indicative Timeline

................................
................................
.........

14

Figure 8: Directory Convergence Indicative Timeline

................................
................................
...........

16


UCL Identity Roadmap
v1.0


Status
: Draft


Page
1

of
18

1

Introduction

This document attempts to define an Identity Roadmap for UCL’s
Information Services Division (
ISD
)
.

It is limited in scope to those processes and IT systems over which ISD has some influence. It draws
requirements from a number of interviews and brainstorming sessions conducted within ISD in
February 2009, and it takes as additional input information ga
thered at the JA
-
SIG 2009 conference.

The purpose of a roadmap is to define a target state and the order in which activities should take
place in order to achieve the target. A few of these activities are already planned and funding has
already been reques
ted. Many are neither planned nor funded and the purpose of the roadmap is to
identify and prioritise
them
.

1.1

Definitions

Identity

is a slippery term. In the context of
UCL
, it means
a combination of
:



A
number of
unique identifier
s

for an individual (UPI, st
aff or student number, UCL login
account name, email address)



Electronically stored attributes specific to that individual (name & address, job title, date of
birth, telephone number)

This paper treats Identity as the aggregate of all these attributes. Se
e especially section
4.3

for a
more detailed dis
cussion.

Authentication

is the process by which an individual or system (a
principal
) asserts an identity and
has that assertion verified. At UCL the two most familiar cases of au
thentication occur when an
individual logs in to a computer system and when an individual attempts to gain access to a building
by means of a swipe card.

Authorisation

is the process by which a computer system decides to permit an operation by a
properly a
uthenticated principal. One example might be when a computer system decides that an
individual should be granted read or write permission to a specific file stored on a shared drive;
another might be when the building access management system (RALIC) deci
des whether or not to
permit access to a building to the user of a specific swipe card.

Access Management

is the process of managing the relationship between resources (files, buildings
in the above examples) and authenticated users so that authorisation c
an take place speedily and
correctly.

This activity is generally system
-
specific.

Privileges

are permitted operations and typically operate within the context of a specific system. The
abilit
ies

to read and to write files are generic

privileges

typically d
efined by file systems. The ability
to enter a building is likely the only privilege managed by a building access management system.
Privileges may be subject to additional rules (for example access to a building may be permitted only
within working hours)
,

but this is the province of Authorisation and Access Management.

Role
s

are

one way in which many systems group related privileges together in order to make them
easier to
manage. For example, the Tutor role in Moodle may group together privileges that pe
rmit
the creation of courses, the examination of multiple students’ test scores and the ability to upload
course materials. A Student role in the same system may group together privileges that permit login,
UCL Identity Roadmap
v1.0


Status
: Draft


Page
2

of
18

test execution and the ability to post questions
on a shared bulletin board. Roles are typically
system
-
specific and defined by system administrators by means of the system’s access management
suite.

Group
s

are a way of working with multiple principals at the same time. A Tutor
role

in Moodle
should only

apply to a specific group of principals: the Staff
group
. It is easy to confuse roles and
groups, often because they can share the same label. For example a Student
role

may aggregate a
number of privileges which the Student
group

is authorised to
possess
.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
3

of
18


2

Background

2.1

Synchronised Identity

Like most Higher Education institutions, UCL operates a number of IT systems for the benefit of staff,
students and visitors. Access to these systems in many cases is restricted to
properly authenticated
and authorised
users
. Since
1997
, UCL has used the UCL Personal Identifier (UPI) as a shared, unique
symbol that can be used across multiple systems in order to identify the same individual.

On the
foundations

of the UPI initiative, it has been possible to:



Associate
mul
tiple

us
ername and password combinations
with each UPI
1



Ge
nerate
email account
s

for each individual who can be identified by a UPI



Permit the association of data about the same individual across multiple systems (e.g. to link an
individual’s HR record in N
orthgate with her swipe card record in RALIC)



Define groups of individuals based on their departmental membership within the HR
and
Registry
system
s

and use these groups to authorise access to resources in some I
T systems. For
example, only currently servi
ng staff are permitted access to the Staff WTS system.



Implement a mechanism
to propagate username
s

and password
s

into multiple IT systems

The last point needs a slightly longer explanation. Because of the diversity and (in some cases)
proprietary nature o
f UCL’s IT systems in many cases it has not been possible to externalise
username and password checking to a single “master” identity authentication system. Instead,
many systems rely on their own internal mechanisms for authenticating principals. What th
e UPI
initiative has enabled is the ability for the
same

username and password to be copied from a central
point into those systems that insist on mastering the identities of their authorised users.

2.2

Federated Web SSO

In common with many UK institutions, U
CL is a member of the JISC UK Federation. In practise, this
means that we are committed to participating in a common ecosystem of SAML
-
based Shibboleth
federated identity management. UCL runs its own Shibboleth Identity Provider, allowing all
participating

institutions (including ourselves) to use our centrally
-
generated username/password
combination to authenticate access to web applications hosted by any other participating
institution. We also authenticate access to some of our own web
-
based applications

using this
mechanism: the Library (Athens) system, IRIS and (soon) Moodle all use Shibboleth as their primary
authentication mechanism.

Shibboleth is our stated standard for Web SSO and should be at the heart of our Identity Roadmap.




1

Note that UPI is
not

a username. It is a surro
gate key generated to permit mapping of identities between
systems and as such is only used by the identity management infrastructure.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
4

of
18

2.3

Hosted Email

At the

time of writing (
April

2009), UCL
was completing

due diligence on a hosted email solution for
all staff and students. The identity
-
related components of this project are fundamental and
therefore the first steps in this roadmap must address them urgently
. In particular:



Users of hosted email should not have to remember a new username and password



Users of hosted email should be able to use the same distribution lists as currently. While some
groups are maintained by individuals, many are auto
-
generated ba
sed on Intranet Group
memberships.

2.4

Funding

In Ja
n
u
ary 2009,
UCL was unsuccessful in obtaining a JISC grant for Identity
-
Management
-
related
activities. Th
is

roadmap must take into account the likelihood that activities will be secondary
components of other
IT projects, such as Hosted Email.

2.5

Resourcing

This roadmap describes a number of “projects”, none of which appear in the ISC budget submission
for Financial Year 2009/10. It is the author’s hope that few of these activities require much, if any,
capital in
vestment, and that many of them can be undertaken by staff supporting the existing IT
systems discussed, as part of an ongoing focus on service improvement. Many projects require
cooperative participation by knowledgeable individuals from both Management S
ystems and
Information Systems. Identity is a concern that cuts a
cross organisational boundaries.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
5

of
18


3

Problems and Opportunities

This section describes some problem statements generated during the preparation of this
document. See Appendix A for a weighted
list of benefits that could be achieved through solving
some of these problems. A more complete mapping of problems to
weighted
benefits and
consequent prioritisation of work is available on request.

3.1

Problem Statements

3.1.1.

Synchronisation of usernames and pass
words can be slow. In some cases, it can take up to 24 hours
for password changes to be propagated across systems. The problem here is twofold: slow
synchronisation and the fact that there are multiple authentication systems.

This problem is
addressed in
section
4.3

of the current document.

3.1.2.

There are three systems that are each able to create new identities: HR, SITS and the Services
system. Respectively, each is the System of Record (SOR) or “master” for Staff

(including Honor
ary
Staff)
, Students and Others (visiting staff
and students
not on payroll, etc). A complex, UPI
-
based
mechanism has been implemented for mapping identity between these systems. Ultimately,
however, creation of a new principal in any one of these systems
relies on a human operator’s ability
to detect an equivalent principal that may exist already in one of the other systems. While errors
here are few, they can take over 24 hours to resolve once spotted.

While we cannot automate
humans out of this loop, th
e approach discussed in section
4.3

should reduce the time to resolve
these issues.

3.1.3.

Groups of users (so
-
called “Intranet Groups”) are derived from the organisational hierarchy defined
in the HR system and also from a number of
categories defined in the
Registry and
Services system
s
.
While useful in many circumstances, this mechanism does not easily support the definition or
discovery of ad
-
hoc groups of individuals to which an IT system may want to grant privileges.

Specific
exa
mples include the inability to decide who should be granted access to the Portico system and the
inability to determine who needs access to which buildings.

This problem is addressed in section
4.5

of the current document.

3.1.4.

Lack

of a flexible mechanism for managing group membership also prevents new IT systems from
implementing finer
-
grained authorisation mechanisms. For example, a postdoctoral student may
have certain teaching responsibilities that require her to share some of t
he privileges of a staff
member in certain systems. Currently, the choice is Staff, Student or both.

As above, this problem is
addressed in section
4.5

of the current document.

3.1.5.

Roles are defined and assigned within IT systems a
ccording to rules specific to each system. For
example, the HR system may grant certain privileges to a role called “Departmental Administrator”.
While the privileges associated with this role are strictly the concern of the HR system, it is likely that
a
similar role would be of use to other systems, as indeed would the rules for assigning it to a
principal. This is an example of mapping a “system role” to an “institutional role”.

As above, this
problem is addressed in section
4.5

of the current document.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
6

of
18

3.1.6.

Lack of this shared definition of roles across systems makes it difficult to pre
-
assign role membership
in individual systems. Ideally, a new student or member of staff would be pre
-
assigned access
privileges to many IT systems

based on their association with a given institutional role. Without this,
individuals need to request access to systems on a case
-
by
-
case basis. In many cases, the knowledge
of to which IT systems an individual needs access
for

her job is communicated onl
y by word of
mouth and this is an obvious impediment to productivity.

As above, this problem is addressed in
section
4.5

of the current document.

3.1.7.

The combination of a lack of global role visibility and siloed authentication sys
tems exposes a
security risk. When an individual leaves UCL, it should be possible to identify deterministically (i.e.
from membership in groups and association with roles) those systems from which access privileges
should be removed.
With only minor excep
tions, t
his is not possible today.

Section
4.3

attempts to
address this issue.

3.1.8.

Current data loads from the UPI “master” system into repositories responsible for authentication
(Active Directory, OpenLDAP) cause principal inform
ation to be recreated nightly. This is a major
obstacle to any progress towards incremental, near
-
real
-
time updates.

As above, section
4.3

attempts to address this issue.

3.2

Opportunities

The Hosted Email project presents an oppor
tunity to clean up UCL’s Active Directory environment
and use it to provide a consolidated view of almost all UCL staff.

Additional opportunities
proceeding from this activity are identified in section
4.4

The UAS project focu
ses on providing IT Reps with better access to information and functionality in
the Services System and is a concrete example of cross
-
organisational cooperation to deliver better
service to ISD’s customers.











UCL Identity Roadmap
v1.0


Status
: Draft


Page
7

of
18


4

Projects

Identity
-
related activities

can be grouped into 5

categories:



Email



Authentication



Identity Lifecycle Management



Directory Convergence



Role Rationalisation

4.1

Email

One principle of hosting email externally is to minimise impact on end users. The existing central
email service authenti
cates users by their institutional username, verified against NIS. To allow users
to continue to use the same username and password,

it will be necessary to synchronise user
accounts with the external provider. Assuming that this provider will be Microsoft
, the preferred
mechanism is to use Microsoft’s ILM meta
-
directory tool to synchronise Active Directory entries
between UCL and Microsoft’s
Outlook.com

service.

This approach requires UCL to ensure that:



All email account holders (staff and students at a
minimum) are represented by an entry in the
central ISD Active Directory. This is already the case
.



User accounts in other Active Directory instances will be synchronised with the same
information. Specifically, this means ensuring that ADS accounts are in
tegrated with the existing
password synchronisation mechanism.

Work is already under way to achieve this.

Other AD
instances in P
rion

and the Medical School

will need to be synchronised in a similar way as
identities within these directories become shared
with Microsoft



An ILM instance will be implemented to synchronise the ISD AD accounts with Exchange Labs

Internet
Microsoft
Live
.
com
Identity
store
ILM
“UCLUsers”
Active
Directory
UPI
UCL Identity creation
&
synchronisation
Email identity
Existing
password
sync
mechanism

Figure
1
: ILM Synchronisation

with Microsoft Live.com

UCL Identity Roadmap
v1.0


Status
: Draft


Page
8

of
18

This approach leverages the existing passwo
rd synchronisation tool but work needs to be done to
minimise the latency of updates in this environment.

See section
4.3

for further discussion.

Note also that Exchange Labs provides a password reset mechanism of its own.
How
ever
,

ILM
can
not

propagate password changes from Exchange Labs

any further than into
UCL’s AD. There are a
number of possible solutions to this problem,
including
making UCL’s central Active Directory the
sole master authentication mechanism within UCL.

Se
e section
4.4

for more detail. However, this is
not a sensible short
-
term approach and we will therefore use manual processes to prevent updates
of passwords at the Microsoft site.
The Email due diligence activity has also iden
tified security
concerns related to storing UCL passwords off
-
site at a Microsoft facility.

In addition to synchronising user accou
nts between UCL and Microsoft, this project should address
two other activities as a matter of secondary urgency:



The abilit
y to integrate Microsoft’
s email web front end (Outlook Live) with Shibboleth. This
would permit Web SSO for email users .



The ability to integrate a UCL Certificate Authority with Active Directory, to allow mail users to
digitally sign and/or encrypt emai
l in a simple, seamless way. While users of desktop email
clients can use other sources of digital certificates,
note that
web mail users can
not
currently
use
such
certificate
s
.



April
2009
May
2009
June
2009
July
2009
Due
Diligence
complete
Agreement
to proceed
Pilot
Student
live
service
ILM Sync
implemented
AD cleanup
complete
Shibboleth
integration
Investigation
Aug
2009
Certificate
Authority
Implementation

Figure
2
: Email Projec
t Candidate
Indicative
Timeline

Sequence

Activity

1

UCLUSERS AD Cleanup

2

ILM Synchronisation

3

Certificate Authority implementation

4

Shibboleth federation for SSO to OWA

4.2

Authentication

There are several priorities in this area. One driving principl
e is to increase the use of Shibboleth as
UCL’s Web SSO solution. This means a progressive migration of existing web applications to use
Shibboleth as their primary authentication mechanism. While this is relatively straightforward with
Open Source or bes
poke
-
built applications like Moodle and the Common Timetabling project, it is
less easy to achieve with COTS packages like
Northgate’s MyView,
Oracle Financials and SITS eVision.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
9

of
18

The first priority of this
strand of the roadmap

therefore should be to ident
ify those applications that
are amenable to externalised authentication and
then
migrate them to Shibboleth.

Two minor pre
-
requisites for this are to:



upgrade the current UCL Shibboleth implementation to version 2



ensure the Shibboleth implementation has
no single point of failure and scales to meet all
predicted future application loads



publish application development guidelines and sample code for implementing WebSSO and
supporting Shibboleth logout

This roadmap does not address “secondary authentication
” mechanisms that are implemented on
systems such as MyView. By their nature, these mechanisms are usually specific to single systems
and are not amenable to generalisation. Where strong authentication is required, UCL could
consider a move to two
-
factor

authentication, but this is not considered a priority in the near
-

or
medium
-
term.

We should also recognise that some external
-
facing applications need to authenticate users who
have neither passed through the UPI and central username creation process nor

belong to
institutions that are members of the UK Federation. One example of this type of ap
plication might
be a web
-
based
event booking application. In these cases we need to adopt an approach
that allows
us to uniquely identify these users without creat
ing multiple silos of authentication
.

There are two
approaches

to this solution. One possible approach is to add this type of user to our
existing Shibboleth authenticat
ion system,
identified as a “visitor” and excluded from any assertions
we might make on

the user’s behalf to the rest of the UK Federation. In order to support this
mechanism, we would need to create a common self
-
registration system for Internet
-
facing
applications and encourage application owners to make use of it.

A second, parallel, appr
oach is to encourage Internet
-
facing application owners to support emerging
standards such as OpenID.

We should consider acting as an OpenID identity provider as well as a
consumer.

In addition to these initiatives, the Authentication strand of this roadma
p should also
investigate the
value of

tighter integration of the centr
al Active Directory with token
systems. One example is to
integrate the RFID tags present in staff and student ID cards with RFID readers attached to cluster
and other centrally managed

computers. This would require tighter integration of the RALIC and
Active Directory systems. Integration of biometric authentication is not recommended, partly
because of the privacy concerns and consequent poor uptake but mainly because of the poor track

record of these types of authentication and their vulnerability to spoofing.

One obvious target for an authentication roadmap is desktop single
-
signon. This takes two forms:
common
authentication of computers and people at startup
(
e.g. an Active Director
y domain login
),
and common authentication of “thick” client applications that run on the desktop and need to
authenticate to some back end server.

The general trend

of application development

in UCL is away from client
-
server applications in
favour of web

apps.
There are very few client
-
server applications in Cluster WTS or Staff

WTS

.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
10

of
18

Attempting to implement an application
-
level single sign
-
on solution on managed desktops is
expensive and not warranted in the UCL environment.

In the context o
f Operating S
ystem

single sign
-
on
,

less than
5
0%

of all desktops

connected to the
college LAN are centrally managed

by ISD
. Active Directory policy at UCL has so far been limited to
securing logins from managed PCs and managing authorisation of access to the institutio
nal file
store.

UCL should open up the Active Directory environment to unmanaged desktops, including
Apple and Unix
machines, to allow users to authenticate to Active Directory and obtain AD
credentials at login. Non
-
Windows file servers should also be o
ffered the opportunity to create
machine accounts in the central AD.

A lower priority but still important is the ability to use the same credentials to authenticate to the
wireless networks available at UCL. eduRoam
already
support
s this, but it could be e
asier and we
should consider providing a consolidated RADIUS directory based on ActiveDirectory (see section
4.4
)
.

A separate but possibly related area is
to implement a common system to
support anonymous/bulk
transient iden
tities for conferences
, temporary identities issued to external principals (e.g. for access
to High Performance Computing resources) and

WiFi access for
visitors from non
-
eduRoam
institutions

that replaces

the current VisiNet
mechanism
.

The natural home f
or this functionality is
the existing Services system, which among other things is used to request UPIs, end user accounts
and email addresses for visitors .

Elapsed Time
Q
1
Shibboleth
upgrade
Publicise
&
productise
Shibboleth for web
apps
Trial token
-
based login
Open up AD to
non
-
managed PCs
Investigate
&
trial AuthN for
non
-
UCL users
(
OpenID as
a first attempt
)
Extend
Services
system for
transient IDs
Q
2
Q
3
Q
4

Figure
3
: Authentication
Indicative
Timeline

Sequence

Activity

1

Shibboleth adoption

2

Shibboleth upgrade

3

Transient User IDs

4

OpenID authentication

5

Investigate authentication mechanisms for non
-
UCL users

6

Add non
-
managed PCs to Active Directory

7

Token based login


4.3

Identity Lifecycle

Management

This theme focuses on the identity

components

that ISD should manage, together with the
management processes that support them.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
11

of
18

4.3.1

Identity and Attributes

As mentioned in section
1.1
, there are two main types of identi
ty
attribute
managed by ISD systems
at UCL. The Systems of Record for attributes like name, address
, position in the
UCL organisational

hierarchy

and staff/student number expose these attributes to one another and to properly
authorised systems via the UPI

mechanism. Essentially, the UPI system

(which is based on Oracle
views)

brings together attributes from all the SORs and exposes them as a consolidated attribute set
for consumption by
all SORs and also by
other identity
-
related systems

(see

Figure
4
: UPI High Level
View
)
.

HR
SITS
Services
U
P
I
V
i
e
w
s
LDAP
AD
NIS
LDAP
AD
OID
Enrichment
Enrichment
UPI

Figure
4
: UPI High Level View

The primary consumers of these consolidated attributes fall into two categories

as shown in the
diagram above
:



automated
“enri
chment”
processes that
create new identity information

(the second type of
attribute)
, e.g. the UPI assignment process and the central username/password generation
process; in some cases, these processes feed back this new identity information to the “mast
er”
SOR



identity repositories, some of which are used for authentication and authorisation purposes (e.g.
the central LDAP directory, Active Directory, NIS, OID
)

some of which are tailored for specific
information purposes (e.g.

RALIC,

the staff director
y,
OID

4.3.2

Services System

Of the three SORs (Northgate’s HR system, SITS/Portico and the Services system), only one


the
Services system


is “open” in the sense of
easy to modify and extend. As such, it is the candidate for
consolidation of existing functio
nality and the logical place to host new functionality.

As a principle, UCL should move away from the pull
-
based , batch processing mechanisms associated
with identity consumption as described above to (at minimum) a publish/subscribe or synchronous
push
-
based mechanism that uses the Services system as the owner of all non
-
SOR identity creation
functionality and as the master distributor of data to “downstream” repositories
.

As an example of the current batch process environment, examine
Figure
5
: User creation

below
that shows a high
-
level view of the process followed to create new users. This process runs
periodically, querying SORs directly or via temporary files for people who need a user ID and/or an
email address. After thes
e have been created, they are fed back to interested upstream systems via
a series of overnight batch updates.

UCL Identity Roadmap
v1.0


Status
: Draft


Page
12

of
18



IS processes
&
systems
HR
SITS
Services
U
P
I
V
i
e
w
s
UPI
New Staff
User
Registration
Pull
/
Push
Process
Mail
system
NIS
Open
LDAP
Students
Visitors via email
Services
Batch update
nightly
1
2
4
3
5
6
Batch update
nightly
Batch update
nightly
Pull
Pull
Push
MS
processes
&
systems

Figure
5
: User creation

The Services system already has a pipeline of enhancements
, inclu
ding a user interface uplift
. To
these, we should add:



migration of email address generation from the current
IS
-
managed scripts into a centrally
managed, on
-
demand process



migration of username / password generation from the current independently managed
scripts
into a centrally managed, on
-
demand process



migration of password reset request processing functionality from the current mechanism into a
centrally
-
managed, on
-
demand process


The above three activities are not simply a relocation of existing func
tionality. Instead, they are
intended to migrate from the current file
-
based “pull” processing to a more reactive “push” model
that invokes functionality on demand. The practical consequence of this, especially for password
synchronisation, is that the cur
rent mechanism is likely to be split into
two:

one component
associated with the identity repository that needs to be updated and the other associated with the
request. In effect, the Services system becomes the sole consumer of the data contained in the
c
urrent

CSO.COM file

and Intranet Groups files and communicates in near
-
real
-
time with the
systems interested in this data.


One major advantage of moving from the current model to this mechanism is that it becomes
feasible to apply validation and business
logic at the level of individuals and for upstream systems to
get real
-
time feedback on changes they request from downstream systems (e.g. update password,
assign new username, request expiry of user credentials etc.)

UCL Identity Roadmap
v1.0


Status
: Draft


Page
13

of
18

HR
SITS
Services System
User
Management
Service
Email
management
service
Mail
system
NIS
Open
LDAP
Real time
Updates

Figure
6
: Service
-
based user creation

Other work that needs to be undertaken in the Services system includes:



Rationalisation of roles (see section
4.5
)



Ability to define and assign users to multiple groups, inc
luding Intranet Groups derived from the
HR system but also including ad
-
hoc groups that may be used by “downstream” authorisation
systems
. Note that the Services database is not necessarily the target repository for this
information (this is more likely t
o be a consolidated directory


see section
4.4
), but it is the
logical place to host the functionality associated with this information.



Ability to add new SORs to the UPI environment


for example, to add some Active Director
y
attributes if that is where we choose to store e.g. PKI Certificates as described in section
4.1
.



Ability to act as the fallback repository for new identity
-
related attributes if none of the other
SORs
are appropriate


e.g.
to record a Library services “opt out” attribute that prevents the
related principal from making use of UCL’s institutional license for access to e
-
Journals.



Ability to support rules that operate on identity information and are triggered by changes in the
SORs


e.g. lock out a user account if the owner leaves UCL, then delete it after a grace period



Ability to recognise and propagate changes to common attributes between SORs. E.g. name,
address and other common attributes.



Ability to capture and propagate

to SORs changes to common attributes. The beginnings of this
functionality has already been developed as part of the staff directory management web
application, which supports name changes, but this needs to be extended to allow updates to be
propagated v
ia the appropriate SoR to other interested systems.



User interface uplift. The current user interface, based on Oracle Forms, is not appropriate to a
wider population of casual users.

An additional area of focus and investigation should be the exposure of
UPI data via web services,
and the extension of this read
-
only facility to permit updates to flow back upstream to SORs. This is a
complex area with a lot of interested parties and issues of data ownership, but it is being driven on a
number of fronts by a

requirement to provide a read/write User Profile for UCL academics in
particular that allows an individual to alter biographical data in one place and to have these
alterations propagate to a number of other systems. IRIS, the SLMS People Pages and the UC
L
Additions social networking application are all good examples of this.

This document stops short of recommending that identity within UCL should be consolidated into a
single master database of record. This is not practical for a number of reasons. As w
e have seen in
the preceding sections, attributes for any given principal may be stored in different locations. It is
the job of the UPI system to present a consolidated view of these
attributes across multiple SORs. It
UCL Identity Roadmap
v1.0


Status
: Draft


Page
14

of
18

should be the job of the Services Sy
stem going forward to provide a robust set of identity
-
related
services based on these attributes and others.

4.3.3

UPI and Types of Identity

As UCL makes more of its IT capabilities available to a larger audience, there is an increasing demand
for support of
tr
ansient

identities


i.e. unique identifiers that have a very limited lifetime and that
will be used only in certain specific circumstances. Examples of this include:



Enabling remote login to
systems such as
the H
igh Performance Computing environment



Temp
orary card access to buildings for conference attendees or other functions to which a large
number of non
-
UCL staff have been invited



Temporary WiFi or other network access for the duration of a conference



Other types of physical or non
-
physical visitor to

UCL who need access to UCL facilities

There are other groups that cannot strictly be categorised as transient but still are highly unlikely
ever to either visit UCL physically or use UCL’s IT systems in anything other than an ad
-
hoc way or in
ways that d
o not require us to take a rigorous approach to identification. Examples include users of
UCL public
-
facing web applications such as online recruitment, find
-
an
-
expert or other systems
where the application needs to track users between one visit and anothe
r but where the users are
highly unlikely to
need a “full” UCL identity. In such cases, we may not want to assign a UPI to an
individual but may still want to generate a partial identity of some kind. The identity roadmap needs
to accommodate these kinds

of requirement.

Q
1
Generate
email
addresses in
Services
Generate all ISD
usernames in
Services
Pasword resets
via Services
Role
rationalisation
SOA
PoC
User Profile
sharing pilot
User Profile
update pilot
Transient
IDs
Elapsed Time
Q
2
Q
3
Q
4

Figure
7
: Services System Identity
Indicative
Timeline

Sequence

Activity

1

Pilot SOA interfaces to Services System

2

Migrate email generation to Services System

3

Migrate password g
eneration to Services System

4

Implement Transient IDs

5

Role Rationalisation

6

User profile


4.4

Directory Convergence

UCL
ISD
operates a number of directories against which identity is authenticated. These include:

UCL Identity Roadmap
v1.0


Status
: Draft


Page
15

of
18



The central (
UCLUSERS
) Active Directory
, used to authenticate and authorise

access to Staff
and Cluster WTS



The central LDAP directory
, used to authenticate web application logins



NIS
, used to authenticate access to centrally managed Unix systems and to group users into
NIS groups, which are in
creasingly being superseded by Intranet Groups



The

Management Systems
ADM

Active Directory, used to authenticate and authorise access
to MS file stores.



The Oracle Internet Directory, used to authenticate users of Oracle Financials, RSS and other
systems

I
n addition to these directories, there are a number of other LDAP and AD repositories that take
subsets of the information held in one of these central systems and use it for other purposes.
Examples include the Staff directory (which hides entries for tho
se staff who have opted not to have
their contact information published) and many departmental directories that are used to
authenticate and authorise access to departmental file servers and other systems and to define
groups of users at the sub
-
department
al level.

This paper contends that a properly
-
attributed and administered Active Directory forest could be
used to take the place of all the above ISD systems and many of the departmental systems as well. It
is a popular misconception that AD is not an LDA
P directory. In fact, AD provides LDAP services out
of the box and can also be extended (via Microsoft’s IAS) to act as a NIS directory.

Rationalisation of Active Directories is
being examined

as part of the Hosted Email project. See
sections
2.3

and
4.1

for more detail.

This rationalisation is not a pre
-
requisite for hosted email,
however, and it is likely that we will postpone any major AD work until later in 2009.
This activity will
result in a
single, internally consistent Active Directory
forest within UCL that will contain a single

entry for each principal for whom an Exchange Labs email account is created (all students , staff and
alumni) and of each principal for whom a UCLUSERS domain accou
nt has been created. As such, it
forms a natural core upon which to consolidate (in order of priority):



Web SSO authentication and attribute mastering, replacing the central OpenLDAP directory used
by Shibboleth



LDAP
-
based web site and web application aut
hentication that is currently also served by the
central OpenLDAP directory



Centralised authentication of Unix system logins, replacing NIS



Staff directory information, replacing one LDAP directory



RADIUS functionality to authenticate and authorise wirele
ss network access as well as
administrative access to network elements

With proper design and delegated administration, this central AD forest could also be used by
individual departments for their own purposes, although this
roadmap does
not
attempt to ma
ndate
that activity.


UCL Identity Roadmap
v1.0


Status
: Draft


Page
16

of
18

Q
1
Q
2
Q
3
Consolidate
AD instances
Web SSO via
Shibboleth
/
AD
Begin LDAP
authN migration
to AD
NIS
Replacement
trial
RADIUS
integration
Staff
Directory
in AD
Elapsed Time

Figure
8
:
Directory

Convergence Indicative
Timeline

Sequence

Activity

1

Consolidate
and stabilise
AD
forest

2

Move Shibboleth to AD

3

Migrate LDAP authentication to AD

4

Staff

directory in AD

5

NIS replacement trial

6

RADIUS integration trial


4.5

Role Rationalisation

The most ambitious activity associated with Identity Management in UCL is an attempt to rationalise
the roles defined in UCL’s many IT applications. The value of t
his is clear and the problems
associated with its absence are summarised in section
3.1.5
. However, there is a poorly
-
defined
point of diminishing returns associated with any exercise of this type. In particular, a top
-
down eff
ort
to define institutional roles and impose them on or map them to IT systems is time consuming and
of dubious benefit.

The primary value associated with role rationalisation can be achieved by centralising the process of
user account creation and modifi
cation, automating the mapping of an individual’s position in the
organisational hierarchy to a set of roles owned and managed by participating IT systems, and
making it easy for end users to request variances from the set of privileges created for them by

default.

In the context of file system authorisation, roles can be easily confused with groups. In fact
, there
are only a limited number of roles (the allowable combinations of
own/
read/write/execute and
similar privileges) while there are a much greater
number of possible groups. Unix and Linux systems
present a major problem to the implementation of groups, however, as they usually
limit roles
recorded against one specific resource to an owner or a single group. <XXX: Check that AD’s NIS
implementation g
ets around the limit on number of NIS groups>

A plan was put in place in early 2008 to move UCL towards an integrated Access Management
solution. The plan and accompanying architecture and descriptive text can be found at
https://www.ucl.ac.uk/upi/liaison
-
group/3
-
July
-
2008/AccMan
-
Roadmap.pdf

. This project failed to
obtain funding in financial year 09/10 and is therefore “on hold” at least u
ntil late 2010. In the
interim, w
ork can be undertaken using existing resources to identify a master list of roles and groups
UCL Identity Roadmap
v1.0


Status
: Draft


Page
17

of
18

across the main UCL IT systems: SITS, HR, FIS, Moodle, Services and others and to decide whether it
is feasible or valuable to rationalise roles and groups across
these systems.

Ownership of Role information is fuzzy and distributed, and responsibility for addressing this area is
unclear. A data
-
gathering exercise, however, can be resourced organically and coordinated by the
ISD Director’s office. Further work must
be postponed until a solid business case can be made for
funding.















UCL Identity Roadmap
v1.0


Status
: Draft


Page
18

of
18


A.

Weighted Benefits

Benefit

Value

Enable hosted email authentication sync

Pre
-
req for hosted
email

Enable hosted email GAL sync

Pre
-
req for hosted
email

Improve ability

to create ad
-
hoc research/teaching groups

H

Improve ability to share files

H

Integrated building access

H

One point of self
-
service for ID

H

Reduce password calls to Helpdesk

H

Speed up access to apps for new starters

H

Remove annoying delay in PWD
update

H

Compliance

H

PKI digital signing & encryption

M

Remove artificial distinctions imposed by coarse grained roles

M/H

Enable hosted email SingleSO

M

Enforce common password rules: improve security

M

Introduce approvals workflow

M

Common second
ary authentication: reduces login failures

L

Extra cash from cashless vending

L

Improved security

L

Library access to digital resources

H

UCL Partners: access to UCL resources

L

Ability to grant transient access to external collaborators

H

Enable MS
domain authentication to NTLM & Kerberos
-
protected web
apps

M

Happy users (one with every Big Mac)

H

Simpler set of solutions

H

Whitepages for ID & user details

H

One point of self
-
service for access

M