From this Curity Identity Server release, the database initialization scripts also support multi-tenancy for delegations.
This migration is only required if it’s important to be able to associate Delegations and tenants. That information could be used in the User Management Delegations endpoint or by querying the database directly.
Warning
If multi-tenancy is already enabled on a Curity Identity Server cluster using JDBC datasource, then delegations will not get assigned to the tenant configured on the authentication profile. As a consequence the SCIM delegations endpoint will not be able to discriminate between delegations of different tenants. In the case associating existing delegations to their actual tenant is needed, please contact Curity Support.
So that delegations are assigned to their owning tenant, it is advised to consider migrating the database schema as soon as possible. All delegations created for a custom tenant before the schema migration will still be valid and no data migration is needed.
Note
Database schema initialization scripts without multi-tenancy support are provided in Curity Identity Server releases under misc/database-schemas directory.
misc/database-schemas
To upgrade the SQL database schema, the following steps must be carried out:
To enable the multi-tenancy feature for delegations in Curity Identity Server, a new column must be created in the delegations table by running the <dbms>-upgrade-from-9.3-to-9.4.sql SQL file matching your DBMS. It is provided with this release in the $IDSVR_INSTALL/misc/upgrade/9.3-to-9.4 directory.
delegations
<dbms>-upgrade-from-9.3-to-9.4.sql
$IDSVR_INSTALL/misc/upgrade/9.3-to-9.4
Upgrade Curity Identity Server to version 9.4.0 or above following the General Upgrade Procedure
The password reset flow was improved, so that the options to continue to authentication are only displayed when they can actually be used. In that context, the authenticator/html-form/set-password/post.vm and authenticator/html-form/account-activation/success.vm templates were updated, including the addition of a new message key.
authenticator/html-form/set-password/post.vm
authenticator/html-form/account-activation/success.vm
Until now, the session cookie had the path attribute set to /. In 9.4.0 the value is set to a more specific path. This prevents sending the cookie to locations other than a token handler application (e.g. a token handler proxy). The value defaults to /<APPS_ANONYMOUS_ENDPOINT_PATH>/<APPLICATION_ID>. There’s also an optional configuration field session-cookie-path added to token handler applications. This field can be used to override the default value for the session cookie path attribute. It can be set in cases when an HTTP proxy rewrites the path to a token handler application.
path
/
9.4.0
/<APPS_ANONYMOUS_ENDPOINT_PATH>/<APPLICATION_ID>
session-cookie-path
The provided version of Kotlin was upgraded from 1.9.21 to 2.0.0. Plug-in developers are encouraged to upgrade to this version to remain aligned with the included version. We strongly recommend to recompile and thoroughly test all custom plugins written in Kotlin.
1.9.21
2.0.0