1. Shibboleth Identity Provider Version 3
Scott Cantor
The Ohio State
University

2. A Bit of History Version 1 – 2003 – 2008 Version 2 – 2008 – 2015
SAML 1, inventing a lot of concepts on the fly
Version 2 – 2008 – 2015
SAML 2, harmonizing two protocols
Version 3 – ?
Focus on design, deployability, and sustainability over features

3. Why Upgrade? Compelling reasons for you Compelling reasons for us
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

4. 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
Velocity views generally live in idp.home/views
Message properties are in idp.home/messages; to internationalize, add a translation file such as authn-messages_fr.properties (in French for example)

5. 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.

6. 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

7. 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
(very incomplete so far)

8. 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

9. 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

10. 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

11. 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