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 1.Client connects to application server (e.g. Netscape) 2.Application binds to directory, to make authenticated query 3.Application queries directory to authenticate user 4.Directory authenticates user to backend authentication system, send assertion to application

14. Not so simplified Example