Additional release notes for Keycloak 24 (#27339)

closes #27142

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


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

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

@@ -30,7 +30,7 @@ benefit from the user profile capabilities, but you are not required to use them
 The first release of the user profile as a supported feature is just the starting point and the baseline for delivering many more capabilities around identity management.
 
 ifeval::[{project_community}==true]
-We would like to give huge thanks to theawesome Keycloak community as lots of ideas, requirements and contributions came from the community! Special thanks to:
+We would like to give huge thanks to the awesome Keycloak community as lots of ideas, requirements and contributions came from the community! Special thanks to:
 
 * https://github.com/velias[Vlastimil Eliáš]
 * https://github.com/alechenninger[Alec Henninger]
@@ -130,23 +130,45 @@ This release contains support for Lightweight access tokens. As a result, you ca
 claims, which is why they are smaller. Note that lightweight access token is still JWT signed by the realm key by default and still contains some very basic claims.
 
 This release introduces an *Add to lightweight access token* flag that is available on some OIDC protocol mappers. Use this flag to specify if a particular claim should be added to a lightweight
-access token. It is *OFF* by default, which means that most claims are not added. Also, a client policy executor exists. Use it to specify if a particular client request
+access token. It is *OFF* by default, which means that most claims are not added.
-should use lightweight access tokens or regular access tokens. A previous release added an *Add to token introspection* switch. You use it to add
+
+Also, a client policy executor exists. Use it to specify if a particular client request
+should use lightweight access tokens or regular access tokens. An alternative to the executor is to use an *Always use lightweight access token* flag on client advanced
+settings, which causes that client to always use lightweight access tokens. An executor can be an alternative if you need
+more flexibility. For instance, you may choose to use lightweight access tokens by default but use regular tokens only for the specified *scope* parameter.
+
+A previous release added an *Add to token introspection* switch. You use it to add
 claims that are not present in the access token into the introspection endpoint response.
+
 ifeval::[{project_community}==true]
 Thanks to https://github.com/skabano[Shigeyuki Kabano] for the contribution and Thanks to
 https://github.com/tnorimat[Takashi Norimatsu] for a help and review of this feature.
 endif::[]
 
+== OAuth 2.1 support
+
+This release contains optional OAuth 2.1 support. New client policy profiles were introduced in this release, which administrators can use to make sure that clients and particular client requests comply with the OAuth 2.1 specification. A dedicated client profile exists for confidential clients and a dedicated profile for public clients.
+ifeval::[{project_community}==true]
+Thanks to https://github.com/tnorimat[Takashi Norimatsu] and https://github.com/skabano[Shigeyuki Kabano] for the contribution.
+endif::[]
+
 == Scope parameter supported in the refresh token flow
 
-Starting with this release, the`scope` parameter in the OAuth2/OIDC endpoint for token refresh is supported. Use this parameter to request access tokens with a smaller amount
+Starting with this release, the *scope* parameter in the OAuth2/OIDC endpoint for token refresh is supported. Use this parameter to request access tokens with a smaller amount
 of scopes than originally granted, which means you cannot increase access token scope. This scope limitation does not affect the scope of the refreshed refresh token. This function works as
 described in the OAuth2 specification.
 ifeval::[{project_community}==true]
 Thanks to https://github.com/cgeorgilakis[Konstantinos Georgilakis] for the contribution.
 endif::[]
 
+== Client policy executor for secure redirect URIs
+
+A new client policy executor `secure-redirect-uris-enforcer` is introduced. Use it to restrict which redirect URIs can be used by the clients. For instance, 
+you can specify that client redirect URIs cannot have wildcards, should be just from specific domain, must be OAuth 2.1 compliant, and so on.
+ifeval::[{project_community}==true]
+Thanks to https://github.com/lexcao[Lex Cao] and https://github.com/tnorimat[Takashi Norimatsu] for the contribution.
+endif::[]
+
 == Client policy executor for enforcing DPoP
 
 A new client policy executor `dpop-bind-enforcer` is introduced. You can use it to enforce DPoP for a particular client if `dpop` preview
@@ -164,6 +186,13 @@ Thanks to
 https://github.com/tnorimat[Takashi Norimatsu] and https://github.com/MuhammadZakwan[Muhammad Zakwan Bin Mohd Zahid] for the contribution.
 endif::[]
 
+== EC Keys supported by JavaKeystore provider
+
+The provider `JavaKeystoreProvider` for providing realm keys now supports EC keys in addition to previously supported RSA keys.
+ifeval::[{project_community}==true]
+Thanks to https://github.com/wistefan[Stefan Wiedemann] for the contribution.
+endif::[]
+
 == Option to add X509 thumbprint to JWT when using private_key_jwt authentication for identity providers
 
 OIDC identity providers now have the *Add X.509 Headers to the JWT* option for the situation when client authentication with JWT signed by private key is used. This option can be useful
@@ -172,6 +201,14 @@ ifeval::[{project_community}==true]
 Thanks to https://github.com/MikeTangoEcho[MT] for the contribution.
 endif::[]
 
+== OAuth Grant Type SPI
+
+The {project_name} codebase includes an internal update  to introduce the OAuth Grant Type SPI. This update allows additional flexibility when introducing custom grant types
+supported by the {project_name} OAuth 2 token endpoint.
+ifeval::[{project_community}==true]
+Thanks to https://github.com/dteleguin[Dmitry Telegin] for the contribution.
+endif::[]
+
 = CORS improvements
 
 The CORS related {project_name} functionality was extracted into the SPI, which can allow additional flexibility. Note that `CorsSPI` is internal and may change at a future release.

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

@@ -79,6 +79,10 @@ Client Role::
     Applies for clients with the client role of the specified name. Typically you can create a client role of specified name to requested clients and use it as a "marker role" to make
     sure that specified client policy will be applied for requested clients.
 
+NOTE: A use-case often exists for requiring the application of a particular client policy for the specified clients such as `my-client-1` and `my-client-2`. The best way to achieve this result 
+is to use a *Client Role* condition in your policy and then a create client role of specified name to requested clients. This client role can be used as a "marker role" used solely
+for marking that particular client policy for particular clients.
+
 Client Domain Name, Host or IP Address::
     Applied for specific domain names of client. Or for the cases when the administrator registers/updates client from particular Host or IP Address.