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