Directory Services at UMass

1. Directory Services at UMass • Directory Services Overview • Some common definitions • What can a directory do or not do? • User Needs Assessment • What are our collective needs? • What are our collective expectations? • What we think they are… • What’s Next

2. Some Common Definitions • Identifiers – “A set of computer-readable codes that uniquely specify a subject” • Authentication – “The process of a subject electronically establishing that it is, in fact, the subject associated with a particular identity” • Directories – “Central repositories that hold information and data associated with identities”

3. What can a directory do for us? • Allow diverse application to access common, consistent data from a common storage area • Contain critical, customizable information about people, processes, resources, and groups • Implement a regular manner of identifying individuals with a relationship to the University • Provide the necessary infrastructure for future authentication and authorization services

4. What can a directory do for us? • Distinguish between identity and account • Currently the existence of an account yields implicit authorization to services • Provide a common, unique, unambiguous naming structure for objects • Not username, but identity • Not just for people, but also devices(?) • Enable Applications to use a common interface to access this data • LDAP, probably…

5. What can a directory do for us? • Reduce administrative overhead • Simplifying service definitions, and reduce duplicated effort • Provide a mechanism to create and organize groups of objects • Mailing lists, device grouping • Reduce complexity of existing systems • For both users and staff

6. What can’t a directory do for us? • Replicate database functionality • Directories are optimized for reading,not writing • Replace existing controlled access systems • But, hopefully, they can extend existing infrastructure to more applications

7. Needs assessment • What are our requirements? • What applications should access this data? • Who is authoritative for which information? • What common data definitions should we use? • What role do meta-directories play? • What are our expectations? • System availability • Control and management of data • Future extensibility

8. Needs assessment • What are our Campus needs (so far at least…) • Distinction between an identifier and account (authorization to specific services) • Simplified presentation of services to clients • Better interaction and consistency with departmental accounts and services • Maintaining FERPA protections for student records • Ability to handle identities outside the scope of PeopleSoft (vendors, visitors, etc)

9. Needs assessment • What are our Campus expectations • Reducing the overhead of managing multiple controlled access systems • Greater user control of directory information • A highly available, secure, authenticated directory service • Enabling future services such as VPN, PKI, Shibboleth

10. What’s Next? • How do we identify these needs and expectations? • Everyone may have different needs • We need to enable many applications, without excluding any • A directory infrastructure should enable and extend applications • What are other Universities doing? • Would that even work for us?

11. Useful links Internet2 Middleware (LDAP Recipe, DoDHE) http://middleware.internet2.edu/ eduPerson (common Higher Ed LDAP schema) http://www.educause.edu/eduperson/ 5 campus Authentication Committee http://dirserv.umassp.edu/

12. Example LDAP schema

13. Simplified Example • Client connects to application server (e.g. Netscape) • Application binds to directory, to make authenticated query • Application queries directory to authenticate user • Directory authenticates user to backend authentication system, send assertion to application

14. Not so simplified Example