| Oracle Access Managerアクセス管理ガイド 10g（10.1.4.3） B55477-01 |
|
 戻る |
 次へ |
WebGate、アクセス・ゲートおよびアクセス・サーバーは、ユーザーが保護されたリソースにアクセスしようとする際のキー・ポイントとなるコンポーネントです。アクセス・サーバーは、認証、認可および監査エンジンとなります。WebGateを、保護対象となるWebコンテンツをホストする各Webサーバーにインストールします。WebGateはサーバー上のWebコンテンツに対するHTTPリクエストを捕捉してアクセス・サーバーに転送します。アクセス・ゲートは、HTTPリソースのみでなく非HTTPリソースに対するリクエストも捕捉できるカスタムWebGateです。
この章では、アクセス・ゲートおよびアクセス・サーバーのインスタンスを定義および管理する方法について説明します。
この章の内容は次のとおりです。
アプリケーションやコンテンツに対するアクセス制御は、E-Businessインフラストラクチャにとって基本となるものです。特定のリソースの使用（アクセス）を、ユーザーに応じて許可または拒否する必要があります。会社のリソースへのアクセスの制御には、アクセス・システムを使用します。アクセス・システムには1つのサーバーと複数のプラグインからなるベース・コンポーネントが提供されており、それらを基盤としてアクセス制御を定義できます。
次の各項では、アクセス・システムのベース・コンポーネントの設定について説明します。これらのコンポーネントは、リソースへのユーザー・アクセスの制御を可能にする基盤ソフトウェアです。
『Oracle Access Manager概要』およびこのマニュアルで説明しているように、アクセス・システムの主要コンポーネントは次のとおりです。
WebGate: WebGateは、追加設定なしにそのままの状態で保護対象の各サーバーにインストールされるプラグインです。WebGateはWebリソース（HTTP）リクエストを捕捉し、それらを認証と認可のためにアクセス・サーバーに転送します。
アクセス・ゲート: ユーザーまたはアプリケーションからのリソース・リクエストを処理する、カスタムのWebGateです。WebGateは、リソースに対するユーザー・リクエストを捕捉して、それらを認証および認可用にアクセス・サーバーに転送します。WebGateと異なるのは、非HTTPリソースへのリクエストを捕捉するカスタムのアクセス・ゲートを定義できる点です。
アクセス・サーバーとWebGateによるリソース保護の方法の詳細は、「アクセス時のログイン手順」を参照してください。
アクセス・システムを管理するには、ポリシー・マネージャとアクセス・システム・コンソールからなるWebベースのユーザー・インタフェースを使用します。
ポリシー・マネージャ: アクセス・システム・アプリケーションの1つ。リソースの保護に使用するポリシー・ドメインの作成と管理、およびポリシーの強制のテストができます。
アクセス・システム・コンソール: アクセス・システム・アプリケーションの1つ。次の構成タスクおよび管理タスク用の機能を提供します。
システム構成: 管理者およびサーバー設定を構成する機能があります。「サーバー設定の表示」ページには、電子メール、シングル・サインオン・ログアウトURLおよびディレクトリ・サーバーに関する情報が表示されます。詳細は、「アクセス管理者およびサーバー設定の構成」を参照してください。
システム管理: 診断の実行、ユーザー・アクセス権限レポートの管理および同期レコードの管理を行うアクセス・サーバーを指定できます。詳細は、「アクセス・システムの構成および管理の概要」を参照してください。
アクセス・システム構成: 次の機能があります（「アクセス・システム構成ファイルの管理」も参照）。
Oracle Access Manager 10.1.4を、『Oracle Access Managerインストレーション・ガイド』の手順に従ってインストールおよび設定しておく必要があります。『Oracle Access Manager概要』には、その他のマニュアルにはないOracle Access Managerの概要が記載されています。また、アクセス・システムの各アプリケーション、インストール、構成、管理および共通機能が説明されている『Oracle Access Manager IDおよび共通管理ガイド』の内容も十分に理解しておく必要があります。
『Oracle Access Managerインストレーション・ガイド』の手順に従って、少なくとも1つのアクセス・サーバーをインストールする必要があります。ユーザーに対して安定したサービスを保証するため、2つ以上のアクセス・サーバーを複数のコンピュータにインストールすることをお薦めします。各アクセス・サーバーは、1つ以上のアクセス・ゲート・インスタンスおよび1つのディレクトリ・サーバーと通信できるように構成する必要があります。
アクセス・システムを構成するには、適切な権限が必要です。詳細は、「アクセス管理者およびサーバー設定の構成」を参照してください。
「アクセス・サーバー・インスタンスの追加」の手順に従って、アクセス・システム・コンソールでアクセス・サーバー・インスタンスを作成します。
『Oracle Access Managerインストレーション・ガイド』の手順に従って、アクセス・サーバーをインストールします。「アクセス・サーバー詳細の変更」の手順に従って、アクセス・サーバーを構成します。
Oracle Access Managerホストのクロックを同期化します。
アクセス・サーバーのクロックは、WebGateのクロックより進んでいる場合にかぎり、60秒以内の時間差が許容されます。WebGateのクロックをアクセス・サーバーのクロックよりも早めることは許可されません。
複数のアクセス・サーバーをいくつかのタイムゾーンで稼働する場合には、各サーバーのアクティビティをグリニッジ標準時（GMT）で記録します。Oracle Access Managerホストのクロック同期化はきわめて重要です。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アクセス・サーバーが対話するディレクトリを調整して、パフォーマンスを最適化します。
詳細は、ディレクトリのベンダーのドキュメントを参照してください。Oracle Internet Directoryの詳細は、『Oracle Internet Directory管理者ガイド』でパフォーマンスの最適化に関する章を参照してください。
アクセス・システム・コンソールの「アクセス・システム構成」機能を使用すると、次のようないくつかの重要なタスクを行うことができます。
アクセス・システム・コンソールでは、構成済のすべてのアクセス・サーバーを表示できます。
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」をクリックして、「アクセス・サーバー構成」を選択します。
構成ランディング・ページに、既存のアクセス・サーバーがリストされます。
構成を表示するアクセス・サーバーを選択します。
そのアクセス・サーバーの構成詳細が表示されます。次の項に説明があります。次項のパラメータの構成方法の詳細は、「アクセス・サーバー・インスタンスの追加」を参照してください。
アクセス・サーバー構成パラメータは、アクセス・システム・コンソールの「アクセス・サーバー構成」ページに表示されます。表3-1に、構成パラメータをリストします。
表3-1 アクセス・サーバー構成パラメータ
| フィールド | 説明 |
|---|---|
|
アクセス・サーバーの名前。 |
|
|
ホスト名 |
アクセス・サーバーをホストするWebサーバーの名前。 |
|
ポート |
アクセス・サーバーがリスニングするポートの番号。 |
|
デバッグ |
デバッグ機能をオンまたはオフのいずれにするかを示します。詳細は、「アクセス・サーバー・インスタンスの追加」を参照してください。 |
|
デバッグ・ファイル名 |
デバッグ・ファイルへの絶対パスも示します。ファイルが存在しない場合は、アクセス・サーバーを再起動すると作成されます。 |
|
アクセス・サーバーとの間のトランスポートのセキュリティ・レベル。 使用可能なオプションは次のとおりです。 オープン: トランスポート・セキュリティなし。 シンプル: 証明書が事前にパッケージされる、暗号化によるトランスポート・セキュリティ。 証明書: 暗号化によるトランスポート・セキュリティ。 |
|
|
アクセス・サーバーで許容されるサービスのスレッドの最大数。デフォルトでは60に設定されます。 このスレッド数はシステム・パフォーマンスに影響する場合があります。詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。 |
|
|
アクセス管理サービスが有効（オン）か無効（オフ）かを識別します。この設定はデフォルトでは「オフ」です。「オン」に設定すると、アクセス・サーバーはアクセス・ゲートからのリクエストの処理を開始します。アクセス管理サービスは、関連付けられたアクセス・サーバーとアクセス・ゲートに対して「オン」にする必要があります。「アクセス・ゲート構成パラメータ」も参照してください。 |
|
|
監査情報をデータベースに書き込むかどうか。この値を「オン」に設定する場合は、サポートされるデータベースをインストールし、さらに構成する必要があります。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
|
|
監査情報をファイルに書き込むかどうか。 |
|
|
監査ファイルの最大サイズ（バイト数）。 |
|
|
監査バッファのサイズ（バイト数）。 |
|
|
この監査ファイルが存続可能な時間（秒数）。 |
|
|
このサーバーの構成が更新される周期（秒数）。 注意: このパラメータに加えた変更は、変更前のエンジン構成リフレッシュ期間が満了するまでは有効にされません。 |
|
|
このアクセス・サーバーのキャッシュ内に保存できる認証済ユーザーの数。 デフォルトは10000です。値が-1の場合、キャッシュは無効になります。 |
|
|
非アクティブなユーザーのデータをキャッシュ内に保存する最大時間（秒数）。 |
|
|
ポリシー・キャッシュ内に格納できる要素の最大数。 |
|
|
非アクティブなポリシーのデータをキャッシュ内に保存する最大時間（秒数）。 |
|
|
SNMPが有効になっているかどうかを示します。SNMPモニタリングの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
|
|
SNMPエージェントのポート番号。 |
|
|
セッション・トークン・キャッシュは、アクセス・サーバーでユーザーのセッション・トークンを復号化するときに使用できます。このパラメータを有効にすると、復号化されたセッション・トークンがキャッシュ内にあるかどうかがアクセス・サーバーによってチェックされます。無効にすると、着信するセッション・トークンがアクセス・サーバーによって復号化されます。セッション・トークンの詳細は、「シングル・サインオンのCookie」を参照してください。 |
|
|
キャッシュ内に保存できる、復号化されたセッション・トークンの最大数。Access Systemで管理されるユーザー数が多くアクティビティ率が高い場合には、このキャッシュのサイズが非常に増大することがあるため、キャッシュを定期的に調整する必要があります。デフォルト値は10,000です。 |
アクセス・サーバーをインストールする前に、アクセス・システム・コンソールで新規インスタンスを追加する必要があります。この時点で指定が必須なのは、アクセス・サーバーの名前、ホスト名、ポートおよびトランスポート・セキュリティ・モードのみです。インスタンスの構成は、インストール後に変更できます。
次の手順に、インスタンスの追加および構成方法を示します。
|
注意: アクセス・サーバー・インスタンスは、インストールするに先立ち、アクセス・システム・コンソールに追加する必要があります。 |
アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・サーバー構成」の順にクリックします。
「アクセス・サーバー構成」ページが表示されます。
「追加」をクリックします。
「新規アクセス・サーバーの追加」ページが表示されます。
「名前」、「ホスト名」および「ポート」フィールドには、情報の入力が必須です。それ以外のフィールドはすべてオプションです。
「名前」フィールドで、このサーバーの名前を入力します。
英数字をスペースなしで入力してください。
|
注意: アクセス・ゲートとアクセス・サーバーに同じ名前を付けることはできません。 |
各アクセス・ゲートとポリシー・マネージャからこのアクセス・サーバーに送信されるすべてのメッセージを取得するには、「オン」をクリックします。
デバッグ・ファイルがある場合は、メッセージはデバッグ・ファイルに格納されます。そうでない場合は、stderrに出力されます。
このメッセージ情報を取得しない場合は、「オフ」をクリックします。
メッセージの取得により、アクセス・ゲート・インスタンスとこのアクセス・サーバーとの間で通信が行われていることが確認できます。
|
注意: デバッグ・メッセージを取得すると、ユーザー・パスワードおよび潜在的なセキュリティ上の問題が記録されるため、アクセス・サーバーのログ・ファイルのサイズは急激に増大します。このデバッグ機能は、問題の診断時にのみ使用してください。 |
「トランスポート・セキュリティ」フィールドで、このアクセス・サーバーとその通信相手として構成済のアクセス・ゲートとの間でメッセージを暗号化するメソッドを選択します。
相互に通信するように構成したアクセス・ゲートとアクセス・サーバーには、同じ暗号化メソッドを選択する必要があります。
選択肢は、「オープン」、「シンプル」または「証明書」モードです。
トランスポート・セキュリティ・モードの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
「最大クライアント・セッション時間（時間）」フィールドに、アクセス・ゲートとこのアクセス・サーバーとの間で維持可能な接続の時間数を入力します。
デフォルト値は24時間です。
このセッション時間が長くなるほど、システムは攻撃に対して脆弱になります。
「スレッド数」フィールドに、このアクセス・サーバーで開始されるスレッドの数を入力します。
デフォルト値は100、最小値は1です。
「アクセス管理サービス」で、使用環境に合せてオプションを選択します。
|
注意: アクセス・ゲートに関連付けられているアクセス・サーバーでは、「アクセス管理サービス」を必ず「オン」にしてください。WebGateでは、関連付けられているアクセス・サーバーで「アクセス管理サービス」を「オン」にしていない場合、「アクセス管理サービス」を「オン」にする必要はありません。キャッシングの詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。 |
自動キャッシュ・フラッシュには、アイデンティティ・サーバーに付随しているAccess Manager SDKが必要です。自動キャッシュ・フラッシュ中に、アイデンティティ・システムはアクセス・ゲートを使用してアクセス・サーバーと通信します（SDKで使用可能なAPIを使用）。この場合は、アクセス・サーバーと関連付けられているアクセス・ゲートの両方のプロファイルで「アクセス管理サービス」を「オン」に設定する必要があります。詳細は、「アクセス・ゲート構成パラメータ」を参照してください。
使用環境に必要な監査オプションを選択します。
データベースの監査（オン/オフ）: 「オン」を選択するには、『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って、アクセス・システムの所定の構成と、サポートされるデータベースのインストールが必要です。
ファイルの監査（オン/オフ）: 「オン」を選択すると、次の追加項目を指定するよう要求されます。
監査ファイル名: このアクセス・サーバーの監査ファイルへのパスを入力します。このファイルは、アクセス・サーバーをホストするコンピュータ上に格納されています。各アクセス・サーバーには固有の監査ファイルがあります。監査ファイルに取得される情報は、マスター監査ルールによって決定されます。詳細は、「マスター監査ルールの概要」を参照してください。
監査ファイルのサイズ（バイト）: この監査ファイルに格納できるバイト数を入力します。デフォルトのサイズを変更する場合は、変更の確定後にサーバーを再起動する必要があります。最大サイズに到達すると、現在のファイルは日付と時刻からなるファイル名を付けてクローズされ、最初の名前と同じ監査ファイルが新たに作成されます。
「バッファ・サイズ（バイト）」フィールドで、この監査ファイルのバッファに保持できるバイト数を入力します。
デフォルト値は512000です。バッファを使用すると、情報を監査ファイルに読み取る頻度が減少するため、パフォーマンスが向上します。
このフィールドに値を入力すると、監査ファイルに書き込まれる監査情報がそのバイト数に到達するまでは、監査情報はバッファに格納されます。バッファが指定したサイズに到達すると、バッファの内容は監査ファイルに転送されます。
このフィールドに0を入力した場合は、監査情報は監査ファイルに直接書き込まれます。
「ファイル・ローテーション間隔（秒）」フィールドで、この監査ファイルが存続可能な秒数を入力します。
デフォルト値は0です。設定値0は監査ファイルがタイムアウトにならないことを意味し、このファイルには監査情報が無期限に追加されていきます。
この間隔が経過すると、ファイルのローテーションが行われます。つまり、そのファイルは日付と時刻からなる名前を付けてクローズされ、最初の名前と同じ監査ファイルが新たに作成されます。
「エンジン構成リフレッシュ期間（秒）」フィールドで、このサーバーの構成変更が有効化される間隔を秒数で入力します。
デフォルト値は14400です。14400という設定値は、監査ファイル名と関連パラメータが4時間ごとにリフレッシュされることを意味します。0に設定した場合、リフレッシュは行われません。構成変更はサーバーの起動時にロードされ、サーバーの稼働中は不変です。
構成変更は、このフィールドに指定した間隔で実施されます。たとえば、600秒と入力した場合は、構成変更は10分以内に実施されます。
詳細は、「アクセス・サーバー詳細の変更」を参照してください。
|
注意: このパラメータに加えた変更は、変更前のエンジン構成リフレッシュ期間が満了するまでは有効にされません。 |
「URL接頭辞リロード間隔（秒）」フィールドで、このアクセス・サーバーによって新しいURLが認識される周期を数値で入力します。
デフォルト値は7200です。
たとえば、このフィールドに600と入力した場合（600秒 = 10分）、URLは10分ごとにディレクトリ・サーバーからリロードされます。この機能は、特定のURL接頭辞キャッシュ・フラッシュ・リクエストがアクセス・サーバーに着信しなかった場合に有用です。
「パスワード・ポリシーのリロード間隔（秒）」フィールドで、パスワード・ポリシーのリロード間隔を秒数で入力します。
デフォルト値は7200です。
「ユーザー・キャッシュ内の最大要素」フィールドで、アクセス・サーバーのキャッシュ内に保存できる認証済ユーザーの数を入力します。
デフォルトは10000です。値が-1の場合、キャッシュは無効になります。
最大数に到達すると、キャッシュにおいて、最も古いユーザー・アクティビティが削除され、最新のユーザー・アクティビティが追加されます。
「ユーザー・キャッシュのタイムアウト（秒）」フィールドで、ユーザー・キャッシュにおいてエントリがパージされるまでに存続できる秒数を入力します。
デフォルト値は1800（30分）です。タイムアウト値0は、キャッシュ要素が期限切れにならないことを意味します。
キャッシュ内のユーザー・エントリがタイムアウトになった後では、アクセス・サーバーは、認証および認可アクションの実行時に、必要なユーザー・プロファイル・データをディレクトリ・サーバーから取得します。
「ポリシー・キャッシュ内の最大要素」フィールドで、ポリシー・ドメイン内のアクティビティに関連付けられている、キャッシュ可能なアイテムとアクティビティ（特定のルールにマップされているURLなど）の数を入力します。
デフォルト値は100000です。
最大数に到達すると、キャッシュにおいて、最も古いユーザー・アクティビティが削除され、最新のユーザー・アクティビティが追加されます。
「ポリシー・キャッシュ・タイムアウト」フィールドで、ポリシーに関するエントリがパージされるまでに存続できる秒数を入力します。
デフォルト値は7200（2時間）です。
「セッション・トークン・キャッシュ」を「有効」または「無効」に設定します。
このパラメータを有効にすると、セッション・トークンはアクセス・サーバーによってキャッシュ内に格納されます。セッション・トークンの詳細は、「シングル・サインオンのCookie」を参照してください。
セッション・トークン・キャッシュ内に格納できる要素の最大数を指定します。
このキャッシュはサイズが非常に大きくなることがあるため、この最大数は定期的に調整することが必要です。
この新しいアクセス・サーバーを保存する場合は、「保存」をクリックします。または、保存しないでページを終了する場合は、「取消」をクリックします。
E-Businessインフラストラクチャにインストールするアクセス・サーバーごとに、この手順のステップを繰り返します。
これで、アクセス・サーバー・インスタンスが作成し終わり、インストール可能になりました。インストール時には、このページで入力した名前、ホスト名およびポート番号を使用します。
アクセス・サーバーのインストールの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アクセス・サーバーのインストール中に、そのアクセス・サーバー用のデフォルトのディレクトリ・プロファイルが作成されます。このプロファイルを表示および変更する方法の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のディレクトリ・プロファイルに関する情報を参照してください。
複数のアクセス・サーバー・インスタンスをインストールする場合、各サーバーには同一のデフォルト・ディレクトリ・サーバー・プロファイルが使用されます。特定のアクセス・サーバー・インスタンスに対して共有のディレクトリ・サーバー・プロファイルを変更すると、それ以外のアクセス・サーバー・インスタンスがすべて影響を受けます。これらのサーバーに対してもプロファイルを変更しないと、次のいずれかを行うたびに警告が表示されます。
サーバー構成の表示
サーバーの再起動
サーバーの再構成
アクセス・サーバーの構成設定の変更が必要となる場合があります。アクセス・サーバー・インスタンスを変更するには、アクセス・システム・コンソールを使用します。アスタリスク記号付きのフィールドを変更した場合は、アクセス・サーバーの再起動が必要です。
|
注意: アクセス・サーバーの名前は変更できません。アクセス・サーバー・インスタンスに新しい名前を付けるには、現在のインスタンスを削除およびアンインストールし、新規インスタンスを作成する必要があります。 |
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」→「アクセス・サーバー構成」の順にクリックします。
「アクセス・サーバー構成」ページが表示されます。このページには、構成済の各アクセス・サーバーの名前、ホストおよびポートがリストされます。
変更するアクセス・サーバーのリンクをクリックします。
表示された「アクセス・サーバーの詳細」ページで、「変更」をクリックします。
「アクセス・サーバーの変更」ページが表示されます。すべてのパラメータの詳細は、「アクセス・サーバー構成パラメータ」を参照してください。
新しい値を入力します（「アクセス・サーバー・インスタンスの追加」を参照）。
「キャッシュの更新」を選択すると、変更内容がただちにこのアクセス・サーバーのキャッシュに送信されます。
変更内容を保存する場合は「保存」を、保存しない場合は「取消」をクリックします。画面は自動的に前のページに戻ります。
アクセス・サーバーをシステムから削除するには、その構成済インスタンスを削除してからアンインストールする必要があります。
アクセス・サーバーを削除すると、そのアクセス・サーバーにリクエストを送信するよう構成済のすべてのアクセス・ゲート・インスタンスに自動的に通知されます。アクセス・サーバーを削除する前に、すべてのアクセス・ゲート・インスタンスが、それ以外の1つ以上のアクセス・サーバーにリクエストを送信するよう構成済であることを確認する必要があります。
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」→「アクセス・サーバー構成」の順にクリックします。
既存のアクセス・サーバーがページにリストされます。
削除するサーバーを選択します。
「削除」をクリックします。
決定の確認を求められます。
インスタンスを削除する場合は、「OK」をクリックします。または、削除を中止する場合は、「取消」をクリックします。
アクセス・サーバーをアンインストールします。
Oracle Access Managerの実装規模が大きい場合、数千単位のアクセス・ゲートが使用されることがあります。新規のアクセス・サーバーを追加するたびに、管理者はそのアクセス・サーバーと通信するすべてのアクセス・ゲートを手動で構成する必要があります。管理者はさらに、『Oracle Access Managerデプロイメント・ガイド』の手順に従って、新規のアクセス・サーバーに対してフェイルオーバーとロード・バランシングも構成する必要があります。
こうした構成タスクへの対処に要する時間を短縮するには、構成タスクの一部がOracle Access Managerによって自動的に実行されるように、複数のアクセス・サーバーをクラスタにグループ化します。クラスタを作成した後、そのクラスタにアクセス・サーバーを追加するとともに1つ以上のアクセス・ゲートを関連付けます。クラスタに関連付けたすべてのアクセス・ゲートは、そのクラスタ内のすべてのアクセス・サーバーと通信するよう、Oracle Access Managerによって自動的に構成されます。
次の管理タスクを実行できるのは、アクセス・サーバー・クラスタに対する適切な管理権限を持っているマスター・アクセス管理者または委任アクセス管理者です。
複数のクラスタへの同一アクセス・サーバーの追加
1つのクラスタへの複数のアクセス・ゲートの関連付け
1つのアクセス・ゲートへの複数のクラスタの関連付け
Oracle Access Managerにより、クラスタ内のすべてのアクセス・サーバーに対してフェイルオーバーとロード・バランシングが動的に構成されるため、リクエストはそれらのアクセス・サーバーに最低限の負荷で確実にルーティングされます。フェイルオーバーの構成の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」ページで、「アクセス・サーバー・クラスタ」をクリックします。
既存のアクセス・サーバー・クラスタがページにリストされます。
「追加」をクリックします。
「アクセス・サーバーの新規クラスタの作成」ページが表示されます。
クラスタに一意の名前を入力します。
クラスタのトランスポート・セキュリティ・モードを選択します。
デフォルト値は「オープン」モードです。「オープン」、「シンプル」または「証明書」から選択できます。同一クラスタ内のアクセス・サーバーには、すべて同じトランスポート・セキュリティ・モードを設定する必要があります。
オン: 「オン」ボタンをクリックします。
オフ: デフォルトでは「オフ」に設定されます。
次のページに進む場合は、「次へ」をクリックします。または、クラスタを保存しない場合は、「取消」をクリックします。
次のページで、リスト内のいずれかのアクセス・サーバーをクリックして、クラスタに追加するアクセス・サーバーを選択します。
クラスタに指定されているアクセス・サーバーと同じトランスポート・セキュリティ・モードおよびアクセス管理サービス状態（ポリシー・マネージャAPIサポート・モードとも呼ばれる）を持つアクセス・サーバーのみが、アクセス・システムによって表示されます。
アクセス・サーバーをクラスタに追加するには、二重右矢印（>>）ボタンをクリックします。
クラスタからアクセス・サーバーを削除するには、「クラスタのアクセス・サーバー」ボックスでそのアクセス・サーバーを選択してから、二重左矢印（<<）ボタンをクリックします。
変更内容を保存する場合は、「保存」をクリックします。または、保存しない場合は、「取消」をクリックします。
「戻る」をクリックすると、最初のページに戻ります。
アクセス・システム・コンソールを起動し、「アクセス・サーバー・クラスタ」をクリックします。
既存のアクセス・サーバー・クラスタがページにリストされます。
詳細を表示するクラスタをクリックします。
「アクセス・サーバー・クラスタの詳細」ページが表示されます。そのクラスタ内の各アクセス・サーバーの詳細がリストされます。
クラスタの詳細を変更するには、「変更」をクリックします。
「クラスタの変更」ページが表示されます。
必要に応じてアクセス・サーバーを追加または削除します。
クラスタにアクセス・サーバーを追加するには、使用可能なアクセス・サーバーのリストからサーバーを選択し、「>>」ボタンをクリックすると、そのサーバーがクラスタに追加されます。
クラスタからアクセス・サーバーを削除するには、「クラスタのアクセス・サーバー」ボックスからサーバーを選択し、「<<」ボタンをクリックすると、そのサーバーがクラスタから削除されます。
「保存」をクリックします。または、変更内容を保存しない場合は、「取消」をクリックします。
インストール・パラメータとその値が含まれるファイルを使用して、アクセス・サーバーのインストールを自動的に実行できます。この方法は、サイレント・モードのインストールと呼ばれます。サイレント・モードでは、ユーザーが操作しなくてもインストールができます。
アクセス・サーバーをサイレント・モードでインストールする手順
コマンドラインで、次のコマンドを入力します。
configureAAAServer.exe install install_dir -S -f aaa_input.xml
ここで、aaa_input.xmlは、インストール・パラメータとその値が含まれるファイルです。
アクセス・システムには、aaa_input.xmlおよびsilent-mode-sample-AAA-Input.xmlという2つのサンプル入力ファイルが用意されています。これらのファイルは次の場所にあります。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
ここで、AccessServer_install_dirは、アクセス・サーバーのインストール先ディレクトリです。サイレント・モードでのインストールの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アクセス・サーバー関連の管理タスクは、configureAAAServerというコマンドライン・ツールを使用して実行できます。このツールは、WindowsおよびSolarisのどちらのインストールでも使用可能です。
configureAAAServerツールで使用できるコマンドは次のとおりです。
install
reconfig
chpasswd
remove
Windowsシステム: configureAAAServer.exeを使用します。アクセス・サーバー・サービスを削除するにはremove、再インストールするにはinstallコマンドを使用します。
UNIXシステム: configureAAAServerツールを起動するため、start_configureAAAServerスクリプトを使用します。オプションを表示するには、オプションを指定しないでこのツールを実行します。
configureAAAServerツールにアクセスする手順
configureAAAServerが置かれているフォルダに移動します。
デフォルトの場所は次のとおりです。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
|
注意: UNIXシステムでは、start_configureAAAServerを使用します。 |
管理タスクの手順内で、configureAAAServerツールを必要に応じて使用します。
configureAAAServerが置かれているフォルダに移動します。
次に例を示します。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
次の実行可能ファイルを実行します。
configureAAAServer reconfig AccessServer_install_dir
プロンプトに従って次を指定します。
アクセス・サーバーを実行するトランスポート・セキュリティ・モード
ディレクトリ・サーバーが実行されているトランスポート・セキュリティ・モード
ディレクトリ・サーバーが常駐するホスト・コンピュータ
ディレクトリ・サーバーがリスニングするポートの番号
ディレクトリ・サーバーのバインドDN
ディレクトリ・サーバーのパスワード
接続先のディレクトリ・サーバー
構成データが格納されている場所
構成DN
ポリシー・ベース
アクセス・サーバーID
ディレクトリ・サーバーの構成の詳細は、「ディレクトリ・サーバーの構成」を参照してください。
アクセス・サーバーを再起動します。
configureAAAServerが置かれているフォルダに移動します。
デフォルトの場所は次のとおりです。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
AccessServer_install_dirは、アクセス・サーバーがインストールされたディレクトリです。
次の実行可能ファイルを実行します。
configureAAAServer reconfig AccessServer_install_dir
構成データまたはポリシー・データにフェイルオーバー情報を指定するかどうかを尋ねられます。
「はい（Y）」を選択します。
データが構成ディレクトリ・ツリーとポリシー・ツリーのどちらに格納されているかを指定します。
次のオプションが表示されます。
1> フェイルオーバー・サーバーを追加します
2> フェイルオーバー・サーバーを変更します
3> フェイルオーバー・サーバーを削除します
4> 共通パラメータを変更します
5> 終了します
「4> 共通パラメータを変更します」を選択します。
必要に応じて、次の共通構成パラメータの値を指定します。
最大接続数: アクセス・サーバーがロード・バランシングのために関連付けられているディレクトリ・サーバーとの間で確立できる接続の最大数。
スリープ時間（秒）: アクセス・サーバーがディレクトリ・サーバーへの接続をチェックする周期。たとえば、この値を60秒に設定した場合、アクセス・サーバーは起動した時点から60秒ごとにその接続をチェックします。
フェイルオーバーしきい値: アクセス・サーバーがディレクトリ・サーバーへの新規接続を開始する接続数を示す数値。たとえば、このフィールドに3を入力した場合、アクセス・サーバーからディレクトリ・サーバーへの接続数が2に減少した時点で、アクセス・サーバーと構成済ディレクトリ・サーバーとの間で新規の接続が開始されます。
最大セッション時間: アクセス・サーバーとディレクトリ・サーバーとの間のセッションの最大時間。
詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
「5> 終了します」を選択して終了します。
変更内容を確定してよいか確認を求められます。
変更内容を確定するには「Y」を、取り消すには「N」を選択します。
configureAAAServerが置かれているフォルダに移動します。
デフォルトの場所は次のとおりです。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
|
注意: UNIXシステムでは、start_configureAAAServerを使用します。 |
コマンドラインで、次の実行可能ファイルを実行します。
configureAAAServer remove AccessServer_install_dir serviceName
ここで、AccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。serviceNameは、AccessManager_AccessServerなど、サービスの名前です。
レジストリのエントリが削除中であることを示すメッセージが表示されます。このメッセージにより、アクセス・サーバーの削除完了までを確認できます。
|
注意: serviceName変数は、Microsoft Windowsでのみ使用できます。serviceNameは、アクセス・システム・コンソール上でアクセス・サーバー用に指定する名前です。 |
configureAAAServerが置かれているフォルダに移動します。定型的なフォルダ例は次のとおりです。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
|
注意: UNIXシステムでは、start_configureAAAServerを使用します。 |
コマンドラインで、次の実行可能ファイルを実行します。
configureAAAServer install AccessServer_install_dir serviceName
ここで、AccessServer_install_dirは、アクセス・サーバーがインストールされているディレクトリです。serviceNameは、AccessManager_AccessServerなど、サービスの名前です。
次の情報を指定します。
アクセス・サーバーを再構成するかどうか
アクセス・サーバーのトランスポート・セキュリティ・モード
Oracle Access Managerのディレクトリ・サーバーのトランスポート・セキュリティ・モード
ディレクトリ・サーバーが常駐するホスト・コンピュータ
ディレクトリ・サーバーがリスニングするポートの番号
ディレクトリ・サーバーのバインドDN
ディレクトリ・サーバーのパスワード
接続先のディレクトリ・サーバー
構成DN
ポリシー・データの場所
ポリシー・ベース
アクセス・サーバーID
アクセス・サーバー・サービスの名前を書き留めます。
アクセス・サーバーが正常にインストールされたことを示すメッセージが表示されます。
Windowsの「コントロール パネル」の「サービス」から、アクセス・サーバーを起動します。
リクエストは、アクセス・サーバーに送信されるとキューに登録されます。各リクエストは1つのスレッドで処理されます。たとえば、現在2つのリクエスト・キューと60のスレッドがある場合には、アクセス・サーバーにより120のスレッドが生成されます。
キューの数は、アクセス・システム・コンソールでは指定できません。一方、スレッドの数は、アクセス・サーバーの構成時に「スレッド数」フィールドに指定できます。デフォルト設定は60です。
各アクセス・サーバーでサポート可能なキュー数は、コマンドラインに指定できます。キュー数は、スレッド数とバランスを取る必要があります。一般的には、各WebGateにつき1つのキューが適切です。
Solaris、Windows 2000またはWindows NTごとにコマンドが1つずつ用意されています。Solarisでは、シェル・ウィンドウを開いてからこのコマンドを使用します。Windowsでは、「サービス」ウィンドウの「開始パラメータ」フィールドでこのコマンドを使用します。
|
ヒント: スレッドとキューの詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。 |
シェル・ウィンドウを開きます。
コマンドラインで、次のコマンドを入力します。
start_access_server -QN
ここで、Nにはキュー数を指定します。
「スタート」→「プログラム」→「管理ツール」→「サービス」、続いてCOREidAAAServerIDの順に選択します。
COREidAAAServerIDを右クリックして、「プロパティ」を選択します。
プロパティ・ウィンドウが表示されます。
キュー数を指定するには、「全般」タブで次のように入力します。
-QN
ここで、Nは、「開始パラメータ」フィールドのキュー数です。
「スタート」→「コントロール パネル」→「サービス」、続いてCOREidAAAServerIDの順に選択します。
ここで、IDは、アクセス・サーバーの名前です。
COREidAAAServerIDを右クリックして、「プロパティ」を選択します。
プロパティ・ウィンドウが表示されます。
キュー数を指定するには、「全般」タブで次のように入力します。
-QN
ここで、Nは、「開始パラメータ」フィールドのキュー数です。
アクセス・システムを稼働させるには、1つ以上のアクセス・サーバーと1つのアクセス・ゲートをインストールし構成する必要があります。アクセス・ゲートとしては、HTTPリソースに対してただちに使用できるアクセス・ゲートであるWebGateを構成できます。アクセス・サーバーは、アクセス・ゲート・プロファイルを追加してアクセス・ゲートをインストールする前にインストールしておく必要があります。
この項の残りの内容は次のとおりです。
「アクセス・ゲートの追加」の手順に従って、アクセス・システム・コンソールで1つ以上のアクセス・ゲート・インスタンスを作成します。
「アクセス・ゲートおよびWebGateのアクセス・サーバーとの関連付け」の手順に従って、各アクセス・ゲート・インスタンスをいずれかのアクセス・サーバーと関連付けます。
『Oracle Access Managerインストレーション・ガイド』の手順に従って、アクセス・システム・コンソールで作成したインスタンスごとにアクセス・ゲートをインストールします。
「WebGateの変更」の手順に従って、アクセス・ゲートの設定値に必要な変更を行います。
|
注意: WebGateを構成する場合は、「保護されていない場合に拒否」をtrueに設定して、Webコンテンツを確実に保護することをお薦めします。詳細は、「デフォルトでのすべてのリソースへのアクセス拒否」を参照してください。 |
アクセス・システム・コンソールでアクセス・ゲートを検索することにより、既存のアクセス・ゲート・プロファイルを表示できます。
アクセス・ゲートを検索するには、「検索」ページでそのアクセス・ゲートの任意の属性を指定します。どの属性を選択するかによって、検索条件、したがって値が異なってきます。たとえば、検索属性として「セキュリティ」を選択した場合、条件のリストには「次と等しい」が表示され、値として、選択可能なセキュリティ・モードから1つを選択します。これにより、検索結果には、指定したセキュリティ・モードで構成されている既存のアクセス・ゲートが表示されます。
アクセス・ゲートの検索属性、条件および値を表3-2にリストします。
表3-2 アクセス・ゲートの検索属性、条件および値
| 属性 | 条件 | 入力タイプ | 説明 |
|---|---|---|---|
|
名前 |
|
テキスト・ボックス |
アクセス・ゲート名で検索する。 |
|
ホスト名 |
|
テキスト・ボックス |
指定したホスト・コンピュータにインストールされているアクセス・ゲートを検索する。 |
|
説明 |
|
テキスト・ボックス |
指定した文字列が「説明」フィールドに含まれているアクセス・ゲートを検索する。 |
|
セキュリティ・モード |
次と等しい |
ラジオ・ボタン: 「オープン」、「シンプル」、「証明書」 |
|
|
次と等しい |
ラジオ・ボタン: 「オン」または「オフ」 |
アクセス管理サービスが「オン」か「オフ」かに基づいてアクセス・ゲートを検索する。これが有効になっているアクセス・ゲートをリスト表示するには、値を「オン」に設定します。これが無効になっているアクセス・ゲートをリストするには、値を「オフ」に設定します。 表3-3「アクセス・ゲート構成パラメータ」も参照してください。 |
|
|
状態 |
次と等しい |
ラジオ・ボタン: 「有効」および「無効」 |
有効または無効にされているアクセス・ゲートを検索する。 |
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
「検索」リストに、表3-2に記載した検索可能な属性が一覧表示されます。
その他のフィールドでは、選択した属性に対応する検索基準を指定できます。
各リストから検索属性と条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」ボタンをクリックします。
「実行」をクリックします。
検索結果がページに表示されます。
詳細を表示するアクセス・ゲートの名前をクリックします。
そのアクセス・ゲートの構成詳細が表示されます。
特定のアクセス・サーバーに関連付けられているアクセス・ゲートを表示する手順
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・サーバー構成」の順にクリックします。
「アクセス・サーバー構成: すべてのアクセス・サーバーをリスト」ページが表示されます。
目的のアクセス・サーバーのリンクをクリックします。
「アクセス・サーバーの詳細」ページが表示されます。
「アクセス・サーバーの詳細」ページの最下部にある「関連するアクセス・ゲートの表示」ボタンをクリックします。
「サーバーに関連づけられたAccess Gate」ページが表示されます。
そのアクセス・サーバーがプライマリ・サーバーとして構成されているアクセス・ゲートを表示するには、「プライマリ・サーバー」を選択します。
そのアクセス・サーバーがセカンダリ・サーバーとして構成されているアクセス・ゲートを表示するには、「セカンダリ・サーバー」を選択します。
検索対象として指定したすべてのアクセス・ゲートをリストする場合は「すべて」を選択します。または、ページに表示する検索結果の件数を指定する場合は、数値を入力します。
「実行」をクリックして、検索結果を表示します。
アクセス・サーバーに関連付けられているアクセス・ゲートの詳細が、ページに表示されます。
ページが複数にわたる場合、次のページに進むには「次へ」を、前のページに戻るには「前へ」をクリックします。
「戻る」をクリックすると「アクセス・サーバー」ページに戻ります。
すべてのアクセス・サーバー（クラスタ内にあるかどうかに関係なく）および関連付けられているWebGateとアクセス・ゲートは、同一のトランスポート・セキュリティ・モードとアクセス管理サービスで設定されている必要があります。
表3-3に、アクセス・ゲート構成パラメータをまとめます。
表3-3 アクセス・ゲート構成パラメータ
| フィールド | 説明 |
|---|---|
|
アクセス・ゲートの名前。 |
|
|
このアクセス・ゲートを識別するための追加情報。 |
|
|
アクセス・ゲートが有効か無効か。 |
|
|
アクセス・ゲートをホストするコンピュータの名前。 |
|
|
これはオプションであり、情報提供専用。WebGateとしてデプロイされたときのアクセス・ゲートによって保護される、Webサーバーのポートを指定します。Access Manager SDKを使用してアプリケーションをサポートするアクセス・ゲート構成の場合は、このフィールドは空である必要があります。 |
|
|
アクセス・ゲートをアクセス・システム・コンソールで定義したときに、オプションで設定する一意のパスワード。アクセス・ゲートは、アクセス・サーバーに接続する際に、このパスワードを使用してアクセス・サーバーから認証を受けます。これにより、不正なアクセス・ゲートsがアクセス・サーバーに接続し、ポリシー情報を取得することが防止されます。 |
|
|
デバッグを有効または無効にする。 |
|
|
アクティビティにかかわりなく、ユーザーの認証セッションが有効でいられる最長時間を秒単位で表す。このセッション時間が満了した場合、ユーザーは認証のための情報を提示するよう再要求されます。これは、強制ログアウトです。 デフォルト: 3600 このタイムアウト設定を無効にするには、値0を指定します。 |
|
|
アクセス・ゲートで保護されたどのリソースへもアクセスしない場合に、ユーザーの認証セッションが有効でいられる時間を秒単位で表す。 デフォルト: 3600 このタイムアウト設定を無効にするには、値0を指定します。 |
|
|
このアクセス・ゲートがアクセス・サーバーと確立できる最大接続数。この数値は、WebGateに実際に関連付けられているアクセス・サーバー数以上である必要があります。 デフォルト: 1 |
|
|
IPアドレスの検証は、WebGate固有であり、クライアントのIPアドレスがシングル・サインオン用に生成されたObSSOCookieに格納されているIPアドレスと一致するかどうかを判断するものである。詳細は、「WebGate用IPアドレス検証の構成」を参照してください。 |
|
|
IPValidationExceptionはWebGateごとに設定する。これは、IPアドレス検証から除外されるIPアドレスのリストです。プロキシによって設定されたIPアドレスを除外するのによく使用されます。詳細は、「WebGate用IPアドレス検証の構成」を参照してください。 |
|
|
アクセス・ゲートがアクセス・サーバーとの接続を維持する時間。アクセス・ゲートとアクセス・サーバーの間にファイアウォール（または他のデバイス）をデプロイしている場合は、この値をファイアウォールのタイムアウト設定よりも小さい値に設定します。 デフォルト: 24時間 |
|
|
このアクセス・ゲートがセカンダリ・アクセス・サーバーへの新規接続を開始する接続数を示す数値。このフィールドに30を入力した場合、プライマリ・アクセス・サーバーへの接続数が29に減少した時点で、このアクセス・ゲートはセカンダリ・アクセス・サーバーへの接続を開始します。 |
|
|
WebGateにのみ適用される。アクセス・サーバーからのレスポンスを待機する秒数。このパラメータは、設定すると、デフォルトTCP/IPタイムアウトのかわりにアプリケーションTCP/IPタイムアウトとして使用されます。 たとえば、WebGateが1つのプライマリ・アクセス・サーバー、および1つのセカンダリ・アクセス・サーバーと通信するように構成されているとします。プライマリ・アクセス・サーバーからネットワーク配線が抜かれると、WebGateは、TCP/IPタイムアウトまでの間に、プライマリ・アクセス・サーバーに接続できなくなったことを認識します。WebGateは、プライマリ・アクセス・サーバーから順に、使用可能なサーバーに対して接続の再確立を試行します。再びWebGateが、TCP/IPタイムアウトまでの間に、接続を確立できるかどうかを判断します。確立できない場合は、リストの次のサーバーに対して接続を試行します。別のアクセス・サーバー（プライマリまたはセカンダリのどちらか）に対して接続を確立できた場合は、リクエストが再ルーティングされます。ただし、これには必要以上の時間がかかる可能性があります。 デフォルトのTCP/IPタイムアウトをそのまま受け入れるかわりに、アクセス・サーバー・タイムアウトしきい値を、アクセス・システム・コンソールの「アクセス・システム構成」にある、「アクセス・ゲート構成」で指定できます。デフォルト値の-1は、デフォルトのネットワークTCP/IPタイムアウトを使用することを意味します。通常、このパラメータには30秒から60秒の間の値を指定します。非常に小さい値に設定すると、アクセス・サーバーからレスポンスを受信する前にソケット接続がクローズし、エラーが生じる可能性があります。 WebGateは、新しい接続を検索するときには、使用可能なサーバーのリストを、その構成で指定した順序でチェックします。プライマリ・アクセス・サーバーが1台のみ、セカンダリ・アクセス・サーバーが1台指定されている場合でも、プライマリ・アクセス・サーバーへの接続がタイムアウトすると、WebGateは最初に、今まで接続していたプライマリ・アクセス・サーバーへの接続を試行します。その結果、WebGateは「アクセス・サーバー・タイムアウトしきい値」の設定値の2倍を超える期間の間、アクセス・サーバーにリクエストを送信できなくなります。 アクセス・サーバーのリクエストの処理時間がタイムアウトしきい値を超過した場合、WebGateはリクエストを中止し、新しい接続でリクエストを再試行します。接続プールの設定によっては、接続プールから返される新しい接続先が、同じアクセス・サーバーになる可能性があります。また、別のアクセス・サーバーでも、リクエストの処理時間がしきい値を超過する可能性があります。この場合、アクセス・サーバーが停止するまで、WebGateによる再試行が続行する可能性があります。再試行の回数は、ユーザー定義パラメータclient_request_retry_attemptsによって制御できます。詳細は、「ユーザー定義のアクセス・ゲート・パラメータの構成」を参照してください。 |
|
|
このアクセス・ゲートがアクセス・サーバーへの接続をチェックする周期を示す秒数。たとえば、このパラメータの値を60秒に設定すると、アクセス・ゲートは起動した時点から60秒ごとに接続をチェックします。 |
|
|
キャッシュに保持される要素数。このキャッシュ要素とは次のものです。 この設定の値は、この2つのキャッシュに含まれる要素を合計した件数の最大値です。 デフォルト: 10000 |
|
|
キャッシュ内の情報が使用も参照もされないときにアクセス・ゲート・キャッシュ内にとどまる時間。 デフォルト: 1800 |
|
|
偽装ユーザーとして作成した、信頼できるユーザーの名前。この値には、たとえばtestdomain@user.netのようにドメイン名を含める必要があります。 信頼できるユーザー名をここに指定します。この名前は、アクセス・ゲート（WebGate）が偽装で使用できるように、アクセス・ゲートにバインドされます。 偽装の詳細および信頼できる偽装ユーザーの作成方法は、『Oracle Access Manager統合ガイド』を参照してください。 |
|
|
偽装に使用する信頼できるユーザーのパスワード。このパスワードは2回入力する必要があります。つまり、再入力するよう要求されます。 |
|
|
アクセス管理サービス または、「ポリシー・マネージャAPIサポート・モード」 |
このパラメータは、アクセス管理サービスが「オン」か「オフ」かを決定します。これはデフォルトでは「オフ」です。アクセス管理サービスは、次のように設定する必要があります。
注意: すべてのアクセス・サーバー（クラスタ内にあるかどうかに関係なく）および関連付けられているアクセス・ゲートまたはWebGateは、同一のトランスポート・セキュリティ・モードとアクセス管理サービス状態にする必要があります。 |
|
このパラメータには、アクセス・ゲートがデプロイされるWebサーバーのドメインを、たとえば.mycompany.comのように記述する。このCookieドメインは、Webサーバー間のシングル・サインオンが有効になるよう、構成する必要があります。特に、シングル・サインオンを構成する各Webサーバーには、同じプライマリHTTP Cookieドメイン値を記述する必要があります。アクセス・システムは、このパラメータをObSSOCookie認証Cookieの作成に使用します。このパラメータにより、Cookieドメインに参加し、ObSSOCookieの受信および更新機能を持つWebサーバーを定義します。このWebGate Cookieドメイン・パラメータは、ObSSOCookieの移入には使用されません。かわりに、どのドメインでObSSOCookieを有効とするか、またどのWebサーバーにObSSOCookieコンテンツの受入れおよび変更機能を持たせるかを決定するのに使用されます。 |
|
|
この必須フィールドによって、保護されているWebサーバーにアクセスを試行したとき、すべてのHTTPリクエストに表示されるホスト名が決定する。HTTPリクエストのホスト名は、ユーザーのHTTPリクエストでの定義に関係なく、このフィールドへの入力値に変換されます。 仮想ホスティングを使用する場合は、フィールドに関する特別な考慮事項があります。詳細は、「仮想Webホスティングの構成」を参照してください。 仮想ホスティングが必要な場合を除いて、各WebGateの「優先HTTPホスト」フィールドの値を常に指定し、その値が「ホスト識別子」フィールドのホスト名にマップするか確認することをお薦めします。ホスト識別子は、ポリシーを定義するときに使用します。 「優先HTTPホスト、ホスト識別子および仮想Webホストの構成」も参照してください。 ポリシー・マネージャのglobalparams.xmlに新しいパラメータを追加できます。これはアクセス・システム・コンソールでWebGate構成の「優先HTTPホスト」フィールドを監視するのに役立ちます。
詳細は、「WebGateプロファイルにある優先HTTPホストの識別子が不正または見つからない」を参照してください。パラメータについては、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。 |
|
|
この設定はWebGateにのみ適用される。このパラメータのデフォルト値はfalseです。この場合、保護はなく、アクセスが可能です。この場合、特に問題なのは、アクセス権が誤って付与される可能性があることです。たとえば、URLでIPアドレスの10進値を使用してリソースにアクセスしようとすると、ホスト識別子にこのアドレス表現が含まれていない場合でも、アクセス権が付与される可能性があります。 「保護されていない場合に拒否」をtrueに設定するのが、Webサーバーのコンテンツを保護する最もセキュアな方法です。 「保護されていない場合に拒否」をtrueに設定すると、アクセスがポリシーで明示的に許可されないかぎり、WebGateで保護されたWebサーバー上のWebページに対するすべてのリクエストが拒否されます。trueに設定する場合は、匿名認証メソッドを作成し、匿名アクセス・ポリシーを使用したコンテンツへのアクセスを許可する必要があります。「保護されていない場合に拒否」スイッチの使用方法の詳細は、「デフォルトでのすべてのリソースへのアクセス拒否」を参照してください。 |
|
|
この設定は、WebGatesのみに適用して、ブラウザのキャッシュを制御します。 デフォルトでは、「CachePragmaHeader」および「CacheControlHeader」は「キャッシュなし」に設定されています。これにより、WebGateがWebサーバー・アプリケーションおよびユーザーのブラウザでデータをキャッシュに格納しないようになります。 ただし、サイトがWebGateで保護されている場合、これはPDFファイルのダウンロードやレポート・ファイルの保存など、特定の操作にとって妨げとなることがあります。 WebGateが使用するAccess Manager SDKキャッシュは、様々なレベルに設定できます。詳細は、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlの14.9項を参照してください。 すべてのキャッシュ・レスポンス・ディレクティブが許可されます。たとえば、PDFファイルのダウンロードを許可するには、両方のキャッシュの値をpublicに設定する必要があります。 |
|
|
この設定はWebGateにのみ適用される。「LogOutURLs」パラメータには、ユーザーがログアウトする特定のURLを1つ以上構成できます。このパラメータに、ポータルのログアウトURLを設定してもかまいません。たとえば、財務ポータルがWebGateによって保護されており、ポータルのログアウト・ページがfinance_exit.htmlであるとします。finance_exit.htmlを「LogOutURLs」のエントリとして追加すると、財務ポータルからログアウトするユーザーはOracle Access Managerからもログアウトすることになります。 「LogOutURLs」パラメータの値の1つとして、SSOログアウトURLを指定することをお薦めします。これにより、一貫性が増し、マルチドメインのシングル・サインオンの実装に対してグローバルなログアウト値を指定できるようになります。詳細は、「アイデンティティ・システム・リソースに対するログアウトの構成」を参照してください。また、WebPassまたはポリシー・マネージャを保護するようにWebGateを構成済の場合は、「LogOutURLs」パラメータにSSOログアウトURLの値を含める必要があります。これは必須です。WebPassまたはポリシー・マネージャの「ログアウト」ボタンを押すと、ユーザーがSSOログアウトURLにリダイレクトされるためです。 |
|
|
この設定はWebGateにのみ適用される。Oracle Access Manager 10.1.4では、WebGateStatic.lstファイルは廃止されました。WebGateStatic.lstに設定していたパラメータの一部は、今リリースでは「アクセス・ゲート構成」ページのみにあるデータ入力フィールドとして用意されています。それ以外のパラメータは、このページのユーザー定義パラメータとして使用可能になっています。詳細は、「ユーザー定義のアクセス・ゲート・パラメータの構成」を参照してください。 |
アクセス・ゲートをインストールする前に、アクセス・システム・コンソールでアクセス・ゲート・インスタンスを追加する必要があります。インストール前に指定する必須パラメータは、「アクセス・ゲート名」、「ホスト名」、「トランスポート・セキュリティ・モード」および「優先HTTPホスト」です。これら以外のアクセス・ゲート・パラメータは、インストール後に構成できます。これについては、後続の各項で説明します。
すべてのパラメータの詳細は、「アクセス・ゲート構成パラメータ」を参照してください。アクセス・ゲートのインストールの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
|
注意: アクセス・ゲート名を一度割り当てて保存すると、変更はできません。アクセス・ゲートの名前を変更するには、インスタンスを削除してアンインストールし、新しいアクセス・ゲートを作成する必要があります。 |
アクセス・システム・コンソールを起動し、「アクセス・システム構成」をクリックします。
左側のナビゲーション・ペインにある、「新規Access Gateの追加」をクリックします。
「新規Access Gateの追加」ページが表示されます。
フォームに次のように入力します。
アクセス・ゲート名: このアクセス・ゲート・インスタンスの名前を入力します。英数字をスペースなしで入力してください。アクセス・ゲートとアクセス・サーバーの名前を同じにすることはできません。
ポート: WebGateとしてデプロイされたときのアクセス・ゲートによって保護される、Webサーバー・ポートを入力します。
このフィールドはオプションであり、情報提供の目的でのみ使用されます。WebGateに対するWebサーバーのポート番号を入力することをお薦めします。その他のアクセス・ゲートには、ポートを指定してもしなくてもかまいません。
Access Manager SDKを使用してアプリケーションをサポートする構成をアクセス・ゲートに指定している場合は、このフィールドは空である必要があります。
アクセス・ゲートのパスワード: このアクセス・ゲートのパスワードを表す英数字の文字列を入力します。
アクセス・ゲートは、このパスワードを使用してアクセス・サーバーに対して自身であることを証明します。ここでパスワードを指定する場合は、アクセス・ゲートの再構成時およびインストール時にも同じパスワードを入力する必要があります。
|
注意: このアクセス・ゲートがWebGateの場合、このパスワードはそのWebGateのインストール時に指定したものと同じである必要があります。 |
Access Gateのパスワードを再入力: パスワードを再入力します。
「保存」をクリックしたときに、これら2つのステップの入力が一致しない場合は、エラー・メッセージが表示されます。その場合は、このプロセスを繰り返す必要があります。
デバッグ: 「デバッグ」フィールドはWebGateにのみ関連します。
この項目では次の操作が可能です。
「オン」をクリックすると、アクセス・ゲートとアクセス・サーバー間で送受信されるデバッグ・メッセージを、ほとんどのプラットフォームで標準出力に書き込みます。IISサーバーはNTサービスとして稼働するため、IISではこのメッセージ情報は標準出力に書き込まれません。
このメッセージ情報を取得しない場合は、「オフ」をクリックします。
|
重要: デバッグ・メッセージを取得すると、ユーザー・パスワードおよび潜在的なセキュリティ上の問題が記録されるため、アクセス・サーバーのログ・ファイルのサイズは急激に増大します。このデバッグ機能は、問題の診断時にのみ「オン」にしてください。 |
次の値を設定して、ユーザー・セッション時間とタイムアウトを決定します。
最大ユーザー・セッション時間: アクティビティにかかわりなく、ユーザーの認証セッションが有効でいられる最長時間を秒単位で入力します。このセッション時間が満了した場合、ユーザーは認証のための情報を提示するよう再要求されます。これは、強制ログアウトです。
アイドル・セッション時間: アクセス・ゲートで保護されたどのリソースへもアクセスしない場合に、ユーザーの認証セッションが有効でいられる時間を秒単位で入力します。デフォルト値は3600です。
最大接続数: このアクセス・ゲートが関連付けられたアクセス・サーバーとの間に確立可能な最大接続数を入力します。この数には、任意の時点で割り当てたアクセス・サーバー接続数より大きい値を設定することもできます。
デフォルト値は1です。
トランスポート・セキュリティ: このアクセス・ゲートとその通信相手として構成済のアクセス・サーバーとの間でメッセージを暗号化するメソッドを選択します。
相互に通信するように構成したアクセス・ゲートとアクセス・サーバーには、同じ暗号化メソッドを選択する必要があります。
選択肢は次のとおりです。
トランスポート・セキュリティ・モードの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』、または「アクセス・ゲート構成パラメータ」にある、アクセス・ゲート構成パラメータの表を参照してください。
|
注意: アクセス・ゲートのモードを「シンプル」または「証明書」から「オープン」に変更する場合は、/oblix/config/simpleディレクトリ（「シンプル」モードの場合）または/oblix/config/*.pemファイル（「証明書」モードの場合）を新しいフォルダに移動する必要があります。移動したら、configureAccessClientプログラムを実行します。 |
次の手順を実行します。
クライアントのIPアドレスが、シングル・サインオン用に生成されObSSOCookieに格納されているIPアドレスと一致するかどうかをWebGateで判断するには、「IPValidation」を指定します。詳細は、「WebGate用IPアドレス検証の構成」を参照してください。
IPアドレス検証から除外するIPアドレスを指定するには、そのアドレスを「IPValidationException」に指定します。詳細は、「WebGate用IPアドレス検証の構成」を参照してください。
最大クライアント・セッション時間: アクセス・ゲートがアクセス・サーバーとの接続を維持する時間を指定します。
「トランスポート・セキュリティ」フィールドで「オープン」を選択した場合は、このフィールドは無視されます。
最大クライアント・セッション時間が0の場合、アクセス・ゲートは、アクセス・サーバーに対して行うリクエストごとに、アクセス・サーバーへの接続を新しく確立します。アクセス・ゲートに対する各ユーザー・リクエストに対して、複数のアクセス・ゲート・リクエストが存在する可能性があります。
デフォルト値は24時間です。「スリープ時間」パラメータよりも大きな値を指定する必要があります。同じセッション鍵を24時間を超えて使用すると、システムが攻撃に対して脆弱になります。
フェイルオーバーしきい値: このアクセス・ゲートが、セカンダリ・アクセス・サーバーへの新規接続を開始する接続数を示す数値を入力します。このフィールドに30を入力した場合、プライマリ・アクセス・サーバーへの接続数が29に減少した時点で、このアクセス・ゲートはセカンダリ・アクセス・サーバーへの接続を開始します。
1からプライマリ・サーバーの合計数までの範囲内の数値を入力できます。数値を入力しない場合は、「最大接続数」が値として使用されます。
フェイルオーバーの構成の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
アクセス・サーバー・タイムアウトしきい値: WebGateにのみ適用されます。アクセス・ゲートがアクセス・サーバーからのレスポンスに対して待機する最長時間を秒単位で指定します。このパラメータは、設定すると、デフォルトTCP/IPタイムアウトのかわりにアプリケーションTCP/IPタイムアウトとして使用されます。
スリープ時間（秒）: このアクセス・ゲートがアクセス・サーバーへの接続をチェックする周期を秒数で入力します。
アクセス・サーバーへの接続が無効になっている場合に、そのアクセス・サーバーが起動されたことをアクセス・ゲートが認識すると、アクセス・ゲートはそのサーバーへの再接続を試行します。
デフォルト値は60秒です。この値が小さいほど、アクセス・ゲートが再起動したアクセス・サーバーへの接続を再確立するまでの時間が短くなります。ただし、接続をチェックするためのオーバーヘッドは大きくなります。
このフィールドのエントリは、他のサーバーへのフェイルオーバーには影響を与えません。フェイルオーバーは、必要になると必ず即時に行われます。
キャッシングの詳細を次のように入力します。
アクセス管理サービスについては、状態を「オン」または「オフ」に設定します。
詳細は、「アクセス・ゲート構成パラメータ」を参照してください。
続いて、次の情報を入力します。
プライマリHTTP Cookieドメイン: アクセス・ゲートのドメイン名を入力します。
次に例を示します。
.yourcompany.com
優先HTTPホスト: 保護されているWebサーバーにアクセスを試行したとき、すべてのHTTPリクエストに表示されるホスト名を指定します。HTTPリクエストのホスト名は、ユーザーのHTTPリクエストでの定義に関係なく、このフィールドへの入力値に変換されます。
「優先ホスト」機能により、ホストの識別子が「ホスト識別子」リストに含まれていない場合に予期せずに発生する可能性があるセキュリティ・ホールが回避されます。ただし、この機能は仮想Webホスティングでは使用できません。仮想ホスティングの場合は、「ホスト識別子」の機能を使用する必要があります。
優先HTTPホスト機能を無効にする場合以外は、ホスト識別子機能に入力したいずれかのバリエーションを入力して、シングル・サインオンが正常に動作することを確認する必要があります。詳細は、「優先HTTPホスト、ホスト識別子および仮想Webホストの構成」および「仮想Webホスティングの構成」を参照してください。
保護されていない場合に拒否: この設定はWebGateにのみ適用されます。trueを指定すると、ポリシーで許可されないかぎり、WebGateで保護されたWebサーバー上のリソースへのアクセスがすべて拒否されます。trueを指定する場合は、匿名認証メソッドを作成し、匿名アクセス・ポリシーを使用したコンテンツへのアクセスを許可する必要があります。詳細は、「デフォルトでのすべてのリソースへのアクセス拒否」を参照してください。
必ず「アクセス・ゲート構成パラメータ」の情報を確認してから、次のWebGate用の値を入力します。
LogOutURLs: この設定はWebGateにのみ適用されます。
ユーザーが「ログアウト」をクリックしたときに、IDアプリケーションおよびアクセス・アプリケーションから確実にログアウトできるように、このパラメータの値をSSOログアウトURLの値に設定します。詳細は、「アクセス・ゲート構成パラメータ」および「アイデンティティ・システム・リソースに対するログアウトの構成」を参照してください。
ユーザー定義パラメータ（WebGatesのみ）: WebGateが特定のブラウザやプロキシなどで動作するように構成するために、特定のユーザー定義パラメータを設定できます。詳細は、「ユーザー定義のアクセス・ゲート・パラメータの構成」を参照してください。
この新しいアクセス・ゲート・インスタンスを保存する場合は、「保存」をクリックします。または、保存しないで前のページに戻る場合は、「取消」をクリックします。
これで、アクセス・ゲート・インスタンスが作成し終わり、インストールと設定が可能になりました。インストール時には、このページで入力した名前、ホスト名およびポート番号を使用します。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アイデンティティ・システムのアプリケーションがWebGateで保護されている場合は、「ログアウト」ボタンは、ポリシー・マネージャおよびアイデンティティ・システム・コンソールで使用できるようには自動構成されません。次の手順に従い、「ログアウト」ボタンおよびログアウトURLを構成する必要があります。
「シングル・サインオン・ログアウトURLの構成」の手順に従い、ユーザーがアプリケーションからログアウトするときに表示するログアウト・ページのURLを構成します。
|
注意: ログアウトURLは、OblixBaseParams.lstファイルのSSOLogoutURLパラメータに指定することもできます。このファイルの場所は、PolicyManager_install_dir/access/oblix/apps/common/bin/です。 |
ユーザーが「ログアウト」をクリックしたときに、WebGateによりIDアプリケーションまたはアクセス・アプリケーションから確実にログアウトできるように、必ず「LogOutURLs」パラメータの値をSSOログアウトURLと同じ値に設定します。
詳細は、「アクセス・ゲートの変更」を参照してください。
旧バージョンのOracle Access Managerでは、ファイルWebGateStatic.lstを使用してWebGateの各種設定を構成していました。このファイル内の設定は、「アクセス・ゲート構成」ページに移動しました。設定の一部は、このページに静的パラメータとして表示されます（「保護されていない場合に拒否」など）。また、これらの設定のいくつかは、この構成ページにおいてユーザー定義パラメータになっています。
アクセス・ゲートのユーザー定義パラメータは、次の問題に対処するためのものです。
UTF-8でエンコードされたURLの処理
IIS上でのMicrosoft Passportまたは統合Windows認証の処理
以前のNetscape Webサーバーとの連携
共有シークレットの更新周期の設定
NetPoint 5.xシステムとの互換性の確保
クライアントとリバース・プロキシの間でSSLを使用し、リバース・プロキシとWebサーバーの間で非SSLを使用するリバース・プロキシとの連携
ユーザー定義パラメータを実装するには、オラクル社カスタマ・サポート・センターに連絡してWebGateに対するパッチを入手し、「アクセス・ゲート構成」ページでパラメータに値を入力する必要があります。
アクセス・ゲートのユーザー定義パラメータは、次のとおりです。
RetainDownstreamPostData: このユーザー定義パラメータを追加して値をtrueに設定すると、Apache 2.0またはApache 2.2用のWebGateでPOSTデータが下流アプリケーションに読み取られるのを防止するときに発生する問題が解決されます。これは、passthroughチャレンジ・パラメータを使用するフォーム・ベース認証スキームと「問合せ文字列変数」オプションを使用するポリシーに影響を与えます。
UrlInUTF8Format: Oracle HTTP Server 2を使用する環境では、Latin-1やその他のキャラクタ・セットを表示するために、このパラメータをtrueに設定する必要があります。
UseIISBuiltinAuthentication: このパラメータのデフォルト値はfalseです。このコンピュータでMicrosoft Passportまたは統合Windows認証を使用している場合のみ、UseIISBuiltinAuthenticationをtrueに設定します。これはIISに対してのみ使用され、別のタイプのWebサーバーに対してWebGateがインストールされている場合は無視されます。
SlowFormLogin: Netscape Webサーバーの一部のバージョンでは、httpsを介したフォームによるログインが適正に動作しない場合があります。このような場合の問題は、SlowFormLoginパラメータによって解決されていました。このパラメータは、Netscape Webサーバーの最新バージョンでは不要です。
InactiveReconfigPeriod: WebGateは、アクティブな場合、アクセス・サーバーから1分ごとに共有シークレットを読み取る更新スレッドを持ちます。アクセス・サーバーは、共有シークレットを独自のキャッシュ（アクセス・サーバー・キャッシュ）に入れて戻します。デフォルトでは、この値は10分ごとに更新されます。たとえば、アクセス・サーバーにより、共有シークレットの値がディレクトリから10分間隔で読み取られ、キャッシュに格納されて、WebGateに戻されます。この設定は変更できます。詳細は、「WebGateポーリング頻度の変更」を参照してください。
アイドル状態の場合、WebGateは、InactiveReconfigPeriodの値を使用して、アクセス・サーバーから共有シークレットを読み取ります。この値が設定されていない場合は、WebGateはアクセス・サーバーに対して、共有シークレット値のポーリングを1分間隔で行います。ただし、更新された共有シークレット値が戻されるのは10分間隔でのみです。
WaitForFailover: NetPoint 5.xシステムと互換性を持たせるためにのみ使用します。このパラメータは、「アクセス・ゲート構成」ページの「アクセス・サーバー・タイムアウトしきい値」で置き換えられています。
WaitForFailoverパラメータ、およびその後継である「アクセス・サーバー・タイムアウトしきい値」パラメータのどちらも、WebGateとそれが通信するアクセス・サーバーの間のTCP/IPタイムアウトを制御します。デフォルト値の-1は、ネットワークのデフォルトTCP/IPタイムアウト値を使用することを意味します。
WaitForFailoverパラメータと、このページで構成する「アクセス・サーバー・タイムアウトしきい値」には必ず同じ値を使用します。
ProxySSLHeaderVar: このパラメータを使用するのは、WebGateがリバース・プロキシの背後にあり、SSLがクライアントとリバース・プロキシの間に構成されており、非SSLがリバース・プロキシとWebサーバーの間に構成されている場合です。これにより、URLがhttpではなくhttpsとして格納されます。プロキシにより、SSLまたは非SSLクライアント接続に対応しているかどうかを示すカスタム・ヘッダー変数を設定することで、URLがhttps形式で格納されるようになります。ProxySSLHeaderVarパラメータの値は、プロキシで設定する必要があるヘッダー変数の名前を定義します。ヘッダー変数の値は、sslまたはnonsslにする必要があります。このヘッダー変数を設定しない場合は、SSL設定は現行WebサーバーのSSL設定で決定されます。
client_request_retry_attempts: WebGateからアクセス・サーバーへのタイムアウトしきい値は、WebGateがアクセス・サーバーを使用不可とみなして新しい接続でリクエストを試行するまでに、WebGateがアクセス・サーバーを待機する時間（秒数）を指定します。アクセス・サーバーのリクエストの処理時間がタイムアウトしきい値を超過した場合、WebGateはリクエストを中止し、新しい接続でリクエストを再試行します。接続プールの設定によっては、接続プールから返される新しい接続先が、同じアクセス・サーバーになる可能性があります。また、別のアクセス・サーバーでも、リクエストの処理に必要な時間が、タイムアウトしきい値に指定された時間よりも長くなる可能性があります。場合によっては、アクセス・サーバーが停止するまで、WebGateによる再試行が続行する可能性があります。client_request_retry_attemptsパラメータを使用すると、応答しないサーバーに対するWebGateの再試行の回数を制限できます。このパラメータのデフォルト値は-1です。パラメータ値を-1に設定する（またはパラメータ値を設定しない）場合、再試行の回数は制限されません。
ContentLengthFor401Response: すべての401応答に対してContent-Lengthを設定するには、ユーザー定義パラメータContentLengthFor401Responseおよび値0を追加します。この値にはゼロ（0）のみ設定できます。その他の値は無視されます。このパラメータと値を使用しない場合、コンテンツとコンテンツ長の間で不一致が発生することがあります。結果として、ブラウザにデータが表示されないか、またはブラウザにエラー・メッセージが表示されます。
SUN61HttpProtocolVersion: SUN v6.1 Webサーバーでは、POSTデータを読み込んだ後のリダイレクションで問題が発生する場合があります。keepAlive（HTTP/1.1）プロトコルを使用して接続している場合、データが正しくフラッシュされません。そのため、リダイレクションが連続して機能しない場合があります。「アクセス・ゲート構成」ページで、ユーザー定義パラメータSUN61HttpProtocolVersionに1.0という値を割り当てると、SUN 6.1 WebサーバーでHTTP/1.0プロトコルの使用を強制することができます。1.0以外の値は無視されます。
idleSessionTimeoutLogic: リリース7.0.4では、WebGatesは独自のアイドル・セッション・タイムアウトのみを強制的に使用します。10g（10.1.4.0.1）では動作が変更され、WebGatesではトークンがアクセスしたすべてのWebGateの間で最も厳格なタイムアウト値が強制的に使用されていました。10g（10.1.4.3）では、7.0.4の動作がデフォルトとして復活しました。デフォルトの7.0.4の動作は、アクセス・システム・コンソールの「アクセス・ゲート構成」ページで、ユーザー定義パラメータ（idleSessionTimeoutLogic）を設定することで再構成できます。idleSessionTimeoutLogicパラメータは次のように設定します。
leastComponentIdleTimeout: アイドル・セッション・タイムアウトの強制に対して、WebGateに「最も厳格な」タイムアウト値を使用するように指示します。
currentComponentIdleTimeout: アイドル・セッション・タイムアウトの強制に対して、WebGateに「現在のWebGate」のタイムアウト値を使用するように指示します。
WebGateによるアクセス・サーバー構成のポーリングを使用することで、WebGateとアクセス・サーバーの間の通信量、およびアクセス・サーバーとLDAPディレクトリ・サーバーの間の通信量が削減されます。
手順の概要: WebGateによるアクセス・サーバー構成のポーリング
WebGateが非アクティブな状態が60秒続くと、その構成情報に対するポーリングの頻度を低下させます。
ポーリングの頻度は、パラメータInactiveReconfigPeriodによって決定されます。これは「アクセス・ゲート構成」ページで設定されるユーザー定義パラメータです。詳細は、「ユーザー定義のアクセス・ゲート・パラメータの構成」を参照してください。InactiveReconfigPeriodには、値を分単位で指定します。WebGateは、10秒以内の再開アクティビティを挟んで、再構成ポーリングを1分に1回実行します。
起動時には、WebGateはブートストラップ構成をチェックし、重要なパラメータが変更されているかどうかを確認します。
これによって、ほとんどの場合再初期化プロセスが不要になり、アクセス・サーバーからの一時的なロードが削減されます。
WebGate構成およびAccess Client構成は、アクセス・サーバーにキャッシュされます。
デフォルトのキャッシュ・タイムアウトは59秒です。これは、Apache以外のAccess Clientではシステム動作になんら影響を与えません。Apache WebサーバーでWebGateを使用する場合は、ディレクトリ・サーバーに対する不要なヒットが回避されます。キャッシング・パラメータは、AccessServer_install_dir/access/oblix/apps/common/bin/globalparams.xmlファイルにあるアクセス・サーバーのglobalparams.xmlファイルで設定できます。パラメータ clientConfigCacheMaxElemsには、キャッシュの最大サイズを設定します（デフォルト値は9999です）。パラメータclientConfigCacheTimeoutは、キャッシュ内の任意の要素の最大存続期間を決定します（デフォルト値は59秒です）。詳細は、『Oracle Access Managerカスタマイズ・ガイド』のパラメータに関する章を参照してください。
WebGateとアクセス・サーバー間およびアクセス・サーバーとLDAPディレクトリ・サーバー間のオフタイム・ネットワーク通信量を削減する方法は2つあります。
WebGateによる構成情報ポーリング頻度の変更
WebGate構成およびAccess Client構成のアクセス・サーバー・キャッシュのデフォルト構成キャッシュ・タイムアウトの変更（前述の手順3で説明）
WebGateとアクセス・サーバー間およびアクセス・サーバーとLDAPディレクトリ・サーバー間のオフタイム・ネットワーク通信量を削減する方法の1つは、WebGateによる構成情報のポーリング頻度を変更することです。
InactiveReconfigPeriodパラメータをこのWebGateの構成ページに追加します。
InactiveReconfigPeriodには、値を分単位で指定します。
デフォルト値は1分です。WebGateが非アクティブな状態（たとえば、認証リクエストが処理されないなど）が60秒を超えて続くと、構成情報に対するポーリングの頻度が低下します。WebGateは、10秒以内の再開アクティビティを挟んで、構成ポーリングを1分に1回ずつ繰り返し実行するようになります。
値を-2に設定すると、WebGateはポーリングを行いません。0より大きい値を設定すると、指定した間隔でポーリングを行います。-1に設定すると、WebGateが非アクティブな状態が1分間続いても、WebGateはポーリングを行いません。WebGateがアクティブな状態に戻ると、構成ポーリングを再開します。
アクセス・ゲートのパラメータ変更が必要になる場合があります。アクセス・ゲートの変更は、アクセス・システム・コンソールまたはコマンドライン・ツールのconfigureAccessGateを使用して行うことができます。通常、コマンドライン・ツールは、トランスポート・セキュリティ・モードの変更に使用します。このツールは、WindowsおよびSolarisのどちらのインストールでも使用可能です。
|
注意: アスタリスク（*）記号付きのフィールドを変更した場合は、このアクセス・ゲートをホストしているサーバーの再起動が必要です。アクセス・ゲート名を一度割り当てて保存すると、変更はできません。アクセス・ゲートの名前を変更するには、インスタンスを削除してアンインストールし、新しいアクセス・ゲートを作成する必要があります。 |
アクセス・システム・コンソールによってアクセス・ゲートを変更する手順
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
各リストから検索属性および条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」を選択します。
「検索」リストは、表3-2に記載した検索可能な属性の選択リストです。その他のフィールドでは、選択した属性に対応する検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
変更するアクセス・ゲートの名前をクリックします。
アクセス・ゲートの詳細ページが表示されます。
「変更」をクリックします。
「アクセス・ゲートの変更」ページが表示されます。このページで新しい情報を入力できます。
アクセス・ゲートの名前は変更できません。アクセス・ゲートの名前を変更するには、アクセス・ゲートをアクセス・システム・コンソールから削除してアンインストールする必要があります。その後で、新しいアクセス・ゲートを作成します。
必要となる新しい値を入力します。
変更内容を保存する場合は、「保存」をクリックします。または、保存しないでページを終了する場合は、「取消」をクリックします。
次の場所に移動します。
AccessGate_install_dir\access\oblix\tools\configureAccessGate
ここで、AccessGate_install_dirはアクセス・ゲートがインストールされているディレクトリです。
configureAccessGateディレクトリで、次のコマンドを実行します。
configureAccessGate -i AccessGate_install_dir -t AccessGate|WebGate options
表3-4に記載されているコマンドを使用して、パラメータを指定します。
表3-4 configureAccessGateおよびconfigureWebGateのコマンド
コマンドラインによってトランスポート・セキュリティ・モードを再構成する手順
アクセス・ゲートのトランスポート・セキュリティ・モードを再構成するには、次のコマンドを実行します。
configureAccessGate -i AccessGate_install_dir -t <AccessGate|WebGate> -R
次に例を示します。
configureAccessGate -i C:\COREid\WebComponent\access -t AccessGate -R
トランスポート・セキュリティ・モードを選択するよう求めるプロンプトが表示されます。
| Openを選択した場合 . . | Simpleを選択した場合 . . | Certを選択した場合 . . |
|---|---|---|
| トランスポート・セキュリティ・モードが再構成され、Openモードで実行されます。 | 1. 次のように、アクセス・ゲートのパスワードを指定します。
アクセス・ゲートのインストールまたは構成時にパスワードを指定している場合は、そのパスワードを入力します。未指定の場合は、[Enter]キーを押してプロンプトをスキップします。 2. グローバル・アクセス・プロトコル・パスフレーズを入力します。入力すると、証明書が生成され、インストールされます。 |
1. 次のように、アクセス・ゲートのパスワードを指定します。
アクセス・ゲートのインストールまたは構成時にパスワードを指定している場合は、そのパスワードを入力します。未指定の場合は、[Enter]キーを押してプロンプトをスキップします。 2. グローバル・アクセス・プロトコル・パスフレーズを入力します。入力すると、証明書が生成され、インストールされます。 次に、後続のステップを実行します。 |
Certモードの場合: 証明書のリクエストまたはインストールのどちらを行うかを指定するよう求められます。
証明書リクエストを指定すると、次の組織情報の入力を要求されます。
国名
都道府県などの行政区分
地域
組織名
組織単位
一般名（HostName.DomainName.comなど）
電子メール・アドレス
情報を入力すると、証明書リクエストが生成され、Component_install_dir\access\oblix\config\aaa_req.pemファイルとして格納されます。
ここで、Component_install_dirは、Access Systemコンポーネントがインストールされているディレクトリです。
この証明書リクエストには認証局の署名を受ける必要があります。
証明書鍵ファイル、証明書ファイルおよび証明連鎖ファイルの場所のフルパスを入力するよう求められます。
パスを指定後、トランスポート・セキュリティ・モードが再構成されます。
トランスポート・セキュリティ・モードのパスワードを変更する手順
コマンドラインで、次のコマンドを実行します。
configureAccessGate -i AccessGate_install_dir -t AccessGate -k
次の情報を入力します。
旧パスワード
新パスワード
新パスワード（確認用）
パスワードが変更されます。
アクセス・ゲートを削除すると、そのアクセス・ゲートが接続していたホスト上のアプリケーションおよびコンテンツが、アクセス・システムで保護されなくなります。それでもかまわないかどうかをアクセス・ゲートの削除前に確認してください。
アクセス・ゲートをホストからアンインストールします。
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
各リストから検索属性および条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」を選択します。
「検索対象」リストは、表3-2に記載した検索可能な属性の選択リストです。その他のフィールドでは、選択した属性に対応する検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
削除するアクセス・ゲートを確認し、「削除」をクリックします。
決定の確認を求められます。
アクセス・ゲートを削除する場合は、「OK」をクリックします。または、削除を中止する場合は、「取消」をクリックします。
WebGateは、HTTPベースのリソースに対するデフォルトのAccess Clientです。WebGateは、Webリソースに対するHTTPリクエストを捕捉してアクセス・サーバーに転送する、NSAPIまたはISAPIプラグインです。
WebGateの構成手順は、アクセス・ゲートの構成手順と同様です。「アクセス・ゲートの追加」を参照してください。次の各トピックでは追加情報を提供します。
すべてのアクセス・サーバーおよび対応するWebGateの時間を同期化させる必要があります。セキュア・リクエストにはすべてタイムスタンプが含まれています。
正常に操作するには、次のようにします。
すべてのコンピュータを60秒以内の時差に収まるように同期化します。
WebGateを実行している各コンピュータのクロックが、それが関連付けられているアクセス・サーバーより進まないようにします。
WebGateのパラメータ変更が必要になる場合があります。WebGateの変更は、アクセス・システム・コンソールまたはコマンドライン・ツールのconfigureWebGateを使用して行うことができます。通常、コマンドライン・ツールは、トランスポート・セキュリティ・モードの変更に使用します。このツールは、WindowsおよびSolarisのどちらのインストールでも使用可能です。
WebGateを変更するには、次のディレクトリに移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate
ここで、WebGate_install_dirは、WebGateがインストールされているディレクトリです。
configureWebGateディレクトリで、次のコマンドを実行します。
configureWebGate -i WebGate_install_dir -t WebGate
表3-4に記載されているコマンドを使用して、パラメータを指定します。
configureWebGateの使用例
次に示すのは、Microsoft Windows上でconfigureWebGateツールを使用してWebGateを構成する例です。
C:\COREid\webcomponent\access\oblix\tools\configureWebGate> configureWebGate -i c:\COREid\webcomponent\access -t WebGate -w andium_AG -m cert -c install -S -P milpid -h andium -p 5160 -a andium_AS -r 99malibu -Z 5
IPアドレスの検証は、WebGate固有のものです。IPアドレス検証では、クライアントのIPアドレスと、シングル・サインオン用に生成されたObSSOCookieに格納されたIPアドレスが一致するかどうかを確認します。「IPValidation」パラメータは、IPアドレス検証のオンとオフを切り替えます。「IPValidation」がtrueの場合は、ObSSOCookieに格納されたIPアドレスが、クライアントのIPアドレスと一致する必要があります。一致しない場合、ObSSOCookieは拒否され、ユーザーは再認証を受ける必要があります。「IPValidation」のデフォルト設定は、trueです。
「IPValidation」パラメータは、一部のWebアプリケーションで問題が生じる場合があります。たとえば、プロキシ・サーバーで管理されるWebアプリケーションは、通常、ユーザーのIPアドレスをプロキシのIPアドレスに変更します。これは、ObSSOCookieを使用するシングル・サインオンの妨げになります。
「IPValidationException」パラメータには、この検証プロセスの対象として例外となるIPアドレスをリストします。「IPValidation」がtrueの場合は、IPアドレスを「IPValidationException」リストと比較できます。そのアドレスが例外リストにある場合、そのアドレスはCookieに格納されたIPアドレスと一致しなくてもよくなります。IPアドレスは、必要な数だけ追加できます。これらのアドレスは、クライアントの実際のIPアドレスであり、obSSOCookieに格納されたIPアドレスではありません。ObSSOCookieに格納されているアドレスは、そのCookieが例外IPアドレスのいずれかから発行されたものである場合、アクセス・システムにより検証を受けなくて済みます。たとえば、CookieのIPアドレスがリバース・プロキシ用のアドレスである場合に、「IPValidationException」パラメータのIPアドレスを使用できます。
WebGateと認証時のクライアントIPアドレスを持たないAccess Clientの間のシングル・サインオンを構成するには、IP検証を明示的に無効にできます（IP検証をfalseに設定）。「IPValidation」パラメータをfalseに設定すると、ブラウザまたはクライアントのIPアドレスは、ObSSOCookieの構成要素として使用されなくなります。ただし、IP検証は、可能なかぎり有効にしておくことをお薦めします。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「アクセス・ゲート構成」をクリックします。
アクセス・ゲートを見つけ、そのリンクをクリックします。
このアクセス・ゲートの詳細ページで、「変更」をクリックします。
検証を無効にするには、「IPValidation」フィールドで「オフ」オプションを選択します。
検証を有効にするには、「IPValidation」フィールドで「オン」オプションを選択し、「IPValidationException」フィールドに検証から除外するIPアドレスを入力します。
アドレスは標準表記法で記述します。たとえば10.20.30.123のようになります。プラスまたはマイナス・ボタンを押して、IPアドレスを追加または削除します。
WebGate診断URLを使用して、WebGateに接続されたアクセス・サーバーに関する情報を表示できます。関連付けられているディレクトリ・サーバー情報も表示します。
診断URLのリンクを表3-5に示します。
表3-5 診断URLのリンク
| プラットフォーム | URL |
|---|---|
|
Domino |
http://WebGate_computer:portnumber/access/oblix/apps/webgate/bin/
webgate.cgi?progid=1
|
|
IIS |
http://WebGate_computer:portnumber/access/oblix/apps/webgate/bin/webgate.dll?progid=1
|
|
NetscapeおよびApache |
http://WebGate_computer:portnumber/access/oblix/apps/webgate/bin/webgate.cgi? progid=1
|
ここで、WebGate_computerはWebサーバーとWebGateがインストールされたコンピュータであり、portnumberはそのWebサーバーのポート番号です。
このURLにアクセスすると、表3-6に示されている情報がブラウザに表示されます。
表3-6 診断URLの入力後にブラウザに表示される情報
| トピック | 説明 | |
|---|---|---|
|
アクセス・サーバー |
アクセス・サーバーのホスト名、ポート番号およびこのWebGateとの接続数 |
|
|
状態 |
アクセス・サーバーの状態（起動中または停止中のいずれか） |
|
|
作成 |
このアクセス・サーバーがインストールされた日付と時間 |
|
|
Install_Dir |
このアクセス・サーバーのインストール・ディレクトリ |
|
|
スレッド数 |
アクセス・サーバーで許容されるスレッドの最大数 |
|
|
ディレクトリ情報 |
ディレクトリ |
このディレクトリ・インスタンスに格納される情報のタイプ（ユーザー、ポリシーまたはOblix） |
|
ホスト:ポート |
このディレクトリ・インスタンスのホスト名およびポート番号 |
|
|
状態 |
ディレクトリ・サーバーの運用状態（起動中または停止中のいずれか） |
|
|
優先度 |
このWebGateにとってのこのアクセス・サーバーの優先度（プライマリまたはセカンダリのいずれか） |
|
|
モード |
ディレクトリ・サーバーの接続モード（オープンまたはSSLのいずれか） |
|
|
サイズ制限 |
検索に対してLDAPサーバーから戻す最大エントリ数 |
|
|
時間制限 |
LDAPサーバーでLDAP操作をどれぐらい長く実行するか |
|
|
ログインDN |
ディレクトリ・サーバー・インスタンスのルートDN |
|
|
作成 |
このディレクトリ・サーバー・インスタンスが作成された日付と時間 |
|
使用するWebサーバーのタイプによっては、URLを発行して、WebGateのステータスを任意のブラウザからチェックできます。
ブラウザで、次のURLのいずれかを発行します。
IISの場合:
http://servername:port/access/oblix/apps/webgate/bin/webgate.dll?progid=1
iPlanetおよびApacheの場合:
http://servername:port/access/oblix/apps/webgate/bin/webgate.cgi?progid=1
Dominoの場合:
http://servername:port/access/oblix/apps/webgate/bin/nwebgate.dll?progid=1
WebGateまたはアクセス・ゲートの構成を変更すると、変更は1分未満の間に有効になります。たとえば、新しいプライマリ・サーバーを追加し、アクセス・サーバーへの接続数を1増加すると、この変更はサーバーを再起動しなくても有効になります。
保留リクエストが終了して2、3分経過すると、アクセス・サーバーとWebGate（またはアクセス・ゲート）間の古い接続は破棄されます。古い接続が破棄された後にnetstatコマンドを発行すると、サーバー起動以降の接続数が2倍検出される場合があります。ただし、この数値は、構成されている接続数にまで速やかに（通常は2、3分の間に）減少します。接続情報が変更されるたびに、netstatコマンドで検出される接続数が2、3分の間2倍になり、構成されている接続数にまで再び減少します。
WebGateはリバース・プロキシとともに使用できます。
次にリバース・プロキシを使用する利点をあげます。
リクエストがすべてプロキシを経由するかぎり、すべてのWebコンテンツを単一の論理コンポーネントから保護できます。
これは、Oracle Access Managerがサポートしていないプラットフォームでも可能です。様々なタイプのWebサーバー（たとえばiPlanet、Apacheなど）がいろいろなプラットフォーム（たとえばWindows XP、Linuxなど）で動作している場合でも、これらのサーバーのすべてのコンテンツを保護できます。リバース・プロキシは、サポートされていないWebサーバーに対する解決策となります。このため、サポートされていないWebサーバーおよびWebGateサポートのないプラットフォーム（MacOSなど）でカスタム・アクセス・ゲートを作成することが不要になります。
リバース・プロキシを使用することで、アーキテクチャが柔軟になります。
リバース・プロキシを使用すると、イントラネットで使用可能なアプリケーションをデプロイしてエクストラネットに公開できるようになります。また、エクストラネットで使用可能なアプリケーションをイントラネットに公開することもできます。これらのことは、すでにデプロイされているアプリケーションを変更することなく行うことができます。
リバース・プロキシに1つのWebGateをインストールするだけで、各Webサーバー上にインストールする必要がなくなります。
これによって、管理ポイントが単一になり、システムの管理が容易になります。他のWebサーバーにフットプリントを確保しなくても、リバース・プロキシを経由することで、すべてのWebサーバーのセキュリティを管理できます。
プロキシ使用の主な短所は、設定時に必要な作業が増えることです。リバース・プロキシの背後にあるWebサーバーにWebGateをデプロイする場合は、次の構成要件を満たす必要があります。
認証にリバース・プロキシを使用するすべてのWebサーバーが、リバース・プロキシからのリクエストのみを受け付けるようにします。
またこの場合、このWebサーバーにデプロイされるWebGateが、そのWebGateのフロントエンドとなるリバース・プロキシ・サーバーからのリクエストに対してIP検証を強制しないように構成する必要があります。これには、1つ以上のリバース・プロキシ・サーバーの既知のIPアドレスをIPValidationリストに構成します。これと同じ効果は、WebGateに対するIP検証を無効にすることでも得られますが、セキュリティ上危険があるため、このアプローチはお薦めしません。Webサーバーがリバース・プロキシからのリクエストのみを受け付けるようにするには、通常、サーバーにACL文を追加します。これにより、ユーザーがリバース・プロキシをバイパスし、制限されたコンテンツに直接アクセスすることを防ぎます。
ポリシー・マネージャで構成された仮想ホストを更新し、リバース・プロキシに送信されたリクエストをアクセス・システムが捕捉するようにします。
ユーザーがバックエンドシステムを直接参照するURLを入力することでプロキシを回避することを防止します。
この問題の発生を防止するには、Webサーバーのアクセス制御リストまたはファイアウォール・フィルタを使用します。
すべてのユーザー・リクエストがプロキシによって処理されるため、負荷を処理するのに十分な数のプロキシ・サーバーをデプロイする必要があります。
既存のすべてのURLをリバース・プロキシ・サーバーのホスト名およびポート番号にリダイレクトします。
このため、リンク切れなどを防ぐため、絶対パスによるHTMLリンクを防止するためのコンテンツの検査および書換えを実行するようにリバース・プロキシを構成することが必要になる場合がよくあります。これはほとんどのリバース・プロキシで可能であり、またアクセス・システムとは無関係に構成できます。
フロントエンド・アプリーケーションに対して公開するURLリンクには相対URL（../../sub-path/resource）のみを使用し、絶対URL（http://hostname.domain:[port]/path/resource）は使用しないことをお薦めします。
絶対URLは、リバース・プロキシの背後にデプロイされると、エンドユーザーのブラウザ上ではリンク切れになる可能性があります。
アクセス・ゲートを、個々のアクセス・サーバーまたはアクセス・サーバー・クラスタに関連付けることができます。各アクセス・ゲートに対して、通信可能なアクセス・サーバーまたはアクセス・サーバー・クラスタを少なくとも1つ選択する必要があります。アクセス・サーバーまたはアクセス・サーバー・クラスタは、すでにインストールおよび構成されている必要があります。
|
注意: WebGateを関連付ける手順は、アクセス・ゲートを関連付ける手順と同じです。 |
関連付けられているアクセス・ゲートは、アクセス・サーバーの詳細ページ、またはアクセス・サーバー・クラスタの詳細ページに表示できます。また、関連付けられているアクセス・サーバーおよびアクセス・サーバー・クラスタは、アクセス・ゲートの詳細ページに表示できます。アクセス・ゲートとアクセス・サーバーまたはアクセス・サーバー・クラスタ間の構成にエラーがある場合は、このページにエラーが表示されます。
たとえば、アクセス・ゲートのセキュリティ・モードが、関連付けられたアクセス・サーバーまたはアクセス・サーバー・クラスタのセキュリティ・モードと異なる場合などです。このような場合は、エラーがページに表示されます。
この項の残りの内容は次のとおりです。
アクセス・ゲートをアクセス・サーバー・クラスタと関連付けると、アクセス・ゲートはクラスタ内のすべてのアクセス・サーバーと自動的に通信します。クラスタからアクセス・ゲートの関連付けを解除すると、アクセス・ゲートとクラスタ内の各アクセス・サーバーの接続は自動的に削除されます。
アクセス・サーバーをクラスタに追加すると、そのクラスタに関連付けられたすべてのアクセス・ゲートが、新しいアクセス・サーバーと自動的に通信します。アクセス・サーバーをクラスタから削除すると、アクセス・ゲートとそのアクセス・サーバーの接続は自動的に削除されます。
ロード・バランシングは、アクセス・ゲートの構成時に指定した接続数と、クラスタ内のアクセス・サーバーの数に基づいて自動的に構成されます。ロード・バランシングの構成の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
フェイルオーバーは、アクセス・ゲートを、プライマリ・クラスタまたはバックアップ・クラスタとして定義したアクセス・サーバー・クラスタに関連付けると自動的に構成されます。フェイルオーバーの構成の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
アクセス・サーバーまたはクラスタとアクセス・ゲートを関連付けるには、次の各手順に従ってください。
タスクの概要: アクセス・サーバーまたはクラスタとのアクセス・ゲートの関連付け
1つのコンポーネント同士の関連付け（「アクセス・ゲートをアクセス・サーバーと関連付ける手順」を参照）
コンポーネント間の通信の構成（「このアクセス・ゲートと通信するようにアクセス・サーバーを構成する手順」を参照）
クラスタとのアクセス・ゲートの関連付け（「アクセス・ゲートをアクセス・サーバー・クラスタと関連付ける手順」を参照）
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
各リストから検索属性および条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」を選択します。
「検索対象」リストは、表3-2に記載した検索可能な属性の選択リストです。このリストには、アクセス・ゲートの検索属性、条件および値が含まれます。その他のフィールドでは、選択した属性に対応する検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
アクセス・ゲートの詳細ページが表示されます。
アクセス・ゲートがアクセス・サーバーに関連付けられていない場合は、次の手順を実行します。
「アクセス・サーバーの関連付け」をクリックします。
アクセス・ゲートとアクセス・サーバーの関連付けページが表示されます。
個々のサーバーを選択し、アクセス・ゲートをアクセス・サーバーと関連付けます。
「次へ」をクリックします。
ページには、アクセス・ゲートと通信するよう構成されている、すべてのプライマリおよびセカンダリ・アクセス・サーバーが表示されます。
このアクセス・ゲートと通信するようにアクセス・サーバーを構成する手順
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックし、左側のナビゲーション・ペインにある「アクセス・ゲート構成」をクリックします。
|
注意: アクセス・サーバーでアクセス・ゲートからのリクエストを受信するには、その前に、アクセス・サーバーをインストールおよび構成しておく必要があります。 |
アクセス・ゲートの検索基準を入力するか「検索」バーで「すべて」をクリックし、「実行」をクリックします。
アクセス・ゲートのリンクをクリックして変更します。
「アクセス・サーバーをリスト」をクリックします。
「追加」をクリックします。
リストからアクセス・サーバーを選択します。
「優先順位の選択」フィールドで、「プライマリ」または「セカンダリ」を選択し、アクセス・サーバーがプライマリ・サーバーまたはセカンダリ・サーバーのどちらであるかを指定します。
このアクセス・ゲートがこのアクセス・サーバーとの間に確立可能な最大接続数を入力します。
デフォルト値は1です。
このサーバーの構成を完了する場合は、「追加」をクリックします。または、前のページに戻る場合は、「戻る」をクリックします。
アクセス・ゲートをアクセス・サーバー・クラスタと関連付ける手順
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
各リストから検索属性および条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」を選択します。
「検索」リストは、表3-2に記載した検索可能な属性の選択リストです。その他のフィールドでは、選択した属性に対応する検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
アクセス・サーバー・クラスタと関連付けるアクセス・ゲートのリンクをクリックします。
アクセス・ゲートの詳細ページが表示されます。
アクセス・ゲートがクラスタに関連付けられていない場合は、次の手順を実行します。
「アクセス・サーバーをリスト」をクリックし、構成済アクセス・サーバーのリストを表示します。
ページには、アクセス・ゲートと通信するよう構成されている、すべてのプライマリおよびセカンダリ（バックアップ）アクセス・サーバー・クラスタが表示されます。
アクセス・ゲートをクラスタと関連付けるため、「クラスタをリスト」をクリックします。
ページには、アクセス・ゲートと通信するよう構成された、すべてのプライマリ・クラスタおよびバックアップ・クラスタが表示されます。
アクセス・サーバー・クラスタをアクセス・ゲートに関連付けるため、「追加」をクリックします。
「アクセス・ゲートへの新規アクセス・サーバー・クラスタの追加」ページが表示されます。
|
注意: アクセス・サーバー・クラスタでアクセス・ゲートからのリクエストを受信するには、その前に、アクセス・サーバー・クラスタを構成しておく必要があります。 |
リストからアクセス・サーバー・クラスタを選択します。
「クラスタ・タイプの選択」フィールドで、「プライマリ」または「バックアップ」を選択し、アクセス・サーバー・クラスタがプライマリ・クラスタまたはバックアップ・クラスタのどちらであるかを指定します。
アクセス・ゲートにより、プライマリ・クラスタ内のアクセス・サーバーへの接続がオープンされます。アクセス・ゲートは、指定された数の接続をオープンできない場合、バックアップ・クラスタ内のアクセス・サーバーとの接続をオープンします。
フェイルオーバーおよびロード・バランシングの構成の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
変更内容を保存する場合は、「保存」をクリックします。または、保存しない場合は、「取消」をクリックします。
特定のアクセス・サーバーに関連付けられているアクセス・ゲートを表示できます。
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
各リストから検索属性および条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」を選択します。
「検索」リストは、表3-2に記載した検索可能な属性の選択リストです。その他のフィールドでは、選択した属性に対応する検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
アクセス・ゲートのリンクをクリックします。
「クラスタをリスト」をクリックします。
詳細を表示するアクセス・サーバー・クラスタをクリックします。
「アクセス・サーバー・クラスタの詳細」ページが表示されます。
「アクセス・サーバー・クラスタの詳細」ページで、「関連するアクセス・ゲートの表示」をクリックします。
関連付けられたアクセス・ゲート・ページが表示されます。
「プライマリ・クラスタ」を選択します。そのクラスタがプライマリ・クラスタとして構成されているアクセス・ゲートを表示するためです。
「バックアップ・クラスタ」を選択します。そのクラスタがセカンダリ・クラスタとして構成されているアクセス・ゲートを表示するためです。
検索対象として指定したすべてのアクセス・ゲートをリストする場合は「すべて」を選択します。または、ページに表示する検索結果の件数を指定する場合は、数値を入力します。
「実行」をクリックして、検索結果を表示します。
クラスタに関連付けられたアクセス・ゲートの詳細がページに表示されます。
ページが複数にわたる場合、次のページに進むには「次へ」を、前のページに戻るには「前へ」をクリックします。
「戻る」をクリックすると、前のページに戻ります。
アクセス・サーバーまたはクラスタからアクセス・ゲートの関連付けを解除するには、次の手順を実行します。
アクセス・サーバーまたはアクセス・サーバー・クラスタからアクセス・ゲートの関連付けを解除する手順
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
各リストから検索属性および条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」を選択します。
「検索対象」リストは、表3-2に記載した検索可能な属性の選択リストです。その他のフィールドでは、選択した属性に対応する検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
アクセス・サーバーまたはアクセス・サーバー・クラスタとの関連付けを解除するアクセス・ゲートをクリックします。
アクセス・ゲートの詳細ページが表示されます。
「アクセス・サーバーをリスト」または「クラスタをリスト」をクリックします。
アクセス・ゲートに関連付けられたアクセス・サーバーまたはアクセス・サーバー・クラスタが、ページにリストされます。
サーバー・クラスタまたはサーバーのどちらの関連付けを解除するかを選択します。
アクセス・サーバー・クラスタの関連付けを解除するには、クラスタを選択し、「削除」ボタンをクリックします。
アクセス・サーバーの関連付けを解除するには、アクセス・サーバーを選択し、「削除」ボタンをクリックします。
接続が削除されます。
Oracle Access Managerに対するWebサーバー・ホストの識別には、たとえば、コンピュータ名やIPアドレスを指定するなど、様々な方法があります。Webサーバー・ホストのアドレス指定方法の例を次に示します。
site.com
site.com:80
www.site.com
www.site.com:80
216.200.159.58
111.111.11.1:80
3232236564（10進数によるアドレス指定）
WebGateの構成ページには、保護対象のリソースをホストしているWebサーバーを識別するフィールドが2つあります。
優先HTTPホスト: 「優先ホスト」フィールドは必須です。
WebGateは、ユーザーのリクエストが優先HTTPホストのバリエーションの場合でも、このホストへのすべてのユーザー・リクエストを捕捉します。たとえば、このフィールドの値がmyhost22:8080である場合、このURLに対するすべてのリクエストがWebGateにより保護されます。また、ホストを他の方法でアドレス指定した場合でも捕捉します。たとえば、http://123.123.123.123:8080（123.123.123.123はサーバーのIPアドレス）など。
ホスト識別子: ホスト識別子は、すべてのURLアドレス指定方法のリストです。
ポリシーは、ホスト識別子に基づいて作成されます。WebGateは、ホスト識別子に構成されたアドレス指定方法と一致し、ポリシーで使用されているホスト識別子と一致するリクエストをすべて保護します。
3番目の機能として、「保護されていない場合に拒否」を構成すると、ルールまたはポリシーでアクセスが明示的に許可されている場合を除いて、すべてのリソースに対するユーザーのアクセスを拒否できます。詳細は、「デフォルトでのすべてのリソースへのアクセス拒否」を参照してください。
保護の対象となるサーバーまたは仮想サーバーをホストするコンピュータに対応する優先HTTPホストを構成します。
詳細は、「優先HTTPホストの概要」および「仮想Webサーバーの優先HTTPホストを構成する手順」を参照してください。
保護の対象となる各Webサイトまたは各仮想Webサイトのホスト識別子を構成します。
詳細は、「ホスト識別子の構成」を参照してください。
ホスト識別子を使用して同じWebGateによって保護される仮想ホストを識別して、これらのリソースを保護するポリシーを作成します。
たとえば、WebGateによって保護された仮想サイトのうち、1つのサイトのみユーザーのアクセスを許可するポリシーを構成できます。詳細は、「ポリシー・ドメインによるリソースの保護」を参照してください。
この項の残りの内容は次のとおりです。
WebGateを構成する場合は、優先HTTPホストを常に指定する必要があります。詳細は、「アクセス・ゲートの追加」を参照してください。
この項の残りの内容は次のとおりです。
Webホスティングを使用していない環境の場合、「優先HTTPホスト」の値は、WebGateがインストールされているコンピュータの名前（myhost22など）と、Webサイトをホストしているポート（8080など）です。完全な値は、myhost22:8080として指定します。「優先HTTPホスト」フィールドには、ホストのアドレス指定に使用される可能性があるすべての方法と一致するホスト名が含まれる必要があります。また、このフィールドに入力する名前は、「ホスト識別子」フィールドに入力したいずれかの名前と一致する必要があります。詳細は、「ホスト識別子の構成」を参照してください。
WebGateの「優先HTTPホスト」の値を指定し、これと同じ値を「ホスト識別子」フィールドに指定した場合、最初のリクエストのアドレス指定にかかわらず、そのホスト識別子を使用するすべてのポリシーが、WebGateで処理されるすべてのリクエストに適用されます。たとえば、host1.company.comのWebサーバー上にWebGateがある場合、「優先HTTPホスト」の値をhost1.company.comに設定することがあります。host1に対してポリシーが構成されている場合、ユーザーがどのような方法でリソースをアドレス指定した場合でも、ホストに送信されるリクエストにそのポリシーが適用されます。たとえば、ユーザーが、任意のホスト名my.host.comにマップする/etc/hostsファイルを設定し、次のURLをリクエストするとします。
http://my.host.com/someResource
WebGateは、このリクエストのポリシーを設定するとき、ユーザーが指定したURLにかかわらず、優先HTTPホストを使用します。「優先HTTPホスト」フィールドの値と一致するリソースに対するリクエストは、ポリシー評価のためアクセス・サーバーにリダイレクトされます。「優先HTTPホスト」機能により、ホストの識別子が「ホスト識別子」リストに含まれていない場合に予期せず発生する可能性があるセキュリティ・ホールが回避されます。
優先HTTPホストの構成は、仮想ホスティングを使用する環境にも必要です。仮想ホストの場合は、「優先HTTPホスト」フィールドに予約値を指定します。詳細は、「仮想Webホスティングの構成」を参照してください。このフィールドにより、WebGateは、ポリシー評価のため、ユーザーがブラウザに入力したホストにではなくアクセス・サーバーに優先ホスト文字列を渡すようになります。ブラウザに何が入力されても、アクセス・サーバーは常に優先ホストを参照します。
前の項で説明したように、ホストは複数の名前で識別できます。「ホスト識別子」機能を使用して、ホストの正式名と、同ホストのアドレスを指定する際にユーザーが使用できるその他の名前をすべて入力します。このリストの特定のアドレスに送信されるリクエストは、正式ホスト名にマップされます。
「ポリシー・ドメインによるリソースの保護」で説明しているように、ホストのリソースを保護するポリシーを定義する場合は、「ホスト識別子」フィールドの名前を使用します。WebGateは、リクエストを捕捉すると、リクエストのアドレスをチェックします。アドレスがホスト識別子のリストに掲載されている場合、そのアドレスはホストの正式名にマップされ、アクセス・サーバーにより、リソースを保護するルールおよびポリシーの適用が可能になります。
「ホスト識別子」リストにおける要件を次にあげます。
各ホスト名は一意であること。
ホスト名:ポートのペアはすべて一意であること。
ホスト名:ポートのペアは、すべて1つのホスト識別子にのみ含まれていること。
ホスト名:ポートのペアは、すべてエンドユーザーのエントリと正確に一致していること。
10進数によるアドレス指定の場合、同じサイトに対して可能なあらゆる組合せのURLを定義することは現実的ではありません。次の計算式を使用して、元のアドレス01.02.03.04に対して、使用可能な10進アドレスを計算します。ここで、各0は8ビットのオクテットです。元のIPアドレスを表現する方法が複数あることがわかります。
計算式:
01*256^3+02*256^2+03*256+04
次のURL値はすべて同じサイトを表します。
http://%61%73%74%65%72%69%78
http://%31%39%32%2E%31%36%38%2E%34%2E%32%30/
http://%33%32%33%32%32%33%36%35%36%34
詳細は、サイトhttp://www.karenware.com/powertools/ptlookup.aspを参照してください。
「ホスト識別子」リストを作成する手順は、「ホスト識別子を追加する手順」を参照してください。
優先ホストを指定する必要があり、1つ以上のホスト識別子を指定できます。ホスト識別子を指定することで、単一ホストの識別、および複数の仮想Webホストの識別ができます。
この項の残りの内容は次のとおりです。
認証チャレンジを別のホストで処理するようにリダイレクトする場合は、そのホストの名前をホスト識別子リストに追加する必要があります。認証スキームの追加または変更時に「チャレンジ・リダイレクト」フィールドに入力するホスト名を、ホスト名識別子リストに追加する必要があります。たとえば、ユーザーを認証のためにSSL対応サーバーにリダイレクトする場合は、そのサーバーを追加する必要があります。
URL接頭辞をポリシー・ドメインに追加する場合、委任アクセス管理者は、そのURL接頭辞をホストするサーバーを指定する必要があります。ユーザーは、ポリシー・ドメインで保護されているURLにアクセスを試みると、「チャレンジ・リダイレクト」フィールドに指定されたサーバーに、認証を受けるためリダイレクトされます。
「ホスト識別子詳細」ページには、「名前」、「説明」および「ホスト名のバリエーション」が表示されます。次に手順を示します。
アクセス・システム・コンソールを起動し、「アクセス・システム構成」をクリックします。
「アクセス・システム構成」ページが表示されます。
左側のナビゲーション・ペインで、「ホスト識別子」をクリックします。
「すべてのホスト識別子をリスト」ページが表示されます。このページには、既存のホスト識別子がリストされます。
ホスト識別子を表示するには、このリストから名前を選択します。
ホスト識別子を削除するには、このリストから名前を選択し、「削除」をクリックします。
仮想Webホスティングを使用しない環境でホスト識別子を構成する場合、「優先HTTPホスト」フィールドのいずれかのホスト名バリエーションを入力して、シングル・サインオンが正常に動作することを確認する必要があります。ホスト名のバリエーションを追加する際に、それがすでに異なるホスト識別子に存在している場合は、重複を警告するメッセージが表示されます。変更を保存することも、または変更を取り消すこともできます。
仮想Webホスティング（「優先HTTPホストの概要」を参照）をサポートする場合は、「優先HTTPホスト」フィールドに、ホスト名バリエーションではなく、予約名を指定します。
アクセス・システム・コンソールを起動し、「アクセス・システム構成」タブをクリックします。
「アクセス・システム構成」ページが表示されます。
左側のナビゲーション・ペインで、「ホスト識別子」をクリックします。
「すべてのホスト識別子をリスト」ページが表示されます。
「追加」をクリックし、新しいホスト識別子を追加します。
「名前」フィールドで、ホストの名前を入力します。
オプションの「説明」フィールドに、簡単な説明を入力します。
「ホスト名のバリエーション」フィールドで、このホストを識別する名前のあらゆるバリエーションを入力します。
ポート番号を指定しなかった場合、デフォルトのポート番号は、アクセス・システムによって追加されません。
「保存」をクリックします。
複数のWebサイトとドメイン名を含むWebサーバー上にWebGateをインストールできます。WebGateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。
多くのWebサーバーに対する仮想Webホスティング機能を使用すると、複数のドメイン名およびIPアドレスをサポートでき、各サーバーが単一の仮想サーバー上にある一意の各サブディレクトリに解決されます。たとえば、それぞれ独自のドメイン名と一意のサイト・コンテンツを持つabc.comとdef.comを、同じ仮想サーバー上でホストすることができます。名前ベースまたはIPベースの仮想ホスティングが可能です。
Oracle Access Manager 10.1.4.0.1より前では、優先HTTPホストを指定する必要がありませんでした。したがって、複数のホスト識別子を指定し、それらを異なる仮想Webホストに解決することが可能であったため、仮想Webホスティングに対しては有効でした。Oracle Access Manager 10.1.4.2以降では、仮想Webホスティングをサポートするには、「優先HTTPホスト」フィールドに特定の値を指定する必要があります。次に、仮想サーバーの構成について説明します。
仮想サーバーの構成の概要は、次のとおりです。
Apacheベースのサーバー以外のほとんどのWebサーバーでは、仮想ホストをサポートするには、「優先HTTPホスト」の値をHOST_HTTP_HEADERに設定する必要があります。
この値を指定した場合、ユーザーのブラウザからリクエストが送信されると、WebGateにより、「優先HTTPホスト」の値がリクエストのホスト値に設定されます。たとえば、次に示すように、ユーザーがURLに文字列myweb2を入力したとします。
http://myweb2
Webサーバーで、いずれかのWebサイトのホスト名がmyweb2であれば、その一致する仮想サイトでリクエストが処理されます。
Apache、Apache 2、IBM HTTP Server、Oracle HTTP ServerなどのApacheベースのサーバーでは、「優先HTTPホスト」の値をSERVER_NAMEに設定する必要があります。
|
注意: Apacheベースのサーバー以外のホストでは、SERVER_NAMEという値はサポートされません。Apacheベースのサーバー以外でこの値を設定した場合、ユーザーはWebサーバー上のWebGateで保護されたリソースにアクセスできなくなります。ユーザーには、WebGateの構成が正しくないというエラーが表示されます。 |
アクセス・システム・コンソールを起動し、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
「アクセス・ゲートの検索」ページが表示されます。
各リストから検索属性および条件を選択します。または、すべてのアクセス・ゲートを検索するには「すべて」を選択します。
検索可能な属性の詳細は、表3-2を参照してください。選択した属性に適合する検索基準を指定できます。
「実行」をクリックします。
検索結果がページに表示されます。
変更するアクセス・ゲートの名前をクリックします。
アクセス・ゲートの詳細ページが表示されます。
「変更」をクリックします。
「アクセス・ゲートの変更」ページが表示されます。
「優先HTTPホスト」フィールドに、次の値を入力します。
ほとんどのWebサーバーでは、HOST_HTTP_HEADERを入力。
Apacheベースのサーバーでは、SERVER_NAMEを入力。
IISの場合、仮想ホスティングをサポートするには、IISコンソールにもアクセスし、各仮想Webサイトを構成して次の3つのフィールドを含める必要があります。
ホスト・ヘッダー名
IPアドレス
ポート
詳細は、次を参照してください。
アクセス・システムのデフォルトの動作では、リソースがルールまたはポリシーで保護されていない場合は、アクセスを許可します。このデフォルト動作には、「アクセス・ゲート構成」ページにあるブール・フラグ「保護されていない場合に拒否」が使用されています。デフォルトの設定はfalseであり、ルールまたはポリシーで保護されていないリソースへのアクセスが許可されます。
「保護されていない場合に拒否」パラメータをtrueに設定すると、反対の動作が設定されます。すなわち、ルールまたはポリシーでアクセスが明示的に許可されていないすべてのリソースへのアクセスが拒否されます。これによって、WebGateがアクセス・サーバーに問い合せる回数を抑えることができ、大規模またはビジーなポリシー・ドメインのパフォーマンスを改善することができます。
WebサーバーやAccess Clientが異なると要件も異なるため、「保護されていない場合に拒否」はWebGateで実施します。「保護されていない場合に拒否」は、WebGateでないタイプのアクセス・ゲートでは使用できません。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「アクセス・ゲート構成」をクリックします。
アクセス・ゲートを見つけ、そのリンクをクリックします。
このアクセス・ゲートの詳細ページで、「変更」をクリックします。
保護されていないすべてのリソースに対するアクセスを拒否するため、「保護されていない場合に拒否」の設定をtrueに変更します。
WebGateを再起動し、変更をただちに有効にします。
「保護されていない場合に拒否」をtrueに設定した場合は、Login.htmlを匿名認証スキームで保護することも必要になります。そうしないと、関連するリソースにアクセスしたときに、ページが表示されません。
IPアドレスがAとBのコンピュータがあり、どちらもポート80および同じ構成ファイルを使用しているとします。NetscapeおよびiPlanetでは、この構成ファイルはobj.confです。これらの仮想サーバーは、どちらも同じアクセス・ゲートまたはWebGateで保護されています。
「優先ホスト」を使用せずに両方の仮想サーバーのコンテンツをすべて保護することが目標です。これを実現するため、AについてすべてのバリエーションのホストIDを設定し、次に、URLごとにポリシーを定義すると、Aのコンテンツを保護できます。アクセス・ゲートAまたはBのどちらかを「優先ホスト」に設定する必要はありません。また、アクセス・ゲートを保護しているWebGateに対して、「保護されていない場合に拒否」をtrueに設定することで、AおよびBのすべてのコンテンツをデフォルトで保護されるようにすることもできます。
この設定では、ユーザーがAのURLにアクセスしようとすると、最初にポリシーが評価され、対応するアクセス・ポリシーが見つかった場合は、Aのコンテンツのみへのアクセスが拒否されます。
シングル・サインオン用にApacheのリバース・プロキシを使用する場合は、Apacheのhttpd.configファイルに、そのApacheサーバー上で稼働するWebサイトを指定する必要があります。この設定は、グローバルにしてすべてのWebサイトで有効にすることも、ローカルにしてそのWebサイトのみで有効にすることもできます。Oracle Access Managerをロードする際のhttpd.configファイル内への参照は、特定のサイト、仮想ホスト、ディレクトリまたは個別ファイルに関連した参照のみを行うように制限できます。
WebGateを特定のターゲットに関連付けるには、次のディレクティブをhttp.confファイルに移動します。
AuthType Oblix require valid-user
これらのディレクティブを、ApacheがリクエストのたびにWebGateを使用するように指示するブロックの中に置きます。また、これらのディレクティブを、WebGateがコールされるタイミングを制限するブロックに移動することもできます。次に、LocationMatchディレクティブを、VirtualHostディレクティブの後に置く例をあげます。
DocumentRoot /usr/local/apache/htdocs/myserver ServerName myserver.example.net AuthType Oblix require valid-user
前述のLocationMatchブロックを次のようにVirtualHostディレクティブの後に移動すると、WebGateはその仮想ホストに対してのみ動作します。LocationMatchブロックは、必要な数の仮想ホストに対して追加できます。次に、1つの仮想サーバーの保護方法の例を示します。
ServerAdmin webmaster@example.net
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
ProxyRequests On
SSLEngine on
SSLCACertificateFile Z:/Apps/sslcert_myapps_ptcweb32/intermediateca.cer
SSLCertificateFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.cer
SSLCertificateKeyFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.key
ErrorLog logs/proxysite1_log
CustomLog logs/proxysite1_log common
ProxyPass /https://apps.example.com/
ProxyPassReverse /https://apps.example.com/
ProxyPass /bkcentral https://apps.example.com/bkcentral
ProxyPassReverse /bkcentral https://apps.example.com/bkcentral
ProxyPass /NR https://apps.example.com/NR
ProxyPassReverse /NR https://apps.example.com/NR
AuthType Oblix
require valid-user
#*** BEGIN Oracle Access Manager WebGate Specific ****
LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll
WebGateInstalldir Z:/apps/Oracle/WebComponent/access
WebGateMode PEER
SetHandler obwebgateerr
SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none
SSLLog logs/SSL.log
SSLLogLevel info
# You can later change "info" to "warn" if everything is OK
ユーザーまたはアプリケーション（.JSPやJavaアプリケーションなど）がアイデンティティ・システム・アプリケーションやアクセス・システムで保護されたWebリソースにアクセスしようとすると、ログイン手順が始動します。このプロセスは、次の要素に応じて異なります。
リソースが保護されているかどうか、どの認証スキームによって保護されているか。
リソースがWebGateで保護されている場合、アクセス・システムは、認証スキームで定義されたチャレンジ・メソッドの指定に従って、ユーザーに対して情報を提示するよう要求します。
リソースが非保護のアイデンティティ・システム・アプリケーション（たとえば、ユーザー・マネージャ）の場合は、アイデンティティ・システムは独自のログイン・フォームを使用して、ユーザーに資格証明を要求します。
ユーザーを認証できるか。
ユーザーが本人の主張するとおりの人物であることを確認するため、WebGateはユーザーに資格証明を要求します。ユーザーが適切な資格証明を入力すると、WebGateはユーザーを認証し、ObSSOCookieを生成してユーザーのブラウザに設定します。
ObSSOCookieの詳細は、「ログイン時に生成されるCookie」を参照してください。
アクセス・システムのシングル・サインオンが構成されているか。
アクセス・システムのシングル・サインオン機能により、ユーザーは1回のログインで複数の保護されたURLまたはアプリケーションにアクセスできます。シングル・サインオンがドメインに実装されている場合、ユーザーが自分以下のレベルのセキュリティを持つ認証スキームで保護されている複数のリソースにアクセスするには、1度認証を受けるだけで済みます。ObSSOCookieが、ユーザーのブラウザから、ドメインに構成されているすべてのWebGateに渡されるためです。
アクセス・システムのシングル・サインオンがマルチドメイン環境に実装されている場合は、複数のドメインのすべてのホストで認証が成功します。
シングル・ドメインおよびマルチドメイン環境に対するSSOの構成の詳細は、「シングル・サインオンの構成」を参照してください。
ユーザーがコンテンツへのアクセスを許可されているか。また、どのアクションを許可されているか。
WebGateはアクセス・サーバーに問合せを行い、ユーザーがリソースへのアクセスを認可されているかどうかを判定します。アクセス・サーバーが認可処理を実行します。ユーザーが認可されている場合、アクセス・サーバーは、ユーザーが実行を許可されているアクションを指定したポリシーがないかどうかをチェックします。
アクセス・サーバーはチェックした情報をWebGateに送信し、WebGateはリクエストされたリソースをユーザーに戻します。
図3-1は、アクセス・システムの認証プロセスを図解したものです。
図3-2は、アクセス・システムの認可プロセスを図解したものです。
図3-3に、保護されていないリソースに対する処理、保護されたリソースに対するユーザーのアイデンティティの確認、ユーザーの認可および保護されたリソースの処理に関連するすべてのプロセスを示します。
図3-3の内容は次のとおりです。
最初のリクエストがWebGateによって捕捉され、アクセス・サーバーにリクエストが転送される。
ディレクトリ・サーバーからポリシーを取得してリソースが保護されているかどうかを判定する。
保護されたリソースでない場合、リソースの処理が実行される。
保護されたリソースの場合、WebGateが資格証明を要求し、アクセス・サーバーに転送する。
アクセス・サーバーは資格証明をディレクトリ内のレコードと照合する。
認証が成功すると、2番目のラウンドトリップを実行してディレクトリ内の認可ポリシーを確認する。
認可ルールで許可される場合、リソースの処理が実行される。
この項では、ユーザーがアクセス・システムで保護されたリソースにアクセスを試みる場合の様々なシナリオを示します。
手順の概要: アイデンティティ・システムのアプリケーションがWebGateで保護されていない場合のアクセス
ユーザーが、WebGateで保護されていないアイデンティティ・システムのアプリケーションにアクセスを試みます。
アイデンティティ・システムは、ユーザー名やパスワードなどの資格証明をユーザーに要求します。
ユーザーの認証が成功すると、アイデンティティ・アプリケーションはObTEMCおよびObTEMP Cookieを生成します。
Cookieの詳細は、「ログイン時に生成されるCookie」を参照してください。
これらのCookieが生成されると、アイデンティティ・システムはIDアプリケーションへのアクセスをユーザーに許可します。ユーザーは、アプリケーションの構成に対応した特定のアクションを実行できます。
手順の概要: リソースがWebGateで保護されている場合のアクセス
ユーザーが、WebGateで保護されているリソースへのアクセスを試みます。
ユーザーがWebリソースまたはアプリケーションにアクセスを試みると、WebGateがリクエストを捕捉し、Access Manager SDKキャッシュに問合せを行い、リクエストされたリソースとそれに関連付けられた操作が保護されているかどうかを確認します。
リクエストされたリソースのデータがキャッシュに存在しない場合、WebGateはアクセス・サーバーにセキュリティ・ポリシーをリクエストし、そのリソースがアクセス・システムで保護されているかどうかを確認します。
リソースが非保護のアイデンティティ・システム・リソースの場合、WebGateは、リクエストをリソースが格納されているサーバーに転送します。次に、アイデンティティ・システム・アプリケーションが、「手順の概要: アイデンティティ・システムのアプリケーションがWebGateで保護されていない場合のアクセス」の手順に従ってユーザーを認証します。
リソースが保護されている場合、WebGateはObSSOCookieを検索し、ユーザーがすでに認証済であるかどうかを確認します。
ユーザーが未認証の場合、サーバーはユーザーに資格証明を要求します。その際に使用されるチャレンジ・メソッドは、使用されている認証スキームに応じて異なります。
フォーム・ベース認証スキームが使用されている場合は、WebGateによりObFormLoginCookieが生成されます。詳細は、「ログイン時に生成されるCookie」を参照してください。認証スキームに関する一般情報については、「新規認証スキームの定義」を参照してください。
ユーザーの認証が成功すると、WebGateはObSSOCookieを生成し、ユーザーのブラウザに対する次のレスポンスに追加のため設定します。
認証成功と認証失敗に対して指定するアクションによって、ユーザーを特定のURLにリダイレクトしたり、ユーザー情報をヘッダー変数またはCookie値に入れて他のアプリケーションに渡すことができます。
WebGateは、リソースの認可についての情報をアクセス・サーバーに問い合せます。
アクセス・サーバーは、ディレクトリ・サーバーに、該当する認可ポリシーが格納されているかを問い合せ、そのポリシーを評価して、この情報をWebGateに渡します。
アイデンティティ・システム・アプリケーションに対するSSOに関しては、認可ポリシーで、HTTP_OBLIX_UIDヘッダーをアイデンティティ・システム・アプリケーションのユーザーIDに設定するアクションを設定する必要があります。このヘッダーが設定されていない場合、アプリケーションは、「手順の概要: アイデンティティ・システムのアプリケーションがWebGateで保護されていない場合のアクセス」の手順に従ってユーザーを認証します。
ユーザーが認証されると、リクエストされたコンテンツへのアクセスが許可され、HTTP_OBLIX_UIDヘッダーが設定されます。
認可成功と認可失敗に対して指定する認可アクションによって、ユーザーを特定のURLにリダイレクトしたり、ユーザー情報をヘッダー変数またはCookie値に入れて他のアプリケーションに渡すことができます。
アイデンティティ・システム・アプリケーションは、HTTP_OBLIX_UIDヘッダー変数を読み取り、IDを取得します。アイデンティティ・システム・アプリケーションは、IDからユーザーのアクセス権を判別します。
.jspまたはJavaアプリケーションなどのクライアント・アプリケーションが、WebGateで保護されているIDリソースのURLにアクセスを試みます。
クライアント・アプリケーションは、Access Manager APIを使用して、アクセス・システムの認証および認可サービスとやりとりします。アプリケーションは、クライアントのユーザー資格証明をAccess Manager APIに提示します。
アクセス・サーバーは、該当する認証ルールを問い合せ、評価します。
Access Manager APIはユーザーを認証し、セッション・トークンを作成します。
Webアプリケーションは、ObSSOCookieを、クライアント・アプリケーションが含まれるドメインのセッション・トークンを使用して設定し、Cookieをリクエストとともにクライアント・アプリケーションに送信します。
WebGateは、クライアント・ユーザーの認可についての情報をアクセス・サーバーに問い合せます。
アクセス・サーバーは、ディレクトリ・サーバーに、該当する認可ポリシーが格納されているかを問い合せ、そのポリシーを評価して、この情報をWebGateに渡します。
アイデンティティ・システム・アプリケーションに対するSSOに関しては、認可ポリシーで、HTTP_OBLIX_UIDヘッダーを設定するアクションを設定する必要があります。このヘッダーには、アイデンティティ・システム・アプリケーションで使用するユーザーIDを設定する必要があります。このヘッダーが設定されていない場合、アイデンティティ・システム・アプリケーションは、「手順の概要: アイデンティティ・システムのアプリケーションがWebGateで保護されていない場合のアクセス」の手順に従って、自身でクライアント・アプリケーションを認証します。
クライアント・アプリケーションが認可されると、リクエストされたコンテンツへのアクセスが許可され、HTTP_OBLIX_UIDヘッダーが設定されます。
認可成功と認可失敗に対して指定する認可アクションによって、ユーザーを特定のURLにリダイレクトしたり、ユーザー情報をヘッダー変数またはCookie値に入れて他のアプリケーションに渡すことができます。
|
注意: クライアント・アプリケーションは、認可されると、リソースへのアクセスを許可されます。 |
シナリオによって、アクセス・システムは1つ以上のCookieを生成します。Cookieには、ユーザーDN、クライアントのIPアドレスおよびCookieの有効期間などの情報が含まれます。
ObSSOCookieは、暗号化されたシングル・サインオンのCookieであり、ユーザーの認証が成功したときにアクセス・サーバーによって生成されます。ObSSOCookieは、セッション・ベースのCookieであり、ユーザーID情報が格納されます。この情報は、必要に応じてキャッシュすることもできます。
ObSSOCookieの詳細は、「シングル・サインオンの構成」を参照してください。
Netscape、Mozilla、Firefoxなどの一部のブラウザは、オープンしているすべてのブラウザ・ウィンドウ間でセッション状態を共有します。Oracle Access Managerにログインし、ブラウザにobSSOCookieが保存されている場合、オープンしているすべてのブラウザ・ウィンドウが同じCookieを共有します。別のブラウザ・ウィンドウをオープンして保護されたリソースにアクセスすると、現在のobSSOCookieが保存されたブラウザを持つユーザーとして自動的に認証されます。
これらのブラウザのobSSOCookieを破棄するには、obSSOCookieを削除またはクリアし、ログアウトURLを構成するか、デスクトップ上のすべてのブラウザ・セッションをクローズする以外に方法はありません。詳細は、「ログアウトの構成」を参照してください。
ObBasicAuthCookieは、リソースを保護するために使用されるHTTPの基本的な方法です。詳細は、「デフォルト認証スキーム」を参照してください。
ObFormLoginCookieは、フォーム・ベース認証スキームがWebリソースの保護に使用されている場合に生成されます。WebGateは、ObFormLoginCookieを使用して、ユーザーをリクエストしたリソースに、認証成功後にリダイレクトします。
ObFormLoginCookieには、元のリクエスト情報が保管されます。デフォルトでは、このCookieは、ブラウザが最初にフォームにリダイレクトされたときに設定されます。ObFormLoginCookieには、元のリクエストに関する次の情報が格納されます。
リクエストされたURL
リクエストされた操作
認証スキーム
戻るホストのURL
詳細は、「フォーム・ベース認証」を参照してください。
ObTEMC Cookieは、暗号化されたセッション・ベースのCookieであり、ユーザーの認証が成功したときに、アイデンティティ・アプリケーションによって生成されます。ObTEMC Cookieには、次の情報が格納されます。
ユーザー識別名（DN）および元のDN。元のDN情報は、ID代替権限機能を使用している場合にのみ格納されます。代替管理者および代替権限の追加の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
ユーザーがマスター管理者、ID管理者またはアクセス管理者のいずれであるかを指定するフラグ。
シングル・サインオン（SSO）が実装されている場合は、SSOログインID。
タイム・スタンプ。
ユーザーがアクションを実行するたびに、Cookie内のタイム・スタンプが更新され、セッションが使用された最後の時間が反映されます。ただし、SSOが実装されている場合は、タイム・スタンプは無視されます。
クライアント・コンピュータのIPアドレス。
ObTEMP Cookieは、セッション・ベースのCookieであり、ユーザーの認証が成功したときにIDアプリケーションによって生成されます。ObTEMP Cookieには、次のアプリケーション情報が格納されます。
ログイン名
ユーザー・タイプ
検索で生成された結果数（セレクタ情報）
様々な構成アプレット内の未コミットの変更内容
