Update release notes for Keycloak 25 (#29894)

closes #29576

Signed-off-by: mposolda <mposolda@gmail.com>


Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>

docs/documentation/release_notes/topics/25_0_0.adoc

@@ -115,6 +115,35 @@ For more details, see the link:{upgradingguide_link}[{upgradingguide_name}]..
 
 Keycloak supports a new password policy that allows you to deny user passwords which contains the user username.
 
+= Required actions improvements
+
+In the Admin Console, you can now configure some required actions in the *Required actions* tab of a particular realm. Currently, the *Update password* is the only built-in configurable required action. It supports setting *Maximum Age of Authentication*, which is the maximum time users can update their password
+by the `kc_action` parameter (used for instance when updating password in the Account Console) without re-authentication. The sorting of required actions is also improved. When there are multiple required
+actions during authentication, all actions are sorted together regardless of whether those are actions set during authentication (for instance by the `kc_action` parameter) or actions added to the user account manually by an administrator.
+Thanks to https://github.com/thomasdarimont[Thomas Darimont] and https://github.com/danielFesenmeyer[Daniel Fesenmeyer] for the contributions.
+
+= Passkeys improvements
+
+The support for Passkeys conditional UI was added. When the Passkeys preview feature is enabled, there is a dedicated authenticator available, which means you can select from a list of available passkeys accounts
+and authenticate a user based on that. Thanks to https://github.com/tnorimat[Takashi Norimatsu] for the contribution.
+
+= Default client profile for SAML
+
+The default client profile to have secured SAML clients was added. When browsing through client policies of a realm in the Admin Console, you see a new client profile `saml-security-profile`. When it is used, there are
+security best practices applied for SAML clients such as signatures are enforced, SAML Redirect binding is disabled, and wildcard redirect URLs are prohibited.
+
+= Authenticator for override existing IDP link during first-broker-login
+
+There was new authenticator `Confirm override existing link` added. This authenticator allows to override linked IDP username for the {project_name} user, which was already linked to different
+IDP identity before. More details in the link:{adminguide_link}#_override_existing_broker_link[{adminguide_name}]. Thanks to https://github.com/lexcao[Lex Cao] for the contribution.
+
+= OpenID for Verifiable Credential Issuance - experimental support
+
+There is work in progress on the support of OpenID for Verifiable Credential Issuance (OID4VCI). Right now, this is still work in progress, but things are being gradually added. {project_name}
+can act as an OID4VC Issuer with support of Pre-Authorized code flow. There is support for verifiable credentials in the JWT-VC, SD-JWT-VC and VCDM formats. Thanks to the members of the OAuth SIG
+groups for the contributions and feedback and especially thanks to https://github.com/wistefan[Stefan Wiedemann], https://github.com/francis-pouatcha[Francis Pouatcha], https://github.com/tnorimat[Takashi Norimatsu]
+and https://github.com/bucchi[Yutaka Obuchi].
+
 = Searching by user attribute no longer case insensitive
 
 When searching for users by user attribute, {project_name} no longer searches for user attribute names forcing lower case comparisons. The goal of this change was to speed up searches by using {project_name}'s native index on the user attribute table. If your database collation is case-insensitive, your search results will stay the same. If your database collation is case-sensitive, you might see less search results than before.

docs/documentation/server_admin/topics/authentication/password-policies.adoc

@@ -125,3 +125,5 @@ The current implementation uses a BloomFilter for fast and memory efficient cont
 Specifies the maximum age of a user authentication in seconds with which the user can update a password without re-authentication. A value of `0` indicates that the user has to always re-authenticate with their current password before they can update the password.
 See <<con-aia-reauth_{context}, AIA section>> for some additional details about this policy.
 
+NOTE: The Maximum Authentication Age is configurable also when configuring the required action *Update Password* in the *Required Actions* tab in the Admin Console. The better choice is to use  the 
+required action for the configuration because the _Maximum Authentication Age_ password policy might be deprecated/removed in the future.

docs/documentation/server_admin/topics/clients/client-policies.adoc

@@ -37,7 +37,8 @@ Conformance to a required security standards and profiles such as FAPI and OAuth
 
 == Protocol
 
-The client policy concept is independent of any specific protocol. However, {project_name} currently supports it only just for the link:{adapterguide_link}#_oidc[OpenID Connect (OIDC) protocol].
+The client policy concept is independent of any specific protocol. {project_name} currently supports especially client profiles for the link:{adapterguide_link}#_oidc[OpenID Connect (OIDC) protocol], but there is
+also a client profile available for the link:{adapterguide_link}#_saml[SAML protocol].
 
 == Architecture
 
@@ -136,6 +137,7 @@ One of several purposes for this executor is to realize the security requirement
 * Enforce <<_using_lightweight_access_token, using lightweight access token>>
 * Enforce that <<_refresh_token_rotation,refresh token rotation>> is skipped and there is no refresh token returned from the refresh token response
 * Enforce a valid redirect URI that the OAuth 2.1 specification requires
+* Enforce SAML Redirect binding cannot be used or SAML requests and assertions are signed
 
 [[_client_policy_profile]]
 === Profile

docs/documentation/server_admin/topics/identity-broker/first-login-flow.adoc

@@ -116,7 +116,7 @@ NOTE: This flow can be used if you want to delegate the identity to other identi
 
 With this configuration, {project_name} is unable to determine which internal account corresponds to the external identity. The *Verify Existing Account By Re-authentication* authenticator asks the provider for the username and password.
 
-[[override_existing_broker_link]]
+[[_override_existing_broker_link]]
 ==== Override existing broker link
 When an another account needs to be linked to the same {project_name} account within the same identity provider, you can configure the following authenticator.
 
@@ -124,8 +124,9 @@ Confirm Override Existing Link::
 This authenticator will detect the existing broker link for the user and display a confirmation page to confirm overriding the existing broker link. Set the authenticator requirement to REQUIRED.
 
 A typical use of this authenticator is a scenario such as the following:
+
 * For example, consider a {project_name} user `john` with the email `john@gmail.com`. That user is linked to the identity provider `google` with the `google` username `john@gmail.com` .
-* Then for instance {project_name} user `john` updates his email in {project_name} to `john-new@gmail.com`
+* Then for instance {project_name} user `john` creates new Google account with email `john-new@gmail.com`
 * Then during login to {project_name}, the user authenticated to the identity provider `google` with a new username such as `john-new@gmail.com`, which is not linked to any {project_name} account yet (as {project_name} account `john` is still linked with the `google` user `john@gmail.com`) and hence the first-broker-login flow is triggered.
 * During first-broker-login, the {project_name} user `john` is authenticated somehow (either by default first-broker-login re-authentication or for instance by authenticator like `Detect existing broker user`)
 * Now with this authenticator in the authentication flow, it is possible to override the IDP link to the `google` identity provider of {project_name} user `john` with the new `google` link to `google` user `john-new@gmail.com` after user `john` confirms this.