Upgrading from 10.7.X to 11.0.0#

Authentication Profile#

OIDC authenticator#

The default value for the use-issuer-as-audience configuration setting, present in the asymmetrically-signed-jwt configuration section of the OIDC authenticator, is now true. This is a change in default behavior from the previous version (default was false), and it is recommended that his configuration setting be explicitly assigned with the intended value.

SMS authenticator#

The SMS authenticator relies on the Caching and Session data source to store verification codes. However, the configuration system didn’t require that data source to be configured when an SMS authenticator is used, which could lead to runtime errors.

In this release, the configuration system now requires that a Caching and Session data source is configured when an SMS authenticator is added to an authentication profile. Note that the Caching and Session data source is required to have session data that is persisted and accessible from multiple nodes, which should be the case in most deployments.

HTML Form authenticator#

Some templates were updated so that labels and input types adapt to the Username is Email setting of the associated Account Manager. Specifically, the label and type of the userName input are now rendered conditionally in the following templates:

  • authenticate/get.vm - The main authentication view. When Username is Email is enabled, the “forgot username” link is also hidden.
  • create-account/get.vm - The account creation view.
  • reset-password/get.vm - The view to start a password reset.

The corresponding HAAPI responses were also updated accordingly.

Encap authenticator#

As of 11.0, the Encap authenticator is no longer supported, nor included in the Curity Identity Server distributions.

GraphQL Settings#

The default for the enable-mutation-over-http-get global GraphQL setting was changed from true to a more secure false. If you still want to enable mutations over the HTTP GET method, you will need to explicitly set this setting to true in the GraphQL settings page:

Admin UISystemGeneralGraphQL

DynamoDB Data Source#

An attribute called expires was added to the curity-bucket table.

Run the update-time-to-live command to set a TTL on the expires attribute of the curity-bucket table. This will enable the automatic expiration of bucket entries.

MongoDB Data Source#

A field called expires was added to the buckets collection.

A TTL index should be added to the expires field of the buckets collection to enable the automatic expiration of bucket entries.

JDBC Data Source#

Database Schema Migration#

With version 11.0, the Curity Identity Server can help administrators perform database schema migrations by using the idsvr command. Under the hood, database migrations are implemented by Liquibase.

Make sure to read the new schema migration procedure before upgrading to version 11.0

Database Schema Changes#

Expiration of Buckets#

The database schema for JDBC data sources was updated to add support for bucket expiration, thus allowing to store bucket entries that expire after a certain time. Once a bucket entry is expired, it will not be returned in queries anymore.

A nullable expires column has been added to the buckets table. No action is required after performing a Database Schema Migration .

Group Management#

The database schema for the JDBC data sources was updated to add support for Group Management (as defined by SCIM specification). A set of database tables are added to the database schema to store the groups and their relations with accounts (and other Curity concepts).

SAML Service Providers#

The Curity Identity Server version 10.7 introduced the Database Service Providers feature, with an optional database upgrade. The Curity Identity Server version 11.0 upgrade scripts will create the related database tables, if and only if they were not already created.

Running The Database Migration#

To upgrade the SQL database schema, the following steps MUST be carried out:

  1. Perform a full database backup
  2. Optionally review the changes which will be executed on the database:
    • Liquibase changelog for 10.7: $IDSVR_HOME/etc/liquibase/core/10.7.0/default-10.7.0.xml (with Database Service Providers related changes)
    • Liquibase changelog for 11.0: $IDSVR_HOME/etc/liquibase/core/11.0.0/default-11.0.0.xml (with Group Management and Buckets Expiration related changes)
    • Or generate the SQL which will be effectively run (using the Curity Identity Server version 11.0) :
<ENV SETTINGS> idsvr -C default
  1. Upgrade the SQL database schema as follows (using the Curity Identity Server version 11.0):
<ENV SETTINGS> idsvr -L default
  1. Upgrade the Curity Identity Server to version 11.0.0 or above following the General Upgrade Procedure

Rolling Back The Database Migration#

In case a rollback of the database migration is needed, the following commands can be applied:

  • To roll back the database to the 10.7 schema version (reverting the changes in $IDSVR_HOME/etc/liquibase/core/11.0.0/default-11.0.0.xml only):
<ENV SETTINGS> idsvr -R default -t 10.7.0
  • To roll back the database to the 10.6 schema version (reverting the changes in $IDSVR_HOME/etc/liquibase/core/10.7.0/default-10.7.0.xml and $IDSVR_HOME/etc/liquibase/core/11.0.0/default-11.0.0.xml):
<ENV SETTINGS> idsvr -R default -t 10.6.0

Summary:

It’s now required to store credentials in the credentials table. The credentials-in-accounts-table and credentials-migration credential modes are no longer supported.

In version 9.0.0 of the Curity Identity Server a new credentials table was introduced to store credentials separately from accounts, and credential modes were added to support the previous database structure as well as transitioning to the new one. In version 10.0.0 the older database schema - where passwords were stored in the accounts table - was deprecated. The corresponding credentials-in-accounts-table and credentials-migration credential modes were also deprecated.

In this release the older database schema is no longer supported. Also, support for the credentials-in-accounts-table and credentials-migration credential modes was dropped and the server will not accept configuration using these modes. Any JDBC data source still using the old credentials schema/modes must be upgraded and configured with standard credentials mode before upgrading the server to version 11.0.0. Refer to the upgrade guide for version 9.0.0 for details on how to upgrade the database schema.

Remove the password column from the accounts table#

The JDBC data source no longer uses the password column in the accounts table. It is recommended (but not required) to remove this column from the table after deploying the server upgrade and verifying that no rollbacks are needed.

Data loss will occur while running the following procedure. Make sure to only execute it when the password migration has been fully completed.

To clean up the SQL database schema, the following steps MUST be carried out:

  1. Perform a full database backup
  2. Optionally review the changes which will be executed on the database:
  • Liquibase changelog for 11.0 cleanup: $IDSVR_HOME/etc/liquibase/core/optional/11.0.0-accounts-password-cleanup.xml
  • Or generate the SQL which will be effectively run (using the Curity Identity Server version 11.0) :
<ENV SETTINGS> idsvr -C core/optional/11.0.0-accounts-password-cleanup.xml
  1. Clean up the SQL database schema as follows (using the Curity Identity Server version 11.0):
<ENV SETTINGS> idsvr -L core/optional/11.0.0-accounts-password-cleanup.xml

End of support for non multi-tenant storage schema#

Summary:

It’s now required that all JDBC data sources are migrated to a multi-tenant schema. JDBC data sources without multi-tenant enabled tables are no longer supported.

In version 9.2.0 of the Curity Identity Server, the database schema for the JDBC data sources was updated to add support for multi-tenancy, thus allowing to store data for different tenants in a single database instance. While the database schema migration was optional in versions 9.x and 10.x of the Curity Identity Server, in this release the older database schema is no longer supported and JDBC data sources MUST be upgraded to support multi-tenancy.

Note that even though database schema must support multi-tenancy, it is not mandatory to configure and use this feature.

SDK#

Removal of the CredentialDataAccessProvider interface#

The changes mentioned in this section are meant for authors of data access plugins, namely when implementing support for Credential Data Access using the CredentialDataAccessProvider interface.

The CredentialDataAccessProvider interface, deprecated since version 10.0.0, was removed. The corresponding getCredentialDataAccessProvider method in the DataAccessProviderPluginDescriptor interface was also removed.

Any data access plugin implementing that interface must be updated to implement one of the subtypes of the CredentialManagementDataAccessProvider interface before upgrading the server to version 11.0.0. Refer to the upgrade guide for version 10.0.0 for details on how to update such plugins.

Removal of the CredentialManager interface#

The CredentialManager service interface, deprecated since version 8.7.0, was removed. Any plugin using that service in its configuration interface must be updated to use CredentialVerifier or UserCredentialManager before upgrading the server to version 11.0.0.

The CredentialManagerException class, deprecated since version 9.0.0, was also removed, as well as the corresponding credentialManagerException method in the ExceptionFactory service interface. That exception type was only meant to be used by data access plugins which implemented the CredentialDataAccessProvider interface, which is also removed in this release.

Refer to the Javadocs of the different interfaces for more details.

Deprecation of the get method in the NonceDataAccessProvider#

The get method in the NonceDataAccessProvider interface is now deprecated and will be removed in a future major release. Plugins implementing that interface should instead implement the new getNonce method, which returns the nonce data regardless of its status. The server can then validate the nonce status and expiration, allowing fine-grained error details when nonce consumption fails. The server still uses the get method if the getNonce method is not implemented, to maintain backwards compatibility. The bundled data source plugins have been updated accordingly.

The consume(String, long) method was deprecated in version 10.4.0 and will also be removed in a future major release.

Log4j library update#

Log4j was updated from version 2.22.0 to version 2.25.3. Some changes in log4j configuration may be required to keep the same logging behavior as before, namely:

  • Log4j’s internal logger (StatusLogger) now logs to standard error instead of standard output in more cases. The log4j2.xml configuration file shipped with the product was updated to set dest="out" in the root Configuration element (refer to the StatusLogger configuration reference for more details).
  • In the configuration of Rfc5424Layout, the newLine attribute was renamed to includeNL. The log4j2.xml configuration file shipped with the product was updated accordingly (includeNL="true" is used in some places).

Please refer to log4j’s release notes to confirm if any other changes may impact your deployment.

Token issuers are restricted to token profiles#

The token-issuers configuration section is now only available under token profiles (i.e. profiles with type oauth-service). Previously, it was possible to configure token issuers in other profile types (this was done by the server setup wizard in some cases), but they would not be considered in runtime.

XML configurations that define token-issuers outside of token/OAuth profiles are still accepted and that section is ignored, but it is recommended to update such configuration files to remove any unused token-issuers sections.

User Management Profile#

SCIM and GraphQL API behavior with configured Account Managers#

The account query and mutation operations exposed via the SCIM and GraphQL APIs now take into consideration the rules and behavior associated to a configured Account Manager. This improves the consistency in account management done via different interfaces, namely SCIM and GraphQL APIs and Account Manager direct access by plugins.

Here are some of the resulting changes in behavior, when a User Management profile has a configured Account Manager:

  • When an account is deleted via the SCIM API, the associated account links will also be deleted. When deleting an account via the GraphQL API the behavior remains unchanged, namely because account link deletion is an argument to the operation.
  • The “Username is Email” setting of the account manager will be used on both the SCIM and GraphQL APIs. For instance, if this setting is enabled, then the username will appear as the primary email when retrieving an account.
  • Both Account Manager and SCIM/GraphQL events will be emitted when accessing an account via SCIM/GraphQL.

Previously, any devices changes included in a user SCIM patch were ignored. In version 11.0.0, device mutations present in a user SCIM patch will also be applied.

BankID version 5 support removed#

Support for BankID version 5 has been removed. Upgrade to BankID version 6 before upgrading to this version.

Support for BankID version 5 was removed in this release. Any authenticators or configurations using BankID version 5 must be upgraded to BankID version 6 before upgrading the server to version 11.0.0.

Curity UI Kit - Now Open Source#

The Curity UI Kit has been completely restructured and is now available as an open-source project on GitHub.

What Changed#

Previously, UI Kit source was not available for download. In version 11.0.0, the UI Kit has been moved to a dedicated public GitHub monorepo, making it easier to customize and extend.

The Curity UI Builder concept is no longer used. All customization and development is now handled directly in the GitHub repository.

What is UI Kit#

The UI Kit is a GitHub repository that enables you to customize the look and feel of your applications. It’s a monorepo containing:

  • Curity Identity Server templates and messages
  • Self Service Portal
  • Common components and styles shared between the Identity Server and Self Service Portal, including:
    • Curity CSS
    • Curity UI Icons React
    • Component Library for React

Getting Started with UI Kit#

To run UI Kit locally:

  1. Clone or fork the repository from GitHub
  2. Ensure you have Node.js installed (use nvm use to switch to the correct version)
  3. Run the following commands:
npm install
npm start

A browser tab will open automatically with an overview page. Follow the links to access the Identity Server template listing page and Self Service Portal previewer.

For detailed instructions on installation, setup, and development workflow, refer to the UI Kit documentation.

For more information on customizing your Curity Identity Server deployment, see:

Was this helpful?