Version 7.4.0 contains changes regarding actions and DynamoDB schema. Details are provided below.
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.
EmailSender
authentication-action/{type}
type
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:
usr/share/templates/overrides/some-directory/test-email.vm
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:
usr/share/templates/overrides/authentication-action/{type}
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.
usr/share/templates/template-areas/{area-name}/authentication-action/{type}
area-name
In the following unlikely scenario, an existing Authentication Action and/or template location may need to be modified:
usr/share/templates/overrides
usr/share/templates/template-areas/{area-name}
In this case, the template in the template area is now used.
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.
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.
deleteAccount
Account
deleted
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.
dynamicallyRegisteredClients
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.
authenticatedUser-created-index
authenticatedUser
created
authenticatedUser-updated-index
updated
instanceOfClient-created-index
instanceOfClient
instanceOfClient-updated-index
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/.
$IDSVR_INSTALL/misc/upgrade/
authenticatedUser-created-index.json
authenticatedUser-created_attribute-definitions.json
authenticatedUser-updated-index.json
authenticatedUser-updated_attribute-definitions.json
instanceOfClient-created-index.json
instanceOfClient-created_attribute-definitions.json
instanceOfClient-updated-index.json
instanceOfClient-updated_attribute-definitions.json
aws dynamodb update-table
--global-secondary-index-updates
--attribute-definitions
aws dynamodb update-table [...] --global-secondary-index-updates file://${D}/authenticatedUser-created-index.json --attribute-definitions file://${D}/authenticatedUser-created_attribute-definitions.json [...]
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.