| 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 |
|
|
前 |
次 |
管理者は、ホスト識別子を手動で作成、変更、および削除できます。
Access Managerポリシーは、コンピュータ・ホストのリソースを保護します。Access Managerでは、コンピュータ・ホストは、ホスト識別子を使用して個別に指定されます。
表22-3は、従業員がアクセスできるWebサーバーの異なるホスト名を示しています。これらの名前すべてを使用して単一のホスト識別子を作成すると、ユーザーのアクセス方法に関係なくアプリケーションを適切に保護する1つのポリシー・セットを定義できます。
表22-3 ホスト識別子の例
| ホスト識別子のサンプル | 説明 |
|---|---|
hrportal.intranet.company.com |
従業員が覚えやすい名前。これはロード・バランシングされたプロキシで、このリクエストによってHRアプリケーションをホストするいくつかのサーバーのいずれかを実際に利用できます。 |
hr-sf-02.intranet.company.com |
直接アクセスできるアプリケーションをホストする単一のマシン。 |
hrportal.company.com |
以前の従業員の福利厚生や401k情報などの確認に主に使用するため、同じアプリケーションで企業ファイアウォールの外部にもアクセスできます。また、これはロード・バランシングされたリバース・プロキシです。 |
定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。
登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、Access Managerはリソースを保護するポリシーを適用できます。
Oracle Access Managementコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。アプリケーションおよびリソースがマップされたホスト識別子のないホストに存在する場合、管理者はホスト識別子を手動で追加できます。また、Oracle Access Management管理者は、新しいホスト名バリエーションに追加するために既存のホスト識別子を変更できます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加するには、新しいホスト名バリエーションが必要です。
詳細は、次を参照してください。
設計時に、特定のアプリケーション・ドメインに属するリソースを定義する場合、ホスト識別子を使用できます。リソースのホスト識別子(HTTP)またはタイプ(HTTP以外)を使用して、リソースをスコープします。この組合せにより、それらはAccess Manager全体で一意に識別されます。
ノート:
各リソースは、すべてのアプリケーション・ドメインで一意である必要があります。各リソースおよびホスト識別子の組合せは、すべてのアプリケーション・ドメインで一意である必要があります。
実行時の使用方法
実行時に、OAMエージェントからのアクセス問合せのWebサーバー・ホスト情報がホスト識別子にマップされ、ユーザーがアクセスしているリソースに関連付けられます。OAMエージェントは、次のどちらかの方法でWebサーバー・ホスト情報を取得します。
仮想Webホスティング・サポートに優先ホスト・パラメータが構成されている場合(「仮想Webホスティングについて」を参照)、指定されたリクエストのWebサーバー・ホスト情報がWebサーバーから取得されます。
優先ホスト・パラメータで直接Webサーバー・ホスト情報を指定する場合、Webサーバー固有のホスト情報と関係なく常に使用されます。
これにより、Webサーバーの現在のデプロイメントと一致するホスト名ではなくホスト識別子の論理ホスト名でリソースを指定できます。
たとえば、aseng-wikiにアクセスするユーザーは、次を入力します。
http://example-wiki.uk.example.com/wikiexample
ここで、wikiexampleはリソースURL、example-wiki.uk.example.comはホストです。このホストおよびポート(ポートは80)を照合して、ホスト識別子を示します。
優先ホスト
通常、OAMエージェントの優先ホスト文字列を設定して、Webサーバー・ホスト情報を取得します。エージェントが複数の仮想ホストをアクティブに保護する場合、この文字列をserver_nameに設定して、実際のリクエスト・ホスト名がWebサーバーのリクエスト・オブジェクトから正しく選択されていることを確認します。詳細は、「仮想Webホスティングについて」を参照してください。
ホストの認証および認証スキームのチャレンジ・リダイレクト
ユーザーが保護されたリソースURLにアクセスしようとすると、認証スキームの「チャレンジ・リダイレクト」フィールドに指定されたサーバーにリダイレクトします。認証チャレンジを別のホストで処理する場合、そのホストの名前を定義して、「ホスト識別子」リストで使用可能にする必要があります。たとえば、ユーザーが認証用のSSL対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。
ノート:
認証スキームの「チャレンジ・リダイレクト」フィールドにホスト名を入力する場合、ホスト識別子として定義する必要があります。
各ホスト識別子を定義して、1つ以上のWebサーバー・ホストを表すことができます。
ホスト識別子のいくつかの重要なガイドラインは、次のとおりです。
各ホスト名を一意にする必要があります。
各ホスト名:ポート・ペアを一意にする必要があります。
各ホスト名:ポート・ペアは、1つのホスト識別子にのみ属する必要があります。
各ホスト名:ポート・ペアは、エンド・ユーザーのエントリと完全に一致する必要があります。
ホスト識別子名とHTTP以外のリソース・タイプ名は一致しません。
各リソースおよびホスト識別子の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。
詳細は、「ホスト識別子のバリエーション」を参照してください。
すべての使用可能なホスト名バリエーションを定義してWebサーバー・ホストのアイデンティティを簡易化するには、ホスト識別子を使用します。ホスト識別子は、すべてのURLアドレス指定方法のリストで構成されます。ホスト識別子は、Access Managerで保護するWebサイトまたは仮想Webサイトごとに構成する必要があります。
Access Managerに対してWebサーバー・ホストを指定する場合、コンピュータ名やIPアドレスを指定するなど、様々な方法があります。次に、同じホストのアドレス指定方法の例を示します。
example.com
example.com:80
www.example.com
www.example.com:80
216.200.159.58
216.200.159.58:80
複数のWebサイトとドメイン名を含むWebサーバー上にWebgateをインストールできます。Webgateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。
この情報は、11gおよび10g Webgateで共通です。
多くのWebサーバーに対する仮想Webホスティング機能を使用すると、複数のドメイン名およびIPアドレスをサポートでき、各サーバーが単一の仮想サーバー上にある一意の各サブディレクトリに解決されます。たとえば、それぞれ独自のドメイン名と一意のサイト・コンテンツを持つabc.comとdef.comを、同じ仮想サーバー上でホストできます。名前ベースまたはIPベースの仮想ホスティングが可能です。
仮想ホストは、複数のNICカード(IPベース)または複数の名前(同じIPを解決するabc.comやdef.comなど)に基づいて使用される複数のサイトが同じホストに存在する状況を示します。
次に示すように、OAMサーバーのリバース・プロキシとして動作するOHSサーバーに構成される2つの仮想ホストが存在するケースを検討します。
1つの仮想ホストが双方向SSLモードで構成されています。
1つの仮想ホストが非SSLモードで構成されています。
異なる認証スキームで保護される2つのリソースとアプリケーション・ドメインがあると仮定します。
/resource1は、チャレンジURL(資格証明コレクションURLを定義するため)のhttps://sslvhost:port/を使用するX509Schemeで保護されます。
ユーザーが/resource1にアクセスすると、認証用のSSLポートのOHSサーバーにリダイレクトされ、X.509証明書を求められます。
/resource2は、チャレンジ・リダイレクトのhttp://host:port/を使用する2番目の仮想ホストのLDAPSchemeで保護されます。
ユーザーが/resource2にアクセスすると、非SSLモード(または必要に応じて一方向SSLモード)の2番目の仮想ホストにリダイレクトされます。LDAP認証のログイン・フォームが表示されます。
ノート:
10g mod_ossoを使用したX.509およびフォーム認証がデプロイメントでサポートされます。ただし、1つのSSOサーバーにのみ、mod_ossoを構成できます。この場合、エージェントは、非SSL仮想ホスト上のAccess Managerにリダイレクトします。資格証明コレクタは、リソースの認証スキームのチャレンジURLパラメータを確認し、X509認証のHTTPS仮想ホストにリダイレクトします。
10g Webgateをリバース・プロキシとともに、Access Managerに対して使用できます。
ここでは、この方法の長所と短所について説明します。
長所:
リクエストがすべてプロキシを経由するかぎり、すべてのWebコンテンツを単一の論理コンポーネントから保護できます。
これは、Access Managerによってサポートされないプラットフォームにも当てはまります。様々なプラットフォーム上(Windows XPやLinuxなど)で、異なるタイプのWebサーバー(iPlanetやApacheなど)が使用されていても、これらのサーバー上のすべてのコンテンツを保護できます。リバース・プロキシはサポートされていないWebサーバーに対する回避策となり、サポートされていないWebサーバーやWebgateをサポートしないプラットフォーム(MacOSなど)用に独自のアクセス・クライアントを記述する必要がなくなります。
リバース・プロキシを使用することで、アーキテクチャが柔軟になります。
リバース・プロキシを使用すると、イントラネットで使用可能なアプリケーションをデプロイしてエクストラネットに公開できるようになります。また、エクストラネットで使用可能なアプリケーションをイントラネットに公開することもできます。これらのことは、すでにデプロイされているアプリケーションを変更することなく行うことができます。
リバース・プロキシに1つのWebgateをインストールするのみで、各Webサーバー上にインストールする必要がなくなります。
これによって、管理ポイントが単一になり、システムの管理が容易になります。他のWebサーバーにフットプリントを確保しなくても、リバース・プロキシを経由することで、すべてのWebサーバーのセキュリティを管理できます。
短所: プロキシ使用の主な短所は、設定時に必要な作業が増えることです。リバース・プロキシの背後にあるWebサーバーにWebgateをデプロイする場合は、次の構成要件を満たす必要があります。
認証にリバース・プロキシを使用するすべてのWebサーバーが、リバース・プロキシからのリクエストのみを受け付けるようにします。
また、このWebサーバーにデプロイされたWebgateを、Webgateのフロントエンドであるリバース・プロキシ・サーバーからのリクエストに対してIP検証を施行しないように構成する必要もあります。これは、IP検証リストに、リバース・プロキシ・サーバー(1つまたは複数)の既知のIPアドレスを構成することによって行います。WebgateのIP検証を無効にする方法でも同じ結果が得られますが、セキュリティ上のリスクがあるためにお薦めできません。通常は、サーバーにACL文を追加することによって、Webサーバーがリバース・プロキシからのリクエストのみを受け付けるように構成します。これにより、ユーザーがリバース・プロキシをバイパスして制限付きコンテンツに直接アクセスしないようにします。
Policy Managerに構成された仮想ホストを更新し、アクセス・システムがリバース・プロキシに送信されたリクエストを捕捉できるようにします。
バックエンド・システムを直接ポイントするURLをユーザーが入力してプロキシを迂回することを防止します。
この問題の発生を防止するには、Webサーバーのアクセス制御リストまたはファイアウォール・フィルタを使用します。
すべてのユーザー・リクエストがプロキシによって処理されるため、負荷を処理するのに十分な数のプロキシ・サーバーをデプロイする必要があります。
既存のすべてのURLをリバース・プロキシ・サーバーのホスト名およびポート番号にリダイレクトします。
このため、リンク切れなどを防ぐため、絶対パスによるHTMLリンクを防止するためのコンテンツの検査および書換えを実行するようにリバース・プロキシを構成することが必要になる場合がよくあります。これはほとんどのリバース・プロキシで可能であり、またアクセス・システムとは無関係に構成できます。
フロントエンド・アプリーケーションに対して公開するURLリンクには相対URL (../../sub-path/resource)のみを使用し、絶対URL (http://example.com:[port]/path/resource)は使用しないことをお薦めします。
絶対URLは、リバース・プロキシの背後にデプロイされると、エンドユーザーのブラウザ上ではリンク切れになる可能性があります。
OAM Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。Apacheベースのサーバー以外のほとんどのWebサーバーでは、「優先ホスト」の値をHOST_HTTP_HEADERに設定する必要があります。これにより、ユーザーのブラウザからリクエストが送信されると、Webgateにより、「優先ホスト」の値がリクエストのホスト値に設定されます。
たとえば、次に示すように、ユーザーがURLに文字列example2を入力したとします。
http://example2
Webサーバーで、いずれかのWebサイトのホスト名がexample2であれば、その一致する仮想サイトでリクエストが処理されます。
展開されたOAM Webgate登録ページの「優先ホスト」フィールドで、次のように入力します。
HOST_HTTP_HEADER
IIS仮想ホスティング: IISコンソールから、各仮想Webサイトを構成して次のフィールドを含める必要があります。
ホスト・ヘッダー名
IPアドレス
ポート
10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。ApacheベースのWebサーバー(Apache、Apache 2、IBM HTTP Server、Oracle HTTP Serverなど)では、「優先ホスト」の値をSERVER_NAMEに設定する必要があります。
ノート:
SERVER_NAME値は、Apacheベースのサーバー以外のホストでサポートされません。この値をApacheベース以外のサーバーに設定すると、ユーザーはそのWebサーバーのWebgateで保護されるリソースにアクセスできません。かわりに、ユーザーはWebgate構成が正しくないことを示すエラーを受け取ります。
ServerNameディレクティブは、hostNameとともに明示的に7777に設定する必要があります。これはListenディレクティブが正しく設定されているかどうかには関係ありません。サーバーは、自己識別のためにこの値を明示的に要求する場合がありますが、通常は自動的に自己識別が可能です。
シングル・サインオンでApacheベースのリバース・プロキシを使用する場合、Webサーバーの構成ファイル(httpd.configなど)でApacheサーバーで実行するWebサイトを指定します。この設定は、グローバルにしてすべてのWebサイトで有効にすることも、ローカルにしてそのWebサイトのみで有効にすることもできます。指定したサイトに関連付ける参照をAccess Managerがhttpd.configファイルからロードする際、仮想ホスト、特定のディレクトリまたはファイルに限定することができます。
Webgateを特定のターゲットに関連付けるには、次のディレクティブをhttp.confファイルに移動します。
AuthType Oblix require valid-user
これらのディレクティブを、ApacheがリクエストのたびにWebgateを使用するように指示するブロックの中に置きます。また、これらのディレクティブを、Webgateがコールされるタイミングを制限するブロックに移動することもできます。次に、LocationMatchディレクティブを、VirtualHostディレクティブの後に置く例を示します。
DocumentRoot /usr/local/apache/htdocs/myserver ServerName myserver.example.net AuthType Oblix require valid-user
LocationMatchブロックをVirtualHostディレクティブに移動した後は、Webゲートはその仮想ホストに対してのみ動作します。LocationMatchブロックは、必要な数の仮想ホストに対して追加できます。次に、1つの仮想サーバーの保護方法の例を示します。
ServerAdmin webmaster@example.net
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
ProxyRequests On
SSLEngine on
SSLCACertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/intermediateca.cer
SSLCertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/sslcert_myapps_ptcweb32.cer
SSLCertificateKeyFile Z:/Apps/sslcert_exampleapps_ptcweb32/sslcert_myapps_ptcweb32.key
ErrorLog logs/proxysite1_log
CustomLog logs/proxysite1_log common
ProxyPass /https://apps.example.com/
ProxyPassReverse /https://apps.example.com/
ProxyPass /bkcentral https://apps.example.com/bkcentral
ProxyPassReverse /bkcentral https://apps.example.com/bkcentral
ProxyPass /NR https://apps.example.com/NR
ProxyPassReverse /NR https://apps.example.com/NR
AuthType Oblix
require valid-user
#*** BEGIN Oracle Access Manager Webgate Specific ****
LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll
WebgateInstalldir Z:/apps/Oracle/WebComponent/access
WebgateMode PEER
SetHandler obwebgateerr
SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none
SSLLog logs/SSL.log
SSLLogLevel info
# You can later change "info" to "warn" if everything is OK
Oracle Access Managementコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。エージェントに登録されるアプリケーション・ドメインでは、ホスト識別子が自動的に使用されます。
管理者はコンソールを使用して、ホスト識別子を作成および管理できます。Oracle Access Managementコンソール内で、ホスト識別子は、「ポリシー構成」タブのナビゲーション・ツリーの「共有コンポーネント」に編成されます。管理者は、新しいホスト識別子定義の手動の作成、定義の変更、定義の削除またはテンプレートとして使用する既存の定義のコピーを実行できます。コピーの名前は、元の定義名に基づきます。たとえば、host3という定義をコピーする場合、コピー名はcopy of host3になります。
図22-4は、ホストの正規名や、ユーザーが同じホストの指定に使用できるその他すべての名前を入力するための、入力コンソールの「ホスト識別子の作成」構成ページを示しています。
ノート:
各ホスト識別子を一意にする必要があります。同じホスト名およびポートは他のホスト識別子定義で使用できません。
表22-4は、ホスト識別子の定義を示しています。
表22-4 ホスト識別子の定義
| プロパティ | 説明 |
|---|---|
名前 |
この定義の一意の名前。大文字および小文字の英字のみ使用します。句読点および特殊文字は使用できません。 |
説明 |
この構成の使用を示す200文字までのオプションの説明。 |
ホスト名組合せ |
|
有効な管理者の資格証明を持つユーザーは、ホスト識別子の定義を手動で作成できます。マップされているホスト識別子がないホストにアプリケーションおよびリソースを手動で追加した場合に必要になります。エージェントの登録時に「ポリシーの自動作成」を選択すると、この作業は自動的に実行されます。
テンプレートとして使用する既存の定義をコピーする場合、コピーのすべての一意の識別子を変更する必要があります。
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「ホスト識別子」をクリックします。
「ホスト識別子の作成」をクリックします。
「ホスト識別子の作成」ページで、次の情報を入力します。
名前
説明
ホスト名組合せ: 「操作」リストのホスト名とポートのバリエーションを追加(または削除)します。
追加: 「追加」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。
削除: ホスト名をクリックし、「削除」ボタンをクリックして削除します。
必要に応じてステップ3cを繰り返して、ユーザーがアクセスできるこのホストのすべてのバリエーションを識別します。
「適用」をクリックして新しい定義を送信します(または変更を適用しないでページを閉じます)。
「確認」ウィンドウを閉じて、新しい定義が結果表にリストされていることを確認します。
有効な管理者の資格証明を持つユーザーは、特定のホスト識別子を検索できます。
ノート:
ホスト識別子がリソースに関連付けられている場合、削除しようとすると、アラートが表示され、確認を求められます。関連付けられていない場合、ホスト識別子は正常に削除されます。
関連項目:
有効な管理者の資格証明を持つユーザーは、ホスト識別子の定義を変更できます。
これには、個々のホスト識別子の定義の追加、変更または削除が含まれます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加する場合、既存のホスト識別子定義を変更して新しいホスト名バリエーションを追加する必要がある場合があります。
前提条件: ホスト識別子を参照するインベントリ・アプリケーション・ドメイン
ノート:
設定の参照後、ページを閉じるか、必要に応じて設定を変更できます。
関連項目:
「ホスト識別子定義の検索」の説明に従って、必要なホスト識別子を検索して表示します。
「ホスト識別子」ページで、必要に応じて情報を変更します(表22-4)。
名前
説明
ホスト名組合せ: 表示される表で次の操作を実行します。
ホスト名バリエーションの追加(+): 「追加」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。
ホスト名バリエーションの削除(X): ホスト名をクリックし、「削除」ボタンをクリックして削除します。
必要に応じてステップ3cを繰り返して、バリエーションを追加または削除します。
「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じて、終了する場合はページを閉じます。
有効な管理者の資格証明を持つユーザーは、ホスト識別子の定義全体を削除できます。リソースで使用されているホスト識別子を削除しようとすると、検証エラーが発生します。
ホスト識別子がリソースに関連付けられている場合、アラートが表示されます。関連付けられていない場合、ホスト識別子は削除されます。
前提条件
アプリケーション・ドメインの各リソースは、特定のホスト識別子に関連付けられます。ホスト識別子を削除する場合、そのホスト識別子を使用するアプリケーション・ドメインのリソース定義を先に変更する必要があります。
関連項目:
既存の定義から単一のホスト識別子を削除する場合は、「ホスト識別子定義の表示または編集」を参照してください。
