Shibboleth Identity Provider V3 Deployment Considerations and Key Differences for V2 Deployers

Configuration in V3 involves smaller files divided by topics, use of Velocity templates for interfaces, and separate read-only system files for safe upgrades. The V2 to V3 upgrade brings changes in XML files like attribute-resolver.xml and relying-party.xml. Clustering options and quick new features are also discussed.

• Shibboleth
• Identity Provider
• Deployment
• Configuration
• Upgrade

ward_rey Follow

Uploaded on Sep 26, 2024 | 3 Views

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.

Presentation Transcript

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