Keycloak

Форк
0
95 строк · 5.8 Кб
1
= OpenID Connect and SAML Adapters End-of-life
2

3
Some Keycloak OpenID Connect adapters have reached end-of-life and are not included in this release.
4

5
== Fuse 6 and 7 (OpenID Connect)
6

7
Keycloak will no longer be providing adapters for Fuse 6 or 7. If you need adapters for Fuse please leverage https://access.redhat.com/products/red-hat-single-sign-on/[Red Hat Single Sign-On] 7.x adapters.
8

9
== JBoss AS 7 and EAP 6 (OpenID Connect and SAML)
10

11
JBoss AS 7 has been unmaintained for a very long time. If you are still using JBoss AS 7 we recommend migrating to WildFly and leveraging the native OIDC support in WildFly.
12

13
Red Hat customers using Red Hat JBoss Enterprise Application Platform 6.x should use https://access.redhat.com/products/red-hat-single-sign-on/[Red Hat Single Sign-On] 7.x adapters. These can be used in combination with the Keycloak server.
14

15
== Jetty 9.2 and 9.3 (OpenID Connect and SAML)
16

17
Jetty 9.2 reached end of life in 2018, while Jetty 9.3 reached end of life in 2020. If you are still using these versions we recommend upgrading to Jetty 9.4 as soon as possible.
18

19
== Spring Boot 1 (OpenID Connect)
20

21
Spring Boot 1.x reached end of life in 2019. If you are still using Spring Boot 1 we recommend upgrading to Spring Boot 2 as soon as possible.
22

23
== WildFly legacy security layer (OpenID Connect and SAML)
24

25
In WildFly 25 the legacy security layer was removed, going forward only Elytron will be supported. We recommend anyone using an older version of WildFly to upgrade and leverage native OIDC support in WildFly.
26

27
Red Hat customers using Red Hat JBoss Enterprise Application Platform 7.x should use https://access.redhat.com/products/red-hat-single-sign-on/[Red Hat Single Sign-On] 7.x adapters. These can be used in combination with the Keycloak server.
28

29
= New Admin Console graduation
30

31
The new Admin Console is now graduated to the default admin console, with the old console now deprecated. The old console will be removed in Keycloak 21.
32

33
= Changes in Keycloak storage
34

35
The Keycloak storage is changing, and the current storage, while still supported, will eventually be replaced with a brand-new implementation.
36
This change brings better support for cloud-native storages, no-downtime abilities, and better support for implementing custom storages for additional areas apart from users.
37

38
It means several deep changes in the supported features of the current store will become _legacy_ features.
39
The legacy store and the new store cannot be used simultaneously; only one store can be active at a time.
40

41
The most visible change is that the User Storage SPI is incompatible with the new storage API, the Map Storage API.
42
Thus, the User Storage SPI will be deprecated with legacy store and will move to a separate module called `keycloak-model-legacy`.
43
This change impacts several areas, especially areas related to user federation and custom user providers.
44

45
Furthermore, APIs have been consolidated so that the details of the storage layer will be transparent to the REST service layer.
46
Specifically, the services will not be able to differentiate cached and non-cached objects, nor specifically access federated versus local storage.
47

48
Hence, custom extensions that access objects in local storage or cache through `KeycloakSession`
49
methods must be reviewed.
50
See link:{upgradingguide_link}[{upgradingguide_name}] for details.
51

52
= OIDC Logout changes
53

54
In the previous release, we added support for OIDC logout. This release contains a few other fixes and polishing. The  highlights include:
55

56
- Support for the `client_id` parameter, which was added in recent draft of the OIDC RP-Initiated Logout specification. As a result, no need exists to use the `Consent Required` flag of the
57
client to show the logout confirmation screen.
58
- Configuration option `Valid Post Logout Redirect URIs` added to the OIDC client. This change is aligned with the OIDC specification, which allows you to use a different set of redirect URIs for redirect after login and logout.
59
Value `+` used for `Valid Post Logout Redirect URIs` means that the logout will use the same set of redirect URIs as specified by the option of `Valid Redirect URIs`. This change also matches the default behavior when migrating
60
from a previous version due to backwards compatibility.
61

62
For more details, see the link:{adminguide_link}#_oidc-logout[{adminguide_name}].
63

64
= Update Email Workflow
65

66
There is new preview feature `UPDATE_EMAIL`. When it is enabled and corresponding flag enabled in the realm, the users will be required
67
to confirm updating their email by clicking the link, which will be sent to their new email address. For more details, see the link:{adminguide_link}#_update-email-workflow[{adminguide_name}].
68
Thanks to https://github.com/reda-alaoui[Réda Housni Alaoui] for the contribution.
69

70
= Deprecated `podDisruptionBudget` in the legacy {project_operator}
71

72
With this release, we have deprecated `podDisruptionBudget` field in the Keycloak CR of the https://github.com/keycloak/keycloak-operator[legacy {project_operator}].
73
This optional field will be ignored when the Operator is deployed on Kubernetes version 1.25 and higher.
74

75
As a workaround, you can manually create the Pod Disruption Budget in your cluster, for example:
76
```yaml
77
apiVersion: policy/v1
78
kind: PodDisruptionBudget
79
metadata:
80
  labels:
81
    app: keycloak
82
  name: keycloak
83
spec:
84
  maxUnavailable: 1
85
  selector:
86
    matchLabels:
87
      component: keycloak
88
```
89
See also the https://kubernetes.io/docs/tasks/run-application/configure-pdb/[Kubernetes Documentation].
90

91
= Initial Support for centralized logging
92

93
Starting with version 19, Keycloak supports sending logs using GELF to centralized logging solutions like ELK, EFK or Graylog out of the box.
94

95
You can find the documentation and examples to get you up and running quickly in the https://www.keycloak.org/server/logging#_centralized_logging_using_gelf[logging] {section}.
96

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

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

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

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