The University of Wisconsin University Directory Service UDS

1. The University of Wisconsin University Directory Service UDS • A repository of people information • Has been in production for about a year. • Serves White pages, portal, and a growing number of other applications. • Laying track ahead of the train.

2. Mail Clients Human Resources Registry Database Authentication Requests LDAP Directory JOIN RULES ISIS Portal Services Special Authorizations Registry Transactions Others? Photo ID WiscWorld Others? UDS Conceptual Overview

3. Registry Database JOIN RULES Registry Transactions Components of the UDS • The Registry

4. Components of the UDS: Registry • A relational database in Oracle • Design principles: • Accept data as-is • Don’t make assumptions about correctness. • Don’t try to determine whose element is the “most correct” • Keep it as flexible and open to change as possible

5. Components of the UDS: Registry • What’s in there: • Data to validate a person’s claim of identity (authentication) • Role information and other data helpful to determine eligibility • Contact information.

6. Components of the UDS: Registry • What it feeds: • Extracts for applications like Photo ID and WiscWorld • Extracts that are better suited to a SQL environment than to LDAP • Data warehouse. • The LDAP Directory

7. Components of the UDS • The Directory LDAP Directory

8. Components of the UDS: Directory • Purpose: • Designed to make Registry data accessible via LDAP • Optimized for very high read volumes, relatively few writes • Intended for high-speed response to small queries (authentication sessions, contact lookups, etc)

9. Components of the UDS: Directory • Environment: • Accessed via LDAP v3 • wiscEduPVI, wiscEduPerson, wiscEduDepartment • Some elements require authentication prior to access

10. Components of the UDS: Directory • What’s in there: • Contact information that is generally accessible • Person-related information and security info • netid, campusid, pvi, affiliation info, password hash, • Attributes needed by certain vendor-supplied applications

11. UDS: Uses • Applications including • Portal • Mail • Calendar • Other portal delivered services • Rec Sports, Photo ID • On-line student services. (authN via portal)

12. UDS: Current Status • Accomplished so far: • Authentication services for the My UW-Madison portal and services delivered through it including mail and calendar. • Role information to My UW-Madison portal • Interface for apps to get authorization attributes. • LDAP-accessible white pages • pH data through an LDAP gateway

13. UDS: Yet to do • Address waiting list of applications wishing to user the directory • Expand the portal application • Integrate with PeopleSoft 8 • Integrate with new HR system • Former student/employee

14. UDS: Yet to do • Enhance role information • “Fourth Source:” new groups of people who are not affiliated by being enrolled or paid. • Delegated admin/RA function. • Policy and possibly API (Shib Attribute Authority?) for “other” apps. • Integrating people info distributed across many directories.

15. Directory Services: Ongoing • Policy: We are continually examining and revising data access policy • Scalability: the directory services team is placed at the convergence point of all project critical paths. • To some extent this is unavoidable. Each vendor-supplied LDAP application will create its own demands for attributes • But we need to commoditize UDS services for our own applications.