12 ポリシー・コンポーネントの管理

共有ポリシー・コンポーネントをOAMポリシーで使用できます。この章では、管理者によるポリシー・コンポーネントの管理方法について説明します。

この章の内容は次のとおりです。

• 前提条件

• ポリシー・コンポーネント管理の概要

• リソース・タイプの管理

• ホスト識別子の管理

• 認証スキームの管理

• 暗号化Cookieのチャレンジ・パラメータの構成

前提条件

Oracle Access Managerコンソールおよび少なくとも1つのOAMサーバーがWebLogicサーバー・ドメインにインストールおよび実行されている必要があります。

この章のアクティビティを実行する前に、次の内容を確認することをお薦めします。

• ポリシー・モデルおよびコンポーネントの詳細は、「OAM 11gポリシー・モデルの概要」を参照してください。

• 現在のポリシー・モデルと他のモデルの比較を確認するには、「OAM 11gポリシー・モデルとOAM 10gモデルの比較」を参照してください。

• Oracle Access Managerコンソールおよびコントロールの詳細は、第3章「共通の管理およびナビゲーションの基礎」を参照してください。

ポリシー・コンポーネント管理の概要

この項では、Oracle Access Manager 11gポリシー・モデルおよびそのグローバル・コンポーネントを説明します。

Oracle Access Manager 11gポリシー・モデルは、OAMアプリケーション・ドメインのコンテキスト内で認証および認可サービスを提供します。ポリシー・モデルは、全体のシステム構成の一部である外部ユーザー・アイデンティティ・ストアおよび認証モジュールに基づいています。

注意: 以前のリリースのOracle Access Managerでは、OAMポリシー・ドメインのコンテキスト内で認証および認可サービスを提供していました。OracleAS SSO 10gは認証のみ提供します。

図12-1は、Oracle Access Manager 11gのポリシー・モデル内の異なる要素を示しています。Oracle Access Manager 11gポリシー・モデルの最上位レベルの構造は、OAMアプリケーション・ドメインです。図の後に詳細があります。

図12-1 ポリシー・コンポーネント: アプリケーション・ドメインとの関係

「図12-1 ポリシー・コンポーネント: アプリケーション・ドメインとの関係」の説明

ポリシー・コンポーネント: アプリケーション・ドメインで使用できるグローバル認証スキーム、リソース・タイプおよびホスト識別子。ポリシー・コンポーネントの管理については、この章全体で説明します。

アプリケーション・ドメイン: リソース(または一連のリソース)および特定のリソースにアクセス可能なユーザーを指示する関連付けられた認証および認可ポリシーの論理コンテナ。アプリケーション・ドメインのサイズおよび数は、管理者に依存します。詳細は、第13章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。

リソース・タイプの管理

この項の内容は次のとおりです。

• リソース・タイプおよびその使用について

• リソース・タイプ・ページについて

• 特定のリソース・タイプの検索

リソース・タイプおよびその使用について

リソースをアプリケーション・ドメインに追加する場合、管理者は定義されたリソース・タイプのリストから選択して、特定のURLを入力する必要があります。

Oracle Access Manager 11g (11.1.1.5)では、リソース・タイプを作成/編集/削除するコマンド・ボタンは無効です。Oracle提供のリソース・タイプには、次が含まれます。HTTPタイプ・リソースには、ホスト識別子を含めます。HTTP以外のリソース・タイプには、次のタイプ名を使用します。

• HTTP

• TokenServiceRP

• wl_authen

HTTP: デフォルトのリソース・タイプがHTTPおよびHTTPSプロトコルと一緒に使用されます。HTTPリソース・タイプに関連付けられた操作を管理者が定義する必要はありません。かわりに、作成されてリソースに適用されたポリシーがすべての操作に適用されます。

HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加する必要があります。

wl_authen: WebLogic認証スキームを表すリソース。wl_authenというHTTP以外のリソース・タイプをWebLogicコンテナでデプロイされたリソースとともに使用できます。wl_authenリソース・タイプには、カスタム・アクセス・クライアントが必要です。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。

TokenServiceRP: トークン・サービスのリライイング・パーティを表すリソース。

HTTP以外のリソース・タイプに関連付けられたホスト識別子はありません。HTTP以外のリソースをアプリケーション・ドメインに追加する場合、管理者はタイプ名をポインタとして「リソースURL」フィールドに入力する必要があります。名前とホスト識別子は一致しません。これは、相対的なHTTP URLではありません。

リソース・タイプ・ページについて

Oracle Access Managerコンソールでは、図12-2に示すように、「ポリシー構成」タブでリソース・タイプが他のコンポーネントとともに編成されます。左側のナビゲーション・ツリーは、インターネット・プロトコルのHTTPおよびWebLogicコンテナにデプロイされたリソースのwl_authenの2つのデフォルトのリソース・タイプを示しています。

図12-2 デフォルトのwl_authenリソース・タイプ定義

「図12-2 デフォルトのwl_authenリソース・タイプ定義」の説明

HTTPリソース・タイプは、Oracle Access Manager 11gで保護されたWebアプリケーションに使用されます。

wl_authenリソース・タイプは、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で示すように、Oracle Access Manager 11gおよび次のOAM認証プロバイダ構成のいずれかと組み合せたFusion Middlewareアプリケーション・シナリオで使用されます。

• オーセンティケータ

• Oracle Web Services Managerを使用するアイデンティティ・アサータ

図12-3で説明するように、TokenServiceRPリソース・タイプはトークン・サービス・リライイング・パーティを表すために使用されます。詳細は、「TokenServiceRPタイプのリソースの管理」を参照してください。

図12-3 TokenServiceRP

「図12-3 TokenServiceRP」の説明

表12-1は、各リソース・タイプ定義の要素を示しています。

表12-1 リソース・タイプの定義

要素	説明
名前	必須。最大30文字の英数字の一意の名前。 注意: HTTP以外のリソース・タイプ名とホスト識別子は一致しません。
説明	オプション。このフィールドを使用して、このリソース・タイプの目的を最大200文字の英数字で説明します。 たとえば、WebLogic認証スキームを表すリソースなどです。

次に、リソース・タイプの作成、変更および削除方法を説明します。

特定のリソース・タイプの検索

有効な管理者の資格証明を持つユーザーは、次の手順を使用してHTTP以外のリソース・タイプを検索できます。

関連項目: コンソールを使用したポリシー要素検索の実行

リソース・タイプを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「リソース・タイプ」を選択し、検索するリソース・タイプの名前を(ワイルド・カード(*)の使用は任意)入力して、「検索」をクリックします。次に例を示します。

   h*
   

   または、目的のアプリケーション・ドメインに移動して、「リソース」ノードを開いてドメインのコントロールを表示し、リストからリソース・タイプを選択してから「検索」をクリックします。

3. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

   • 編集または表示: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

   • 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

   • 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

   • 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

4. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

ホスト識別子の管理

この項では、ホスト識別子とその使用方法およびホスト識別子の作成、変更または削除方法を説明します。次に内容を示します。

• ホスト識別子について

• 仮想Webホスティングについて

• ホスト識別子ページについて

• ホスト識別子の作成

• ホスト識別子定義の検索

• ホスト識別子定義の表示または編集

• ホスト識別子定義の削除

ホスト識別子について

ポリシーは、コンピュータ・ホストのリソースを保護します。Oracle Access Manager内で、ホスト識別子を使用してコンピュータ・ホストを個別に指定します。

定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。

登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、OAMはリソースを保護するポリシーを適用できます。

Oracle Access Managerコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。アプリケーションおよびリソースがマップされたホスト識別子のないホストに存在する場合、管理者はホスト識別子を手動で追加できます。また、管理者は、新しいホスト名バリエーションに追加するために既存のホスト識別子を変更できます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加するには、新しいホスト名バリエーションが必要です。

詳細は、次の項を参照してください。

• ホスト識別子の使用方法

• ホスト識別子のガイドライン

• ホスト識別子のバリエーション

ホスト識別子の使用方法

設計時に、特定のアプリケーション・ドメインに属するリソースを定義する場合、ホスト識別子を使用できます。リソースのホスト識別子(HTTP)またはタイプ(HTTP以外)を使用して、リソースをスコープします。この組合せにより、Oracle Access Managerで一意に識別されます。

注意: 各リソースは、すべてのアプリケーション・ドメインで一意である必要があります。各リソースおよびホスト識別子の組合せは、すべてのアプリケーション・ドメインで一意である必要があります。

実行時の使用方法

実行時に、OAMエージェントからのアクセス問合せのWebサーバー・ホスト情報がホスト識別子にマップされ、ユーザーがアクセスしているリソースに関連付けられます。OAMエージェントは、次のいずれかの方法でWebサーバー・ホスト情報を取得します。

• 仮想Webホスティング・サポートに優先ホスト・パラメータが構成されている場合(「仮想Webホスティングについて」を参照してください)、指定されたリクエストのWebサーバー・ホスト情報がWebサーバーから取得されます。

• 優先ホスト・パラメータで直接Webサーバー・ホスト情報を指定する場合、Webサーバー固有のホスト情報と関係なく常に使用されます。

これにより、Webサーバーの現在のデプロイメントと一致するホスト名ではなくホスト識別子の論理ホスト名でリソースを指定できます。

たとえば、aseng-wikiにアクセスするユーザーは、次の内容を入力します。

http://corp-wiki.uk.mycompany.com/mywikipage

この「mywikipage」はリソースURLで、「corp-wiki.uk.mycompany.com」はホストです。このホストおよびポート(ポートは80)を照合して、ホスト識別子を示します。

優先ホスト

通常、OAMエージェントの優先ホスト文字列を設定して、Webサーバー・ホスト情報を取得します。エージェントが複数の仮想ホストをアクティブに保護する場合、この文字列をserver_nameに設定して、実際のリクエスト・ホスト名がWebサーバーのリクエスト・オブジェクトから正しく選択されていることを確認します。詳細は、「仮想Webホスティングについて」を参照してください。

ホストの認証および認証スキームのチャレンジ・リダイレクト

ユーザーが保護されたリソースURLにアクセスしようとすると、認証スキームの「チャレンジ・リダイレクト」フィールドに指定されたサーバーにリダイレクトします。認証チャレンジを別のホストで処理する場合、そのホストの名前を定義して、「ホスト識別子」リストで使用可能にする必要があります。たとえば、ユーザーが認証用のSSL対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。

注意: 認証スキームの「チャレンジ・リダイレクト」フィールドにホスト名を入力する場合、ホスト識別子として定義する必要があります。

ホスト識別子のガイドライン

各ホスト識別子を定義して、1つ以上のWebサーバー・ホストを表すことができます。ホスト識別子のいくつかの重要なガイドラインは、次のとおりです。

• 各ホスト名を一意にする必要があります。

• 各ホスト名:ポート・ペアを一意にする必要があります。

• 各ホスト名:ポート・ペアは、1つのホスト識別子にのみ属する必要があります。

• 各ホスト名:ポート・ペアは、エンド・ユーザーのエントリと完全に一致する必要があります。

• ホスト識別子名とHTTP以外のリソース・タイプ名は一致しません。

• 各リソースおよびホスト識別子の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。

詳細は、「ホスト識別子のバリエーション」を参照してください。

ホスト識別子のバリエーション

すべての使用可能なホスト名バリエーションを定義してWebサーバー・ホストのアイデンティティを簡易化するには、ホスト識別子を使用します。ホスト識別子は、すべてのURLアドレス指定方法のリストで構成されます。Oracle Access Managerで保護する各Webサイトまたは仮想Webサイトにホスト識別子を構成する必要があります。

Oracle Access Managerに対するWebサーバー・ホストの識別には、たとえば、コンピュータ名やIPアドレスを指定するなど、様々な方法があります。Webサーバー・ホストのアドレス指定方法の例を次に示します。

• site.com

• site.com:80

• www.site.com

• www.site.com:80

• 216.200.159.58

• 216.200.159.58:80

仮想Webホスティングについて

複数の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仮想ホストのOracle Access Managerにリダイレクトします。資格証明コレクタは、リソースの認証スキームのチャレンジURLパラメータを確認し、X509認証のHTTPS仮想ホストにリダイレクトします。

リバース・プロキシの背後へのWebgateの配置

OAM 10g Webgateは、OAM 11gのリバース・プロキシとともに使用できます。この項では、この方針の長所と短所について説明します。

長所:

• リクエストがすべてプロキシを経由するかぎり、すべてのWebコンテンツを単一の論理コンポーネントから保護できます。

  これは、Oracle 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://hostname.domain:[port]/path/resource)は使用しないことをお薦めします。

  絶対URLは、リバース・プロキシの背後にデプロイされると、エンドユーザーのブラウザ上ではリンク切れになる可能性があります。

Apache以外のWebサーバーの仮想ホストの構成

10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。

Apacheベースのサーバー以外のほとんどのWebサーバーでは、「優先ホスト」の値をHOST_HTTP_HEADERに設定する必要があります。これにより、ユーザーのブラウザからリクエストが送信されると、Webgateにより、「優先ホスト」の値がリクエストのホスト値に設定されます。たとえば、次に示すように、ユーザーがURLに文字列myweb2を入力したとします。

http://myweb2

Webサーバーで、いずれかのWebサイトのホスト名がmyweb2であれば、その一致する仮想サイトでリクエストが処理されます。

展開された10g Webgate登録ページの「優先ホスト」フィールドで、次のように入力します。

HOST_HTTP_HEADER

IIS仮想ホスティング: IISコンソールから、各仮想Webサイトを構成して次のフィールドを含める必要があります。

• ホスト・ヘッダー名

• IPアドレス

• ポート

関連項目: http://www.simpledns.com/kb.aspx?kbid=1149 http://support.microsoft.com/kb/q190008/

仮想ホスト、ディレクトリまたはファイルとのApache用Webgateの関連付け

10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。

ApacheベースのWebサーバー(Apache、Apache 2、IBM HTTP Server、Oracle HTTP Serverなど)では、「優先ホスト」の値をSERVER_NAMEに設定する必要があります。

注意: Apacheベースのサーバー以外のホストでは、SERVER_NAMEという値はサポートされません。この値をApacheベース以外のサーバーに設定すると、ユーザーはそのWebサーバーのWebgateで保護されるリソースにアクセスできません。かわりに、ユーザーはWebgate構成が正しくないことを示すエラーを受け取ります。 「ServerName」ディレクティブは、hostNameとともに明示的に7777に設定する必要があります。これは「Listen」ディレクティブが正しく設定されているかどうかには関係ありません。サーバーは、自己識別のためにこの値を明示的に要求する場合がありますが、通常は自動的に自己識別が可能です。

シングル・サインオンでApacheベースのリバース・プロキシを使用する場合、Webサーバーの構成ファイル(httpd.configなど)でApacheサーバーで実行するWebサイトを指定します。この設定は、グローバルにしてすべてのWebサイトで有効にすることも、ローカルにしてそのWebサイトのみで有効にすることもできます。Oracle Access Managerをロードする際のhttpd.configファイル内への参照は、特定のサイト、仮想ホスト、ディレクトリまたは個別ファイルに関連した参照のみを行うように制限できます。

Webgateを特定のターゲットに関連付けるには、次のディレクティブをhttp.confファイルに移動します。

AuthType Oblix
require valid-user

これらのディレクティブを、ApacheがリクエストのたびにWebgateを使用するように指示するブロックの中に置きます。また、これらのディレクティブを、Webgateがコールされるタイミングを制限するブロックに移動することもできます。次に、LocationMatchディレクティブを、VirtualHostディレクティブの後に置く例をあげます。

  DocumentRoot /usr/local/apache/htdocs/myserver    
  ServerName myserver.example.net    
  AuthType Oblix       
  require valid-user    

前述のLocationMatchブロックを次のようにVirtualHostディレクティブの後に移動すると、Webgateはその仮想ホストに対してのみ動作します。LocationMatchブロックは、必要な数の仮想ホストに対して追加できます。次に、1つの仮想サーバーの保護方法の例を示します。

ServerAdmin [e-mail]
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
    ProxyRequests On
    SSLEngine on
    SSLCACertificateFile Z:/Apps/sslcert_myapps_ptcweb32/intermediateca.cer
    SSLCertificateFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.cer
    SSLCertificateKeyFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.key
    ErrorLog logs/proxysite1_log
    CustomLog logs/proxysite1_log common
    ProxyPass /https://apps.example.com/
    ProxyPassReverse /https://apps.example.com/
    ProxyPass /bkcentral https://apps.example.com/bkcentral
    ProxyPassReverse /bkcentral https://apps.example.com/bkcentral
    ProxyPass /NR https://apps.example.com/NR
    ProxyPassReverse /NR https://apps.example.com/NR
    
      AuthType Oblix
      require valid-user
    
#*** BEGIN Oracle Access Manager Webgate Specific **** 
 
LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll
WebgateInstalldir Z:/apps/Oracle/WebComponent/access
WebgateMode PEER
 
 SetHandler obwebgateerr
 
SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none
 
SSLLog logs/SSL.log
SSLLogLevel info
# You can later change "info" to "warn" if everything is OK

ホスト識別子ページについて

Oracle Access Managerコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。エージェントに登録されるアプリケーション・ドメインでは、ホスト識別子が自動的に使用されます。

管理者はコンソールを使用して、ホスト識別子を作成および管理できます。Oracle Access Managerコンソール内で、ホスト識別子は、「ポリシー構成」タブのナビゲーション・ツリーの「共有コンポーネント」に編成されます。管理者は、新しいホスト識別子定義の手動の作成、定義の変更、定義の削除またはテンプレートとして使用する既存の定義のコピーを実行できます。コピーの名前は、元の定義名に基づきます。たとえば、host3という定義をコピーする場合、コピー名はcopy of host3になります。

図12-4は、コンソールの通常のホスト識別子構成ページを示しています。ここでは、ホストの正規の名前およびユーザーが同じホストを表現できる他のすべての名前を入力します。

注意: 各ホスト識別子を一意にする必要があります。同じホスト名およびポートは他のホスト識別子定義で使用できません。

図12-4 「ホスト識別子」ページ

「図12-4 「ホスト識別子」ページ」の説明

表12-2は、ホスト識別子の定義を示しています。

表12-2 ホスト識別子の定義

プロパティ	説明
名前	この定義の一意の名前。大文字および小文字の英字のみ使用します。句読点および特殊文字は使用できません。
説明	この構成の使用を示す200文字までのオプションの説明。
操作	ホスト名: ユーザーがアプリケーションにアクセスする場合に使用する可能性のある様々なホスト名または組合せのリスト。 関連項目: 「ホスト識別子のバリエーション」および「ホスト識別子のガイドライン」 ポート: 各ホストまたは組合せで使用されるWebサーバー・ポート

ホスト識別子の作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を手動で作成できます。マップされているホスト識別子がないホストにアプリケーションおよびリソースを手動で追加した場合に必要になります。エージェントの登録時に「ポリシーの自動作成」を選択すると、この作業は自動的に実行されます。

注意: テンプレートとして使用する既存の定義をコピーする場合、コピーのすべての一意の識別子を変更する必要があります。

関連項目: 「ホスト識別子について」 「仮想Webホスティングについて」

ホスト識別子を手動で作成するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」を拡張します。

2. 「ホスト識別子」をクリックし、ツール・バーの「作成」コマンド・ボタンをクリックします。

   または、「ホスト識別子」ノードを拡張して、テンプレートとして使用する定義の名前をダブルクリックし、「複製」ボタンをクリックしてcopyofnameという名前のコピーを作成します。

3. 「ホスト識別子」ページで、次の内容を入力します。

   1. 名前

   2. 説明

   3. 操作: 「操作」リストのホスト名およびポート・バリエーションを追加(または削除)します。

      追加: プラス記号(+)をクリックして、新しいホスト名およびポートの組合せを入力します。

      削除: ホスト名をクリックし、「削除」ボタンをクリックして削除します。

4. 必要に応じて手順3cを繰り返して、ユーザーがアクセスできるこのホストのすべてのバリエーションを識別します。

5. 「適用」をクリックして新しい定義を送信します(または変更を適用しないでページを閉じます)。

6. 確認ウィンドウを閉じて、新しい定義がナビゲーション・ツリーにリストされていることを確認します。

ホスト識別子定義の検索

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定のホスト識別子を検索できます。

関連項目: 「ポリシー構成検索コントロールについて」

ホスト識別子を検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「ホスト識別子」を選択して、検索を定義します。

3. テキスト・フィールドに検索条件を(ワイルド・カード(*)の使用は任意)入力します。次に例を示します。

   my_h*
   

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

   • 編集または表示: ツール・バーの「編集」ボタンをクリック(または結果表内の名前をダブルクリック)して、構成ページを表示します。

   • 削除: ツール・バーの「削除」ボタンをクリックして、結果表で選択されたアイテムを削除し、「確認」ウィンドウで削除を確認します。

   • 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

   • 表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

ホスト識別子定義の表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を変更できます。これには、個々のホスト識別子の定義の追加、変更または削除が含まれます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加する場合、既存のホスト識別子定義を変更して新しいホスト名バリエーションを追加する必要がある場合があります。

前提条件: ホスト識別子を参照するインベントリ・アプリケーション・ドメイン

注意: 設定の参照後、ページを閉じるか、必要に応じて設定を変更できます。

関連項目: 「ホスト識別子ページについて」

ホスト識別子を表示または変更するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

   1. 「共有コンポーネント」ノード

   2. 「ホスト識別子」ノード

2. 目的の定義名をダブルクリックします。

3. 「ホスト識別子」ページを表示し、必要に応じて情報を変更します(表12-2を参照してください)。

   1. 名前

   2. 説明

   3. 操作: 「操作」リストのホスト名およびポート・バリエーションを追加または削除します。

      プラス記号(+)をクリックして、新しいホスト名およびポートの組合せを追加します。

      既存のホスト名をクリックし、「削除」ボタンをクリックして削除します。

4. 必要に応じて手順3cを繰り返して、バリエーションを追加または削除します。

5. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

6. 確認ウィンドウを閉じて、終了する場合はページを閉じます。

ホスト識別子定義の削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の全体の定義を削除できます。リソースで使用されているホスト識別子を削除しようとすると、検証エラーが発生します。

前提条件

アプリケーション・ドメインの各リソースは、特定のホスト識別子に関連付けられます。ホスト識別子を削除する場合、ホスト識別子を使用するアプリケーション・ドメインのリソース定義を最初に変更する必要があります。

関連項目: 既存の定義から単一のホスト識別子を削除する場合は、「ホスト識別子定義の表示または編集」を参照してください。

ホスト識別子を削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

   1. 「共有コンポーネント」ノード

   2. 「ホスト識別子」ノード

2. オプション: リストで、目的の名前をダブルクリックして定義を表示し、ページを閉じます。

3. ナビゲーション・ツリーで、目的の定義名をクリックします。

4. ツール・バーの「削除」ボタンをクリックして、確認ウィンドウで削除を確認します。

5. ナビゲーション・ツリーを確認して、定義が削除されたことを確認します。

認証スキームの管理

この項の内容は次のとおりです。

• 認証スキーム・ページについて

• 認証スキームの作成

• 認証スキームの表示または編集

• 認証スキームの検索

• 認証スキームの削除

認証スキーム・ページについて

リソースまたはリソースのグループへのアクセスは、認証スキームという単一の認証プロセスで制御できます。認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。各認証スキームには、定義済の認証モジュール(「認証モジュールの管理」に示すような標準またはカスタムのモジュール)も含まれている必要があります。

コンソールまたはリモート登録ツールを使用してパートナを登録する場合、作成されるアプリケーション・ドメインは、デフォルト・スキームとして設定される認証スキームを使用するポリシーでシードされます。ポリシー作成中に使用されるデフォルトとして、既存の認証スキームを選択できます。

新しい認証スキームの作成、テンプレートとして使用する既存の定義のコピー、定義の変更または定義の削除も実行できます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、KerberosSchemeというスキームをコピーする場合、コピー名はcopyofKerberosSchemeになります。

すべての認証スキームには、異なる値を使用した同じ要素が含まれます。図12-5は、例としてデフォルトのLDAPSchemeページを示しています。「認証スキーム」ナビゲーション・ツリーは、提供される他のデフォルト・スキームを示しています。

図12-5 デフォルトのLDAPSchemeページ

「図12-5 デフォルトのLDAPSchemeページ」の説明

表12-3は、認証スキームのそれぞれの要素および値の情報を示しています。「デフォルトとして設定」ボタンを使用して、これをデフォルト・スキームにします。

表12-3 認証スキームの定義

要素	説明
名前	ナビゲーション・ツリーに表示されるこのスキームの一意の名前。 関連項目: 「事前構成済認証スキーム」
説明	このスキームの使用を示す200文字までのオプションの説明。
認証レベル	認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。 信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。 注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表13-1「リソース定義の要素」を参照してください。 注意: 指定されたレベルのリソースにユーザーが認証された後、リソースが元のリソースと同等またはそれ以下の信頼レベルである場合に同じアプリケーション・ドメインまたは異なるアプリケーション・ドメインの他のリソースでユーザーが自動的に認証されます。 関連項目: 「マルチレベル認証について」
デフォルト	「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックス。
チャレンジ・メソッド	次の選択可能な項目から1つのチャレンジ・メソッドを選択する必要があります。 フォーム Basic(LDAP) X509(証明書) WNA(Windows固有の認証) なし DAP OAM10g 関連項目: 「チャレンジ・メソッドについて」
チャレンジ・リダイレクトURL	処理するためにユーザー・リクエストを別のサーバーにリダイレクトする場合の「チャレンジ・リダイレクト」フィールドに指定されたサーバーのURL。 関連項目: 「ホスト識別子について」
認証モジュール	ユーザーに資格証明を要求するために使用する事前構成済認証モジュール。 LDAP(「LDAP認証モジュール」ノードの下) LDAPNoPasswordAuthModule Kerberosプラグイン(「認証モジュール」の「カスタム認証モジュール」の下) LDAPプラグイン(「認証モジュール」の「カスタム認証モジュール」の下) X509プラグイン(「X509認証モジュール」ノードの下) 「認証モジュールの管理」も参照してください。
チャレンジ・パラメータ	サポートされているチャレンジ・パラメータの詳細は、「認証スキームのチャレンジ・パラメータについて」を参照してください。
フォーム、X509またはDAPチャレンジ・メソッドを使用したスキーム	フォーム、X509またはDAPチャレンジ・メソッドを使用したスキームのみ、これらの追加要素が含まれます。他のスキームは、変更する必要がないデフォルトを使用します。
チャレンジURL	資格証明コレクションのために資格証明コレクタがリダイレクトするURL。 フォーム・ベースの即時利用可能な認証スキーム(LDAPSchemeおよびLDAPNoPasswordValidationScheme)の場合、デフォルトのチャレンジURLは「/pages/login.jsp」です。最後のURLを作成するには、コンテキスト・タイプおよびコンテキスト値を使用します。
コンテキスト・タイプ	次の使用可能な値に基づいて資格証明コレクタの最後のURLを作成するために使用されます。 デフォルト: コンテキスト値を使用して、資格証明コレクションのために送信する最後のURLを作成します。たとえば、チャレンジURLが「/pages/login.jsp」、コンテキスト値が/oamの場合、サーバーが資格証明コレクションのために「/oam/pages/login.jsp」に送信します。 customWar: カスタマイズされた資格証明コレクタ・ページ「customlogin.jsp」が同じドメイン内のWARファイル(コンテキスト・ルートの「custom」を使用)にデプロイされる場合、資格証明の収集にこの値を使用する必要があります。資格証明を収集するためにサーバーがWebアプリケーション・ページ「/custom/customlogin.jsp」に送信するには、次の値を設定します。 challenge_url = "/customlogin.jsp" contextType="customWar" contextValue="/contextroot of custom application" customHtml: カスタムHTML資格証明コレクタ・ページ。アプリケーションにアクセスできる場所にこのファイルを配置できます。サーバーがhtmlファイルを読み取ってページをレンダリングするために提供されるカスタム・サーブレットに送信するには、次の値を設定します。 challenge_url = "/CustomReadServlet" contextType="customHtml" contextValue="html file location" 外部: ログイン・ページが外部の場合、アプリケーションにアクセスできる場所にファイルを配置できます。資格証明コレクションのためにサーバーがチャレンジURL(外部資格証明コレクタ・ページの完全修飾URL)にリダイレクトするには、次の値を設定します。ユーザー名およびパスワードが外部フォーム(HTMLまたはjsp)で収集され、OAMサーバーに送信されます。 challenge_url = "/http://host:port/externallogin.jsp" contextType="external" contextValue=Not applicable 関連項目: 「カスタム・ログイン・ページについて」
コンテキスト値	資格証明コレクタの最後のURLを作成するために使用されます。デフォルト値は/oamです。

カスタム・ログイン・ページについて

フォーム、X509またはDAPチャレンジ・メソッドを使用したスキームのみ、表12-3の最後に示されている追加要素が含まれます。すべてのカスタム・ログイン・ページで次の要件を満たす必要があります。

• カスタム・ログイン・ページには、2つのフォーム・フィールド(ユーザー名およびパスワード)が必要です。Oracle Access Managerは、2つのフィールドを使用した認証フォームのみサポートします。

• CustomWarおよび外部コンテキスト・タイプでは、次の2つのタスクを実行するカスタム・ログイン・ページ内のロジックが必要になります。

  • Oracle Access Managerサーバーから受け取ったページにリクエストIDを送信します。たとえば、String reqId = request.getParameter("request_id"); <input type="hidden" name="request_id" value="<%=reqId%>">などです。

  • OAMサーバーにエンド・ポイント「/oam/server/auth_cred_submit」を戻します。たとえば、<form action="/oam/server/auth_cred_submit">または「http://oamserverhost:port/oam/server/auth_cred_submit」などです。

詳細は、次の各項を参照してください。

• 事前構成済認証スキーム

• チャレンジ・メソッドについて

• 認証モジュールについて

• マルチレベル認証について

事前構成済認証スキーム

表12-4は、Oracle Access Manager 11gで使用できる事前構成済認証スキームおよびそれぞれの固有の詳細を示しています。チャレンジ・パラメータの詳細は、表12-5を参照してください。

表12-4 事前構成済認証スキーム

スキーム名	指定	目的
AnonymousScheme	認証レベル: 0 チャレンジ・メソッド: なし 認証モジュール: AnonymousModule	特定のOracle Access Manager URLを保護されていない状態のままにするため、ユーザーは要求なしでURLにアクセスできます。ユーザーが要求されないので、資格証明を入力する必要はありません。 注意: 認証レベル0は、公開ページに使用されます。カスタム認証スキームにレベル0を使用しないことをお薦めします。 付記: リソースがAnonymousSchemeによって保護されている場合、セッション検索では表示されません。
BasicScheme	認証レベル: 1 チャレンジ・メソッド: Basic 認証モジュール: LDAP	ほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。 注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。
BasicSessionlessScheme	認証レベル: 1 チャレンジ・メソッド: Basic 認証モジュール: LDAP	主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 チャレンジ・パラメータ: CookieLessMode=true 注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。
FAAuthScheme	認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト: customWar コンテキスト値: /fusion_apps	Fusion Applicationsを保護します。
KerbScheme	認証レベル: 2 チャレンジ・メソッド: WNA 認証モジュール: Kerberos	Active DirectoryのWindows固有の認証チャレンジ・メソッドおよび有効なWNA資格証明に基づいて、ほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。
LDAPNoPasswordValidationScheme	認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAPNoPasswordAuthModule コンテキスト・タイプ: デフォルト コンテキスト値: /oam 注意: LDAPNoPasswordAuthModuleは、DAP(アサータ)メカニズムに似ています。 この表の後半の「OAM10gScheme」も参照してください。	フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。 WebLogicコンテナのリソースを使用している場合にSSOのアイデンティティ・アサータとともに使用されます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
LDAPScheme	認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP	フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのOracle Access Manager関連リソース(URL)を保護します。
OAAMAdvanced	認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: 外部	外部コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの完全な統合が必要な場合、この認証スキームが使用されます。Webgateは、パートナのフロント・エンド処理を行う必要があります。
OAAMBasic	認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: デフォルト コンテキスト値: /oam	デフォルト・コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの基本統合が必要な場合、このスキームを使用する必要があります。ここでは、OTPなどの拡張機能はサポートされません。エージェントとしてmod_ossoを使用する場合、統合機能のようになります。 チャレンジ・パラメータ: oaamPostAuth=true oaamPreAuth=true
OAM10gScheme	認証レベル: 2 チャレンジ・メソッド: OAM10G 認証モジュール: LDAPNoPasswordAuthModule 注意: チャレンジ・メカニズムのOAM10Gは、DAP(アサータ)メカニズムと似ています。特にOSSOとOAM10gが共存する場合にOAM10gメカニズムを使用するので、他のスキームで使用しないでください。 この表の前半の「LDAPNoPasswordValidationScheme」も参照してください。	OAM 10gとの統合および共存を容易にします。共存モードでは、OAM 10gがオーセンティケータ、OAM 11gがアサータです。 このスキームは、新しいチャレンジ・メカニズムOAM10Gを使用します。
OAMAdminConsoleScheme	認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: デフォルト コンテキスト値: /oam	OAM管理コンソールの認証スキーム。
OIFScheme	認証レベル: 2 チャレンジ・メソッド: DAP 認証モジュール: DAP コンテキスト・タイプ: 外部	このスキームは、認証をOIFに委任します。その後にOAMサーバーによってアサートされるトークンをOIFが戻します。 委任認証プロトコル(DAP)チャレンジ・メソッドを使用して、認証をサード・パーティ(この場合はOIF)に委任します。 チャレンジ・パラメータ: TAPPartnerId=OIFDAPPartner
OIMScheme	認証レベル: 1 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: デフォルト コンテキスト値: /oam	デフォルト・コンテキスト・タイプでOracle Identity Manager関連リソースを保護します。 注意: OAMおよびOIMを統合する場合、OAMは、次のいずれかが検出された場合にユーザーの認証レベルをダウングレードします。 パスワード期限切れ 強制的なパスワードの変更 未実行のチャレンジ設定 このため、ユーザーがリダイレクトされるアイデンティティ管理(OIM)ページの必要な操作を実行した後にのみ、ユーザーはページにアクセスできます。 レベル1の場合、必要な操作の公開ページおよびOIMページにのみアクセスできます。 注意: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。
TAPScheme	認証レベル: 2 チャレンジ・メソッド: DAP 認証モジュール: DAP コンテキスト・タイプ: 外部	IAM Suiteアプリケーション・ドメイン、「Protected HigherLevel Policy」でIDM製品リソースにTAPSchemeを使用するには、「認証スキーム」の変更に加えて、次の構成を行う必要があります。 IAM Suiteアプリケーション・ドメイン、「Protected HigherLevel Policy」から、IAMSuiteAgent:/oamTAPAuthenticateを削除します。 IAM Suiteアプリケーション・ドメインで、LDAPSchemeを使用する新しい認証ポリシーを作成します。 新規作成したポリシーを使用して、IAMSuiteAgent:/oamTAPAuthenticateを保護します。 チャレンジ・パラメータ: TAPPartnerId=TAPPartnerName
X509Scheme	認証レベル: 2 チャレンジ・メソッド: X509 認証モジュール: X509	この認証スキームは、証明書ベースのユーザー識別方法です。この方法を使用するには、ユーザーのブラウザに証明書をインストールし、WebサーバーをSSL対応にする必要があります。

チャレンジ・メソッドについて

認証には、リソースへのアクセスのリクエスト、HTTPを介した資格証明の収集および資格証明の検証結果に基づくHTTPレスポンスの応答の実行時にユーザーが指定する必要がある資格証明の決定が含まれます。Oracle Access Manager 11gは、認証スキームに使用する次の資格証明チャレンジ・メソッドを提供します。

• フォーム

• Basic

• X509

• WNA

• なし

• DAP

• OAM10G

フォーム

この認証チャレンジは、ユーザー資格証明のために1つ以上のテキスト入力フィールドを含むHTMLフォームを使用します。通常のフォームベース・チャレンジで、ユーザーはフォームの2つのテキスト・ボックスにユーザー名とパスワードを入力します。最も一般的な資格証明の選択はユーザー名とパスワードですが、ユーザー名、パスワード、ドメインなどの任意のユーザー属性を使用できます。

「送信」ボタンを使用して、フォームのコンテンツを転送します。ユーザーが「送信」ボタンをクリックすると、フォーム・データがWebサーバーに転送されます。OAMおよびOSSOエージェントは、フォーム・データを捕捉および処理します。フォームで収集されたユーザー資格証明の検証時に、ユーザーが認証されます。

注意: このチャレンジ・メソッドは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに基づいています。

次のような理由でフォームベースの認証チャレンジを使用できます。

• 一貫性のあるユーザー操作性: フォームベースのログインおよび標準化されたログインを使用すると、ログインおよびログアウト機能のユーザー操作性がブラウザ間で一貫して実現します。

• カスタム・フォーム: 認証プロセスで組織のルック・アンド・フィールを適用できます。

  たとえば、Basic認証で使用される標準のユーザー名およびパスワード・ウィンドウのかわりに、カスタム・フォームに企業ロゴおよびようこそメッセージを含めることができます。

• 追加情報: ログイン時に追加情報を収集できます。

• 追加機能: 紛失したパスワードを管理するページのリンクなど、ログイン手順とともに追加機能を提供できます。

Basic

この組込みのWebサーバー・チャレンジ・メカニズムは、ユーザーにログインIDおよびパスワードの入力を要求します。提供された資格証明は、LDAPディレクトリ・サーバーのユーザー定義と比較されます。

注意: Basicチャレンジは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに基づいています。

X509

X509証明書チャレンジ・メソッドを使用する場合、認証を実行するには、エージェントを通じてOAMサーバーに送信するSSLを介したX.509デジタル証明書をユーザーのブラウザで指定する必要があります。

注意: X509は、X509Schemeのチャレンジ・メソッドです。ユーザーの組織は、証明書の取得方法を決定できます。

認証するX.509クライアント証明書の妥当性を確認するには、OAMプロキシおよびOAMサーバーで使用されるキーストアの信頼されたCAに対してX.509クライアント証明書を確認する必要があります。

OAM 11gに関連付けられているユーザー・アイデンティティ・ストアに対して、X.509証明書の次の属性を検証できます。

• SubjectDN

• SubjectUniqueID

• Mail

• CN

ユーザー・エントリを取得するには、X509認証モジュールで検証されるX.509証明書の属性名および検索が起動するLDAP属性を取得します。予期される結果は、基準と一致する1つのユーザー・エントリです。検索でユーザー・エントリが戻らない場合または複数のエントリが戻る場合、認証に失敗します。認証スキーム・パラメータはoam-policy.xmlにあります。

注意: X509認証の場合、管理者はリバース・プロキシとしてOracle HTTP Server(またはwl-proxyプラグインを使用するサーバー)を構成する必要があります。Oracle HTTP Serverを双方向SSLモードで構成して、認証するX.509証明書を取得する必要があります。CRL検証にもOracle HTTP Serverを構成できます。

オンライン証明書ステータス・プロトコル(OCSP)機能も提供されます。X.509証明書ベースの認証に渡される証明書は、OCSPリクエストを使用して検証します。管理者は、1つ以上のOCSPサーバーと通信するシステムを構成して、証明書ステータスを取得できます。

OCSP応答者URLのX509認証モジュール構成は、OCSP検証を実行するかどうかを示します。指定されている場合、値は、OCSPを使用してX.509クライアント証明書を検証するURLを示します。値がない場合、OCSP検証はありません。

WNA

Active DirectoryのWindows固有の認証およびKerberos認証モジュールを使用します。

注意: KerbSchemeは、WNAチャレンジ・メソッドおよびKerberos認証モジュールに基づいています。

関連項目: 統合のWindows固有の認証の詳細は、『Oracle Fusion Middleware Oracle Access Manager統合ガイド』を参照してください。

なし

なしチャレンジ・メソッドでは、ユーザーが要求されないので資格証明を入力する必要がありません。保護しないOracle Access Manager固有のURLにアクセスできるAnonymousScheme認証スキームで使用されます。

DAP

新しい委任認証プロトコル(DAP)チャレンジ・メソッドは、DAP認証モジュールおよび外部コンテキスト・タイプを使用したOIFScheme(Oracle Identity Federation統合)に必要になります(表12-3を参照してください)。DAPチャレンジ・メカニズムでは、外部オプションを使用する標準チャレンジのフォーム・メカニズムと異なり、OAMが受け取ったトークンのアサーションを実行します。

DAPModuleは新しいアサーション・モジュールですが、このアプリケーションに特化され、Oracle Access Managerコンソールの認証モジュールのリストに表示されません。この統合により、OSSO 10gはOAM11gに置き換えられますが、Oracle Identity Federation側からの変更はありません。

DAPチャレンジ・メカニズムは、認証をサード・パーティ(この場合はOracle Identity Federation)に委任します。challenge_urlは、Oracle Identity FederationサーバーのURLを指しています。リソースがこのスキームで保護される場合、OAMサーバーが資格証明コレクションのためにOracle Identity FederationサーバーURLにリダイレクトします。この場合、OAMサーバーは、資格証明の収集または検証を実行しません。Oracle Identity Federationは、資格証明を収集し、ユーザー・アイデンティティ・ストアに対してユーザーを認証して、ユーザー名を構成するアサーション・トークンをOAMサーバーに戻します。Oracle Access Managerは、このトークンを受信および復号化し、OAMのデフォルト・アイデンティティ・ストアでユーザーが有効かどうかを確認します。ユーザーが有効な場合、OAMはリソースのアクセス権を付与します。

DAPTokenは、OAMおよびOIF間で共有されるキーで暗号化および復号化します。DAPTokenは、OAM側から作成されます。

Oracle Identity Federation管理EMコンソールは、OAM 11gおよびOIF間の通信の保護に使用される暗号化鍵を含むキーストアを生成する方法を提供します。OAMは、OIFストアで生成されたキーストアの場所を特定し、キーを取得してOAM側に格納するWLSTコマンド(registerOIFDAPPartner)を提供します。

OAM10G

このチャレンジ・メソッドは、OSSO 10g統合クラシック・アプリケーション(PortalやDiscoなど)も含むドメインを保護するOAM 10gを使用している場合の信頼性を高めるため、LDAPNoPasswordAuthModuleを使用したOAM10gSchemeに必要です。この新しいメカニズムは、OAM 10g共存のために作成されます。

OAM10Gが常に認証/認可プロバイダとして動作するように、OSSO10GはWebgateを通じてOAM10Gで保護されます。

統合の促進: OSSO 10g統合クラシック・アプリケーションをアサータとしてのみ動作するOAM 11gにアップグレードできます。OAM 11gは、mod_ossoで使用できるトークンを作成して、これらのアプリケーションへのアクセスを実現します。mod_ossoアプリケーションは、新しい「OAM10gScheme」で保護されます。OAM 10gアクセス・サーバーに対して構成されたOAM 11gサーバーのフロント・エンド処理を行うWebgateがあります。

設定: リソースにアクセスする場合、Webgateはリクエストを捕捉し、認証するためにOAM 10gアクセス・サーバーに送信します。OAM 10gは、資格証明を収集し、アイデンティティ・ストアに対して検証し、ヘッダー変数(OAM_REMOTE_USER)としてユーザー名を設定します。リクエストは、OAM10gSchemeを使用してヘッダー変数のユーザー名を検索するOAM 11gサーバーに移動します。OAM 11gは、ヘッダー変数を取得し、プライマリ・アイデンティティ・ストアに対してユーザーの存在をアサートします。存在する場合、必要なCookie(OAM_ID)が生成され、リソースにリダイレクトされます。

認証スキームのチャレンジ・パラメータについて

チャレンジ・パラメータは、Webgateおよび資格証明コレクタ・モジュールによって使用および解釈される短いテキスト文字列で、その値で示された方法で動作します。

次のデフォルトのチャレンジ・パラメータの例では、使用するCookieでHttpOnlyプロパティを使用するようにWebgateで解釈されます。

ssoCookie=httponly

表12-5は、チャレンジ・パラメータを持つ事前構成済のスキームを示しています。スキーム自体の詳細は、表12-4を参照してください。

表12-5 事前構成済スキームのチャレンジ・パラメータ

事前構成済スキーム	チャレンジ・パラメータ
BasicSessionlessScheme	CookieLessMode=true 主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。
OAAMBasic	oaamPostAuth=true oaamPreAuth=true OAAM関連のリソースを保護します。これらのパラメータは、OAAMとの基本統合が必要な場合に使用します。
OIFScheme	TAPPartnerId=OIFDAPPartner このスキームは、認証をOracle Identity Federationに委任し、その後にOAMサーバーによってアサートされるトークンをFederationが戻します。
TapScheme	TAPPartnerId=TAPPartnerName

認証モジュールについて

Oracle Access Manager 11gでは、各認証スキームに認証モジュールが必要です。管理者は、既存のタイプの新しい認証モジュールを作成できます。ただし、すぐに利用するためにいくつかのデフォルトの認証モジュールを使用できます。

• LDAP: LDAPディレクトリ・サーバーに格納されたユーザー定義にリソースをリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。

• LDAPNoPasswordAuthModule

• カスタム認証モジュール: このモジュールのタイプは、Oracle Access ManagerのJava API拡張認証機能を使用して開発されたカスタム・プラグインに依存しています。このモジュールのタイプでは、1つ以上のカスタム・プラグインを使用できます。複数のプラグインを使用する場合、認証機能を実行するように各プラグインを組織化し、それが成功か失敗かによって、別の認証プラグインをコールします。

関連項目: 「カスタム認証モジュールの作成」 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』: プラグインの開発とデプロイ、カスタム認証モジュールおよびカスタム・モジュールを使用するスキームの詳細

マルチレベル認証について

各認証スキームに強度レベルが必要になります。この数値が低いほど、スキームが厳密ではなくなります。高いレベルの数値は、よりセキュアな認証メカニズムを示します。

• LDAPScheme authLevel=1

• KerbScheme authLevel=2

注意: マルチレベル認証は、X.509証明書の認証に影響を与えず、X.509証明書の認証を否定または変更しません。

SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。特定のレベルのユーザーの認証に成功した後、ユーザーは、1つ以上のアプリケーション・ドメインで保護された1つ以上のリソースにアクセスできます。ただし、アプリケーション・ドメインで使用される認証スキームは、同じレベル(または下位のレベル)にする必要があります。ユーザーが現在のSSOトークンのレベルを超える認証レベルで保護されたリソースにアクセスする場合、再認証されます。ステップアップ認証の場合、高いレベルで示されるチャレンジに失敗しても、ユーザーは現在のレベルのアクセスを維持します。これは「追加認証」です。

注意: レベル3のリソースへのアクセスを認証されているユーザーは、3以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます(これはステップアップ認証と呼ばれます)。

Oracle Access Manager 11gポリシーにより、同じアプリケーションの異なるリソースを別の認証レベルで保護できます。ただし、mod_ossoプラグインは、異なる信頼レベルの同じアプリケーションの2つのリソースをサポートしません。

注意: mod_ossoは、認証をOAMに委任します。mod_ossoで保護されたリソースをOAM認証レベルで保護することをお薦めします。

その場合、アプリケーションはそのレベルを適用し、再認証するために動的ディレクティブをmod_ossoに送信する必要があります。動的ディレクティブを受信すると、適切なレベルで再認証するためにmod_ossoがOracle Access Managerにリダイレクトします。

詳細は、次の項を参照してください。

• エージェントおよびマルチレベル認証について

• OAMエージェントによる不十分な認証レベルの検出

• OSSOエージェント(mod_osso 10g)を使用したマルチレベル認証のリクエスト・フロー

エージェントおよびマルチレベル認証について

登録されたエージェントは、次に示すように認証レベルを検出します。

• mod_ossoは、動的ディレクティブから認証レベルを検出します(「OSSOエージェント(mod_osso 10g)を使用したマルチレベル認証のリクエスト・フロー」を参照してください)。

• OAMエージェントは、OAMサーバーから不十分なレベルのエラー・メッセージを受け取ります(「OAMエージェントによる不十分な認証レベルの検出」を参照してください)。

両方のエージェント・タイプでユーザーがOAMサーバーにリダイレクトされ、再認証されます。リソースのポリシーに構成された認証スキームのレベルに応じて、チャレンジが示されます。

OAMエージェントによる不十分な認証レベルの検出

ユーザーが高いレベルの認証スキームで保護されるリソースをリクエストすると、次のプロセスが発生します。

プロセスの概要: OAMエージェントによる不十分なユーザー・セッション・レベルの検出

1. OAMエージェントはリクエストをOAMプロキシに送信し、保護されたリソースのスキーム詳細を取得します。

2. OAMエージェントは、セッション情報のリクエストをOAMプロキシに送信します。

3. OAMプロキシは、認証されたレベルのObSSOCookieを含むObSSOCookieの詳細を戻します。

4. OAMエージェントは、ObSSOCookieのレベルを認証スキームのレベルと比較します。

   • 不十分な場合、エージェントは認証プロセスを再起動します。

   • 十分な場合、アクセス権が付与されます。

サーバー側で認証レベルの確認は行われません。

OSSOエージェント(mod_osso 10g)を使用したマルチレベル認証のリクエスト・フロー

OAMエージェントとは対照的に、ホスト(または仮想ホスト)のmod_ossoで保護されたすべてのリソースが同じレベルで保護されます。

mod_ossoでは、ユーザーがレベル2でmod_ossoホスト(または仮想ホスト)ですでに認証され、レベル3で別のmod_ossoで保護されたホスト(または仮想ホスト)にアクセスする場合にマルチレベル認証が適用されます。

プロセスの概要: OSSOエージェントのマルチレベル認証フロー

1. ユーザーは、レベル2のhost1のmod_ossoで保護されたリソースにアクセスします。

2. OSSOエージェントはリクエストをOAMプロキシに送信し、保護されたリソースの認証スキーム詳細を取得します。

3. SSOサーバーのOAM_ID Cookieおよびhost1のホスト・ベースCookie「HOST_port」が設定され、認証レベル情報が格納されます。

4. 認証後、ユーザーは、高いレベルの認証で保護されるhost2のリソースにアクセスします。

5. host2の最初のアクセスなので、認証するためにユーザーがOAMサーバーにリダイレクトされます。

6. OAMサーバー(OSSOプロキシ)は、host2のリソースのアクセスに不十分なレベルのOAM_ID Cookieを受け取ります。

   • レベルが不十分な場合、OAMサーバー(OSSOプロキシ)は再認証を要求します。

   • レベルが十分な場合、アクセス権が付与されます。

認証スキームの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用してアプリケーション・ドメインで使用される新しい認証スキームを追加できます。

前提条件

認証モジュールを定義して使用可能にする必要があります。

関連項目: 「認証スキーム・ページについて」

認証スキームを作成するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」ノードを拡張します。

2. 「認証スキーム」ノードをクリックし、ツール・バーの「作成」ボタンをクリックします。

3. 新しい「認証スキーム」ページに入力します(表12-3)。

   1. 名前

   2. 説明

   3. 認証レベル

   4. チャレンジ・メソッド

   5. チャレンジ・リダイレクトURL

   6. 認証モジュール

   7. チャレンジ・パラメータ

   8. チャレンジURL

4. 「適用」をクリックして新しいスキームを送信します(または変更を適用しないでページを閉じます)。

5. 確認ウィンドウを閉じます。

6. オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。

7. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。

認証スキームの検索

有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定の認証スキームを検索できます。

関連項目: 「ポリシー構成検索コントロールについて」

認証スキームを検索するには、次の手順を実行します。

1. 「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

2. 検索タイプ・リストから「認証スキーム」を選択して、検索を定義します。

3. テキスト・フィールドに目的のスキーム名を(ワイルドカード(*)の使用は任意)入力します。次に例を示します。

   OA*
   

4. 「検索」ボタンをクリックして、検索を開始します。

5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

   • 編集: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。

   • 削除: ツール・バーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。

   • 連結解除: ツール・バーの連結解除をクリックして、ページ全体に表を拡張します。

   • 表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。

6. この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。

認証スキームの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを表示または変更できます。

関連項目: 「認証スキーム・ページについて」

認証スキームを表示または変更するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

   1. 「共有コンポーネント」ノード

   2. 「認証スキーム」ノード

2. 表示または変更するスキームの名前をダブルクリックします。

3. 編集:

   1. 「認証スキーム」ページで、必要に応じて値を変更します(表12-3)。

   2. 「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。

   3. 確認ウィンドウを閉じます。

4. デフォルトとして設定: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。

5. 終了する場合はページを閉じます。

認証スキームの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを削除できます。

前提条件

この認証スキームを使用してアプリケーション・ドメインを確認し、異なるスキームを指定します。

関連項目: 「認証スキーム・ページについて」

認証スキームを削除するには、次の手順を実行します。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次の項目を拡張します。

   1. 「共有コンポーネント」ノード

   2. 「認証スキーム」ノード

2. オプション: スキームの名前をダブルクリックして削除対象のスキームを確認し、ページを閉じます。

3. ナビゲーション・ツリーで、スキームの名前をクリックし、ツール・バーの「削除」ボタンをクリックします。

4. 削除を確認します(または確認ウィンドウを閉じます)。

5. ナビゲーション・ツリーで、インスタンスが削除されていることを確認します。

暗号化Cookieのチャレンジ・パラメータの構成

ここでは、次の内容について説明します。

• 暗号化CookieのssoCookieチャレンジ・パラメータについて

• 暗号化Cookieのセキュリティのためのチャレンジ・パラメータの構成

• 暗号化Cookieの永続性のためのチャレンジ・パラメータの設定

暗号化CookieのssoCookieチャレンジ・パラメータについて

OAMサーバーCookie(OAM_ID)に加えて、Oracle Access Managerは暗号化Cookieを使用してシングル・サインオンを実装します。

• 11g Webgate、エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用してWebgateで設定されたOAMAuthnCookie_<host:port>_<random number>

  注意: 有効なOAMAuthnCookieがセッションに必要です。

• 10g Webgate、すべての10g Webgateに対してObSSOCookieを1つ。

Oracle Access Managerには、Webgateによる暗号化Cookieのフラグの設定方法を制御するために任意の認証スキーム内で使用できる、ssoCookieチャレンジ・パラメータが用意されています。次に例を示します。

• 暗号化Cookieの保護: 暗号化CookieがSSL接続を介してのみ送信され、暗号化CookieがセキュアでないWebサーバーに返信されないようにできます。

• 暗号化Cookieの永続性: ユーザーが、単一のセッションではなく、一定期間ログインできるようにします。Cookieの永続機能は、Internet ExplorerおよびMozillaブラウザと連動します。

パラメータと値の構文には、Webgateのリリースによって次のようなわずかな違いがあります。

11g Webgate ssoCookie=

10g Webgate ssoCookie:

複数の値は、セミコロン(;)で区切る必要があります。次に例を示します。

11g Webgate ssoCookie=<value1>;<value2>;...

10g Webgate ssoCookie:<value1>;<value2>>;...

次の例は、暗号化CookieがSSL接続を介してのみ送信され、クライアント側スクリプトによって暗号化Cookieにアクセスできるように指定しています。

11g Webgate ssoCookie=Secure;disablehttponly

10g Webgate ssoCookie:Secure;disablehttponly

注意: チャレンジ・パラメータの値では大/小文字を区別します。ssoCookieのCおよびSecureのSは大文字で入力してください。

表12-5は、Webgateがシングル・サインオンの暗号化Cookieのフラグを設定する方法を制御する、特定のチャレンジ・パラメータを示しています。

表12-6 暗号化Cookieのチャレンジ・パラメータ

11g WebgateとOAMAuthnCookieの構文	10g WebgateとObSSOCookieの構文	説明
ssoCookie=	ssoCookie:	暗号化Cookieのフラグを制御するパラメータ。
ssoCookie=httponly	ssoCookie:httponly	暗号化Cookieが、JavaScriptなどのクライアント側スクリプトにアクセスできないようにします。 デフォルト: 有効
ssoCookie=disablehttponly	ssoCookie:disablehttponly	httponly機能を明示的に無効にすると、暗号化Cookieがクライアント側スクリプトにアクセスできるようになります。 明示的に無効にした場合、有効にするにはデフォルト値(httponly)を使用する必要があります。
ssoCookie=Secure	ssoCookie:Secure	HTTPSによってリソースにアクセスした場合のみ、暗号化Cookieが送信されるようにします。ブラウザがHTTPSを使用してサーバーにアクセスする場合のみ、セキュアなCookieが必要です。
ssoCookie=max-age=time-in-seconds	ssoCookie:max-age=time-in-seconds	Internet ExplorerおよびMozillaブラウザで、単一セッション用のものではなく、永続的なCookieを作成します。 Cookieが期限切れになるまでの時間間隔を秒単位で指定します。たとえば、Cookieを30日(2592000秒)で期限切れにするには、次のように設定します。 max-age=2592000

暗号化Cookieのセキュリティのためのチャレンジ・パラメータの構成

「チャレンジ・パラメータ」では大/小文字を区別します。ssoCookieのCおよびSecureのSは大文字で入力してください。

関連項目: 「暗号化CookieのssoCookieチャレンジ・パラメータについて」

暗号化Cookieを保護する手順は次のとおりです。

1. 「認証スキームの作成」で説明されているように、認証スキームを作成します。

2. 「チャレンジ・パラメータ」フィールドで、次のように指定して暗号化Cookieを保護します。

   11g Webgate ssoCookie=Secure

   10g Webgate ssoCookie:Secure

3. 付録Eに示すように、OAMサーバーとクライアント(OAMエージェント)が、アクセス・プロトコル・チャネルを介してセキュアに通信していることを確認します。

暗号化Cookieの永続性のためのチャレンジ・パラメータの設定

「チャレンジ・パラメータ」では大/小文字を区別します。ssoCookieのCは大文字で入力してください。

関連項目: 「暗号化CookieのssoCookieチャレンジ・パラメータについて」

暗号化Cookieの永続性を定義する手順は次のとおりです。

1. 「認証スキームの作成」で説明されているように、認証スキームを定義します。

2. このスキームのチャレンジ・パラメータに次の内容を追加します。

   11g Webgate ssoCookie=max-age=time-in-seconds

   10g Webgate ssoCookie:max-age=time-in-seconds