Shibboleth v4 Upgrade Path Recommendations

The Shibboleth v4 Release Notes recommend an in-place upgrade over the existing v3 installation. The Australian Access Federation strongly recommends against this approach and instead recommends deploying new parallel infrastructure for customers continuing to maintain their own identity provider software.

 

The AAF recommends new infrastructure for the following reasons:

  • the new v4 AAF Installer will NOT work over the top of an existing v3 installation. An in-place upgrade with the AAF Installer will not be possible. The v4 AAF Installer will use different approaches that make it incompatible with previous versions (eg. Apache will no longer be used).
  • new infrastructure reduces risks to the organisation by maintaining the current working environment.
    • New infrastructure allows testing to be conducted before full deployment
    • New infrastructure reduces pressure on the upgrade team since cutover and rollback are reduced to a simple DNS change
  • new infrastructure provides the opportunity to update the operating system to RHEL / CentOS 8 to maintain security and supportability and reduce the prospect of emergency operating system upgrades in the future
  • new infrastructure enables clean installations of Java 11 and Jetty 9.4 that Shibboleth requires
  • An in place upgrade will preserve the version 3 configuration and script formats. A fresh install will begin using the new Attribute Registry format. While migrating attribute resolvers and scripts to the new format will be more work in the short-term, it will make future identity provider upgrades simpler.

 

Recommended process:

  1. Build a new RHEL or CentOS 8 server.
  2. Use the AAF Shibboleth V4 Installer (expected release Q4 2020) to install a new Shibboleth v4 instance and set the base AAF configuration.
  3. Manually migrate configuration (attribute resolver, scripts, site-specific bilateral connections etc) to the new server updating to the new format as you go.
  4. Manually migrate database content to the new server.
  5. Test and deploy the new server to production.