1.5. 新機能および機能拡張

このリリースでは、User Profile SPI への変更により、この SPI に基づく既存の実装に影響が及ぶ可能性があります。詳細は、アップグレードガイド を参照してください。

このリリースでは、次のテンプレートが更新され、レルムに設定されたユーザープロファイル設定に基づいて属性を動的にレンダリングできるようになりました。

詳細は、アップグレードガイド を参照してください。

このリリースでは、ユーザーが idp-review-user-profile.ftl テンプレートを使用して初めてブローカー経由で認証するときに、サーバーが更新プロファイルページをレンダリングします。

詳細は、アップグレードガイド を参照してください。

このリリースには、軽量アクセストークンのサポートが含まれています。そのため、指定のクライアントのアクセストークンを小さくすることができます。このトークンにはクレームがわずかしかないため、サイズが小さくなります。軽量アクセストークンは、デフォルトではレルムキーによって署名された JWT のままであり、非常に基本的なクレームをいくつか含んでいることに注意してください。

このリリースでは、Add to lightweight access token フラグが導入されました。これは一部の OIDC プロトコルマッパーで使用できます。このフラグを使用して、特定のクレームを軽量アクセストークンに追加する必要があるかどうかを指定します。デフォルトでは OFF なっているため、ほとんどのクレームは追加されません。

また、クライアントポリシーエグゼキューターも存在します。これを使用して、特定のクライアント要求で軽量アクセストークンを使用するか、通常のアクセストークンを使用するかを指定します。エグゼキューターの代替手段として、クライアントの詳細設定で Always use lightweight access token フラグを使用する方法があります。これを使用すると、クライアントが常に軽量アクセストークンを使用するようになります。より柔軟性が必要な場合は、代わりにエグゼキューターを利用できます。たとえば、デフォルトで軽量アクセストークンを使用し、指定の scope パラメーターに対してのみ通常のトークンを使用するように選択できます。

以前のバージョンでは、イントロスペクションエンドポイントが、アクセストークンで使用可能なほとんどのクレームを自動的に返していました。現在は、ほとんどのプロトコルマッパーに、新しい Add to token introspection スイッチが含まれています。これにより、イントロスペクションエンドポイントがアクセストークンとは異なるクレームを返すことができるため、柔軟性が向上します。この変更は、"軽量アクセストークン" のサポートに向けた第一歩です。アクセストークンでは多くのクレームを省略できますが、現在も、多くのクレームがイントロスペクションエンドポイントによって返されるためです。以前のバージョンから移行する場合、イントロスペクションエンドポイントはアクセストークンから返されるものと同じクレームを返す必要があります。そのため、アップグレード後の動作は、デフォルトで実質的に同じになるはずです。

詳細は、軽量アクセストークンの使用 を参照してください。

このリリースには、オプションの OAuth 2.1 サポートが含まれています。このリリースでは、新しいクライアントポリシープロファイルが導入されました。管理者はこれを使用して、クライアントと特定のクライアント要求が OAuth 2.1 仕様に準拠していることを確認できます。このリリースには、機密クライアント専用のクライアントプロファイルと、パブリッククライアント専用のプロファイルが含まれています。

詳細は、OAuth 2.1 のサポート を参照してください。

このリリースから、トークン更新用の OAuth2/OIDC エンドポイントの scope パラメーターがサポートされるようになりました。このパラメーターは、最初に付与されたスコープよりもスコープ数が少ないアクセストークンを要求するために使用します。つまり、アクセストークンのスコープ数を増やすことはできません。このスコープの制限は、更新された更新トークンのスコープには影響しません。この機能は、OAuth2 仕様で説明されているとおりに動作します。

詳細は、サーバー管理ガイド を参照してください。

新しいクライアントポリシーエグゼキューター secure-redirect-uris-enforcer が導入されました。これは、クライアントが使用できるリダイレクト URI を制限するために使用します。たとえば、クライアントのリダイレクト URI でワイルドカードを使用できないこと、URI が特定のドメインからのものであること、URI が OAuth 2.1 に準拠している必要があることなどを指定できます。

詳細は、クライアントポリシー を参照してください。

新しいクライアントポリシーエグゼキューター dpop-bind-enforcer が導入されました。プレビュー機能の dpop が有効になっている場合、このエグゼキューターを使用して、特定のクライアントに対して DPoP を適用できます。

詳細は、クライアントポリシー を参照してください。

EdDSA レルムキーを作成し、さまざまなクライアントの署名アルゴリズムとして使用できます。たとえば、このキーを使用してトークンに署名したり、署名済み JWT によるクライアント認証を行ったりすることができます。この機能には、サードパーティーのアイデンティティープロバイダーへの private_key_jwt 認証に使用されるクライアントアサーションに Red Hat build of Keycloak 自体が署名するアイデンティティーブローカリングが含まれています。

詳細は、レルムキーの設定 を参照してください。

レルムキーを提供するためのプロバイダー JavaKeystoreProvider が、以前サポートされていた RSA キーに加えて、EC キーもサポートするようになりました。

詳細は、レルムキーの設定 を参照してください。

秘密鍵で署名された JWT を使用したクライアント認証が使用される状況に対応するために、OIDC アイデンティティープロバイダーに、Add X.509 Headers to the JWT オプションが追加されました。このオプションは、JWT にサムプリントが存在することを必須とする Azure AD など、一部のアイデンティティープロバイダーとの相互運用性を確保するのに役立ちます。

詳細は、アイデンティティープロバイダーの統合 を参照してください。

Red Hat build of Keycloak のコードベースに、OAuth Grant Type SPI を導入するための内部更新が追加されました。この更新により、Red Hat build of Keycloak OAuth 2 トークンエンドポイントでサポートされているカスタムグラントタイプを導入する際の柔軟性が向上します。

詳細は、認可サービス を参照してください。

Red Hat build of Keycloak に、新しいクライアントプロファイル fapi-2-security-profile と fapi-2-message-signing が追加されました。これにより、Red Hat build of Keycloak がクライアントと通信する際に最新の FAPI 2 ドラフト仕様への準拠が確実に適用されます。

詳細は、クライアントポリシー を参照してください。

Red Hat build of Keycloak に、OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) のサポートのプレビューが追加されました。

OAuth 2.0 デバイス認可グラントフローに機能フラグが追加されたため、この機能を簡単に無効にすることができます。この機能はデフォルトで有効になっています。

詳細は、デバイス認可グラント を参照してください。

Red Hat build of Keycloak は、パスキー のプレビューサポートを提供します。

パスキーの登録と認証は WebAuthn の機能によって実現されます。したがって、Red Hat build of Keycloak のユーザーは、既存の WebAuthn の登録と認証を使用して、パスキーの登録と認証を行うことができます。

同期されたパスキーとデバイスにバインドされたパスキーは、Same-Device Authentication と Cross-Device Authentication の両方に使用できます。ただし、パスキー操作の成功は、ユーザーの環境によって異なります。どの操作が 環境 で正常に実行されるかを確認してください。

WebAuthn ポリシーに、新しいフィールド Extra Origins が追加されました。これにより、非 Web プラットフォーム (ネイティブモバイルアプリケーションなど) との相互運用性が向上します。

このリリースでは、ユーザーが複数のブラウザータブでログインページを開いていて、1 つのブラウザータブでユーザーが認証するときに発生する問題に対処しています。ユーザーが別のブラウザータブで認証を試みると、You are already logged-in というメッセージが表示されていました。最初のタブで認証された後、他のブラウザータブでユーザーが自動的に認証されるようになったため、この問題は改善されました。しかし、さらなる改善が必要です。たとえば、あるブラウザータブで認証セッションが有効期限切れになった後に再開されても、他のブラウザータブではログインが自動的に行われません。

Red Hat build of Keycloak は、再認証なしでユーザーがパスワードを変更できる最大認証有効期間を指定できる新しいパスワードポリシーをサポートするようになりました。このパスワードポリシーが 0 に設定されている場合、ユーザーはアカウントコンソールまたはその他の手段でパスワードを変更するために再認証する必要があります。デフォルト値の 5 分よりも低い値または高い値を指定することもできます。

Red Hat build of Keycloak に、高負荷時に受信要求を適切に拒否できるようにする http-max-queued-requests オプションが追加されました。詳細は、サーバーガイド を参照してください。

Red Hat build of Keycloak は RESTEasy Reactive に切り替わりました。quarkus-resteasy-reactive を使用するアプリケーションで、リアクティブスタイル/セマンティクスを使用していない場合でも、起動時間、実行時パフォーマンス、メモリーフットプリントの改善による利点が得られるはずです。JAX-RS API に直接依存する SPI は、通常、この変更に対して互換性があります。ResteasyClientBuilder など、RESTEasy Classic に依存する SPI は、互換性がないため、更新が必要になります。この更新は、Jersey のような JAX-RS API の他の実装にも必要になります。

Keycloak CR に startOptimized フィールドが追加されました。これを使用すると、start コマンドに --optimized フラグを使用するかどうかに関するデフォルトの想定をオーバーライドできます。そのため、カスタム Keycloak イメージを使用する場合でも、CR を使用してビルド時のオプションを設定できます。

Keycloak CR で、Keycloak コンテナーのコンピュートリソースを管理するための resources オプションを指定できるようになりました。これにより、Keycloak CR を使用して Red Hat build of Keycloak に対して、および Realm Import CR を使用してレルムインポートジョブに対して、個別にリソースを要求および制限できます。

値が指定されていない場合、デフォルトの requests メモリーが 1700MiB に設定され、limits メモリーが 2GiB に設定されます。

次のように、要件に応じてカスタム値を指定できます。

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  ...
  resources:
    requests:
      cpu: 1200m
      memory: 896Mi
    limits:
      cpu: 6
      memory: 3Gi

詳細は、Operator ガイド を参照してください。

Keycloak CR で、cache 仕様の configMapFile フィールドを使用して cache-config-file オプションを指定できるようになりました。次に例を示します。

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  ...
  cache:
    configMapFile:
      name: my-configmap
      key: config.xml

Keycloak CR を使用して、トラストストアの新しいサーバー側処理を利用することもできます。次に例を示します。

spec:
  truststores:
    mystore:
      secret:
        name: mystore-secret
    myotherstore:
      secret:
        name: myotherstore-secret

現在はシークレットのみがサポートされています。

Kubernetes CA の証明書は、Operator によって管理される Red Hat build of Keycloak Pod に自動的に追加されます。

Red Hat build of Keycloak JS アダプターが、package.json 内の exports フィールド を使用するようになりました。この変更により、Webpack 5 や Vite などの最新のバンドラーのサポートが改善されますが、避けられない重大な変更がいくつか発生します。詳細は、アップグレードガイド を参照してください。

Red Hat build of Keycloak JS アダプターが、pkceMethod オプションをデフォルトで S256 に設定するようになりました。この変更により、アダプターを使用するすべてのアプリケーションで Proof Key Code Exchange (PKCE) が有効になります。PKCE をサポートしていないシステムでアダプターを使用する場合は、pkceMethod オプションを false に設定すると、PKCE を無効にできます。

IDP エンティティーメタデータ記述子エンドポイントから署名証明書を自動的にダウンロードするように SAML アイデンティティープロバイダーを設定できるようになりました。新しい機能を使用するには、プロバイダーの Metadata descriptor URL オプション (証明書を含む IDP メタデータ情報が公開される URL) を設定し、Use metadata descriptor URL を ON に設定します。証明書はその URL から自動的にダウンロードされ、public-key-storage SPI にキャッシュされます。管理コンソールから、プロバイダーページのアクションコンボを使用して、証明書を再読み込みまたはインポートすることもできます。

新しいオプションの詳細は、サーバー管理ガイド を参照してください。

/lb-check で利用可能な新しいヘルスチェックエンドポイントが追加されました。イベントループ内で実行が動作するため、このチェックは、リクエストキューで待機している多数の要求を Red Hat build of Keycloak が処理する必要がある過負荷の状況でも応答します。この動作は、たとえば、マルチサイトデプロイメントで、負荷の高い別のサイトへのフェイルオーバーを回避する場合に役立ちます。このエンドポイントは、現在、組み込みおよび外部 Infinispan キャッシュの可用性をチェックします。今後、他のチェックが追加される可能性があります。

このエンドポイントはデフォルトでは利用できません。有効にするには、multi-site 機能を使用して Keyloak を実行します。詳細は、機能の有効化と無効化 を参照してください。

このリリースでは、Admin Account と Account REST API を使用するときにルートユーザー属性 (username、email、firstName、lastName、locale など) をマーシャリングおよびアンマーシャリングする方法を一致させるために、これらの属性を基底/抽象クラスに移動してカプセル化しています。

この方法により、クライアントによる属性の管理方法の一貫性が確保され、レルムに設定されたユーザープロファイル設定に属性が確実に準拠するようになります。

詳細は、アップグレードガイド を参照してください。

管理ユーザー API を介してユーザー属性を更新する場合、username、email、firstName、lastName などのルート属性を含むユーザー属性を更新するときに、部分的な更新はできません。

詳細は、アップグレードガイド を参照してください。

このリリースから、Red Hat build of Keycloak クラスターの最初のメンバーが、リモートセッションを並行してではなく順番にロードするようになります。オフラインセッションのプリロードが有効になっている場合は、それらも順番にロードされます。

詳細は、アップグレードガイド を参照してください。

このリリースでは、ユーザーがすでに認証されていて、アクションが別のユーザーにバインドされている場合、メール検証などのアクションを実行できなくなりました。たとえば、メールリンクが別のアカウントにバインドされている場合、ユーザーは検証メールフローを完了できません。

このリリースでは、ユーザーがリンクをクリックしてメールアドレスを検証しようとしたときに、メールアドレスが以前に検証済みである場合、適切なメッセージが表示されます。

さらに、すでに検証済みのメールアドレスを検証しようとしていることを示すために、新しいエラー (EMAIL_ALREADY_VERIFIED) イベントが発生するようになりました。このイベントを使用すると、リンクが漏洩した場合にユーザーアカウントを乗っ取る可能性のある攻撃を追跡したり、ユーザーがアクションを認識していない場合に警告したりすることができます。

テーマのメッセージプロパティーファイルが UTF-8 エンコードで読み取られるようになり、自動的に ISO-8859-1 エンコードにフォールバックされます。

詳細は、アップグレードガイド を参照してください。

メモリー要件を削減するために、Infinispan キャッシュにインポートされたオフラインセッションの有効期間を短縮する設定オプションが導入されました。現在、オフラインセッションの有効期間のオーバーライドはデフォルトで無効になっています。

詳細は、サーバー管理ガイド を参照してください。

Red Hat build of Keycloak の組み込みキャッシュのメトリクスを有効にしたときに、メトリクスがキャッシュマネージャーとキャッシュ名のラベルを使用するようになりました。

詳細は、アップグレードガイド を参照してください。

このリリース以降、Red Hat build of Keycloak は、以前は制限されていた 255 文字を超えるユーザー属性値の保存と検索をサポートします。

詳細は、アップグレードガイド を参照してください。

ブルートフォース保護にいくつかの機能拡張が加えられました。

以前のバージョンの Red Hat build of Keycloak では、ユーザー、グループ、またはクライアントポリシーの最後のメンバーが削除されると、そのポリシーも削除されていました。そのため、このポリシーが集約ポリシーで使用された場合、権限の昇格が発生することがありました。権限の昇格を回避するために、有効なポリシーが削除されなくなりました。また、管理者がこのようなポリシーを更新する必要があります。

ブルートフォースプロテクターによってユーザーが一時的にロックアウトされた場合に、新しいイベント USER_DISABLED_BY_TEMPORARY_LOCKOUT が発生するようになりました。新しいイベントは情報を構造化された形式で提供するため、ID KC-SERVICES0053 のログは削除されました。

詳細は、アップグレードガイド を参照してください。

新しい Cookie プロバイダーを含め、Cookie 処理コードがリファクタリングされ、改善されました。これにより、Red Hat build of Keycloak によって処理される Cookie の一貫性が向上し、必要に応じて Cookie に関する設定オプションを導入できるようになります。

以前は、User Attribute Mapper For NameID で、Name ID Format オプションを次の値に設定できました。

しかし、Red Hat build of Keycloak は、これらの NameIDPolicy のいずれかを使用した AuthnRequest ドキュメントの受信をサポートしていないため、これらのマッパーは使用されません。サポートされるオプションが更新され、次の Name ID Formats だけが含まれるようになりました。

Red Hat build of Keycloak では、初期ヒープサイズと最大ヒープサイズにハードコード値を指定せずに、コンテナーの合計メモリーに対する相対値を使用します。JVM オプション -Xms および -Xmx が、-XX:InitialRAMPercentage と -XX:MaxRAMPercentage に置き換えられました。

詳細は、アップグレードガイド を参照してください。

Red Hat build of Keycloak のデフォルトの動作では、オンデマンドでオフラインセッションをロードします。起動時にオフラインセッションをプリロードするという従来の動作は、非推奨になりました。起動時にプリロードすると、セッション数の増加に応じて適切にスケールすることができず、Red Hat build of Keycloak のメモリー使用量が増加するためです。古い動作は今後のリリースで削除される予定です。

詳細は、アップグレードガイド を参照してください。