| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
アクセス・ポータル・サービスを使用するアプリケーションに対してフォーム入力シングル・サインオン機能を有効にできます。
次のトピックでは、フォーム入力シングル・サインオン機能を有効にする方法について説明します。
アプリケーション・ポリシーを作成したら、ポリシーにプロキシ対応アプリケーションURLを追加して、フォーム入力機能を有効にする必要があります。構成が完了したら、ポリシーをリポジトリに公開して、フォーム入力シングル・サインオンが期待どおりに機能するかどうかを確認するためにテストする必要があります。
次の各トピックでは、フォーム入力アプリケーション・ポリシーの構成方法について説明します。
Oracle Enterprise Single Sign-On管理コンソールを使用してフォーム入力アプリケーション・ポリシーを作成できます。
作成するには、次のようにします。
Oracle Enterprise Single Sign-On管理コンソールを起動します。
左側のツリーで「アプリケーション」ノードを右クリックし、コンテキスト・メニューから新規Webアプリケーションを選択します。
表示されるダイアログに、説明的な名前を入力し、「次」をクリックします。これは、Oracle Access Managerコンソールでアプリケーション・ポリシー名として表示されます。
表示される画面で、希望のフォーム・タイプを選択し、「OK」をクリックします。
表示される画面で、ターゲット・アプリケーションのURLを入力します。
「フィールドの検出」をクリックします。
アプリケーションのログオン・フォームがウィンドウに表示され、適切なフィールドが自動的に検出されて構成されます。次のことを確認してください。
フィールド・リストでフィールドが正しく検出され構成されていることを確認します。
「送信」ボタンが検出されます。「送信」ボタンが定義されていないと、資格証明のサイレント取得が機能しません。
アプリケーション・ポリシー(テンプレートとも呼ばれる)の作成の詳細は、Logon Managerのアプリケーション・テンプレートの作成および構成ガイドを参照してください。
「OK」をクリックして、アプリケーション・ポリシーを保存します。
「一般」タブで、アプリケーションについて説明するオプションのメタデータを指定します(このメタデータは、アクセス・ポータル参照アプリケーションまたは任意の解析済ユーザー・インタフェースに表示されます)。
説明: ユーザーのアプリケーションの意味のある説明。
参照: アプリケーション・テンプレートのバージョン/バリアントを説明する内部参照。
カテゴリ: アクセス・ポータル参照アプリケーションでアプリケーションが表示されるカテゴリ。たとえば、「会計」、「開発」などがあります。
アイコン・イメージURL: アクセス・ポータル参照アプリケーションのアプリケーション・エントリの横に表示されるアイコン・イメージのURL。
ロゴ・イメージのURL: アクセス・ポータル参照アプリケーションに表示されるフルサイズのアプリケーション・ロゴ・イメージのURL。
ベンダー: アプリケーションのベンダー。
管理者: 組織内のアプリケーション管理者の連絡先情報。
このテンプレートを利用可能にする希望のユーザーまたはユーザー・グループを選択します。
「セキュリティ」タブを選択します。
「ディレクトリ」ドロップダウン・メニューから、アクセス・ポータル・サービス・リポジトリを選択します。
「追加」をクリックします。
表示されるダイアログで、ターゲット・ユーザーまたはグループの名前を入力します。
名前の確認をクリックして、ディレクトリ内にユーザーまたはグループが存在することを確認します。エラーが表示される場合は、名前を再度入力して再試行してください。
「OK」をクリックして、変更を保存します。
ポリシーの「一般」タブからフォーム入力アプリケーション・ポリシーにプロキシ対応URLを追加できます。
追加するには、次のようにします。
アクセス・ポータル・サービスを使用すると、man-in-the-middleスヌーピングを回避するために各構成フィールドの挿入中にブラウザに表示されるモック資格証明フィールド値を構成できます。
モック資格証明フィールド値を構成するには、次のようにします。
ユーザーが挿入済資格証明の表示や変更をできないようにする場合は、オーバーレイ(任意の単色またはイメージ)を使用してフォーム全体をビューからマスキングするようにアクセス・ポータル・サービスを構成できます。
次の点に留意してください:
ターゲット・フォームにアプリケーション資格証明が存在しない場合、マスクが構成されていてもフォームはマスキングされず、ユーザーは自身の資格証明を入力して引き続きフォームで作業できます。
ターゲット・フォームに複数の資格証明セットが存在する場合、「ログオン・チューザ」ダイアログが表示され、ユーザーは挿入する資格証明を選択できます。
フォーム・マスキングを構成するには、次のようにします。
ポリシーをリポジトリに公開するかわりに、Oracle Access Managerコンソールにインポートして、そこで基本設定をさらに編集することもできます。
すでにリポジトリに公開している場合は、Oracle Access Managerコンソールはそれをリポジトリから取得してそのポリシー・リストに表示するため、このステップをスキップできます。ポリシーをOracle Access Managerコンソールで変更してから、それをEnterprise Single Sign-On管理コンソールで編集することにした場合は、アクセス・ポータル・サービス・リポジトリから更新されたバージョンを手動でプル・ダウンする必要があります。
ノート:
Oracle Access ManagerコンソールですべてのOracle Access Portal機能を構成できるわけではないため、Enterprise Single Sign-On管理コンソールでポリシーを作成および構成することをお薦めします。また、Oracle Access ManagementコンソールではUnicode以外のファイルのインポートはサポートされていないため、エクスポートした.INIファイルを保存するときにはUnicodeエンコーディングを選択する必要があります。
必要に応じて、Oracle Access Managerにポリシーをインポートするには、次のようにします。
Enterprise Single Sign-On管理コンソールを起動し、リポジトリから希望のポリシー(テンプレート)をインポートします。
ポリシーをファイルにエクスポートします。
「ファイル」メニューから「エクスポート」を選択します。
表示される「.INIファイルにエクスポート」ダイアログで、リストからポリシーを選択し、「OK」をクリックします。
表示されるダイアログで、「エンコーディング」ドロップダウン・リストから「Unicode」を選択し、エクスポートするファイルのパスと名前を指定して、「保存」をクリックします。
次のようにテンプレート・ファイルをOracle Access Managerにインポートします。
Oracle Access Managerコンソールにログオンします。
表示されるページの「Access Manager」セクションで、「アプリケーション」をクリックします。
アプリケーション・リストの上にあるツールバーで、「インポート」(青色の下向き矢印)をクリックします。
表示される「アプリケーションのインポート」ポップアップ・メニューで、「参照」をクリックします。
表示されるダイアログで、ポリシー・ファイルに移動し、「開く」をクリックします。
「アプリケーションのインポート」ポップアップで、「OK」をクリックします。
ポップアップで表示されるインポートするアプリケーションのリストで、希望のアプリケーションを選択し、「インポート」をクリックします。
表示されるアプリケーション構成ページで、各タブの構成設定が適切に持ち込まれていることを確認し、必要に応じて変更を行います。作業の終了後に、「保存」をクリックします。
インポートされたアプリケーション・ポリシーがアプリケーション・リストに表示されます。
ターゲット・アプリケーションのログイン・ページのURLパスに合致するようにEssoDirectSubmit Server Application Function (SAF)を構成してください。
ターゲット・アプリケーションへのユーザー接続を捕捉し、それらをリダイレクトしてWebゲート・プラグインをパス・スルーさせるために必要なプロキシ・ルールを作成するための基本的なガイドラインに従う必要があります。
Oracle Traffic Directorの構成の詳細は、『Oracle Traffic Director管理者ガイド』を参照してください。
リクエストされたユーザー接続はOracle Traffic Directorにより捕捉され、オリジン・サーバーにリダイレクトされるため、ページのコード内で参照されるすべてのリソースは、元のホストではなくOracle Traffic Directorのオリジン・サーバーを指すようパスをリライトする必要があります。そうしないと、これらの要素はロードされず、ページは適切に表示されず、予期したとおりに機能しない可能性が高くなります。次の各トピックでは、プロキシのリダイレクト後にページが適切に機能するためにリライトする必要のあるリソースのタイプに関するガイドラインを示します。
単一のホスト・サーバーに存在するOracle Access Portalアプリケーションに対してOracle Traffic Directorプロキシ・ルールを構成する必要があります。
複数のサーバー上でホストされているアプリケーションは対象外です。Oracle Traffic Directorの概念および構成手順に関する実用的な知識があることを前提としています。Oracle Traffic DirectorにOracle Access Portalアプリケーションを追加するには、次のようにします。
次のシナリオから、オリジン・サーバー・アプリケーションのページ(ホームページ、ログオン・ページ、ポストURLページ、ランディング・ページ)で必要なプロトコルを選択します。
HTTPのみ。アプリケーションのすべてのページはHTTPを介して提供されます。
HTTPSのみ。アプリケーションのすべてのページはHTTPSを介して提供されます。
HTTP (ログオン前)/HTTPS (ログオン後)。ホームページとログイン・ページはHTTPまたはHTTPSを介して表示されますが、認証に成功したユーザーのランディング・ページはHTTPSを介して表示されます。
HTTP (POSTはHTTPS)。すべてのページはHTTPを介して提供されますが、ログオン・フォームPOSTトランザクションはHTTPSを介して行われます。
適切なセキュリティを確保するため、プロキシ・ルールの構成時にプロキシ・リスナー・プロトコルをそれぞれのオリジン・サーバー・ページのプロトコルと一致させることを強くお薦めします。たとえば、最初にHTTPSを介して提供されたページに対してHTTPプロキシ・リスナーを構成しないでください。
これに対し、最初はHTTPを介して表示されたページに対してHTTPSリスナーを構成する場合は、追加のプロキシ・ルールを構成する必要があります(詳細はOracle Traffic Directorのドキュメントを参照)。
プロトコルごとに適切なリスナーを作成し、それらをターゲット仮想サーバーに割り当てます。
プロトコルごとに、対応するオリジン・サーバー・プールを作成します。各プールを明確に区別するために、オリジン・アプリケーションのプロトコルおよびURIを含めます。次に例を示します。
URI: http://www.originapp.com
プール名: origin-server-pool-http-www-originapp.com
URI: https://www.originapp.com
プール名: origin-server-pool-https-www-originapp.com
次のようにして、新規ルート・ウィザードを使用してオリジン・アプリケーションのルートを作成します。
ステップ3で作成したオリジン・サーバー・プールを選択します。複数のオリジン・サーバー・プールを作成した場合は、HTTP (SSL以外の)プールを選択します。
アプリケーションのURIルート条件を作成します。これが、アプリケーションにアクセスできるパスとなります。この値をオリジン・アプリケーションの名前に設定するか、条件ビルダーを使用することをお薦めします。このパスには、この手順で以降にPROXY_MAPという名前を付けます。
例: $uri =~ "^/originapp"
ウィザードの残りのステップを実行して、ルートの作成を完了します。
ルートのリストで、ステップ4で作成したルートを選択し、「詳細設定」セクションを開きます。
「リライト・ヘッダー」フィールドで、オリジン・アプリケーションのホスト・ヘッダーを次の形式で追加します。
location,content-location,host
次のルート・テンプレートを適用し、次に示すように変数を置き換えます。
#PROXY_MAP# - ステップ4bに示したプロキシ経由のアプリケーションへのパス(「開始URI」値の逆マップ)。例: originapp。
#OTD_HTTP# - アプリケーションのHTTPリスナーのポート。
例: 80
#OTD_HTTPS# - アプリケーションのHTTPSリスナーのポート番号。
例: 443
#ORIGIN_HOST# - リライトするオリジン・サーバー・プールのホスト名。
例: www.originapp.com
#DOCUMENT-DOMAIN# - Cookieの値を指定できるドメイン属性。
例: originapp.com
#Instructs OTD to map the incoming URI from the user's browser to the root path of the origin server. OTD also uses these values to create a reverse mapping to rewrite cookie paths. It is not usually necessary to change the value of the to parameter.
NameTrans fn="map" to="/" from="/#PROXY_MAP#" #Rewrite the https referer header <If defined $referer and $referer =~ "https://.*?\\.us\\.oracle\\.com:#OTD_HTTPS#/#PROXY_MAP#/(.*)$"> AuthTrans fn="set-variable" set-headers="referer=https://#ORIGIN_HOST#/$1" </If> #Rewrite the http referer header <If defined $referer and $referer =~ "http://.*?\\.us\\.oracle\\.com:#OTD_HTTP#/#PROXY_MAP#/(.*)$"> AuthTrans fn="set-variable" set-headers="referer=http://#ORIGIN_HOST#/$1" </If> #Remove potential headers that may interfere with mixed proxy content <If defined $srvhdrs{'content-security-policy'}> Output fn="sed-response-header" name="content-security-policy" sed="s|script-src |script-src 'self' |g" </If> <If defined $srvhdrs{'access-control-allow-origin'}> Output fn="set-variable" remove-srvhdrs="access-control-allow-origin" </If> #rewrite the location header when origin server is redirecting from HTTP to HTTPS <If defined $srvhdrs{'location'} and $srvhdrs{'location'} =~ "^https://#ORIGIN_HOST#(:\\d+)?(/?.*)" > Output fn="set-variable" $srvhdrs{'location'}="https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#$2" </If> <If defined $srvhdrs{'location'} and $srvhdrs{'location'} =~ "^http://#ORIGIN_HOST#(:\\d+)?(/?.*)" > Output fn="set-variable" $srvhdrs{'location'}="http://$urlhost:#OTD_HTTP#/#PROXY_MAP#/$2" </If> #Insert the Dynamic Proxy Script parameters AuthTrans fn="set-variable" insert-vars="DYNAMIC-PROXY-ENABLE=on" insert-vars="DYNAMIC-PROXY-MAP-TO=/#PROXY_MAP#" insert-vars="DYNAMIC-PROXY-MAP-FROM=/" insert-vars="DYNAMIC-PROXY-HTTPS=#OTD_HTTPS#" insert-vars="DYNAMIC-PROXY-HTTP=#OTD_HTTP#" insert-vars="DYNAMIC-PROXY-IGNORE-PATHS=" #Map all src,href,action,background,data-li-search-action and data-li-advanced-link attributes found in html content to the proxied path Output fn="insert-filter" filter="sed-response" sed="s|\\( src=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( src=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( href=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( href=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( action=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( action=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( background=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( background=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( data-li-advanced-link=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( data-li-advanced-link=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( data-li-search-action=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( data-li-search-action=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" append-newline-at-end="false" type="(text/html*|text/xml*)" #Map CSS attributes to the proxied path Output fn="insert-filter" filter="sed-response" sed="s|url(\"/\\([^/][^\"]\\)|url(\"/#PROXY_MAP#/\\1|g" sed="s|url('/\\([^/][^']\\)|url('/#PROXY_MAP#/\\1|g" sed="s|url(/\\([^/][^)]\\)|url(/#PROXY_MAP#/\\1|g" type="(text/css*|text/html*)" append-newline-at-end="false" #Rewrite full URL links to the OTD proxied host/port. These sed expressions keep the existing protocols in the URL. Output fn="insert-filter" filter="sed-response" sed="s|http://#ORIGIN_HOST#:80|http://$urlhost:#OTD_HTTP#/#PROXY_MAP#|g" sed="s|http://#ORIGIN_HOST#|http://$urlhost:#OTD_HTTP#/#PROXY_MAP#|g" sed="s|https://#ORIGIN_HOST#:443|https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#|g" sed="s|https://#ORIGIN_HOST#|https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#|g" sed="s|https:\\\\/\\\\/#ORIGIN_HOST#|https:\\\\/\\\\/$urlhost:#OTD_HTTPS#\\\\/#PROXY_MAP#|g" sed="s|http:\\\\/\\\\/#ORIGIN_HOST#|http:\\\\/\\\\/$urlhost:#OTD_HTTP#\\\\/#PROXY_MAP#|g" type="(text*|application*)" sed="s|//#ORIGIN_HOST#|https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#|g" append-newline-at-end="false" #Sanitize any illegal javascript domain values for our proxied host Output fn="insert-filter" filter="sed-response" sed="s|\\(document.domain=\"\\)#DOCUMENT_DOMAIN#\"|\\1$urlhost\"|g" sed="s|\\(document.domain='\\)#DOCUMENT_DOMAIN#'|\\1$urlhost'|g" sed="s|\\(document.domain = \"\\)#DOCUMENT_DOMAIN#\"|\\1$urlhost\"|g" sed="s|\\(document.domain = '\\)#DOCUMENT_DOMAIN#'|\\1$urlhost'|g" type="(text*|application*)" append-newline-at-end="false" #Attempt to rewrite any javascript page redirects Output fn="insert-filter" filter="sed-response" sed="s|\\(location.replace(\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2|g" sed="s|\\(location.replace(\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2|g" sed="s|\\(location.href =\"\\)\\(/[^/][^\"]*\"\\)|\\1/#PROXY_MAP#\\2|g" sed="s|\\(location.href ='\\)\\(/[^/][^']*'\\)|\\1/#PROXY_MAP#\\2|g" type="(text*|application*)" append-newline-at-end="false" #Attempt to rewrite any JSON objects that appear as URI paths.Output fn="insert-filter" filter="sed-response" sed="s|\\(:\"\\)\\(/[^/][^\"]*\"\\)|\\1/#PROXY_MAP#\\2|g" sed="s|\\(:'\\)\\(/[^/][^\']*'\\)|\\1/#PROXY_MAP#\\2|g" type="application/json*" append-newline-at-end="false" #rewrite any javascript page redirects common in ADF applications Output fn="insert-filter" filter="sed-response" sed="s|\\(redirect url=\"/\\)|\\1#PROXY_MAP#/|g" sed="s|<redirect>/\\([^/][^<]*\\)|<redirect>/#PROXY_MAP#/\\1|g" type="text/xml*" #Remove any domain attributes from the cookie header. This will force the browser to use the otd host name as a default Output fn="sed-response-header" name="set-cookie" sed="s|domain=#DOCUMENT_DOMAIN#||g" sed="s|Domain=#DOCUMENT_DOMAIN#||g" sed="s|domain=.#DOCUMENT_DOMAIN#||g" sed="s|Domain=.#DOCUMENT_DOMAIN#||g" sed="s|domain=.#ORIGIN_HOST#||g" sed="s|Domain=.#ORIGIN_HOST#||g"
生成されたテンプレートを$SERVER-obj.confファイルのターゲット・ルート(例: originapp)セクションに貼り付けます。
ステップ2で1つ以上のHTTPSリスナーを作成した場合は、$SERVER-obj.conf ファイルのターゲット・ルート(例: originapp)セクションを次のように変更します。
次の文を見つけます。
Route fn="set-origin-server" origin-server-pool= "origin-server-pool-http-www-originapp-com" rewrite-host="true"
次のセキュリティ・ルールを、ステップ9aに示した文のすぐ上に追加します。
<If $security>
Route fn="set-origin-server" origin-server-pool="origin-server-pool-https-www-originapp-com" rewrite-host="true"
</If>
サーバーを再構成します。
HTTPリクエストおよびレスポンス・ヘッダーには、Oracle Traffic Directorオリジン・サーバーを指すようリライトする必要のあるパラメータが含まれます。Oracle Traffic Directorは、オリジン・サーバーのホスト名と正確なプロトコル、または相対パスを含む基本的なロケーション・ヘッダーをリライトできます。
典型的なHTTPリクエスト・ヘッダーは次のようになります。
GET /web/en-US/default.aspx HTTP/1.1
Host: www.oracle.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html, application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.oracle.com/web/en-US/default.aspx ?root=1
Connection: keep-alive
この例のヘッダーには、パスのリライトを必要とする次のパラメータが含まれています。
GET: Webルートに対する要求されたページの相対パスと、HTTPプロトコル・バージョンを含みます。
例: GET /web/en-US/default.aspx HTTP/1.1
GETパラメータをリライトするプロキシ・ルールの例は次のとおりです。
NameTrans fn="map" to="/" from="/myLocalPath"
Host: ページ・ホストのURLを含みます。
例: www.oracle.com
Hostパラメータをリライトするプロキシ・ルールの例は次のとおりです。
Route fn="set-origin-server" origin-server-pool="myoriginserverpool" rewrite-host="true"
Referer: リクエストを参照したページのURLを含みます。例: http://www.oracle.com/web/en-US/default.aspx ?root=1
Refererパラメータをリライトするルールの例は次のとおりです。
<If defined $referer and $referer =~ "https://myoriginserver.oracle.com/myLocalPath/(.*)$">
AuthTrans fn="set-variable" set-headers="referer=https://www.oracle.com/$1"
</If>
ノート:
Webアプリケーションは多様であるため、前述の例に加えて、URLまたは相対パスを参照するその他のパラメータを構成するHTTPヘッダーを調べる必要があります。
サンプルのヘッダーのリライトされたバージョンは次のとおりです。
GET /myLocalPath/web/en-US/default.aspx HTTP/1.1
Host: myoriginserver.oracle.com:8484
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html, application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://myoriginserver.oracle.com:8484/myLocalPath/ web/en-US/default.aspx?root=1
Connection: keep-alive
Oracle Traffic Directorでは、別のオリジン・サーバーへの場所のリダイレクトを処理できません。たとえば、あるホストでホストされるログオン・ページが、正常なログオン時にユーザーを別のホスト上のページにリダイレクトする場合、この再マップのためのリライト・ルールを手動で構成する必要があります。次に例を示します。
<Object name="route-oracle-travel-sso">
<If defined $srvhdrs{'location'} and $srvhdrs{'location'} =~ "(http|https)://portal.myapplication.com(.*)$">
Output fn="set-variable" $srvhdrs{'location'}="https://myoriginserver.oracle.com:8484/travel-portal$2"
</If>
Output fn="sed-response-header" name="set-cookie" sed="s|path=/travel-sso/|path=/|g"
</Object>
<Object name="route-travel-portal">
Route fn="set-origin-server" origin-server-pool="origin-server-portal-oracle-travle" rewrite-host="true"
</Object>
Cookieのパスおよびドメイン・パラメータは、ターゲット・アプリケーション・ホストではなく、Oracle Traffic Directorオリジン・サーバーを指すようリライトする必要があります。
次に例を示します。
Set-cookie: v1st=1666B5EACC906D6; path=/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.www.oracle.com
これを次のようにリライトする必要があります。
Set-cookie: v1st=1666B5EACC906D6; path=/myLocalPath/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.myoriginserver.oracle.com
Cookieのリライト・ルールを構成する際は、次の点に注意してください。
Oracle Traffic Directorでは、.oracle.comなどのワイルドカードが使用されたドメインをリライトできません。.www.oracle.comなど、ターゲット・ホスト名を指定する必要があります。
アプリケーションが、複数のドメイン間でCookieを共有している場合は、各ドメインに対して個別のCookieリライト・ルールを作成する必要があります。
Oracle Authentication Manager Cookieは、Dropboxなどの特定のWebアプリケーションに影響を及ぼすため、Cookieが設定されたリクエストからストリップする必要があります。
Oracle Authentication Manager Cookieをストリップするルールの例は次のとおりです。
AuthTrans fn="sed-request-header" name="cookie" sed="s|OAMAuthnCookie[^;]*;| |g" sed="s|OAMRequestContext[^;]*;| |g"
Oracle Authentication Managerヘッダーは、アプリケーション・ホストに送信する前にストリップする必要があります。
Oracle Traffic Directorでは、ターゲット・ページのHTMLコード内のホスト名とリソース・パスをリライトする方法を直接提供していません。
これらの値をリライトするには、sed式を使用する必要があります。値のリライトを必要とする一般的なHTML要素には、src、hrefおよびactionがあります。
src、hrefおよびaction要素をリライトするために設定されたsedルールの例を次に示します。
Output fn="insert-filter" filter="sed-response" sed="s|\\(src\\)=\"/\\([^\"|^/]\\)|\\1=\"/myLocalPath/\\2|g" sed="s|\\(src\\)='/\\([^'|^/]\\)|\\1='/myLocalPath/\\2|g" sed="s|\\(href\\)=\"/\\([^\"|^/]\\)|\\1=\"/myLocalPath/\\2|g" sed="s|\\(href\\)='/\\([^'|^/]\\)|\\1='/myLocalPath/\\2|g" sed="s|\\(action\\)=\"/\\([^\"|^/]\\)|\\1=\"/myLocalPath/\\2|g" sed="s|\\(action\\)='/\\([^'|^/]\\)|\\1='/myLocalPath/\\2|g" type="text/html*"
ハードコードされたホスト名をリライトするルールの例は次のとおりです。
Output fn="insert-filter" filter="sed-response" sed="s|https://www.oracle.com|https://myoriginserver.oracle.com:8484/myLocalPath|g" type="(text*|application*)"
CSS要素内のパス参照をリライトするルールの例は次のとおりです。
Output fn="insert-filter" filter="sed-response" sed="s|url(\"/\\([^\"|^/]\\)|url(\"/myLocalPath/\\1|g" sed="s|url('/\\([^'|^/]\\)|url('/myLocalPath/\\1|g" sed="s|url(/\\([^) |^/]\\)|url(/myLocalPath/\\1|g" type="text/css*"
ホスト名とパスのリライト・ルールを作成する際は、次の点に注意してください。
リライトの際にコンテンツの互換性を最大化するために、Oracle Traffic Director構成ファイル内にターゲット・ページで使用されるコンテンツ・タイプの"Content-Type"属性値を含める必要があります。
圧縮されたコンテンツは、sedでは直接サポートされません。コンテンツにsedのリライト・ルールを適用する前に圧縮されたHTMLコンテンツを解凍して、後で再度圧縮するよう、Oracle Traffic Directorを構成する必要があります。
HTMLコンテンツを解凍して再度圧縮するルールの例は次のとおりです。
Output fn="insert-filter" type="(text*|application*)" filter="http-decompression"
Output fn="insert-filter" type="(text*|application*)" filter="http-compression"
場合によっては、リクエスト・ヘッダー内の"Accept Encoding"パラメータをストリップして、アプリケーション・ホストが最初から圧縮データを送信しないようにすることができます。
"Accept Encoding"ヘッダーをストリップするルールの例は次のとおりです。
AuthTrans fn="set-variable" remove-headers="accept-encoding"
JavaScriptコードの複雑性は様々なため、クリーンで互換性のあるリライト・ルールを作成するためには、コードをケース・バイ・ケースで確認する必要があります。
HTTPリクエスト・フィルタリング・メカニズムを使用してWebゲート・リクエスト・フィルタリングを構成できます。
Webゲート・プラグインには、次のHTTPリクエスト・フィルタリング・メカニズムが備わっています。
(ユーザーのブラウザへの)着信HTMLページへのJavaScriptタグの挿入
送信POSTリクエストでのモック資格証明置換
HTTP基本認証資格証明の挿入および資格証明の取得
リクエストがオリジン・サーバーに転送される前に、OAM/ESSO cookiesおよびヘッダーを削除するための送信HTTPリクエストのサニタイズ
Webゲート・プラグインでは、magnus.conf内に次のInitディレクティブが必要です。
NSAPIフィルタおよびSAFをロードするには:
Init fn="load-modules" funcs="OBWebGate_Init,OBWebGate_Authent,OBWebGate_Control,OBWebGate_Err,OBWebGate_Handle401,OBWebGate_Response,EssoBasicAuthInit,EssoBasicAuth,EssoClean" shlib="webgate.so" obinstalldir="Webgate_Home_Dir" obinstancedir="Webgate_Instance_Dir"
Init fn="OBWebGate_Init" obinstalldir="Webgate_Home_Dir" obinstancedir="Webgate_Instance_Dir" Mode="PEER"
HTTP Basic認証を有効化するには:
Init fn="EssoBasicAuthInit" obinstalldir="Webgate_Home_Dir" obinstancedir="Webgate_Instance_Dir" Mode="PEER"
説明:
| パラメータ | 説明 |
|---|---|
|
|
|
ターゲットWebゲート・インストール・ディレクトリへのフルパス。 |
|
Webゲート・インスタンス・ディレクトリへのフルパス。 |
|
すべてのプラグインを有効または無効にします。 |
JavaScript挿入フィルタは、ユーザーのターゲットWebブラウザに着信するページにタグ挿入を行います。
次の表では、サポートされているパラメータを説明します。
| パラメータ | 説明 |
|---|---|
|
JavaScript挿入フィルタを有効または無効にします。 |
|
JavaScript挿入の際に照合するHTMLタグ |
|
|
|
照合の際に大文字と小文字を区別するかどうかを決定します。 |
|
="パス"、デフォルトは
|
|
|
|
パートナIDの値です。 |
たとえば、obj.confに次のコードを追加すると、
AuthTrans fn="set-variable" insert-vars="DYNAMIC-PROXY-ENABLE=on" insert-vars="DYNAMIC-PROXY-MAP-TO=/myTarget" insert-vars="DYNAMIC-PROXY-MAP-FROM=/" insert-vars="DYNAMIC-PROXY-HTTPS=18484" insert-vars="DYNAMIC-PROXY-HTTP=18282" insert-vars="DYNAMIC-PROXY-IGNORE-PATHS=/ignoreMe"
次の結果が生成されます。
Output fn="insert-filter" type="text/*" filter="esso_webproxy" ESSOSearchTag="</title>"
動的プロキシを有効にし、JS挿入フィルタのパラメータをOracle Traffic Directorサーバー変数としてルートに挿入できます。動的プロキシの動作を構成するために、null以外の値のパラメータがJavaScriptタグに渡されます。
(DYNAMIC-PROXY-ENABLEパラメータを介して)動的プロキシ・サポートが有効化されている場合、次のパラメータがOracle Traffic Directorサーバー変数としてルートに挿入され、動的プロキシ動作を構成するためにJavaScript属性として渡されます。
nullでない値のみがJavaScriptタグに渡されます。DYNAMIC-PROXY-MAP-FROMまたはDYNAMIC-PROXY-MAP-TOのいずれの値も指定されていない場合、エラー("Dynamic proxy enabled but missing mapTo/mapFrom")がログに記録されます。これらのパラメータをobj.confに追加します。
| パラメータ | 説明 |
|---|---|
|
動的プロキシ機能を有効または無効にします。無効になっている場合、この表の残りの部分に示されたパラメータはJavaScript挿入フィルタに渡されません。 |
|
宛先URI。デフォルトはnull (空の文字列)です。 |
|
ソースURI。デフォルトはnull (空の文字列)です。 |
|
HTTPSポート番号。デフォルトはnull (空の文字列)です。 |
|
HTTPポート番号。デフォルトはnull (空の文字列)です。 |
|
無視する必要のあるURI。デフォルトはnull (空の文字列)です。 |
次に例を示します。
<script type='text/javascript' id='MyProxy' src='/myjavascript/myJavaScript.js'essoConsoleLoggingLevel='5' ... mapTo='/myTarget' mapFrom='/' ignorePaths='/ignoreMe' otdHttps='18484' otdHttp='18282'></script></head>
モック資格証明フィルタは、送信POSTリクエストにおいてESSOモック資格証明の置換を提供します。
デフォルトでは、リクエストが元のサーバーに渡される前に、OAMヘッダーがストリップされますが、これらはpass-oam-headersパラメータとともに転送できます。
有効にするには、次のようにobj.confのディレクティブにパラメータとともにディレクティブを追加します。
pass-oam-headers="true|false"、デフォルトは"false"です。
これには、次のヘッダーが含まれます(デフォルトは、省略されます)。
OAM_IMPERSONATOR_USER
OAM_REMOTE_USER
OAM_LAST_REAUTHENTICATION_TIME
OAM_IDENTITY_DOMAIN
次に例を示します。
Input fn="insert-filter" type="application/x-www-form-urlencoded" filter="esso_webproxy_input" pass-oam-headers="true"
WebブラウザのBasic認証(モーダル)ダイアログ間での資格証明の取得および挿入を行う機能を提供するHTTP Basic認証を構成できます。
次に示すように、magnus.conf内でHTTP Basic認証を構成します。
EssoBasicAuthInit関数とEssoBasicAuth関数をload-modules Initディレクティブに追加します(「Webゲート・リクエスト・フィルタリングの構成」を参照)。
ESSOBasicAuthInit関数をロードするスタンドアロンInitディレクティブを追加します。
次に例を示します。
Init fn="load-modules" funcs="OBWebGate_Init,OBWebGate_Authent,OBWebGate_Control,OBWebGate_Err,OBWebGate_Handle401,OBWebGate_Response,EssoBasicAuthInit,EssoBasicAuth,EssoClean" shlib="webgate.so" obinstalldir="Webgate_Home_Dir" obinstancedir="Webgate_Instance_Dir"
Init fn="EssoBasicAuthInit" obinstalldir="Webgate_Home_Dir" obinstancedir="Webgate_Instance_Dir" Mode="PEER"
ノート:
アクセス・ポータル・サービスをインストールすると、HTTP Basic認証はデフォルトで有効になります。これを無効にするには、load-modules InitディレクティブからEssoBasicAuthInit関数とEssoBasicAuth関数を削除し、magnus.conf ファイルからfn="EssoBasicAuthinit"スタンドアロン・ディレクティブを削除します。
次に、ヘッダー挿入SAFおよび資格証明取得フィルタのために、次のパラメータのうちの1つ以上をobj.confに追加します。
| パラメータ | 説明 |
|---|---|
policy |
必須。認証用に使用するESSOポリシー(認証テンプレート)の名前。 |
realm |
オプション。複数のレルムが使用中の場合、ターゲットWebサイトの該当する認証レルム。 |
次に例を示します。
NameTrans fn="EssoBasicAuth" policy="BasicAuth1" realm="realm1"
Output fn="insert-filter" filter="esso_output_capture" policy="BasicAuth1" realm="realm1"
HTTPリクエスト・サニタイザは、リクエストがオリジン・サーバーに転送される前に、Oracle Access ManagerおよびWebゲート・プラグインにより追加されたCookieとヘッダーのプロキシ経由HTTPリクエストをストリップします。
サニタイザは、次の名前のCookieを削除します。
OAM_Partner
OAMAuthnCookie_*
OAMRequestContext*
OAMAuthnHintCookie
OAM_*
ESSO_BAH* (基本認証のヒント、キャッシュ・ポリシー、レルムおよび資格証明のGUID)
ワイルドカード(前述の末尾にアスタリスクを付けたもの)を使用して、リクエスト固有のcookie名(サーバー名が含まれていることがあります)が照合されます。
サニタイザは、次のヘッダーを削除します。
OAM_IMPERSONATOR_USER
OAM_REMOTE_USER
OAM_LAST_REAUTHENTICATION_TIME
OAM_IDENTITY_DOMAIN
ノート:
モック資格証明フィルタは、このサニタイズ機能も提供しますが、モック資格証明が含まれるHTTP POSTリクエストを処理する場合に限られます。WebゲートHTTPリクエスト・サニタイザは、すべてのリクエストに対してこの機能を無条件で実行します。
サニタイザを有効にするには、magnus.confファイル内のload-modules InitディレクティブにEssoClean関数を追加します。次に例を示します。
Init fn="load-modules" funcs="OBWebGate_Init,OBWebGate_Authent,OBWebGate_Control,OBWebGate_Err,OBWebGate_Handle401,OBWebGate_Response,EssoBasicAuthInit,EssoBasicAuth,EssoClean" shlib="webgate.so" obinstalldir="Webgate_Home_Dir" obinstancedir="Webgate_Instance_Dir"
次に、obj.confファイルに次のコードを追加します。
<If not $uri =~ "/oamsso">
NameTrans fn="EssoClean"
</If>
ノート:
アクセス・ポータル・サービスをインストールすると、HTTPリクエスト・サニタイザはデフォルトで有効になります。これを無効にするには、magnus.conf ファイル内のload-modules InitディレクティブからEssoClean関数を削除し、obj.confファイルから前述のコードを削除します。
Webゲート・プラグインは、プロキシ経由URL内のターゲットの資格証明GUID値をオリジン・サーバーに渡します。この値が渡されるために、ターゲット・アプリケーションが正しく動作しない場合、次のリライト・ルールをOracle Traffic Director構成に追加して、GUID値をストリップします。
<If defined $query and $query =~ "(.*?)(ESSOCredGuid={.*?})(.*)$">
AuthTrans fn="set-variable" set-reqpb="query=$1$3"
</If>
