Deployers should be aware of the following platform/version requirements for V3:
The following common configurations, and versions often in use with prior IdP versions, are specifically NOT usable with V3:
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 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.
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 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.
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.