Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

6.6. スティッキーセッションの有効化

通常のクラスターデプロイメントは、プライベートネットワークにあるロードバランサー (リバースプロキシー) および 2 つ以上の Red Hat build of Keycloak サーバーで構成されます。パフォーマンスの観点からは、ロードバランサーが特定のブラウザーセッションに関連するすべての要求を同じ Red Hat build of Keycloak バックエンドノードに転送すると便利です。

なぜなら、Red Hat build of Keycloak は、現在の認証セッションとユーザーセッションに関連するデータを保存する裏で、Infinispan の分散キャッシュを使用しているためです。Infinispan の分散キャッシュは、デフォルトで 2 つの所有者で設定されます。つまり、特定のセッションは 2 つのクラスターノードに保存され、そのセッションにアクセスする必要がある場合は、リモートでセッションを検索する必要があります。

たとえば、ID 123 の認証セッションが node1 の Infinispan キャッシュに保存され、node2 がこのセッションを検索する必要がある場合は、特定のセッションエンティティーを返すために、ネットワーク経由で要求を node1 に送信する必要があります。

特定のセッションエンティティーが常にローカルで利用可能な場合に利点があります。これは、スティッキーセッションを使用して実行できます。パブリックフロントエンドロードバランサーと 2 つのバックエンド Red Hat build of Keycloak ノードを持つクラスター環境のワークフローは次のようになります。

  • ユーザーは、Red Hat build of Keycloak のログイン画面を表示するために、最初の要求を送信します。
  • この要求はフロントエンドロードバランサーにより提供されます。このロードバランサーは、これをランダムなノード (例: node1) に転送します。厳密に言及されているので、ノードはランダムにする必要はありませんが、他の基準 (クライアント IP アドレスなど) に従って選択できます。これらはすべて、基盤のロードバランサーの実装および設定 (逆引きプロキシー) によって異なります。
  • Red Hat build of Keycloak は、ランダム ID (例: 123) で認証セッションを作成し、Infinispan キャッシュに保存します。
  • Infinispan の分散キャッシュは、セッション ID のハッシュに基づいてセッションのプライマリー所有者を割り当てます。詳細は、Infinispan のドキュメントを参照してください。Infinispan が、このセッションの所有者として node2 を割り当てたとします。
  • Red Hat build of Keycloak は、<session-id>.<owner-node-id> のような形式で cookie (AUTH_SESSION_ID) を作成します。この例では、123.node2 になります。
  • ブラウザーで、Red Hat build of Keycloak ログイン画面と cookie (AUTH_SESSION_ID) を持つユーザーに応答が返されます。

この観点から、ロードバランサーが次の要求をすべて node2 に転送することは有用です。なぜなら、これは ID 123 の認証セッションの所有者であるノードであり、Infinispan がこのセッションをローカルで検索できるからです。認証が終了すると、認証セッションはユーザーセッションに変換されます。その場合も ID 123 と同じになるため、node2 に保存されます。

クラスターの設定にスティッキーセッションは必須ではありませんが、上記の理由でパフォーマンスの観点から推奨されます。AUTH_SESSION_ID cookie をスティッキーにするように、ロードバランサーを設定する必要があります。これは、ロードバランサーによって異なります。

プロキシーがバックエンドノードからの cookie を処理せずにセッションアフィニティーをサポートする場合は、ノードを cookie にアタッチせず、リバースプロキシー機能に依存するのみにするために、spi-sticky-session-encoder-infinispan-should-attach-route オプションを false に設定する必要があります。 

bin/kc.[sh|bat] start --spi-sticky-session-encoder-infinispan-should-attach-route=false
Copy to Clipboard Toggle word wrap

デフォルトでは、spi-sticky-session-encoder-infinispan-should-attach-route オプションの値は true であるため、ノード名は cookie にアタッチされ、リバースプロキシーには後続の要求の送信先であるノードが示されます。

6.6.1. 管理コンソールを公開する
リンクのコピー

デフォルトでは、管理コンソール URL は、適切なスキーム、ホスト名、およびポートを解決する要求に基づく場合にのみ作成されます。たとえば、edge プロキシーモードを使用しており、プロキシーが正しく設定されていない場合、TLS Termination プロキシーからのバックエンド要求ではプレーン HTTP が使用されます。その場合、URL は http スキームを使用して作成され、プロキシーがプレーン HTTP をサポートしないため、管理コンソールにアクセスできなくなる可能性があります。

管理コンソールを適切に公開するには、プロキシーにより公開されたスキーム、ホスト名、ポートを使用して URL を作成するために、ここで説明されている X-Forwarded-* ヘッダーをプロキシーが設定していることを確認する必要があります。

6.6.2. 公開されたパスに関する推奨事項
リンクのコピー

リバースプロキシーを使用する場合、Red Hat build of Keycloak では特定のパスのみ公開する必要があります。次の表は、公開が推奨されるパスを示しています。

Expand
Red Hat build of Keycloak のパスリバースプロキシーパス公開理由

/

-

いいえ

すべてのパスを公開すると、管理パスが不必要に公開されます。

/admin/

-

いいえ

管理パスが公開されると、不要な攻撃ベクトルが発生します。

/js/

-

はい (以下の注記を参照)

"内部" クライアント (アカウントコンソールなど) に必要な keycloak.js へのアクセス

/welcome/

-

いいえ

初回インストール後に welcome ページを公開する必要はありません。

/realms/

/realms/

はい

このパスは、たとえば OIDC エンドポイントなどで正しく機能するために必要です。

/resources/

/resources/

はい

このパスは、アセットを正しく提供するために必要です。Red Hat build of Keycloak のパスではなく、CDN から提供される場合があります。

/robots.txt

/robots.txt

はい

検索エンジンのルール

/metrics

-

いいえ

メトリクスが公開されると、不要な攻撃ベクトルが発生します。

/health

-

いいえ

ヘルスチェックが公開されると、不要な攻撃ベクトルが発生します。

注記

アカウントコンソールなどの内部クライアントには js パスが必要なため、外部クライアントには npm や yarn などの JavaScript パッケージマネージャーから keycloak.js を使用することが推奨されます。

Red Hat build of Keycloak をリバースプロキシー/ゲートウェイのパブリック API のルートパス / で実行していることを前提としています。そうでない場合は、パスの前に任意の接頭辞を追加します。

6.6.3. クライアント証明書ルックアップを有効にする
リンクのコピー

プロキシーが TLS Termination プロキシーとして設定されている場合、クライアント証明書情報は特定の HTTP 要求ヘッダーを通じてサーバーに転送され、クライアントの認証に使用されます。使用しているプロキシーに応じて、サーバーがクライアント証明書情報を取得する方法を設定できます。

サーバーは、次のような最も一般的な TLS Termination プロキシーのいくつかをサポートしています。

Expand
ProxyProvider

Apache HTTP サーバー

apache

HAProxy

haproxy

NGINX

nginx

要求からクライアント証明書を取得する方法を設定するには、以下を実行する必要があります。

対応するプロキシープロバイダーを有効にする

bin/kc.[sh|bat] build --spi-x509cert-lookup-provider=<provider>
Copy to Clipboard Toggle word wrap

HTTP ヘッダーを設定する

bin/kc.[sh|bat] start --spi-x509cert-lookup-<provider>-ssl-client-cert=SSL_CLIENT_CERT --spi-x509cert-lookup-<provider>-ssl-cert-chain-prefix=CERT_CHAIN --spi-x509cert-lookup-<provider>-certificate-chain-length=10
Copy to Clipboard Toggle word wrap

HTTP ヘッダーを設定する際には、使用している値が、プロキシーによってクライアント証明書情報とともに転送されるヘッダーの名前に対応していることを確認する必要があります。

プロバイダーの設定に使用できるオプションは次のとおりです。

Expand
オプション説明

ssl-client-cert

クライアント証明書を保持するヘッダーの名前

ssl-cert-chain-prefix

チェーン内の追加の証明書を保持するヘッダーの接頭辞。チェーンの長さに応じて個々の証明書を取得するために使用されます。たとえば CERT_CHAIN の値は、certificate-chain-length が 10 に設定されている場合に、ヘッダー CERT_CHAIN_0 から CERT_CHAIN_9 まで追加の証明書をロードするようにサーバーに指示します。

certificate-chain-length

証明書チェーンの最大長。

trust-proxy-verification

証明書を Red Hat build of Keycloak に転送して Red Hat build of Keycloak で検証するのではなく、信頼している NGINX プロキシー証明書の検証を有効にします。

6.6.3.1. NGINX プロバイダーを設定する
リンクのコピー

NGINX SSL/TLS モジュールは、クライアント証明書チェーンを公開しません。Red Hat build of Keycloak の NGINX 証明書ルックアッププロバイダーは、Red Hat build of Keycloak トラストストアを使用してそれを再構築します。

このプロバイダーを使用している場合、Red Hat build of Keycloak トラストストアを設定する方法は、送信要求用の信頼済み証明書の設定 を参照してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat