| Oracle Access Manager統合ガイド 10g（10.1.4.3） B55481-01 |
|
 戻る |
 次へ |
この章では、OracleAS Web CacheとOracle Access Managerを統合し、ポスト・データの復元およびCookieを使用しないサポートを行う方法について説明します。
この章では、次の内容について説明します。
OracleAS Web Cacheはリバース・プロキシ・キャッシュであり、アプリケーションのパフォーマンスを最適化し、低コストの既存のハードウェア・リソースをより効果的に利用する圧縮エンジンです。OracleAS Web Cacheでは、キャッシング・ルールに基づいた静的および動的コンテンツのページ全体のキャッシングが可能です。OracleAS Web Cacheは、アプリケーションWebサーバー（この場合はOracle Access Manager）上のコンテンツとのキャッシュ一貫性を維持するためのメカニズムとして無効化をサポートしています。OracleAS Web Cacheの詳細は、『Oracle Application Server Web Cache管理者ガイド』を参照してください。
Oracle Access Managerとの統合により、OracleAS Web Cacheでは、さらに次のような機能も利用できます。
POSTデータの復元: WebGateでは、POSTリクエストがタイムアウトにより再認証のため中断された後で、Web Cacheを使用してPOSTデータの復元を行います。詳細は、「POSTデータの復元シナリオ」を参照してください。
Cookieを使用しないセッション・サポート: Oracle Access ManagerではWeb Cacheを使用し、Cookieを使用せずにセッションを管理します。詳細は、「Cookieを使用しないセッション・サポートのシナリオ」を参照してください。
この統合の一般的な情報は、「統合のシナリオおよびアーキテクチャ」を参照してください。
この項では、Oracle Access ManagerとOracleAS Web Cache統合後のアーキテクチャおよび情報フローを、次のシナリオで説明します。
Oracle Access Managerとの統合に対するOracleAS Web Cacheトポロジ・サポートにより、1:Nマッピングでリソースをホストする複数のWebサーバーで構成される単一のWeb Cacheが提供されます。サポートされているトポロジを、図4-1に示します。
Oracle Access ManagerとOracleAS Web Cache間の統合に適用される条件は次のとおりです。
OracleAS Web Cacheのキャッシュ・クラスタリング、フェイルオーバーおよびロード・バランシングは、この統合シナリオではサポートされません。
OracleAS Web Cache認可およびアクセス規定を使用するには、Oracle HTTP Serverを介してOracleAS Web Cache Suiteで利用可能なmod_accessモジュールが必要です。
Oracle Application Server Single Sign-Onパートナ・アプリケーション（mod_osso）は、このOracle Access Managerとの統合には含まれません。この統合では、POSTデータの復元およびCookieを使用しないセッション・サポートのみを提供します。
OracleAS Web Cacheは、Oracle Enterprise Manager 10g Application Server Controlコンソールを使用して管理できます。ポート番号18100および9400は、それぞれOracleAS管理コンソールおよびOracleAS Web Cache管理コンソールをホストします。
|
注意: OracleAS Web Cacheの管理タスクは、すべてOracleAS Web Cache管理コンソールを介して処理されます。ただし、『Oracle Application Server Web Cache管理者ガイド』の説明に従って、Oracle Process Manager and Notification（OPMN）を使用できます。 |
OracleAS Web Cacheとの統合により、エンドユーザーのブラウザとOracle Access Managerコンポーネント間にレイヤーが1つ追加されます。接続性の問題を診断する場合は、Web CacheのログとOracle Access Managerコンポーネントのログを両方とも調査する必要があります。監査イベントは、ブラウザとOracleAS Web Cache間で取得されます。これらのイベントは、OracleAS Web CacheとWebGate間で取得される監査イベントとの関係付けが可能です。Oracle Access Managerのイベント監査の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
OracleAS Web CacheとOracle Access Managerの統合によりPOSTデータが保存されます。保存されたデータはユーザー再認証後にWebGateによって取得できます。WebGateでは、POSTリクエストを開始したユーザーの資格証明を取得している場合のみ、再認証後にPOSTデータ・リクエストを処理します。
|
注意: OracleAS Web Cacheと統合しない場合、認証イベント（たとえば、セキュアなセッション・タイムアウトなど）によってPOSTリクエストが中断されても、WebGateによりPOSTデータは保存されません。 |
OracleAS Web Cacheは、リバース・プロキシとしてバックエンド・サーバーに対するゲートウェイになります。図4-2は、Oracle Access ManagerとOracleAS Web Cacheを統合した場合の、POSTデータ復元に関連するコンポーネントおよび情報フローを示しています。
図4-2 OracleAS Web CacheとOracle Access Manager間のPOSTデータ復元
プロセスの概要: OracleAS Web CacheとOracle Access Managerを使用したPOSTデータ復元
ユーザーがOracleAS Web CacheからOracle Access Managerで保護されたリソースをリクエストすると、OracleAS Web Cacheはそのリクエストを受け取って次のものを生成します。
秘密鍵（個々のリクエストに対してOracleAS Web Cacheで生成される一意の識別子）。
キャッシュID（所有者キャッシュのID番号）。OracleAS Web Cacheではクラスタを使用しないため、デフォルトのキャッシュIDは0です。
Oracle Web Cacheの公開cookie ORA_WX_SESSION。これは、主に3つ以上のオリジナル・サーバーがある場合に、セッション・バインディング方式により生成されます。このため、存在しない場合があります。Cookieを使用しないトランザクション中は、除外されることなくブラウザへ送信されます。
OracleAS Web CacheからWebGateにリクエストが渡され、そこからさらにアクセス・サーバーへ送信されます。アクセス・サーバーでは、フォーム・ベースのユーザー認証をチャレンジ方式で行います。
認証および認可に成功すると、リクエストされたページがOracleAS Web Cacheへ送信されます。
リクエストされたコンテンツがキャッシュに入ると、OracleAS Web Cacheからユーザーにそのコンテンツが送信されます。
ユーザーが手順3で受け取ったターゲット・リソースへデータをポストすると、このデータはさらにWebサーバーへポストされます。データをポストするには、「送信」ボタンをクリックします。
この「送信」ボタンはWebアプリケーション開発者によって利用可能になり、ポストされたデータを使用する別のHTMLページをトリガーします。セッションが期限切れ、またはアイドル・セッション・タイムアウトになると、フォーム・ログイン・ページでチャレンジ方式によってユーザーの再認証が実施されます。
再認証によりPOSTリクエストが中断されると、WebGateは、次のキャッシュされたPOSTデータの鍵として使用する一意の識別子（UID）を、OracleAS Web Cacheに返します。
保護されたリソース: リソースが保護されており、POSTリクエストがタイムアウトにより中断された場合、UIDにはユーザーDNおよびOracleAS Web Cache秘密鍵が含まれます。
Web Cache使用不可: WebGateからOracle Access Managerにリクエストが渡されます。
リクエストしているユーザーの再認証が成功すると、中断されていたPOSTデータ・リクエストがWebGateで処理され、OracleAS Web Cacheによってリクエスト・アイテムが送信されます。
|
注意: 復元されたPOSTデータがWebGateに送られると、WebGateではこのリクエストが元のユーザーから送信されているかどうかを確認します。元のユーザーからのリクエストでない場合、WebGateはポスト・データを拒否します。 |
この統合を使用しない場合、Oracle Access Managerでは、Cookieを使用して同レベル（またはより低いレベル）の認証が必要な、保護されたリソースに対するユーザー・アイデンティティ情報を格納します。Oracle Access Manager内では、アクセス・サーバーによりセッションベースの暗号化されたシングル・サインオンCookie（ObSSOCookie）が作成され、認証成功後にWebGateに送信されます。WebGateでは、ObSSOCookieをWebブラウザに送信します。
|
注意: Oracle Access ManagerのObSSOCookieはホストCookieで、そのCookieを発行したWebサイトからのみアクセスできます。ObSSOCookieは、異なるWebサイト間のユーザー・アクションの追跡には使用できません。 |
Oracle Access Managerでは、ObSSOCookieを使用して次の種類のシングル・サインオン（SSO）がサポートされています。
シングル・ドメインSSO: シングル・ドメイン内のURLのセットに使用されます（たとえば、company.comなど）。
マルチ・ドメインSSO: 複数ドメイン内のURLのセットに使用されます（たとえば、company.comおよびyourcompany.comなど）。
この統合を使用しない場合、ObSSOCookieが期限切れになるか、なんらかの理由で消失すると、ユーザー・セッションは期限切れになります。
Cookieを使用しないセッション: この統合により、次のコンポーネントについて、OracleAS Web Cacheを使用するSSOに対し、Cookieを使用しないセッションがサポートされます。
シングル・ドメイン内の1つのWebGate
シングル・ドメイン内の複数のWebGate
複数ドメイン内の複数のWebGate
Cookieを使用しないセッションは、様々な状況でサポートされます。次に例を示します。
WebブラウザでCookieが無効: エンドユーザーは、明示的にCookieサポートをオフにできます。Cookieが無効化されているブラウザからでも、Oracle Access Managerで保護されたリソースにアクセスできる必要があります。この場合、Oracle Access Managerで生成されたObSSOCookieがOracleAS Web Cacheサーバーのキャッシュに格納され、WebGateで取得できます。
モバイル・デバイス（またはサイズの大きいCookieを処理できないデバイス）: 携帯電話、PDA、その他のワイヤレス・デバイスなどの電子デバイスは、帯域幅が制限されています。これらのデバイスでは、含まれるデータが大きいためにObSSOCookieを処理できない場合があります。これは、Webブラウザ上でCookieが無効化されている場合と同様です。ただし、この場合はデバイスがモバイルです。
プライバシ: ユーザーは自身のプライバシ保護のため、すべてのCookieを無効化または非許可にできます。政府機関の中には、特定の政府WebサイトのCookieに、暗号化されたものであっても個人のアイデンティティ・データを含めないよう義務付けていることがあります。Cookieに含めることができるのは、セッション識別子のみです。
Cookieは、ユーザーのサイト間の移動を追跡するために使用できますが、これは、特定の国や政府機関では機密情報に関する問題になることがあります。Oracle Access ManagerのObSSOCookieはホストCookieで、そのCookieを発行したWebサイトからのみアクセスできます。ObSSOCookieは、異なるWebサイト間のユーザー・アクションの追跡には使用できません。
図4-3は、Cookieを使用しないセッション中の処理を示しています。詳細は図を参照してください。
図4-3 Oracle Access ManagerをOracleAS Web Cacheと統合した場合のCookieを使用しないサポート
Oracle Access ManagerのObSSOCookieは、WebGateからOracleAS Web Cacheへ渡されます。
プロセスの概要: Cookieを使用しないセッション中
ユーザーが、OracleAS Web CacheからOracle Access Managerで保護されたリソースをリクエストします。
OracleAS Web Cacheでリクエストが捕捉されます。
リソースがキャッシュされていない場合、OracleAS Web CacheからアプリケーションWebサーバーへリクエストが送信されます。
リソースがOracle Access Managerポリシーで保護されている場合、ユーザー認証が行われます。
認証が成功すると、暗号化されたシングル・サインオンCookie（ObSSOCookie）が生成され、アプリケーションWebサーバーがホストするWebGateへ送信されます。
ObSSOCookieは、ユーザー認証が成功するとアクセス・サーバーで生成されます。このセッションベースのCookieには、ユーザーのアイデンティティ情報が格納されます。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
OracleAS Web Cacheでは、次の処理を行います。
リクエストされたリソースとともに、WebGateからブラウザへ送信されたObSSOCookieを捕捉します。
ObSSOCookieを格納し、リクエストされたページを送信してクライアントに応答します。
Cookieが期限切れになるまで、格納されたCookieを後続のリクエストでのユーザー認証に利用します。
独自の公開CookieであるORA_WX_SESSIONをユーザーのWebブラウザへ送信します。
|
注意: OracleAS Web CacheのCookie（ORA_WX_SESSION）の有効期限は、Oracle Access Managerでは制御されません。OracleAS Web CacheのCookieの詳細は、『Oracle Application Server Web Cache管理者ガイド』を参照してください。ただし、ObSSOCookieの有効期限は、『Oracle Access Managerアクセス管理ガイド』で説明されているように、Oracle Access Managerで制御されます。 |
Oracle Access Managerの最新の動作確認情報は、次の手順を参照してください。
Oracle Technology Networkに移動します。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
「Oracle Identity and Access Management」を探し、最新のOracle Access Manager動作確認のスプレッドシートへのリンクをクリックします。次に例を示します。
System Requirements and Supported Platforms for Oracle Access Manager 10gR3 (xls)
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/
oracle_access_manager_certification_10.1.4_r3_matrix.xls
WebGate Webサーバーの前で使用するリバース・プロキシとして、OracleAS Web Cacheリリース10.1.2.2.1（またはそれ以上）をインストールおよび構成する必要があります。これにより、すべてのリクエストは、OracleAS Web Cacheを介してWebサーバーへルーティングされます。この統合には、OracleAS 10.1.2.3パッチが必要です。
次に示すタスクの概要では、この章の統合シナリオを実装するために、実行する必要があるタスクについて説明します。
タスクの概要: コンポーネントのインストールおよび統合
「統合用コンポーネントのインストール」の説明に従って、使用目的に基づいてOracleAS Web Cacheをインストールおよび構成します。
SSLを有効にしない構成は、POSTデータの復元にのみ使用できます。
SSLが有効な構成は、Cookieを使用しないセッション・サポート（またはPOSTデータの復元）に使用できます。
「統合用コンポーネントのインストール」の説明に従って、Oracle Access Managerをインストールおよび設定します。
POSTデータ復元: 「ポスト・データ復元のためのOracleAS Web Cache構成」の手順に従ってタスクを実行します。
Cookieを使用しないセッション: 「Cookieを使用しないセッション・サポートのためのOracleAS Web Cache構成」の手順に従ってタスクを実行します。
「Oracle Access Managerを使用したリソースの保護」の手順に従って、Oracle Access Managerを使用してリソースを保護します。
テスト: 「統合の検証およびテスト」の手順に従ってタスクを実行します。
この項では、この章の統合シナリオ用のコンポーネントをインストールするために、実行する必要があるタスクについて説明します。
WebGate Webサーバーの前で使用するリバース・プロキシとして、OracleAS Web Cacheリリース10.1.2.2.1（またはそれ以上）をインストールおよび構成する必要があります。これにより、すべてのリクエストは、OracleAS Web Cacheを介してWebサーバーへルーティングされます。
使用目的に基づいて、次の条件がインストールと設定に適用されます。
SSLを有効にしない: POSTデータの復元にのみ使用します。
|
注意: Cookieを使用しないセッション・サポートでは、Web CacheおよびOracle Access Managerを、SSL通信を有効にして構成する必要があります。 |
SSLが有効: Cookieを使用しないセッション・サポート（またはPOSTデータの復元）に使用します。
|
注意: POSTデータの復元を行う場合は、SSLが有効または無効のどちらのデプロイでもWeb CacheとOracle Access Managerを統合できます。 |
次に示すタスクの概要は、他のドキュメントに記載されている一般的な手順だけでなく、この項に含まれる固有の手順も示しています。次の手順では、Windowsの場合の例が示されています。
|
注意: Oracle Universal Installerにより、OracleAS Web CacheがインストールされているORACLE_HOMEが示されます。 |
タスクの概要: 統合コンポーネントのインストール
『Oracle Access Managerインストレーション・ガイド』の情報を参照し、目的の統合シナリオに応じてOracle Access Managerをインストールおよび設定します。
『Oracle Application Server Web Cache管理者ガイド』の説明に従って、次のようにOracleAS Web Cacheをインストールおよび設定します。
Oracle Technology Networkに移動して、「J2EE and Web Cache」または「Web Cache Standalone」のどちらかでOracleAS Web Cacheを探します。
http://www.oracle.com/technology/software/products/ias/htdocs/101202.html
Oracle Access Manager WebGate Webサーバーの前にOracleAS Web Cacheをインストールします。例: as_windows_x86_j2ee_webcache_101202.zip
次のようにOracleAS 10.1.2.3パッチを適用します。
パッチ5983622を適用して、OracleAS Web Cache 10.1.2.3をインストールします。例: patch p5983622_10123_WINNT_webcache.zip
バンドル・パッチ7438911を適用して、Oracle Access ManagerのCookieを使用しないサポートを組み込みます。例: p7438911_10123_WINNT.zip
パッチ8255470を適用します。
OracleAS Web Cacheをリバース・プロキシとして構成します。
次の手順に進み、初期設定を行います。
SSLを有効にしない: POSTデータの復元にのみ使用します。「SSLを有効にしないOracleAS Web Cacheの構成」を参照してください。
SSLが有効: Cookieを使用しないセッション・サポート（またはPOSTデータの復元）に使用します。「SSLが有効なOracleAS Web Cacheの構成」を参照してください。
次に示す初回インストールおよび設定の手順で、目的の要件に従って進みます。
このトピックでは、デプロイでSSLを有効にしない場合のWeb Cacheの構成方法を説明します。
POSTデータの復元を行う場合は、SSLが有効または無効のどちらのデプロイでもWeb CacheとOracle Access Managerを統合できます。ただし、Cookieを使用しないセッション・サポートでは、Web CacheおよびOracle Access Managerを、SSL通信を有効にして構成する必要があります。
次に示す手順を完了すると、オリジナル・サーバーとして構成したWebサーバーでホストされるリソースに、Web Cacheサイトcomputer:portのURLを使用してアクセスできます。サイト定義で指定されているキャッシング・ルールはすべて、アクセスされるリソースに適用されます。
SSLを使用しない統合のためにOracleAS Web Cacheを構成する手順
「統合用コンポーネントのインストール」の説明に従って、OracleAS Web Cacheをインストールし、10.1.2.3.0パッチ・セットを適用します。
『Oracle Access Managerインストレーション・ガイド』の説明に従って、SSLが有効ではないWebサーバーにOracle Access Managerをオープン・モードでインストールします。
OracleAS Web Cache管理コンソールにアクセスします。次に例を示します。
http://webcache_host.company.com:18100
この例では、webcache_host.company.com:18100は、OracleAS Web Cacheを含むOracle Application Serverコンポーネントを管理できる、Oracle Application Server管理サイトを示しています。
または
http://webcache_host.company.com:9400
この例では、webcache_host.company.com:9400は、Web Cacheプロセスおよび構成を（Oracle Application Server管理サイトと同様に）管理できるOracleAS Web Cache専用の管理サイトを示しています。ポート9400は、Oracle Application Server管理サイトで構成できます。
管理コンソールで、インストールされているOracle Application Serverのシステム・コンポーネントから、「Webキャッシュ」をクリックします。
「ホーム」、「パフォーマンス」、「管理」のタブが選択可能です。
「管理」タブをクリックし、Web Cache構成のリンクを表示します。
「プロパティ」から、「ポート」リンクをクリックします。
リスニング・ポートのリストで行を追加し、構成済バックエンド・オリジナル・サーバーでホストされるリソースへのアクセスに使用できる、Web Cacheインスタンスのポートを作成します。次に例を示します。
IPアドレス: *、またはWeb Cacheインスタンスをホストするコンピュータの固有のIPアドレスを入力します。
ポート: 構成済バックエンド・オリジナル・サーバーでホストされるリソースへアクセスする際に使用する、Web Cacheサイトの一意のポート番号を入力します。
プロトコル: 非SSLサイトにはHTTPを入力し、SSL有効サイトにはHTTPSを入力します。
HTTPSのクライアント側証明書: 必須ではありません。
HTTPSのウォレット: 空白のままにします。
「OK」をクリックし、Web Cacheを再起動します。
「管理」タブをクリックします。
「プロパティ」から、「オリジナル・サーバー」リンクをクリックします。
Web Cacheサイトでマッピングするオリジナル・サーバーの新規エントリを作成します。
オリジナル・サーバーでは、保護されたリソースをホストするWebサーバーのcomputer:portが保持されます。このオリジナル・サーバーのエントリがWeb Cacheサイトでマッピングされると、手順7で作成したWeb CacheサイトのURLを使用して、Webサーバーがホストするリソースを利用できるようになります。
「作成」をクリックして、オリジナル・サーバーのエントリを追加します。次に例を示します。
ホスト: リソースWebサーバーをホストするコンピュータ名
ポート: Webサーバーのリスニング・ポートの番号
プロトコル: HTTP
オリジナル・サーバー構成ページのその他の詳細は、デフォルト値を維持します。
「OK」をクリックし、Web Cacheを再起動します。
「管理」タブをクリックします。
「プロパティ」から、「サイト」をクリックします。
「名前付きサイトの定義」で「作成」をクリックし、「一般」タブで次の詳細を入力します。
ホスト: Web Cacheをホストするコンピュータ名を入力します。
ポート: （手順7で指定したように）構成済バックエンド・オリジナル・サーバーでホストされるリソースへアクセスする際に使用する、Web Cacheサイトの一意のポート番号を入力します。
接頭辞: 空白のままにします（任意で/*を入力します）。
サイトのオリジナル・サーバーの詳細で、手順11で作成したオリジナル・サーバーのcomputer:portエントリを次のように移動します。
移動元: 「使用可能なオリジナル・サーバー」リスト
移動先: 「選択したオリジナル・サーバー」リスト
|
注意: 複数のオリジナル・サーバー・エントリを、選択したオリジナル・サーバーのリストへ移動できます。移動したエントリは、ロード・バランシング概念に基づいて使用されます。 |
「OK」をクリックし、Web Cacheを再起動します。
必要に応じて次の手順に進みます。
このトピックでは、SSLを有効にする場合のOracleAS Web Cacheを構成する方法を説明します。Cookieを使用しないセッション・サポートでは、Web CacheおよびOracle Access Managerを、SSL通信を有効にして構成する必要があります。
|
注意: 通常のリスニング・ポート（新規および既存ポートを含む）では、Cookieのキャッシュ設定はグローバルで行われ、サイトまたはポートに基づいたオン・オフはできないため、すべてのポートでSSLを有効にしておく必要があります。SSLが有効になっているポートとそうでないポートがあると、キャッシュが正常に機能しません。例外は管理、無効化および統計ポートのみで、これらのポートではSSLを有効にする必要はありません。 |
POSTデータの復元を行う場合は、SSLが有効または無効のどちらのデプロイでもWeb CacheとOracle Access Managerを統合できます。
次のトピックで、実行する必要がある手順を説明します。
このトピックでは、OracleAS Web Cache SSL通信用のウォレットを作成する手順を説明します。
OracleAS Web CacheのSSLが有効な通信用のウォレットの作成手順
OracleAS Web Cacheをインストールし、10.1.2.3.0パッチ・セットを適用します。
SSLが有効なWebサーバーを使用して、簡易モードまたは証明書モードでOracle Access Managerをインストールします。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
「スタート」、「プログラム」、「Orahome」、「Integrated Management Tools」、「Wallet Manager」の順にクリックし、Wallet Managerを開きます。
ウォレット・コンソールから次の手順を実行します。
新しいウォレットの作成: 「ウォレット」メニューで、「新規」をクリックします。
ウォレットのパスワードを入力して確認します。
ウォレット・タイプ: 標準。
証明書リクエストの作成を依頼します。「はい」をクリックしてWeb Cacheの証明書リクエストを作成し、環境に合った情報を使用して次の手順を実行します。
次のように証明書リクエストの詳細を入力します。
共通名: Web Cacheインスタンスをホストするコンピュータの完全修飾ドメイン名を入力します。
組織単位:
組織:
地域:
都道府県:
国:
キー・サイズ: デフォルト値を維持できます。
「OK」をクリックします。
証明書リクエストを送信します。
|
注意: 証明書リクエストは拡張子.csrを使用するファイルに保存できます。リクエストを.csrファイルで保存するには、Wallet Managerで「証明書リクエスト」ノードを右クリックしてから「証明書リクエストのエクスポート」をクリックし、拡張子.csrを使用して目的の場所に保存します。また、Oracle HTTP Server以外のサーバーを使用する環境には、OpenSSLが使用できます。Oracle HTTP Serverベースの環境には、OCAが使用できます。 |
認証局（CA）から署名付き証明書を取得します。
|
注意: OracleAS Web Cacheの証明書を含む信頼できるCAチェーンがインポートされている場合は、次の手順7を実行する必要はありません。手順7は、証明書が新規ウォレットの作成時に生成され、認証局によって署名された場合に適用されます。 |
CAの署名付きWeb Cache証明書をウォレットにインポートします。
|
注意: 次の手順8は、認証局の証明書について記述しているため、一般的なCAを使用している場合は実行する必要はありません。 |
SSLで構成されているバックエンドWebサーバーの証明書の署名に使用した、CAの証明書をインポートします。
Wallet Managerの「ウォレット」メニューで、「自動ログイン」ボックスを選択することにより、SSLのハンドシェイク・アクティビティ中に使用されるウォレットの.ssoファイルが作成されます。
ウォレットを目的の場所に保存します。
前述の手順により、.ssoファイルおよび.p12ファイルが作成されたことを確認します。
SSLが有効な通信用のOracleAS Web Cacheを構成する前に、前述のトピックの説明に従ってウォレットを作成する必要があります。
次に示す手順を完了すると、オリジナル・サーバーとして構成したWebサーバーでホストされるリソースに、SSLが有効なWeb Cacheサイトcomputer:portのURLを使用してアクセスできます。サイト定義で指定されているキャッシング・ルールはすべて、アクセスされるリソースに適用されます。
SSLが有効な通信のためにOracleAS Web Cacheを構成する手順
OracleAS Web Cacheをインストールし、10.1.2.3.0パッチ・セットを適用します。
SSLが有効なWebサーバーを使用して、簡易モードまたは証明書モードでOracle Access Managerをインストールします。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Web Cache管理コンソールにアクセスします。次に例を示します。
http://webcache_host.company.com:18100
この例では、webcache_host.company.com:18100は、OracleAS Web Cacheを含むOracle Application Serverコンポーネントを管理できる、Oracle Application Server管理サイトを示しています。
または
http://webcache_host.company.com:9400
この例では、webcache_host.company.com:9400は、Web Cacheプロセスおよび構成を（Oracle Application Server管理サイトと同様に）管理できるOracleAS Web Cache専用の管理サイトを示しています。ポート9400は、Oracle Application Server管理サイトで構成できます。
管理コンソールで、インストールされているOracle Application Serverのシステム・コンポーネントから、「Webキャッシュ」をクリックします。
「ホーム」、「パフォーマンス」、「管理」のタブが選択可能です。
「管理」タブをクリックし、Web Cache構成のリンクを表示します。
「プロパティ」から、「ポート」リンクをクリックします。
リスニング・ポートのリストで行を追加し、構成済バックエンド・オリジナル・サーバーでホストされるリソースへのアクセスに使用できる、Web Cacheインスタンスのポートを作成します。次に例を示します。
IPアドレス: *、またはWeb Cacheインスタンスをホストするコンピュータの固有のIPアドレスを入力します。
ポート: 構成済バックエンド・オリジナル・サーバーでホストされるリソースへアクセスする際に使用する、Web Cacheサイトの一意のポート番号を入力します。
プロトコル: 非SSLサイトにはHTTPを入力し、SSL有効サイトにはHTTPSを入力します。
HTTPSのクライアント側証明書: 必須ではありません。
HTTPSのウォレット: 「OracleAS Web Cache SSL通信用のウォレット作成」で作成したウォレットの正確な場所を入力します。
「OK」をクリックし、Web Cacheを再起動します。
「管理」タブをクリックします。
「プロパティ」から、「オリジナル・サーバー」リンクをクリックします。
Web Cacheサイトでマッピングするオリジナル・サーバーの新規エントリを作成します。
オリジナル・サーバーでは、保護されたリソースをホストするWebサーバーのcomputer:portが保持されます。このオリジナル・サーバーのエントリがWeb Cacheサイトでマッピングされると、手順7で作成したWeb CacheサイトのURLを使用して、Webサーバーがホストするリソースを利用できるようになります。
「作成」をクリックして、オリジナル・サーバーのエントリを追加します。次に例を示します。
ホスト: リソースWebサーバーをホストするコンピュータ名
ポート: Webサーバーのリスニング・ポートの番号
プロトコル: HTTPS
オリジナル・サーバー構成ページのその他の詳細は、デフォルト値を維持します。
「OK」をクリックし、Web Cacheを再起動します。
「管理」タブをクリックします。
「プロパティ」から、「サイト」をクリックします。
「名前付きサイトの定義」で「作成」をクリックし、「一般」タブで次の詳細を入力します。
ホスト: Web Cacheをホストするコンピュータ名を入力します。
ポート: （手順7で指定したように）構成済バックエンド・オリジナル・サーバーでホストされるリソースへアクセスする際に使用する、Web Cacheサイトの一意のポート番号を入力します。
接頭辞: 空白のままにします（任意で/*を入力します）。
サイトのオリジナル・サーバーの詳細で、手順11で作成したオリジナル・サーバーのcomputer:portエントリを次のように移動します。
移動元: 「使用可能なオリジナル・サーバー」リスト
移動先: 「選択したオリジナル・サーバー」リスト
|
注意: 複数のオリジナル・サーバー・エントリを、選択したオリジナル・サーバーのリストへ移動できます。移動したエントリは、ロード・バランシング概念に基づいて使用されます。 |
「OK」をクリックし、Web Cacheを再起動します。
必要に応じて次の手順に進みます。
POSTデータ復元のためにOracleAS Web Cacheを構成するには、webcache.xmlファイルを変更する必要があります。
POSTデータ復元のためには、POSTBODYCACHEエレメントを<GENERAL>ノードの下にある<ACCESSLOG>ノード（および該当する場合はSITESノード）の後の、<SITE>ノードの前に追加する必要があります。
その他のPOSTBODYCACHEエレメントの属性は、次のとおりです。
MAXAGE: POSTコンテンツがキャッシュ内に存在できる時間（秒）。デフォルトは120秒です。
MAXCACHEABLESIZE: キャッシュ可能とみなされるPOSTリクエスト・コンテンツの最大サイズ（バイト）。デフォルトは8152バイトです。
|
注意: webcache.xmlの編集には注意が必要です。編集を誤るとエラーが発生することがあります。 |
POSTデータ復元のためにOracleAS Web Cacheを構成する手順
次のパスでwebcache.xmlファイルを検索します。
$ORACLE_HOME/webcache/config/webcache.xml
次の例で示すように、<GENERAL>ノードの下にある<SITE>ノードの前にPOSTBODYCACHEエレメントを追加します。
<GENERAL> ...
<ACCESSLOG> ...
<POSTBODYCACHE> ...
<POSTBODYCACHE ENABLED="YES" MAXAGE="120" MAXCACHEABLESIZE="8152" />
<SITE> ...
Web Cacheサーバーを再起動します。
Cookieを使用しないセッション・サポートのためのOracleAS Web Cacheを構成するには、COOKIECACHEエレメントを、<GENERAL>ノードの下にある<ACCESSLOG>ノードの後の、<SITE>エレメントの前に追加して、webcache.xmlファイルを変更する必要があります。
その他のCOOKIECACHEエレメントの属性は、次のとおりです。
COOKIENAME: 0以上のサブエレメントを次のように定義できます。
<COOKIENAME="cookiename"/>
ここで、cookienameはWeb Cacheがキャッシュする実際のCookieの名前を表します。
|
注意: COOKIEエレメントが指定されない場合、すべてのCookieがキャッシュされます。 |
REDIRECTURL: ドメインCookieの関連付けに使用する、サインオンのSSOリダイレクトURLです。
PASSNOCACHECOOKIES: CookieがCOOKIEエレメントで指定されている名前リストと一致しない場合、Web CacheでそのCookieを渡すか、またはすべてのレスポンスからCookieを除外するかを決定できます。値は次のとおりです。
YES: デフォルトの指定で、Web Cacheによってブラウザ・クライアントにCookieが渡されます。
NO: すべてのレスポンスからCookieが除外されます。
Cookieを使用しないセッション・サポートのためのWeb Cacheを構成する手順を説明します。
|
注意: webcache.xmlの編集には注意が必要です。編集を誤るとエラーが発生することがあります。また、Cookieを使用しないセッション・サポートでは、Web CacheおよびOracle Access Managerを、SSL通信を有効にして構成する必要があります。詳細は、「SSLが有効なOracleAS Web Cacheの構成」を参照してください。 |
Cookieを使用しないセッション・サポートのためのOracleAS Web Cacheの構成手順
次のパスでwebcache.xmlファイルを検索します。
$ORACLE_HOME/webcache/config/webcache.xml
次の例で示すように、<GENERAL>ノードの下にある<SITE>ノードの前にCOOKIECACHEエレメントを追加します。
<GENERAL> ... <ACCESSLOG> ... <POSTBODYCACHE> ... <SITE> ... <COOKIECACHE ENABLED="YES" COOKIENAME="OBSSOCOOKIE"/> REDIRECTURL="http://www.oracle.com" /> PASSNOCACHECOOKIES=No/>
Web Cacheサーバーを再起動します。
この章の統合シナリオを正常に機能させるには、WebサーバーのリソースがOracle Access Managerのポリシー・ドメインおよびアクセス・ポリシーによって保護されている必要があります。リソースを保護する前に、次の前提条件のタスクを実行する必要があります。
マスター管理者の前提条件
ポリシー・マネージャの設定中にポリシー・ベースを定義します。
アクセス・システム・コンソールからポリシー・ベースを確認するには、「システム構成」をクリックし、次に「サーバー設定」をクリックします。『Oracle Access Managerアクセス管理ガイド』の説明に従って、「サーバー設定の表示」ページで「ポリシー・データ構成」セクションを探し、コンピュータ名、ポート、ルートDN、ディレクトリ・サーバー・セキュリティおよびポリシー・ベースを取得します。
ポリシー・マネージャの設定中にポリシー・ドメインを定義します。
ポリシー・マネージャの設定中、マスター管理者はポリシー・ドメイン・ルートを指定します。これは、すべてのリソースを保護するURL接頭辞です。デフォルトのポリシー・ドメイン・ルートを広げてすべてのリソースが含まれるようにします。デフォルト・ルートは/です。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
マスター・アクセス管理者を作成してポリシー・ドメイン、リソース・タイプおよびアクセス・コントロール・スキームを作成し、ポリシー・ドメインの委任管理者のロールを他の人に割り当てます。
マスター管理者のみが、マスター・アクセス管理者を作成できます。マスター・アクセス管理者は、アクセス・システムのあらゆる機能（他のマスター・アクセス管理者の作成を除く）を実行でき、管理機能の委任もできます。『Oracle Access Managerアクセス管理ガイド』のマスター・アクセス管理者の構成およびポリシー・ドメイン管理の委任の項を参照してください。
マスター・アクセス管理者（またはマスター管理者）はポリシー・ドメイン・ルートを定義した後で、最初のポリシー・ドメインを作成する必要があります。最初のポリシー・ドメインの下に複数のURLのポリシー・ドメインを作成でき、さらにそれらのポリシー・ドメインの管理を他の管理者に委任できます。次の概要では、Webリソースを保護するための最初のポリシー・ドメインを作成するのに必要なタスクを示します。
|
関連項目: 次の各タスクの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
最初のドメイン: 最初のポリシー・ドメインの場合は、ポリシー・ドメインの作成の前に次のタスクを実行する必要があります。
ドメインに含むリソースのリソース・タイプを構成します（デフォルトでタイプが定義されていない場合）。これらはタスク2cで必要になります。
アクセス・システム・コンソールから、「アクセス・システム構成」タブをクリックし、左側のペインで「共通情報の構成」リンクをクリックしてから、「リソース・タイプ定義」サブタブをクリックします。
マスター監査ルールを作成します。これはタスク2fで必要になります。アクセス・システムでは、マスター管理者またはマスター・アクセス管理者がマスター監査ルールを作成するまで、監査ログ・ファイルに監査情報が記録されません。
マスター監査ルールは、マスター・アクセス管理者が構成できます。委任アクセス管理者は、マスター監査ルールを使用して、ポリシー・ドメインおよびポリシーに対して自身の監査ルールを作成できます。
アクセス・システム・コンソールから、「アクセス・システム構成」タブをクリックし、左側のペインで「共通情報の構成」をクリックしてから、「マスター監査ルール」サブタブをクリックします。
ポリシー・ドメインで使用する認証スキームを作成します。ポリシー・ドメインには少なくとも1つの認証ルールと、それに従って1つの認証スキームが必要です。このスキームはタスク2eで必要になります。
認証スキームには、ユーザー資格証明のチャレンジに使用するメソッドが含まれます。さらに1つ以上のステップが含まれ、各ステップには認証プロセスの一部を実行する1つ以上のプラグインを含めることができます。単一ステップのスキーム、または連鎖スキームは認証フローを必要とします。
アクセス・システム・コンソールから、「アクセス・システム構成」タブをクリックし、左側のペインで「認証管理」リンクをクリックします。
ポリシー・ドメインで使用する認可スキームを作成します。これは、認可プラグインを使用してカスタム認可スキームを利用する場合に必要となります。それ以外の場合は、ポリシー・ドメインでは認可条件式を構成する個々の認可ルールを作成できます。
定義するすべての認可ルールごとに、認可スキーム（認可プラグインとも呼ばれる）が必要です。デフォルトの認可スキームを使用するか、またはカスタム・スキームを用意することもできます。ポリシー・ドメインには、少なくとも1つの認可ルールを含む認可条件式が必要です。スキームを定義すると、異なるポリシー・ドメインの委任アクセス管理者が、各自のドメインのルールや、各自のドメイン内のポリシーのルールで同じスキームを使用できます。
アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、次に左側のペインで「認証管理」をクリックします。必要に応じて、新規認可スキームを作成する前に、既存の認可スキームの内容と定義を表示します。
ここで説明する手順と『Oracle Access Managerアクセス管理ガイド』の説明に従って、ポリシー・ドメインを作成します。
次のようにポリシー・ドメインを作成し、一般情報を指定します。
ポリシー・マネージャから、左側のペインで「ポリシー・ドメインの作成」をクリックします。
一般: このタブをクリックして、ポリシー・ドメインについての一般的な情報（名前やオプションの説明）を入力します。
リソース: 「リソース」タブをクリックしてから「追加」をクリックし、「リソース・タイプ」（前述の手順1を参照）、「ホスト識別子」、「URL接頭辞」を選択し、説明を入力して「保存」をクリックします。
URL接頭辞は、ポリシー・ドメイン内のリソースの先頭を示します。URL接頭辞では、ポリシー・ドメイン（最初のリソース）の先頭がどこで始まるかを定義します。URL接頭辞は、アプリケーション・サーバーやWebサーバーのいずれかのファイルシステムのディレクトリにマップされます。
認可ルール: 一般情報、時間的な条件、アクションおよびアクセス（許可または拒否）の条件を指定します。これらのフィールドはオプションで、指定しない場合はデフォルト値を使用します。ただし、ほとんどの場合、ポリシー・ドメインではアクセス（許可または拒否）の条件を指定します。
「認可ルール」タブをクリックしてから「追加」をクリックし、ルールの一般情報を入力して「保存」をクリックします。
タイミング条件: 「タイミング条件」をクリックします。何も定義しない場合、そのルールが常時有効になります。必要に応じてタイミング条件を追加します。
アクション: 「アクション」をクリックし、ユーザーが保護されたリソースへのアクセスをリクエストした場合のレスポンスとして、認可の成否を返す際に発生する一連のアクション・セットを指定します。
アクセスの許可: 条件を何も指定しない場合、誰もアクセスを許可されません。「アクセスの許可」をクリックし、適切な情報を入力します。
アクセスの拒否: 条件を何も指定しない場合、誰もアクセスを拒否されません。「アクセスの拒否」をクリックし、適切な情報を追加します。
ルールの有効化: このルールを有効にしない場合、認可条件式を作成する場合にこのルールを利用できなくなります。「認可ルール」タブをクリックし、ルールの横のボックスをクリックして「有効化」をクリックします。
デフォルト・ルール: ここで認証ルールおよび認可条件式を追加します。
認証ルール: 「デフォルト・ルール」タブをクリックし、このルールの「一般」タブおよび「アクション」タブを表示します。「追加」をクリックし、ユーザーのアイデンティティの検証方法を指定する認証スキーム（前述のタスク3を参照）などのルールの詳細を入力します。「アクション」をクリックしてから「追加」をクリックし、認証失敗、認証成功またはその両方のオプションのアクションを指定します。
|
注意: 1つのポリシー・ドメインには、認可条件式が1つ（1つのみ）含まれている必要があります。認可条件式は、定義済の利用可能な認可ルールから作成されます。カスタム認可スキームが定義されている場合（手順1d）、ポリシー・ドメインの「認可ルール」（手順2d）に表示されるリストからそのスキームを選択できます。または、リストにあるOracle認証スキームを選択することもできます。 |
認可条件式: 「認可条件式」タブをクリックしてから「追加」をクリックし、条件式を作成します。
重複アクション: ポリシーが何も定義されていない場合、重複アクション・ヘッダーに対するアクセス・システム・レベルのデフォルトのポリシーが使用されます。「重複アクション」サブタブで、これを変更できます。
アクション: このサブタブから、認可の成否、または未確定な結果を返す際の一連のアクション・セットを指定できます。
監査ルール: 「マスター監査ルール」が定義されていない場合、アクセス・システム管理者に連絡するように指示されます。
ポリシー: ポリシーを設定する前に、保護するURLに必要なアクセス管理のレベルを決定します。作成する各ポリシーに対して、固有の認証ルール、認可条件式および監査ルールを割り当てることができます。ルールを定義しない場合は、ポリシー・ドメインのデフォルトのルール（タスク2eで定義）が適用されます。
「ポリシー」タブをクリックし、このポリシーの一般情報を入力します。
ポリシーの名前をクリックし、このポリシーのサブタブを表示します。
認証ルール: このサブタブをクリックしてから「追加」をクリック（または「デフォルトの表示」をクリック）します。このポリシーの認証ルールを作成（または編集）します。ポリシー・ドメインの場合と同様に行います。
認可条件式: このサブタブをクリックしてから「追加」をクリック（または「デフォルトの表示」をクリック）します。このポリシーの認可条件式を作成（または編集）します。ポリシー・ドメインの場合と同様に行います。
監査ルール: このサブタブをクリックします。監査ルールをこのポリシーに追加する際、「マスター監査ルール」が定義されていない場合は、アクセス・システム管理者に連絡するように指示されます。
委任管理: 特定のドメインへのアクセス権限を持つ委任アクセス管理者（またはマスター・アクセス管理者）のみが、ポリシー・ドメインを表示できます。「委任管理」タブをクリックします。
準備ができたら、ポリシー・ドメインを有効にします。
『Oracle Access Managerアクセス管理ガイド』の説明に従って、ポリシー・ドメインをテストします。
Oracle Access Managerのポリシー・ドメイン、認証スキームおよびアクセス・ポリシーの設定の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
ここでは統合のテストについて説明します。
次の機能を実行して、POSTデータ復元の構成をテストできます。
POSTデータ復元では、認証イベントによりPOSTリクエストが中断された場合に、WebGateでポストされたデータが消失しないようにする機能を提供します。この機能をテストするには、ユーザーがポストするデータを入力できるフィールド（たとえば、ユーザー認証用のユーザー名やパスワードのフィールド）を含む簡単なフォーム・タイプのリソースを使用できます。データのポストに使用するフォーム・リソースによって、ポスト・データを収集するターゲット・リソース・ページにデータが送信されます。このリソースを保護する認証スキームでは、フォーム・チャレンジ・メソッドを使用する必要があります。
このテストでは、フォーム・リソースにアクセスして、有効な資格証明を入力します。フォームが表示されたら、表示されたテキスト・フィールドにポストするデータを入力し、アイドル・セッション・タイムアウトの設定時間を超えるまで待機して、再認証を強制します。これにより、再認証イベント後にポストされたデータを復元できるかどうかをテストします。セッション・タイムアウト後に、データを送信し、ユーザー資格情報を要求されたら入力します。再認証が行われます。再認証後、ポストしたデータがターゲット・リソース・ページで復元されれば、POSTデータの復元を確認できます。
ブラウザのウィンドウで、Oracle Access Managerで保護されているリソースにアクセスする際のWeb Cacheホストおよびポートを入力します。
適切なユーザー資格情報を使用してログインし、Oracle Access Managerで保護されているリソースを取得します。
テキスト・フィールドに値を入力します（ユーザー名および部署名など）。次に例を示します。
ユーザー名および部署名
ここで、「ユーザー名」および「部署名」は、ユーザー認証に使用するものではなく、ユーザーによってポストされる可能性のあるデータを示します。
アイドル状態のままにします。アイドル・セッション・タイムアウトの設定時間を超えるまで何も変更しないでください。
手順4では、ユーザーがポストするデータを入力するテキスト・フィールドを含むページに進みます。アイドル・セッション・タイムアウトの設定時間を超えるまでアイドル状態のままにし、再認証を強制します。この間、このページでは操作や変更をしないでください。これにより、アイドル・セッション・タイムが失効します。
残りのフィールドに入力し、必要に応じて「送信」または「次へ」をクリックします。
残りのフィールドへのデータ入力はオプションです。ここで実行する必要があるアクションは、アイドル・セッション・タイムアウト発生後にポストするデータの送信です。
アイドル・セッション・タイムアウト発生後、再認証するよう求められます。
要求されたらユーザー資格情報を入力し、Oracle Access Managerで保護されたリソースを取得します。
再認証に成功した後、リクエストしたページに移されます。Web Cacheからポストされたデータがそのページに移入されます。
Oracle Access Managerを使用して次の機能を実行し、Cookieを使用しないセッション・サポートをテストできます。
このタスクを完了するには、webcache.xmlファイルにXMLタグCOOKIECACHEが追加されている必要があります。詳細は、「Cookieを使用しないセッション・サポートのためのOracleAS Web Cache構成」を参照してください。
ブラウザのウィンドウで、Oracle Access Managerで保護されているリソースにアクセスする際のWeb Cacheホストおよびポートを入力します。
適切なユーザー資格情報を使用してログインし、Oracle Access Managerで保護されているリソースを取得します。
そのリソースへのアクセスが許可されます。
HTTPヘッダーなどのツールを使用してWebブラウザで受信されるヘッダーを確認します。
Oracleでは、Webブラウザで受信されるヘッダーを確認するツールは提供していません。
OracleAS Web Cacheで生成された公開cookie（ORA_WX_SESSION）がWebブラウザによる受信時に表示されます。Oracle Access ManagerのObSSOCookieは、Webブラウザには送信されません。
Web Cacheサーバーを再起動します。
Oracle Access Manager監査機能では、ポリシー設定やプロファイル設定、システム・イベントおよび使用パターンに関連するデータを収集し、表示します。すべての動的監査レポートおよび一部の静的監査レポートを、ディスク・ファイルやリレーショナル・データベースのどちらかまたはその両方に記録できます。一部の静的レポートは、グラフィカル・ユーザー・インタフェースを介して一定のフォームで表示することもできます。
監査の他にも、Oracle Access Managerコンポーネント・インスタンスでは、インスタンスのプロセスおよび状態についての情報をログ・ファイルに記録できます。ログは、様々なレベルの粒度で情報を提供するように設定できます。たとえば、エラーの記録、エラーおよび状態情報の記録、またはエラーと状態に加えてデバッグ・トレース・レベルのその他の情報を記録することもできます。また、ログから機密情報を削除することもできます。
Oracle Access Managerを使用した監査およびロギングの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
Oracle Enterprise Manager 10g Application Server ControlコンソールまたはOracleAS Web Cache Managerを使用すると、最もポピュラーなリクエストのリストおよびキャッシュ・コンテンツのリストを表示できます。
OracleAS Web Cacheのイベントおよびエラーは、イベント・ログに格納されます。イベント・ログは、どのオブジェクトがキャッシュに入れられたかを判断するのに役立ちます。また、リスニング・ポートの競合や、起動時および停止時の問題も特定できます。OracleAS Web Cacheは、OracleAS Web Cacheに送信されるHTTPリクエストの情報が含まれるアクセス・ログを生成します。
Oracle Web Cacheで診断ツールを使用する方法の詳細は、『Oracle Application Server Web Cache管理者ガイド』を参照してください。
この項では、様々な問題のトラブルシューティングに役立つヒントを示します。
問題
ポスト・データ復元を有効にすると、最初のセッションにログインしたユーザーとは別のユーザーがログインする際に、再認証が行われます。ターゲット・リソースは、保護されたリソースの認可セットに基づいてエンドユーザーが利用できるようになります。アクセスが許可されていないユーザーの資格情報でアクセスしようとすると、最大ログイン試行回数の制限を超えるまでログイン・フォームが表示されます。
原因
これは想定されている動作です。再認証イベントでは、ユーザーは同一の資格証明を使用するか、または他の既知のユーザー資格証明を使用してログインできます。ただし、後者の場合は、ログイン・フォームが2回表示されます。
解決方法
ユーザーは、他のユーザーがログインを試行した後で同じブラウザを使用してログインする場合、認証を2回行う必要があります。
問題
ポスト・データ復元およびCookieを使用しないサポートのためにWeb CacheがOracle Access Managerの前で構成されている場合は常に、別個のWebGateへの認証チャレンジ・リダイレクトを有効化しても、そのWebGateのホスト・ポートが認証スキームの定義に直接記述されていると、正常に機能しません。リダイレクトは実行されますが、機能が動作しない場合があります。SSLトランザクションの場合、セッション・リストアの問題が発生することがあります。
原因
認証を行うWebGateのホスト・ポートがOracle Access Managerの認証スキームの定義に直接記述されている場合、認証を行うWebGateへのリダイレクトで認証時にWeb Cacheが認識されません。
解決方法
Oracle Access Managerで認証用に別個のWebGateを使用してチャレンジ・リダイレクトを有効にする場合は、認証を行うWebGateホスト・ポートと対応するWeb Cacheサイトを構成する必要があります。
リダイレクトまたはセッション・リストアの問題を解決する手順
Web Cacheサイトが認証を行うWebGateと対応するように定義されていることを確認します。
Web Cacheサイトのホスト・ポートが指定のバックエンドWebGateへ認証をリダイレクトするように、認証スキームのチャレンジ・リダイレクト・フィールドに記述されていることを確認します。
問題
httpsセッションがhttpセッションに変換され、アクセス不可能なサイトへ接続されます。この問題は主に、フォルダ構造ベースのリソースにアクセスする際に発生します。
原因
OracleAS Web CacheサイトとOracle Access Managerオリジナル・サーバー間でのCookieを使用しないセッションでは、SSL通信を必要とします。このため、SSLが有効でないOracle Access Managerオリジナル・サーバーではエラーが発生します。
解決方法
Oracle HTTP Server（OHSまたはOHS2）のhttpd.confファイルに情報を追加して、非SSLでホストされるOracle Access Managerを、SSLが有効なOracleAS Web CacheサイトおよびCookieを使用しないセッションで構成する必要があります。
|
注意: この方法は、他のWebサーバーのタイプではまだサポートされていません。 |
非SSLでホストされるOracle Access ManagerとSSLが有効なOracleAS Web CacheサイトでCookieを使用しないセッションをサポートする手順
テキスト・エディタでOHSファイルまたはOHS2のhttp.confファイルを探して開きます。次に例を示します。
OHS_install_dir/conf/httpd.conf
OHS: 次の情報をhttpd.confファイルの最後に追加します。
LoadModule certheaders_module libexec/mod_certheaders.so AddCertHeader HTTPS SimulateHttps On
OHS2:
LoadModule certheaders_module modules/mod_certheaders.so AddCertHeader HTTPS SimulateHttps On
ファイルを保存します。
問題
Web CacheサイトのURLを使用して、Oracle Access Managerで保護されたHTMLファイルにアクセスすると、Web CacheのHTMLキャッシング・ルールが有効化されている場合、セッションがコピーされることがあります。このため、HTMLファイルへの最初のアクセス時にのみ認証が行われます。次のアクセスでは、ユーザーは認証を行わずにファイルを利用できることがあります。また、HTMLキャッシング・ルールにより、最初のアクセスの成功時に作成されたCookieが同じHTMLファイルへの追加のアクセスに対して利用されることがあります。
原因
Web CacheのHTMLキャッシング・ルールにより、後続のアクセスを迅速にするためHTMLファイル全体とそのコンテンツがキャッシュされます。
解決方法
Web CacheでHTMLキャッシング・ルールが有効化されている場合、保護されたHTMLファイルに対するセッションがコピーされることがあります。これにより、認証を行わずにターゲットHTMLファイルが利用可能になる場合があります。
Web Cache管理コンソールからHTMLキャッシング・ルールを無効にします。
