Enterprise directory service at college park
Download
1 / 17

Enterprise Directory Service at College Park - PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on

Enterprise Directory Service at College Park. David Henry Office of Information Technology University of Maryland College Park david_henry@umail.umd.edu. History. Umail directory – 1990 faculty/staff only Gopher/CSO directory – 1993 f/s only Added web page access – short time later

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Enterprise Directory Service at College Park' - melissa-rosales


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Enterprise directory service at college park

Enterprise Directory Serviceat College Park

David Henry

Office of Information Technology

University of Maryland

College Park

david_henry@umail.umd.edu


History
History

  • Umail directory – 1990 faculty/staff only

  • Gopher/CSO directory – 1993 f/s only

    • Added web page access – short time later

    • University wide effort to build combined directory

      • X.500 considered, but wasn’t ready

      • Decided on gopher with single search page (umbc)

  • First LDAP – 1995 f/s only

  • Current LDAP – 1999 f/s/students/affiliates


Content
Content

  • People

    • Prospective students

    • Students

    • Faculty (current and Emeritus)

    • Staff

    • Affiliates ( Visiting faculty, Golden ID, etc.)

    • Alumni

  • Other things too


Where we are now
Where we are now

  • Running IBM Secureway LDAP server

  • Contains faculty, staff, students, affiliates

    • Does not contain alumni

    • Access to student data is limited (for now)

  • LDAP is not the primary source of most data

  • Data feeds required

    • HR, SIS, ARS, affiliates, etc.

    • Data warehouse simplifies

  • Weekly updates


Current work
Current work

  • On-the-fly updates of certain data elements

    • Privacy flags (Buckley)

    • Email address

  • Ultimately want to update each data element as appropriate

    • Instant (e.g., email, privacy flags)

    • Daily (e.g. registration/course info)

    • Weekly (e.g. address, phone, etc.)


Who is involved
Who is involved?

  • LDAP Steering committee

    • OIT staff only

    • Involving Administrative and Academic IT support units

  • Team effort

  • Data Warehouse/DBA’s

  • Programming staff

    • Construct data feeds

    • Process/consolidate data

    • Web based tools


Why do all this
Why do all this?

  • Single sign-on

  • Common and consistent (standards-based) mechanism for authentication and authorization

  • 24X7 services

  • Can use freely available access tools

  • Don’t need special client tools (e.g. Oracle)

  • Many COTS packages contain hooks for LDAP already


Some specifics
Some specifics

  • Distinguished name uses employee number

    • Everyone in the people databases gets one

    • It is unique

    • It never changes once assigned

    • 8 digits plus a check digit

  • Selected attributes

    • Name, uid, email address, phone number, ssn*

    • Students*: college, major, courses*, class standing*

    • F/S: title, department, home address*, home phone*

      * Restricted access


A critical resource
A Critical Resource

  • As the directory becomes a critical part of the enterprise infrastructure, it becomes critical to have stable, always available services.

    • Systems should have redundant components

    • Should run replicated servers

      • Located on different parts of the network

      • With battery backup

    • 3 replicas

      • Any two should be able to handle load


Directory enabling applications
Directory Enabling Applications

  • Permissions required for each application

  • Buckley entries won’t appear otherwise

  • Certain attributes are protected

    • Ssn, registration info

    • Optionally home address, phone, etc.

  • Each app should have its own authn id/pwd

  • Authorization to each attribute controlled by the data steward for that attribute


Some directory enabled apps
Some Directory Enabled Apps

  • Email

    • Directory search (email addresses)

    • http://www.oit.umd.edu/staff/

    • https://cgi.umd.edu/ldap_search

    • Central forwarding agent (name@umd.edu)

  • CorporateTime scheduling software

    • Authorization/authentication

    • Bunch of attributes

    • http://calendar.umd.edu/

  • Web sites

    • Authorization/authentication

    • http://www.agnr.umd.edu/AGNRWebAdmin/index.cfm


Some potential directory enabled apps
Some Potential Directory Enabled Apps

  • Unique ID

  • Portal authorization/authentication

  • Dial-up/DHCP access

  • Card key access

  • Roles based authorization

  • Single sign-on

  • Dynamic email lists (e.g., class, department membership)

  • More…


Examples
Examples

  • Directory Search

    • Netscape Addressbook

    • Staff listing – www.oit.umd.edu/staff

  • Authn/Authz

    • Corporatetime

    • Webpage access www.agnr.umd.edu/internal

    • Affiliates DB updates


Issues
Issues

  • Establishing primary source for each data element

  • Password changes need to be centralized

  • Establishing policies

    • Who is in

    • Who isn’t

    • What types of information to include


Security services
Security Services

  • PKI requires a directory for publication of the public key

    • See www.inform.umd.edu/About/Staff/dave/PKI

  • Encryption

  • Signed documents

  • Secured access to web server

    • Note secure server does not mean the data is secure on the server, just getting between client and server


Conclusion
Conclusion

  • A directory provides the basis for a common set of services needed to support the network/web based applications becoming so commonplace at each of our institutions

  • Significant planning is needed to do it right

  • Resources are available to help

  • Use the available resources


That s it

That’s IT

David Henry

OIT

University of Maryland