Details

Supported Platforms and Versions

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

• Oracle Java or OpenJDK versions 7 and 8 are supported, and the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files are required. While the JRE may work, only the JDK is officially supported.
• 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 - Jetty 9.3 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 and Jetty 9.3 is recommended for Java 8.
• There are no specific requirements regarding Operating Systems, but Linux, OS X and Windows are recommended.

Red Hat/CentOS Users, Stop!

Some older versions of Red Hat Enterprise Linux and CentOS ship with the GNU Java compiler and VM (gcj) by default. These are not usable with Shibboleth so you must install another JVM.

OpenJDK Warning

We strongly recommend the use of Oracle's "standard" JVM on all platforms. The OpenJDK implementation that ships with many Linux distributions is used by many deployers, but the community has off and on reported various problems that have frequently been traced to the use of OpenJDK, including memory leaks. You should expect that reports of unexplained problems may be met with a request to reproduce them on Oracle's JVM.

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.

Alternative Java Implementations

While we support only the Oracle and OpenJDK Java implementations, it is possible in principle to use alternatives, but they will not in general be likely to work out of the box because the default configuration includes settings to secure the XML parser that is built into the Java reference implementation. At minimum, you will need to change or remove the "SecurityManager" implementation specified in system/conf/global.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 SecurityManager class, if one exists, can be established by setting a idp.xml.securityManager property in conf/idp.properties or as a system property.

Outcomes:

If all prerequisite software is compatible, the instillation of AAF IDP/SP software should work without any major issues notwithstanding unforseen errors or issues which is outside the control of the Australian Access Federation. Every consideration is taken when developing specialist software for third party providers and subsequent support is always provided for versions which are current. If you find your software out of date or no longer supported, the AAF support staff will endeavour to assist as much as possible in all circumstances.

Links

Not sure which other links would be needed or required in this instance... maybe some guides to setting up IDP's and SP'S??

What are the minimal set of capabilities that an IdP needs to support to be able to fully participate in the AAF?