6.2. 統合
6.2.1. SAML クライアントの自動証明書管理 リンクのコピーリンクがクリップボードにコピーされました!
SAML クライアントは、SP エンティティーメタデータ記述子エンドポイントから署名証明書と暗号化証明書を自動的にダウンロードするように設定できるようになりました。この新しい機能を使用するには、クライアントの Settings タブの Signature and Encryption セクションで、Metadata descriptor URL オプション (証明書を含む SP メタデータ情報が公開される URL) を設定し、Use metadata descriptor URL を有効にします。証明書はその URL から自動的にダウンロードされ、public-key-storage SPI にキャッシュされます。これにより、証明書のシームレスなローテーションも可能になります。
詳細は、SAML クライアントの作成 を参照してください。
6.2.2. MCP における認可サーバーとしての機能 リンクのコピーリンクがクリップボードにコピーされました!
MCP (Model Context Protocol) は、AI アプリケーションを外部システムに接続するためのオープンソース標準です。MCP を使用すると、AI アプリケーションはデータソース、ツール、ワークフローに接続して、重要な情報にアクセスし、タスクを実行できるようになります。
MCP 仕様に準拠するために、このバージョンでは、RFC 8414 OAuth 2.0 Authorization Server Metadata 仕様に準拠した形式の既知の URI を介して OAuth 2.0 Server Metadata を提供します。したがって、Keycloak ユーザーは Keycloak を MCP の認可サーバーとして使用できるようになりました。
最新の MCP 仕様 2025-06-18 では、Red Hat build of Keycloak に現在実装されていないリソースインジケーターのサポートも必要です。
6.2.3. ユーザーアカウントとアイデンティティープロバイダーのリンクを簡素化 リンクのコピーリンクがクリップボードにコピーされました!
クライアントが開始するユーザーアカウントのアイデンティティープロバイダーへのリンク機能が、アプリケーション開始アクション (AIA) の実装に基づいて行われるようになりました。この機能により、この機能の設定が調整され、クライアントアプリケーションの呼び出し時のエラー処理が簡素化され、より幅広いユーザーにとって便利になります。
以前はクライアントが開始するアカウントリンクに使用されていたカスタムプロトコルは、非推奨となりました。
6.2.4. OAuth v2 準拠の認可サーバーとのブローカー接続 リンクのコピーリンクがクリップボードにコピーされました!
以前のリリースでは、Red Hat build of Keycloak は他の OpenID Connect および SAML プロバイダー、および OAuth 2.0 に基づく GitHub や Google などのいくつかのソーシャルプロバイダーとのフェデレーションをすでにサポートしていました。
新しい OAuth 2.0 ブローカーにより、あらゆる OAuth 2.0 プロバイダーとのフェデレーションにおけるギャップが解消されます。この変更の結果、Amazon や他のプロバイダーとフェデレートできるようになります。これは汎用プロバイダーであるため、プロバイダーの設定でさまざまなクレームとユーザー情報エンドポイントを指定する必要があります。
詳細は、OAuth v2 アイデンティティープロバイダー を参照してください。
6.2.5. OpenID Connect プロバイダーとのブローカー接続時における信頼できるメール検証 リンクのコピーリンクがクリップボードにコピーされました!
これまで、OpenID Connect ブローカーは、OpenID Connect プロバイダーによって発行された ID トークンから利用できる標準の email_verified クレームをサポートしていませんでした。
このリリースより、Red Hat build of Keycloak は、フェデレーション向けに OpenID Connect Core Specification で定義されているこの標準クレームをサポートします。
ユーザーが初めてフェデレーションされるとき、または再認証を行う際に、Trust email 設定が有効で、かつ Sync Mode が FORCE に設定されており、プロバイダーが email_verified クレームを送信する場合、ユーザーアカウントのメールアドレスは、その email_verified クレームに従ってマーキングされます。プロバイダーがクレームを送信しない場合は、デフォルトで元の動作に戻り、メールは検証済みとして設定されます。