8.3. ロードバランサーまたはプロキシーの設定
このセクションでは、クラスター化された Red Hat Single Sign-On デプロイメントの前にリバースプロキシーまたはロードバランサーを配置する前に設定する必要があるいくつかの点について説明します。また、クラスター化されたドメインの例 であった組み込みロードバランサーの設定についても説明します。
8.3.1. クライアント IP アドレスの特定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Single Sign-On のいくつかの機能は、認証サーバーに接続する HTTP クライアントのリモートアドレスがクライアントマシンの実際の IP アドレスであるというファクトに依存します。以下のようになります。
- イベントログ - 失敗したログイン試行が誤ったソース IP アドレスでログに記録される
- SSL 必須: SSL が外部 (デフォルト) に設定されている場合、外部リクエストすべてに SSL が必要になります。
- 認証フロー: IP アドレスを使用して外部リクエストにのみ OTP を示すカスタム認証フロー
- 動的クライアント登録
これは、Red Hat Single Sign-On 認証サーバーの前にリバースプロキシーまたはロードバランサーがある場合に問題が発生することがあります。通常の設定とは、プライベートネットワークにあるバックエンドの Red Hat Single Sign-On サーバーインスタンスに負荷を分散し、要求を転送するパブリックネットワークにフロントエンドプロキシーがあることです。この場合、実際のクライアントの IP アドレスが Red Hat Single Sign-On サーバーインスタンスへ転送され、処理されるようにするため、いくつかの追加設定が必要です。具体的には以下を実行します。
-
HTTP ヘッダーの
X-Forwarded-ForおよびX-Forwarded-Protoを適切に設定するように、リバースプロキシーまたはロードバランサーを設定します。 - 元の 'Host' HTTP ヘッダーを保持するようにリバースプロキシーまたはロードバランサーを設定します。
-
クライアントの IP アドレスを
X-Forwarded-For ヘッダーから読み取るように認証サーバーを設定します。
HTTP ヘッダーの X-Forwarded-For および X-Forwarded-Proto を生成し、元の Host HTTP ヘッダーを保持するようにプロキシーを設定することは本ガイドの対象外となります。X-Forwared-For ヘッダーがプロキシーによって設定されるように、特別な注意を払ってください。プロキシーが正しく設定されていないと、不正な クライアントはこのヘッダー自体を設定し、Red Hat Single Sign-On に、クライアントが実際とは異なる IP アドレスから接続していると思わせることができます。IP アドレスのブラックリストまたはホワイト一覧を実行する場合は、このことが重要になります。
プロキシー自体以外では、Red Hat Single Sign-On で設定する必要があるいくつかの点があります。プロキシーが HTTP プロトコル経由で要求を転送している場合は、ネットワークパケットからではなく、X-Forwarded-For ヘッダーからクライアントの IP アドレスをプルするように Red Hat Single Sign-On を設定する必要があります。これを行うには、プロファイル設定ファイル(操作 モードに応じてstandalone.xml、standalone-ha.xml、または domain.xml )を開き、urn:jboss:domain:undertow:4.0 XML ブロックを探します。
HTTP 設定 X-Forwarded-For
proxy-address-forwarding 属性を http-listener 要素に追加します。この値は true に設定します。
プロキシーが HTTP ではなく AJP プロトコルを使用してリクエストを転送する場合 (Apache HTTPD + mod-cluster など)、何も異なる方法を設定する必要があります。http-listener を変更する代わりに、フィルターを追加して AJP パケットからこの情報をプルする必要があります。
AJP 設定 X-Forwarded-For
8.3.2. リバースプロキシーを使用して HTTPS/SSL を有効にします。 リンクのコピーリンクがクリップボードにコピーされました!
リバースプロキシーが SSL にポート 8443 を使用しない場合は、どのポート HTTPS トラフィックがリダイレクトされているかを設定する必要があります。
http-listener 要素に redirect-socket 属性を追加します。この値は、定義する必要のあるソケットバインディングを参照する proxy-https である必要があります。
次に、新しい socket-binding 要素を socket-binding-group 要素に追加します。
8.3.3. 設定の確認 リンクのコピーリンクがクリップボードにコピーされました!
リバースプロキシーまたはロードバランサーの設定を確認するには、リバースプロキシーを介して /auth/realms/master/.well-known/openid-configuration パスを開きます。たとえば、リバースプロキシーアドレスが https://acme.com/ の場合は、URL https://acme.com/auth/realms/master/.well-known/openid-configuration を開きます。これにより、JSON ドキュメントに Red Hat Single Sign-On の多数のエンドポイントがリストされます。エンドポイントがリバースプロキシーまたはロードバランサーのアドレス (スキーム、ドメイン、ポート) で始まることを確認します。これを実行することで、Red Hat Single Sign-On が正しいエンドポイントを使用していることを確認します。
また、Red Hat Single Sign-On が要求の正しいソース IP アドレスを確認することも確認する必要があります。これは、無効なユーザー名とパスワードを使用して管理コンソールへのログインを試みることができます。これにより、以下のような警告がサーバーログに記録されます。
08:14:21,287 WARN XNIO-1 task-45 [org.keycloak.events] type=LOGIN_ERROR, realmId=master, clientId=security-admin-console, userId=8f20d7ba-4974-4811-a695-242c8fbd1bf8, ipAddress=X.X.X.X, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:8080/auth/admin/master/console/?redirect_fragment=%2Frealms%2Fmaster%2Fevents-settings, code_id=a3d48b67-a439-4546-b992-e93311d6493e, username=admin
08:14:21,287 WARN XNIO-1 task-45 [org.keycloak.events] type=LOGIN_ERROR, realmId=master, clientId=security-admin-console, userId=8f20d7ba-4974-4811-a695-242c8fbd1bf8, ipAddress=X.X.X.X, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=http://localhost:8080/auth/admin/master/console/?redirect_fragment=%2Frealms%2Fmaster%2Fevents-settings, code_id=a3d48b67-a439-4546-b992-e93311d6493e, username=admin
ipAddress の値が、リバースプロキシーまたはロードバランサーの IP アドレスではなく、ログインを試みたマシンの IP アドレスであることを確認します。
8.3.4. 組み込みロードバランサーの使用 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、クラスター化されたドメインの例 で説明されている組み込みロードバランサーの設定について説明します。
クラスター化されたドメインの例 は、1 台のマシンでのみ実行されるように設計されています。別のホストでスレーブを起動するには、
- domain.xml ファイルを編集して、新規ホストのスレーブを指定します。
- サーバーのディストリビューションをコピーします。domain.xml ファイル、host.xml ファイル、または host-master.xml ファイルは必要ありません。また、standalone/ ディレクトリーも必要ありません。
- host-slave.xml ファイルを編集して、コマンドラインで使用するバインドアドレスを変更するか、または上書きします。
8.3.4.1. ロードバランサーでの新規ホストの登録 リンクのコピーリンクがクリップボードにコピーされました!
まず、domain.xml のロードバランサー設定を使用して新規ホストスレーブを登録する方法を説明します。このファイルを開き、load-balancer プロファイルの undertow 設定に移動します。reverse-proxy XML ブロック内に remote-host3 という名前の新規 host 定義を追加します。
domain.xml reverse-proxy config
output-socket-binding は、domain.xml ファイルの後半で設定された socket-binding をポイントする論理名です。負荷分散時にスティッキーセッションを有効にするためにこの値も新しいホストに固有である必要があるためです。
次に load-balancer-sockets socket-binding-group に移動し、remote-host3 に outbound-socket-binding を追加します。この新しいバインディングは新規ホストのホストおよびポートを参照する必要があります。
domain.xml outbound-socket-binding
8.3.4.2. マスターバインドアドレス リンクのコピーリンクがクリップボードにコピーされました!
次に、マスターホストの public および management バインドアドレスを変更する必要があります。バインドアドレス の章で説明されているように domain.xml ファイルを編集するか、以下のようにコマンドラインでこれらのバインドアドレスを指定します。
domain.sh --host-config=host-master.xml -Djboss.bind.address=192.168.0.2 -Djboss.bind.address.management=192.168.0.2
$ domain.sh --host-config=host-master.xml -Djboss.bind.address=192.168.0.2 -Djboss.bind.address.management=192.168.0.2
8.3.4.3. ホストスレーブバインドアドレス リンクのコピーリンクがクリップボードにコピーされました!
次に、public、management、およびドメインコントローラーのバインドアドレス (jboss.domain.master-address) を変更する必要があります。host-slave.xml ファイルを編集するか、以下のようにコマンドラインで指定します。
domain.sh --host-config=host-slave.xml
-Djboss.bind.address=192.168.0.5
-Djboss.bind.address.management=192.168.0.5
-Djboss.domain.master.address=192.168.0.2
$ domain.sh --host-config=host-slave.xml
-Djboss.bind.address=192.168.0.5
-Djboss.bind.address.management=192.168.0.5
-Djboss.domain.master.address=192.168.0.2
ホストスレーブの IP アドレスに関連する jboss.bind.address および jboss.bind.addres.management の値。jboss.domain.master.address の値は、マスターホストの管理アドレスであるドメインコントローラーの IP アドレスである必要があります。
8.3.5. 他のロードバランサーの設定 リンクのコピーリンクがクリップボードにコピーされました!
他 のソフトウェアベースのロードバランサーの使用方法は、JBoss EAP設定ガイド の 負荷分散 を参照してください。