Shibboleth at USMAI David Kennedy

Download Report

Transcript Shibboleth at USMAI David Kennedy

Shibboleth at USMAI
David Kennedy
[email protected]
http://usmai.umd.edu/auth
Spring 2006 Internet2 Member Meeting, April 24-26, 2006 – Arlington, VA
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)
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)
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…
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
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 identity providers, hosted centrally
IdP designed for single institution
Different IdP configurations per institution
Modified WebISO – different directory per
institution
Multiple Identity Providers –
Virtually Separate
• Totally separate identity providers as far as
service providers are concerned
• Unique access points
• Separate trust relationships
EZproxy
• Host EZproxy instances for 14 institutions
• Now shib-enabled
• Access to online resources by user
attributes
Metalib/PDS
• Patron Directory Service
• Single Sign On between Ex Libris
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
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?)
Before
After
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
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
What’s next?
•
•
•
•
•
Persistent Identifiers
We are rolling out more service providers
Aleph as SP by year end
Online resources, content providers
Working within consortium
– Library IdP using patron database
– Library IdP using campus directory
– Campus IdP using library service providers
David Kennedy
[email protected]
Shib project page:
http://usmai.umd.edu/auth