1 / 25

Shibboleth at USMAI

Explore how the USMAI Consortium of Libraries implemented Shibboleth for single sign-on and attribute sharing across multiple institutions, improving user experience and streamlining access to online resources.

teresawalker
Download Presentation

Shibboleth at USMAI

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. Shibboleth at USMAI David Kennedy davekenn@umd.edu http://usmai.umd.edu/auth Spring 2006 Internet2 Member Meeting, April 24-26, 2006 – Arlington, VA

  2. USMAI Consortium of Libraries Univ. System of Maryland and Affiliated Institutions http://usmai.umd.edu/ • 16 Libraries from the 12 campuses of the USM & 2 affiliated Maryland higher ed institutions • Began in 1982 with a subset of these institutions • Over 7,000,000 items in catalog • Approximately 200,000 patrons • Built on a resource sharing model • Hosted at the University of Maryland • Governed by the Council of Library Directors (CLD)

  3. USMAI Consortium of Libraries • Shared IT products and services, e.g.: • Systems Administration, Development, & Help Desk • E-Resource licensing & procurement • Consortium-wide ID management (patron database) • Library Information Management System (Aleph) • OpenURL resolver (SFX) • E-Resource Portal (MetaLib) • Proxy services (EZproxy) • ILL (ILLiad) • Institutional Repository (DSpace) • E-Resource Management (Verde)

  4. What is the problem? • Separate login process for each service • IT Management: secure flow of data for each login process • User: multiple logins • Different login credentials; library barcode, NetID, UID…

  5. Why Shibboleth? • Other SSO solutions: PDS, CAS, Pubcookie • Shibboleth • Secure handling of user attributes • Flexibility to use different AuthZ criteria per service • Designed to function across domains • Ability to authenticate for different vendors’ products

  6. Shib architecture • Shibboleth – an architecture for handling authentication and attribute assertion in a secure and controlled manner • Service Provider (SP) – resource • Identity Provider (IdP) – AuthN source • WAYF – Where Are You From • WebISO – Web Initial Sign On

  7. Shib architecture

  8. Investigation • Installed generic single institution IdP • Installed generic service provider (script that prints out attributes) • Proof of concept

  9. Implementation • Chose EZproxy and Ex Libris’ Metalib/PDS as initial SPs • EZproxy was already shibboleth-enabled, so easily configured • Had to implement multiple identity providers for institutions in the consortium

  10. IdP Implementation • Multiple identity providers, hosted centrally • IdP designed for single institution • Different IdP configurations per institution • Modified WebISO – different directory per institution

  11. Multiple Identity Providers – Virtually Separate • Totally separate identity providers as far as service providers are concerned • Unique access points • Separate trust relationships

  12. EZproxy • Host EZproxy instances for 14 institutions • Now shib-enabled • Access to online resources by user attributes

  13. Metalib/PDS • Patron Directory Service • Single Sign On between Ex Libris applications • AuthN and AuthZ

  14. Role of PDS in Shib Environment • Dual role of WAYF and SP • AuthN • AuthZ at the application level (Metalib, in our case)

  15. PDS as WAYF • PDS to present list of institutions (WAYF) • Choice of institutions redirects to an institution specific URL within PDS

  16. PDS as SP • Each URL protected by different institution’s Identity Provider • IdP handles authentication and attribute assertion • SP receives attributes back from IdP and establishes PDS session

  17. Shib SP configuration • Shibboleth.xml – settings for SP • Multiple applications defined, each with a different Identity Provider • RequestMap defined – map URLs to shib applications

  18. Logout • No logout provided in shibboleth architecture • Created a logout for identity provider, with an optional redirect back to service provider

  19. ILLiad • InterLibrary Loan software, Atlas Systems • Consortial implementation – 8 institutions • ILLiad is now shib-aware, SSO • Future – ILLiad development to take advantage of other shib attributes to facilitate user registration (v 7.2?)

  20. Before

  21. After

  22. Project Details • Began investigation – March 2005 • 1 staff member • 16 IdPs, 3 SPs into production, April 2006 • 3,000 - 6,000 logins per day • Hardware: • Test – Sun Fire V480, 2x900MHz UltraSparc III, 8GB RAM (shared server) • Production – Sun Fire V880, 4x900MHz UltraSparc III+, 16GB RAM (shared server) • Documentation

  23. Challenges • Technical • Consortium – virtually separate identity providers • Logout • LDAP – hook into our ldap, single ldap for all institutions, only use institution specific attributes • Learning curve, needed concentrated chunks of staff time • Making shibboleth a priority

  24. What’s next? • Persistent Identifiers • We are rolling out more service providers • Aleph as SP by year end • Online resources, content providers • Working within consortium • Library IdP using patron database • Library IdP using campus directory • Campus IdP using library service providers

  25. David Kennedy davekenn@umd.edu Shib project page: http://usmai.umd.edu/auth

More Related