Supported Platforms and Versions

The following Java distributions are fully supported:

  • Amazon Corretto 17 for Linux

  • Amazon Corretto 17 for Windows

  • Red Hat's OpenJDK 17 for Linux as supplied under Red Hat Enterprise Linux (or compatible rebuild):

    • Note that this specifically refers to actual Java 17, and not “latest”. Some older versions of these OS’s include “floating” versions but not a specifically supported package for Java 17.

The following distributions are partially supported:

  • Debian's OpenJDK 17 as supplied under Debian 11 and 12.

Other Java distributions that are substantially identical or meant to be fully compatible with OpenJDK 17 are of course likely to work, but are officially regarded as unsupported to limit the range of environments we need to be able to reproduce problems under to a manageable set.

Other platform/version requirements

  • A servlet container implementing Servlet API 5.0 or above is required. For example:

    • Jetty 11+

    • Tomcat 10.1+

  • We also do not officially support any "packaged" containers provided by OS vendors. We do not test on these containers so we cannot assess what changes may have been made by the packaging process, and they frequently contain unwarranted and ill-considered changes from the upstream software.

  • The recommended container implementation is Jetty and all development and most testing time by the core project team is confined to the Jetty platform. At present, Jetty 11 or 12 are recommended.

  • There are no specific requirements regarding Operating Systems, but in practice this is inherently limited by the Java distributions supported, as noted above.

Unusable Platforms and Versions

The following common configurations, and versions often in use with prior IdP versions, are specifically NOT usable:

  • Java version 16 or earlier

  • Jetty 10 or earlier

  • Tomcat 9.5 or earlier

User Agent Assumptions

There are no specific requirements regarding Browsers, but we test on only relatively recent, mainstream software, and certain features like HTML Local Storage assume standards-compliant software.

The HTML-based user interfaces make relatively minimal use of Javascript with the exception of the Duo and logout features, which include a dependency on JQuery (a version of which is included with the software).

The IdP requires the use of first-party cookies and is not designed to function without them.

The IdP does not require third-party cookies to be enabled (except for single logout functionality) and does not support the embedding of the supported user interfaces in frames hosted by a third party. While this may work, it is not guaranteed to work, and we ship with a configuration that explicitly blocks the use of frames via response headers. The blocking behavior is configurable and can be disabled, though this is not recommended for newer deployments.

Alternative JAXP Implementations

While we support only the Oracle and OpenJDK Java implementations and the JAXP XML Parser implementation included with them, it is possible in principle to use alternatives. They will not in general be likely to work out of the box (or at least not safely) because our default configuration includes settings to secure the XML parser that are built into the Java reference implementation. We strongly recommend against use of an alternative parser, but there are hooks built into the software to allow for it.

An alternative XML parser configuration can be established by defining a custom bean of type ParserPool, and providing its name via the idp.xml.parserPool property. This is typically done through reuse of the BasicParserPool class by copying the system-provided bean (see shibboleth.DefaultParserPool in this system file) into a new bean in conf/global.xml and adjusting the default attributes and features to match the JAXP implementation in use. Any appropriate security measures and protections required are the deployer's responsibility, and there is no guarantee of interoperability.