darkMode=false2025年1月15日
リリースをダウンロードするには、Keycloak ダウンロードにアクセスしてください。
jdbc-ping が新しいデフォルトにKeycloak は、同じクラスタの他のノードを検出するためにデフォルトでデータベースを使用するようになりました。これにより、特にクラウドプロバイダー向けの追加のネットワーク関連構成が不要になります。また、クラウド環境で追加設定なしですぐに動作するデフォルトでもあります。
以前のバージョンの Keycloak では、クラスタを形成し、Keycloak のレプリケートされたキャッシュを同期するために、デフォルトで UDP マルチキャストを使用して他のノードを検出していました。これには、マルチキャストが利用可能であり、正しく構成されている必要がありましたが、通常、クラウド環境ではそうではありません。
このバージョンから、デフォルトは jdbc-ping 設定に変更され、Keycloak のデータベースを使用して他のノードを検出します。これにより、マルチキャストネットワーク機能と UDP が不要になり、TCP ベースの障害検出に動的ポートを使用しなくなるため、以前のデフォルトを使用していた環境にとって簡素化され、ドロップインの代替となります。以前の動作を有効にするには、非推奨となったトランスポートスタック udp を選択してください。
Keycloak Operator は、引き続きトランスポートスタックとして kubernetes を構成します。
詳細については、分散キャッシュの設定ガイドを参照してください。
このリリース以降、OpenJDK 21 で実行している場合、Keycloak は組み込みの Infinispan と JGroups の両方で仮想スレッドプールのサポートを自動的に有効にします。これにより、JGroups スレッドプールの構成、JGroups スレッドプールと HTTP ワーカー スレッドプールの調整が不要になり、全体的なメモリフットプリントが削減されます。
以前のリリースでは、OpenTelemetry トレーシング機能はプレビューでしたが、現在は完全にサポートされています。つまり、opentelemetry 機能はデフォルトで有効になっています。
Keycloak のトレーシング機能には、次のような複数の改善が加えられました。
Keycloak Operator のKeycloak CR による構成
カスタムスパン
アイデンティティプロバイダーのブローカレッジを含む、受信/送信 HTTP リクエスト
データベース操作と接続
LDAP リクエスト
時間のかかる操作 (パスワードハッシュ、永続セッション操作など)
詳細については、トレーシングの有効化ガイドを参照してください。
以前のリリースでは、--cache-config-file オプションが指定されていない場合、conf/cache-ispn.xml への変更は無視されていました。
このリリースから、--cache-config-file が設定されていない場合、デフォルトの Infinispan XML 構成ファイルは conf/cache-ispn.xml になります。これは、現在のリリースと以前のリリースのドキュメントから想定される動作であり、暗黙的な動作でもあります。
カテゴリ固有のログレベルを個別の log-level-category オプションとして設定できるようになりました。
詳細については、ロギングガイドを参照してください。
検証可能な資格情報発行のための OpenID (OID4VCI) は、Keycloak では実験的な機能のままですが、このリリースでは大幅な改善が見られます。この機能は、既存の構成の多くの改善と、機能をより動的でカスタマイズ可能にすることから恩恵を受けています。
Keycloak OAuth SIG で、重要な開発と議論を見つけることができます。Keycloak コミュニティの誰でも参加を歓迎します。
この機能の開発と議論への参加について、OAuth SIG グループのすべてのメンバーに感謝します。特に、Francis Pouatcha、Ingrid Kamga、Pascal Knüppel、Thomas Darimont、Ogen Bertrand、Awambeng Rodrick、Takashi Norimatsu に感謝します。
最小 ACR 値 オプションが、レルム OIDC クライアントの構成オプションとして追加されました。この追加は、ステップアップ認証に関連する機能強化であり、特定のクライアントにログインする際に最小 ACR レベルを強制することが可能になります。
貢献してくれた Simon Levermann に感謝します。
ユーザー登録開始標準のサポートが追加されました。これにより、OIDC クライアントはパラメーター prompt=create を指定してログインリクエストを開始し、Keycloak に既存のユーザーを認証するのではなく、新しいユーザーを登録する必要があることを通知できます。ユーザー登録の開始は、専用のエンドポイント /realms/<realm>/protocol/openid-connect/registrations の使用により、Keycloak で既にサポートされていました。ただし、このエンドポイントは Keycloak 固有のプロプライエタリなソリューションであったため、標準的な方法が推奨されるようになり、非推奨となりました。
貢献してくれた Thomas Darimont に感謝します。
新しいオプション、証明書を生成 が、EC-DSA および Ed-DSA キープロバイダーに存在します。生成されたキーがレルム管理者によって作成されると、このキーの証明書が生成される場合があります。証明書情報は、管理コンソールと、レルムキー付きの JWKS エンドポイントから利用可能なこのキーの JWK 表現で利用可能です。
貢献してくれた Pascal Knüppel に感謝します。
DPoP キーへの認可コードバインディングのサポートが追加されました。これには、プッシュ認可リクエスト付きの DPoP のサポートが含まれます。
貢献してくれた Takashi Norimatsu に感謝します。
OIDC 認証リクエストは、最大長の追加カスタムパラメータの数を制限付きでサポートします。追加パラメータは、カスタム目的 (たとえば、プロトコルマッパーを使用してトークンにクレームを追加するなど) に使用できます。以前のバージョンでは、パラメータの最大数はハードコードされて 5 であり、パラメータの最大長はハードコードされて 2000 でした。現在、両方の値が構成可能です。さらに、追加パラメータがリクエストを失敗させるか、パラメータが無視されるかを構成することも可能です。
貢献してくれた Manuel Schallar と Patrick Weiner に感謝します。
|
注記
|
プレビュー機能。 |
Kubernetes デプロイメントのセキュリティを向上させるために、ネットワークポリシーを Keycloak CR で指定できます。Keycloak Operator は、トラフィックの送信元を定義するイングレスルールを受け入れ、必要なネットワークポリシーを自動的に作成します。
Microsoft AD を使用し、管理インターフェースを通じてユーザーを作成する場合、ユーザーはデフォルトで有効として作成されます。
以前のバージョンでは、ユーザーに (一時的でない) パスワードを設定した後でのみ、ユーザーのステータスを更新することができました。この動作は、他の組み込みユーザー ストレージや、LDAP プロバイダーでサポートされている他の LDAP ベンダーと一貫性がありませんでした。
Condition - sub-flow executed および Condition - client scopeCondition - sub-flow executed および Condition - client scope は、Keycloak の新しい条件付き認証器です。条件 Condition - sub-flow executed は、認証フローの実行中に以前のサブフローが正常に実行された (または実行されなかった) かどうかをチェックします。条件 Condition - client scope は、構成されたクライアントスコープが認証を要求しているクライアントのクライアントスコープとして存在するかどうかをチェックします。詳細については、条件付きフローの条件を参照してください。
Keycloak の拡張機能を開発する場合、開発者は ProviderFactory インターフェースに dependsOn() メソッドを実装することで、プロバイダーファクトリクラス間の依存関係を指定できるようになりました。詳細な説明については、Javadoc を参照してください。
すべての keycloak テーマでダークモードのサポートが有効になりました。この機能は以前は管理コンソール、アカウントコンソール、ログインに存在していましたが、ウェルカムページでも利用できるようになりました。ユーザーがオペレーティングシステム設定 (例: ライトモードまたはダークモード) またはユーザーエージェント設定を通じて好みを指定すると、テーマはこれらの設定に自動的に追従します。
keycloak テーマのいずれかを拡張するカスタムテーマを使用しており、ダークモードをまだサポートする準備ができていない場合、またはダークモードの実装を妨げるスタイルの競合がある場合は、テーマに次のプロパティを追加することでサポートを無効にできます。
darkMode=falseまたは、レルム設定の テーマ タブにある ダークモード 設定をオフにすることで、組み込みの Keycloak テーマのダークモードサポートをレルムごとに無効にできます。
Keycloak によって実行されたパスワード検証の数をカウントする新しいメトリクスが利用可能です。これにより、CPU リソースがどこで使用されているかをより適切に評価でき、サイジング計算に役立ちます。
詳細については、Keycloak メトリクス および CPU およびメモリリソースのサイジングの概念 を参照してください。
以前のバージョンでは、管理コンソールで アクティブなセッションをすべてサインアウト をクリックすると、通常のセッションのみが削除されていました。オフラインセッションは、効果的に無効になっているにもかかわらず、引き続き表示されていました。
これが変更されました。アクティブなセッションをすべてサインアウトすると、通常のセッションとオフラインセッションの両方が削除されるようになりました。
このリリース以降、Keycloak JavaScript アダプターと Keycloak Node.js アダプターは、Keycloak サーバーのリリースサイクルとは独立したリリースサイクルを持つようになります。26.1.0 リリースは、これらのアダプターが Keycloak サーバーとともにリリースされる最後のリリースの可能性がありますが、今後は、これらのアダプターは Keycloak サーバーとは異なるタイミングでリリースされる可能性があります。
Keycloak クイックスタートは、ベースブランチとして main を使用するようになりました。以前使用されていた latest ブランチは削除されました。main ブランチは、Keycloak サーバー、Keycloak クライアントライブラリ、およびアダプターの最新リリースバージョンに依存します。その結果、クイックスタートへの貢献は、次の Keycloak サーバーリリースを待つ必要がなく、クイックスタートの利用者にすぐに表示されます。
KEYCLOAK_SESSION クッキーの形式がわずかに更新され、平文でプライベートデータが含まれないようになりました。これまで、クッキーの形式は realmName/userId/userSessionId でした。現在、クッキーにはユーザーセッション ID が含まれており、SHA-256 でハッシュされ、URL エンコードされています。
AUTH_SESSION_ID クッキーの形式が更新され、認証セッション ID の整合性を署名検証によって保証するために、認証セッション ID の署名が含まれるようになりました。新しい形式は base64(auth_session_id.auth_session_id_signature) です。この更新により、古い形式は受け入れられなくなり、古い認証セッションは無効になります。この変更は、ユーザーセッションには影響しません。
これらの変更は、独自のプロバイダーを実装し、Keycloak 内部クッキーの形式に依存している場合にのみ影響を与える可能性があります。
以前はデフォルトで含まれていた robots.txt ファイルが削除されました。デフォルトの robots.txt ファイルはすべてのクロールをブロックしており、noindex/nofollow ディレクティブが従われませんでした。望ましいデフォルトの動作は、Keycloak ページが検索エンジンの結果に表示されないことであり、これは既存の X-Robots-Tag ヘッダーによって実現されます。このヘッダーはデフォルトで none に設定されています。異なる動作が必要な場合は、このヘッダーの値をレルムごとにオーバーライドできます。
以前にリバースプロキシ構成にルールを追加した場合、削除できます。
外部で生成されたキー (rsa および java-keystore ファクトリ) をインポートできるキープロバイダーは、存在する場合は、関連付けられた証明書の有効性をチェックするようになりました。したがって、有効期限切れの証明書を持つキーは、Keycloak にインポートできなくなりました。証明書がランタイムに有効期限切れになると、キーはパッシブキー (有効だがアクティブではない) に変換されます。パッシブキーは、新しいトークンには使用されませんが、以前に発行されたトークンを検証するためには引き続き有効です。
デフォルトの generated キープロバイダーは、10 年間有効な証明書を生成します (関連付けられた証明書を持つか、持つことができるタイプ)。有効期間が長く、キーを頻繁にローテーションすることが推奨されているため、生成されたプロバイダーはこのチェックを実行しません。
このリリースでは、管理イベントに、イベントが発生したときのコンテキストに関する追加の詳細が含まれる可能性があります。アップグレードする場合、データベーススキーマが更新され、ADMIN_EVENT_ENTITY テーブルに新しい列 DETAILS_JSON が追加されることを想定する必要があります。
OpenShift v3 はしばらく前にサポート終了を迎えたため、OpenShift v3 とのアイデンティティブローカリングのサポートは Keycloak から削除されました。
アップグレードする前に、変更の完全なリストについては、移行ガイドを参照してください。