There are no changes to the database schema, SDK, or the configuration model in this version. As a result, it should be possible to upgrade without explicit action. One configuration setting was deprecated, so it can be changed to the new setting if desired. If this change is not made, the old will continue to be used until at least the next major version.
There is a profile-wide setting that causes parameters that are provided in HTTP form / query strings to always be included as claims in request objects. This is off by default, but can be enabled (e.g., to comply with FAPI 1 advanced). The support for JAR and PAR extended how parameter merging should be handled. As a result, a new setting was added and the old one, require-parameters-as-claims was deprecated. To prepare the configuration for when this old setting will be obsolete, the following changes may be made:
require-parameters-as-claims
<request-object> <!-- ... --> <require-parameters-as-claims>true</require-parameters-as-claims> </request-object>
request-object-parameter-handling
<admin-service> <!-- ... --> <request-object-parameter-handling>must-be-inside-and-match-if-outside</request-object-parameter-handling> </admin-service>
Certain profiles of OpenID Connect, like FAPI and CIBA, require a request object not be valid longer than a certain time. This was previously checked automatically, but now needs to be configured explicitly. This allows customers to reduce or extend the time as required by their deployments or satisfy the requirements of other profiles of OpenID Connect. However, with this release, no default maximum lifetime of request objects is applied. To maintain the same behavior as in previous releases, the following configuration should be added:
<request-object> <!-- ... --> <maximum-lifetime>60</maximum-lifetime> </request-object>
Request objects cannot have a validity greater than three hours. To allow them to last longer, do not configure a lifetime.
In order to support not only OpenID Connect and FAPI’s requirements for handling request objects but also JAR and PAR’s, client authentication claims in a request object are no longer verified implicitly. Before, in requests made to the authorize endpoint, parameters like client_id and client_secret had to match claims with the same name in the request object. These claims didn’t have to be explicitly configured as required. Due to differences in these newly-supported standards, this is no longer the case. In order for the client_id and other client-authentication-related claims in a JWT request object to be required, they must be explicitly configured as such. This can be done by adding configuration such as this:
client_id
client_secret
<request-object> <!-- ... --> <required-claim>client_id</required-claim> </request-object>
Some alarms have been updated to employ a sliding window on incoming faults before the alarm is raised. These sliding windows are enabled by default, and must be disabled manually to retain alarm behavior as it was before upgrading.
Affected alarms are slow-connection alarms for
slow-connection
and failed-communication alarms for
failed-communication
It is recommended to have sliding windows enabled for these alarms, to reduce false positives for raised alarms. When it’s deemed appropriate to disable some, or all, of these alarms, see configuration examples below.
<config xmlns="http://tail-f.com/ns/config/1.0"> <facilities xmlns="https://curity.se/ns/conf/base"> <data-sources> <data-source> <id>my-data-source</id> <data-source-alarms> <slow-connection-alarm> <sliding-window> <faults-to-raise-alarm>1</faults-to-raise-alarm> <sliding-window-duration>0</sliding-window-duration> </sliding-window> </slow-connection-alarm> </data-source-alarms> </data-source> </data-sources> </facilities> </config>
<config xmlns="http://tail-f.com/ns/config/1.0"> <facilities xmlns="https://curity.se/ns/conf/base"> <data-sources> <data-source> <id>my-data-source</id> <data-source-alarms> <failed-communication-alarm> <sliding-window> <faults-to-raise-alarm>1</faults-to-raise-alarm> <sliding-window-duration>0</sliding-window-duration> </sliding-window> </failed-communication-alarm> </data-source-alarms> </data-source> </data-sources> </facilities> </config>
<config xmlns="http://tail-f.com/ns/config/1.0"> <facilities xmlns="https://curity.se/ns/conf/base"> <http> <client> <id>my-http-client</id> <client-alarms> <failed-communication-alarm> <sliding-window> <faults-to-raise-alarm>1</faults-to-raise-alarm> <sliding-window-duration>0</sliding-window-duration> </sliding-window> </failed-communication-alarm> </client-alarms> </client> </http> </facilities> </config>
There were templates updated to account for encoding the user provided state parameter when this value is being used in forms. In case you modified these templates on your own, these changes need to be made manually as well.
state
The affected templates and their changes are:
templates/core/views/oauth/consent.vm
<form method="post" action="$!_target" class="consent-form center"> - <input type="hidden" name="state" value="$!_state" /> + <input type="hidden" name="state" value="$_tr.encodeHtmlAttribute($!_state)" />
templates/core/views/oauth/form-response-mode.vm
#if ($state) - <input type="hidden" name="state" value="$state"/> + <input type="hidden" name="state" value="$_tr.encodeHtmlAttribute($state)"/> #end
The WebAuthn templates did not include a static resource path when one was configured. For customers that have configured this setting and have overridden the WebAuthn templates, the img and src attributes should be updated to include $!_staticResourceRootPath. These changes are needed in the following templates:
img
src
$!_staticResourceRootPath
$IDSVR_HOME/usr/share/templates/core/authenticator/webauthn/js/common-js.vm
$IDSVR_HOME/usr/share/templates/core/authenticator/webauthn/register/get.vm
The form response mode template, form-response-mode.vm was updated to support JARM. If this template has been overriden and JARM support is needed, the hidden response form parameter should be added.
form-response-mode.vm
response
The RESTCONF API has been fixed in a two places to conform with the specification.
1. Errors in JSON
The error reporting in JSON has been fixed to always include the module name in the parameter response. Before "errors" was reported as a key, this has been updated to correctly use ietf-restconf:errors.
"errors"
ietf-restconf:errors
2. List responses in JSON
When a list contained a single item, this was not wrapped in an array. This has been fixed and list responses are now always wrapped inside an array.
TLS settings of HTTP clients and databases have been changed to disallow versions 1.0 and 1.1 by default. To reenable them, do the following:
Create a new file somewhere on the Curity Identity Server node (e.g., $IDSVR_HOME/etc/my-good-security.policy)
$IDSVR_HOME/etc/my-good-security.policy
Add contents similar to the following to enable TLS 1.0 and 1.1 while leaving other algorithms disabled:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \ EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \ include jdk.disabled.namedCurves
Pass this policy file to the node using the Java options, e.g., like -Djava.security.properties=$IDSVR_HOME/etc/my-good-security.policy
-Djava.security.properties=$IDSVR_HOME/etc/my-good-security.policy
No changes have been made to the SDK. However, the provided version of Kotlin was upgraded to 1.5.10. Plug-in developers are encouraged to upgrade to this version to remain aligned with the included version. The old version, 1.3.72, of the Kotlin JAR file should be removed from any plug-in’s directory when upgrading. Otherwise, a version mismatch will cause the server not to start.