Date: Fri, 29 Mar 2024 06:35:21 +0000 (UTC) Message-ID: <1774786942.1.1711694121385@170d30bec080> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_0_1523539871.1711694121372" ------=_Part_0_1523539871.1711694121372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The following Java distributions are fully = supported:
Amazon Corretto 11 for Linux
Amazon Corretto 11 for Windows
Amazon Corretto 17 for Linux
Amazon Corretto 17 for Windows
Red Hat's OpenJDK 11 for Linux as supplied under Red Hat Enterprise Linu= x and CentOS 7 and 8
The following distributions are partia= lly 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 off= icially regarded as unsupported to limit the range of environments we need = to be able to reproduce problems under to a manageable set.
Java 17 Note
Use of Java 17 or above require the use of V4.2+ of the IdP. Additionall= y, note that use of Javascript in your own configurations requires the inst= allation of a Javascript engine plugin<= /a> due to the removal of Javascript from Java itself.
A servlet container implementing Servlet API 3.1 is required, but Servle= t API 5.0 (or greater) are NOT supported. For example:
Jetty 9.4, 10, 12 (but not Jetty 11)
Tomcat 9 (but not 10.x) (while some older versions of Tomcat are nominal= ly 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 cha= nges may have been made by the packaging process, and they frequently conta= in unwarranted and ill-considered changes from the upstream software.
= li>The recommended container implementation is Jetty and a= ll development and most testing time by the core project team is confined t= o the Jetty platform. At present, Jetty 10 or 12+ are recommended.
There are no specific requirements regarding Operating Systems, but in p= ractice this is inherently limited by the Java distributions supported, as = noted above.
The following common configurations, and versions often in use with prio= r IdP versions, are specifically NOT usable:
Java version 10 or earlier
Jetty 9.3 or earlier
Jetty 11 (11 is part of a =E2=80=9Cnew=E2=80=9D API stream supporting th= e incompatible new Jakarta EE specification, which will be supported and in= fact required by IdP V5.0 when it is available). Jetty 10 is the equivalen= t to 11 while maintaining support for the old Java EE API. Jetty 12 support= s both APIs.
Tomcat 7 or earlier
Tomcat 10.x (per the Jetty 11 comment above, this is the Tomcat branch s= upporting only Jakarta EE)
There are no specific requirements regarding Browsers, but we test on on= ly relatively recent, mainstream software, and certain features like HTML L= ocal 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 depende= ncy 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 f= unction without them.
The IdP does not require third-party cookies to be enab= led and does not support the embedding of the support= ed 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 explici= tly 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.
While we support only the Oracle and OpenJDK Java implementations and th= e JAXP XML Parser implementation included with them, it is possible in prin= ciple to use alternatives. They will not in general be likely to work out o= f the box (or at least not safely) because our default configuration includ= es 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