bin/kc.sh start-dev --features=account3In the past Keycloak was maintained across multiple GitHub repositories:
+Having multiple repositories introduced a lot of complexity and toil. For example frequently multiple pull requests had to be sent +to different repositories for a single change.
+To simplify things we have now migrated everything into the main repository.
+FIPS 140-2 support in Keycloak, which was preview in the previous release, is now promoted to be officially supported.
+The Account Console version 3 is now available as an experimental feature in Keycloak. This version supports custom fields created with the 'User Profile' feature. If you are looking to try it out and provide us with some early feedback you can enable it as follows:
+bin/kc.sh start-dev --features=account3As part of the removal of the deprecated adapters, the Keycloak Policy Enforcer was extracted from the adapters code base +into a separate dependency:
+<dependency>
+ <groupId>org.keycloak</groupId>
+ <artifactId>keycloak-policy-enforcer</artifactId>
+ <version>21.1.0</version>
+</dependency>By providing this dependency, we expect making it possible to integrate the policy enforcer with the Java stack of your preference.
+It also provides built-in support for enabling the policy enforcer to Jakarta applications protected with Wildfly Elytron.
+For now, this dependency is not yet GA as we are still working on the quickstarts and documentation.
+This work should not impact existing applications using the deprecated adapters.
+In the previous version, when Keycloak was used on Java 17 with Javascript providers it was needed to add the Nashorn +javascript engine to the distribution. This is no longer needed as Nashorn javascript engine is available in Keycloak server by default.
+If an application client is using non http(s) custom schemes, from now on the validation requires that a valid redirect pattern explicitly allows that scheme. Example patterns for allowing custom scheme are custom:/test, custom:/test/* or custom:*. For security reasons a general pattern like * does not cover them anymore.
Running the Keycloak server with Java 11 is no longer supported. Java 11 was deprecated in Keycloak 21 with the announced plan to be removed in Keycloak 22.
+Keycloak upgraded to version 3.2.0.Final of the Quarkus Java framework. +Quarkus 3.x continues the tradition of propelling Java development by moving fast and providing a cutting-edge user experience with the latest technologies.
+As part of upgrading to Quarkus 3.x Keycloak migrated its codebase from Java EE (Enterprise Edition) to its successor Jakarta EE, which brings various changes into Keycloak. +We have upgraded all Jakarta EE specifications in order to support Jakarta EE 10.
+In order to provide a better runtime and leverage as much as possible the underlying stack,
+all injection points for contextual data using the javax.ws.rs.core.Context annotation were removed. The expected improvement
+in performance involves no longer creating proxies instances multiple times during the request lifecycle, and drastically reducing the amount of reflection code at runtime.
Keycloak now benefits from the upgrade to Hibernate ORM 6.2, which includes improved performance, better SQL, modern JDK support, and support for modern RDBMS features.
+The previous and now removed WildFly distribution provided a built-in vault provider that reads secrets from a keystore-backed Elytron credential store. As this is no longer available, we have added a new implementation of the Keycloak Vault SPI called Keycloak KeyStore Vault. As the name suggests, this implementation reads secrets from a Java keystore file. Such secrets can be then used within multiple places of the Administration Console. For further details, see our guide and the latest documentation.
+In relation to the KeyStore Vault news, we also integrated Quarkus’s recently released feature called KeyStore Config Source. This means that among the already existing configuration sources (CLI parameters, environment variables and files), you can now configure your Keycloak server via configuration properties stored in a Java keystore file. You can learn more about this feature in the Configuration guide.
+As a number of users have had problems with configuring the hostname for the server correctly there is now a new helper tool to allow debugging the configuration.
+Installations which use Keycloak’s --proxy configuration setting with mode passthrough should review the documentation as the behavior of this mode has changed.
In previous releases, the export and import commands required a build command to be run first.
+Starting with this release, the export and import commands perform an automatic rebuild of Keycloak if a build time configuration has changed.
The old Account Console (v1) is now completely removed. This version of the Account Console was marked as deprecated +in Keycloak 12.
+In version 21.1.0 of Keycloak the new Account Console (version 3) was introduced as an experimental feature. Starting this version it has been promoted to a preview feature.
+Two of the variables exposed to the Account Console V2 and V3 templates (isEventsEnabled and isTotpConfigured) were left unused, and have been removed in this release.
It is possible that if a developer extended the Account Console theme, he or she could make use of these variables. So make sure that these variables are no longer used if you are extending the base theme.
+The Admin Console (and soon also the new Account Console) works slightly different than the rest of Keycloak in regards to how keys for internationalized messages are parsed. This is due to the fact that it uses the i18next library for internationalization. Therefore when defining custom messages for the Admin Console under "Realm Settings" ➡ "Localization" best practices for i18next must be taken into account. Specifically, when defining a message for the Admin Console it is it important to specify a namespace in the key of your message.
+For example, let’s assume we want to overwrite the welcome message shown to the user when a new realm has been created. This message is located in the dashboard namespace, same as the name of the original file that holds the messages (dashboard.json). If we wanted to overwrite this message we’ll have to use the namespace as a prefix followed by the key of the message separated by a colon, in this case it would become dashboard:welcome.
With this release, we have removed the legacy Promise API methods from the Keycloak JS adapter. This means that calling .success() and .error() on promises returned from the adapter is no longer possible.
new operatorIn a previous release we started to actively log deprecation warnings when the Keycloak JS adapter is constructed without the new operator. Starting this release doing so will throw an exception instead. This is to align with the expected behavior of JavaScript classes, which will allow further refactoring of the adapter in the future.
After the upgrade to Jakarta EE, artifacts for Keycloak Admin clients were renamed to more descriptive names with consideration for long-term maintainability. +We still provide two separate Keycloak Admin clients, one with Jakarta EE and the other with Java EE support.
+The User API now supports querying the number of users based on custom attributes. For that, a new q parameter was added to the /{realm}/users/count endpoint.
The q parameter expects the following format q=<name>:<value> <name>:<value>. Where <name> and <value> represent the attribute name and value, respectively.
The are additional fields available in the keycloak.status to facilitate keycloak being a scalable resource. There are also additional fields that make the status easier to interpret such as observedGeneration and condition observedGeneration and lastTransitionTime fields.
+The condition status field was changed from a boolean to a string for conformance with standard Kubernetes conditions. In the CRD it will temporarily be represented as accepting any content, but it will only ever be a string. Please make sure any of your usage of this field is updated to expect the values "True", "False", or "Unknown", rather than true or false.
+In scenarios where advanced management is needed you may now directly update most fields on operator managed resources that have not been set by the operator directly. This can be used as an alternative to the unsupported stanza of the Keycloak spec. Like the unsupported stanza these direct modifications are not considered supported. If your modifications prevent the operator from being able to manage the resource, there Keycloak CR will show this error condition and the operator will log it.
+OpenID Connect identity providers support a new configuration to specify that the ID tokens issued by the identity provider must have a specific claim, +otherwise the user can not authenticate through this broker.
+The option is disabled by default; when it is enabled, you can specify the name of the JWT token claim to filter and the value to match +(supports regular expression format).
+The OpenID Connect providers now support Json Web Encryption (JWE) for the ID Token and the UserInfo response. The providers use the realm keys defined for the selected encryption algorithm to perform the decryption.
+The new hardcorded group mapper allows adding a specific group to users brokered from an Identity Provider.
+The new user session note mapper allows mapping a claim to the user session notes.
+LDAP option to use truststore SPI Only for ldaps has been removed. This parameter is used to
+select truststore for TLS-secured LDAP connection: either internal Keycloak truststore is
+picked (Always), or the global JVM one (Never).
Deployments where Only for ldaps was used will automatically behave as if Always option was
+selected for TLS-secured LDAP connections.
The openshift-integration preview feature that allowed replacing the internal IdP in OpenShift 3.x with Keycloak was removed from Keycloak codebase into separate extension project.
Keycloak now supports multiple LDAP providers in a realm, which support Kerberos integration with the same Kerberos realm. When an LDAP provider is not able to find the user which was authenticated through +Kerberos/SPNEGO, Keycloak ties to fallback to the next LDAP provider. Keycloak has also better support for the case when single LDAP provider supports multiple Kerberos realms, which are in trust with each other.
+A security vulnerability was introduced in Keycloak 22.0.2. We highly recommend not upgrading to 22.0.2, and for anyone that has deployed 22.0.2 in production to upgrade to 22.0.3 immediately.
+For users that has self-registered after Keycloak was upgraded to 22.0.2 their password is not stored securely, and can be exposed to administrators of Keycloak. This only affects users that has registered after the upgrade was rolled-out, and does not affect any previously registered users.
+Any realm using the preview declarative user profile is not affected by this issue, and only realms using the default user profile provider is affected.
+To identify if there are any affected users in your deployment you can query these by accessing the database, and running the following SQL statement:
+SELECT DISTINCT U.ID, U.USERNAME, U.EMAIL, U.REALM_ID FROM USER_ENTITY U
+ INNER JOIN USER_ATTRIBUTE UA ON U.ID = UA.USER_ID
+ WHERE UA.NAME IN ('password','password-confirm')We recommend contacting any affected users as well as adding the update password required action for them.
+If there are any affected users we also recommend removing these attributes from the database by running the following SQL statement:
+DELETE FROM USER_ATTRIBUTE UA WHERE UA.NAME IN ('password','password-confirm')If any backups have been done of the database after the 22.0.2 release and there are affected users, we recommend deleting these.
+Any deployments with custom user storage federation providers may also be affected, please verify your custom user storage to identify if this is an issue.
+To identify if there are any federated user affected in your deployment in case the user storage provider is delegating management of attributes to Keycloak, you can query these by accessing the database, and running the following SQL statement:
+SELECT DISTINCT USER_ID,REALM_ID,STORAGE_PROVIDER_ID FROM FED_USER_ATTRIBUTE
+ WHERE NAME IN ('password','password-confirm')If there are any affected federated users, we also recommend removing these attributes from the database by running the following SQL statement:
+DELETE FROM FED_USER_ATTRIBUTE UA WHERE UA.NAME IN ('password','password-confirm')If your custom user storage provider is managing attributes itself, you should look at your custom storage to remove the password and password-confirm attributes.
To download the release go to Keycloak downloads.
+ +<#if version.releaseNotes??> +Before upgrading refer to the migration guide for a complete list of changes.
+ +<#if version.changes?? && version.changes.all?has_content> +Before upgrading refer to the migration guide for a complete list of changes.
+ +<#if version.changes?? && version.changes.all?has_content> +${c.area}${c.area}${c.area}${c.area}