Identity Roadmap v1.0 - UCL

Document Sample
Identity Roadmap v1.0 - UCL Powered By Docstoc
					LONDON’S GLOBAL UNIVERSITY




                     Identity Management Roadmap




          Version:   1.0
          Date:      13h May 2009
          Status:    Draft
          Author:    Simon Farrell


          Version History

          Version    Date              Comment
          0.1        17th April 2009   First draft to inform brainstorming sessions
          0.2        23rd April 2009   Second draft for internal review
          0.3        28th April 2009   Third draft for feedback from Design Authority
          1.0        13th 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      Directory 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




 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 gathered 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 requested. 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 identifiers for an individual (UPI, staff 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. See especially section 4.3 for a
    more detailed discussion.

    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 authentication 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 authenticated 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) decides 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 can 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
    abilities to read and to write files are generic privileges typically defined 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.

    Roles 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 permit
    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,


                                                  Page 1 of 18
UCL Identity Roadmap v1.0                                                                   Status: Draft


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.

Groups 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.




                                             Page 2 of 18
    UCL Identity Roadmap v1.0                                                                        Status: Draft




 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 multiple username and password combinations with each UPI1
       Generate email accounts 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 Northgate with her swipe card record in RALIC)
       Define groups of individuals based on their departmental membership within the HR and
        Registry systems and use these groups to authorise access to resources in some IT systems. For
        example, only currently serving staff are permitted access to the Staff WTS system.
       Implement a mechanism to propagate usernames and passwords into multiple IT systems

    The last point needs a slightly longer explanation. Because of the diversity and (in some cases)
    proprietary nature of 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 the 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, UCL 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 surrogate key generated to permit mapping of identities between
    systems and as such is only used by the identity management infrastructure.


                                                    Page 3 of 18
    UCL Identity Roadmap v1.0                                                                  Status: Draft


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 based on Intranet Group
        memberships.

2.4 Funding
    In January 2009, UCL was unsuccessful in obtaining a JISC grant for Identity-Management-related
    activities. This 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 investment, 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 Systems and
    Information Systems. Identity is a concern that cuts across organisational boundaries.




                                                 Page 4 of 18
      UCL Identity Roadmap v1.0                                                                       Status: Draft




 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 passwords 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 Honorary
       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, the 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 systems.
       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
       examples 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 the 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 according 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.




                                                     Page 5 of 18
      UCL Identity Roadmap v1.0                                                                     Status: Draft


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 only 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 systems 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 exceptions, this 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 information 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 opportunity 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 focuses 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.




                                                    Page 6 of 18
    UCL Identity Roadmap v1.0                                                                               Status: Draft




 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 authenticates 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 integrated with the existing
        password synchronisation mechanism. Work is already under way to achieve this. Other AD
        instances in Prion 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

                                                                                                        Existing
                                                                                                       password
                                                                                                         sync
                                                                                                       mechanism




          Microsoft
                                                                            “UCLUsers”
          Live.com
                                                       ILM                    Active                       UPI
           Identity             Internet                                     Directory
            store




          Email identity                                         UCL Identity creation & synchronisation


                                  Figure 1: ILM Synchronisation with Microsoft Live.com




                                                     Page 7 of 18
    UCL Identity Roadmap v1.0                                                                               Status: Draft


    This approach leverages the existing password 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. However, ILM
    cannot 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. See 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 identified security
    concerns related to storing UCL passwords off-site at a Microsoft facility.

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

       The ability 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 email in a simple, seamless way. While users of desktop email
        clients can use other sources of digital certificates, note that web mail users cannot currently use
        such certificates.

                                    Due
                                                               AD cleanup
                                    Diligence
                                                               complete      Student
                                    complete                                           Certificate
                                                                             live
                                                                             service   Authority
                                                Pilot                                  Implementation



                           April        May             June        July     Aug            Shibboleth
                           2009         2009            2009        2009     2009           integration
                                          Agreement                                         Investigation
                                          to proceed               ILM Sync
                                                                   implemented


                                   Figure 2: Email Project 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 principle 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 bespoke-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.




                                                         Page 8 of 18
UCL Identity Roadmap v1.0                                                                   Status: Draft


The first priority of this strand of the roadmap therefore should be to identify 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 application 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 creating 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 authentication 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, approach 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 roadmap should also investigate the
value of tighter integration of the central 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 Directory 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 .



                                             Page 9 of 18
    UCL Identity Roadmap v1.0                                                                               Status: Draft


    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 of Operating System single sign-on, less than 50% 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 institutional 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 offered 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 supports this, but it could be easier 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 identities 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 for this functionality is
    the existing Services system, which among other things is used to request UPIs, end user accounts
    and email addresses for visitors .

                                                     Extend
                                                                            Investigate & trial AuthN for
                                                    Services
                                                                            non-UCL users (OpenID as
                     Shibboleth                   system for
                                                                            a first attempt)
                       upgrade                 transient IDs



                    Elapsed Time               Q1              Q2            Q3               Q4
                Publicise & productise
                                                                  Open up AD to         Trial token-
                   Shibboleth for web
                                                               non-managed PCs          based login
                                 apps


                                         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.




                                                      Page 10 of 18
      UCL Identity Roadmap v1.0                                                                  Status: Draft


4.3.1 Identity and Attributes
      As mentioned in section 1.1, there are two main types of identity 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).

                                                                              LDAP
                                                                               LDAP
                                    HR                      U
                                                            P                  AD
                                                                               AD
                                                            I

                                   SITS                     V                  NIS
                                                            i
                                                            e
                                                                               OID
                                                            w
                                  Services                  s
                                                                             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 “enrichment” 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 “master”
          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 directory, 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 functionality 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 these have been created, they are fed back to interested upstream systems via
      a series of overnight batch updates.


                                                   Page 11 of 18
UCL Identity Roadmap v1.0                                                                         Status: Draft




                             6       Batch update
                                        nightly

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


                                                 Figure 5: User creation

The Services system already has a pipeline of enhancements, including 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 functionality. 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 current 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
current 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.)




                                                     Page 12 of 18
UCL Identity Roadmap v1.0                                                                  Status: Draft



                                              User                                Mail
                                           Management                            system
                       HR                    Service


                                                 Services System                  NIS
                                                                     Real time
                       SITS                                          Updates
                                              Email
                                           management                            Open
                                             service                             LDAP



                                    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, including 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 to 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 Directory
   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 via 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 UCL
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 we 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


                                              Page 13 of 18
      UCL Identity Roadmap v1.0                                                                               Status: Draft


      should be the job of the Services System 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 transient 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 High Performance Computing environment
         Temporary 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 do 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 another 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.

                                          Generate
                                          email
                                          addresses in           Pasword resets             Role
                                          Services               via Services               rationalisation




                Elapsed Time        Q1                      Q2                    Q3                   Q4


                                    SOA              Generate all ISD
                                    PoC              usernames in            Transient        User Profile    User Profile
                                                     Services                IDs              sharing pilot   update pilot



                                   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 generation 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:




                                                         Page 14 of 18
UCL Identity Roadmap v1.0                                                                    Status: Draft


       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 increasingly 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

In 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 those 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-departmental 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 LDAP 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 account 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 authentication 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 wireless 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 mandate
that activity.




                                             Page 15 of 18
    UCL Identity Roadmap v1.0                                                                      Status: Draft


                                          Consolidate            Begin LDAP              NIS
                                          AD instances           authN migration         Replacement
                                                                 to AD                   trial




                Elapsed Time        Q1                                 Q2                     Q3

                                                     Web SSO via             Staff
                                                                                          RADIUS
                                                     Shibboleth / AD         Directory
                                                                                          integration
                                                                             in AD


                                 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 this 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 effort
    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 modification, 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 gets 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 until late 2010. In the
    interim, work can be undertaken using existing resources to identify a master list of roles and groups




                                                  Page 16 of 18
UCL Identity Roadmap v1.0                                                                  Status: Draft


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.




                                            Page 17 of 18
UCL Identity Roadmap v1.0                                                       Status: Draft




A. Weighted Benefits
 Benefit                                                            Value
                                                                    Pre-req for hosted
 Enable hosted email authentication sync                            email
                                                                    Pre-req for hosted
 Enable hosted email GAL sync                                       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 secondary 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




                                           Page 18 of 18

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:11/24/2012
language:Latin
pages:20