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

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”

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

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…

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

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

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

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)

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

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?

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/

Example LDAP schema

dc=umass,dc=edu

OU=people OU=devices

uid=123456NetID=cmisra

givenName= Christophersn = Misra

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

Directory

ClientApplication

Server

2. LDAPS (bind)

Kerberos

4. S

AS

L(kr

b5)

1. HTTPS3. LDAPS (query)

Not so simplified Example