diff --git a/docs/documentation/release_notes/topics/25_0_0.adoc b/docs/documentation/release_notes/topics/25_0_0.adoc index 979826b9d5..24aaa629c5 100644 --- a/docs/documentation/release_notes/topics/25_0_0.adoc +++ b/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. diff --git a/docs/documentation/server_admin/topics/authentication/password-policies.adoc b/docs/documentation/server_admin/topics/authentication/password-policies.adoc index d5f7f1c98e..bb9ffde48f 100644 --- a/docs/documentation/server_admin/topics/authentication/password-policies.adoc +++ b/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 <> 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. diff --git a/docs/documentation/server_admin/topics/clients/client-policies.adoc b/docs/documentation/server_admin/topics/clients/client-policies.adoc index e49c72c9d9..2df4f50999 100644 --- a/docs/documentation/server_admin/topics/clients/client-policies.adoc +++ b/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 diff --git a/docs/documentation/server_admin/topics/identity-broker/first-login-flow.adoc b/docs/documentation/server_admin/topics/identity-broker/first-login-flow.adoc index 4e1b5e7fa0..f69427132d 100644 --- a/docs/documentation/server_admin/topics/identity-broker/first-login-flow.adoc +++ b/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.