Shibboleth Authentication and Single Sign On at USMAI

1
Shibboleth Authentication and Single Sign On at
USMAI

• Jean Phillips
• jeanp_at_umd.edu
• David Kennedy
• davekenn_at_umd.edu
• http//usmai.umd.edu/auth

ELUNA 2006, June 4-7, 2006 Knoxville, Tennessee
2
USMAI Institutions
USMAI
3
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)

4
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)
• Digital Libraries (Digitool and Fedora)

5
What is the problem?

• Separate login process for each service
• IT Management secure flow of data for each login
  process overhead for each process
• User multiple logins
• Different login credentials library barcode,
  NetID, UID

6
Goals

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

7
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

8
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

9
Shib architecture
10
Our Shib Project - Investigation

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

11
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

12
IdP Implementation

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

13
Multiple Identity Providers Virtually Separate

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

14
EZproxy

• Host EZproxy instances for 14 institutions
• Now shib-enabled
• Access to online resources by user attributes
• Ex. limiting access to a medical database to
  subset of campus community, pharmacy preceptors

15
Metalib/PDS

• Patron Directory Service
• Single Sign On between Ex Libris applications
• AuthN and AuthZ

16
Role of PDS in Shib Environment

• PDS plays dual role of WAYF and SP
• AuthN
• AuthZ at the application level (Metalib, in our
  case)

17
PDS as WAYF

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

18
PDS as SP

• Each URL protected by different institutions
  Identity Provider
• IdP handles authentication and attribute
  assertion
• SP receives attributes back from IdP and
  establishes PDS session

19
Shib SP configuration

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

20
Shibboleth.xml
21
PDS Configuration
22
Logout

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

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

24
Before
25
After
26
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

27
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

28
Benefits

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

29
Whats next?

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

30
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

31

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