Shibboleth Identity Provider Version 3: A Comprehensive Overview
Exploring the evolution and benefits of Shibboleth Identity Provider Version 3, including its historical background, reasons for upgrading, user interface leveraging, error handling, and clustering capabilities. Discover the compelling reasons for upgrading, practical considerations, and features enhancing user experience and system performance.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Shibboleth Identity Provider Version 3 Scott Cantor The Ohio State University
A Bit of History Version 1 2003 2008 SAML 1, inventing a lot of concepts on the fly Version 2 2008 2015 SAML 2, harmonizing two protocols Version 3 2015 - ? Focus on design, deployability, and sustainability over features 2
Why Upgrade? Compelling reasons for you Easier UI and login customization, error handling, simpler clustering, attribute release consent, easier handling of vendor quirks, much improved update process, CAS protocol support Compelling reasons for us Up to date library stack, much easier to deliver future enhancements, V2 maintenance is a drain on limited resources A practical reason V2 maintenance ends July 2016; you don't have to upgrade, but you can't stay here 3
User Interface Leverages "views" from Spring Web Flow Views can be Velocity templates, JSP pages, potentially others Most views are Velocity by default so they can be modified on the fly, including example login/logout/error templates Spring message properties Reusable macros across views (e.g., logo paths, titles, organization names, etc.) Can be internationalized to a browser's primary language 4
Error Handling WebFlow is event-driven, so most errors are "events", e.g., "MessageReplay" Events can be classified by you as Local or non-Local, local meaning "don't issue a response back to requester" Error view(s) under your control, an example view is provided using message properties to map events into different error content You can reuse example, roll your own, map events to different views, etc. 5
Clustering Ding-dong, Terracotta's dead With one exception, all short/long-term persistent state relies on a StorageService API in-memory cookie (*) JPA / database memcache Web Storage (work in progress) Defaults allow zero-effort clustering with most critical features supported 6
Consent New feature: interceptor flows Security/policy checks run this way invisibly Also have post-authentication hook for running flows after user identified, several built-in examples uApprove-style attribute release consent and terms of use flows (former is on by default on new installs), has an enhanced mode of approving each attribute individually Context-checking flow that can halt processing if expected conditions aren t met, such as attributes or specific values available 7
Vendor Quirks Common use cases for integrating vendor SAML implementations are easier and less invasive Security settings like digest algorithms can finally be overridden per-SP or group of SPs Assertion Encryption can be made optional so it turns on whenever possible and off when not (based on metadata) Setting up custom NameID formats in a dedicated place Attaching custom SAML encoder rules to attribute definitions and limiting them to specific SPs 8
Safe Upgrades Simpler, safer, robust upgrade process: Review release notes Stop service Unpack, install over top Rebuild warfile to add back local changes Start service Clearly delineated system and user config files Local warfile overlay to prevent losing webapp changes or additions On Windows, Jetty can be installed and managed for you in simple deployments, Unix TBD 9
CAS Protocol Major technical goal for redesign was to facilitate non-SAML / non-XML protocol integration CAS was a natural candidate to work on and help prove out the design Second phase of work will be integration of CAS features with SAML metadata to unify management/approach OpenID, if done, likely to follow a similar evolution 10
Work in Progress Delivery of V3.2.0 expected late summer HTML5 Local Storage support for sessions / consent Enhancements for complex authentication extensions SAML delegation support Lots of other fixes and improvements based on feedback 11
