Middleware Services
University Directory Service (UDS)
UW-Madison’s University Directory Service (UDS) is a set of UW-Madison (only) person data intended specifically for use in identification, authentication, authorization and contact management. (Use the InfoAccess service for access to data needed for other purposes.)
The UDS contains two main components that work together to gather data from various source systems and present them in a cohesive manner:
- The UDS Registry is an Oracle relational database that gathers information from source systems and creates a single view of a person, collecting information from various sources to capture information relating to that person’s roles in the University community. Campus organizations needing such information can access this data.
- The UDS Directory is an LDAP (Lightweight Directory Access Protocol)-accessible directory service that makes a subset of this information available to client applications and services for use in identification, authentication, authorization and contact management.
Address questions regarding UDS data to udsrequests@doit.wisc.edu. The process for requesting access to UDS data is outlined here: doit.wisc.edu/middleware/uds/access.asp.
Functional Overview
DoIT Middleware supports and maintains the UDS, which acts as the central authentication mechanism for most DoIT applications and, indirectly through NetID Login, for many campus applications as well. Middleware also provides the University White Pages directory, which is behind the People Search at wisc.edu/directories. This directory is typically used by email clients to search for addresses.
Where the data comes from
UDS begins with data stored in several disparate systems, the largest being UW-Madison’s Student Information System (ISIS) and UW System’s payroll processing center (the Integrated Appointment Data System, or IADS). Those systems continuously feed their data to DoIT, which aggregates it in a database called the UDS Registry. DoIT attempts to resolve duplicates by identifying and combining any records from different systems that are actually for the same person.
DoIT then assigns each person a unique Publicly Visible Identifier (PVI), which is guaranteed to be unique across all of UW System. We also create a UW-Madison NetID for each person in this system who is eligible to receive one and then add that NetID to the person’s record in the UDS Registry.
The UDS Directory
DoIT also maintains an LDAP (or Lightweight Directory Access Protocol, a protocol for querying and modifying directory services on a network) Directory of this data, which is fed from the UDS Registry. Changes made to data on source systems are reflected in the UDS Directory within about two hours, and generally much faster. NetIDs and passwords are stored in this Directory, along with configuration and preference data for many central services such as WiscMail and WiscCal. When users enter their NetID to log in, they are authenticating against this Directory, and some central services use this Directory for authentication.
The UDS Directory is not, however, publicly accessible. It is on a non-routed private network and is never directly available to campus applications. This protects everyone on campus, since the UDS Directory is the central authentication mechanism for most DoIT applications and, indirectly through NetID Login, many campus applications as well. Those central services that authenticate directly against the UDS Directory can do so only because they maintain a presence on the private network.
The White Pages Directory
If the UDS Directory is not publicly accessible, how can your email client look up an address from an “LDAP server”? DoIT actually runs two LDAP directories; your email client uses this second directory when searching for an email address. Called the White Pages Directory, this is also the data store behind the University White Pages, or the People Search at wisc.edu/directories. This directory’s data comes from the same sources as the UDS Directory, but through a completely different channel. Moreover, this data is privacy-filtered by the source systems, so that private data never exists on the White Pages Directory server.
This also means, however, that White Pages Directory data can never be guaranteed to match exactly the data in the UDS Directory. Only University faculty and staff, and those students who have chosen to be publicly visible, appear in the White Pages Directory, and no home address or other contact information is ever stored here. The White Pages Directory has no NetIDs or passwords and can never be used for authentication.
How to use directory data
For information on configuring your email client to use the University White Pages LDAP Directory, contact the DoIT Help Desk.
Even though the UDS Directory is not publicly accessible, campus applications now have two options for authenticating against it. DoIT’s NetID Login Service provides the equivalent of LDAP authentication for Web-based applications. For non-Web applications, the only way to authenticate a NetID is DoIT’s Kerberos Service. No other authentication mechanisms are available currently or in planning for NetID or LDAP authentication.