Upgrading from 7.3.X to 7.4.0

Version 7.4.0 contains changes regarding actions and DynamoDB schema. Details are provided below.

Email templates in Authentication Actions

The resolution of email templates when using the EmailSender SDK service in Authentication Actions was updated to use the same directory structure as other templates in Curity. This means that email templates are resolved relative to authentication-action/{type} within the templates directory, where type is the plugin type of the executing Authentication Action.

The previous behavior - i.e. resolving the template provided to EmailSender relative to the root of the templates directory - is still supported, but it is recommended that Authentication Actions are updated to use the common directory structure. As an example, if the usr/share/templates/overrides/some-directory/test-email.vm template exists, it would previously be used with EmailSender as follows:

emailSender.sendEmail("user@example.com", new Email(...), "some-directory/test-email")

It is recommended to move such template to the Authentication Action’s template directory (i.e. usr/share/templates/overrides/authentication-action/{type}) and use it with EmailSender as follows:

emailSender.sendEmail("user@example.com", new Email(...), "test-email")

In addition, template areas are now considered when resolving the email templates. This means that if a template is found in usr/share/templates/template-areas/{area-name}/authentication-action/{type}, it is considered by Curity when the area-name template area is used.

In the following unlikely scenario, an existing Authentication Action and/or template location may need to be modified:

  • The email template being used by the Authentication Action exists in usr/share/templates/overrides
  • A template with the same name also exists for the area-name template area (i.e. in usr/share/templates/template-areas/{area-name})
  • The requesting client is configured to use the area-name template area

In this case, the template in the template area is now used.

Startup script changes

The way the server starts by the idsvr script has been changed so that it now takes over the main process instead of spawning a child process.

User Management with GraphQL

The GraphQL User Management deleteAccount mutation response has been updated to include an Account in addition to deleted (boolean value) so that any linked accounts or dynamically registered clients can be easily identified.

DynamoDB schema changes

This release brings dynamic client listing on DynamoDB through the dynamicallyRegisteredClients GraphQL query. To use this feature, the schema of the dynamic clients table on DynamoDB must be updated as described below, otherwise it is optional.

To allow listing dynamic clients through GraphQL, 4 global secondary indexes (GSI) must be added to the schema of the dynamic clients table: - authenticatedUser-created-index: with authenticatedUser attribute as partition key and created attribute as sort key, - authenticatedUser-updated-index: with authenticatedUser attribute as partition key and updated attribute as sort key, - instanceOfClient-created-index: with instanceOfClient attribute as partition key and created attribute as sort key, - and instanceOfClient-updated-index: with instanceOfClient attribute as partition key and updated attribute as sort key.

To facilitate updating the dynamic clients table’s schema, JSON configuration files are provided with this release, in the $IDSVR_INSTALL/misc/upgrade/ directory. A pair is provided for each index to be created: - for authenticatedUser-created-index: authenticatedUser-created-index.json and authenticatedUser-created_attribute-definitions.json, - for authenticatedUser-updated-index: authenticatedUser-updated-index.json and authenticatedUser-updated_attribute-definitions.json, - for instanceOfClient-created-index: instanceOfClient-created-index.json and instanceOfClient-created_attribute-definitions.json, - and for instanceOfClient-updated-index: instanceOfClient-updated-index.json and instanceOfClient-updated_attribute-definitions.json. They can be used with the aws dynamodb update-table command and passed as arguments to, respectively, the --global-secondary-index-updates and the --attribute-definitions options, to create each one of the 4 indexes. For instance, to create authenticatedUser-created-index: aws dynamodb update-table [...] --global-secondary-index-updates file://${D}/authenticatedUser-created-index.json --attribute-definitions file://${D}/authenticatedUser-created_attribute-definitions.json [...] Where D=$IDSVR_INSTALL/misc/upgrade/.

The update must be done only if you plan to list dynamic clients on DynamoDB through GraphQL. It can be done either: - Before having updated the Identity Server, and while running the previous version. Indeed, this will only extend the schema by adding new indexes. - After having updated the Identity Server and while running the new version, or even when server is stopped.