gla.smp/smp/LDAPuse-smp/ 2001-02-15/1
FINAL
Improving the authentication mechanisms to Intranet resources is an important goal of the Scottish Middleware Project. This is relatively easy to achieve in organisations which use tightly coupled systems from a single supplier (such as Microsoft's web server software Internet Information Server (IIS) running on Microsoft Windows NT or Windows 2000 servers). Such an arrangement is most common in small organisations or organisations that employ a very top down management style, which allows no deviations from a central policy. Few universities operate in single supplier IT environments and the Scottish Middleware Project is working on solutions which may be employed in heterogeneous IT environments, which currently employ a variety of authentication mechanisms to control IT and information access, such as Novell's Novell Directory Services (NDS), Sun's Network Information Service (NIS), Microsoft's Active Directory Services (ADS), Apache's htaccess files, MySQL's MySQL database, etc.
The Lightweight Directory Access Protocol (LDAP) is a derivative of the much more cumbersome X.500 directory model which never really achieve mass acceptance as a result of its complexity. LDAP is being seen by many as a route by which authentication across multiple types of directory services can be achieved and by which authentication to Intranet resources can be integrated with authentication to other systems.
Both the University of Glasgow and the University of St Andrews have employed LDAP to authenticate users and a summary of this experience is discussed below.
If looking up a directory make you think of directory enquiries, their potential is much greater than that in the digital world. They're not just for keeping lists of people's phone numbers, e-mail addresses, and departmental and home addresses. The first difference is that in the digital world, directories don't only store information about people; they can also contain any type of information to be shared or centralised, such as: software configuration and/or preferences, access privileges, group memberships, and busy/free calendar information. They can also be used to manage things like conference rooms or network resources (such as printers or fax machines).
A few applications for directories:
Having directories that follow a standards-based open protocol, moves us away from the current world where proprietary formats for information require separate copies of the same information to be created and maintained. Instead of being limited to looking up e-mail addresses in a local e-mail address book, users can search external directories that follow the standard protocol and applications can refer to an authoritative common source for details of people and things.
Initially developed at the University of Michigan, LDAP is now an Internet standard for directory services that run over the type of networks that we run in HE/FE(TCP/IP). One or more LDAP servers contain information that makes up an LDAP directory tree. An LDAP client (applications that want to look up information, such as login process) connects to an LDAP server and submits a query to request information or submits information to be updated. If access rights for the client are granted, the server responds with an answer or possibly with a referral to another LDAP server which has the information required.
An LDAP server is not simply a form of database, but a specialised server for directories. A directory can be distinguished from a general-purpose database by the usage pattern. A directory contains information that is often searched but rarely modified. Web host names or people's userids and e-mail addresses, for example, are assigned once and then looked up thousands of times. LDAP servers are tuned for this type of usage, whereas relational databases are much more geared toward maintaining data that's constantly changing.
Shared directories provide a mechanism to implement 'single sign-on', where one userid/password pair can be used to access all computers and resources within an organisation. The use of single sign-on in an organisation implies that equivalent levels of security are required on all systems and to access all information. In practice this is rarely likely to be true and some applications (perhaps the University Finance System, Payroll System, Human Resource Database, etc. might require a rather higher level of security than the minutes of the Information Strategy Committee). This problem can be overcome in a variety of ways:-
Two different uses of LDAP have been employed at Glasgow, one to facilitate access to an existing authentication directory by a web based application and the other to start to develop a university-wide web authentication mechanism, which can be used for other authentication tasks such as access to the Glasgow web cache from outside the institutional network.
As part of a comprehensive review of the student record (Student Records Improvement Project), it was agreed to make much of the student record available to students over the web. The application which was developed by Management Information Systems (MIS) at Glasgow is written in Java and interfaces with the student records system. The system allows students to view the majority of their record and to update such fields as the home and term-time addresses and their next of kin.
All students at Glasgow have access to a common set of applications for word processing, web browsing, e-mail, etc. and some networked file store. These facilities are available to each student no matter where they sit down at a machine on campus. This system is called the Common Student Computing Environment and student authentication is via a Novell Directory Service (NDS).
Novell provide the facility to install an LDAP server which will map LDAP protocols onto NDS directory entities and thus provide an LDAP interface to the NDS. This facility was configured so that the SURF program could use the NDS for authenticating students before giving them access to their (and only their) student record.
The SURF application asks the student for his/her userid and password and performs an anonymous bind to the Novell LDAP server asking for the full context of the userid presented. On receipt of this, the program makes an authentication request to the LDAP server combining the information gathered from student and LDAP server and receives a reply indicating whether or not the password is a correct match for the userid. On the basis of this answer the student is granted (or not) access to his/her record.
This system has been in operation for about 8 months and is currently servicing about 400 requests a day with few, if any problems. Its use has meant that the students can use the same userid and password for accessing their student record as they use to login to access their e-mail and filestore. This arrangement has been welcomed by the students and has kept management overheads down.
A growing number of committees in the University of Glasgow distribute their papers via web technology. Most of these are restricted to people who have computers attached to the University of Glasgow network, by a series of rather ad hoc measures usually involving IP address filtering. When the Committee Document System was introduced into the Senate Office in September 2000 there was a need for a more robust mechanism and the Permissions Database being developed by the Scottish Middleware Project was employed.
The Permissions Database which is developing to form the basis of a university-wide authentication mechanism, is based on LDAP using the public domain OpenLDAP server software. The permissions database is written in perl and the NET::LDAPapi is used to provide the LDAP functionality.
The Apache web server sees that the web page in question requires authentication and asks the browser to get the userid and password details. These details are sent to the server where they are handled by an authentication module written by the Scottish Middleware project called 'check-in'. Check-in retrieves the user record from the OpenLDAP database via an anonymous bind and makes an authentication request to the OpenLDAP server. If the authentication is positive, the request then passes to another SMP module called 'security-gate' which accesses LDAP tables dealing with authorisation (looking up group membership details if control is to a group - as is the case with the Senate - rather than to individuals). If the userid in question is authorised to access the file, then the web server returns it to the user's web browser.
Currently St Andrews uses LDAP servers to host a local directory of staff and student email addresses and to control access to the Data Warehouse and some Web pages.
LDAP was first used at St Andrews in December 1997 when IT Services installed the University of Michigan LDAP 3.3 server on one of its Sun systems to host a directory of staff and student email addresses. The directory is built from three sources; staff data from Personnel Services, student data from the Registry and data kept by IT Services of its users. A locally-written utility combines data from these three sources to create an ASCII file in LDIF format; a utility program provided with the UMich software then converts this file into the LDBM database format used by the LDAP server.
A PH-LDAP gateway was installed to permit queries via the Ph facility of Eudora; a UNIX ph client was provided for users (the majority at that time) of PINE on the Suns. Users of LDAP-enabled email clients (mainly Eudora, Netscape, Outlook Express) can directly query the directory. Access to the directory is restricted to clients with IP addresses in the St Andrews domain; this is done by configuring the external router to filter packets on port 389. The directory is still in regular use but further development of the service is required. The directory needs to be ported to a more up-to-date LDAP server since the UMich LDAP server is no longer being developed. Also the extent of access by students to the email directory needs to be reviewed as a result of the Data Protection Act 1998.
The Data Warehouse was introduced in 1997 to give University staff read-only access to central administrative data, principally student records, stored in an Ingres database. The original intention was to use ODBC in conjunction with PC client software (Impromptu) to access the data. In order that the system could be rolled-out more widely a web interface was developed and introduced in 1998. This proved very successful and the most common method of access to the Data Warehouse is now from web browsers.
Access to the Data Warehouse is controlled by username and password. Netscape Directory Server is installed on the Data Warehouse computer and hosts an LDAP directory containing usernames, passwords and group membership. The usernames and passwords are the same as those used for access to the IT Services Suns; a job runs every hour to keep the passwords on the LDAP server in step with the Sun passwords in the NIS maps. Users must apply on a paper form for authorisation to use the Data Warehouse. If approved their entry in the LDAP server is updated to add them to the dwusers group. This is done by adding their username to a text file containing the list of users currently authorised to access the Data Warehouse. A job is run regularly to read this text file and update the LDAP directory with membership of the dwusers group. The same file is also used to form a mailing list for communicating with users of the Data Warehouse.
Netscape Enterprise Server is used as the Web server on the Data Warehouse computer. The access control list is configured to restrict access to the Data Warehouse pages to users in the dwusers group. The pages are accessed using a secure (SSL) connection. On first connecting to these pages in a session the user is prompted for a username and password; this is validated against the values in the LDAP server. If the username and password is correct and the user is a member of the dwusers group access is granted to the Data Warehouse pages. There are two other additional access controls. First, the web browser must be running on a computer with an IP address in the St Andrews domain. Second, restrictions are placed via configuration files on the tables that can be accessed.
The use of LDAP for authentication has recently been extended to the main University web server. The LDAP server installed on the Data Warehouse computer is used and new groups have been created viz. staff and court for this purpose. The driver for this was the University Secretary's desire to widen participation to the formulation of the University's new Strategic Plan. Various issues for discussion were published on the Web, using the HyperNews online conferencing system. Authentication for HyperNews is normally done by issuing proprietary usernames and passwords and controlling access via the ht-access mechanism.
It was desired to obviate the need for separate identifiers so the above new groups (staff and court) were added to the LDAP database within the Netscape Enterprise Server system. The htaccess mechanism was removed from the HyperNews 'base article' pages and access given to the staff and court groups via LDAP. The LDAP usernames and passwords are uploaded hourly from the NIS database, so staff and Court members could use the same username and password in accessing the HyperNews forums that they use for electronic mail.
Apart from the clear advantage of not having two separate identifiers in this case, these groups can now be used for any other Web pages for which access must be controlled to these groups. (A spin-off of this process is that the Clerk's office could have an on-line database of Court member details which they could maintain themselves and from which an automatic feed could be taken to the LDAP directory. At the time of writing, this has not yet been done.)
It is worth mentioning that some of the University's Court members are lay members and did not already have accounts on the system. In order to grant them access to the HyperNews discussion forums, sponsored accounts were created for them. (At St Andrews, a sponsored account is one that is given to users who do not have a contract with the University but have some well-defined association with it. A sponsor signs a form to this effect.). This raised the issue of whether a full account is really needed for such users or whether a "for network access only" account would be more appropriate.
Committee Document System http://www.gla.ac.uk/projects/scotmid/gendocs/cdocs-smp.html
OpenLDAP http://www.openldap.org/
NET::LDAPapi http://www.linc-dev.com/perl.html
HyperNews http://www.hypernews.org/
University of Michigan LDAP server http://www.umich.edu/~dirsvcs/ldap/
Netscape Directory Server http://docs.iplanet.com/docs/manuals/directory.html
Prepared by: James Currall and John Henderson
Last modified on: Wednesday 7th November 2001