Transcript Directory Services at UMass  Directory Services Overview  Some common definitions  What can a directory do or not do?  User Needs.

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
uid=123456
NetID=cmisra
giv enName= Christopher
sn = Misra
OU=devices
Simplified Example
2. LDAPS (bind)
1. HTTPS
3. LDAPS (query)
Directory
Application
Server
1.
2.
3.
4.
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
4. SASL(krb5)
Client
Kerberos
Not so simplified Example