Shibboleth at USMAI

1
Shibboleth at USMAI

• David Kennedy
• davekenn_at_umd.edu
• http//usmai.umd.edu/auth

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)
• 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
Goals

• Short term
• SSO amongst library hosted services
• SSO with content providers
• Long term
• Interoperability with campus authentication, SSO,
  portal, etc

6
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

7
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

8
Shib architecture
9
Our Shib project - Investigation

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

10
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

11
IdP Implementation

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

12
Multiple Identity Providers Virtually Separate

• Totally separate identity providers as far as
  service providers are concerned
• Unique access points
• Separate trust relationships

13
EZproxy

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

14
Metalib/PDS

• Patron Directory Service
• Single Sign On between Ex Libris applications
• AuthN and AuthZ
• Dual Role of PDS as WAYF and SP

15
Logout

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

16
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?)

17
Before
18
After
19
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

20
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

21
Benefits

• Persistent Identifiers
• Security/Privacy
• Low overhead for new services
• Framework established for integration with campus
  SSO

22
Whats next?

• We are rolling out more service providers
• Aleph as SP by year end
• Online resources, content providers
• Working within consortium

23
Consortial Models

• Library hosts IdP with Aleph patron database as
  directory
• Library hosts IdP with campus LDAP as directory
• Campus hosts IdP with campus LDAP as directory

24
(No Transcript)
25

• David Kennedy
• davekenn_at_umd.edu
• Shib project page http//usmai.umd.edu/auth