Shibboleth for Real

Dave Kennedy

davekenn@umd.edu

http://usmai.umd.edu/auth

Environment

• Consortium– 16 institutions

• Services– Ex Libris’ Metalib, Aleph, SFX, Digitool– EZproxy– ILLiad– DSpace, Fedora, etc.

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

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

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

Shib architecture

Investigation

• Installed generic single institution IdP

• Installed generic service provider (script that prints out attributes)

• Proof of concept

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

IdP Implementation

• Multiple institutions in one installation

• Multiple configurations for attributes and trust settings

• Multiple ldap settings in WebISO for user verification

Multiple Identity Providers – Virtually Separate

• Totally separate identity providers as far as service providers are concerned

• Unique access points

• Separate trust relationships

PDS

• Patron Directory Service

• Single Sign On between ExLibris applications

• AuthN and AuthZ

Role of PDS in Shib Environment

• Dual role of WAYF and SP

• AuthN

• AuthZ at the application level (Metalib, in our case)

PDS as WAYF

• PDS to present list of institutions (WAYF)

• Choice of institutions redirects to an institution specific URL within PDS

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

Shib SP configuration

• Shibboleth.xml – settings for SP

• Multiple applications defined, each with a different Identity Provider

• RequestMap defined – map URLs to shib applications

Logout

• No logout provided in shibboleth architecture

• Created a logout for identity provider, with an optional redirect back to service provider

Before

After

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

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

What’s next?

• We are rolling out more service providers

• ILLiad going into production within the month

• Aleph to be shib service provider by year’s end

• Online resources

• Consortial members implementing their own identity providers

Dave Kennedy

davekenn@umd.edu

Shib project page: http://usmai.umd.edu/auth