| Oracle® Fusion Middleware Oracle Adaptive Access Manager開発者ガイド 11gリリース2(11.1.2) B71697-01 |
|
 前 |
 次 |
Oracle Adaptive Access Manager Universal Installation Option(UIO)のリバース・プロキシ・デプロイメント・オプションでは、アプリケーション・コードを変更しなくても、Webアプリケーションにログイン・リスク・ベースのマルチファクタ認証を提供できます。
プロキシの主な機能は、ユーザー・トラフィックをアプリケーションのログイン・フローからOracle Adaptive Access Managerのログイン・フローへリダイレクトすることです。
UIOプロキシは、Apache Webサーバーに使用できます。この章では、Apache用のAdaptive Access ManagerプロキシをUIO Apacheプロキシと呼んでいます。
この章では、UIO Apacheプロキシの実装および使用について説明します。
対象読者は、UIOプロキシを構成してWebアプリケーションにマルチファクタ認証を追加するインテグレータです。このドキュメントの内容を理解するには、HTTPリクエスト/レスポンスのパラダイムを理解する必要があります。
内容は次のとおりです。
OAAMサーバーの構成方法と、UIOプロキシ・デプロイメント固有のクライアント向けマルチファクタ認証のWebアプリケーションの詳細は、第8章「OAAM Webアプリケーション・ページのカスタマイズ」を参照してください。
この章の概要の項の内容は、次のとおりです。
この項では、参考用に重要な用語が定義されています。
Universal Installation Option
Universal Installation Optionは、保護されたWebアプリケーションのコード変更を必要としないOracle Adaptive Access Managerの統合方針です。Universal Installation Optionでは、保護されたWebアプリケーションの前にUIOプロキシを配置します。
プロキシ
プロキシは、リクエストを他のサーバーに転送することでクライアントのリクエストに対応するサーバーです。この章では、Webプロトコル(主にHTTP)を処理するWebプロキシについて説明します。
転送プロキシ
転送プロキシは、クライアントとオリジナル・サーバーとの間に位置する中間サーバーです。オリジナル・サーバーからコンテンツを取得するために、クライアントはオリジナル・サーバーをターゲットに指定するリクエストをプロキシに送信し、プロキシはオリジナル・サーバーのコンテンツをリクエストして、それをクライアントに返します。クライアントは、転送プロキシを使用して他のサイトにアクセスできるように特別に構成されている必要があります。
リバース・プロキシ
リバース・プロキシは、クライアントには通常のWebサーバーのように表示されます。クライアント側での特別な構成は必要ありません。クライアントは、リバース・プロキシのネームスペース内のコンテンツに対して、通常のリクエストを作成します。リバース・プロキシは、それらのリクエストの送信先を決定し、リバース・プロキシ自体が送信元であるかのようにコンテンツを返します。
OAAMサーバー
OAAMサーバーは、Oracle Adaptive Access ManagerのWebアプリケーション・コンポーネントです。UIOプロキシは、UIOプロキシのXML構成の定義に従って、トラッキングおよび認証のためにクライアント・ブラウザをOAAMサーバーにリダイレクトします。
次の図では、標準的なUIOプロキシのデプロイメントを示しています。
図6-1は、UIOプロキシをデプロイしてマルチファクタ認証を提供する前のWebアプリケーションを示しています。
図6-2は、UIOプロキシのデプロイ後に追加された様々なコンポーネントを示しています。
Apache HTTPサーバーを実行しているローカル・マシン。サンプル・アプリケーションは、会社のイントラネットのアプリケーション・サーバーで実行中です。OAAMのデプロイメントは、会社のイントラネットのOAAMサーバーで実行中です。
UIOプロキシは、クライアント(ブラウザ)とサーバー(Webアプリケーション)間のHTTPトラフィックをインターセプトし、適切なアクション(トラフィックのOAAMサーバーへのリダイレクトなど)を実行して、マルチファクタ認証と認可を提供します。次に、OAAMサーバーはOAAM管理と通信してリスクを評価し、適切なアクション(ログインの許可、ユーザーへのチャレンジ、ユーザーのブロックなど)を取ります。
Apache HTTPサーバーの詳細は、次のWebサイトで、Apache HTTPサーバー、バージョン2.2のドキュメントを参照してください。
UIO Apacheプロキシをインストールするには、UIO Apacheプロキシのインストール先である新規のApache Hypertext Transfer Protocol Daemon(httpd)をインストールする必要があります。このApache httpdでは、mod_proxyを使用します。これは、リバース・プロキシ(保護するバックエンド・アプリケーションのかわりのプロキシ)にプロキシ/ゲートウェイ/キャッシュを実装するモジュールです。
インストールの項では、WindowsおよびLinuxプラットフォーム向けのUIO Apacheプロキシのインストール方法について説明しています。
インストール手順
インストール手順は、次のとおりです。
Apache httpdの要件が満たされていることを確認する。
第6.2.2項「Apache httpdのダウンロードまたはビルド」を参照してください。
UIOプロキシのdllsおよびサポートされているdllsをApache固有のディレクトリにコピーする。
memcacheを構成する(Linuxのみ)。
第6.2.4項「Memcacheの構成(Linuxのみ)」を参照してください。
UIOプロキシをアクティブにするためにhttpd.confを編集する。
第6.2.5項「httpd.confの構成」を参照してください。
この項では、mod_proxy_htmlをオプションでインストールする方法についても説明します。これは、プロキシを使用する際に、外部ユーザーがアクセスできるようにHTMLリンクをリライトする場合に必要です。
アプリケーション構成のXMLファイルを使用してUIOプロキシの設定を変更する。
第6.2.6項「UIO Apacheプロキシの設定の変更」を参照してください。
インストール後の手順は、次のとおりです。
UIO Apacheプロキシ・プロセスの実行ユーザーを新規に作成する(Linuxのみ)。
インストール後
OAAM UIOプロキシのインストール手順を実行した後、次のApache構成の設定値が設定されます。
UIOモジュール
Apacheリバース・プロキシ・モジュール
仮想ホスト・エントリ
OAAMのロケーション・マッピング、および個別にProxyPassおよびProxyPassReverseターゲットを指定したアプリケーション
SSL証明書の場所(必要な場合)
参考までに、次の各表にUIOプロキシ・ファイルの概要を示します。
|
注意: UIO Apacheプロキシのバイナリは、Windows向けとLinux向けでは異なります。UIOプロキシはC/C++で作成されているため、(Javaとは異なり)同じバイナリは別のプラットフォームでは動作しません。 |
ファイルは、$ORACLE_HOME/oaam/oaam_proxyplatform_specific_fileに格納されています。
Windows UIOプロキシのバイナリ・ファイルを表6-1に示しします。
表6-1 Windowsバイナリ・ファイル
| 名前 | 説明 |
|---|---|
|
mod_uio.so |
UIO Apacheプロキシ・モジュール |
|
log4cxx.dll |
Apache Log4cxxバイナリ |
|
libxml2.dll |
XML/HTMLパーサー |
|
apr_memcache.dll |
APR Memcacheクライアント・ライブラリ |
Windows UIOプロキシのデータファイルを表6-2に示します。
Apache httpdをダウンロードまたはビルドするためのインストール前手順は、プラットフォーム(WindowsまたはLinux)と、一定の要件が満たされているかどうかによって異なります。
Apache Webサイトから、Windows向けの最新のApache httpd(2.2.8)ビルドをダウンロードします。次の要件が満たされていることを確認します。
Apache httpd(2.2.8)ビルドがバージョン2.2.8である。
mod_proxyのサポートが有効になっている(標準インストールにmod_proxyが含まれている)。
mod_sslのサポートが有効になっている。
WindowsおよびLinuxの両方のプラットフォームで、UIO Apacheプロキシとサポート・ファイルをApache固有のディレクトリにコピーします。
表6-5には、次の情報が含まれます。
インストール後にUIO Apacheプロキシ・ファイルをコピーする必要のあるディレクトリ
UIO Apacheプロキシのライブラリ・ファイルと構成ファイルのツリー構造(これらのファイルをC:\Apache2.2にインストールした場合)
UIO Apacheプロキシのバイナリ・ファイルの格納先ディレクトリを表6-5に示します。
表6-5 Windows UIOプロキシのバイナリ・ファイルのディレクトリ
| ディレクトリ | ファイルの説明 |
|---|---|
|
C:\Apache2.2\modules\mod_uio.so |
UIO Apacheプロキシ・モジュール |
|
C:\Apache2.2\bin\log4cxx.dll |
Apache Log4cxxバイナリ |
|
C:\Apache2.2\bin\libxml2.dll |
XML/HTMLパーサー |
|
C:\Apache2.2\bin\apr_memcache.dll |
APR Memcacheライブラリ。 |
表6-6に示すディレクトリに、データファイルを移動してください。
表6-6 Windows UIOプロキシのデータファイルのディレクトリ
| ディレクトリ | ファイルの説明 |
|---|---|
|
C:\OAAMUIO\UIO_Settings.xml |
UIO Apacheプロキシ設定のXMLファイル |
|
C:\OAAMUIO\UIO_log4j.xml |
UIO ApacheプロキシのLog4j(log4cxx)構成XMLファイル |
|
C:\OAAMUIO\TestConfig.xml |
UIO Apacheプロキシのアプリケーション構成ファイル(任意の数) |
|
C:\OAAMUIO\UIO_Settings.rng |
UIO_Settings.xmlに対するNG構文を解除します |
|
C:\OAAMUIO\UIO_Config.rng |
アプリケーション構成XMLファイルに対するNG構文を解除します |
|
C:\OAAMUIO\logs\uio.log |
UIO Apacheプロキシのログ |
様々な構成ファイルの場所を変更するには、第6.2.5項「httpd.confの構成」を参照してください。
Apache httpdのインストール後、次の手順を実行します。
UIO Apacheプロキシのバイナリ・ファイルを、表6-7に示すディレクトリにコピーします(Apache httpdが/usr/local/apache2にインストールされているものとします)。
次に、ライブラリへのソフト・リンクを次のように作成します。
cd /usr/local/apache2/lib ln -s liblog4cxx.so.10.0.0 liblog4cxx.so.10 ln -s libxml2.so.2.6.32 libxml2.so.2 ln -s libapr_memcache.so.0.0.1 libapr_memcache.so.0
バイナリ・ファイルに実行可能な権限があることを確認します。
Apache httpdは通常、rootとして実行されるため、ポート80でリスニングする親プロセスが作成されます。また、httpd.confのUserディレクティブで指定したユーザーとして実行するハンドラ・プロセスも作成されます。
そのため、UIO Apacheプロキシのチェックポイント・ユーザーであるoaamuioというユーザーを作成してください。このユーザーは、プロキシの構成ファイルとログ・ファイルにアクセスできます。このユーザーのみがログ・ファイルにアクセスできることを確認してください。/home/oaamuioがこのユーザーのホーム・ディレクトリであると想定すると、ディレクトリ構造は表6-8のようになります。(UIO Apacheプロキシのデータファイルは、表6-8に示すディレクトリ構造に従う必要があります。)
表6-8 Linux UIOプロキシのデータファイルのディレクトリ
| ディレクトリ | 説明 |
|---|---|
|
/home/oaamuio/uio/UIO_Settings.xml |
UIO Apacheプロキシ設定のXMLファイル |
|
/home/oaamuio/uio/UIO_log4j.xml |
UIO ApacheプロキシのLog4j(log4cxx)構成XMLファイル |
|
/home/oaamuio/uio/TestConfig.xml |
UIO Apacheプロキシのアプリケーション構成ファイル(任意の数) |
|
/home/oaamuio/uio/UIO_Settings.rng |
UIO_Settings.xmlに対するNG構文を解除します |
|
/home/oaamuio/uio/UIO_Config.rng |
アプリケーション構成XMLファイルに対するNG構文を解除します |
|
/home/oaamuio/uio/logs/uio.log |
UIO Apacheプロキシのログ |
様々な構成ファイルの場所を変更するには、第6.2.5項「httpd.confの構成」を参照してください。
httpdの実行時ユーザーは、これらのファイルすべてにアクセスできる適切な権限を持っている必要があります。
これは、UIO ApacheプロキシのLinuxデプロイメントに必要な場合があるオプション構成です。
UIO Apacheプロキシは、ユーザーのセッション・レベル変数など、ユーザー用にローカル状態を維持するセッションを保持しています。
Windowsでは、実行中のApache httpdサーバーに対して常に1つのプロセスが存在するため、このセッション情報はそのプロセスにとってローカルなものになります。
Linuxでは、Apache httpdサーバーの複数のプロセスを実行できます。つまり、セッション情報は特定のプロセスに対してローカルに保持できず、一元管理する必要があります。この場合、memcachedを使用してセッション情報が保持されます。
次の説明では、memcachedを使用してUIO Apacheプロキシのセッション情報を保持するタイミングを特定しています。
Apache httpdにはいくつかのマルチプロセス・モジュール(MPM)が付属しています。これらのモジュールは、マシン上のネットワーク・ポートへのバインド、リクエストの受入れ、およびリクエストを処理するための子のディスパッチを行います。Linuxの場合: httpdは2つの異なるMPMで実行できます。つまり、prefork MPM(シングル・スレッド)またはworker MPM(マルチスレッド)を使用するhttpdが実行可能です。MPMはhttpdにビルドされており、ランタイム・オプションではありません。
Prefork MPM用にMemcachedを使用するようにUIO Apacheプロキシを構成する
prefork MPMを使用するhttpdでは、各リクエストがシングル・プロセスで処理されるシングル・スレッド・プロセスのプールが保持されます。この場合は、memcachedを使用するようにUIO Apacheプロキシを構成する必要があります。
Worker MPM用にシングル・プロセスを起動するようにApache httpdを構成する
worker MPMを使用するhttpdでは、すべてのプロセスで一度に複数のリクエストを処理できるマルチスレッド・プロセスのプールが保持されます。この場合は、memcachedを使用しないで、シングル・プロセスを起動するようにApache httpdを構成できます。ただし、デフォルト構成では複数のプロセスを起動するため、これを変更しないようにするには、memcachedを使用するようにUIO Apacheプロキシを構成する必要があります。次に、シングル・プロセスを起動するworker MPMの構成に使用できるhttpd.confの例を示します。
# Following forces worker MPM to run 1 process (make sure mod_cgid is # not loaded, otherwise it starts one more httpd process). # Basically ThreadLimit=MinSpareThreads=MaxSpareThreads=MaxClients=ThreadsPerChild # and StartServers=1. Setting MaxRequestsPerChild to 0 ensures that the process is not # bounced. <IfModule mpm_worker_module> ThreadLimit 150 StartServers 1 MinSpareThreads 150 MaxSpareThreads 150 MaxClients 150 ThreadsPerChild 150 MaxRequestsPerChild 0 </IfModule>
Windowsでは、httpd MPMは常に、シングル・プロセスを使用するマルチスレッド・モードになっています。
Linuxでは、(シングル・スレッドまたはマルチスレッドかどうかに関係なく)httpdが複数のプロセスを実行する場合は、UIO Apacheプロキシのセッション・データを共通ストア(データベースまたはキャッシュ)に保持しておき、複数のプロセスがセッション・データにアクセスできるようにする必要があります。UIOプロキシは、memcache(メモリー・ベースの高速キャッシュ)を使用してセッション・データを格納します。
起動時に、UIOプロキシでは、httpdがシングル・プロセスまたはマルチプロセスのどちらで実行されているかが自動検出されます。httpdが複数のプロセスで実行されている場合(つまり、Linuxでpreforkまたはworker MPMを使用している場合)、デフォルトの接続パラメータ(第6.2.6.1項「UIO_Settings.xml」で定義する)を使用してmemcacheデーモンへの接続を試みます。Windowsの場合、デフォルトでは、UIOプロキシはローカル・セッションを使用します。memcacheデーモンへの接続は実行しませんが、memcacheデーモンでセッション・データを保持するように構成できます(第6.2.6.1項「UIO_Settings.xml」で説明しています)。
UIO Apacheプロキシがmemcacheデーモンに接続するシナリオでは、memcacheをインストールします。
UIO Apacheプロキシがmemcacheデーモンに接続するシナリオでは、memcacheのWebサイトの手順に従ってmemcacheをシステムにインストールし、memcacheデーモンを実行した後でApache httpdを実行する必要があります。
次のWebサイトの手順に従って、memcacheをインストールします。
http://www.danga.com/memcached
Linuxディストリビューションのバイナリ・インストールがすでに存在している可能性があります。UIO Apacheプロキシは、memcacheのバージョン1.2.5でテスト済です。
UIO Apacheプロキシをアクティブにするためにhttpd.confファイルを編集します。httpd.confファイルは、Apache HTTPサーバーにより使用されるメインの構成ファイルです。
サンプル・インストールでは、Apache httpdはc:\ProgramFiles\Apache2.2または/usr/local/apache2にインストールされています。
http.confが各自の環境で正しく設定されていることを確認するには、次の手順を実行します。
mod_proxyを有効にするために、次の行が非コメント化されていることを確認します。
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so
次の行をLoadModule行グループの終わりに追加して、UIO Apacheプロキシをアクティブにします。
LoadModule uio_module modules/mod_uio.so
UIO Apacheプロキシの設定値を持っているUIO_Settings.xmlファイルをポイントする行を追加します。
|
注意: これは、 |
Windowsの場合(すべてのパスにフォワードスラッシュを使用します）、
UioProxySettingsFile c:/OAAMUIO/UIO_Settings.xml
Linuxの場合、
UioProxySettingsFile /home/oaamuio/uio/UIO_Settings.xml
mod_proxyのフォワード・プロキシ機能は必要でないため、これを無効にします。
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
oaam_serverのリバース・プロキシでmod_proxy構成を有効にすると、ターゲット・アプリケーションがOAAMによって保護されます。
ProxyPass /oaam_server/ http://<FQDN_oaam_server>:<oaam_server_port>/oaam_server/ ProxyPassReverse /oaam_server/ http://<FQDN_oaam_server>:<oaam_server_port>/oaam_server/ ProxyPass /<target_app>/ http://<FQDN_target_app>:<target_app_port>//<target_appl> ProxyPassReverse /<target_app>/ http://<FQDN_target_app>:<target_app_port>/<target_app>
UserおよびGroupのディレクティブを使用して、httpdのユーザー/グループをoaamuioに設定します。
手順4および5の実際の設定値はインストール固有であり、必要な設定値の例にすぎません。設定の詳細は、Apacheドキュメントに記載されています。
記載した変更を使用し、UIO_Settings.xmlを適切に設定することによって、OAAMサーバー(oaam_server)とターゲット・アプリケーションにアクセスして、フェーズ1シナリオが実行できるようになります。ターゲット・アプリケーションのURLは、次のとおりです。
http://apache-host:apache-port/target_application
この章ではこれまで、SSLを使用しないでプロキシの構成を行ってきました。
SSLの有効化については、Tomcat向けのApache WebサイトおよびApacheドキュメントを参照してください。
UIO Apacheプロキシでは、mod_sslをhttpdに含める必要があります。これによってOpenSSLライブラリがUIO Apacheプロキシにリンクされ、セッションIDを生成するようにUIO Apacheプロキシで正しく構成されます。mod_sslをロードしておくと、SSLを使用しない場合に構成を実行する必要がありません。
mod_proxy_htmlモジュール(オプション)
オプションとして、mod_proxy_html(http://apache.webthing.com/mod_proxy_html/)Apacheモジュールのインストールが必要になる場合があります。このモジュールは、保護されたアプリケーションに、自身に対するハードコード化されたURLリンクを持つWebページが含まれている場合にのみ必要です。アプリケーションに相対URLが含まれる場合、このモジュールは必要ありません。
Webサイトでは、このモジュールの実行サマリーが次のように説明されています。
mod_proxy_htmlは、プロキシを使用する際に、外部ユーザーがアクセスできるようにHTMLリンクをリライトする出力フィルタです。これは、HTTPヘッダーにおけるApacheのProxyPassReverseディレクティブと同じ目的を果たし、リバース・プロキシの重要なコンポーネントです。
たとえば、企業がアプリケーション・サーバー(社内ネットワークからのみ表示可能なappserver.example.comにある)とパブリックWebサーバー(www.example.comにある)を持っている場合、http://www.example.com/appserver/でアプリケーション・サーバーへのゲートウェイを提供する場合があります。アプリケーション・サーバーが自身にリンクするときは、これらのリンクをリライトしてゲートウェイ経由で動作できるようにする必要があります。mod_proxy_htmlは、<a href="http://appserver.example.com/foo/bar.html">foobar</a>を<a href="http://www.example.com/appserver/foo/bar.html">foobar</a>にリライトして、外部からアクセスできるようにします。
後続の例に応じて、UIO Apacheプロキシの設定を変更します。
<UIO_ProxySettings xmlns="http://bharosa.com/">
<!-- Log4jProperties location="/home/oaamuio/uio/UIO_log4j.xml"/ -->
<Log4jProperties location="f:/oaamuio/uio/UIO_log4j.xml"/>
<Memcache ipaddress="127.0.0.1" port="11211" maxconn="10"/>
<GlobalVariable name='one" value="something"/>
<ConfigFile location="/home/oaamuio/uio/TestConfig1.xml" enabled="true"/>
<ConfigFile location="/home/oaamuio/uio/TestConfig2.xml" enabled="false"/>
<ConfigFile location="f:/oaamuio/uio/TestConfig1.xml" enabled="false"/>
<Setting name="GarbageCollectorInterval_ms" value="60000"/>
<Setting name="MaxSessionInactiveInterval_sec" value="1200"/>
<Setting name="CachedConfigExpiry_sec" value="120"/>
<Setting name="SessionIdCookieName_str" value="SessionId"/>
<Setting name="SessionCookie_ExpiryInMinutes" value="0"/> <Setting name="SessionCookie_IsHttpOnly" value="0"/> <Setting name="SessionCookie_IsSecure" value="1"/> <Setting name="Profiling" value="0"/>
<Setting name="IgnoreUrlMappings" value="0"/>
<Setting name="CaptureTraffic" value="0"/>
<!-- Enable AutoLoadConfig for Windows or Single-process Linux.
Do not use for Multiple-process Linux when in production.
-->
<Setting name="AutoLoadConfig" value="1"/>
<!-- Setting name="UseMemcache" value="1"/ -->
</UIO_ProxySettings>
Log4jProperties
UIO Apacheプロキシのロギング構成を定義するlog4j.xmlファイルの場所を設定します。この場所は絶対パスである必要があります。相対パスのServerRootは使用できません。Linuxの場合は、httpdプロセスがディレクトリにアクセス可能であることを確認する必要があります。
httpdをマルチプロセス・モードで使用する場合は、FileAppenderを使用しないでください。かわりにSocketAppenderを使用して、別のプロセスのログを記録します。log4jの場所の設定については、log4jドキュメントを参照してください。Log4jは、Javaで作成されたロギング・フレームワーク(API)です。
GlobalVariable
GlobalVariableは、アプリケーション構成で使用されるグローバル変数です。このような名前と値のペアをいくつでも設定できます。
ConfigFile
ConfigFileは、アプリケーション構成への絶対パスです。このような構成をいくつでも設定できます。Linuxでは、httpdプロセスにこれらのファイルへのアクセス権が与えられていることを確認する必要があります。アプリケーションの構成の詳細は、第6.5項「UIOプロキシの構成」を参照してください。
Memcache
Memcacheには、memcacheサーバーのIPアドレスとポートが割り当てられています。複数のmemcacheサーバーを実行している場合は、複数のMemcache要素を設定ファイルに含めることができます。1つのローカルmemcacheを実行している場合は、この要素を含める必要はありません。デフォルトでは、UIO Apacheプロキシは、IPアドレス127.0.0.1およびポート11211でmemcacheに接続しようとします。
設定
これらは、UIO Apacheプロキシの動作を制御するフラグです。各種設定を表6-9に示します。
表6-9 OAAM UIOプロキシの設定
| フラグ | 説明 |
|---|---|
|
MaxSessionInactiveInterval_sec |
UIO Apacheプロキシは、そのプロキシを経由するユーザーごとのセッションを保持します。この設定では、ユーザーが非アクティブになった後でこのセッションの有効期間が設定されます。これは、秒単位で設定されます(デフォルトは30分)。 例: |
|
GarbageCollectorInterval_ms |
実行中セッションの有効期間スレッドの間隔(デフォルト=5分) 例: |
|
FileWatcherInterval_ms |
設定または構成ファイルが変更されたかどうかを確認する間隔(デフォルト=1分) 例: (プロキシが即時に構成を更新する場合でも、構成XMLファイルの変更後にはhttpdサーバーを再起動することをお薦めします。) |
|
SessionIdCookieName_str |
UIO Apacheプロキシでセッションの保持に使用されるCookieの名前(デフォルト= OAAM_UIOProxy_SessionId) 例: |
|
SessionCookie_DomainLevelCount |
UIO ApacheプロキシのセッションCookieのドメイン・レベル。その他のCookieには影響しません。 例: |
|
SessionCookie_ExpiryInMinutes |
この設定値は、UIO ApacheプロキシのセッションCookieの |
|
SessionCookie_IsHttpOnly |
設定値が1の場合、UIO ApacheプロキシのセッションCookieは サポートされるブラウザでは、 |
|
SessionCookie_IsSecure |
設定値が1の場合、UIO ApacheプロキシのセッションCookieはSet-Cookieヘッダーでセキュアとしてマークされます。その他のCookieには影響しません。デフォルトでは、Cookieはセキュアとしてマークされません。 セキュアなCookieは、ブラウザがHTTPSを通してサーバーにアクセスする場合にのみ使用されます。これによって、クライアントからサーバーへの送信時にCookieは常に暗号化され、傍受によるCookie盗難にさらされるリスクが低くなります。 |
|
IgnoreUrlMappings |
アプリケーション構成XMLファイルを無視します。プロキシは、フロースルー・プロキシとして動作します。 例: 値1ではプロキシがフロースルーとして動作するように設定され、値0では構成XMLインターセプタが有効になります。 |
|
CaptureTraffic |
HTTPトラフィック(ログ・ファイルのヘッダーとコンテンツ)を取得します。このモードは、デバッグを目的としています。これはヘッダーとコンテンツをそのまま取得し、カスタマの個人データを含めることもできます。このモードの使用には注意を要します。これはデバッグ/テスト専用です。 例: |
|
MaxReqBodyBytes |
プロキシで処理可能な最大リクエスト・ボディ。この値を超えるリクエスト・ボディは切り捨てられます。これは、サイズの大きなファイルをアップロードするPOSTがアプリケーションに含まれている場合に必要です。 例: |
|
UseMemcache |
httpdがシングル・プロセス・モードで実行中であっても、memcacheを強制的に使用します。マルチプロセス・モードで実行中の場合は、何の影響もありません。起動時に適用されます。変更を適用する際には、httpdを再起動する必要があります。 例: |
|
CachedConfigExpiry_sec |
複数のconfig XML構成がメモリーにロードされた場合、メモリー内の未使用のconfig XMLデータの有効期間。これは、変更したconfig XMLファイルが自動的にロードされると発生します。(デフォルト= 60分)。 例: |
|
AutoLoadConfig |
ユーザーがconfig XMLファイルを変更したときの自動ロードを有効にするには、1に設定します。0に設定すると、この機能はオフになります。httpdのシングル・プロセス・モードを使用する際には、この機能を有効にできます。本番用のhttpdのマルチプロセス・モードに対してこの機能を有効にしないでください。個々のプロセスで異なるバージョンのconfig XMLファイルを使用している可能性があるためです。 例: |
|
設定名 |
インターセプション・フェーズに従って各種操作の内部プロファイリングを有効にし、それをログにマイクロ秒単位で出力します。パフォーマンスに影響することがあるため、これは、本番以外の環境でデバッグおよびプロファイリングする場合にのみ必要です。ログは、 |
実際のlog4jのフォーマット詳細は、log4jドキュメントを参照してください。Apache::log4cxxはC++を実装したlog4jフレームワークであり、XMLファイル・フォーマットはlog4cxxとlog4jに共通しています。
使用可能なUIO ApacheプロキシのLog4jロガーを表6-10に示します。
表6-10 UIO ApacheプロキシのLog4jロガー
| ロガー | 説明 |
|---|---|
|
config.reader |
このロガーは、UIO_Config XMLファイルをロードする関連クラスが使用します。 |
|
settings.reader |
このロガーは、UIO_Settings XMLファイルをロードするクラスが使用します。 |
|
config.datastore |
このロガーは、UIO_Config XMLファイルをロードする関連クラスが使用します。 |
|
config |
このロガーは、UIO_Config XMLファイルをロードする関連クラスが使用します。 |
|
config.reader.populator |
このロガーは、UIO_Config XMLファイルをロードする関連クラスが使用します。 |
|
condition |
このロガーは、UIO_Config.xmlに定義されているすべての条件が使用します。 |
|
filter |
このロガーは、UIO_Config.xmlで定義されているすべてのフィルタが使用します。 |
|
action |
このロガーは、UIO_Config.xmlで定義されているすべてのアクションが使用します。 |
|
interceptor |
このロガーは、UIO_Config.xmlで定義されているすべてのアクションが使用します。 |
|
requestcontext |
HTTPリクエスト処理は、このロガーを使用するクラスによって実行されます。 |
|
プロキシ |
HTTPリクエスト処理は、このロガーを使用するクラスによって実行されます。 |
|
htmlpage |
HTMLページ関連処理は、このロガーを使用するクラスによって実行されます。 |
|
httpreqimpl |
HTTPリクエスト処理は、このロガーを使用するクラスによって実行されます。 |
|
container |
HTTPリクエスト処理は、このロガーを使用するクラスによって実行されます。 |
|
sessions |
このロガーは、UIOプロキシのセッション管理関連クラスが使用します。 |
|
http |
CaptureTrafficの設定がオンになっているときにすべてのHTTPトラフィックのログに使用されるロガー。 |
|
distsessions |
このロガーは、UIOプロキシのセッション管理関連クラスが使用します。 |
|
注意: ロガー・ドキュメントはログを詳述したもので、デプロイメント・エンジニアがログをよりよく理解できるように用意されています。通常、デバッグ・シナリオの場合はログ・レベルを |
ルールとユーザー・グループの設定の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』を参照してください。
UIOプロキシのポリシーを設定するには、そのまま使用できるポリシーをインポートします。ポリシーのインポートの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』を参照してください。
プロキシは、クライアント・ブラウザとWebアプリケーション間のすべてのHTTPトラフィックをインターセプトし、構成ファイルに指定されたアクションを実行します。UIO Apacheプロキシは、プロキシ・ディストリビューションのUIO_Config.rngファイルにあるXMLのNG定義解除を使用します。
次の各項では、プロキシ構成ファイルの各種要素について説明します。
インターセプタは、プロキシ構成で最も重要な要素です。プロキシ構成ファイルのオーサリングでは、主にインターセプタの定義が行われます。
インターセプタには、リクエスト・インターセプタとレスポンス・インターセプタという2つのタイプがあります。名前が示すように、リクエスト・インターセプタはプロキシがクライアント・ブラウザからHTTPリクエストを受信するときに使用され、レスポンス・インターセプタはプロキシがサーバー(Webアプリケーション・サーバーまたはOAAMサーバーなど)からHTTPレスポンスを受信するときに使用されます。
インターセプタには4つのコンポーネントがあり、それらはすべてオプションです。
URLリスト: インターセプタのURLリストに現在のリクエストURLが含まれているか、URLリストが空の場合、インターセプタが評価されます。URLは完全に一致する必要があります。正規表現はサポートされていません。リクエスト・インターセプタの場合、これは、たとえばクライアントからサーバーへの送信途上で、HTTPリクエストのリクエスト部分でリクエスト・インターセプタが実行されるURLのセットです。 レスポンス・インターセプタの場合、HTTPリクエストのURLです。レスポンス・インターセプタは、たとえばサーバーからクライアントへのレスポンスの取得時に、HTTPリクエストのレスポンス部分で実行されます。URLに問合せパラメータが含まれている場合は、そのURLをリストに入れないでください。条件を使用して問合せパラメータを確認できます。
条件リスト: 条件はリクエスト/レスポンスのコンテンツを調べることができます。たとえば、HTTPヘッダー/パラメータ/Cookieなどの有無を確認したり、ヘッダー/パラメータ/Cookieに特定の値があるかどうかをテストすることができます。インターセプタに定義されているフィルタとアクションは、指定された条件がすべて満たされているか、条件が指定されていない場合のみ実行されます。
フィルタ・リスト: フィルタは、リクエスト/レスポンスのコンテンツを変更したり、プロキシ内の状態情報を変更する可能性のあるアクションを実行します。たとえば、フィルタでHTTPヘッダーを追加/削除したり、HTTPヘッダー/パラメータ/Cookieの値をプロキシ変数に保存することができます。
アクション: フィルタの実行後、インターセプタはアクションが指定されている場合に、そのアクションを実行します。アクションとして、次のいずれかが実行できます。
クライアントを別のURLにリダイレクトする。
保存されたレスポンスをクライアントに送信する。
サーバーでHTTP取得を実行する。
サーバーでHTTPポストを実行する。
保存されたリクエストをサーバーに送信する。
表6-11 インターセプタのコンポーネント
| インターセプタ | 属性 | 説明 |
|---|---|---|
|
RequestInterceptor |
id, desc, post-exec-action, isGlobal, enabled |
|
|
ResponseInterceptor |
id, desc, post-exec-action, isGlobal, enabled |
|
条件は、HTTPリクエスト/レスポンス、またはプロキシに保存された状態情報(変数)を調べるためにプロキシで使用します。各条件は、trueまたはfalseに評価されます。条件は、1つの条件がfalseに評価されるか、すべての条件が評価されるまで、構成ファイルでのリスト順で評価されます。表6-12に、インターセプタに定義可能な条件を示します。
表6-12 インターセプタに定義される条件
| 条件名 | 属性 | 説明 |
|---|---|---|
|
HeaderPresent |
enabled, name |
指定されたヘッダーがリクエスト/レスポンスに存在するかどうかを確認します。ヘッダー名の最後にコロン( 例:
|
|
ParamPresent |
enabled, name |
指定されたパラメータがリクエストに存在するかどうかを確認します。 例:
|
|
QueryParamPresent |
enabled, name |
指定された問合せパラメータがURLに存在するかどうかを確認します。 例:
|
|
VariablePresent |
enabled, name |
指定されたプロキシ変数が設定されているかどうかを確認します。 例:
|
|
RequestCookiePresent |
enabled, name |
指定されたCookieがリクエストに存在するかどうかを確認します。 例:
|
|
ResponseCookiePresent |
enabled, name |
指定されたCookieがレスポンスに存在するかどうかを確認します。 例:
|
|
HeaderValue |
enabled, name, value, mode, ignore-case |
指定されたリクエスト/レスポンスのヘッダー値が指定された値と一致するかどうかを確認します。ヘッダー名の最後にコロン( 例:
|
|
ParamValue |
enabled, name, value, mode, ignore-case |
指定されたリクエストのパラメータ値が指定された値と一致するかどうかを確認します。 例:
|
|
QueryParamValue |
enabled, name, value, mode, ignore-case |
指定されたURLの問合せパラメータ値が指定された値と一致するかどうかを確認します。 例:
|
|
VariableValue |
enabled, name, value, mode, ignore-case |
指定されたプロキシ変数の値が指定された値と一致するかどうかを確認します。 例:
|
|
RequestCookieValue |
enabled, name, value, mode, ignore-case |
指定されたリクエストのCookie値が指定された値と一致するかどうかを確認します。 例:
|
|
ResponseCookieValue |
enabled, name, value, mode, ignore-case |
指定されたレスポンスのCookie値が指定された値と一致するかどうかを確認します。 例:
|
|
HttpStatus |
enabled, status |
レスポンスのステータス・コードが指定された値と一致するかどうかを確認します。 例:
|
|
HtmlElementPresent |
enabled, name, attrib-name1, attrib-value1, attrib-name2, attrib-value2, … attrib-name9, attrib-value9, |
指定された条件に一致させるHTML要素の有無を確認します。
例:
|
|
PageContainsText |
enabled, text |
レスポンスに指定されたテキストが含まれているかどうかを確認します。 例:
|
|
NotVariableValue |
enabled, name, value, mode, ignore-case |
指定されたプロキシの変数値が指定された値に一致しないかどうかを確認します。 例:
|
|
And |
enabled |
すべての子条件が 例:
|
|
Or |
enabled |
子条件の1つが 例:
|
|
Not |
enabled |
子条件の結果を逆にします。 例:
|
属性idはオプションであり、トレース・メッセージでのみ使用します。値が指定されていない場合は、条件名(HeaderPresentなど)が使用されます。
属性enabledはオプションであり、デフォルト値はtrueです。この属性を使用して、条件をenable/disable(有効化/無効化)できます。この属性の値は、グローバル変数の値に設定できます。その場合、条件はグローバル変数の値に応じて有効化または無効化されます。
属性valueは、プロキシ変数の名前に設定できます。その場合、プロキシはチェックポイントで変数を評価し、その値を条件に使用します。
属性modeは、begins-with、ends-with、containsのいずれかに設定できます。
属性ignore-caseは、true、falseのいずれかに設定できます。
フィルタは、HTTPリクエスト/レスポンスのコンテンツを変更したり、プロキシに保存された状態情報(変数)を変更するためにプロキシで使用されます。フィルタは、構成ファイルでのリスト順に従って実行されます。表6-13に、インターセプタに定義可能なフィルタを示します。
表6-13 インターセプトに定義されるフィルタ
| フィルタ名 | 属性 | 説明 |
|---|---|---|
|
AddHeader |
enabled, name, value |
指定されたヘッダーを、指定された値とともにリクエスト/レスポンスに追加します。ヘッダー名の最後にコロン( 例:
|
|
SaveHeader |
enabled, name, variable |
指定されたリクエスト/レスポンスのヘッダー値を、指定されたプロキシ変数に保存します。ヘッダー名の最後にコロン( 例:
|
|
RemoveHeader |
enabled, name |
指定されたヘッダーをリクエスト/レスポンスから削除します。ヘッダー名の最後にコロン( 例:
|
|
AddParam |
enabled, name, value |
指定された名前と値を持つリクエスト・パラメータを追加します。 例:
|
|
SaveParam |
enabled, name, variable |
指定されたリクエストのパラメータ値を、指定されたプロキシ変数に保存します。 例:
|
|
AddRequestCookie |
enabled, name, value |
指定されたCookieを、指定された値とともにリクエストに追加します。 例:
|
|
SaveRequestCookie |
enabled, name |
指定されたリクエストのCookie値を、指定されたプロキシ変数に保存します。 |
|
AddResponseCookie |
enabled, name |
指定されたCookieを、指定された値とともにレスポンスに追加します。 例:
|
|
SaveResponseCookie |
enabled, name |
指定されたレスポンスのCookie値を、指定されたプロキシ変数に保存します。 例:
|
|
SaveHiddenFields |
enabled, form, variable, save-submit-fields |
指定されたプロキシ変数にフォーム名が指定されている場合、非表示の送信フィールドの値がすべて指定されたフォームで保存されます。送信フィールドを保存しない場合は、save-submit-fields属性をfalseに設定します。 例:
|
|
AddHiddenFieldsParams |
enabled, variable |
変数に保存された非表示フィールドごとにリクエスト・パラメータを追加します。 例:
|
|
SetVariable |
enabled, name, value |
指定された名前を持つプロキシ変数を指定された値に設定します。 例:
|
|
UnsetVariable |
enabled, name |
指定された名前を持つプロキシ変数を削除します。 例:
|
|
ClearSession |
enabled, name |
現行セッションのセッション変数をすべて削除します。 例:
|
|
SaveQueryParam |
enabled, name, variable |
指定された問合せパラメータを、指定されたプロキシ変数に保存します。 例:
|
|
SaveRequest |
enabled, variable |
リクエストのコンテンツ全体を、指定されたプロキシ変数に保存します。ヘッダーとボディが存在する場合は、すべてのヘッダーとボディも対象になります。 例:
|
|
SaveResponse |
enabled, variable |
レスポンスのコンテンツ全体を、指定されたプロキシ変数に保存します。ヘッダーとボディが存在する場合は、すべてのヘッダーとボディも対象になります。 例:
|
|
ReplaceText |
enabled, find, replace |
例:
|
|
ProcessString |
enabled, source, find, action, count, search-str, start-tag, end-tag, ignore-case, replace, encoding |
このフィルタを使用して、文字列(リクエスト、レスポンスのコンテンツなど)から部分文字列を抽出し、それをプロキシ変数に保存できます。また、このフィルタを使用して文字列を動的にフォーマット化することもできます。 |
|
FormatString |
enabled, variable, format-str, encoder, param-0, param-1, …, param-n |
このフィルタには FormatStringは、UIO Apacheプロキシではサポートされていません。ProcessStringによって必要な機能がすべて提供されるためです。 |
指定されたstart-tagとend-tagの間の部分文字列をソース文字列内で検索し、見つかったsub-stringを抽出して、抽出したsub-stringを指定の変数に保存します。'extract'のアクションにより、最初に一致するstart-tagとend-tagのペアが抽出されます。
<ProcessString source="%RESPONSE_CONTENT"
find="sub-string"
start-tag="var traceID = '" end-tag="';"
action="extract"
variable="$TRACE_ID"/>
指定されたsearch-stringをソース文字列内で検索し、それを置換文字列で置換して、更新された文字列を指定の変数に保存します。複数の一致が存在する場合は、カウント属性を使用して動作を指定することもできます。属性'count'は、値としてall、onceまたはnumberを取ることができます。
<ProcessString
source="/bfb/accounts/accounts.asp?TraceID=$TRACE_ID"
find="string" search-str="$TRACE_ID"
action="replace"
replace="$TRACE_ID"
variable="%POST_URL"/>
指定されたstart-tagとend-tagの間のsub-stringをソース文字列内で検索し、それを(開始タグと終了タグも含めて)検出されたsub stringの評価済の値に置換し、更新された文字列を指定の変数に保存します。複数の一致が存在する場合は、カウント属性を使用して動作を指定できます。この属性は、値として'all'、'once'またはnumberを取ることができます。
<ProcessString
source="/cgi-bin/mcw055.cgi?TRANEXIT[$UrlSuffix]"
find="sub-string" start-tag="[" end-tag="]"
action="eval"
variable="%LogoffUrl"/>
属性ignore-caseをtrueまたはfalseとして指定し、前述のすべての例に適用できます。したがって、検索操作では大/小文字を区別する場合としない場合があります。オプションとして、エンコーディング属性を指定できます。指定すると、結果の文字列が変数に保存される前にエンコードされます。この属性が取れる値はbase64のみです。この属性を指定しない場合、結果の文字列はそのまま保存されます。
エンコーディング属性は、UIO Apacheプロキシのみでサポートされています。On
次に、変数%useridおよび%passwordのユーザー名とパスワードを使用した、変数$AuthHeaderValueへのHTTP Basic認証のレスポンス・ヘッダーの作成方法の例を示します。
<FormatString variable="%UsernamePassword"
format-str="{0}:{1}"
param-0="%userid"
param-1="%password"
encoder="Base64"/>
<FormatString variable="$AuthHeaderValue"
format-str="Basic {0}"
param-0="%UsernamePassword"/>
インターセプタは、オプションとして、すべてのフィルタの実行後に次のアクションのいずれかを実行できます。アクション実行後に、さらにインターセプタが試行されることはありません。
redirect-client
プロキシでは、別のURLをロードするためにクライアントをリダイレクトする必要が生じることがあります。そのような場合、アクションとしてredirect-clientを使用します。プロキシは、302 HTTPレスポンスを送信して、指定したURLをロードするようクライアントに要求します。これは、次の2つの属性を取ります。urlにはユーザーのリダイレクト先であるURLが含まれており、display-urlはオプションです。
display-url属性がインターセプタに指定された場合、プロキシはHTTP 302レスポンスをブラウザに送信し、display-url属性に指定されたURLをロードします。プロキシは、このリクエストを受信すると、サーバー上でHTTP-GETを実行し、url属性で指定されたURLを取得します。
send-to-client
サーバーからのレスポンスをプロキシに保存し、他のHTTPリクエストをいくつか実行した後でクライアントに送信する必要が生じることがあります。そのような場合、アクションとしてsend-to-clientを使用します。プロキシは、指定された変数のコンテンツをクライアントに送信します。これは、次の2つの属性を取ります。htmlには、ユーザーに返送する保存済コンテンツのある変数が含まれており、display-urlはオプションの属性です。
display-url属性がインターセプタに指定された場合、プロキシはHTTP 302レスポンスをブラウザに送信し、display-url属性に指定されたURLをロードします。プロキシは、このリクエストを受信すると、インターセプタで指定されたレスポンスを送信します。
get-server
プロキシがサーバーからURLを取得する必要が生じることがあります。そのような場合、アクションとしてget-serverを使用します。プロキシは、指定されたURLのHTTP-GETリクエストをサーバーに送信します。これは、次の2つの属性を取ります。urlは取得の実行対象となるURLであり、display-urlはオプションです。
display-url属性がインターセプタで指定されたり、このアクションがレスポンス・インターセプタで指定された場合、プロキシはHTTP 302レスポンスをブラウザに送信します。プロキシは、このリクエストを受信すると、サーバー上でHTTP-GETを実行して、url属性で指定されているURLを取得します。
post-server
プロキシがサーバーのURLにpostする必要が生じることがあります。そのような場合、アクションとしてpost-serverを使用します。プロキシは、指定されたURLのHTTP-POSTリクエストをサーバーに送信します。これは、次の2つの属性を取ります。urlにはポストの送信先のURLが含まれており、display-urlはオプションです。
display-url属性がインターセプタで指定されたり、このアクションがレスポンス・インターセプタで指定された場合、プロキシはHTTP 302レスポンスをブラウザに送信します。プロキシは、このリクエストを受信すると、url属性で指定されているURLのサーバーに対してHTTP-POSTを実行します。
send-to-server
クライアントからのリクエストをプロキシに保存し、他のいくつかのHTTPリクエストを実行した後でそれをサーバーに送信する必要が生じることがあります。そのような場合、アクションとしてsend-to-serverを使用します。プロキシは、指定された変数のコンテンツをサーバーに送信します。これは、次の2つの属性を取ります。htmlには保存済コンテンツのある変数が含まれており、display-urlはオプションの属性です。
display-url属性がインターセプタで指定された場合、プロキシはHTTP 302リダイレクト・レスポンスをブラウザに送信します。これによって、ブラウザはdisplay-urlをリクエストし、プロキシは保存されたリクエストをサーバーに送信します。このアクションをレスポンス・インターセプタで使用する場合は、display-urlが必須です。これを指定しないと、アクションは失敗します。
プロキシ変数は、文字列データをプロキシのメモリーに格納できます。変数は、条件、フィルタおよびアクションで使用できます。たとえば、SaveHeaderフィルタを使用して、特定のヘッダーの値を、指定されたプロキシ変数に保存できます。この変数値は、後で使用できます(たとえば、パラメータをリクエストに追加するために)。また、変数を条件で使用して、インターセプタを実行できるかどうかを判別することもできます。
プロキシ変数は、その寿命に応じて3つのタイプがあります。変数のタイプは、変数名の最初の文字、%、$、@のいずれかによって判別されます。
すべての変数タイプは、SetVariable、SaveHeader、SaveParam、SaveResponseなどのフィルタを使用して設定できます。
すべての変数タイプは、UnsetVariableフィルタで設定解除/削除できます。すべてのセッション変数を削除するには、ClearSessionフィルタを使用します。
リクエスト変数
リクエスト変数: これらの変数名は%で始まります。これらの変数は現在のリクエストに関連付けられており、現在のリクエストの完了時に削除されます。リクエスト変数は、リクエスト全体で値を必要としない場合に使用します。
セッション変数
セッション変数: これらの変数名は$で始まります。これらの変数は現在のプロキシ・セッションに関連付けられており、プロキシ・セッションのクリーンアップ時に削除されます。セッション変数は、クライアントのリクエスト全体にわたって値を保持する必要がある場合に使用します。
グローバル変数
グローバル変数: これらの変数名は@で始まります。これらの変数は現在のプロキシ構成に関連付けられており、プロキシ構成のアンロード時に削除されます。グローバル変数は、リクエスト全体およびクライアント全体にわたって値を保持する必要のある場合に使用します。
グローバル変数は、プロキシ構成のロード時に構成ファイルでSetGlobalを使用して設定できます。
事前定義済変数
UIOプロキシでは、次の事前定義済リクエスト変数をサポートしています。
表6-14 UIOプロキシによりサポートされる事前定義済変数
| 変数名 | 説明 |
|---|---|
|
%RESPONSE_CONTENT |
この変数には、現在のリクエストに対するWebサーバーからのレスポンス全体のコンテンツが含まれています。UIO Apacheプロキシでは、 |
|
%REQUEST_CONTENT |
この変数には、クライアントのリクエスト全体のコンテンツが含まれています。UIO Apacheプロキシでは、 |
|
%QUERY_STRING |
この変数には、現在のリクエストURLの |
|
%REQUEST_METHOD |
リクエストのHTTPメソッドの動詞( |
|
%REMOTE_HOST |
クライアントまたはクライアント・エージェントのホスト名。(UIO Apacheプロキシの場合は、Apacheディレクティブ' |
|
%REMOTE_ADDR |
クライアントまたはクライアント・エージェントのIPアドレス。 |
|
%HTTP_HOST |
HTTPホスト・ヘッダーのコンテンツ。 |
|
%URL |
現在のリクエストのURL。 |
HTTPメッセージは、クライアントからサーバーへのリクエストとサーバーからクライアントへのレスポンスで構成されます。HTTPはトランザクション指向です。クライアントからサーバーへのリクエストには、サーバーからクライアントへのレスポンスが1つ割り当てられます。リクエストにはいくつかのヘッダーがあり、その後にオプションとしてリクエスト・ボディが続きます。同様に、レスポンスにもいくつかのヘッダーと、オプションとしてボディが1つあります。プロキシはクライアントとターゲット・アプリケーションの中間に存在するため、構成XMLを使用してHTTPリクエストのリクエスト・ヘッダーとボディ、レスポンス・ヘッダーとボディを変更できます。レスポンスとして、通常の200 OKレスポンス、リダイレクト・レスポンス302、またはその他のどのHTTPステータス・レスポンスも使用できます。いずれの場合でも、レスポンスはそのリクエストに対応しており、同じリクエストのレスポンス・インターセプタをトリガーします。たとえば、リクエストがURL /doLogin.doに対するもので、そのレスポンスが/loginPage.jspという場所でのredirect (302)である場合、すべてのリクエストおよびレスポンス・インターセプタがURL /doLogin.doに対してトリガーされます。次のHTTPリクエストは/loginPage.jspにあるHTTP GETであり、これによって/loginPage.jspに対するすべてのリクエストおよびレスポンス・インターセプタがトリガーされます。
リクエストを受信すると、プロキシはURLに対して定義されたリクエスト・インターセプタを、構成ファイルでの定義順に評価します。同様に、Webサーバーからレスポンスを受信すると、プロキシはHTTPリクエストのURLに対して定義されたレスポンス・インターセプタを、構成ファイルでの定義順に評価します。
インターセプタの条件がtrueに評価されると、そのインターセプタが実行されます。たとえば、フィルタとアクションが実行されます。インターセプタの実行後、次の条件が満たされている場合にのみ、後続のインターセプタの実行が続行されます。
現在のインターセプタに対して指定されたアクションがない。
現在のインターセプタのpost-exec-action属性がcontinueである。
post-exec-action属性は、アクションを定義していないインターセプタに対して指定するようにしてください。グローバル・インターセプタ(アプリケーションの外部で定義されたインターセプタなど)の場合、post-exec-action属性のデフォルト値はcontinueです。リクエスト・インターセプタのpost-exec-actionのstop-phase-intercept値によってリクエストのインターセプションが停止しますが、stop-interceptがそのリクエストに対するインターセプションを完全に停止している間はレスポンスのインターセプションが続行されます。グローバル以外のインターセプタについては、アクションが指定されていない場合のデフォルト値はcontinueであり、アクションが指定されている場合のデフォルト値はstop-phase-interceptになります。
前述したように、プロキシ構成には複数のアプリケーションを含めることができます。URLに対して評価するインターセプタのリストを検索している間は、次のインターセプタのみが検討されます。
アプリケーションの外部で定義されているグローバル・インターセプタ
現在のセッションに関連付けられたアプリケーションで定義されているインターセプタ
各セッションに関連付けられるアプリケーションは、最大で1つです。プロキシがURLに対するインターセプタをアプリケーションで見つけたときに、現在のセッションに関連付けられたアプリケーションが(まだ)存在していない場合は、そのアプリケーションが現在のセッションに関連付けられます。
現在のセッションにすでにアプリケーションが関連付けられており、URLに対するインターセプタがそのアプリケーションに見つからない場合、プロキシは他のアプリケーションでインターセプタを検索します。URLに対するインターセプタが別のアプリケーションで見つかった場合は、セッションが新規作成され、リクエストはその新しいセッションに関連付けられます。
UIOプロキシは、たとえばOAAMサーバーを使用してパスワードを収集したり、リスク・ルールを実行するために、適切なタイミングでユーザーをOAAMサーバー・ページにリダイレクトします。HTTPヘッダーは、UIOプロキシとOAAMサーバー間でデータをやり取りするために使用します。表6-15に、プロキシ構成で参照されるOAAMサーバー・ページと、データの受渡しに使用するHTTPヘッダーの詳細を示します。また、指定された条件でプロキシが実行すると予想されるアクションも示します。
表6-15 OAAMサーバー・インタフェース
| URL | 条件 | アクション |
|---|---|---|
|
OAAMサーバー・ページへのリクエスト |
リクエスト受信時 |
ヘッダー「 |
|
loginPage.jspまたはlogin.do |
アプリケーション・ログイン・ページへのリクエスト受信時 |
このURLにリダイレクトして、アプリケーションのログイン・ページのかわりにOracle Adaptive Access Managerのログイン・ページを使用します。 |
|
password.do |
レスポンスにはヘッダーのユーザーIDとパスワードが含まれます(アプリケーションによっては、さらに多くが含まれる場合もあります)。 |
レスポンス・ヘッダーからの資格証明を保存し、アプリケーションにポストします。
|
|
login.do |
フェーズ1のみ: ユーザーにより入力された資格証明の検証後。 |
このURLにリダイレクトしてOracle Adaptive Access Managerでステータスを更新し、適切なリスク・ルールを実行します。 |
|
login.do |
フェーズ1のみ: リクエスト受信時。 |
|
|
updateLoginStatus.do |
フェーズ2のみ: ユーザーにより入力された資格証明の検証後。 |
このURLにリダイレクトしてOracle Adaptive Access Managerでステータスを更新し、適切なリスク・ルールを実行します。 |
|
updateLoginStatus.do |
フェーズ2のみ: リクエスト受信時 |
|
|
updateLoginStatus.do challengeUser.do registerQuestions.do userPreferencesDone.do |
レスポンス・ヘッダー Rules-Resultには値allowが設定されています。 |
Oracle Adaptive Access Managerのルールは、ログインを許可するように評価しました。この時点以降、プロキシで、保護されたアプリケーションURLへのアクセスを許可できます。 |
|
registerQuestions.do |
レスポンス・ヘッダー Rules-Resultには値blockが設定されています。 |
アプリケーションがログイン資格証明を受け入れなかったか、Oracle Adaptive Access Managerのルールでログインをブロックするように評価されました。ログインが成功した場合、プロキシでアプリケーションのセッションをログオフする必要があります。それによって、Login Blockedメッセージがブラウザに送信されます。 |
|
changePassword.do |
レスポンスにはpassword、newpasswordおよびconfirmpasswordというヘッダーが含まれています。 |
レスポンス・ヘッダーからのパスワードを保存して、アプリケーションにポストします。 |
|
loginFail.do |
Login Blockedメッセージなどのエラー・メッセージをOAAMサーバー・ページに表示します。 |
適切な 通常、ブロック状況下では、レスポンス・ヘッダーを通してプロキシに制御が渡ることはありません。かわりに、問合せパラメータ
または、次のURLを使用して同じ結果を得ることもできます。
|
|
logout.do |
アプリケーション・セッションのログアウト完了時 |
このURLにリダイレクトして、OAAMサーバー・セッションをログアウトします。 |
|
logout.do |
レスポンス受信時 |
アプリケーション・ログアウトURLにリダイレクトして、アプリケーション・セッションがまだオフになっていない場合にそれをログオフします。 |
|
resetPassword.do |
レスポンスには、ヘッダーnewpasswordおよびconfirmpasswordが含まれています。 |
レスポンス・ヘッダーからのパスワードを保存して、アプリケーションにポストします。 |
|
getUserInput.do |
レスポンスには、ヘッダーBH_UserInputが含まれています。 |
ユーザー入力を保存して、適切なアクションを実行します(アプリケーションへのポストなど)。 |
|
changeUserId.do |
リクエスト受信時 |
|
|
changeUserId.do |
レスポンス受信時 |
適切なアプリケーション・ページにリダイレクトするか、保存されたアプリケーション・レスポンスを返送します。 |
|
updateForgotPasswordStatus.do |
フェーズ2のみ: ユーザーにより入力されたforgot- password-credentialsの検証後。 |
このURLにリダイレクトしてOracle Adaptive Access Managerでステータスを更新し、適切なリスク・ルールを実行します。 |
|
updateForgotPasswordStatus.do |
フェーズ2のみ: リクエスト受信時 |
|
|
updateForgotPasswordStatus.do challengeForgotPasswordUser.do |
レスポンス・ヘッダー BH_FP-Rules-Resultには値allowが設定されています。 |
Oracle Adaptive Access Managerルールは、forgot-passwordフローを許可するように評価しました。プロキシでは、アプリケーションに応じてパスワードをリセットするか、ユーザー・ログインを許可するために、forgot-passwordフローの続行を許可できます。 |
|
updateForgotPasswordStatus.do challengeForgotPasswordUser.do |
レスポンス・ヘッダー BH_FP-Rules-Resultには値blockが設定されています。 |
アプリケーションがforgot-password資格証明を受け入れなかったか、Oracle Adaptive Access Managerルールがforgot-passwordフローをブロックするように評価しました。Login Blockedメッセージがブラウザに送信されます。 |
|
OAAMサーバー・ページへのリクエスト |
プロキシがプロパティ値をOAAMサーバーから取得する必要がある場合。 リクエスト受信時 |
OAAMサーバーは、複数のレスポンス・ヘッダーの値をプロパティごとに1つずつ返します。返されるレスポンス・ヘッダー名のフォーマットは |
アプリケーション検出では、設定の中から2つのフラグが使用されます。1つのフラグは、構成XMLを無視してリバース・プロキシ専用として動作するようプロキシに指示します。もう1つのフラグは、すべてのHTTPトラフィックを取得してそれをログに出力するようプロキシに指示します。最初のフラグは、HTTPトラフィックの取得とその分析のためにアプリケーション検出で使用します。2番目のフラグは、構成XML自体のデバッグに対応するために構成XMLのデプロイメント・フェーズ期間中ずっと維持されます。
アプリケーション検出とは、プロキシ構成を作成し、UIOプロキシを使用してマルチファクタ認証を追加するために既存のWebアプリケーションを調査するプロセスのことです。プロキシを使用してアプリケーションへのログインが何回か試みられ、ログインを試みるたびにHTTPトラフィックが取得されます。その後、取得したHTTPトラフィックを分析してプロキシ構成を作成します。UIOプロキシは、すべてのHTTPトラフィックをファイルにダンプするように設定する必要があります。さらに、アプリケーションへのログインをプロキシを通して何回か試みる必要があります。その後、取得したHTTPトラフィックを分析してプロキシ構成を作成します。
アプリケーション検出プロセスでは、ユーザーが使用している本番アプリケーションではなく、カスタマのテスト環境のWebアプリケーションを使用することをお薦めします。テスト環境が使用できない場合は、ライブ・アプリケーションを使用できます。
アプリケーション検出プロセスでは、次の情報をクライアントから取得する必要があります。
アプリケーションにログインするためのURL。
テスト・ユーザー・アカウントの資格証明(forgot passwordシナリオに必要なデータも含む)。検出とテストが中断されないために、できるだけ多くのテスト・アカウント(少なくとも5つのアカウント)を取得してください。検出プロセス中にアカウントが無効になる場合がありますが、これは無効なログインの試みが複数回行われたためです。
テスト・アカウントを有効化/テストするための連絡先(電話、電子メール)。
アプリケーション検出では、プロキシを使用してHTTPトラフィックを取得する必要があります。
表6-16に、この操作モードを有効化する設定(UIO_Settings.xml内にあります)を示します。
IgnoreUrlMappingsの設定は、プロキシを介したHTTPトラフィックのURLインターセプションを無効にするために使用します。
CaptureTrafficの設定では、情報のログ・レベルに設定されているロガー名HTTPを使用してHTTPトラフィックが取得されます。
HTTPトラフィックの取得は、シナリオごとに(ログイン試行の成功、不正パスワード、不正ユーザー名、無効になったユーザーなど)ファイル別にしておくと便利です。ログ・ファイル名の設定は、シナリオを開始する前に適切なファイル名に更新してください。
アプリケーション検出の実行後に、表6-17に示すようにプロキシ設定を行って、デフォルトのUIO Apacheプロキシの動作をリストアする必要があります。
HTTPトラフィックで特定のURLと条件を検索するインターセプタを、TestConfig.xmlファイルに作成する必要があります。プロキシはHTTPトラフィックをリスニングして、TestConfig.xmlファイルのURLと一致するURLを確認したときに、URL一致のあるインターセプタを評価し、そのインターセプタの条件ブロックを評価します。一致した場合、UIOプロキシはフィルタ・ブロックと条件ブロックを実行します。
ログイン
ログイン・プロセスを開始するURL。
ログイン・フォームを含むURL。
資格証明の送信に使用する入力フィールドの名前(ユーザー名、パスワードなど)。
ログイン・フォームの資格証明の送信先のURL。
ログイン成功の識別。この情報を得るには、HTTPトラフィック・ダンプを精査する必要があります。ログイン成功に対するアプリケーションの応答として、次のいくつかの方法があります。
資格証明送信レスポンスに特定のCookieを設定する。
特定のURL(アカウント・サマリー、ようこそページなど)にリダイレクトする。
特定のテキストで応答する。
失敗の場合に、理由を添えて失敗ログインを識別する。これは、資格証明送信リクエストに対するレスポンスで特定のテキストを検索することによって得られることがよくあります。
ログアウト
ログアウト・プロセスを開始するURL。
ログアウト・プロセスを終了するURL。通常、ログアウトは、ログアウト開始URLに対するレスポンスを受信したときに終了します。
パスワード変更
パスワード変更プロセスを開始するURL。
パスワード変更フォームが含まれているURL。
パスワード変更リクエストの送信に使用する入力フィールドの名前(パスワード、新規パスワード、パスワードの確認など)。
パスワード変更フォームのパスワード送信先のURL。
パスワード変更リクエストのステータス(成否)を識別します。これは、レスポンスで特定のテキストを検索することによって得られることがよくあります。
パスワードのリセット
パスワード変更と同じプロセスです。
ログインIDの変更
login-id変更がアプリケーションにポストされる際のURL。
パスワード変更リクエストの送信に使用する入力フィールドの名前(new-loginなど)。
login-id変更リクエストのステータス(success/failure)を識別します。login-id変更リクエストが成功したときに、OAAMサーバーでchangeUserId.doページを呼び出して、Oracle Adaptive Access Managerデータベースでlogin-idを更新する必要があります。
パスワード忘れ
アプリケーションが提供するForgot-passwordオプションを確認して、理解を深める必要があります。多くのアプリケーションではユーザー識別の代替方法(アカウント番号/PIN、SSN/PIN、質問/回答など)が求められます。アプリケーションの中には、複数のオプションを提供するものもあります。アプリケーションの中には、代替の資格証明を正しく入力した後でパスワードをリセットできるものや、メール/電子メールによって新規パスワードをユーザーに送信するもの、カスタマ・ケアを呼び出す必要のあるものがあります。サポートされるシナリオごとに、次のデータを取得する必要があります。
forgot-passwordプロセスを開始するURL。
forgot-passwordフォームが含まれているURL。
forgot-passwordリクエストを送信するための入力フィールド名とURL。
forgot-passwordリクエストのステータス(成否)を識別します。
この項では、マルチファクタ認証をBigBank Webアプリケーションに追加するプロキシ構成を示しています。BigBank Webアプリケーションは、ログイン・フローを示しているサンプル・アプリケーションです。この例では、UIOプロキシとアプリケーションのログイン・フローとの統合を示します。
Apacheプロキシで使用する場合
<?xml version="1.0" encoding="utf-8"?>
<BharosaProxyConfig xmlns="http://bharosa.com/">
<RequestInterceptor id="AddAppIdToOAAMServerRequests-BigBank"
desc="Add BharosaAppId header to each request to oaam_server"
post-exec-action="continue">
<Conditions>
<VariableValue name="%URL"
value="/oaam_server/"
mode="begins-with"
ignore-case="true"/>
</Conditions>
<Filters>
<AddHeader name="BharosaAppId:" value="BigBank"/>
</Filters>
</RequestInterceptor>
<SetGlobal name="@Phase1Enabled" value="false"/>
<SetGlobal name="@Phase2Only" value="true"/>
<Application id="BigBank">
<!-- In phase one, you use BigBank's login form to collect username and password -->
<!-- In phase two, you use oaam_server login forms to collect username and password -->
<!-- Disable this interceptor after phase one is retired -->
<RequestInterceptor id="Phase1BigBankLoginPostRequest"
desc="get the loginid from the post parameters"
post-exec-action="continue" enabled="@Phase1Enabled">
<RequestUrl url="/bigbank/login.do"/>
<Conditions>
<VariableValue name="%REQUEST_METHOD" value="POST"/>
</Conditions>
<Filters>
<ClearSession/>
<SetVariable name="$WebUIOPhase" value="one"/>
<SaveParam name="userid" variable="$userid"/>
</Filters>
</RequestInterceptor>
<!-- Enable this interceptor after phase one is retired -->
<RequestInterceptor id="Phase2RedirectBigBankLoginPageRequest"
desc="Redirect BigBank login page requests to Bharosa login page"
enabled="@Phase2Only">
<RequestUrl url="/bigbank"/>
<RequestUrl url="/bigbank/"/>
<RequestUrl url="/bigbank/loginPage.jsp"/>
<Target action="redirect-client" url="/oaam_server/login.do"/>
</RequestInterceptor>
<RequestInterceptor id="Phase2BharosaLoginPageRequest"
desc="Phase-2 loginid post request"
post-exec-action="continue">
<RequestUrl url="/oaam_server/login.do"/>
<Conditions>
<VariableValue name="%REQUEST_METHOD" value="POST"/>
<ParamPresent name="userid"/>
<Not>
<ParamPresent name="password"/>
</Not>
</Conditions>
<Filters>
<ClearSession/>
<SetVariable name="$WebUIOPhase" value="two"/>
</Filters>
</RequestInterceptor>
<ResponseInterceptor id="Phase2PasswordPageResponse"
desc="Save the userid, decoded password from Bharosa Password Page response">
<ResponseUrl url="/oaam_server/password.do"/>
<Conditions>
<HeaderPresent name="userid:"/>
<HeaderPresent name="password:"/>
</Conditions>
<Filters>
<SaveHeader name="userid:" variable="$userid"/>
<SaveHeader name="password:" variable="$password"/>
</Filters>
<Target action="redirect-client"
url="/bigbank/loginPage.jsp"
display-url="/bigbank/GetLoginPage"/>
</ResponseInterceptor>
<ResponseInterceptor id="GetBigBankLoginPageResponse"
desc="Save values of all hidden fields; then post login crdentials">
<ResponseUrl url="/bigbank/GetLoginPage"/>
<Filters>
<SaveHiddenFields variable="%LoginPageHiddenParams"/>
<AddHiddenFieldsParams variable="%LoginPageHiddenParams"/>
<AddParam name="userid" value="$userid"/>
<AddParam name="password" value="$password"/>
</Filters>
<Target action="post-server" url="/bigbank/login.do"/>
</ResponseInterceptor>
<ResponseInterceptor id="InvalidLoginResponse"
desc="Invalid login response from BigBank">
<ResponseUrl url="/bigbank/login.do"/>
<Conditions>
<PageContainsText text="You have entered an invalid Login Id"/>
</Conditions>
<Filters>
<SetVariable name="$Login-Credentials-Status" value="invalid_user"/>
<SetVariable name="$Login-Continue-Url" value="%URL"/>
<SaveResponse variable="$Submit-Credentials-Response"/>
</Filters>
<Target action="redirect-client" url="/oaam_server/UpdateLoginStatusPage"/>
</ResponseInterceptor>
<ResponseInterceptor id="WrongPasswordResponse"
desc="Invalid login response from BigBank">
<ResponseUrl url="/bigbank/login.do"/>
<Conditions>
<PageContainsText text="We do not recognize your password"/>
</Conditions>
<Filters>
<SetVariable name="$Login-Credentials-Status" value="wrong_password"/>
<SetVariable name="$Login-Continue-Url" value="%URL"/>
<SaveResponse variable="$Submit-Credentials-Response"/>
</Filters>
<Target action="redirect-client" url="/oaam_server/UpdateLoginStatusPage"/>
</ResponseInterceptor>
<ResponseInterceptor id="LoginSuccessResponse"
desc="Login success response from BigBank">
<ResponseUrl url="/bigbank/activity.do"/>
<!-- ResponseUrl url="/bigbank/login.do"/ -->
<Conditions>
<NotVariableValue name="$Login-Status" value="In-Session"/>
<PageContainsText text="/bigbank/images/success.gif"/>
</Conditions>
<Filters>
<SetVariable name="$Login-Credentials-Status" value="success"/>
<SetVariable name="$Login-Continue-Url" value="%URL"/>
<SaveResponse variable="$Submit-Credentials-Response"/>
<AddHeader name="Login-Status:" value="$Login-Credentials-Status"/>
</Filters>
<!-- Target action="redirect-client" url="/oaam_server/UpdateLoginStatusPage"/ -->
<Target action="get-server" url="/oaam_server/updateLoginStatus.do"/>
</ResponseInterceptor>
<RequestInterceptor id="Phase1UpdateLoginStatusPageRequest"
desc="Update Bharosa Tracker with the login status">
<RequestUrl url="/oaam_server/UpdateLoginStatusPage"/>
<Conditions>
<VariableValue name="$WebUIOPhase" value="one"/>
</Conditions>
<Filters>
<AddHeader name="WebUIOPhase:" value="$WebUIOPhase"/>
<AddHeader name="userid:" value="$userid"/>
<AddHeader name="Login-Status:" value="$Login-Credentials-Status"/>
</Filters>
<!-- Any interceptors for /bigbank/login.do will not run because we are doing get-server. -->
<Target action="get-server" url="/oaam_server/login.do"/>
</RequestInterceptor>
<RequestInterceptor id="Phase2UpdateLoginStatusPageRequest"
desc="Update Bharosa Tracker with the login status">
<!--post-exec-action="continue" -->
<RequestUrl url="/oaam_server/UpdateLoginStatusPage"/>
<Filters>
<AddHeader name="Login-Status:" value="$Login-Credentials-Status"/>
</Filters>
<Target action="get-server" url="/oaam_server/updateLoginStatus.do"/>
</RequestInterceptor>
<ResponseInterceptor id="AllowLoginResponse"
desc="Tracker returned 'allow' - continue with login">
<ResponseUrl url="/oaam_server/UpdateLoginStatusPage"/>
<ResponseUrl url="/oaam_server/updateLoginStatus.do"/>
<ResponseUrl url="/oaam_server/challengeUser.do"/>
<ResponseUrl url="/oaam_server/registerQuestions.do"/>
<ResponseUrl url="/oaam_server/userPreferencesDone.do"/>
<Conditions>
<HeaderValue name="Rules-Result:" value="allow"/>
</Conditions>
<Filters>
<SetVariable name="$Login-Status" value="In-Session"/>
</Filters>
<Target action="send-to-client" html="$Submit-Credentials-Response"
display-url="$Login-Continue-Url"/>
</ResponseInterceptor>
<ResponseInterceptor id="Phase1FailLoginResponse" desc="BigBank failed the login">
<ResponseUrl url="/oaam_server/UpdateLoginStatusPage"/>
<ResponseUrl url="/oaam_server/updateLoginStatus.do"/>
<ResponseUrl url="/oaam_server/challengeUser.do"/>
<ResponseUrl url="/oaam_server/registerQuestions.do"/>
<ResponseUrl url="/oaam_server/userPreferencesDone.do"/>
<Conditions>
<VariableValue name="$WebUIOPhase" value="one"/>
<NotVariableValue name="$Login-Credentials-Status" value="success"/>
<HeaderValue name="Rules-Result:" value="block"/>
</Conditions>
<Filters>
<UnsetVariable name="$Login-Status"/>
</Filters>
<Target action="send-to-client" html="$Submit-Credentials-Response"
display-url="$Login-Continue-Url"/>
</ResponseInterceptor>
<ResponseInterceptor id="FailLoginResponse" desc="BigBank failed the login">
<ResponseUrl url="/oaam_server/UpdateLoginStatusPage"/>
<ResponseUrl url="/oaam_server/updateLoginStatus.do"/>
<ResponseUrl url="/oaam_server/challengeUser.do"/>
<ResponseUrl url="/oaam_server/registerQuestions.do"/>
<ResponseUrl url="/oaam_server/userPreferencesDone.do"/>
<Conditions>
<HeaderValue name="Rules-Result:" value="block"/>
<NotVariableValue name="$Login-Credentials-Status" value="success"/>
</Conditions>
<Filters>
<UnsetVariable name="$Login-Status"/>
</Filters>
<Target action="redirect-client" url="/oaam_server/loginPage.jsp?action=invalid_user"/>
</ResponseInterceptor>
<ResponseInterceptor id="BlockLoginResponse"
desc="BigBank passed login but tracker returned 'block' - fail the login">
<ResponseUrl url="/oaam_server/UpdateLoginStatusPage"/>
<ResponseUrl url="/oaam_server/updateLoginStatus.do"/>
<ResponseUrl url="/oaam_server/challengeUser.do"/>
<ResponseUrl url="/oaam_server/registerQuestions.do"/>
<ResponseUrl url="/oaam_server/userPreferencesDone.do"/>
<Conditions>
<HeaderValue name="Rules-Result:" value="block"/>
</Conditions>
<Filters>
<UnsetVariable name="$Login-Status"/>
</Filters>
<!-- /bigbank/LoginBlockedPage isn't a real page. The request will be intercepted and redirected. -->
<Target action="redirect-client" url="/bigbank/LoginBlockedPage"/>
</ResponseInterceptor>
<RequestInterceptor id="LoginBlockedPageRequest"
desc="logoff the session in BigBank">
<RequestUrl url="/bigbank/LoginBlockedPage"/>
<Target action="get-server" url="/bigbank/logout.do"/>
</RequestInterceptor>
<ResponseInterceptor id="Phase1LoginBlockedPageResponse"
desc="BigBank approved login; but Bharosa blocked the login"
post-exec-action="stop-intercept">
<ResponseUrl url="/bigbank/LoginBlockedPage"/>
<Conditions>
<VariableValue name="$WebUIOPhase" value="one"/>
</Conditions>
<Filters>
<ClearSession/>
</Filters>
<Target action="redirect-client" url="/oaam_server/loginFail.do?action=block"/>
</ResponseInterceptor>
<ResponseInterceptor id="Phase2LoginBlockedPageResponse"
desc="BigBank approved the login; but Bharosa blocked the login">
<ResponseUrl url="/bigbank/LoginBlockedPage"/>
<Filters>
<ClearSession/>
</Filters>
<Target action="redirect-client" url="/oaam_server/loginPage.jsp?action=block"/>
</ResponseInterceptor>
<ResponseInterceptor id="LogoutPageResponse"
desc="Bharosa logout selected; logoff the session in BigBank">
<ResponseUrl url="/oaam_server/logout.do"/>
<Target action="redirect-client" url="/bigbank/logout.do"/>
</ResponseInterceptor>
<ResponseInterceptor id="Phase1LogoffPageResponse"
desc="Logoff - clear Bharosa proxy session"
post-exec-action="stop-intercept">
<ResponseUrl url="/bigbank/logout.do"/>
<Conditions>
<VariableValue name="$WebUIOPhase" value="one"/>
</Conditions>
<Filters>
<ClearSession/>
</Filters>
</ResponseInterceptor>
<ResponseInterceptor id="Phase2LogoffPageResponse"
desc="Logoff - clear Bharosa proxy session">
<ResponseUrl url="/bigbank/logout.do"/>
<Filters>
<ClearSession/>
</Filters>
<!-- Target action="redirect-client" url="/oaam_server/loginPage.jsp"/ -->
</ResponseInterceptor>
</Application>
</BharosaProxyConfig>
表6-18では、サンプル構成で定義されている各種インターセプタを説明しています。
表6-18 サンプル構成のインターセプタ
| インターセプタID | タイプ | 説明 |
|---|---|---|
|
AddAppIdTobharosauioRequests-BigBank |
リクエスト |
OAAMサーバーのすべてのリクエストのヘッダーを設定します。OAAMサーバーへのリクエストにより起動します。 |
|
Phase1BigBankLoginPostRequest |
リクエスト |
ポスト・パラメータのログインIDを取得し、フェーズ1を設定しユーザーIDを保存します。 |
|
Phase2RedirectBigBankLoginPageRequest |
リクエスト |
アプリケーションからのログイン・ページをOAAMサーバーにリダイレクトします。フェーズ2が有効になり、アプリケーション・ログイン・ページがリクエストされたときに起動します。 |
|
Phase2BharosaLoginPageRequest |
リクエスト |
フェーズ2を設定し、変数を保存します。OAAMサーバーの |
|
Phase2PasswordPageResponse |
レスポンス |
ヘッダーにID/パスワードを保存し、クライアントをBigBankログイン・ページにリダイレクトします。OAAMサーバーの |
|
GetBigBankLoginPageResponse |
レスポンス |
非表示フィールドの値をすべて保存し、ログイン資格証明をBigBankにポストします。 |
|
InvalidLoginResponse |
レスポンス |
BigBankから無効なログイン・レスポンスを取得したときに実行するアクション。 |
|
WrongPasswordResponse |
レスポンス |
BigBankから不正パスワード・レスポンスを取得したときに実行するアクション。 |
|
LoginSuccessResponse |
レスポンス |
BigBankからログイン成功レスポンスを取得したときに実行するアクション。 |
|
Phase1UpdateLoginStatusPageRequest |
リクエスト |
フェーズ1を設定し、ヘッダーを追加します。BigBankからのログイン・レスポンス取得後にステータスを更新するという、OAAMサーバーへのリクエストにより起動します。 |
|
Phase2UpdateLoginStatusPageRequest |
リクエスト |
ヘッダーを追加し、OAAMサーバーをログイン・ステータスで更新します。 |
|
AllowLoginResponse |
レスポンス |
変数を設定し、クライアントを次のページに送ってログインを続行します。OAAMサーバーからログイン成功レスポンスを受信したときに起動します。 |
|
Phase1FailLoginResponse |
レスポンス |
ログイン・ステータスを設定し、クライアントを次のページに送ります。BigBankがログインに失敗し、レスポンスがOAAMサーバーから返送されたときにフェーズ1で起動します。 |
|
FailLoginResponse |
レスポンス |
ログイン・ステータスを設定し、クライアントをOAAMログイン・ブロック・ページにリダイレクトします。BigBankがログインに失敗し、フェーズ1が有効になっていないときに起動します。 |
|
BlockLoginResponse |
レスポンス |
|
|
LoginBlockedPageRequest |
リクエスト |
クライアントをBigBankログアウト・ページにリダイレクトします。BigBankログイン・ブロック済ページへのリクエストにより起動します。 |
|
Phase1LoginBlockedPageResponse |
レスポンス |
セッションをクリアし、クライアントをOAAMログイン・ブロック済ページにリダイレクトした後でインターセプトを停止します。フェーズ1で使用され、BigBankログイン・ブロック済ページからのレスポンスにより起動します。 |
|
Phase2LoginBlockedPageResponse |
レスポンス |
セッションをクリアし、クライアントをOAAMログイン・ブロック済ページにリダイレクトします。フェーズ1が有効でないときに使用され、BigBankログイン・ブロック済ページからのレスポンスにより起動します。 |
|
LogoutPageResponse |
レスポンス |
クライアントをBigBankログアウト・ページにリダイレクトします。OAAMログアウト・ページからのレスポンスにより起動します。 |
|
Phase1LogoffPageResponse |
レスポンス |
BigBankログアウト・ページからレスポンスを取得したときにセッションをクリアします。フェーズ1が有効なときに使用します。 |
|
Phase2LogoffPageResponse |
レスポンス |
BigBankログアウト・ページからレスポンスを取得したときにセッションをクリアします。フェーズ2が有効なときに使用します。 |
この項では、UIOプロキシを使用してBigBankアプリケーションに初めてログインするユーザーのフローを説明します。ログイン・フェーズ、登録フェーズ/登録スキップ・フェーズ、ログアウト・フェーズおよび逸脱フロー(ログインのブロック)を含む通常のフローについて説明しています。構成XMLで定義され、フローの各手順で使用されるインターセプタを示します。
注意: プロキシについては、インターセプタがリクエスト/レスポンスに一致する場合のメッセージのみが表示されます。クライアントとOracle Adaptive Access Manager/アプリケーションとの間でプロキシによって受け渡される通常のメッセージは、シナリオを単純化するために省略しています。
通常のフローは、ログイン、登録、登録スキップおよびログアウトという4つのフェーズで構成されます。
図6-5に、ログイン取得ページ(ログイン・フェーズ)のフローを示します。
クライアントは、アプリケーションのログイン・ページ(http://proxyhost:port/bigbank)をリクエストします。
プロキシはそのリクエストをインターセプトして、ヘッダーを設定します。次に、プロキシはクライアントをoaam_server/login.doにリダイレクトします。
リクエストは、AddAppIdTobharosauioRequests-BigBankおよびPhase2RedirectBigBankLoginPageRequestという2つのインターセプタによってインターセプトされます。
注意: AddAppIdTobharosauioRequests-BigBankは、HTTPヘッダーおよび変数を設定します。これによりOAAMサーバーに対するリクエストがすべてインターセプトされ、プロキシでは、このインターセプタの後に一致するものがないかどうかを確認するために、他のインターセプタの実行が試行されます。
Phase2RedirectBigBankLoginPageRequestは、クライアントをBigBankログイン・ページからoaam_server/login.doにリダイレクトします。
クライアントは、OAAMサーバー(http://proxyhost:port/oaam_server/login.do)でlogin.doを取得するようリクエストします。
OAAMサーバーは、クライアント・デバイスのフィンガープリントを処理するために、ジャンプ・ページにリダイレクトします。
OAAMサーバーは、クライアント・ブラウザからフィンガープリントを取得します。
OAAMサーバーは、図6-6に示すように、ログイン・ページでフィンガープリントを取得した後に応答します。
クライアントは、ユーザー名をOAAMサーバー(http://proxyhost:port/oaam_server/login.do)にポストします。
AddAppIdTobharosauioRequests-BigBankインターセプタ以外に、リクエストはPhase2BharosaLoginPageRequestインターセプタによってプロキシでインターセプトされます。プロキシはWebUIOPhaseを2に設定します。
OAAMサーバーが応答します。
OAAMサーバーはフィンガープリントを取得します。
OAAMサーバーは、パスワード収集ページでフィンガープリントを取得した後に応答します。パスワード収集ページには、図6-7に示すように厳密な認証デバイスがあります。
クライアントは、パスワードをOAAMサーバー(http://proxyhost:port/oaam_server/password.do)に送信します。
OAAMサーバーが応答します。
レスポンスは、Phase2PasswordPageResponseによってインターセプトされます。プロキシは、OAAMサーバーによってこれまでに収集されたログインIDとパスワードが含まれているヘッダーを保存し、クライアントを/bigbank/GetLoginPageにリダイレクトします。
プロキシは、クライアントをGetLoginPageにリダイレクトします。
クライアントは、GetLoginPage(http://proxyhost:port/bigbank/GetLoginPage)に対するリクエストをBigBankに送信します。
BigBankはレスポンスを返送します。
レスポンスは、プロキシでGetBigBankLoginPageResponseによってインターセプトされます。プロキシはパラメータを保存し、/bigbank/login.doに対してPost-serverアクションを実行します。これは、BigBankアプリケーションの通常の認証フローです。
プロキシはインターセプタをキューに入れて、クライアントをbigbank/login.doにリダイレクトします。
クライアントはlogin.do(http://proxyhost:port/bigbank/login.do)をリクエストします。
リクエストは、プロキシによってインターセプトされます。プロキシはキューに入れられたインターセプタ(GetBigBankLoginPageResponse)を実行して、リクエスト・メソッドをGETからPOSTに変更します。
BigBankが応答して、クライアントをactivity.doにリダイレクトします。これは、BigBankアプリケーションの通常の認証フローです。
クライアントはactivity.do(http://proxyhost:port/bigbank/activity.do)をリクエストします。
BigBankはログイン成功レスポンスを送信します。
レスポンスは、プロキシでLoginSuccessResponseによってインターセプトされます。プロキシはログイン・ステータスをsuccessに設定し、/oaam_server/updateLoginStatus.doに対してget serverアクションを実行します。
プロキシは、クライアントをupdateLoginStatus.doにリダイレクトします。
クライアントは、ステータス更新のリクエストをOAAMサーバーに送信します。
http://proxyhost:port/oaam_server/updateLoginStatus.do
OAAMサーバーは認証後チェックを実行して、その結果を返します。
レスポンスは、プロキシでAllowLoginResponseによってインターセプトされます。
プロキシは、send-to-clientアクションを実行します。display-url変数が設定されて、レスポンス受信後にクライアントがこのURLをリクエストできるようにします。
クライアントは、ユーザーが登録ページ(http://proxyhost:port/oaam_server/registerQuestions.do)を初めて取得するためのリクエストをOAAMサーバーに送信します。
レスポンス・ページには、ユーザー向けにスキップおよび登録という2つのオプションが表示されます。
図6-8に、クライアントが登録を選択する登録フローを示します。
クライアントは、登録を選択します(http://proxyhost:port/oaam_server/registerQuestions.doへのPost)。
OAAMサーバーは、その手順を示す応答を返します。
クライアントは、手順ページ(http://proxyhost:port/oaam_server/registerQuestions.do)で「続行」をクリックします。
OAAMサーバーは、質問ページによって応答します。
クライアントは質問/回答を選択し、それをOAAMサーバー(http://proxyhost:port/oaam_server/registerQuestions.do)に送信します。
OAAMサーバーは情報を更新して応答します。
プロキシは、次のページへのsend-to-clientを実行します。
レスポンスは、プロキシでAllowLoginResponseインターセプタによってインターセプトされます。プロキシは、認証が成功した後で次のページを指定して、sends to Clientアクションを実行します。クライアントは次の手順でアプリケーション・ページにリダイレクトされます。
クライアントは、プロキシを通して次のページをリクエストします(http://proxyhost:port/bigbank/activity.do)。
アプリケーション・ページ(activity.do)が、プロキシを通してクライアントに返送されます。ここでログイン・プロセスが終了します。
図6-9にログアウト・フェーズを示します。
クライアントは、「ログアウト」をクリックします(http://proxyhost:port/bigbank/logout.do)。
アプリケーションはレスポンスを返送して、クライアントをbigbank/loginPage.jspにリダイレクトします。
レスポンスは、セッション変数を消去するPhase2LogoffPageResponseによってインターセプトされます。
クライアントは、BigBankログイン・ページ(http://proxyhost:port/bigbank/loginPage.jsp)をリクエストします。
プロキシはそのリクエストをインターセプトし、クライアントをOAAMサーバーにリダイレクトします。
クライアントは、OAAMサーバーに対してlogin.do(http://proxyhost:port/oaam_server/login.do)をリクエストします。
OAAMサーバーは、クライアント・デバイスのフィンガープリントを処理するために、ジャンプ・ページにリダイレクトします。
OAAMサーバーは、クライアント・ブラウザをフィンガープリント処理します。
OAAMサーバーは、フィンガープリント処理後にログイン・ページで応答します。
図6-10に登録スキップ・フェーズを示します。このフェーズで、クライアントは質問の登録をスキップすることを選択します。このフェーズは、通常のフローでログイン・フェーズの後に発生します。
クライアントは、登録(http://proxyhost:port/oaam_server/registerQuestions.doへのポスト)のスキップを選択します。
OAAMサーバーが応答します。
プロキシはレスポンスをインターセプトして、クライアントをリダイレクトします。
レスポンスは、AllowLoginResponseによってインターセプトされます。プロキシは、send-to-clientを使用してクライアントの次の手順を指定します。
クライアントは、プロキシにより指定されたページ(http://proxyhost:port/bigbank/activity.do)をリクエストします。
BigBankアプリケーションはレスポンスを返送します。
図6-11に、「逸脱フロー: ログインのブロック」を示します。これは、認証後チェックの後でクライアントをブロックするようにOAAMサーバーが決定したときに発生します。このフローは、通常のフローのログイン・フェーズにおける、手順15から19にかわるものです。
OAAMサーバーは、認証後チェックの後でユーザーをブロックするよう決定します。
レスポンスは、BlockLoginResponseインターセプタによってインターセプトされます。このインターセプタは、クライアントをアプリケーションのブロック・ページ(/bigbank/BlockLoginPage)にリダイレクトします。
プロキシは、クライアントをBigBankのloginBlockPageにリダイレクトします。
クライアントは、BigBankのBlockLoginPage(http://proxyhost:port/bigbank/loginPage.jsp?action=block)をリクエストします。
リクエストは、プロキシでLoginBlockedPageRequestによってインターセプトされます。プロキシは、ログアウト・ページ(/bigbank/logout.do)に対するget-serverアクションを受け入れます。このアクションにより、BigBankでのセッションが終了します。
アプリケーションが応答します。
レスポンスは、Phase2LoginBlockedPageResponseによってインターセプトされます。プロキシはセッションをクリアして、クライアントをOAAMログイン・ブロック・ページにリダイレクトします。
プロキシは、クライアントをOAAMログイン・ブロック・ページにリダイレクトします。
クライアントは、OAAMサーバーからブロック・ページ(http://proxyhost:port/oaam_server/loginPage.jsp?action=block)をリクエストします。
OAAMサーバーは、ブロック済ページで応答します。
Oracle Adaptive Access Managerパッチには、Microsoft WindowsおよびLinux(rhel4)向けにUIO Apacheプロキシの更新が含まれている場合があります。この章の手順に従って、mod_uio.soと関連する.dlls(MS Windowsの場合)、および.so(Linuxの場合)ライブラリをこのパッチ・リリースの一環としてリリースされたものと置換してください。
パッチのインストールは、UIOプロキシ・パッケージのインストールと類似しています。パッチには、変更済ファイルのみが含まれます。パッチによってファイルの一部またはすべてが上書きされるため、既存のファイルをすべてバックアップすることをお薦めします。
パッチには変更済ファイルのみが含まれるため、パッチ内のファイルが使用できない場合は、その手順をスキップしてください。各手順は、パッチ・インストーラで手動で実行する必要があります。
MS WindowsおよびLinuxで、次の手順を実行します。
更新中のApacheインスタンスを停止します。
|
注意:
|
既存のファイル、binary、rngおよび.xmlをバックアップします。
oaam_uioディレクトリにあるpatch_oaam_win_apache_uio.zip(Windowsの場合)またはpatch_oaam_rhel4_apache_uio.zip(Linuxの場合)を解凍します。
パッチからバイナリ・ファイルをコピーします(Linuxでは、必要に応じてソフト・リンクを.soファイルに設定する必要もあります)。
パッチからUIO_Settings.rngファイルとUIO_Config.rngファイルをコピーします。
既存のUIO_Settings.xmlファイルおよびUIO_log4j.xmlファイルをパッチに定義されているファイルと比較して、設定が正しいことを検証します。このパッチに関する項を参照して、設定が正しいことを確認します。これは、構成XMLファイルにも該当します。
Apacheを起動して、健全性テストを実行します。
Windowsの場合、
バイナリ・ファイル: mod_uio.so、log4cxx.dll、libxml2.dll、apr_memcache.dll(apr_memcache.dllは10.1.4.5.bp1で導入済)
構成ファイル: UIO_Settings.rng、UIO_Config.rng、UIO_Settings.xml、UIO_log4j.xmlおよびアプリケーション構成XMLファイル
Linuxの場合、
バイナリ・ファイル: mod_uio.so、liblog4cxx.so.0.10.0.0、libxml2.so.2.6.32、libapr_memcache.so.0.0.1
バイナリ構成ファイル: UIO_Settings.rng、UIO_Config.rng、UIO_Settings.xml、UIO_log4j.xmlおよびアプリケーション構成XMLファイル
