Release Notes

KeycloakのデフォルトのディストリビューションはQuarkusをベースとするようになりました。新しいディストリビューションは、より速く、よりスリムで、より簡単に設定できます！

WildFlyディストリビューションからの移行は、Keycloakの起動と設定方法が根本的に変わっているため、すべての人にとって簡単なことではないことを理解しています。このことを念頭に置いて、私たちは2022年6月までWildFlyディストリビューションのサポートを継続します。

新しいディストリビューションへの移行方法については、 Quarkus Migration Guide を参照してください。

Quarkusディストリビューションは、可能な限り良い体験となるよう、多くの努力によって磨き上げられ、改善されました。そのハイライトは以下の通りです。

Keycloakサーバーは、基盤となるコンテナーとしてWildfly 26.0.0.Finalを使用するようにアップグレードされました。

WildFly 26の詳細については、 WildFly 26 リリースノート を参照してください。

Keycloakサーバーは、基盤となるコンテナーとしてWildfly 25.0.1.Finalを使用するようにアップグレードされました。

WildFly 25はレガシー・セキュリティー・サブシステムのサポートを終了し、Elytronに完全に置き換わります。このため、Keycloakの設定方法を大幅に変更する必要があります。詳細については、移行ガイドを参照してください。

WildFly 25の詳細については、 WildFly 25 リリースノート を参照してください。

Keycloak.X Quarkusプレビュー・ディストリビューションはQuarkus 2.5.3にアップグレードされました。

今回のリリースの最大のハイライトは、Quarkusディストリビューションに施されたすべての改善です。実際には非常に多くの改良点があり、すべてを列挙するのは難しいでしょう。

CLIは徹底的に改良され、Keycloakの設定と実行に非常にシンプルで便利なアプローチを提供するようになったと信じています。それは、ほとんどドキュメントが必要ないほどシンプルです。

まず、配布物を解凍し、bin/kc.[sh|bat] -h と入力すれば、素晴らしいものを発見することができます。

Keycloakの設定に関するドキュメントを提供する予定がないわけではありませんが、今回はまだ実現できていません。ドキュメントがないため、リリース後にQuarkusディストリビューションへのすべての変更とその使用方法の概要を紹介するブログ投稿を予定しています。

私たちはQuarkusディストリビューションをデフォルトのディストリビューションとする方向で急速に進んでおり、WildFlyディストリビューションはまもなく廃止される予定です。このことを念頭に置いて、できるだけ多くの人がQuarkusを試用し、使い勝手の問題や設定できないこと、バグを発見した場合などにフィードバックを提供することが重要です。

ぜひ、 GitHub Discussions でご意見をお聞かせください!

新しい管理コンソールはとてもよくできていて、プレビュー版がメインのディストリビューションに含まれています。まだ機能は完全ではありませんが、試せることはたくさんあります。

WildFly 23からWildFly 25へのアップグレードは、私たちが望むよりもずっと長い時間がかかりました。しかし、Quarkusディストリビューションへのアップデートを提供したかったので、このリリースはその間に行います。

WildFly 25では、Keycloakアダプターを必要としない優れたネイティブのOpenID Connectサポートがあります。このことを考慮して、WildFlyアダプターを非推奨とし、WildFly 25をサポートしませんが、古いWildFlyバージョンやRed Hat JBoss Enterprise Application Platform 7.yではしばらくの間存続させる予定です。

Spring Security 5.0で、OAuth 2.0とOpenID ConnectがSpringでネイティブサポートされるようになってからだいぶ経ちました。これを受けて、Spring BootとSecurityのアダプターを非推奨にする時期が来ました。

Keycloakは OpenID Connect Front-Channel Logout 1.0 をサポートしました。

詳しくは、 Server Administration Guide を参照してください。

Ronaldo Yamada のコントリビューションに感謝します。

本リリースでは、Keycloak Operatorの機能の一部を非推奨とし、サポート対象外としました。これは、Backup CRDとオペレーター管理のPostgres Databaseに関するものです。詳細については、 Server Installation and Configuration Guideの関連する章を参照してください。

Keycloakサーバーでは、Financial-grade API（FAPI）のサポートが改善されました。具体的には、KeycloakはFAPI CIBAとOpenBanking Brasilに準拠するようになりました。また、CIBAのpingモードにも対応しています。FAPI CIBAのほとんどの作業を行い、Keycloakプロジェクトのために本当に素晴らしい仕事をし続けてくれている Takashi Norimatsu に感謝します。また、 Dmytro Mishchuk 、 Andrii Murashkin 、 Hryhorii Hevorkian 、 Leandro José de Bortoli にも感謝します。彼らは同様にFAPIのコンプライアンスについて多大な働きかけをしてくれたのです。最後に、 FAPI Special interest group のすべてのメンバーの支援とフィードバックに感謝します。

Keycloakサーバーは、クライアント・ポリシーとFinancial-grade API（FAPI）を公式にサポートするようになりました。この機能は以前のバージョンでプレビューされていましたが、現在はより洗練され、適切に文書化されています。これに関するほとんどの作業を行ってくれた Takashi Norimatsu に感謝します。また、 Dmytro Mishchuk 、 Andrii Murashkin 、 Hryhorii Hevorkian にも感謝します。彼らは、この機能についても多くの作業を行いました。最後に、 FAPI Special interest group のすべてのメンバーの支援とフィードバックに感謝します。

このバージョンでは、Keycloakでユーザー・プロフィールを管理する方法の基礎を準備するために、ユーザー・プロフィールSPIにいくつかの改善が加えられました。

これらの改善の1つは、管理コンソールを介したユーザー・プロフィールの設定のサポートです。詳細については、 Server Administration Guide を参照してください。

コミュニティーとこの取り組みに携わったすべての方に感謝します。

オフライン・セッションの事前ロードが改善され、 Peter Flintholm のおかげでより高速になるはずです。

プレビュー機能として、 Thomas Darimont の取り組みのおかげで、オフライン・セッションの事前ロードをスキップして遅延ロードを行うことができます。この機能は、サーバー設定で明示的にアクティブ化する必要があります。詳細については、サーバー管理ガイドを参照してください。

Keycloakサーバーは、基盤となるコンテナーとしてWildfly 23.0.2.Finalを使用するようにアップグレードされました。

OAuth 2.0デバイス認可グラントのサポートが利用可能になりました。

Hiroyuki Wada 、 Łukasz Dywicki 、 Michito Okai に感謝します。

OpenID Connect Client Initiated Backchannel Authentication （CIBA）のサポートが利用可能になりました。

Takashi Norimatsu 、 Andrii Murashkin 、 Christophe Lannoy およびFAPI WGのメンバーによる実装とフィードバックに感謝します。

Keycloakは、SAML Artifact バインディングを使用したクライアントとの通信をサポートするようになりました。新しい Force Artifact Binding オプションがクライアントの設定に導入され、アーティファクト・メッセージを使用してクライアントとの通信を強制します。詳細については、 Server Administration Guide に進んでください。このバージョンでは、Keycloak SAMLクライアント・アダプターはアーティファクト・バインディングをサポートしていないことに注意してください。

AlistairDoswald と hartureに感謝します。

Keycloakは、外部のOpenID ConnectのIdPにブローカリングするときにPKCEを活用できるようになりました。

thomasdarimont に感謝します。

デフォルトロールが、通常は default-roles-<realmName> という名前の新しいロールの複合ロールとして内部的に保存されるようになりました。レルムとすべてのクライアントのデフォルトロールの両方を、新しく作成されたユーザーまたはアイデンティティー・ブローカリングを介してインポートされたユーザーに直接割り当てる代わりに、ロールだけが割り当てられ、残りのデフォルトロールは有効なロールとして割り当てられます。この変更により、すべてのクライアントを通過する必要がなくなるため、特に多数のクライアントでのデフォルトロールの処理のパフォーマンスが向上します。

新規および今後のKeycloak.Xディストリビューションがプレビュー機能として導入されました。このディストリビューションはQuarkusを利用しており、起動時間とメモリ消費量が大幅に改善されるだけでなく、Keycloakの設定がはるかに簡単になります。

新しいアカウント・コンソールはプレビュー機能ではなくなり、Keycloakのデフォルトのアカウントコンソールになりました。古いアカウント・コンソールはしばらくの間残ります。古いアカウントコンソール用のカスタムテーマがある場合は、デフォルトで古いコンソールが使用されるため、すぐにカスタムテーマを新しいアカウントコンソールに更新する必要はありません。

DaSmoo と benjamin37 のおかげで、OpenID Connect Back-Channel Logoutが利用可能になりました。

Keycloakサーバーは、基盤となるコンテナーとしてWildfly 21を使用するようにアップグレードされました。

SAMLアイデンティティー・プロバイダーによって発行される認証リクエストにおけるAuthnContextセクションの指定がサポートされました。

lscorcia に感謝します。

Financial-grade API Read and Write API Security Profile（FAPI RW）をサポートするために行われた作業がたくさんありました。これはクライアント・ポリシーの使用で利用可能であり、まだプレビュー状態です。次のリリースでは、さらに磨きをかけることが期待できます。 Takashi Norimatsu と FAPI Special interest group のすべてのメンバーに感謝します。

Keycloakログイン・テーマ・コンポーネントがPatternFly 4にアップグレードされました。古いPatternFly 3は新しいものと同時に実行されるため、そこにPF3コンポーネントを含めることができます。

ユーザー・エクスペリエンスを向上させるために、ログインテーマのデザインも変更されています。カスタム・アイデンティティー・プロバイダーのアイコンを定義することもできます。詳細については、 ドキュメント を参照してください。

Gatekeeperは11月21日にサポートが終了しました。これは、サポートまたは更新を終了したことを意味します。発表は このページ で参照できます。

LDAPv3パスワード変更操作のサポートが追加されました。また、設定されたLDAPサーバーからメタデータを要求して、LDAPv3パスワード変更操作をサポートしているかどうかを確認する管理コンソールの機能も追加されました。

cachescrubber に感謝します。

LDAPグループマッパーのネームスペースのサポートにより、Keycloakグループツリーの指定されたブランチ（ネームスペース）の下のLDAPからグループをマップできます。以前は、LDAPのグループは常にKeycloakの最上位グループとして追加されていました。

Torsten Juergeleit に感謝します。

Keycloakサーバーは、WildFly 20.0.1.Finalを使用するようにアップグレードされました。詳細については、 Upgrading Guide を参照してください。

Keycloak SAMLアダプターが正しく動作するには、 JSESSIONID Cookieの SameSite 値を None にする必要があります。SAML POSTバインディングが使用されている場合、異なる値を使用すると、Keycloakへのリクエストごとにコンテナーのセッションがリセットされます。正しい動作を維持するように Wildfly と Tomcat については、次の手順を参照してください。この回避策は、以前のバージョンのアダプターでも機能するはずであることに注意してください。

アイデンティティー・ブローカリング同期モードにより、ユーザー・プロファイルを最初のログイン時に更新するか、外部のアイデンティティー・プロバイダーからのすべてのログイン時に更新するかを制御できるようになりました。個々のマッパーでこの動作をオーバーライドすることもできます。

Martin Idel のコントリビューションに感謝します。

通常、SSOセッションは数ヶ月ではないにしても数日間続きますが、個々のクライアント・セッションは理想的にはもっと短いはずです。クライアント・セッションタイムアウトの導入により、レルム内のすべてのクライアントのデフォルトだけでなく、個々のクライアントに個別のタイムアウトを設定できるようになりました。

Yoshiyuki Tabata のコントリビューションに感謝します。

KeycloakをOAuth 2.0認可サーバーとして使用するアプリケーションの場合に、トークン無効化エンドポイントを介してリフレッシュトークンを無効化することがサポートされました。

Yoshiyuki Tabata のコントリビューションに感謝します。

レスポンスにセキュリティー関連のヘッダーを設定するときに柔軟性を高めるため、新しいSPIが導入されました。これにより、Keycloak内の実装がよりクリーンになりますが、必要に応じて完全にカスタマイズすることもできます。セキュリティー・ヘッダーは、コード自体ではなくレスポンス・フィルターによって設定されるようになりました。これにより、エラーが発生しにくくなり、一部のレスポンスでヘッダーが欠落する可能性がなくなります。

Keycloakサーバーは内部でWildFly 19を使用するようにアップグレードされました。

promiseTypeのinitオプションがJavaScriptアダプターから削除されました。代わりに、ネイティブPromise APIとレガシーKeycloak Promise APIの両方をサポートするPromiseが返されます。これにより、レガシー/非推奨のAPIからネイティブのPromise APIへのアプリケーションの段階的な移行が可能になります。

9.0.0では、LocaleSelectorSPIに重大なAPI変更が導入されました。9.0.1では、このAPIへの変更が元に戻され、新しいLocaleUpdatorSPIが導入されました。

以前のリリースでは、Spring Bootアプリケーションは手動で KeycloakConfigResolver インターフェイスを実装するか、組み込みの org.keycloak.adapters.springboot.KeycloakSpringBootConfigResolver を拡張する必要がありました。

このリリースでは、何も提供されない場合にインスタンスを自動的に解決することにより、下位互換性の問題が修正されています。さらに、アプリケーションが独自の設定リゾルバーの実装を提供できるようにします。

Droolsポリシーは非推奨期間の後に最終的に削除されました。より複雑なポリシーが必要な場合は、JavaScriptベースのポリシーが使用できます。

管理コンソールとREST APIで、ページ分割のサポートがクライアントに追加されました。 saibot94 に感謝します。

キーストアでサポートされているElytronクレデンシャル・ストアからシークレットを読み取る新しい組み込みのボールト・プロバイダーが、WildFly拡張機能として追加されました。クレデンシャル・ストアの作成と管理は、 elytron サブシステムまたは elytron-tool.sh スクリプトを使用してElytronによって処理されます。

このリリースでは、認証フローの使いやすさが改善されました。エンドユーザーは、2要素認証に使用できる認証メカニズムを簡単に選択できます。ユーザーがより多くのOTPまたはWebAuthnクレデンシャルを持つことができるという事実を考慮し、OTPまたはWebAuthnでログインする方が直感的であるはずです。パスワードレスのWebAuthn認証のサポートも改善されました。最後に、認証フローに関連する欠陥についていくつかの作業を行いました。

ログインページのロケールが選択される方法、およびユーザーのロケールが更新されるタイミングに多くの改良が加えられました。

詳細については、 Server Administration Guide を参照してください。

バージョン80以降、Google Chromeは SameSite Cookieパラメータ－のデフォルト値を Lax に変更します。したがって、 SameSite パラメーターを None に設定するために、いくつかのKeycloak Cookie（特にJavaScriptアダプター内でiframeを使用してセッション・ステータスをチェックするために使用されるCookie）を変更する必要がありました。この設定では Secure パラメーターも設定する必要があることに注意してください。このバージョン以降、JavaScriptアダプターはKeycloak側でSSL / TLS接続を使用する場合にのみ完全に機能します。

このリリースではKeycloak 7からのLDAPにおける致命的な脆弱性を修正しました。Keycloak 7.0.0、もしくは7.0.1、8.0.0をプロダクション環境で利用している場合は、すぐにアップグレードすることを強く推奨します。

WildFly 18.0.1.Finalにアップグレードしました。これにはサードパーティー・ライブラリーにおけるいくつかのCVEに対する更新が含まれています。

いくつかの設定フィールドは、LDAPバインド・パスワード、SMTPパスワード、およびアイデンティティー・プロバイダー・シークレットの値を直接入力する代わりに、ボールトから値を取得できます。

さらに、カスタム・ボールトからシークレットにアクセスするための拡張機能の開発を可能にする新しいボールトSPIが導入されました。

固定ホスト名プロバイダーとリクエストホスト名プロバイダーは、単一の新しいデフォルト・ホスト名プロバイダーに置き換えられました。このプロバイダーには、次のような多くの改善点があります。

テーマリソースのメッセージ・バンドルにより、オーセンティケーターなどのカスタム・プロバイダーの国際化が可能になります。また、すべてのテーマタイプ間で共有されるため、たとえばログイン・コンソールとアカウント・コンソール間でメッセージを共有できます。 micedre に感謝します。

SAMLアサーションから抽出されたロールをSPアプリケーション環境に存在するロールにマッピングするために、SAMLアダプターによって使用されるカスタム・ロールマッパーの設定を可能にする新しいSPIを追加しました。これは、アダプターがサードパーティーのIDPと通信する必要があり、アサーションでIDPによって設定されたロールがSPアプリケーションに対して定義されたロールに対応していない場合に特に役立ちます。使用するプロバイダーは、 keycloak-saml.xml ファイルまたは keycloak-saml サブシステムで設定できます。プロパティー・ファイルの内容に基づいてロールマッピングを実行する実装も提供されました。

KeycloakがIDPとして機能する場合、ロールをアサーションに設定する前に、組み込みのロールマッパーを使用して必要なマッピングを実行できるため、この場合、このSPIはおそらく冗長になることに注意してください。 RoleMappingsProvider SPIは、IDPがロールをアサーションに追加する前にマップする方法を提供しない状況のために設計されました。

Keycloakサーバーは内部でWildFly 18を使用するようにアップグレードされました。

このリリースでは、W3C Web Authentication（WebAuthn）の初期サポートを追加しました。現在の実装にはいくつかの制限がありますが、この領域のさらなる改善に取り組んでいます。 tnorimat の貢献に感謝します。また、 ynojima のご協力とフィードバックにも感謝します。

W3C Web Authenticationサポートの登場により、認証フローシステムを改良し、ユーザーがログインに適した認証方法の選択（たとえば、OTPクレデンシャルとWebAuthnクレデンシャルの選択）ができるようにしました。新しいメカニズムにより、管理者はパスワードレス・ログインのフローを作成することもできます。たとえば、認証方法としてWebAuthnを使用するだけです。これらの変更により、場合によっては作成したカスタム認証フローを新しい制御ロジックに適合させる必要があることに注意してください。

これらの変更の結果、ユーザーは複数のOTPデバイスと複数のWebAuthnデバイスを使用できるようになりました。ユーザーがログイン時に使用するデバイスのタイプを選択できるようにする同じシステムでは、ユーザーが使用する特定のデバイスを選択することもできます。 Cloudtrust チーム： AlistairDoswald 、 sispeo 、 Fratt の貢献、および harture 、 Laurent の協力に感謝します。

theme.propertiesファイル内でシステム・プロパティーと環境変数を使用できるようになりました。 Opa- に感謝します。

tnorimat の貢献により、署名付きJWTを使用したクライアント認証用の署名アルゴリズムをサポートしました。

このリリースでは、署名付きJWTまたはBASIC認証でOIDCプロバイダーを認証できる機能が追加されました。そのため、 OIDC仕様 に記載されているすべてのクライアント認証方式がサポートされるようになりました。貢献してくれた madgaet と rradillen に感謝します。

jonkoops の貢献により、JSアダプターのロギングを有効または無効にできるようになりました。

JavaScriptアダプターでクライアント・クレデンシャルを提供するオプションが削除されました。 jonkoops に感謝します。

特定の動作をカスタマイズするためにスクリプトをデプロイおよび実行する方法の詳細については、 7.0.1 Release Notes を参照してください。

Keycloakサーバーは内部でWildFly 17を使用するようにアップグレードされました。

Apache Tomcat 8とApache Tomcat 9のJavaアダプターは統合され、現在は両方に対応しています。

新しいアカウント・コンソールとアカウントREST APIに対して多くの改良が行われました。まだ準備は完了していませんが、それが実現しつつあり、うまくいけば、Keycloak 8で完了します。

Keycloakは、JSON Web Encryption（JWE）の仕様に従って署名および暗号化されたIDトークンをサポートできます。 tnorimat に感謝します。

Keycloakチームは、KeycloakとRed Hat Single Sign-Onの両方のテストとリリースに関する自動化にかなりの時間を費やしました。

Keycloakは、標準的な正常性とメトリクスのエンドポイントを提供するSmallRye HealthとSmallRye Metricsの拡張機能が有効になりました。Keycloak固有のメトリクスと同様にいくつかのドキュメントを間もなく追加します。

UMA 2.0が認可サービスでサポートされるようになりました。以前のバージョンのKeycloakからアップグレードしている場合は、ドキュメントの詳細を確認してください。

クライアント・アプリケーションは、任意のクレームに基づいてパーミッションを評価するために、認可リクエストとともにKeycloakにそれらのクレームを送信できるようになりました。これは、特定のトランザクションの範囲内で、またはランタイムに関する情報に基づいてアクセスを許可（または拒否）する必要がある場合に、非常に便利です。

Keycloakで保護されているリソースに属性を関連付け、これらの属性を使用してポリシーのパーミッションを評価することが可能になりました。

場合によっては、通常のアクセストークンをリソースサーバーに送信するだけで、これらのリソースに対してポリシーを適用することができます。

このリリースで導入された主な変更の1つは、（UMAを使用しない場合）リソースサーバーによって保護されたリソースにアクセスするために、アクセストークンをRPTと交換する必要がなくなったことです。ポリシー・エンフォーサーがリソースサーバー側でどのように設定されているかに応じて、通常のアクセストークンをベアラートークンとして送信するだけで、パーミッションは引き続き適用されます。

今のところ、 policy-enforcer で設定されたアプリケーションをデプロイするときに、ポリシー・エンフォーサーはサーバーからすべてのプロテクトされたパスをロードするか、またはアダプター設定から取得したこれらのパスをマップするだけです。ユーザーは、サーバーからオンデマンドでパスをロードし、アダプター設定でこれらのリソースをマップすることを避けることができます。保護されたリソースの数に応じて、この機能を使用すると、アプリケーションのデプロイメント時間を短縮することもできます。

サーバーへの不必要なヒットを避けるために、ポリシー・エンフォーサーは、保護されたリソースとアプリケーション内の対応するパスとの間のマッピングをキャッシュします。ユーザーはキャッシュの動作を設定したり、完全に無効にすることもできます。

アダプターの policy-enforcer 定義（ keycloak.json ）もプッシュされたクレームの概念をサポートするように更新されました。ここには、クレーム情報ポイントという概念があります。このクレーム情報ポイントには、HTTPリクエストや外部HTTPサービスなど、さまざまなソースからクレームをプッシュするように設定できます。

Keycloak（特にJavaScriptとDroolsポリシー）でポリシーを実装するために使用されるEvaluation APIは、以下のメソッドを提供します。

ユーザーがアカウント管理コンソールを介してユーザーアクセスを管理できるようにするなど、UMA 2.0が認可サービスでサポートされるようになりました。認可サービスには、他にも追加や改良があります。

パーミッションを評価するときに、クライアントが追加のクレームをプッシュし、ポリシーで使用されるようにすることが可能になりました。

パーミッションを評価するときに、リソースの属性を定義して、ポリシーで使用されるようにすることが可能になりました。

Spring Boot 2をサポートしました。

Fuse 7をサポートしました。

JavaScriptアダプターは、ネイティブのPromiseをサポートするようになりました。古いスタイルのPromiseも、今までどおりサポートしています。どちらも区別せずに使用できます。

JavaScriptアダプターのログインやその他のメソッドにCordova固有のオプションを渡すことができるようになりました。 loorent からのコントリビュートに感謝します。