Peter Austin, Senior LAN Administrator, Knowledge and IT Services Centre [HREF1], Edith Cowan University [HREF2], 2 Bradford Street, Mt Lawley WA 6050. p.austin@ecu.edu.au
An inter-university authentication and authorization directory service deployment which implements a new schema, derived from a common consensus between the participating universities and ideas contained in the eduPerson schema, is described. New attributes which make up the schema are listed and security provisions for controlling access to data represented by the schema are outlined. A sample application, developed to test the directory deployment, is described. In addition, preliminary performance test results are outlined.
In 2001, the West Australian Group of University Librarians (WAGUL) obtained funding to deploy a directory infrastructure that would enable cross-university authentication and authorization for university Web applications. The main aim of the project was to enable staff and students from any of the participating universities to gain authorized access to information resources, held by other participating universities, via Web applications.
A project team comprised of library and IT staff from each of the member universities (Curtin University, Edith Cowan University, Murdoch University, Notre-Dame University and the University of Western Australia) was assembled and the WA Libraries Authentication Project (WALAP) was launched to select and implement the directory infrastructure.
A Request For Proposal was issued in 2001, with Computer Associates' E-Trust Directory being the successful proposal. During 2002, the directory design was developed and implemented at each of the universities. Now, in 2003, each university is developing procedures for provisioning their portions of the directory, and examining how existing applications and projects may use the directory.
This poster session describes and demonstrates:
The session also provides results data from preliminary performance testing.
Note that the content of this poster session will assume some previous knowledge of LDAP directories and the concepts surrounding them.
The Directory Information Tree (DIT) for the WALAP directory is very simple; consisting of:
Within each Organization container, the WALAP schema specifies three Organization Unit (OU) containers:
Two new object classes have been defined for the WALAP directory schema; auEduPerson and auEduUnit.
The auEduPerson class has been defined by WALAP to represent people stored in the directory. The class is structural and inherits from the class inetOrgPerson, as defined in RFC 2798. An instance of the auEduPerson class can only occur within an OU container object and is named by the "cn" attribute.
It was agreed that for the purposes of WALAP, the auEduPerson class would:
The new attributes defined for the auEduPerson class are:
Attribute Shared Description auEduPersonID Yes Contains an alphanumeric value that uniquely identifies the person; normally a student or staff number. This attribute is mandatory. auEduPersonExpiryDate Yes Contains a date in the format "yyyy-mm-dd" which indicates that the person is no longer current at the university. This attribute is not mandatory. auEduPersonType Yes Contains a value representing a broad level of person categorization. Three values have been defined for WALAP; "student", "staff" or "other". The attribute is provided for authorization purposes and is not mandatory. auEduPersonSubType Yes Contains a value representing a finer level of person categorization. Six values have been defined for WALAP; "undergraduate", "honours", "postgraduate", "external", "visitor" and "unclassified". The attribute is provided for authorization purposes and is not mandatory. auEduPersonActiveUnit Yes Contains the distinguished name of an object representing a teaching unit the person is a member of. The attribute is provided for authorization purposes and is not mandatory. auEduPersonSalutation No Contains the preferred salutation for the person. Possible values include "Ms", "Mr", "Dr" and "prof". This attribute is not mandatory. auEduPersonPreferredGivenName No Contains the preferred given name of a person. This attribute is not mandatory and may be the same as the inherited "givenName" attribute. auEduPersonPreferredSurname No Contains the preferred family name of a person. This attribute is not mandatory and may be the same as the inherited "sn" attribute. auEduPersonEmailAddress No Contains the email address of a person. This attribute is not mandatory. auEduPersonLibraryBarCodeNumber No Contains an alphanumeric barcode value as used by university libraries. This attribute is provided for authentication purposes and is not mandatory. auEduPersonLibraryPIN No Contains an alphanumeric value used by library systems for authenticating patrons against their barcode. This attribute is provided for authentication purposes and is not mandatory.
The inherited attributes defined for the auEduPerson class are:
Attribute Shared Description cn Yes Contains an alphanumeric value that uniquely identifies the person and forms part of the object's distinguished name. This attribute is mandatory. userPassword Yes Contains an encrypted password to be used to authenticate a person. This attribute is not mandatory. userCertificate Yes Contains an X.509 certificate. This attribute is not mandatory and is not used at present. member Yes Contains the distinguished name of an instance of any other object class. This attribute is not mandatory and is not used at present. sn No Contains the family name of the person. This attribute is mandatory. givenName No Contains the first name of a person. This attribute is not mandatory. displayName No Contains the preferred name of a person for display purposes. This attribute is not mandatory.
If individual universities wish to define additional attributes, they can define a new object class, derived form auEduPerson.
The auEduUnit class has been defined by WALAP to represent course units stored in the directory. An instance of the auEduUnit class can only occur within an OU container object and is named by the "cn" attribute.
The new attributes defined for the auEduUnit class are:
Attribute Shared Description auEduUnitCode No Contains an alphanumeric value that uniquely identifies the unit. This attribute is mandatory. auEduUnitName No Contains the title of the unit. This attribute is not mandatory. auEduUnitActiveMember No Contains the distinguished name of an object representing a person who is a member of the unit. This attribute is not mandatory.
The inherited attributes defined for the auEduUnit class are:
Attribute Shared Description cn No Contains an alphanumeric value that uniquely identifies the unit and forms part of the object's distinguished name. This attribute is mandatory.
The directory design was implemented using Computer Associates' x.500-compliant e-Trust Directory product. This product provides all of the advantages of x.500 directories such as standards-based distribution and replication of the directory database, along with full LDAP v3 compliance to enable easy integration with applications.
Each Organization container in the DIT is represented by a Directory Service Agent (DSA) instance, installed on servers located at the university represented by the Organization container. Together, these DSA instances form a single directory. This structure was created to ensure that:
In addition, to maintain high availability, each university's DSA is replicated to another DSA installed on another server at that university. If the primary server becomes unavailable for any reason, the secondary server is available to take over. (Note that the mechanism by which this would occur is not defined by the project.)
Communication between DSAs is provided by the x.500 Directory Server Protocol (DSP), whilst communication between Directory User Agents (DUAs) is provided by the LDAP protocol. It is expected that all DUAs accessing the directory will be applications, and that a DUA will only ever connect to the DSA located at the university hosting the DUA. All inter-university communication will be between DSAs using DSP.
Security is paramount to the success of this project, due to the sensitivity of the data stored in the directory.
Security for DSA to DSA communication is implemented by:
Security for DUA to DSA communication is implemented by:
Each DSA has a super user account that has full access to that DSA only; the user has no access to any of the DSAs located at other universities. In addition, this user account controls the access rights granted to other DSAs.
Note that all of the above security can be over-ridden by operating system level security so it is essential that servers be suitably secured.
DUAs have read-only access to the People and Units containers. The accessible attributes for both local and remote DSAs are listed in the table below.
Object Class Attribute Local Remote auEduPerson cn Yes Yes auEduPersonID Yes Yes userPassword Yes Yes auEduPersonExpiryDate Yes Yes auEduPersonType Yes Yes auEduPersonSubType Yes Yes auEduPersonActiveUnit Yes Yes member Yes Yes userCertificate Yes Yes auEduPersonEmailAddress Yes No displayName Yes No auEduUnit cn Yes Yes auEduUnitCode Yes Yes auEduUnitName Yes Yes auEduUnitActiveMember Yes Yes
The design requirement for performance was up to 10 authentications per second, with an average of 5 per second. Testing with a 120,000 object directory database running on a dual-processor 1.2GHz Pentium PIII server with 1.25GB of RAM and using the Windows 2000 Advanced Server operating system has demonstrated an average rate of 42 authentications per second using the slowest authentication algorithm.
The test program was accessing the directory across the local network and was the only application accessing the directory. It is expected that supporting multiple connections may slow performance, however enabling caching on the directory server generally improves performance by a factor of 10. Further performance testing under more realistic application loads, and with caching enabled, needs to be undertaken.
Each university will be provisioning their portion of the directory according to their own established procedures. This part of the project is currently underway, with provisioning at each university expected to be in production by the end of May, 2003. It is expected that provisioning procedures will update the directory on a daily basis at minimum.
The poster session will describe how directory provisioning is undertaken at Edith Cowan University.
As part of the initial directory implementation, a basic sample application (DUA) was created to test the directory configuration. The application accepts login name, password and university information from a user then authenticates them against the directory. If authentication is successful and the user is a student, the user is asked to enter a course unit code. If the student user is enrolled in the unit, information about the unit is displayed. For staff users, information about the staff user is displayed.
The application was written as a Java servlet and, whilst being very simple, it provides an API that can be used by other Web applications to access the directory.
This application will be demonstrated during the poster session.