1 / 22

Shibboleth for Real

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

edwardjohnson
Download Presentation

Shibboleth for Real

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Shibboleth for Real Dave Kennedy davekenn@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 institution’s 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. 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

  22. Dave Kennedy davekenn@umd.edu Shib project page: http://usmai.umd.edu/auth

More Related