Shibboleth for Real Dave Kennedy [email protected] .
-
Upload
madeline-mcgee -
Category
Documents
-
view
222 -
download
3
Transcript of Shibboleth for Real Dave Kennedy [email protected] .
Shibboleth for Real
Dave Kennedy
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
Shib project page: http://usmai.umd.edu/auth