Friday, November 15 2019
To download the release go to Keycloak downloads.
Several configuration fields can obtain their value from a vault instead of entering the value directly: LDAP bind password, SMTP password, and identity provider secrets.
Furthermore, new vault SPI has been introduced to enable development of extensions to access secrets from custom vaults.
The fixed and request hostname providers have been replaced with a single new default hostname provider. This provider comes with a number of improvements, including:
No need to change provider to set fixed base URL
Support different base URL for frontend and backend requests
Support changing context-path in cases where Keycloak is exposed on a different context-path through a reverse proxy
Message bundles in theme resources enables internationalization of custom providers such as authenticators. They are also shared between all theme types, making it possible to for example share messages between the login and account console. Thanks to micedre.
We have added a new SPI that allows for the configuration of custom role mappers that are used by the SAML adapters to map
the roles extracted from the SAML assertion into roles that exist in the SP application environment. This is particularly useful
when the adapters need to communicate with third party IDPs and the roles set by the IDP in the assertion do not correspond to
the roles that were defined for the SP application. The provider to be used can configured in the
file or in the
keycloak-saml subsystem. An implementation that performs the role mappings based on the contents of a properties
file was also provided.
Notice that when Keycloak acts as the IDP we can use the built-in role mappers to perform any necessary mappings
before setting the roles into the assertion, so this SPI will probably be redundant in this case. The
SPI was designed for situations when the IDP offer no way to map roles before adding them to the assertion.
Keycloak server was upgraded to use WildFly 18 under the covers.
With the arrival of W3C Web Authentication support, we’ve refined the authentication flow system to be able to allow a user to select which authentication method is preferred for login (for example, the choice between an OTP credential and a WebAuthn credential). The new mechanisms also allow an administrator to craft flows for password-less login, for example just using WebAuthn as an authentication method. Please note that with these changes, any custom authentication flow you have created may need to be adapted to the new flow logic.
As a result of these changes, users can now have multiple OTP devices and multiple WebAuthn devices. The same system that allows a user to select which type of device to use during login also allows that user to select which specific device to use. Thanks to the Cloudtrust team: AlistairDoswald, sispeo and Fratt for their contributions, and to harture and Laurent for their help.
It is now possible to use system properties and environment variables within theme.properties file. Thanks to Opa-
Thanks to tnorimat, we support more signing algorithms for client authentication with signed JWT.
Thanks to jonkoops now it’s possible to enable or disable logging for the JS adapter.
Please take a look at 7.0.1 Release Notes for more details on how you can now deploy and run scripts to customize specific behavior.
The full list of resolved issues are available in JIRA
Before you upgrade remember to backup your database and check the upgrade guide for anything that may have changed.