...
The following Java distributions are fully supported:
Amazon Corretto 11 for Linux
Amazon Corretto 11 for Windows
Red Hat's OpenJDK 11 for Linux as supplied under Red Hat Enterprise Linux and CentOS 7 and 8
The following distributions are partially supported:
Debian's OpenJDK 11 as supplied under Debian 10 "buster"
Other Java distributions that are substantially identical or meant to be fully compatible with OpenJDK 11 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 3.1 is required. For example:
Jetty 9.4 or later (but not Jetty 11)
Tomcat 9 or later (while some older versions of Tomcat are nominally suitable, they have not been tested and have been obsoleted in any case)
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 9.4 is 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 10 or earlier
Tomcat 7 or earlier
Jetty 9.3 or earlier
Jetty 11 or later
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.
...
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 in system/conf/global-system.xml 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.