Version 4.3.0 contains a number of changes to the configuration model. In case you want to upgrade existing XML configuration, read the paragraph Upgrading the XML Configuration
As with previous releases, the XML configuration can be converted using a provided XSLT and its associated auto-upgrade.sh script. To run the XSLT on a configuration data set, run the auto-upgrade.sh script, like this:
auto-upgrade.sh
$ $INSTALL_DIR/misc/upgrade/4.2-to-4.3/auto-upgrade.sh $IDSVR_HOME/etc/init/some-config.xml
Prior to release 4.3, the only HTTP client related configuration for non-templatized DCR clients was the HTTP client used for sector verification. This configuration was done inside the sector-identifier-http-clients configuration section. Release 4.3 introduces more HTTP usages (e.g. OIDC request object retrieval, JWKS retrieval). Due to that, the configuration model was changed and a new http-client-mappings configuration section was introduced.
4.3
sector-identifier-http-clients
http-client-mappings
To avoid breaking changes, both configuration sections are still used on release 4.3, however:
WARN
There are a few ways to migrate to the new http-client-mappings based model:
Using the following configuration as example, the manual migration process uses the following steps:
sector-identifier-http-client
http-client-mapping
url
sector-identifier
usage
sector-verification
http-client
<profile>`` <id>oauth-dev</id> <type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type> <settings> <authorization-server xmlns="https://curity.se/ns/conf/profile/oauth"> <dynamic-client-registration> (...) <non-templatized> <sector-identifier-http-clients> <sector-identifier-http-client> <sector-identifier>https://example.com/*</sector-identifier> <http-client>standard-http-client</http-client> </sector-identifier-http-client> <sector-identifier-http-client> <sector-identifier>https://example.org/some/path</sector-identifier> <http-client>standard-http-client</http-client> </sector-identifier-http-client> </sector-identifier-http-clients> </non-templatized> </dynamic-client-registration> </authorization-server> </settings> </profile>
The upgraded configuration is shown in the following block.
<profile> <id>oauth-dev</id> <type xmlns:as="https://curity.se/ns/conf/profile/oauth">as:oauth-service</type> <settings> <authorization-server xmlns="https://curity.se/ns/conf/profile/oauth"> <dynamic-client-registration> (...) <non-templatized> <http-client-mappings> <http-client-mapping> <url>https://example.com/*</url> <usage>sector-verification</usage> <http-client>standard-http-client</http-client> </http-client-mapping> <http-client-mapping> <url>https://example.org/some/path</url> <usage>sector-verification</usage> <http-client>standard-http-client</http-client> </http-client-mapping> </http-client-mappings> </non-templatized> </dynamic-client-registration> </authorization-server> </settings> </profile>
An error identifier has been added in the default error templates. The updated template in question is layouts/error.vm, the change affects all error pages, since they use the changed template as a layout. The identifier is a combination of the Request Id ($RequestId) and Session Id ($SessionId), if the latter exists.
layouts/error.vm
$RequestId
$SessionId
Templates updated:
ROOT_DIR/layouts/error.vm
(Where ROOT_DIR = $IDSVR_HOME/usr/share/templates/core.)
A new message has been added with message key error.identifier, which is visible in the error templates.
error.identifier
Message files updated:
ROOT_DIR/en/messages
ROOT_DIR/sv/messages
(Where ROOT_DIR = $IDSVR_HOME/usr/share/messages/core.)
Every endpoint can be configured to disallow, allow, or require mutual TLS. Depending on how the service role hosting that endpoint is configured, it may be possible to make a connection to the endpoint without mutual TLS when it is required or to use mutual TLS when it is forbidden. Previously, this would return an HTTP 426, Upgrade, error. To comply with the Financial-grade API (FAPI) standard, this has been changed to a 400, Bad Request. This status code can be reverted back to the old one by setting the system property se.curity:override:mtls-mismatch:statuscode to the value 426. Also, be aware that if the client indicates that it accepts JSON as the media type, this will now be returned, whereas plaintext was all that was previously returned. This behavior can be reverted to the old by providing an Accept header of text/plain, an Accept that doesn’t not include application/json, or no Accept header at all.
se.curity:override:mtls-mismatch:statuscode
426
Accept
text/plain
application/json