1. Shibboleth Identity Provider V3 Deployment Considerations Scott Cantor (tOSU) Walter Hoehn (U Memphis) David Langenberg (U Chicago)

2. KEY DIFFERENCES FOR V2 DEPLOYERS

3. Configuration More/smaller configuration files divided by topics and types Properties for big/global changes XML files for main configuration as before Velocity templates for user interfaces (JSP optional) Message files for internationalized text System files are separate, read-only, and provided only for reference to ensure safe upgrades 3

4. Configuration attribute-resolver.xml Basic scripts work under Java 7 or if adapted to Java 8, but complex scripts that access V2 APIs will likely need adjustments No other significant changes attribute-filter.xml No significant changes, but XML simplifications will be available with V3.2.0 relying-party.xml Legacy support or the more powerful native format are available metadata-providers.xml Separate file for metadata sources with streamlined options saml-nameid.xml New file for configuring SAML Subject identifiers for accomodating deficient SP software 4

5. Clustering Ding-dong, Terracotta's dead Clustering Options client-side cookies (+ HTML Storage in V3.2.0) in-memory JPA / database memcache All options assuming per-request stickiness from a load balancer, no realistic chance of this changing 5

6. Quick New Feature Blitz Built-in attribute release consent Built-in CAS protocol support Advanced support for controlling configuration settings based on arbitrary conditions Help with migration to stronger security algorithms IdP-driven authorization (the Google bug) Safe and reliable upgrade process 6

7. V2 UPGRADE CONSIDERATIONS

8. Basics The easy: Filter policies just work Legacy relying-party files just work Most attribute resolver files just work Use of V2 “in the box” authentication options is very easy to transfer across The less easy: Login UI is some work to re-customize Adapting, converting, or waiting for older add-ons 8

9. Upgrade or New Install? Upgrade in-place if you: Don’t need any new features initially Want a faster upgrade process Transfer settings manually if you: Need newer features as part of your deployment Have the time to move settings over deliberately and test them If you do want to reuse your old relying-party file, start with an in-place upgrade. 9