9.3. ロードバランサーまたはプロキシーの設定
このセクションでは、クラスター化された Red Hat Single Sign-On デプロイメントの前にリバースプロキシーまたはロードバランサーを配置する前に設定する必要があるいくつかの点について説明します。また、クラスター化されたドメインの例 であった組み込みロードバランサーの設定についても説明します。
以下の図は、ロードバランサーの使用を示しています。この例では、ロードバランサーは 3 つのクライアントと 3 つの Red Hat Single Sign-On サーバーのクラスターとの間のリバースプロキシーとして機能します。
ロードバランサーダイアグラムの例
9.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-Forwarded-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:10.0
XML ブロックを探します。
HTTP 設定 X-Forwarded-For
<subsystem xmlns="urn:jboss:domain:undertow:10.0"> <buffer-cache name="default"/> <server name="default-server"> <ajp-listener name="ajp" socket-binding="ajp"/> <http-listener name="default" socket-binding="http" redirect-socket="https" proxy-address-forwarding="true"/> ... </server> ... </subsystem>
proxy-address-forwarding
属性を http-listener
要素に追加します。この値は true
に設定します。
プロキシーが HTTP ではなく AJP プロトコルを使用してリクエストを転送する場合 (Apache HTTPD + mod-cluster など)、何も異なる方法を設定する必要があります。http-listener
を変更する代わりに、フィルターを追加して AJP パケットからこの情報をプルする必要があります。
AJP 設定 X-Forwarded-For
<subsystem xmlns="urn:jboss:domain:undertow:10.0"> <buffer-cache name="default"/> <server name="default-server"> <ajp-listener name="ajp" socket-binding="ajp"/> <http-listener name="default" socket-binding="http" redirect-socket="https"/> <host name="default-host" alias="localhost"> ... <filter-ref name="proxy-peer"/> </host> </server> ... <filters> ... <filter name="proxy-peer" class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" module="io.undertow.core" /> </filters> </subsystem>
9.3.2. リバースプロキシーを使用して HTTPS/SSL を有効にします。
リバースプロキシーが SSL にポート 8443 を使用しない場合は、どのポート HTTPS トラフィックがリダイレクトされているかを設定する必要があります。
<subsystem xmlns="urn:jboss:domain:undertow:10.0"> ... <http-listener name="default" socket-binding="http" proxy-address-forwarding="true" redirect-socket="proxy-https"/> ... </subsystem>
http-listener
要素に redirect-socket
属性を追加します。この値は、定義する必要のあるソケットバインディングを参照する proxy-https
である必要があります。
次に、新しい socket-binding
要素を socket-binding-group
要素に追加します。
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> ... <socket-binding name="proxy-https" port="443"/> ... </socket-binding-group>
9.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
ipAddress
の値が、リバースプロキシーまたはロードバランサーの IP アドレスではなく、ログインを試みたマシンの IP アドレスであることを確認します。
9.3.4. 組み込みロードバランサーの使用
このセクションでは、クラスター化ドメインの例 で説明されている組み込みロードバランサーの設定を説明します。
クラスター化されたドメインの例 は、1 台のマシンでのみ実行されるように設計されています。別のホストでスレーブを起動するには、
- domain.xml ファイルを編集して、新規ホストのスレーブを指定します。
- サーバーのディストリビューションをコピーします。domain.xml ファイル、host.xml ファイル、または host-master.xml ファイルは必要ありません。また、standalone/ ディレクトリーも必要ありません。
- host-slave.xml ファイルを編集して、コマンドラインで使用するバインドアドレスを変更するか、または上書きします。
9.3.4.1. ロードバランサーでの新規ホストの登録
まず、domain.xml のロードバランサー設定を使用して新規ホストスレーブを登録する方法を説明します。このファイルを開き、load-balancer
プロファイルの undertow 設定に移動します。reverse-proxy
XML ブロック内に remote-host3
という名前の新規 host
定義を追加します。
domain.xml reverse-proxy config
<subsystem xmlns="urn:jboss:domain:undertow:10.0"> ... <handlers> <reverse-proxy name="lb-handler"> <host name="host1" outbound-socket-binding="remote-host1" scheme="ajp" path="/" instance-id="myroute1"/> <host name="host2" outbound-socket-binding="remote-host2" scheme="ajp" path="/" instance-id="myroute2"/> <host name="remote-host3" outbound-socket-binding="remote-host3" scheme="ajp" path="/" instance-id="myroute3"/> </reverse-proxy> </handlers> ... </subsystem>
output-socket-binding
は、domain.xml ファイルの後半に設定された socket-binding
を示す論理名です。instance-id
属性は、負荷分散時にスティッキーセッションを有効にするために cookie によってこの値が使用されるため、新規ホストに一意である必要があります。
次に load-balancer-sockets
socket-binding-group
に移動し、remote-host3
に outbound-socket-binding
を追加します。この新しいバインディングは新規ホストのホストおよびポートを参照する必要があります。
domain.xml outbound-socket-binding
<socket-binding-group name="load-balancer-sockets" default-interface="public"> ... <outbound-socket-binding name="remote-host1"> <remote-destination host="localhost" port="8159"/> </outbound-socket-binding> <outbound-socket-binding name="remote-host2"> <remote-destination host="localhost" port="8259"/> </outbound-socket-binding> <outbound-socket-binding name="remote-host3"> <remote-destination host="192.168.0.5" port="8259"/> </outbound-socket-binding> </socket-binding-group>
9.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
9.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
ホストのスレーブの IP アドレスに関連する jboss.bind.address
値および jboss.bind.address.management
の値です。jboss.domain.master.address
の値は、マスターホストの管理アドレスであるドメインコントローラーの IP アドレスである必要があります。
9.3.5. 他のロードバランサーの設定
他のソフトウェアベースのロードバランサーの使用方法は、JBoss EAP 設定ガイドの 負荷分散 を参照してください。