Shibboleth for Real

1
Shibboleth for Real

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

2
Environment

• Consortium
• 16 institutions
• Services
• Ex Libris Metalib, Aleph, SFX, Digitool
• EZproxy
• ILLiad
• DSpace, Fedora, etc.

3
What is the problem?

• Multiple logins for multiple services
• Need to secure flow of data for multiple logins
  for different applications
• Username/password embedded in URLs to give
  appearance of single sign on

4
Why Shibboleth?

• Other considered solutions PDS, CAS, Pubcookie
• Shibboleth
• Single sign on
• 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

5
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

6
Shib architecture
7
Investigation

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

8
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

9
IdP Implementation

• Multiple institutions in one installation
• Multiple configurations for attributes and trust
  settings
• Multiple ldap settings in WebISO for user
  verification

10
Multiple Identity Providers Virtually Separate

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

11
PDS

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

12
Role of PDS in Shib Environment

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

13
PDS as WAYF

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

14
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

15
Shib SP configuration

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

16
Logout

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

17
Before
18
After
19
Project Details

• Began investigation March 2005
• 1 staff member
• 16 IdPs, 3 SPs into production, April 2006
• 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
• Consortia 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
Whats next?

• We are rolling out more service providers
• ILLiad going into production within the month
• Aleph to be shib service provider by years end
• Online resources
• Consortial members implementing their own
  identity providers

22

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