69497382d8
closes #22372 Co-authored-by: Erik Jan de Wit <erikjan.dewit@gmail.com> Co-authored-by: Pedro Igor <pigor.craveiro@gmail.com> Co-authored-by: Michal Hajas <mhajas@redhat.com>
137 lines
7.3 KiB
Text
137 lines
7.3 KiB
Text
= Added iss parameter to OAuth 2.0/OpenID Connect Authentication Response
|
|
|
|
RFC 9207 OAuth 2.0 Authorization Server Issuer Identification specification adds the parameter `iss` in the OAuth 2.0/OpenID Connect Authentication Response for realizing secure authorization responses.
|
|
|
|
In past releases, we did not have this parameter, but now {project_name} adds this parameter by default, as required by the specification.
|
|
|
|
However, some OpenID Connect / OAuth2 adapters, and especially older {project_name} adapters, may have issues with this new parameter.
|
|
|
|
For example, the parameter will be always present in the browser URL after successful authentication to the client application.
|
|
In these cases, it may be useful to disable adding the `iss` parameter to the authentication response. This can be done
|
|
for the particular client in the {project_name} Admin console, in client details in the section with `OpenID Connect Compatibility Modes`,
|
|
described in <<_compatibility_with_older_adapters>>. Dedicated `Exclude Issuer From Authentication Response` switch exists,
|
|
which can be turned on to prevent adding the `iss` parameter to the authentication response.
|
|
|
|
= Wildcard characters handling
|
|
|
|
JPA allows wildcards `%` and `_` when searching, while other providers like LDAP allow only `*`.
|
|
As `*` is a natural wildcard character in LDAP, it works in all places, while with JPA it only
|
|
worked at the beginning and the end of the search string. Starting with this release the only
|
|
wildcard character is `*` which work consistently across all providers in all places in the search
|
|
string. All special characters in a specific provider like `%` and `_` for JPA are escaped. For exact
|
|
search, with added quotes e.g. `"w*ord"`, the behavior remains the same as in previous releases.
|
|
|
|
= Language files for themes default to UTF-8 encoding
|
|
|
|
This release now follows the standard mechanisms of Java and later, which assumes resource bundle files to be encoded in UTF-8.
|
|
|
|
Previous versions of Keycloak supported specifying the encoding in the first line with a comment like `# encoding: UTF-8`, which is no longer supported and is ignored.
|
|
|
|
Message properties files for themes are now read in UTF-8 encoding, with an automatic fallback to ISO-8859-1 encoding.
|
|
If you are using a different encoding, convert the files to UTF-8.
|
|
|
|
= Changes to the value format of claims mapped by the realm and client role mappers
|
|
|
|
Before this release, both realm (`User Realm Role`) and client (`User Client Role`) protocol mappers
|
|
were mapping a stringfied JSON array when the `Multivalued` setting was disabled.
|
|
|
|
However, the `Multivalued` setting indicates whether the claim should be mapped as a list or, if disabled, only a single value
|
|
from the same list of values.
|
|
|
|
In this release, the role and client mappers now map to a single value from the effective roles of a user when
|
|
they are marked as single-valued (`Multivalued` disabled).
|
|
|
|
= Changes to password fields in Login UI
|
|
|
|
In this version we want to introduce a toggle to hide/show password inputs.
|
|
|
|
.Affected pages:
|
|
- login.ftl
|
|
- login-password.ftl
|
|
- login-update-password.ftl
|
|
- register.ftl
|
|
- register-user-profile.ftl
|
|
|
|
In general all `<input type="password" name="password" />` are encapsulated within a div now. The input element is followed by a button which toggles the visibility of the password input.
|
|
|
|
Old code example:
|
|
[source,html]
|
|
----
|
|
<input type="password" id="password" name="password" autocomplete="current-password" style="display:none;"/>
|
|
----
|
|
|
|
New code example:
|
|
[source,html]
|
|
----
|
|
<div class="${properties.kcInputGroup!}">
|
|
<input type="password" id="password" name="password" autocomplete="current-password" style="display:none;"/>
|
|
<button class="pf-c-button pf-m-control" type="button" aria-label="${msg('showPassword')}"
|
|
aria-controls="password" data-password-toggle
|
|
data-label-show="${msg('showPassword')}" data-label-hide="${msg('hidePassword')}">
|
|
<i class="fa fa-eye" aria-hidden="true"></i>
|
|
</button>
|
|
</div>
|
|
----
|
|
|
|
= Default Keycloak CR Hostname
|
|
|
|
When running on OpenShift, with ingress enabled, and with the spec.ingress.classname set to openshift-default, you may leave the spec.hostname.hostname unpopulated in the Keycloak CR.
|
|
The operator will assign a default hostname to the stored version of the CR similar to what would be created by an OpenShift Route without an explicit host - that is ingress-namespace.appsDomain
|
|
If the appsDomain changes, or should you need a different hostname for any reason, then update the Keycloak CR.
|
|
|
|
= The deprecated `auto-build` CLI option was removed
|
|
|
|
The `auto-build` CLI option has been marked as deprecated for a long time.
|
|
In this release, it was completely removed, and it is no longer supported.
|
|
|
|
When executing the `start` command, the server is automatically built based on the configuration.
|
|
In order to prevent this behavior, set the `--optimized` flag.
|
|
|
|
|
|
= kc.sh and shell metacharacters
|
|
|
|
The kc.sh no longer uses an additional shell eval on parameters and the environment variables JAVA_OPTS_APPEND and JAVA_ADD_OPENS, thus the continued use of double escaping/quoting will result in the parameter being misunderstood. For example instead of
|
|
|
|
```
|
|
bin/kc.sh start --db postgres --db-username keycloak --db-url "\"jdbc:postgresql://localhost:5432/keycloak?ssl=false&connectTimeout=30\"" --db-password keycloak --hostname localhost
|
|
```
|
|
|
|
Use a single escape:
|
|
|
|
```
|
|
bin/kc.sh start --db postgres --db-username keycloak --db-url "jdbc:postgresql://localhost:5432/keycloak?ssl=false&connectTimeout=30" --db-password keycloak --hostname localhost
|
|
```
|
|
|
|
= Removed RegistrationProfile form action
|
|
|
|
The form action `RegistrationProfile` (displayed in the UI of authentication flows as `Profile Validation`) was removed from the codebase and also from all authentication flows. By default, it was in
|
|
the built-in registration flow of every realm. The validation of user attributes as well as creation of the user including all that user's attributes is handled by `RegistrationUserCreation` form action and
|
|
hence `RegistrationProfile` is not needed anymore. There is usually no further action needed in relation to this change, unless you used `RegistrationProfile` class in your own providers.
|
|
|
|
= Deprecated methods from data providers and models
|
|
|
|
* `RealmModel#getTopLevelGroupsStream()` and overloaded methods are now deprecated
|
|
|
|
= `GroupProvider` changes
|
|
|
|
A new method has been added to allow for searching and paging through top level groups.
|
|
If you implement this interface you will need to implement the following method:
|
|
[source,java]
|
|
----
|
|
Stream<GroupModel> getTopLevelGroupsStream(RealmModel realm,
|
|
String search,
|
|
Boolean exact,
|
|
Integer firstResult,
|
|
Integer maxResults)
|
|
----
|
|
|
|
= `GroupRepresentation` changes
|
|
|
|
* new field `subGroupCount` added to inform client how many subgroups are on any given group
|
|
* `subGroups` list is now only populated on queries that request hierarchy data
|
|
* This field is populated from the "bottom up" so can't be relied on for getting all subgroups for a group. Use a `GroupProvider` or request the subgroups from `GET {keycloak server}/realms/{realm}/groups/{group_id}/children`
|
|
|
|
= New endpoint for Group Admin API
|
|
|
|
Endpoint `GET {keycloak server}/realms/{realm}/groups/{group_id}/children` added as a way to get subgroups of specific groups that support pagination
|
|
|