libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases 1 Packages Activity Actions

Additional release notes for Keycloak 24 (#27339)

Browse source 
closes #27142

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


Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
This commit is contained in:
Marek Posolda 2024-02-29 08:43:22 +01:00 committed by GitHub
parent dd2605b054
commit 8dd0eb451d
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 45 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
docs/documentation/release_notes/topics/24_0_0.adoc
View file

@ -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
should use lightweight access tokens or regular access tokens. A previous release added an *Add to token introspection* switch. You use it to add
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
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.

4
docs/documentation/server_admin/topics/clients/client-policies.adoc
View file

@ -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.