History and technology

History and the technique of the Identity & Access Management System (IAM) of the University of Leiden.


The University Leiden Community Network (ULCN) is a collection of ICT-related facilities for the University community. Every student, staff member and external is given an ULCN account that provides them with access to relevant facilities needed for their study or work. For example workstations, Blackboard and the Catalogue UBL.
ULCN has developed into a full Identity & Access Management System (IAM). Identity & Access Management is the term used for managing the rights and facilities (authorizations) available to an entity (user or group). A digital identity (an account) is created to manage these rights and facilities. This avoids the necessity of registering local accounts in applications.
The central authentication mechanism is the heart of ULCN. This central authentication mechanism controls the user name and password entered when a user logs in to a ULCN-linked application. Once these details have been successfully verified, access to the application is permitted. 
Two important processes involved in Identity Management are: registration and provisioning.
Registration of entities takes place in one or more source systems. ULCN has three source systems: uSis (for students), SAP (for staff members) and GMS (for externals). Once a user has been registered in one of the source systems, an ULCN account is created. It is not possible to create a ULCN account outside the source systems. Changes to user information can only be made in the source systems and are passed on to ULCN via transactions.
ULCN is the link between the source systems and the relevant applications. Provisioning sends account details from ULCN to the applications. With deprovisioning access will be denied.


  • 2000: start of ULCN. Students receive an ULCN account that gives restricted access to a limited number of applications. Scripts send information from ULCN to the applications.
  • 2001 and 2002: new applications are linked, including workplace environments for students.
  • 2002: staff members are also given an ULCN account.
  • 2003: start of renewing the architecture. Scripts are replaced by stable (partly real time) links. The processes are governed by the source systems (SAP and ISIS) and it is no longer possible to change details manually in ULCN.
  • 2004: new version into production. ULCN develops into a full Identity & Access Management System.
  • 2005: more applications are connected to ULCN, such as the VUW workplace environment.
  • 2006: start development of a register system for externals. Up to this time, externals were registered in the source systems (SAP of ISIS).
  • 2008: the Guest Management System (GMS) into production. GMS is the third source system for ULCN.
  • 2009: ULCN connects to the SURFfederation. Federative Identity Management gives access to external applications, such as publications from publishing houses and other universities.
  • 2010: the student information system ISIS has been replaced by PeopleSoft Campus Solutions (uSis). Replacing the old ISIS-link.
  • 2010: extending the links with the workplace environments. This will give staff a single password for both their workplace and their ULCN account.
  • 2010: helpdesk can sent new passwords by sms messages.
  • 2011: the LU-Card connects to ULCN, including uploading of passport photographs.
  • 2012: replacement of the software of uMail.
  • 2013: replacement of the University Address Book.
  • 2013: provisioning of account details by email. User who have forgotten their password can reset their password without the intervention of a helpdesk.
  • 2013: start Single Sign On (SSO). A user has to login only oce to use multiple applications.


The Components of ULCN are developed with Novell software:

  • The Meta Directory of Identity Vault, abbreviated to IDVault (a security box) is the central storage medium for the information on identities (students, staff and externals). In addition, two other storage media, the MAIL TREE and the SERVICE TREE, store a selection of the details from the Meta Directory.   
  • The Meta Directory Engine directs the different processes to synchronize the details between the Meta Directory and a linked application.  
  • The Identity Manager Drivers (abbreviated to IdM driver, formerly DirXML links) ensure the actual transfer of information.
Incoming information
The uSis (via Component Interface API) and GMS (via NCP) source systems prepare changes real-time for the relevant IdM driver. SAP (via iDoc) prepares the changes from one day during the following night. The IdM driver checks at intervals of a minute for new changes, transforms these to XML and then applies relevant rules and policies. The transformed XML message then arrives at the Meta Directory Engine that stores the information in the Meta Directory. If appropriate, internal IdM drivers synchronize changes in the Meta Directory with the SERVICE TREE.
Outgoing information
There are three methods whereby outgoing applications link with ULCN:  
  • IdM driver
    Most IdM drivers have been developed for linking with workplace environments and services. The IdM driver passes every change in ULCN in real time on to the relevant workplace environment: from ULCN to the outgoing workplace environment (push).
  • LDAP link
    An LDAP link works in reverse: the application asks ULCN for information (pull). An example is Blackboard. 
    • Many applications use the LDAP link for checking whether the user name and password entered appear in ULCN (authentication). 
    • A small number of applications obtain information from ULCN (the SERVICE TREE). This operation take place a few times a day.   
  • Radius link
    A Radius link works in the same way as an LDAP link, but uses a different protocol to communication.  For example, Eduroam.

Last Modified: 27-09-2013