Shibboleth for Real Dave Kennedy

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 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 Shib project page: