Keycloak

Форк
0
492 строки · 29.8 Кб
1
= Changes to the Welcome theme
2

3
The 'welcome' theme has has been updated to use a new layout and now uses PatternFly 5, rather than PatternFly 3. If you are extending the theme, or providing your own, you may need to update it as follows:
4

5
== Migrate from PatternFly 3 to PatternFly 5
6

7
The welcome theme was one of the more outdated themes in {project_name}. It was originally based on PatternFly 3, but has now been updated to use PatternFly 5, skipping a major version in the process. If your custom theme extends the built-in theme, you will need to update it to use PatternFly 5 syntax. Consult the https://www.patternfly.org/get-started/develop/[PatternFly 5 documentation] for details.
8

9
If you are still using PatternFly 3 in your own custom theme (not extending the built-in one), you can continue to use it, but PatternFly 3 support will be removed in a future release, so you should consider migrating to PatternFly 5 as soon as possible.
10

11
== Automatic redirect to the Admin Console
12

13
If the Admin Console is enabled, the welcome page will automatically redirect to it if the administrative user already exists. This behavior can be modified by setting the `redirectToAdmin` in your `theme.properties` file. By default, the property is set to `false`, unless you are extending the built-in theme, in which case, the property is set to `true`.
14

15
== The `documentationUrl` and `displayCommunityLinks` properties have been removed.
16

17
These properties were previously used for navigational elements that are now no longer present. If you are extending the built-in theme, you will need to remove these properties from your `theme.properties` file, as they no longer have any effect.
18

19
== Assets are now loaded from 'common' resources
20

21
Images such as the background, logo and favicon are now loaded from the 'common' resources, rather than the theme resources. This change means that if you are extending the built-in theme, and are overwriting these images, you will need to move them to the 'common' resources of your theme, and update your `theme.properties` file to include the new paths:
22

23
[source,properties]
24
----
25
# This defaults to 'common/keycloak' if not set.
26
import=common/your-theme-name
27
----
28

29
= Changes to the Account Console theme customization
30

31
If you were previously extending the now deprecated version 2 of the Account Console theme, you will need to update your theme to use the new version 3 of the Account Console theme. The new version of the Account Console theme comes with some changes in regards to how it is customized. To start with a clean slate, you can follow the new https://github.com/keycloak/keycloak-quickstarts/tree/release/24.0/extension/extend-account-console[customization quickstart].
32

33
To move your custom theme start by changing the `parent` to the new theme:
34

35
[source,properties]
36
----
37
# Before
38
parent=keycloak.v2
39

40
# After
41
parent=keycloak.v3
42
----
43

44
If you have any custom React components, you will import React directly, rather than using a relative path:
45

46
[source,js]
47
----
48
// Before
49
import * as React from "../../../../common/keycloak/web_modules/react.js";
50

51
// After
52
import React from "react";
53
----
54

55

56
If you are using `content.json` to customize the theme there are some changes to the structure of the file, specifically:
57

58
* The `content` property has been renamed to `children`.
59
* The `id`, `icon` and `componentName` properties have been removed, as `modulePath` provides the same functionality.
60

61
= Keycloak JS imports might need to be updated
62

63
If you are loading Keycloak JS directly from the {project_name} server, this section can be safely ignored. If you are loading Keycloak JS from the NPM package and are using a bundler like Webpack, Vite, and so on, you might need to make some changes to your code. The Keycloak JS package now uses the https://webpack.js.org/guides/package-exports/[`exports` field] in the package.json file. This means that you might have to change your imports:
64

65
[source,js]
66
----
67
// Before
68
import Keycloak from 'keycloak-js/dist/keycloak.js';
69
import AuthZ from 'keycloak-js/dist/keycloak-authz.js';
70

71
// After
72
import Keycloak from 'keycloak-js';
73
import AuthZ from 'keycloak-js/authz';
74
----
75

76
= Features Changes
77

78
It is no longer allowed to have the same feature in both the `--features` and `--features-disabled` list.  The feature should appear in only one list.
79

80
The usage of unversioned feature names, such as `docker`, in the `--features` list will allow for the most supported / latest feature version to be enabled for you. 
81
If you need more predictable behavior across releases, reference the particular version you want instead, such as `docker:v1`.
82

83
= User Profile Changes
84

85
== User profile enabled by default
86

87
The user profile feature is now enabled by default. The  `declarative-user-profile`feature is no longer available, because the user profile is assumed to be enabled.
88
Therefore, the *User Profile Enabled* switch is removed from the *Realm Settings* and replaced by *Unmanaged attributes*.
89
When migrating from previous version, the behavior is as follows:
90

91
* For the deployments where *User Profile Enabled* was set to *ON*, *Unmanaged attributes* will be set to *OFF* after the upgrade. As a result, only user attributes supported explicitly
92
by user profile will be allowed.
93

94
* For the deployments where the *User Profile Enabled* was set to *OFF* (which was also the default settings for the deployments with `declarative-user-profile` feature disabled, which was the default),
95
*Unmanaged attributes* will be set to *ON*` after the upgrade. As a result, the behavior should be basically the same as in previous versions with the user profile disabled. 
96
The *Attributes* tab will remain in the user details part of the Admin Console. Also users can now set arbitrary attributes through UI pages such as the registration page and update profile page  as long as 
97
a particular custom theme supports it. The custom themes should work as before as well. However, consider updating your themes to use the user-profile and
98
maybe even remove your custom themes if those themes were need to add custom attributes. See the subsequent section on themes. Also, consider toggling *Unmanaged attributes* to *OFF* or enable this switch only for
99
administrators so that you can rely on mainly on using managed attributes.
100

101
See the link:{adminguide_link}#user-profile[User Profile Documentation] for the details about the *Unmanaged attributes*.
102

103
== Default validations
104

105
Default user profile configuration comes with a set of default validations for the basic predefined fields. Those validations were not present in previous versions when the `declarative-user-profile` feature was disabled by default.
106
If you have issues due to backward compatibility, you can change the default validators according to your needs. The default validators are as follows:
107

108
* The`username`, `email`, `firstName` and `lastName` attributes have a maximum length of 255 characters. These validations were indirectly present in previous versions as well
109
because of the database constraint on the table `USER_ENTITY` for those fields with a maximum length of 255 characters. However, when using user storage providers, it might be possible before to use longer values.
110

111
* The `username` attribute has a minimum length of three characters. Username has also `username-prohibited-characters` and `up-username-not-idn-homograph` validator by default, which were not present in previous versions.
112
See the link:{adminguide_link}#user-profile[Validation section of the User Profile Documentation] for the details about those attributes. Note that username is not editable by default unless you have the realm switch `Edit username enabled`.
113
This change means that existing users with incorrect usernames should still work and they will not be enforced to update their usernames. But new users will be enforced to use correct usernames
114
during their registration or creation by the admin REST API.
115

116
* The `firstName` and `lastName` attributes have the `person-name-prohibited-characters` validator on them, which were not present in previous versions.
117
See the link:{adminguide_link}#user-profile[Validation section of the User Profile Documentation] for the details about those attributes. Note that both first
118
name and last name are editable by default, so users, who already have such incorrect first/last name from a previous version will be forced to update them when updating their user profiles.
119

120
== User attribute names with strange characters
121

122
In previous versions, you could create a user with attribute names such as `some:attribute` or `some/attribute`. The user profile intentionally does not allow you to create
123
attributes with such strange names in the user profile configuration. So you may need to configure `Unmanaged attributes` for your realm and enable unmanaged attributes for administrators
124
(ideally) or for end users (if really needed). Although it is strongly preferred to avoid using such attribute names.
125

126
== Verify Profile required action enabled by default
127

128
The `verify-profile` required action is enabled by default for new realms. However, when you migrate from a previous version, your existing realms will have the same state of this `verify-profile` action as before, which
129
usually means disabled as it was disabled by default in previous versions. For the details about this required action, see the link:{adminguide_link}#user-profile[User Profile Documentation].
130

131
== Breaking changes to the User Profile SPI
132

133
If you are using the User Profile SPI in your extension, you might be impacted by the API changes introduced in this release.
134

135
The `org.keycloak.userprofile.Attributes` interface includes the following changes:
136

137
* Method `getValues` was renamed to `get` to make it more aligned with the same operation from a regular Java `Map`
138
* Method `isRootAttribute` was moved to the utility class `org.keycloak.userprofile.UserProfileUtil.isRootAttribute`
139
* Method `getFirstValue` was renamed to `getFirst` to make it less verbose
140
* Method `getReadable(boolean)` was removed and now all attributes (including root attributes) are returned whenever they have read rights.
141

142
== Changes to Freemarker templates to render pages based on the user profile and realm
143

144
In this release, the following templates were updated to make it possible to dynamically render attributes based
145
on the user profile configuration set to a realm:
146

147
* `login-update-profile.ftl`
148
* `register.ftl`
149
* `update-email.ftl`
150

151
These templates are responsible for rendering the update profile (when the *Update Profile* required action is enabled for a user), 
152
the registration, and the update email (when the *UPDATE_EMAIL* feature is enabled) pages, respectively.
153

154
If you use a custom theme to change these templates, they will function as expected because only the content is updated.
155
However, we recommend you to take a look at how to configure a link:{adminguide_link}#user-profile[{declarative user profile}] and possibly avoid
156
changing the built-in templates by using all the capabilities provided by this feature.
157

158
Also, the templates used by the `declarative-user-profile` feature to render the pages for the same flows are longer necessary and removed in this release:
159

160
* `update-user-profile.ftl`
161
* `register-user-profile.ftl`
162

163
If you were using the `declarative-user-profile` feature in a previous release with customizations to the above templates,
164
update the `login-update-profile.ftl` and `register.ftl` accordingly.
165

166
== New Freemarker template for the update profile page at first login through a broker
167

168
In this release, the server will render the update profile page when the user is authenticating through a broker for the
169
first time using the `idp-review-user-profile.ftl` template.
170

171
In previous releases, the template used to update the profile during the first broker login flow was the `login-update-profile.ftl`, the same used
172
to update the profile when users are authenticating to a realm.
173

174
By using separate templates for each flow, a more clear distinction exist as to which flow a template is actually used rather than sharing a same template,
175
and potentially introduce unexpected changes and behavior that should only affect pages for a specific flow.
176

177
If you have customizations to the `login-update-profile.ftl` template to customize how users update their profiles when authenticating through a broker, make sure to move your changes
178
to the new template.
179

180
= Truststore Changes
181

182
The `spi-truststore-file-*` options and the truststore related options `https-trust-store-*` are deprecated. Therefore, use the new default location for truststore material, `conf/truststores`, or specify your desired paths by using the `truststore-paths` option. For details, see the relevant https://www.keycloak.org/server/keycloak-truststore[guide].
183

184
The `tls-hostname-verifier` property should be used instead of the `spi-truststore-file-hostname-verification-policy` property.
185

186
= Deprecated `--proxy` option
187

188
The `--proxy` option has been deprecated and will be removed in a future release. The following table explains how the deprecated option maps to supported options.
189

190
[%autowidth,cols="a,a"]
191
|===
192
| Deprecated usage | New usage
193

194
|`kc.sh` (no `proxy` option set)
195
|`kc.sh`
196
|`kc.sh --proxy none`
197
|`kc.sh`
198
|`kc.sh --proxy edge`
199
|`kc.sh --proxy-headers forwarded\|xforwarded --http-enabled true`
200
|`kc.sh --proxy passthrough`
201
|`kc.sh --hostname-port 80\|443` (depending if HTTPS is used)
202
|`kc.sh --proxy reencrypt`
203
|`kc.sh --proxy-headers forwarded\|xforwarded`
204
|===
205

206
NOTE: For hardened security, the `--proxy-headers` option does not allow selecting both `forwarded` and `xforwarded` values at the same time (as it was
207
the case before for `--proxy edge` and `--proxy reencrypt`).
208

209
WARNING: When using the proxy headers option, make sure your reverse proxy properly sets and overwrites the `Forwarded` or `X-Forwarded-*` headers respectively.
210
To set these headers, consult the documentation for your reverse proxy. Misconfiguration will leave {project_name} exposed to security vulnerabilities.
211

212
You can also set the proxy headers when using the Operator:
213
[source,yaml]
214
----
215
apiVersion: k8s.keycloak.org/v2alpha1
216
kind: Keycloak
217
metadata:
218
  name: example-kc
219
spec:
220
  ...
221
  proxy:
222
    headers: forwarded|xforwarded
223
----
224
NOTE: If the `proxy.headers` field is not specified, the Operator falls back to the previous behavior by implicitly setting
225
`proxy=passthrough` by default. This results in deprecation warnings in the server log. This fallback will be removed
226
in a future release.
227

228
= Changes to the user representation in both Admin API and Account contexts
229

230
Both `org.keycloak.representations.idm.UserRepresentation` and `org.keycloak.representations.account.UserRepresentation` representation classes have changed
231
so that the root user attributes (such as `username`, `email`, `firstName`, `lastName`, and `locale`) have a consistent representation when fetching or sending
232
the representation payload to the Admin and Account APIS, respectively.
233

234
The `username`, `email`, `firstName`, `lastName`, and `locale` attributes were moved to a new `org.keycloak.representations.idm.AbstractUserRepresentation` base class.
235

236
Also the `getAttributes` method is targeted for representing only custom attributes, so you should not expect any root attribute in the map returned by this method. This method is
237
mainly targeted for clients when updating or fetching any custom attribute for a give user.
238

239
In order to resolve all the attributes including the root attributes, a new `getRawAttributes` method was added so that the resulting map also includes the root attributes. However,
240
this method is not available from the representation payload and it is targeted to be used by the server when managing user profiles.
241

242
= `https-client-auth` is a build time option
243

244
Option `https-client-auth` had been treated as a run time option, however this is not supported by Quarkus. The option needs to be handled at build time instead.
245

246
= Sequential loading of offline sessions and remote sessions
247

248
Starting with this release, the first member of a {project_name} cluster will load remote sessions sequentially instead of in parallel.
249
If offline session preloading is enabled, those will be loaded sequentially as well.
250

251
The previous code led to high resource-consumption across the cluster at startup and was challenging to analyze in production environments and could lead to complex failure scenarios if a node was restarted during loading.
252
Therefore, it was changed to sequential session loading.
253

254
For offline sessions, the default in this and previous versions of {project_name} is to load those sessions on demand, which scales better with a lot of offline sessions than the attempt to preload them in parallel. Setups that use this default setup are not affected by the change of the loading strategy for offline sessions.
255
Setups that have offline session preloading enabled should migrate to a setup where offline-session preloading is disabled.
256

257
= Deprecated offline session preloading
258

259
The default behavior of {project_name} is to load offline sessions on demand.
260
The old behavior to preload them at startup is now deprecated, as preloading them at startup does not scale well with a growing number of sessions, and increases {project_name} memory usage.
261
The old behavior will be removed in a future release.
262

263
To re-enable old behavior while it is deprecated and not removed yet, use the feature flag and the SPI option as shown below:
264

265
[source,bash]
266
----
267
bin/kc.[sh|bat] start --features-enabled offline-session-preloading --spi-user-sessions-infinispan-preload-offline-sessions-from-database=true
268
----
269

270
The API of `UserSessionProvider` deprecated the method `getOfflineUserSessionByBrokerSessionId(RealmModel realm, String brokerSessionId)`.
271
Instead of this method, use `getOfflineUserSessionByBrokerUserIdStream(RealmModel, String brokerUserId)` to first get the sessions of a user, and then filter by the broker session ID as needed.
272

273
= Infinispan metrics use labels for cache manager and cache names
274

275
When enabling metrics for {project_name}'s embedded caches, the metrics now use labels for the cache manager and the cache names.
276

277
.Old metric example without labels
278
----
279
vendor_cache_manager_keycloak_cache_sessions_statistics_approximate_entries_in_memory{cache="sessions",node="..."}
280
----
281

282
.New metric example with labels
283
----
284
vendor_statistics_approximate_entries_in_memory{cache="sessions",cache_manager="keycloak",node="..."}
285
----
286

287
To revert the change for an installation, use a custom Infinispan XML configuration and change the configuration as follows:
288

289
----
290
<metrics names-as-tags="false" />
291
----
292

293
= User attribute value length extension
294

295
As of this release, {project_name} supports storing and searching by user attribute values longer than 255 characters, which was previously a limitation.
296

297
In setups where users are allowed to update attributes, for example, via the account console, prevent denial of service attacks by adding validations.
298
Ensure that no unmanaged attributes are allowed and all editable attributes have a validation that limits the input length.
299

300
For unmanaged attributes, the maximum length is 2048 characters.
301
For managed attributes, the default maximum length is 2048 characters. Administrator can change this by adding a validator of type `length`.
302

303
WARNING: {project_name} caches user-related objects in its internal caches.
304
Using longer attributes increases the memory that is consumed by the cache.
305
Therefore, limiting the size of the length attributes is recommended.
306
Consider storing large objects outside {project_name} and reference them by ID or URL.
307

308
This change adds new indexes on the tables `USER_ATTRIBUTE` and `FED_USER_ATTRIBUTE`.
309
If those tables contain more than 300000 entries, {project_name} will skip the index creation by default during the automatic schema migration and instead log the SQL statement on the console during migration to be applied manually after {project_name}'s startup.
310
See the link:{upgradingguide_link}[{upgradingguide_name}] for details on how to configure a different limit.
311

312
== Additional migration steps for LDAP
313

314
This is for installations that match all the following criteria:
315

316
* User attributes in the LDAP directory are larger than 2048 characters or binary attributes that are larger than 1500 bytes.
317
* The attributes are changed by admins or users via the admin console, the APIs or the account console.
318

319
To be able to enable changing those attributes via UI and REST APIs, perform the following steps:
320

321
. Declare the attributes identified above as managed attributes in the user profile of the realm.
322
. Define a `length` validator for each attribute added in the previous step specifying the desired minimum and maximum length of the attribute value.
323
For binary values, add 33 percent to the expected binary length to count in the overhead for {project_name}'s internal base64 encoding of binary values.
324

325
== Additional migration steps for custom user storage providers
326

327
This is for installations that match all the following criteria:
328

329
* Running MariaDB or MySQL as a database for {project_name}.
330
* Entries in table `FED_USER_ATTRIBUTE` with contents in the `VALUE` column that are larger than 2048 characters.
331
This table is used for custom user providers which have federation enabled.
332
* The long attributes are changed by admins or users via the admin console or the account console.
333

334
To be able to enable changing those attributes via UI and REST APIs,  perform the following steps:
335

336
. Declare the attributes identified above as managed attributes in the user profile of the realm.
337
. Define a `length` validator for each attribute added in the previous step specifying the desired minimum and maximum length of the attribute value.
338

339
= The Admin send-verify-email API now uses the same email verification template
340

341
----
342
PUT /admin/realms/{realm}/users/{id}/send-verify-email
343
----
344

345
In this release, the API will use the `email-verification.ftl` template instead of `executeActions.ftl`.
346

347
.Before upgrading
348
----
349
Perform the following action(s): Verify Email
350
----
351

352
.After upgrading
353
----
354
Confirm validity of e-mail address email@example.org.
355
----
356

357
If you have customized the `executeActions.ftl` template to modify how users verify their email using this API, ensure that you transfer your modifications to the new template.
358

359
A new parameter called `lifespan` will be introduced to allow overriding of the default lifespan value (12 hours).
360

361
If you prefer the previous behavior, use the `execute-actions-email` API as follows.
362

363
----
364
PUT /admin/realms/{realm}/users/{id}/execute-actions-email
365

366
["VERIFY_EMAIL"]
367
----
368

369
= Removal of the deprecated mode for SAML encryption
370

371
The compatibility mode for SAML encryption introduced in version 21 is now removed. The system property `keycloak.saml.deprecated.encryption` is not managed anymore by the server. The clients which still used the old signing key for encryption should update it from the new IDP configuration metadata.
372

373
= Changes to Password Hashing
374

375
In this release, we adapted the password hashing defaults to match the https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2[OWASP recommendations for Password Storage].
376

377
As part of this change, the default password hashing provider has changed from `pbkdf2-sha256` to `pbkdf2-sha512`.
378
Also, the number of default hash iterations for `pbkdf2` based password hashing algorithms changed as follows:
379
[%autowidth,cols="a,a,>a,>a"]
380
|===
381
| Provider ID | Algorithm | Old Iterations | New Iterations
382

383
| `pbkdf2`   | `PBKDF2WithHmacSHA1` | 20.000 | 1.300.000
384
| `pbkdf2-sha256` | `PBKDF2WithHmacSHA256` | 27.500 | 600.000
385
| `pbkdf2-sha512` | `PBKDF2WithHmacSHA512` | 30.000 | 210.000
386
|===
387

388
If a realm does not explicitly configure a password policy with `hashAlgorithm` and `hashIterations`, then
389
the new configuration will take effect on the next password based login, or when a user password is created or updated.
390

391
== Performance of new password hashing configuration
392

393
Tests on a machine with an Intel i9-8950HK CPU (12) @ 4.800GHz yielded the following &#8960; time differences for hashing 1000 passwords (averages from 3 runs).
394
Note that the average duration for the `PBKDF2WithHmacSHA1` was computed with a lower number of passwords due to the long runtime.
395
[%autowidth,cols="a,a,>a,>a,>a"]
396
|===
397
| Provider ID | Algorithm | Old duration | New duration | Difference
398

399
| `pbkdf2` | `PBKDF2WithHmacSHA1`   | 122ms | 3.114ms | +2.992ms
400
| `pbkdf2-sha256` | `PBKDF2WithHmacSHA256` |  20ms |   451ms |   +431ms
401
| `pbkdf2-sha512` | `PBKDF2WithHmacSHA512` |  33ms |   224ms |   +191ms
402
|===
403

404
Users of the `pbkdf2` provider might need to explicitly reduce the
405
number of hash iterations to regain acceptable performance.
406
This can be done by configuring the hash iterations explicitly in the password policy of the realm.
407

408
== Expected increased overall CPU usage and temporary increased database activity
409

410
The Concepts for sizing CPU and memory resources in the {project_name} High Availability guide have been updated to reflect the new hashing defaults.
411
While the CPU usage per password-based login in our tests increased by 33% (which includes both the changed password hashing and unchanged TLS connection handling), the overall CPU increase should be around 10% to 15%.
412
This is due to the averaging effect of {project_name}'s other activities like refreshing access tokens and client credential grants, still this depends on the unique workload of an installation.
413

414
After the upgrade, during a password-based login, the user's passwords will be re-hashed with the new hash algorithm and hash iterations as a one-off activity and updated in the database.
415
As this clears the user from {project_name}'s internal cache, you will also see an increased read activity on the database level.
416
This increased database activity will decrease over time as more and more user's passwords have been re-hashed.
417

418
== How to keep using the old pbkdf2-sha256 password hashing?
419

420
To keep the old password hashing for a realm, specify `hashAlgorithm` and `hashIterations` explicitly in the
421
realm password policy.
422

423
* `Hashing Algorithm: pbkdf2-sha256`
424
* `Hashing Iterations: 27500`
425

426
= Operator Referenced Resource Polling
427

428
Secrets and ConfigMaps referenced via the Keycloak CR will now be polled for changes, rather than watched via the api server. It may take around 1 minute for changes to be detected.
429

430
This was done so to not require label manipulation on those resources. After upgrading if any Secret still has the operator.keycloak.org/component label, it may be removed or ignored.
431

432
= Renaming JPA provider configuration options for migration
433

434
After removal of the Map Store the following configuration options were renamed:
435

436
* `spi-connections-jpa-legacy-initialize-empty` to `spi-connections-jpa-quarkus-initialize-empty`
437
* `spi-connections-jpa-legacy-migration-export` to `spi-connections-jpa-quarkus-migration-export`
438
* `spi-connections-jpa-legacy-migration-strategy` to `spi-connections-jpa-quarkus-migration-strategy`
439

440
= Renaming model modules
441

442
After removal of the Map Store the following modules were renamed:
443

444
* `org.keycloak:keycloak-model-legacy-private` to `org.keycloak:keycloak-model-storage-private`
445
* `org.keycloak:keycloak-model-legacy-services` to `org.keycloak:keycloak-model-storage-services`
446

447
and `org.keycloak:keycloak-model-legacy` module was deprecated and will be removed in the next release in favour of `org.keycloak:keycloak-model-storage` module.
448

449
= Temporary lockout log replaced with event
450

451
There is now a new event `USER_DISABLED_BY_TEMPORARY_LOCKOUT` when a user is temporarily locked out by the brute force protector.
452
The log with ID `KC-SERVICES0053` has been removed as the new event offers the information in a structured form.
453

454
As it is a success event, the new event is logged by default at the `DEBUG` level.
455
Use the setting `spi-events-listener-jboss-logging-success-level` as described in the link:{adminguide_eventlistener_link}[{adminguide_eventlistener_name} chapter in the {adminguide_name}] to change the log level of all success events.
456

457
To trigger custom actions or custom log entries, write a custom event listener as described in the Event Listener SPI in the link:{developerguide_link}[{developerguide_name}].
458

459
= Operator Customization Property Keys
460

461
The property keys used by the operator for advanced configuration have changed from `operator.keycloak` to `kc.operator.keycloak`.
462

463
= Keycloak CR resources options
464

465
When no `resources` options are specified in the Keycloak CR and KeycloakRealmImport CR, default values are used.
466
The default `requests` memory for Keycloak deployment and the realm import Job is set to `1700MiB`, and the `limits` memory is set to `2GiB`.
467

468
= Updates to cookies
469

470
As part of refactoring cookie handling in {project_name} there are some changes to how cookies are set:
471

472
* All cookies will now have the secure attribute set if the request is through a secure context
473
* `WELCOME_STATE_CHECKER` cookies now set `SameSite=Strict`
474

475
For custom extensions there may be some changes needed:
476

477
* `LocaleSelectorProvider.KEYCLOAK_LOCALE` is deprecated as cookies are now managed through the CookieProvider
478
* `HttpResponse.setWriteCookiesOnTransactionComplete` has been removed
479
* `HttpCookie` is deprecated, please use `NewCookie.Builder` instead
480
* `ServerCookie` is deprecated, please use `NewCookie.Builder` instead
481

482
= Internal algorithm changed from HS256 to HS512
483

484
The algorithm that {project_name} uses to sign internal tokens (a JWT which is consumed by {project_name} itself, for example a refresh or action token) is being changed from `HS256` to the more secure `HS512`. A new key provider named `hmac-generated-hs512` is now added for realms. Note that in migrated realms the old `hmac-generated` provider and the old `HS256` key are maintained and still validate tokens issued before the upgrade. The `HS256` provider can be manually deleted when no more old tokens exist following the {adminguide_link}#rotating-keys[rotating keys guidelines].
485

486
ifeval::[{project_community}==true]
487
= GELF log handler has been deprecated
488

489
With sunsetting of the https://github.com/mp911de/logstash-gelf[underlying library] providing integration
490
with GELF, {project_name} will no longer support the GELF log handler out-of-the-box. This feature will be removed in a future
491
release. If you require an external log management, consider using file log parsing.
492
endif::[]

Использование cookies

Мы используем файлы cookie в соответствии с Политикой конфиденциальности и Политикой использования cookies.

Нажимая кнопку «Принимаю», Вы даете АО «СберТех» согласие на обработку Ваших персональных данных в целях совершенствования нашего веб-сайта и Сервиса GitVerse, а также повышения удобства их использования.

Запретить использование cookies Вы можете самостоятельно в настройках Вашего браузера.