| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
特に明記しないかぎり、ここに示す情報は、11gと10gのWebGate(プログラムのアクセス・クライアントを含む)に同様に適用されます。
次の各トピックでは、OAMエージェント登録パラメータについて説明します。
OAM ... Webゲートの作成ページでは、登録を合理化するために最小限の情報が要求されます。
アスタリスク(*)は必須の詳細です。11g Webゲートまたは10g Webゲートのどちらを登録する場合でも、要求される最初の情報は同じです。
表15-1は、11g Webゲート(またはアクセス・クライアント)の作成ページについて示しています。
特に明記しないかぎり、すべての要素が11gおよび10gエージェントの両方に適用されます。
表15-1 11gおよび10g OAMエージェントの作成ページの要素
| OAM Webゲートの要素 | 説明 |
|---|---|
バージョン |
これを10g Webゲートにするか、11g Webゲートにするかを指定します。 |
名前 |
このエージェント登録を一意に識別できる名前。ほとんどの場合、WebGateに使用されるWebサーバーをホストするコンピュータ名です。 各エージェント登録を一意に識別する名前がお薦めされます。ただし、次のことに注意してください。
|
説明 |
このエージェント登録のわかりやすい説明。 |
ベースURL オプション |
WebゲートのWebサーバーがインストールされるコンピュータのホストおよびポート。たとえば、http://example_host:portまたはhttps://example_host:portになります。ポート番号はオプションです。 ノート: 特定のベースURLは、一度のみ登録できます。このベースURLからWebゲートがインストールされているWebサーバー・ドメイン(ホスト識別子要素で指定)へのマッピングは、1対1です。ただし、1つのドメインが複数のベースURLを持つことができます。 |
アクセス・クライアント・パスワード オプション |
このWebゲートのオプションかつ一意のパスワードで、この登録プロセス中に割り当てられます。 登録されたWebゲートがOAMサーバーに接続するときは、認可されていないWebゲートがOAMサーバーに接続してポリシー情報を取得しないように、認証にこのパスワードが使用されます。 |
セキュリティ |
エージェントとOAMサーバー間の通信トランスポート・セキュリティのレベル(これはOAMサーバーに指定したレベルと一致する必要があります)。
ノート: 簡易モードと証明書モード、秘密キーの暗号化の詳細は、「通信の保護」を参照してください。 |
ホスト識別子 |
この識別子は、Webサーバー・ホストを表します。ここにはエージェントの「名前」フィールドの値が自動的に入力されます。 ノート: 次に示すように、同じアプリケーション・ドメインとポリシーを使用して、1つのホスト識別子の下に、複数のOAM Webゲート(またはアクセス・クライアント)を登録できます。
関連項目: 「仮想Webホスティングについて」 |
ユーザー定義パラメータ |
特定のWebゲートの動作を有効にするために入力できるパラメータ。 関連項目: 「ユーザー定義のWebゲート・パラメータ」。 |
仮想ホスト |
複数のWebサイトとドメイン名を含むWebサーバー上にWebゲートをインストールした場合は、「仮想ホスト」の横にあるボックスを選択します。WebGateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。 関連項目: 「仮想Webホスティングについて」 |
ポリシーの自動作成 |
エージェントの登録中、自動的に作成された認証および認可ポリシーを使用できます。デフォルトで、このオプションが選択(有効化)されます。 デフォルト: 有効 登録およびポリシーの共有: 別々のWebサーバーにインストールされた複数のWebゲート(またはアクセス・クライアント)は、同じリソースを保護するために1つの登録およびポリシーを共有できます。この設定は、高可用性フェイルオーバー環境で役立ちます。これを行うには:
2つ目のエージェントの登録後、どちらのWebゲートも同じホスト識別子とポリシーを使用します。 |
IPの検証 |
「IPの検証」の横にあるボックスを選択し、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。「IPの検証例外」ボックスに、検証から除外するIPアドレスを標準的なアドレス表記(例: 10.20.30.123)で入力します。 これを有効にした場合は、ObSSOCookieに格納されているIPアドレスがクライアントのIPアドレスに一致する必要があります。一致しない場合はCookieが拒否され、ユーザーは再認証が必要になります。 デフォルト: 無効 関連項目: 「Webゲート用IPアドレスの検証」。 |
エージェント・キー・パスワード |
このパスフレーズは、証明書モードの通信でのみ要求され、簡易モードと証明書モードでWebゲートとOAMサーバーとの間のSSL通信に使用する秘密キーを暗号化する際に使用されます。 ノート: 「エージェント・キー・パスワード」は、この表で既出の「アクセス・クライアント・パスワード」とは関係ありません。 証明書モード:: このモードの場合、エージェント・キーはグローバルではないため、クライアントとサーバーで同じである必要はありません。管理者は、エージェント登録時のpassword.xmlファイルの生成を有効にし、password.xmlファイルがエージェント側にコピーされるように、エージェント・キー・パスワードを入力する必要があります。証明書を生成するには、
詳細は、「通信の保護」を参照してください。 |
リソース・リスト |
|
保護されているリソース(URI)リスト |
保護されているアプリケーションのURI: / デフォルト: /** デフォルトは、複数のディレクトリにまたがるゼロまたは複数の中間レベル内にある任意の文字シーケンスに一致します。 リソースの追加: 各URIは、保護されているリソース・リストの表の新しい行で指定する必要があります。「+」ボタンをクリックして、保護されているリソース・リストにリソースを追加します。たとえば、
関連項目: 「リソースURL、接頭辞およびパターン」。 |
パブリック・リソース(URI)リスト |
それぞれのパブリック・アプリケーションは、パブリック・リソース・リストの表の新しい行で指定する必要があります。 リソースの追加: 各URIは、パブリック・リソース・リストの表の新しい行で指定する必要があります。「+」ボタンをクリックして、パブリック・リソース・リストにリソースを追加します。たとえば、
関連項目: 「リソースURL、接頭辞およびパターン」。 |
関連項目: |
Webゲート登録を合理化するために、作成操作時に一部の要素は非表示になり、デフォルト値が適用されます。
ノート:
Oracle Access Managementコンソールを使用して変更した内容は、アプリケーション・サーバーの再起動なしで反映されます。変更内容は、再構成タイムアウト期間後に、自動的に反映されます。
サポートされる一部のパラメータは、管理者が、Webゲートの登録ページで値を直接入力するか、OAMエージェントのリモート登録リクエスト・テンプレートに値を入力することで定義できます。
表15-2に、サポートされるユーザー定義パラメータを示します。各パラメータに指定できる値は1つのみです。
表15-2 ユーザー定義のWebゲート・パラメータ
| ユーザー定義のWebゲート・パラメータ | 説明 |
|---|---|
ChallengeRedirectMethod |
埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対して、このユーザー定義認証POSTデータ保持パラメータを構成します。 値: GET|POST|DYNAMIC ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebゲートが参照されます。そうでない場合、デフォルト動作はDynamicです。 関連項目: 表22-23 |
ChallengeRedirectMaxMessageBytes |
obrareq.cgiおよびobrar.cgiとして受信するメッセージ・データのサイズを制限するためにこのユーザー定義Webゲート・パラメータを構成します。メッセージ・データは、問合せ文字列長(存在する場合)で構成されます。また、POSTデータが存在する場合は、POSTデータ長で構成されます。メッセージ長がこの制限を超える場合、メッセージは処理されることなく、ブラウザには既存メッセージが表示されます。イベントは通常どおり記録されます。 デフォルト: 8192バイト ノート: obrareq.cgiは、WebゲートからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。 obrar.cgiは、OAMサーバーからWebゲートにリダイレクトされる認証レスポンス文字列です。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
MaxPostDataBytes |
埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対する認証POSTデータ保持パラメータ。 このパラメータは、ユーザーの資格証明として送信され、OAMサーバーに転送されるPOSTデータの最大バイト数を制限する正の整数値を必要とします。 デフォルト: 8192バイト MaxPostDataBytesをリソースWebゲートに割り当てることにより、保持するPOSTデータを転送する前にアプリケーションから受信するPOSTデータのサイズを制限するプリファレンスを指定します。 |
MaxPreservedPostDataBytes |
認証POSTデータの保持に対してこのユーザー定義Webゲート・パラメータ(またはユーザー定義認証スキームのチャレンジ・パラメータ)を構成します。 デフォルト: 8192バイト ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebゲートが参照されます。そうでない場合、デフォルト動作は8192バイトです。 このパラメータは、Webゲートが保持できるPOSTデータの最大長を定義します。インバウンド・ロー・ユーザーPOSTデータ(または処理後に暗号化されるPOSTデータ)がこの制限を超えた場合、POSTデータは削除され、既存の認証フローが続行されます。イベントは通常どおり記録されます。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
PostDataRestoration |
埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対する認証POSTデータ保持パラメータ。このパラメータは、 デフォルト値:
関連項目: 「認証POSTデータ・ハンドリングの構成」 |
serverRequestCacheType ECCのみ |
埋込み資格証明コレクタ(ECC)に対する認証POSTデータ保持パラメータ。 oam-config.xml内のこのOAMサーバー・パラメータは、リクエスト・コンテキストを記憶するために使用されるメカニズムを示します。可能な値は、FORM、COOKIEまたはCACHEです。 デフォルト: COOKIE POSTデータを保持するにはFORMが必要です。 関連項目: 表22-23の |
UrlInUTF8Format=true |
Oracle HTTP Server 2を使用する環境では、このパラメータをtrueに設定してラテン1および他の文字セットを表示する必要があります。 |
ProxySSLHeaderVar=IS_SSL |
Webゲートがリバース・プロキシの背後にあり、クライアントとリバース・プロキシの間でSSLが構成されており、リバース・プロキシとWebサーバーの間で非SSLが構成されている場合に使用します。これにより、URLがHTTPではなくHTTPSとして格納されます。プロキシを使用すると、クライアント接続にSSLと非SSLのどちらを使用するかを示すカスタム・ヘッダー変数を設定して、URLがHTTPS形式で格納されます。 ProxySSLHeaderVarパラメータの値はプロキシが設定する必要のあるヘッダー変数の名前を定義します。ヘッダー変数の値は"ssl"または"nonssl"である必要があります。 ヘッダー変数が設定されていない場合、SSL状態は現在のWebサーバーのSSL状態によって決まります。 デフォルト: IS_SSL |
client_request_retry_attempts=1 |
WebGateとOAMサーバーのタイムアウトしきい値は、接続不可能とみなして新しい接続のリクエストを試みるまでのWebGateがOAMサーバーを待機する時間(秒単位)を指定します。 OAMサーバーがリクエストを処理する時間がタイムアウトしきい値を超える場合、Webゲートはそのリクエストを破棄し、新規接続でリクエストを再試行します。 デフォルト: 1 ノート: 接続プールから返された新しい接続は、接続プールの設定に応じて、同じOAMサーバーへのものとなることがあります。また、別のOAMサーバーでも、リクエストの処理に必要な時間が、タイムアウトしきい値に指定された時間よりも長くなる可能性があります。場合によっては、OAMサーバーが停止するまで、Webゲートによる再試行が続行する可能性があります。client_request_retry_attemptsパラメータを使用すると、応答しないサーバーに対するWebGateの再試行の回数を制限できます。 |
InactiveReconfigPeriod=10 |
Webゲート更新スレッドは、Webゲートがアクティブなとき1分間隔で共有シークレットをOAMサーバーから読み取ります。OAMサーバーは、共有シークレットを独自のキャッシュ(OAMサーバー・キャッシュ)に入れて戻します。 デフォルト: 10 (分) 関連項目: パフォーマンスのチューニング |
fallbackToContainerPolicy=true |
IAMSuiteAgentに使用されます。 trueに設定すると、リクエストはコンテナまで到達し、コンテナで構成されているポリシー(J2EEの認証/認可に関係する)を使用してユーザーにアクセス権を付与または拒否します。 デフォルト値: |
logoutRedirectUrl= |
デフォルト = http://OAMServer_host:14200/oam/server/logout |
protectWebXmlSecuredPagesOnly=true |
IAMSuiteAgentに使用されます。ユーザーが認証されると、後続のすべてのリクエストに対してこのパラメータを使用し、エージェントで着信リクエストの検証が必要かどうかが決定されます。設定によって次のようになります。
|
maxAuthorizationResultCacheElems |
認可結果キャッシュの最大要素: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するセッションの認可結果に関する情報を保持します。次に例を示します。 maxAuthorizationResultCacheElems=10000 デフォルト = 100000 関連項目: パフォーマンスのチューニング |
authorizationResultCacheTimeout |
認可結果のキャッシュ・タイムアウト: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するセッションの認可結果に関する情報を保持します。次に例を示します。 authorizationResultCacheTimeout=60 時間が指定されていない場合のデフォルトは、15(秒)です。 ノート: 「認可結果キャッシュのタイムアウト」はデフォルトでは設定されません。 キャッシュが有効になっている場合は、最初のリクエスト結果がキャッシュ期間中保持されます。これにより効果が拡大され、遅延時間が短縮します。たとえば、認証ポリシー・レスポンスを設定し、カスタム・セッション属性exmpl:sampleを設定するとします。これに対応する認可ポリシー・レスポンスは、HEADER SESSION_ATTR_EXMPL=sampleとして返されます。ユーザーが、これらのポリシーによって保護されているURLにアクセスした場合、いくつか更新された後のヘッダーを受信することになります。ただし、最初は値が見つからない可能性もあります。 値が0の場合、キャッシュは無効になります。キャッシュが存在しない場合、ヘッダーのレスポンスに入力するために2つのリクエストが実行されます。1つ目のリクエストでは使用するセッション変数を設定し、2つ目でそのセッション変数を使用します。トリガーした認可リクエスト内にはレスポンス値を設定しないことをお薦めします。 関連項目: パフォーマンスのチューニング。 |
UniqueCookieNames |
WebゲートのCookie名の書式を、次のように制御します。
|
11g Webゲートのみ |
|
SetKeepAlive |
デフォルトでは、SetKeepAliveはONです。この場合、最初のキープアライブ・メッセージは、2分間のデフォルト・アイドル時間の後に送信されます。この動作を変更するには、パラメータに新しい値を設定します。SetKeepAlive=Offである場合、機能は無効となっておりキープアライブ・メッセージは送信されません。SetKeepAlive=x (xはなんらかの正の整数値)である場合、キープアライブ・メッセージは、チャネルが アイドル時間をプログラム的に変更する方法は、Linux64、Linux32およびWindows32のWebGateに実装されています。この機能は、SPARC Solarisプラットフォームには対応してません。その場合には、SetKeepAliveを有効化して、管理者がキープアライブのアイドル時間を手動設定する必要があります。 |
filterOAMAuthnCookie |
11g Webゲートでは、セキュリティを考慮してユーザー定義パラメータ( |
ssoCookie |
OAMAuthnCookieのCookieを制御します。 デフォルト: ssoCookie=httponly ssoCookie=Secure どちらかの設定を無効にします。 ssoCookie=disablehttponly ssoCookie=disableSecure ノート: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。
関連項目: |
miscCookies |
その他の各種のAccess Manager内部Cookiesを制御します。デフォルトでは、httponlyは、その他の(各種の)すべてのCookiesに対して有効化されています。 デフォルト: miscCookies=httponly miscCookies=Secure どちらかの設定を無効にします。 miscCookies=disablehttponly miscCookies=disableSecure ノート: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。
関連項目: |
obSSOCookieCoExConfig |
OAM 10gの共存中にObSSOCookieに設定されたCookieプロパティを制御します。 デフォルト: obSSOCookieCoExConfig=httponly obSSOCookieCoExConfig=Secure どちらかの設定を無効にします。 obSSOCookieCoExConfig=disablehttponly obSSOCookieCoExConfig=disableSecure 両方の設定を無効にします。 obSSOCookieCoExConfig=disableSecure;disablehttponly 共存に使用される部資格証明コレクタ対応の11g Webゲート(DCCまたはDCCトンネリング)の場合は、エージェント登録ページでこのパラメータを設定します。Oracle Fusion Middleware Oracle Identity and Access Management移行ガイドの共存に関する章を参照してください。 |
OAMAuthAuthenticationServiceLocation 11g Webゲート非ブラウザ・クライアント機能 |
非ブラウザ・クライアント機能をアクティブ化し、認証サービスの場所を定義します。
たとえば、Identity Connectに対してこの機能をアクティブ化する場合は、次のようになります。 OAMAuthAuthenticationServiceLocation=https://login.example.com/nbc
このパラメータが省略(または値なしで設定)された場合、非ブラウザ・クライアント機能は非アクティブになります。 |
OAMAuthUserAgentPrefix 11g Webゲート非ブラウザ・クライアント機能 |
非ブラウザ・クライアント機能をアクティブ化し、user-agent HTTPヘッダー値の接頭辞として機能する文字列を定義します。
たとえば、Identity Connectに対してこの機能をアクティブ化する場合は、次のようになります。 OAMAuthUserAgentPrefix=NBC このパラメータが省略(または値なしで設定)された場合、非ブラウザ・クライアント機能は非アクティブになります。 |
RequestContextCookieExpTime |
OAMRequestContext Cookieの有効期限が切れる時間(秒単位)を制御します。Cookieライフタイムの構成は、Cookieが急増した状況に対応する必要があるデプロイメントでの制御オプションです。 デフォルト: 設定なし リソースWebゲートの登録では、このパラメータを追加して、IEブラウザ以外のすべてのブラウザに対してMax-Ageディレクティブを使用して、構成されている秒数(デフォルトは5分)でOAMRequestContext Cookieの有効期限が切れるようにします。 ノート: IEユーザーは、Expiresディレクティブを使用して、絶対時刻でCookieの有効期限を制御するため、Internet Explorerの場合のみ、ブラウザとWebサーバー・ホスト間の時間同期が必要です。ただし、IEブラウザで、このパラメータを設定しない場合、OAMRequestContext Cookieは一時セッションCookieになります。 IE以外の他のブラウザでは、Cookieは永続Cookieになり、Max-Ageディレクティブを使用して設定される時刻に基づいて有効期限が制御されます。 関連項目: 表21-6のOAMRequestContext |
ProxyTrustedIPList |
信頼できるプロキシやロード・バランサのIPアドレスのリストを保持する複数値のパラメータです。「ProxyTrustedIPList」を参照してください。 |
ProxyRemoteIPHeaderVar |
IPアドレスのリスクを含むHTTPヘッダーの名前を指定します。「ProxyRemoteIPHeaderVar」を参照してください。 |
IPアドレス検証は、クライアントのIPアドレスと、シングル・サインオン用に生成されるCookieに格納されているIPアドレスが同じであるかどうかを確認する機能です。IPValidationパラメータは、IPアドレス検証のオンとオフを切り替えます。これはWebGate固有のパラメータであり、WebGateプロファイルの中にあります。
IPValidationがtrueの場合は、Cookieに格納されているIPアドレスとクライアントのIPアドレスが一致する必要があり、一致しない場合はSSO Cookie (表1-2)が拒否されるため、ユーザーは再認証が必要になります。IPValidationは、デフォルトでfalseです。IP検証の有効化および無効化に関して、次が該当します。
WebゲートでIP検証を有効にすると、OAMサーバー側で自動的に有効になり、Access Managerの設定で確認できます。
WebゲートでIP検証を無効にしても、OAMサーバー側では無効になりません。
すべてのWebゲートで無効になっている場合に(のみ)、OAMサーバー側のIP検証を手動で無効にする必要があります。
Webゲート側でIP検証が有効な場合、サーバー側IP検証は無効にしないでください。
ノート:
現在のAccess Managerは、IPv4に加えてインターネット・プロトコル・バージョン6 (IPv6)もサポートしています。
Webゲートと認証時にクライアントIPアドレスを持たないアクセス・クライアントの間のシングル・サインオンを構成する場合は、IP検証オプションを明示的に無効にできます(「IPValidation」をfalseに設定します)。「IPValidation」パラメータをfalseに設定すると、ブラウザまたはクライアントのIPアドレスは、SSO Cookieの構成要素として使用されなくなります。ただし、IP検証は、可能なかぎり有効にしておくことをお薦めします。Webゲート・プロファイル構成の詳細は、「コンソール内のOAMエージェント登録ページの表示または編集」を参照してください。さらなる詳細は、次の項を参照してください。
IP検証パラメータによって、ある一定のWebアプリケーションのデプロイメントに問題が生じる可能性があります。
たとえば、プロキシ・サーバーで管理されるWebアプリケーションは、通常、ユーザーのIPアドレスをプロキシのIPアドレスに変更します。これは、Cookieを使用したシングル・サインオンの妨げになります。「IPValidationException」パラメータには、この検証プロセスの対象として例外となるIPアドレスをリストします。IPValidationがtrueの場合には、IPアドレスはIP検証例外リストと比較されます。そのアドレスがリストにある場合、そのアドレスはCookieに格納されたIPアドレスと一致する必要はありません。
必要なだけの数のIPアドレス(クライアントの実際のIPアドレスであり、ObSSOCookie SSO Cookieに格納されたIPアドレスではありません)を例外リストに追加できます。SSO Cookieが例外IPアドレスのいずれかである場合、アクセス・システムはそのSSO Cookieに格納されているアドレスの検証を省略します。(CookieのIPアドレスがリバース・プロキシ用のアドレスである場合には、IP検証例外リストのIPアドレスを使用できます。)
(プロキシ・サーバーまたは)ロード・バランサの場合、攻撃者が例外リストに定義されているIPアドレスを使用する可能性があるため、Oracle Access Managerは真のIPの検証を強制できません。したがって、管理されたWebアプリケーションは、通常、ユーザーのIPアドレスを(プロキシまたはロード・バランサのIPアドレスに)変更します。これによって、SSO Cookieを使用したシングル・サインオンを防止できます。
ロード・バランサは、リクエスタの本来のIP番号がカンマとスペースで区切られているリストを含むX-forwarded-forヘッダ変数を、受信したHTTPリクエストに追加します。リクエストがproxy1、proxy2そしてproxy3 (proxy3がリクエストのリモート・アドレスであるように見えます)を通過する次の例を考えてみましょう。最後のIPアドレスは、必ず、最後のプロキシに接続するIPアドレスです。
X-Forwarded-For: client1, proxy1, proxy2
ヘッダーから各IPアドレスを検索するために、一番右の値から信頼リストを参照します。一番左のIPアドレスは下流側で最も遠いクライアントであり、その後ろにリクエストが通過するプロキシがそれぞれ続きます(リクエストを受信したIPアドレスを追加)。
指定された順番の中で、信頼リストの中のどれとも一致しないIPアドレスの最初のものは、(信頼可能な通信パスに沿った最遠ノードに対する接続の起動側のIPアドレスとして定義される)見かけのクライアントIPとして取り扱われます。次の点にも留意してください。
ヘッダー内のすべてのIPアドレス(右側から順に)が信頼リストのエントリに一致する場合には、WebGateはエンド・クライアントIP(ヘッダー内で一番左のIPアドレス)を選択します。
IPアドレスが決定したところで、WebGateは見かけのクライアントIPアドレスが格納されているセッション・トークンを獲得し、IPアドレスをセッション・トークン内のアドレスと比較することによって、IP検証が評価されます。
負荷分散されたデプロイメント内でIP検証機能が有効化されている場合には、認証(セッションの作成)と認可がこの機能を有するWebGateによって実行されますが、有効化されていない場合には、認証されたユーザーは再認証の必要があります。WebGateが特定のHTTPヘッダーを検索する場合には、大文字と小文字は区別されません。たとえば、X-Forwarded-ForとX-FORWARDED-FORは同じものとして扱われます。
ProxyTrustedIPListは、信頼できるプロキシやロード・バランサのIPアドレスのリストを保持する、ユーザー定義の複数値WebGateパラメータです。
値は、空白で区切られます。CookieのIPアドレスがリバース・プロキシ用のアドレスである場合には、IP検証例外リストのIPアドレスを使用できます。
図15-2では、エンド・ユーザーのHTTPリクエストは、REVERSEPROXY1とREVERSEPROXY2を通過して実際のWebサーバーに到達しています。この場合、REVERSEPROXY1とREVERSEPROXY2のIPアドレスは、次のようにProxyTrustedIPListリストに追加する必要があります。
ProxyTrustedIPList=10.77.199.59 10.77.199.26
ノート:
集中認証デプロイメントでは、リソースWebGate (RWG)または認証WebGate (AWG)のどれかがプロキシの先にある場合には、プロキシの先のWebGateのプロファイルの中に、すべての仲介サービスのIPアドレスを(ProxyTrustedIPListパラメータ内に)構成する必要があります。そうしないと、IP検証が失敗する可能性があります。
ProxyRemoteIPHeaderVarパラメータは、IPアドレスのリスクを含むHTTPヘッダーの名前を指定します。
このパラメータが提供されない場合には、デフォルトヘッダーのX-Forwarded-Forが使用されます。このパラメータは、WebGateプロファイル内の他のどのユーザー定義パラメータとも同じように構成できます。たとえば、「ProxyTrustedIPList」で説明したデプロイメントでは、"X-FORWARDED-FOR"およびWebサーバーに到達するそれ以外のヘッダーは、次の形式となります。
HTTP_X_FORWARDED_FOR="10.77.199.129, 10.77.199.59" REMOTE_ADDR="10.77.199.26"
