When using the external-browser-flow client operation, a client gets a launch link to be opened in an external browser. That link is valid for a short period of time.
In rare situations where the browser asks for user interaction before actually following the link (e.g. creating a new account on the device), the link may expire.
A new template was added (views/api/external-flow-launch-error) for this particular scenario, displaying a specific error message to the user.
When using HAAPI, it is now possible to enable authorization and refresh token binding using DPoP.
See Authorization code and refresh token binding on how to enable this feature for specific OAuth clients.
The use of this feature requires the use of a compatible Android or iOS HAAPI SDK version (see SDK guide).
This release introduces DynamoDB support for database clients that are accessible through GraphQL, the Devops Dashboard and the admin UI.
To use this feature, a new table must be created for the database clients on DynamoDB as described below, otherwise it is optional.
aws dynamodb create-table [...] --cli-input-json file://<IDSVR>/etc/create-table-curity-database-clients.json
Also refer to DynamoDB for more information on Amazon DynamoDB support in Curity Identity Server.
The BankID authenticator has been updated for better handling of polling and browser differences. The new behaviours is not on by default, but must be enabled in the settings.vm. More on the available options in the See BankID Authenticator Docs.
Updated template: authenticator/bankid/launch/index.vm
The SAML authenticator has been marked as deprecated since the Curity Identity Server version 7.6. It was replaced by the
SAML2 authenticator. As support for the original SAML authenticator is planned to be dropped,
it is strongly advised to migrate to the SAML2 authenticator.
The Encap authenticator is now deprecated and will be removed in some future major version
(the exact version when it will be deprecated is not yet decided). It is advised to reconsider the use of the Encap
authenticator and instead investigate alternative means of authentication, or to find an alternative way of
getting support for it.
The current default launch behavior is now deprecated and will be removed in an upcoming major release. It is advised to enable the new behavior in preparation of this removal. See BankID Authenticator Docs for details.
This version introduces Credential Policies as an experimental feature. Credential policies are applied during password
verification and/or update, and support features like password complexity requirements and temporary lockouts on failed
attempts. These policies are configured via the Facilities menu in the Admin UI.
Refer to Credential Managers for more information.
Credential policies require that the configured Credential data source has certain capabilities. For this release,
credential policies can only be used with the JDBC data source (with specific configuration) or with a dedicated Bucket.
In addition, the HTML Forms authenticator was partially updated to leverage credential policies. For example, during
authentication, details about verification failures are shown and it is possible to reset an expired password.
The authenticator will be further improved in upcoming releases.
Note that, to avoid redundancy, when using a credential policy with Temporary Lockout rule enabled,
it is advised to configure the HTML Forms authenticator Max Allowed Attempts setting to 0.
Max Allowed Attempts
Plugins using the CredentialManager SDK service can immediately use credential policies as they are configured in
a Credential Manager in the system. However, that service interface doesn’t provide fine-grained details about the
outcome of credential operations. New service interfaces were introduced, which allow plugins to obtain more details.
Refer to the SDK changes section below for more information.
The database schema for the JDBC data source is being updated to better accommodate credential policies and
deployments with dedicated credential data sources. There are new configuration options for a “credentials mode” which
determines how the data source operates. for this release, these options are only meant for green-field environments/deployments.
The next major release will include schema upgrade scripts and data migration tooling.
Refer to the JDBC data source documentation for more information.
The experimental Credential Data Access Provider interfaces added in previous versions were refined to match the intended capabilities.
These interfaces will become the recommended API for Credential data sources in a future version, so it is advised that authors of data access plugins get familiar with them.
Refer to the CredentialManagementDataAccessProvider type in the server SDK.
New service interfaces for Credential Management were added to the server SDK. Refer to the CredentialVerifier and UserCredentialManager types in the server SDK.
These interfaces are still experimental, but only small changes are expected in upcoming releases.
The new services allow plugin authors to get full details about credential operations - namely considering Credential Policies - and are recommended as a replacement for the CredentialManager service.
The CredentialManager service is now deprecated in favor of the new Credential Management services introduced in this release and mentioned in the previous item.
CredentialManager will be supported for at least one more major release of the Curity Identity Server.
The new interfaces expose methods for setting and verifying credentials which allow achieving the same goals as CredentialManager, but the possible outcomes are clearer and the result types are more expressive.