Page tree
Skip to end of metadata
Go to start of metadata

Supported Platforms and Versions

Deployers should be aware of the following platform/version requirements for V3:

  • Oracle Java or OpenJDK versions 8, and 11 are supported. Note that Oracle's JDK is no longer free for production use.
  • Per the note below, we are in the process of assessing the OpenJDK options available and expect to make some explicit statements about which sources of OpenJDK will be officially tested and supported by the project. This may not include Oracle at all, but this decision has not yet been made.
  • The Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files are required, but are installed by default pretty much everywhere now, so this is just more of a legacy note.
  • A servlet container implementing Servlet API 3.0 is required. For example:
    • Tomcat 7 or later (but we strongly recommend 8, we have at least one open bug indicating there may be problems using 7)
    • Jetty 8 or later
  • Only Tomcat 8+ and Jetty 9.2+ are officially supported by the project at this time. While older versions of Tomcat and Jetty are nominally suitable (see above), neither has 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.
  • 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.2 is recommended for Java 7 use, Jetty 9.3 is recommended for Java 8, and Jetty 9.4 is recommended for Java 11.
  • There are no specific requirements (yet) regarding Operating Systems, but Linux, OS X and Windows are recommended. Because of the fluid situation with Java, we expect to have to make some more explicit decisions about this because alternate sources of Java on some platforms won't be subject to testing.


Oracle vs OpenJDK

We historically recommended the use of Oracle's "standard" JVM on all platforms. The older "pre-Java 8" OpenJDK implementations that shipped with many Linux distributions were used by many deployers, but the community has off and on reported various problems that have frequently been traced to the use of those versions, including memory leaks.

There are now several credible sources for OpenJDK builds that are closely or identically based on the official OpenJDK "update" source trees. With Oracle Java now officially no longer a free product, we will make more explicit recommendations regarding which versions of OpenJDK we will officially support. While support for Oracle Java is not precluded if we experience demand for it from Consortium Members, we do not expect there to be much demand for that at the present time.

Unusable Platforms and Versions

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

  • Java version 6 or earlier.
  • Java without the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files.
  • Tomcat 6 or earlier. Note that RHEL 5's system-supplied Tomcat is Tomcat 5 and RHEL 6's system-supplied Tomcat is Tomcat 6. Deploying IdP V3 on these systems therefore requires the installation of an alternative application container or the use of RHEL 7, which supplies Tomcat 7 (but note the recommendation at the top to stick with Tomcat 8).
  • Jetty 7 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 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 V3.4 and above 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.

V3.4 and Above

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.

V3.3 and Earlier

At minimum, you will need to change or remove the "SecurityManager" implementation specified in system/conf/global-system.xml and you will be forced to take responsibility for the result of that change, which could introduce vulnerabilities (typically denial of service vectors) into the software.

An alternative custom SecurityManager class, if one exists, can be established via the idp.xml.securityManager property.

  • No labels