...
If you are upgrading from a pre-V5 release, you must upgrade to the latest V4 release first and remove deprecation warnings. Note that some of these warnings may only be visible in your servlet container’s log. This is due to the order of operations; the IdP’s logging service cannot be started until the global Spring context is running, and some of the configuration triggering warnings may be in that root context.
There is one set of warnings that are an exception to this: the undocumented “SAML2NameID” and “SAML1NameID” attribute encoders produce warnings indicating they were removed from the next major version, but in fact :
Code Block DEPRECATED xsi:type 'SAML2NameID', (file [/opt/shibboleth-idp/conf/attribute-resolver.xml]): This will be removed in the next major version of this software; replacement is (none)In fact they were not, and their use (while still unsupported and undocumented) will produce a less aggressive “at risk” warning going forward. There are no explicit plans to remove them, but their use is incompatible with the vast majority of SAML software and should not be used in new deployments.
You must ensure that your versions of Java and servlet container meet the system requirements for V5. This is more complex than usual because there are relatively few servlet containers right now that support both Java and Jakarta Servlet specifications, and V4 requires the former while V5 requires the latter. At a minimum, it’s a good idea to upgrade a V4 system to Java 17 first, likely also installing one of our scripting engine plugins (Nashorn or Rhino).
If using Jetty it should be possible to use essentially the same configuration between Jetty 10 and 11, so if using Jetty 9 you should definitely migrate a V4 system to Jetty 10 before the V5 upgrade, at least in development/testing.
Note that the jetty installed by the V4 windows installer is Jetty 10.x.Finally, remove the system directory before upgrading (the installer will block on this issue). In V4, this directory was used for compatibility with older systems that had overridden the web.xml file, but we are removing this stopgap. In the event your V4 IdP fails to start with the system directory removed, you will need to either remove your overriden copy of web.xml, or at least freshen it by updating the very top of the file and correct the contextConfigLocation context parameter:
Code Block language xml <!-- Spring application context files. Files are loaded in the order they appear with subsequent files overwriting same named beans in previous files. --> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath*:/META-INF/net.shibboleth.idp/preconfig.xml,classpath:/net/shibboleth/idp/conf/global-system.xml,classpath*:/META-INF/net.shibboleth.idp/postconfig.xml</param-value> </context-param>
...