enterprise directory service at college park
Download
Skip this Video
Download Presentation
Enterprise Directory Service at College Park

Loading in 2 Seconds...

play fullscreen
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 [email protected] 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

[email protected]

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 ([email protected])
  • 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

ad