1 / 28

Directories are Fundamental

Directories are Fundamental. Keith Hazelton, Senior IT Architect University of Wisconsin-Madison. Directories are Fundamental: Outline. Sketch: A minimal, idealized enterprise directory What its features will buy you Divergences from the ideal that will cost you Policy matters

Download Presentation

Directories are Fundamental

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Directories are Fundamental Keith Hazelton, Senior IT Architect University of Wisconsin-Madison

  2. Directories are Fundamental: Outline • Sketch: A minimal, idealized enterprise directory • What its features will buy you • Divergences from the ideal that will cost you • Policy matters • A dip into directory internals • Working with applications and with other directories

  3. A minimal, idealized enterprise directory—Start from scratch HR Stdnt Sys Faculty and staff Students Services we want to provide to people as members or affiliates of the community

  4. A minimal, idealized enterprise directory—Start from scratch HR Stdnt Sys Faculty and staff Students Sys-specific data => Institutional information Identity management Registry Services we want to provide to people as members or affiliates of the community

  5. A minimal, idealized enterprise directory—Start from scratch HR Stdnt Sys Faculty and staff Students Sys-specific data => Institutional information Identity management Registry LDAP server Directory Services we want to provide to people as members or affiliates of the community

  6. A minimal, idealized enterprise directory—Start from scratch HR Stdnt Sys Faculty and staff Students Enterprise Directory Sys-specific data => Institutional information Identity management Registry LDAP server Directory Services we want to provide to people as members or affiliates of the community

  7. A minimal, idealized enterprise directory—Start from scratch HR Stdnt Sys Other populations Faculty and staff Students Enterprise Directory Sys-specific data => Institutional information Identity management Registry LDAP server Directory Services we want to provide to people as members or affiliates of the community

  8. A minimal, idealized enterprise directory—Challenges • If people enter the population by more than one path, Identity management required • Informational basis for same/not same person judgment • Processes to manage exceptions • An attractive alternative: A single shared Registration Authority service • Anyone have such a thing in operation?

  9. A minimal, idealized enterprise directory—Contents • Basic demographic data • Contact information • Affiliation/role attributes • Person’s identifiers in associated systems

  10. What its features will buy you • The Enterprise Directory supports operations over the whole population • Single authentication namespace (“NetID”) • Data walkabouts • Application specific directories can stay specific by linking rather than synching • Provisioning

  11. What its features will buy you • Business Case for Dir plus Security Middleware • See Early Harvest work for full document • Reduced number of credentials • Shorter waiting period for service activation • Shorter delay between revocation of privilege and loss of service • Reduced overhead to deploy & maintain services • Better audit and accountability • Lower profile of credentials (less risk of compromise)

  12. Divergences from the ideal that will cost you • Unconnected systems • Back on their own for population & access management • Unconnected populations • Invisible to the middleware and integrated applications • Isolated attributes • Not available for access control decisions or other purposes

  13. Policy matters • You won’t get data into or out of the enterprise directory without navigating some tricky policy waters • No adequate standards for vendors to implement for access control over directory content • So we must fall back on sharing best practices

  14. A dip into directory internals—the LDAP Recipe “A Recipe for Configuring and Operating LDAP Directories” • Michael Gettes, Georgetown University • Directory Information Tree, Schema,Bindings… • LDAP filter configuration for white pages • …and much more

  15. A dip into directory internals—the Directory Information Tree dc=edu dc=wisc Dir. Info. Tree (DIT) ou=people ou=groups uid = foo cn = Mike Smith givenName = Michael surname = Smith cn = Letters & Science History Dept {member: uid=foo, ou=people, dc=wisc, dc=edu member:… …}

  16. A dip into directory internals—Schema • eduObjects: People, Organizations, Services, Resources,… • Widely implemented common attributes • Extensible object classes (your attr.here) • Lower impedance in application access to info • No need to invest in your own wheel factory

  17. A dip into directory internals—Schema • eduPerson 1.0 • Agreement on higher education community use of commonly provided attributes • From the person object class: sn (surname): “If the person has a multi-part surname (whether hyphenated or not), store each component as a separate value in this multi-valued attribute. That yields the best results for the broadest range of clients doing name searches.”

  18. A dip into directory internals—Schema • eduPerson 1.0 • Six attributes newly defined primarily for inter-institutional uses • eduPersonAffiliation • faculty, student, staff, alum, member, affiliate, employee • "member" is intended to include faculty, staff, student, and other persons with a basic set of privileges that go with membership in the university community (e.g., library privileges). It could be glossed as "member in good standing of the university community."

  19. A dip into directory internals—Schema • eduPerson 1.0 • eduPersonPrincipalName (ePPN) • Of form userid@securitydomain • For access control lists (.htaccess) • For shibboleth inter-realm authentication • Primary requirement: globally unique names • Sites must publish reassignment rules

  20. A dip into directory internals—Schema • eduPerson 1.5 • Additional attributes needed for Shibboleth and other access control purposes • eduPersonEntitlement • Simple case: value is the name of a contract for licensed resource • URIs (URNs or URLs) to allow federation of name creation without name clashes. • http://xstor.com/contract1234

  21. A dip into directory internals—Schema • eduPerson 1.5 • eduPersonExtension: A playground attribute • URNs to allow federation of name creation without name clashes. • urn:mace:brown.edu:foo • mace-submit@internet2.edu for information on URN registration

  22. A dip into directory internals—Schema • eduOrg 1.0 in progress • Basic organizational info attributes from X.520 • Telecomm, postal, locale • eduOrgBluePage • Multi-valued, labeled URI syntax • Standardized labels for key organizational offices, e.g.: • eduOrgBluePage = http://bussvc.wisc.edu Business Services • eduOrgBluePage = http://dev.washington.edu Development Office • eduOrgBluePage = http://www.uchicago.edu/sec_pol IT Security Policies

  23. CDS Working with applications and with other directories—DoDHE Submit final LDIF to CDS using authenticated POST via HTTPS. Local Data Source LDAP Filter LDIF according to local policy. Generate new LDIF for submission. DODHE Generate LDIF Data

  24. Working with applications and with other directories—DoDHE CDS dc=edu dc=georgetown dc=memphis dc=virginia dc=washington dn: uid=gettes,ou=People,dc=georgetown,dc=edu objectclass: {person, organizationalPerson, inetOrgPerson, eduPerson} cn: Michael Gettes sn: Gettes mail: gettes@georgetown.edu displayName: Michael R Gettes eduPersonPrimaryAffiliation: Employee eduPersonAffiliation: Employee … Generate LDIF Data

  25. Working with applications and with other directories—DoDConfig Directory dc=edu dc=georgetown dc=memphis dc=virginia dc=washington dn: dc=georgetown,dc=edu objectclass: {organizationalUnit, domain, referral, DoDEntry } cn: Georgetown University ref: ldap://directory.georgetown.edu/dc=georgetown,dc=edu dodRefSearch: ldap://cds1.dodhe.internet2.edu/dc=georgetown,dc=edu dodCarnegieClass: Research-1 uid: georgetown.edu

  26. Working with applications and with other directories • Shibboleth Project • Authenticate locally, access resources globally • Secure sharing of authorization information between home institution and target site • Need to front the directory with an Attribute Authority (where policy happens) • eduOrganization information essential

  27. Working with applications and with other directories • Recent NSF Middleware Initiative (NMI) award enabling an expansion of directory work • Groups in directories (draft just released) • VidMid Video Conferencing • Metadirectory practices • Affiliated directories scenarios • More on some of these work areas tomorrow

  28. Conclusion • The root URL for all these topics: • http://middleware.internet2.edu

More Related