16 認証コンポーネントと共有ポリシー・コンポーネントの管理

この章では、管理者が共有ポリシー・コンポーネントを管理する方法について説明します。この章の内容は、次のとおりです。

• 前提条件

• 認証コンポーネントと共有ポリシー・コンポーネントの管理の概要

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

• ホスト識別子の管理

• 認証方式と資格証明コレクタの理解

• ネイティブ認証モジュールの管理

• プラグイン・ベースのモジュールによるマルチステップ認証の編成

• 個別の認証用プラグインのデプロイおよび管理

• 認証スキームの管理

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

• パスワード・ポリシーの理解

• グローバル・パスワード・ポリシーの管理

• パスワード・ポリシー認証の構成

• DCC対応の11g Webgateと認証ポリシーの構成

• パスワード・ポリシー構成の完了

16.1 前提条件

Oracle Access Managementコンソールおよび少なくとも1つのOAMサーバーがWebLogicサーバー・ドメイン内にインストールされ、稼動している必要があります。Access Managerが少なくとも2つのエージェントが登録された状態で稼動している必要があります。

この章で説明されているアクティビティを実行する前に、第15章「Access Managerを使用したシングル・サインオンの概要」で説明されている情報を確認することをお薦めします。

16.2 認証コンポーネントと共有ポリシー・コンポーネントの管理の概要

この項では、共有ポリシー・コンポーネントを構成するために実行する必要のあるタスクについて説明します。このコンポーネントは、リソースを保護し、シングル・サインオンを可能にするAccess Manager認証ポリシーで使用する必要があります。

関連項目: 第15章「Access Managerを使用したシングル・サインオンの概要」

タスク概要: 共有ポリシー・コンポーネントの構成

1. この章の説明に従って、必要なリソース・タイプが定義されていることを確認します。

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

2. 次の説明に従って、エージェントに由来する名前が付けられたホスト識別子の定義がエージェント登録時に作成された(またはユーザーが手動で作成した)ことを確認します。

   • ホスト識別子の管理

3. Access Managerによる資格証明コレクションについて理解します。

   • 認証方式と資格証明コレクタの理解

4. 複数ステップの認証を可能にする認証プラグインについて理解してから使用します。

   • プラグイン・ベースのモジュールによるマルチステップ認証の編成

   • 個別の認証用プラグインのデプロイおよび管理

5. 認証ポリシーに追加できる認証スキームを作成して管理します(次の項目を参照)。

   • 認証スキームの管理

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

6. デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタに独自のグローバル・パスワード・ポリシーを設定します(特に明記しないかぎり、このタスクはECCとDCCの両方に適用されます。わずかな違いについては、説明内に示しています)。

   • パスワード・ポリシーの理解

   • グローバル・パスワード・ポリシーの管理

   • パスワード・ポリシー認証の構成

   • DCC: DCC対応の11g Webgateと認証ポリシーの構成

   • パスワード・ポリシー構成の完了

7. 第17章に進み、認証ポリシーを設定します。

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

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

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

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

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

• カスタム・リソース・タイプの作成

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

リソースをアプリケーション・ドメインに追加する場合、管理者は定義されているリソース・タイプのリストから選択する必要があります。Oracle提供のリソース・タイプには、次が含まれます。

• HTTP

• wl_authen

• TokenServiceRP

管理者は、他のリソース・タイプを定義できます。また、Oracle提供のリソース・タイプまたはカスタム・リソース・タイプのどちらにも、操作を定義できます。特定のリソースについて、宣言されている操作の一部またはすべて(後でリソース・タイプに対して定義された新しい操作もすべて含めて)を使用するように定義できます。管理者は、リソースが作成されているカスタム・リソース・タイプまたは操作を削除することはできません。Oracle提供のリソース・タイプおよび操作は、ポリシー・ストア内で読取り専用としてマークされており、削除できません。

注意: リソース・タイプの操作リストは、そのタイプのリソースが存在する場合は、変更できません。

表16-1に、リソース・タイプと操作の比較を示します。

表16-1 Access Managerのリソース・タイプの10gとの比較

Access Manager 11g	Oracle AccessManager 10g
HTTP: HTTPプロトコルおよびHTTPSプロトコルで使用されるデフォルトのリソース・タイプ。 HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加する必要があります。 このリソース・タイプは読取り専用です。HTTPリソース・タイプに関連付けられているデフォルト操作を管理者が定義する必要はありません。かわりに、作成されてリソースに適用されるポリシーがすべての操作に適用されます。 操作: Oracle提供のリソース・タイプは読取り専用です。事前定義されている操作が関連付けられています。作成されてHTTPタイプのリソースに適用されるポリシーが、すべての操作に適用されます。 Get Post Put Head Delete トレース Options 接続 Other 関連項目: 「「リソース・タイプ」ページについて」	HTTP: HTTPリソース・タイプは読取り専用です。 操作: Oracle提供のリソース・タイプは読取り専用です。事前定義されている操作が関連付けられています。作成されてリソースに適用されるポリシーが、すべての操作に適用されます。 Get Post Put Head Delete トレース Options 接続 Other
wl_authen: WebLogic認証スキームを表すリソースも読取り専用です(デフォルト操作は変更も削除もできません。) この非HTTPリソース・タイプは、Access Managerが存在しないドメインにWebLogicコンテナでデプロイされているリソースとともに使用できます。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。 wl_authenタイプのリソースには、カスタム・アクセス・クライアントが必要です。	なし
TokenServiceRP: トークン・サービスのリライイング・パーティを表すリソース。このリソース・タイプの操作は発行です。	なし
カスタム・リソース・タイプ: 関連付けられたホスト識別子はありません。 カスタムEJBリソース・タイプは、SSO統合に使用するためにオンデマンドに作成できます。	EJB: ユーザー認証のためにWebLogicおよびWebSphereにSSOを統合する場合に使用するカスタム・リソース・タイプ。認証中は、ユーザーのグループがフェッチされ、サブジェクト・プリンシパルにロールとして移入されました。その後の認可は、ユーザー・ロールに基づいて、アプリケーション・サーバー内部で実行されました。 リソース操作によって認可がコールされることはありませんでした。
非HTTPリソース・タイプに関連付けられたホスト識別子はありません。 非HTTPリソースをアプリケーション・ドメインに追加する場合、管理者はタイプ名をポインタとして「リソースURL」フィールドに入力する必要があります。名前とホスト識別子は一致しません。これは、相対的なHTTP URLではありません。

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

Oracle Access Managementコンソールでは、リソース・タイプは、「ポリシー構成」タブで他のコンポーネントとともに編成されます。ナビゲーション・ツリーには、Oracle提供のリソース・タイプであるHTTP、wl_authenおよびTokenServiceRPが表示されます。

注意: 事前定義済のリソース・タイプは削除できません。鍵のアイコン付きで示される事前定義済の操作は、削除できません。必要に応じて、追加の操作を作成、編集または削除できます。

HTTPリソース・タイプ(図16-1参照)はAccess Managerで保護され、インターネット・プロトコル(HTTPまたはHTTPS)でアクセスされるWebアプリケーションに使用されます。

図16-1 デフォルトのHTTPリソース・タイプ定義

「図16-1 デフォルトのHTTPリソース・タイプ定義」の説明

図16-2は、 wl_authenリソース・タイプを示しています。これは、次のいずれかのAccess Manager IDアサーション・プロバイダ構成を使用するFusion Middlewareアプリケーションに使用します。このプロバイダ構成については、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

• IDアサーション・プロバイダ

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

• 認証プロバイダ機能

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

図16-3に示すように、TokenServiceRPリソース・タイプは、トークン・サービス・リライイング・パーティを表します。このリソース・タイプの操作は発行です。詳細は、「TokenServiceRPタイプのリソースの管理」を参照してください。

図16-3 デフォルト・リソース・タイプのTokenServiceRPリソース・タイプ

「図16-3 デフォルト・リソース・タイプのTokenServiceRPリソース・タイプ」の説明

表16-2に、各リソース・タイプ定義の要素を示します。

表16-2 リソース・タイプの定義

要素	説明
名前	必須。最大30文字の英数字の一意の名前。 注意: HTTP以外のリソース・タイプ名とホスト識別子は一致しません。
説明	オプション。このフィールドを使用して、このリソース・タイプの目的を最大200文字の英数字で説明します。 たとえば、WebLogic認証スキームを表すリソースなどです。
操作	オプション。特定のリソースを制御するポリシーは、そのリソースに定義されている、指定されたすべての操作に適用されます。このリソース・タイプに文字列として操作を追加(または削除)して、アプリケーション・ドメイン内でこのタイプのリソースを定義すると、操作が使用可能になります。リソース・タイプに追加できる操作の数に制限はありません。 Get Post Put Head Issue (TokenServiceRP) Login (wl_authen) Delete トレース Options 接続 Other (Oracle Access Manager 10では使用可能、11gではサポートされていません) リモート登録: 自動ポリシー作成時に、指定された操作がサポートされます。自動ポリシー作成時に何も操作が指定されていない場合は、そのタイプに対して定義されたすべての操作がサポートされます。 移行: Access Manager 11.1.2へのアップグレード(10gまたは11.1.1.3または11.1.1.5のいずれかから)の実行中、リソース定義およびHTTPデフォルト操作は自動的に処理されます。ただし、10gで提供されていたEJBカスタム・リソース・タイプは現在Oracleから提供されていないので、それに変わるカスタム・リソース・タイプを作成する必要があります。次を参照してください。 関連項目: 「リソース・タイプおよびその使用について」および「アプリケーション・ドメインのリソースの定義について」

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

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

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

関連項目: 「コンソールを使用した検索の実行」

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

1. Oracle Access Managementコンソールで「ポリシー構成」タブをアクティブ化し、「検索」タブをクリックします。

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

   h*
   

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

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

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

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

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

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

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

16.3.4 カスタム・リソース・タイプの作成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して事前定義のリソース・タイプを作成できます。たとえば、わずか1つまたは2つ(またはそれ以上)の操作に適用されるカスタム・リソース・タイプを定義できます。定義されているカスタム・リソース・タイプは、リソースを認証ポリシーまたは認可ポリシーに追加する際に、デフォルト・リソース・タイプとともにリストに表示されます。

関連項目: 「リソース・タイプおよびその使用法について」 アプリケーション・ドメインのリソースの定義

カスタム・リソース・タイプを作成するには:

1. Oracle Access Managementコンソールで「ポリシー構成」タブをアクティブ化します。

2. 「共有コンポーネント」で「リソース・タイプ」ノードをクリックし、「追加」(+)ボタンをクリックします。

3. 次の情報を入力します。

   • 名前: このリソース・タイプを識別する一意の名前。

   • 説明: オプション。

   • 操作: 「操作」表で「+」をクリックし、表示されるフィルドに操作名を入力します。必要に応じて手順を繰り返して、このリソース・タイプのすべての操作を定義します。

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

4. 「適用」をクリックして、このカスタム・リソース定義を送信します。

5. 「ポリシーに追加するリソース定義の追加および管理」の説明に従って、このリソース・タイプをアプリケーション・ドメインに追加します。

16.4 ホスト識別子の管理

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

• ホスト識別子について

• 仮想Webホストについて

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

• ホスト識別子の作成

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

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

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

16.4.1 ホスト識別子について

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

表16-3は、従業員がアクセスできるWebサーバーの異なるホスト名を示しています。これらの名前すべてを使用して単一のホスト識別子を作成すると、ユーザーのアクセス方法に関係なくアプリケーションを適切に保護する1つのポリシー・セットを定義できます。

表16-3 ホスト識別子の例

ホスト識別子のサンプル	説明
hrportal.intranet.company.com	従業員が覚えやすい名前。これはロード・バランシングされたプロキシで、このリクエストによってHRアプリケーションをホストするいくつかのサーバーのいずれかを実際に利用できます。
hr-sf-02.intranet.company.com	直接アクセスできるアプリケーションをホストする単一のマシン。
hrportal.company.com	以前の従業員の福利厚生や企業年金情報などの確認に主に使用するため、同じアプリケーションで企業ファイアウォールの外部にもアクセスできます。また、これはロード・バランシングされたリバース・プロキシです。

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

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

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

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

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

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

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

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

設計時に、特定のアプリケーション・ドメインに属するリソースを定義する場合、ホスト識別子を使用できます。リソースのホスト識別子(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対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。

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

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

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

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

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

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

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

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

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

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

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

すべての使用可能なホスト名バリエーションを定義して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

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

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

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は、リバース・プロキシの背後にデプロイされると、エンドユーザーのブラウザ上ではリンク切れになる可能性があります。

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

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

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

http://example2

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

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

HOST_HTTP_HEADER

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

• ホスト・ヘッダー名

• IPアドレス

• ポート

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

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

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 [e-mail]
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

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

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

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

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

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

図16-4 ホスト識別子ページ

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

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

表16-4 ホスト識別子の定義

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

16.4.4 ホスト識別子の作成

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

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

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

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

1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「ホスト識別子」ノードを開きます。

2. 「ホスト識別子の検索」ページの右上隅の「ホスト識別子の作成」ボタンをクリックします。

   または、「ホスト識別子」ノードを開いて「検索結果」表の上にある「作成」(+)ボタンをクリックします。

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

   1. 名前

   2. 説明

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

      追加: 「作成」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。

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

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

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

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

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

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

注意: ホスト識別子がリソースに関連付けられている場合、削除しようとすると、アラートが表示され、確認を求められます。関連付けられていない場合、ホスト識別子は正常に削除されます。

関連項目: 「コンソールを使用した検索の実行」

ホスト識別子を検索するには:

1. Oracle Access Managementコンソールの「ポリシー構成」タブで、「ホスト識別子」ノードを開きます。

2. 「ホスト識別子の検索」ページで、「名前」フィールドに名前(またはワイルド・カード(*)を含む部分的な名前)を入力するか、または「名前」フィールドを空白のままにしてすべてのホスト識別子を表示します。次に例を示します。

   my_h*
   

3. 「検索」ボタンをクリックして検索を開始し、表に結果が表示されたら、次の操作を実行します。

   • 表示または編集: 「検索結果」表で名前をダブルクリックして構成ページを表示し、通常どおり追加または編集します。

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

   • 連結解除: ツールバーの「連結解除」ボタンをクリックして、「検索結果」表をページ全体に拡張します(または「表示」メニューで「連結解除」をクリックします)。

   • 列の並替え: 「表示」メニューで「列の並替え」を選択して、表示される矢印を使用して列を並べ替えます。

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

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

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

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

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

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

1. 「ホスト識別子定義の検索」の説明に従って、必要なホスト識別子を検索して表示します。

2. 「ホスト識別子」ページで、必要に応じて情報を変更します(表16-4)。

   1. 名前

   2. 説明

   3. ホスト名組合せ: 表示される表で次の操作を実行します。

      ホスト名バリエーションの追加(+): 「追加」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。

      ホスト名バリエーションの削除(X): ホスト名をクリックし、「削除」ボタンをクリックして削除します。

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

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

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

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

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

注意: ホスト識別子がリソースに関連付けられている場合、アラートが表示されます。関連付けられていない場合、ホスト識別子は削除されます。

前提条件

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

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

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

1. このホスト識別子を使用するアプリケーション・ドメインの関連するリソース定義を検索して変更します。「リソース定義の検索」を参照してください。

2. 「ホスト識別子定義の検索」の説明に従って、必要なホスト識別子を検索します。

3. 表示: 結果表で名前をダブルクリックして構成ページを表示し、削除可能であることを確認します。

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

16.5 認証方式と資格証明コレクタの理解

Access Managerの認証では、リクエスタ(ユーザー)を一元化されたコンポーネントにリダイレクトする操作が伴われます。このコンポーネント(資格証明コレクタと呼びます)が、認証を実行します。

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

• 複数の認証方式について

• 埋込み資格証明コレクタと外部資格証明コレクタの比較

• 認証イベントのロギングおよび監査

16.5.1 複数の認証方式について

認証は、ユーザーを証明するプロセスです。Access Managerを使用してユーザーのアイデンティティを認証することは、事前定義された一連のプロセスを実行してユーザーのデジタル・アイデンティティを確認することを示します。

Access Managerを使用すると、認証スキームという単一の認証プロセスでリソースまたはリソースのグループを保護できます。認証スキームは、事前定義済の認証モジュールまたはプラグインに依存します。

この項では、マルチレベル認証およびAccess Managerでサポートされている他の認証方式について説明します。

マルチレベル認証

Access Managerを使用すると、管理者は複数の認証スキームに複数の認証レベルを割り当てて、どのアプリケーションをどのスキームで保護するかを選択できます。各認証スキームに強度レベルが必要になります。この数値が低いほど、スキームが厳密ではなくなります。高いレベルの数値は、よりセキュアな認証メカニズムを示します。

SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。レベル2のリソースへのアクセスを認証されているユーザーは、2以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます(これはステップアップ認証と呼ばれます)。

詳細は、「マルチレベル認証およびステップアップ認証について」を参照してください。

マルチステップ認証

マルチステップ認証には、複数の認証プラグインで構成されるカスタム認証モジュールが必要になります。このモジュールは、ログイン処理時に、バックエンドの認証スキームに情報を複数回伝送します。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。

「単純フォーム認証とマルチファクタ(マルチステップ)認証の比較」を参照してください。

Windowsネイティブ認証

統合Windowsネイティブ認証は、OSSOおよびWebgateの両方によって保護されているアプリケーションでサポートされています。この形式の認証は、Kerberos認証モジュールに依存しています。詳細は、第43章「Windowsネイティブ認証のためのAccess Managerの構成」を参照してください。

他の認証タイプ

次のような、Oracle Fusion Middlewareアプリケーションに必要な認証機能がサポートされています。

• 一般的にユーザー名およびパスワードを使用して証明書を使用しない弱い認証

• サード・パーティのセルフサービス・ユーザー・プロビジョニングの自動ログイン

• ユーザー・コンテキスト情報のHTTPヘッダー・サポート。たとえば、ホスト識別子を使用してリソースのホスト・コンテキストを作成します。これは、異なるコンピュータで同じURLパスを使用するリソースを追加する場合に役立ちます。

2つのWebGateの異なる認証スキームを使用する場合、ユーザーは再認証なしで高い認証スキームから低い認証スキームに移行できますが、低い認証スキームから高い認証スキームには移行できません。

注意: シングル・サインオンの実行中、ユーザーが認証テストに成功しても、2番目または3番目のリソースにアクセスする際に認可テストに失敗する場合があります。ドメインの各リソースに一意の認可ポリシーが存在する場合があります。

Access Managerを使用した認証スキームの構成および使用の詳細は、「認証スキームの管理」を参照してください。

16.5.2 埋込み資格証明コレクタと外部資格証明コレクタの比較

Access Manager 11.1.2は、デフォルトで埋込み資格証明コレクタ(ECC)をサポートします。さらに、最新のWebゲートを外部資格証明コレクタ(DCC。認証Webゲートと呼ぶこともあります)として使用するように構成することもできます。

DCCは、デフォルトの埋込み資格証明コレクタ(ECC)よりも安全性が高いと考えられます。集中DCCは、ログイン・ページを提示してユーザーの資格証明(ユーザーIDやパスワードなど)を収集し、バック・チャネルのOracle Accessプロトコル(OAP)を使用してこれらをOAMサーバーに送信します。DCCを使用すると、追加の資格証明が要求されることがあります。

OAMサーバーがDCCを使用するように構成されている場合、ECCとそのHTTPエンドポイントは無効になります。唯一のHTTP通信は、OAMサーバーがデプロイされているドメイン内のWebLogic AdminServerでホストしているOracle Access Managementコンソールに対する通信です。AdminServerへの接続は、ネットワーク・レベルで制御できます。たとえば、内部ネットワークの外部からの管理リクエストを禁止できます。

• ECCとDCCの共存を許可すると、ECCまたはDCCで使用するように構成した認証スキームとポリシーを使用できるようになります。これにより、Oracle Access Managementコンソールを含むECCに依存するリソースにフォールバック・メカニズムを使用できるようになります。

• ECCを無効にする(オフにする)と、Oracle Access Managementコンソールを含むECCメカニズムに依存するリソースへのアクセスを、完全に禁止することになります。

埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)には、本質的な違いはありませんが、これらの比較を表16-5に示します。

関連項目: 「Access Manager資格証明コレクションおよびログインの概要」

表16-5 DCCとECCの比較

	DCC	ECC
デプロイメント	外部資格証明コレクタは、サーバーの論理部分に存在し続けて、OAMサーバーのフロント・チャネル通信のエンドポイントとして機能します。ただし、DCCは次のようにも構成できます。 スタンドアロン(OAMサーバーからデタッチされ、アプリケーション・サーバーを必要としません)。 RSA SecurIDのパスコード検証、次回のトークンの取得、新規PIN作成のワークフローをサポートします。 サーバーのスケールアウト、攻撃リジリエンスに対する優れた柔軟性に加え、資格証明コレクションUIの作成、フローおよびライフサイクル管理については、以前の10g認証Webゲートと同様です。	埋込み資格証明コレクタは、OAMサーバーとともにデプロイされ、このサーバーに統合され、プロトコル・バインディング・レイヤーの一部になります。 ECCは、RSA SecurIDパスコードの検証、次回のトークンの取得、新規PINの作成ワークフローをサポートします。
DMZデプロイメント	可能。 DMZでDCCを使用するデプロイメントの場合、エンド・ユーザーのネットワーク接続が公衆回線網内で終了し、OAMサーバーには相互認証された接続でOracle Accessプロトコル(Oracle独自のアプリケーション・ネットワーク・プロトコル)を使用して接続するという利点があります。これにより、OAMサーバーは完全に分離され、非認証ネットワーク接続が確立することはありません。 非認証ユーザーは、不正なリクエストをOAMサーバーに送信できません。	不可。
通信チャネル	DCCは、ユーザーからのHTTP/HTTPSリクエストを利用して、SSLに対応できるOracle Accessプロトコル(バック・チャネル)を通じてOAMサーバーと通信します。	ECCは、HTTP/HTTPSを通じてユーザーとOAMサーバーの両方と通信します。
DCCログイン、エラーおよびパスワードのページ	DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso/*、WEBGATE_HOME/webgate/ohs/oamsso-bin/*plおよびWEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*ディレクトリで、次を参照してください。 ログイン・ページ: /oamsso-bin/login.pl ログアウト: /oamsso-bin/logout.pl RSA SecurIDログイン・ページ: /oamsso-bin/securid.pl 注意: /oamsso-bin内の、login、logoutおよびsecuridスクリプトの最初の行にあるPerlの場所を更新してください。 関連項目: 表16-24「資格証明コレクタのパスワード・ページ」。 この実装のログイン・ページの詳細は、第42章「RSA SecurID認証とAccess Managerとの統合」を参照してください。 ページおよびメッセージのカスタマイズの詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。	ユーザーが資格証明を入力するページです。OAMサーバーにデフォルトで付属し、追加の設定や変更は必要ありません。 ログイン・ページ: /pages/login.jsp ログアウト・ページ: /pages/logout.jsp エラー・ページ: /pages/servererror.jsp マルチステップ: /pages/mfa_login.jsp
DCCベースのログインおよびログアウトを行うPerlスクリプト	DCCベースのログインおよびログアウトを行うPerlスクリプト Perl実行ファイルのパス名は、Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso-bin/*plにあるOracle提供のPerlスクリプト内で、実際の場所と一致するように更新する必要があります。 Unix: whichコマンドを使用すると、OAMサーバー上でperlを検索できます。次に例を示します。 which perl /usr/bin/perl ただし、perlスクリプト自体では次の場所が参照されています。 /usr/local/bin/perl Windows: Oracle提供のPerlスクリプトで指定されているデフォルトのPerlインタプリタは使用できません。これらのスクリプトのPerlインタプリタのパスを、ご使用のシステムの実際のPerlへのパスに更新する必要があります。	なし
パスワード・ポリシーの強制	可能。 「パスワード・ポリシーのDCCフォームの検索と更新」を参照	可 関連項目: 「グローバル・パスワード・ポリシーの管理」
認証スキームのコレクション・メソッド	DCCはすべてのチャレンジ・メソッドをサポートしています。	ECCはすべてのチャレンジ・メソッドをサポートしています。 ECCは、認証スキームのチャレンジ・メソッドに基づいてユーザーの資格証明を収集し、その資格証明を検証するためにOAMサーバーに送り返します。
カスタム認証プラグインとチャレンジ・メソッド	可。ECCと同じです。	すべてのチャレンジ・メソッドとマルチステップ認証(パスワード・ポリシーと、その他のカスタム認証プラグイン)がサポートされます。
シングル・ステップ(単純フォーム)認証	可。ECCと同じです。	可能。次の場合、DCCとECCの両方がこれを処理ます。 すべての資格証明が1つの単純フォームで提供される場合。 資格証明の検証時および認証時。成功または失敗のステータスが返されます。 これは失敗時に再試行できます。
マルチステップ認証	可能。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、繰返しおよび変数)の認証プロセスを処理します。 この場合、次のようになります。 必要な資格証明が、一度に提供されない場合。 認証ステータスに応じて、PENDING状態になり、予期される資格証明とコンテキスト・データが返され、該当する資格証明が次回に提供されると予期されます。 成功または失敗のステータスが返されるまでは、各中間ステップで認証エンジンにフィードする必要がある資格証明とコンテキスト・データが送信されます。 認証プラグインは、複数のステップで構成できます。 「マルチレベル認証およびステップアップ認証の理解」を参照	可能。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、繰返しおよび変数)の認証プロセスを処理します。
認証処理	ECCと比較すると、DCCがOAMサーバーの認証機能を制限することはありません。 DCC: 10g Webgateおよび11g Webgateの両方からの認証リダイレクトを処理します。 ユーザーの資格証明(単純フォームまたはマルチファクタ)に対するチャレンジを含むフォームベース認証を処理します。 エージェント・キーを使用するエージェントからの認証リクエスト・メッセージを復号化し、基本的な整合性チェックを実行し、リクエストの時刻を検証し、リクエスト・コンテキストを含むリクエストからすべてのパラメータを抽出します。 最初に取得したリクエスト・コンテキストを含む認証レスポンス・メッセージを作成し、エージェント・キーを使用してobrarを復号化します。 エージェント・キーを使用してログアウト・リダイレクト・リクエストを復号化し、ログアウト処理を起動します。	認証時: ECCは、プロトコル・バインディング・レイヤー(PBL)に着信するリクエストを処理します。PBLでは、リクエストを変換してSSOエンジンに送信します。 SSOエンジンは、有効なセッションについてチェックします。有効なセッションが存在しない場合は、認証エンジンに制御を移します。 認証エンジンは、リソースの保護についてチェックし、そのリソースに関連付けられた認証スキームをフェッチします。 ECCはクライアントと対話し、データを受け入れて、これをPBLに送信します。
ECCのオーバーライド	DCCをデプロイしてECCを無効にする場合、管理者は次のタスクを実行して、関連するDCC URLとフォームを指定する必要があります。 OAMエージェント登録: 資格証明コレクタ操作の許可(DCCに対して有効化) 認証モジュール、ステップ編成: エラー(失敗時) 認証スキーム: チャレンジ・リダイレクトURL (DCCホストおよびポート) 認証スキーム: チャレンジURL /oamsso-bin/login.pl (DCCログイン・ページ) 認証スキーム: チャレンジ・メソッド パスワード・ポリシー: DCCのパスワード・サービスURL (デフォルト: /oamsso-bin/login.pl) 「DCCの資格証明操作の有効化」を参照	なし
ログアウト構成	「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」を参照	「11g Webgateの集中ログアウト構成」を参照
Cookie/トークン	DCCCtxCookie 11g Webgate: OAMAuthnCookie 11g Webgate: OAMRequestContext 10gリソースWebgate: ObSSOCookie 関連項目: 「ユーザー・ログイン時のシングル・サインオンCookieについて」	11g Webgate: OAMAuthnCookie 11g Webgate: OAM_REQ 11g Webgate: OAM_ID 11g Webgate: OAMRequestContext 10g Webgate: ObSSOCookie 関連項目: 「ユーザー・ログイン時のシングル・サインオンCookieについて」

16.5.3 認証イベントのロギングおよび監査

管理イベント以外に、認証の成功および失敗イベントが監査されます。監査には、認証スキーム、モジュールおよびポリシーの作成、変更、表示および削除が含まれます。認証するユーザーに関して収集される情報は、次のとおりです。

• IPアドレス

• ユーザー・ログインID

• アクセスの時間

ロギング(または監査)中、ユーザー情報およびユーザー機密属性は記録されません。誤用を避けるためにセキュアなデータ(ユーザー・パスワードなど)が削除されます。

関連項目: 第6章「コンポーネント・イベント・メッセージのロギング」 第8章「管理および実行時イベントの監査」 第9章「Oracle Access Managementコンソールを使用したパフォーマンスのモニタリング」

16.6 ネイティブ認証モジュールの管理

Access Managerでは、各認証スキームに認証モジュールが必要です。

注意: ネイティブ認証モジュールには、指定された認証ニーズを満たすように複数のプラグインを編成するための柔軟性がありません。したがって、ネイティブ認証モジュールは今後のリリースで非推奨の対象となります。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースの認証モジュールを使用することを強くお薦めします。

この項では次の情報を提供します。

• ネイティブのAccess Manager認証モジュールについて

• ネイティブ認証モジュールの表示または編集

• ネイティブ認証モジュールの削除

16.6.1 ネイティブのAccess Manager認証モジュールについて

表16-6に、Access Managerネイティブ認証モジュールを示します。

表16-6 ネイティブ認証モジュール

モジュール名	説明
LDAP	リソースをリクエストしたユーザーの資格証明(ユーザー名およびパスワード)を、LDAPディレクトリ・サーバーに格納されているユーザー定義と比較します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。 関連項目: ネイティブのLDAP認証モジュール.
LDAPNoPasswordAuthModule	リソースをリクエストしたユーザーの資格証明(ユーザー名およびパスワード)を、LDAPディレクトリ・サーバーに格納されているユーザー定義と比較します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。 関連項目: ネイティブのLDAP認証モジュール.
Kerberos	キー・タブ・ファイル名、krb5.configurationファイル名およびプリンシパルを指定します。 第43章の説明に従い、Windowsネイティブ認証用にAccess Managerを構成するときには、このプラグインを使用します。 関連項目: 「ネイティブのKerberos認証モジュール」
X509	LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示す追加プロパティを使用するLDAPPluginに似ています。 関連項目: ネイティブのX509認証モジュール。
カスタム認証モジュール	このタイプのモジュールは、バンドルされているプラグイン(またはAccess Manager認証拡張機能Java APIを使用して開発されたプラグイン)に依存しています。このタイプのモジュールは、通常、複数のプラグインを使用します。これらのプラグインは、各プラグインが固有の認証機能を実行することが保証されるように編成できます。各プラグインに定義されている成功アクションまたは失敗アクションに応じて、別の認証プラグインがコールされます。 関連項目: 「マルチステップ認証のプラグイン・ベースのモジュールについて」および『Oracle Fusion Middleware Oracle Access Management開発者ガイド』(カスタム・モジュールを使用するスキーム、カスタム認証モジュールおよびプラグインの開発とデプロイの詳細)。

関連項目: 「チャレンジ・メソッドについて」 カスタム認証プラグインの作成の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

16.6.1.1 ネイティブのKerberos認証モジュール

事前構成済Kerberos認証モジュールを図16-5に示します。詳細は、図の後に説明します。

図16-5 ネイティブのKerberos認証モジュール

「図16-5 ネイティブのKerberos認証モジュール」の説明

表16-7は、ネイティブのKerberos認証モジュールの定義を示しています。既存の事前構成済Kerberos認証モジュールを使用するか、独自のモジュールを作成できます。

表16-7 ネイティブのKerberos認証モジュールの定義

要素	説明
名前	大文字および小文字の英字、数値および空白を使用できるこのモジュールの一意のID。
キー・タブ・ファイル	キー配布センター(KDC)の認証に必要となる、ホストのキーの暗号化されたローカルのディスク上のコピーへのパス。たとえば、/etc/krb5.keytabなどです。 KDCは、リクエストしているユーザーを認証し、ユーザーにリクエストされたサービスのアクセスが認可されていることを確認します。認証されたユーザーがすべての所定の条件を満たしている場合、KDCはサーバー・キーに基づくアクセスを許可するチケットを発行します。クライアントはチケットを受け取り、適切なサーバーに送信します。サーバーは、送信されたチケットを確認し、送信したユーザーにアクセス権を付与できます。 キー・タブ・ファイルは、rootによってのみ読取り可能であること、およびマシンのローカル・ディスク上に存在することが必要です。バックアップ・データへのアクセスが、マシンのrootパスワード自体へのアクセスと同じくらい厳密に保護されていないかぎり、バックアップの一部にはできません。
プリンシパル	ホストのキータブの生成を有効化するKerberosデータベースのプリンシパルのHTTPホストを識別します。
KRB構成ファイル	Kerberosインストールの特定の側面を制御する構成ファイルのパスを識別します。krb5.confファイルは、Kerberosを実行している各UNIXコードの/etcディレクトリに存在する必要があります。 krb5.confには、Kerberos V5ライブラリに必要な構成情報が含まれます(デフォルトのKerberosレルムおよび既知のレルムのKerberosキー配布センターの場所)。

16.6.1.2 ネイティブのLDAP認証モジュール

Oracleでは、次の2つのLDAP認証モジュールを提供しています。

• LDAP

• LDAPNoPasswordAuthModule

図16-6に示すように、両方のモジュールが同じ要件(「名前」と「ユーザー・アイデンティティ・ストア」)を持っています。詳細は、図の後に説明します。

図16-6 ネイティブのLDAP認証モジュール

「図16-6 ネイティブのLDAP認証モジュール」の説明

表16-8は、LDAP認証モジュールの要素を示しています。同じ要素と値がLDAPNoPasswordAuthnModuleでも使用されます。

注意: これらの標準LDAP認証モジュールは廃止対象になっています。将来の拡張機能は、この標準モジュールでは使用できなくなります。Oracleでは、プラグイン・ベースのモジュールの使用を強くお薦めします。

表16-8 ネイティブのLDAP認証モジュールの定義

要素	説明
名前	このモジュールの一意の名前。
ユーザー・アイデンティティ・ストア	指定されたLDAPユーザー・アイデンティティ・ストアは、このモジュールの認証に必要なユーザー資格証明を含んでいる必要があります。LDAPストアはAccess Managerに登録されていなければなりません。 関連項目: 「ユーザー・アイデンティティ・ストアの管理」 複数のアイデンティティ・ストア・ベンダーがサポートされています。インストール時には、ユーザー・アイデンティティ・ストアは1つのみで、それが指定されたシステム・ストアでもあります。アイデンティティ・ストアを追加し、別のストアをシステム・ストアとして指定する場合には、必ずそのシステム・ストアを参照するようにLDAPモジュールを変更してください。認証スキームOAMAdminConsoleSchemeは、管理者ロールと資格証明をLDAPモジュールに依存します。 関連項目: 「デフォルト・ストアおよびシステム・ストアの設定」および「管理者のロックアウト」

16.6.1.3 ネイティブのX509認証モジュール

Access Managerは、デフォルトとして事前定義済X509認証モジュールを用意しています。管理者は、新しいX509認証モジュールも作成できます。暗号化の表現のX.509は、シングル・サインオン(SSO)に使用されるデジタル公開鍵証明書の標準です。X.509では、特に公開鍵証明書、証明書失効リストおよび属性証明書の標準形式を指定します。

X.509デジタル証明書を使用すると、証明書を発行する認証局(CA)の厳密な階層システムを取得できます。X.509システムで、CAは、特定の識別名または電子メール・アドレスやDNSエントリなどの代替名に公開鍵をバインドする証明書を発行します。

企業のPKIシステムで使用できるように、企業の信頼されたルート証明書をすべての従業員に配布できます。SSL証明書をすぐに使用できるように、特定のWebブラウザは、事前インストールされたルート証明書を用意しています。

Access Managerは、オンライン証明書ステータス・プロトコル(OCSP)インターネット・プロトコルを使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスします。OCSPは、X.509デジタル証明書の失効ステータスの取得に使用されます。OCSPは、証明書ステータスを含むサーバーおよびそのステータスを通知されるクライアント・アプリケーション間で使用される通信構文を指定します。

ユーザーがサーバーにアクセスしようとすると、OCSPは証明書ステータス情報のリクエストを送信します。OCSPは、特定のネットワーク・ホストが特定の時間に特定の証明書を使用していたことをリクエスタに公開します。サーバーは、「current」、「expired」、または「unknown」というレスポンスを戻します。OCSPは、期限が切れた証明書を使用するユーザーに更新前の指定された期間にサーバーにアクセスできる構成可能な猶予期間を与えます。

OCSPメッセージはASN.1で暗号化され、HTTPで一般的に転送されます。OCSPのリクエストおよびレスポンス特性では、OCSPサーバーを参照する場合に「OCSP応答者」という用語を使用します。Access Managerを使用する場合、Oracle Access ManagementコンソールをホストするコンピュータはOCSP応答者です。

OCS応答者は、リクエストで指定された証明書が適正、失効または不明であることを示す署名されたレスポンスを戻すことができます。OCSPがリクエストを処理できない場合、エラー・コードを戻すことができます。

図16-7 ネイティブのX509認証モジュール

「図16-7 ネイティブのX509認証モジュール」の説明

表16-9は、ネイティブのX509認証モジュールの要件を示しています。

注意: この標準認証モジュールは廃止対象になっています。将来の拡張機能は、この標準モジュールでは使用できなくなります。Oracleでは、プラグイン・ベースのモジュールの使用を強くお薦めします。

表16-9 X509認証モジュールの定義

要素	説明
名前	一意の名前でこのモジュール定義を識別します。
一致するLDAP属性	特定の「X509証明書属性」値に対して検索されるLDAP識別名属性を定義します。 たとえば、証明書のサブジェクトEMAILが[e-mail]で、それがLDAP属性の"mail"に一致する必要がある場合、LDAP問合せは、[e-mail] (cn)という値を持つ"mail"属性をLDAPから検索する必要があります。 デフォルト: cn
X509証明書属性	公開鍵のバインドに使用される証明書属性を定義します(サブジェクト内の属性、証明書から抽出される発行者スコープ。たとえば、subject.DN、issuer.DN、subject.EMAIL)。 関連項目: この表の前半にある「一致するLDAP属性」
証明書検証有効	X.509証明書の検証を有効化(選択されていない場合は無効化)します。 有効化された場合、OAMサーバーは証明書検証を実行します(OAMサーバーに渡される前にWebLogicサーバーで証明書を捕捉して検証することはありません)。Access Managerが証明書のパス検証をすべて実行します。
OCSP有効	オンライン証明書ステータス・プロトコルを有効化(選択されていない場合は無効化)します。値はtrueまたはfalseです。次に例を示します。 OCSP有効: true 注意: 「OCSP有効」を選択した場合のみ、OCSPサーバー別名、OCSP応答者URLおよびOCSP応答者タイムアウトが必要です。
OCSPサーバー別名	.oamkeystoreファイルのCA証明書を指すOSCSP応答者の別名--別名およびOSCSP応答者インスタンスの実際のインスタンス名またはIPアドレスのマッピング。
OCSP応答者URL	オンライン証明書ステータス・プロトコル応答者のURLを入力します。たとえば、OpenSSLの応答者URLは次のようになります。 http://localhost:6060
OCSP応答者タイムアウト	証明書の更新前の限定された期間にOAMサーバーにアクセスできる期限が切れた証明書を使用するユーザーの猶予期間を指定します。

16.6.2 ネイティブ認証モジュールの表示または編集

有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証モジュールを変更できます。これには、既存のモジュール名の変更および他の属性の変更が含まれます。

前提条件

別の認証モジュールを使用するには、変更されるモジュールを参照する各認証スキームを変更します(必要な場合)。

注意: デフォルトでは、LDAPモジュールは、Oracle Access Managementコンソールを保護する認証スキームで使用されます。管理者アクセスの安全を確保するために、LDAPモジュールは、システム・ストアとして指定したユーザー・アイデンティティ・ストアを参照する必要があります。指定したシステム・ストアを変更する場合、新しく指定したシステム・ストアを参照するようにLDAPモジュールも変更する必要があります。

認証モジュールを検索、表示または編集する手順

1. Oracle Access Managementコンソールで、次の順に移動します。

   
   「システム構成」タブ
   「Access Manager」セクション
   「認証モジュール」ノード
   

2. 目的の「認証モジュール」ページを開きます。

3. 認証モジュール・ページで、必要に応じて情報を変更します。

   • Kerberosモジュール: 表16-7を参照してください。

   • LDAPモジュール: 表16-8を参照してください。

   • X509モジュール: 表16-9と表16-15を参照してください。

4. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。

5. 「認証スキームの管理」の手順に従って、更新された認証モジュールを認証スキームに追加します(または、このモジュールを参照する各認証スキームで、別の認証モジュールに変更します)。

16.6.3 ネイティブ認証モジュールの削除

有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証モジュールを削除できます。

次の手順は、カスタム認証モジュールとネイティブ認証モジュールのどちらを削除する場合でも同じです。

前提条件

削除するモジュールを参照している各認証スキームで、別の認証モジュールを指定します。

認証モジュールを削除するには、次の手順を実行します。

1. このモジュールを参照する各認証スキームでは、別の認証モジュールを指定します。

2. Oracle Access Managementコンソールで、次の順に移動します。

   
   「システム構成」タブ
   「Access Manager」セクション
   「認証モジュール」ノード
   

3. オプション: モジュールを開いて削除するモジュールであることを確認してから、ページを閉じます。

4. 目的のモジュール名をクリックし、「削除」ボタンをクリックします。

5. 削除を確認します(またはモジュールを保持する確認ウィンドウを閉じます)。

16.7 プラグイン・ベースのモジュールによるマルチステップ認証の編成

認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。認証処理では、1つの認証モジュールを使用して、バックエンド認証スキームに対する情報の要件および転送を制御するルールを定義します。プラグインにより収集され、コンテキストに保存された情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。

注意: カスタム認証モジュールの作成には、認証プラグインを使用するようにお薦めします。

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

• プラグインとマルチステップ認証モジュールの作成について

• マルチステップ認証のプラグイン・ベースのモジュールについて

• SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合

• プラグイン・ベースのマルチステップ認証モジュールの作成と編成

関連項目: カスタム認証プラグインを作成する場合は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

16.7.1 単純フォーム認証とマルチファクタ(マルチステップ)認証の比較

単純フォームベースの認証は、デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタと、Access Manager認証メカニズムでユーザー・ログインを処理するWebフォームに依存します。単純フォームベースの認証は、デフォルトであるため、フォームをカスタマイズしないときには、追加の設定は必要ありません。

単純フォームベースの認証を使用する場合:

• すべての資格証明が1つの単純フォームで提供される場合。

• 資格証明の検証時および認証時。成功または失敗のステータスが返されます。

• これは失敗時に再試行できます。

関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびフォームのカスタマイズの詳細

動的なマルチステップ認証のために、Access Managerは、独自にカスタマイズした認証モジュールで設計および編成できる、いくつかのプラグインを提供しています。認証プラグインは、特定のニーズを満たす処理を実現します。

また、管理者はAccess Manager用の複数のユーザー・アイデンティティ・ストアをインストールすることもできます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。各認証プラグインは、別々のユーザー・アイデンティティ・ストアを使用するように構成できます。

DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、反復および変数)の認証プロセスを、次のように処理します。

• 必要な資格証明が、一度に提供されない場合。

• 認証ステータスに応じて、PENDING状態になり、予期される資格証明とコンテキスト・データが返され、該当する資格証明が次回に提供されると予期されます。

• 成功または失敗のステータスが返されるまでは、各中間ステップで認証エンジンに必要な資格証明とコンテキスト・データが送信されます。

• 認証プラグインは、複数のステップで構成できます。

表16-10に、これら2つの形式の認証についての詳細を示します。

表16-10 単純フォーム認証とマルチステップ認証

認証方式	説明
フォームベースの簡易認証	単純フォームベースの認証は、資格証明コレクタ(ECCおよびDCC)と、Access Manager認証メカニズムを使用してユーザー・ログインを処理するWebフォームに依存します。これはデフォルトであるため、フォームをカスタマイズしないときには、追加の構成は必要ありません。 関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびフォームのカスタマイズの詳細
マルチステップ認証	マルチステップ認証には、複数の認証プラグインで構成されるカスタム認証モジュールが必要になります。このモジュールは、ログイン処理時に、バックエンドの認証スキームに情報を複数回伝送します。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。 マルチステップ認証は、次のものに依存しています。 認証のチェーン化: 複数の認証プラグインを新しい認証モジュールにチェーンして、そのモジュールを認証スキームに追加できます。 チャレンジ・メカニズム: 必要な資格証明の収集方法を制御します。現在は、認証スキームに関連付けられています。ECCとDCCは同じチャレンジ・メカニズムを使用します。 資格証明コレクション: マルチステップ認証には、ECCまたはDCCのどちらかを使用できます。(DCCにより、ユーザーのアイデンティティを確立するための様々な方法を使用して認証関連情報を収集する際の、ユーザーとの対話またはプログラム・エンティティとの通信の柔軟性が大幅に向上します)。 関連項目: 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」 カスタム認証プラグインの詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

16.7.2 プラグインとマルチステップ認証モジュールの作成について

カスタム・プラグイン・ベースの認証モジュールは、既存のAccess Managerプラグインを使用して作成できます。Oracle Fusion Middleware Oracle Access Management開発者ガイドの説明に従って、ユーザー独自のプラグインを作成することもできます。

各プラグインは個別の機能部分を提供しており、これらは単独で使用するか、一連の手順につなぎ合わせて使用することができます。プラグインのライフサイクルは、プラグインをOAMサーバーに追加し、そのプラグインを使用して、OAMサーバーの拡張機能として動作する機能やワークフローを構築できるようにすることに中心が置かれています。各プラグインはJARファイルとしてデプロイされるので、各プラグインの構成要件はXML形式で指定する必要があります。

注意: プラグインは、デフォルトの埋込みの資格証明コレクタ(ECC)か、オプションのデタッチされた資格証明コレクタ(DCC対応のWebゲート)のいずれかと連動します。標準(ネイティブの)認証モジュールは、非推奨になる予定です。将来の拡張機能は、標準モジュールでは使用できなくなる予定です。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースの認証モジュールを使用することを強くお薦めします。

図16-8は、Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから使用できるデフォルトのプラグインを示しています。カスタム認証モジュールを構築するためのステップを追加すると、これらのプラグインと、ユーザーがSDKや使用して作成したりインポートしたプラグインが、リストに表示されます。

図16-8 カスタマイズした認証モジュールのAccess Managerプラグイン

一般的に、「名前」によって、プラグインに依存するコンポーネントが定義されます。「説明」はオプションです。「タイプ」列は、プラグインの目的を示しています。「アクティブ化のステータス」によって、このプラグインがアクティブで使用可能かどうかがわかります。

関連項目: ユーザー独自のカスタム・プラグイン構築の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。新しいプラグインをインポートしたり、カスタム・プラグインを配布、アクティブ化、非アクティブ化、削除することができます。

Oracle提供のプラグインを使用する場合も、ユーザー独自のプラグインを作成する場合も、カスタム認証モジュールの作成時にプラグインを追加することは同じです。

各カスタム・モジュールには、次のタイプの情報が必要です。

• 「一般」: 個々のプラグインの一意の名前とオプションの説明を識別します。

• 「ステップ」: 各プラグインの構成詳細(使用するユーザー・アイデンティティ・ストアを含む)に基づいて、使用する固有のプラグインと、その実行順序を識別します。

• 「ステップ編成」: 成功時、失敗時、またはエラー時に実行するアクションを指定します。

図16-9に、「システム構成」ツリーの「Access Manager」にある「カスタム認証モジュール」を示します。モジュールごとに、モジュールの情報を入力する3つのサブタブが表示されます。

図16-9 カスタム認証モジュールの作成: 「一般」

「図16-9 カスタム認証モジュールの作成: 「一般」」の説明

表16-11は、「一般」タブの内容について説明しています。

表16-11 「一般」タブ

要素	説明
名前	一意の名前で、60文字以内です。
説明	オプション。250文字以内です。

「ステップ」タブをクリックすると、新しいページが開き、そこで新規ステップを追加できます。新規のステップを追加するときには、次のダイアログ・ボックスが表示されます。ここで入力する情報を使用して、表と、ページの「詳細」セクションにデータが移入されます。

図16-10 ステップの追加とプラグインの関連付け

「図16-10 ステップの追加とプラグインの関連付け」の説明

表16-12では、新規ステップの追加に必要な情報について説明します。各ステップに1つのプラグインが必要です。また、各プラグインには、適切な操作のための具体的な詳細が必要です。

表16-12 「新規ステップの追加」のエントリ、ステップの結果表、「詳細」セクション

要素	説明
ステップ名	ステップを識別するために入力する一意の名前で、60文字以内です。
説明	ステップを追加するときにオプションで入力する、このステップの説明(250文字以内)。
プラグイン名	特定のステップに対して選択するプラグインです。インポートされアクティブ化されているプラグインのリストから選択します。 関連項目: カスタム・プラグインの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
ステップの詳細	正しい操作を確実に実行するために、プラグインの構成詳細を指定する必要があります。詳細の内容は、選択したプラグインと、そのプラグインの要件によって異なることがあります。 関連項目: 表16-13。

表16-13に、各種プラグインで必要になるプラグイン・パラメータの詳細を示します。この表に記載されていないプラグインのKerberosTokenIdentifier、FedAuthnRequestPluginおよびFedUserAuthenticationPluginは、例外的なプラグインです(これらのプラグインには、初期パラメータがありません)。

表16-13 各種プラグインのパラメータの詳細

プラグイン・パラメータ	表示名	説明
KEY_IDENTITY_STORE_REF	アイデンティティ・ストア名	認証時に適切なユーザー・アイデンティティ・ストアが呼び出されるようにするために、ほとんどのプラグインでこの属性が必要になります。 次のプラグインは、このプロパティのみを使用します。 TAPAssertionPlugIn このプロパティを採用するプラグインに必要な追加の詳細は、次を参照してください。 UserIdentificationPlugIn UserAuthenticationPlugIn UserPasswordPolicyPlugin TAPUserAuthenticationPlugin TenantDisambiguationPlugin
UserIdentificationPlugIn
KEY_LDAP_FILTER	LDAPフィルタ	ユーザーを特定するために必要な検索フィルタです。LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。
KEY_SEARCHBASE_URL	LDAP検索ベース	問合せに必要な検索ベースです。ディレクトリ情報ツリー(DIT)のノードです。このノード以下にユーザー・データが格納されるため、すべてのユーザー・データ検索の最高位のベースになります。
UserAuthenticationPlugIn
KEY_PROP_AUTHN_EXCEPTION	LDAPエラーの伝播	LDAPエラーの伝播を有効(または無効)にします。UserAuthenticationPlugInは、この属性を採用しています。
UserPasswordPolicyPlugin
PLUGIN_EXECUTION_MODE	操作モード	プラグイン(UserPasswordPolicyPlugin)の実行モードです。このプラグインは、構成に従って、単独または他のプラグインとともに動作可能です。値は次のいずれかになります。 PSWDONLY: デフォルト。パスワードのステータスのみを決定する、最もお薦めされる構成です。IDと認証は、UserIdentificationおよびUserAuthenticationプラグインを使用して実行する必要があります。 AUTHWITHPSWD: このプラグインの実行によって、認証とパスワードの両方が実行されます。 AUTHONLY: ユーザーの識別と認可はこのプラグインを使用した場合にのみ実行されます。
POLICY_SCHEMA	使用するポリシー・スキーマ	パスワード・サービス(UserPasswordPolicyPluginで使用)のスキーマを指定します。OAM10Gのみがサポートされています。 デフォルト: OAM10G
NEW_USERPSWD_BEHAVIOR	初回ログイン時にパスワードの変更を強制	新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。UserPasswordPolicyPluginに使用します。値は、次のどちらかになります。 FORCEPASSWORDCHANGE: パスワード変更を強制します。 NOFORCEPASSWORDCHANGE: パスワードのポリシー変更は、設定済のユーザー・パスワードには影響しません。 デフォルト: FORCEPASSWORDCHANGE
DISABLED_STATUS_SUPPORT	無効化されたアカウント・ステータスのサポート	無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。 デフォルト: TRUE
URL_ACTION	パスワード管理アクションURL	パスワード管理のために、ユーザーを移動するURLを指定します。ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。 REDIRECT_POST REDIRECT_GET FORWARD デフォルト: REDIRECT_POST
FedUserProvisioningPlugin
KEY_USER_RECORD_ATTRIBUTE_LIST	ユーザー属性のリスト	フェデレーション用です。ユーザー・レコードの作成に必要なアサーション属性を、カンマで区切ったリストです。
KEY_PROVIDERID_ATTRIBUTE_NAME	パートナ属性名	フェデレーション用です。LDAPユーザー・レコードの属性名です。このレコードの値は、ユーザーをプロビジョニングするときにパートナのアイデンティティ・プロバイダIDに設定されます。最初のフィールドはオプションであり、このフィールドを空にすると、パートナのアイデンティティ・プロバイダIDは、LDAPユーザー・レコードに設定されなくなります。
KEY_USERID_ATTRIBUTE_NAME	ユーザーのUserID属性	フェデレーション用です。LDAP UserIDとして使用されるアサーション属性の属性名です。
TAPIdentifyPlugIn
KEY_TAP_RETURN_ATTRIBUTE	ユーザー名マッピング属性	TAPIdentifyPlugInでアカウントをリンクするために使用する属性の名前です。
SequentialPlugInExecutionStrategy
StrategyName	編成戦略	SequentialPlugInExecutionStrategyに必要なプラグイン編成戦略の名前です。
KerberosTokenAuthenticator
KEY_KEYTAB_FILE	キー・タブ・ファイルの場所	Kerberosプリンシパルと暗号化されたキーを含むファイルの名前です。これは、KerberosTokenAuthenticatorに必要になります。
KEY_PRINCIPAL	OAMサービス・プリンシパル	OAMアカウントのSPNです。KerberosTokenAuthenticatorに必要になります。
KEY_KRB_CONFIG_FILE	Kerberos構成ファイルの場所	Kerberos構成プロパティ・ファイルの場所です。KerberosTokenAuthenticatorに必要になります。
KEY_DOMAIN_DNS2DN_MAP	ADドメインDNS名のDNへのマッピング	Active Directory DNSドメインのDNへのマッピングをカンマで区切ったリストです。KerberosTokenAuthenticatorに必要になります。
X509CredentialExtractor
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT	ユーザーのマッピング属性	X509証明書属性です。X509CredentialExtractorに必要なユーザー・マッピングに使用します。
KEY_IS_CERT_VALIDATION_ENABLED	証明書検証	X.509証明書の検証を有効または無効にします。X509CredentialExtractorに必要になります。
TAPRequestPlugin
TAPS2PVersion	統合プロトコルのバージョン	統合用のトークン・バージョンです。
TAPPartnerId	統合PartnerId	統合パートナ識別子です。
TAPChallengeURL	パートナ統合のエンドポイントURL	リモート・パートナーのエンド・ポイントURLです。
TAPUserAuthenticationPlugin
KEY_USERNAME_ATTRIBUTE	ユーザー名マッピング属性	アカウントのリンクに使用される属性の名前です。TAPUserAuthenticationPluginに必要になります。
KEY_CHECK_TOKEN_EXPIRY	トークンの有効期限チェックの有効化	統合トークンの有効期限を有効または無効にします。
TenantDisambiguationPlugin
KEY_FEDERATED_TENANTS	FederatedTenantNames	フェデレーテッド認証が有効にされている、オプションの各テナントの名前(カンマ区切り)です。プラグインは、フェデレーション・エンジンにテナントの名前が記述されていないことを問い合せます。
RSA SecurIDプラグイン
username	ユーザー名パラメータ	ユーザー名プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。
passcode	パスコード・パラメータ	パスコード・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。
nexttoken	次のトークン・パラメータ	次のトークン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。
newpin	新規PINパラメータ	新規ピン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。
confirmnewpin	新規PINの確認パラメータ	新規pinの確認プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。
HTTPTokenExtractor
KEY_HEADER_PROPERTY	HTTPヘッダー名	HTTPヘッダーのカンマ区切りのリストです。
KEY_COOKIE_PROPERTY	HTTP Cookie名	Cookieのカンマ区切りのリストです。

図16-11は、カスタム認証モジュールの「ステップ」サブタブと「詳細」セクションを示しています。ステップを追加する際には、表に表示するデータはありません。ただし、1つ以上のステップを表に追加すると、「詳細」セクションに移入されます。

図16-11 プラグイン・ベースの認証モジュールの「ステップ」と「詳細」

「図16-11 プラグイン・ベースの認証モジュールの「ステップ」と「詳細」」の説明

図16-12は、カスタム認証モジュールの「ステップ編成」サブタブを示しています。このサブタブには、定義された各ステップ(および各操作条件に対して選択したアクション)の情報が移入されます。

図16-12 プラグイン・ベースの認証モジュールの「ステップ編成」

「図16-12 プラグイン・ベースの認証モジュールの「ステップ編成」」の説明

表16-14では、「ステップ編成」サブタブの要素について説明します。OnSuccess、OnFailure、OnErrorで選択できるリストの項目は次のとおりです。

• 成功

• 失敗

• StepName (モジュールの任意のモジュールを、操作条件のアクションとして選択できます)

表16-14 「ステップ編成」サブタブ

要素	説明
初期手順	リストから開始ステップを選択します。リストに含まれるのは、このモジュールに定義されているステップのみです。
名前	このモジュールに追加された各ステップが、追加するときに入力した名前別にリストされます。
説明	ステップを追加するときにオプションで入力した、このステップの説明。
OnSuccess	操作が成功した場合に選択されるアクション。選択できるアクションがリストに示されます。 成功 失敗 StepName (次のステップをアクティブ化します)
OnFailure	このステップが失敗した場合に選択されるアクション。選択できるアクションがリストに示されます。 成功 失敗 StepName (次のステップをアクティブ化します)
OnError	このステップを実行してエラーになる場合に選択されるアクション。選択できるアクションがリストに示されます。 成功 失敗 StepName (次のステップをアクティブ化します)

16.7.3 マルチステップ認証のプラグイン・ベースのモジュールについて

図16-13は、現在使用できるネイティブなプラグイン・ベースの認証モジュールのリストです。

図16-13 Oracle提供のプラグイン・ベースの認証モジュール

次の各項では、事前移入済のプラグインで提供されるネイティブなカスタム・モジュールのいくつかについて説明します。これらを使用すると、独自のカスタム認証モジュールを編成できます。

• KerberosPlugin

• LDAPPlugin

• X509Plugin

• パスワード・ポリシー検証モジュールとプラグイン

関連項目: 表16-13「各種プラグインのパラメータの詳細」 例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法

KerberosPlugin

第43章の説明に従い、Windowsネイティブ認証用にAccess Managerを構成するときには、このプラグインを使用します。

図16-14は、Access Manager 11gにバンドルされているKerberosPluginモジュールを示しています。これはリソースを暗号化された「Kerberosチケット」にリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致する資格証明マッピング・モジュールです。

図16-14 KerberosPlugin

「図16-14 KerberosPlugin」の説明

図16-15は、デフォルトのステップと詳細を示しています。図16-16は、ステップの編成と条件を示しています。

図16-15 デフォルトのKerberosPluginステップと詳細

「図16-15 デフォルトのKerberosPluginステップと詳細」の説明

図16-16 デフォルトのKerberosPluginステップと編成

「図16-16 デフォルトのKerberosPluginステップと編成」の説明

LDAPPlugin

図16-17は、Access ManagerにバンドルされているLDAPPluginモジュールを示しています。デフォルトでは、図16-18のようにLDAPPluginには2つのステップがあります。図16-19は、LDAPpluginのステップのデフォルト編成を示しています。

図16-17 LDAPPlugin

「図16-17 LDAPPlugin」の説明

図16-18 デフォルトのLDAPPluginステップと詳細

「図16-18 デフォルトのLDAPPluginステップと詳細」の説明

図16-19 LDAPpluginのステップのデフォルト編成

「図16-19 LDAPpluginのステップのデフォルト編成」の説明

X509Plugin

図16-20は、Access Manager 11gにバンドルされているX509Pluginモジュールを示しています。X509PluginはLDAPPluginと似ていますが、LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示すプロパティが追加されています。図16-21は、このプラグインのデフォルトのステップと詳細を示しています。図16-22は、X509Pluginのステップのデフォルト編成を示しています。

図16-20 X509Plugin

「図16-20 X509Plugin」の説明

図16-21 X509Pluginのデフォルト・ステップと詳細

「図16-21 X509Pluginのデフォルト・ステップと詳細」の説明

このプラグインでは、ルートとサブのCA証明書をDOMAIN_HOME/config/fmwconfig/amtruststoreに追加する必要があります。X509CredentialExtractorプラグインがこの場所から証明書をロードするからです。

表16-15では、stepX509のサブジェクトとサブジェクト代替名の値をリストしています。これらの処理は、X509Pluginの使用時のみサポートされます。

関連項目: 表16-13「各種プラグインのパラメータの詳細」 例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法

表16-15 X509の「ステップの詳細」(KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT)

issuer.D	サブジェクト
subject.	EDIPI 注意: EDIPIはElectronic Data Interchange Personal Identifierの略です。
subjectAltName.	OTHER_NAME (FASC-N) 注意: FASC-NはFederal Agency Smart Credential Numberの略です。
subjectAltName.	RFC822_NAME
subjectAltName.	UNIFORM_RESOURCE_IDENTIFIER

図16-22 X509Pluginのステップのデフォルト編成

「図16-22 X509Pluginのステップのデフォルト編成」の説明

関連項目: 「SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合」

パスワード・ポリシー検証モジュールとプラグイン

Oracleでは、認証プロセスで次のプラグインを個別のステップとして採用するパスワード・ポリシー検証モジュールを提供しています。

• ユーザー識別ステップ

• ユーザー認証ステップ

• ユーザー・パスワード・ステータス・ステップ

図16-23は、「ステップ」タブを示しています。詳細は、図の後に説明します。

図16-23 パスワード・ポリシー検証モジュールのプラグイン

図16-24は、パスワード・ポリシー検証モジュールのプラグインの「ステップ編成」ページです。ステップの編成内容は、この図のとおりです。

関連項目: 表16-13「各種プラグインのパラメータの詳細」 「パスワード・ポリシーの理解」

図16-24 「ステップ編成」: パスワード・ポリシー検証プラグイン

16.7.4 SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合

Access Manager 11gはPIV (Personal Identity Verification)カード(米国連邦政府のスマート・カード)をサポートしており、これは、X.509認証時に、SubjectaltName拡張のFASC-NおよびEDIPI属性を使用してユーザーをマッピングするために使用されます。複数のOCSPプロバイダはサポートされませんが、OCSP Gatewayを使用するか、OSDT OCSP APIを使用するカスタム認証プラグインを作成することで、複数のOCSPプロバイダに対する検証を行うことができます。

次の機能は、X.509プラグイン(X.509認証モジュールではない)のみで使用できます。このプラグイン構成では、X.509クライアント証明書から抽出した属性のマップ先のLDAP属性を指定します。

例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法

1. Oracle Access Managementコンソールで、次に示すように、既存のX509Pluginを編集します(またはカスタムX509プラグインを作成します)。

   
   「システム構成」タブ
   「Access Manager」セクション
   「認証モジュール」ノード
   「カスタム認証モジュール」ノード
   X509plugin
   
   

   関連項目: 「プラグイン・ベースのマルチステップ認証モジュールの作成と編成」

   
   

   「一般」タブ:

   1. 名前: CustomX509Plugin。

   2. 「説明」: X509のカスタム・プラグイン

   「ステップ」タブ:

   1. 「+」をクリックして、プラグインにステップを追加します。

   2. 「名前」と「説明」を入力して、「X509CredentialExtractor」プラグインを選択します。

   「ステップの詳細」:

   1. KEY_IS_CERT_VALIDATION_ENABLED: true

   2. KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT (表16-15): subject.EDIPI, subjectAltName.OTHER_NAME (FASC-N), subjectAltName.RFC822_NAME, subjectAltName.UNIFORM_RESOURCE_IDENTIFIER

   3. 「Save」ボタンをクリックします。

   別のプラグインの追加:

   1. 「+」をクリックして、別のプラグインを追加します。

   2. 「名前」と「説明」を入力して、UserIdentificationPluginを選択します。

   2つ目のプラグインの「ステップの詳細」:

   1. 必要なアイデンティティ・ストアに関するKEY_IDENTITY_STORE_REFを設定します。

   2. KEY_LDAP_FILTER属性にLDAPフィルタを追加します。次に例を示します。

      (&(uid= 
      Unknown macro: {subject.CN} 
      )(mail=
      Unknown macro: {subject.E} 
      ))
      

   3. 必要な場合は、KEY_SEARCH_BASE_URL属性にユーザー検索ベースを追加します。

   4. 「Save」ボタンをクリックします。

   5. 「ステップ編成」タブ(ステップ2)に進みます。

2. ステップの編成:

   1. 「最初のステップ」: ドロップダウンから「X509CredentialPlugin」ステップを選択します。

   2. 「成功時」: 「X509CredentialPlugin」ステップで、ドロップダウン・リストから「UserIdentificationPlugin」を選択します。

   3. 「成功時」: 「UserIdentificationPlugin」ステップで、ドロップダウン・リストから「Success」を選択します。

   4. 「失敗時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」を選択します。

   5. 「エラー発生時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」を選択します。

   6. 「適用」ボタンをクリックし、プラグインが正常に作成されたことを示す確認ウィンドウを確認します。

3. OCSPを使用して、「証明書検証」と「証明書失効」に証明書検証モジュールを設定します。

   
   

   関連項目: 「グローバル証明書の検証および取消の管理」

   
   

   1. Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから、「証明書検証」を選択します。

   2. 「証明書失効リスト」セクションで、「有効」が選択されていることを確認し、「保存」をクリックします。

   3. 「OCSP/CDP」セクションでOCSPを有効にし、OCSPのURLと、OCSPサーバーの証明書のサブジェクトを入力し、「保存」をクリックします。

   4. コマンドラインでJavaのkeytoolアプリケーションを使用し、信頼できる証明書のエントリとして$DOMAIN_HOME/config/fmwconfig/amtruststoreキーストアに信頼できる証明書をインポートします。

      
      

      注意: 初期状態ではキーストアは空です。パスワードは、Java keytoolアプリケーションを最初に使用するときに設定されます。

      
      

16.7.5 プラグイン・ベースのマルチステップ認証モジュールの作成と編成

有効な管理者の資格証明を持つユーザーは、次の手順を使用して、1つ以上の認証プラグインを使用するカスタム認証プラグイン・モジュールを作成できます。

この手順は、認証モジュールの一般ステップの概要を示しています(オンライン証明書ステータス・プロトコル(OCSP)を使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスするために、認証X509モジュールを構成する場合のサンプル情報も含んでいます)。

関連項目: 「例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法」

前提条件

モジュールに関連付けられているユーザー・アイデンティティ・ストアが実行中であり、必要なユーザー移入が含まれていることを確認します。

バンドルされているプラグインを使用してカスタム認証モジュールを作成する手順

1. 「システム構成」タブの「Access Manager」セクションから、「認証モジュール」ノードを展開します。

2. 新規作成:

   1. 「カスタム認証モジュール」ノードをクリックします。

   2. 「作成」(+)ボタンをクリックします。

   3. 一般的な情報の追加: 「名前」と、オプションの「説明」。たとえば、順に「CustomX509Plugin」と「X509のプラグイン」とします。

      「適用」をクリックして一般情報を保存します。

3. ステップの追加:

   1. 「ステップ」サブタブをクリックします。

   2. 「ステップ」表の上にある「追加」(+)ボタンをクリックします。

   3. 「新規ステップの追加」ダイアログ・ボックスで、一意の「ステップ名」と、オプションで「説明」を入力します。

   4. 目的のカスタム・プラグイン名(たとえば、X509CredentialExtractor)を参照して選択し、「OK」をクリックします。

   5. 結果表の情報を確認します。

   6. モジュールに必要なすべてのプラグインがリストされるまで、bからeを繰り返して他のステップを追加します。

4. 「ステップの詳細」の定義: 要求されるパラメータに適切な値を使用します(表16-12、表16-13、表16-16「カスタム・プラグインの管理アクション」および「例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法」)。

   1. 表の「StepName」をクリックして必要な詳細を表示させ、必要な詳細に適切な値を入力します。

   2. OCSPを使用したユーザー証明書の検証:

      KEY_IS_CERT_VALIDATION_ENABLEDがtrueに設定されていることを確認します。

      KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACTで抽出される証明書属性を追加します(表16-15):

      subject.EDIPI
      subjectAltName.OTHER_NAME (FASC-N)
      subjectAltName.RFC822_NAME
      subjectAltName.UNIFORM_RESOURCE_IDENTIFIER
      

   3. 「Save」ボタンをクリックします。

   4. 手順を繰り返し、各ステップを適切に構成します。

   5. ステップで割り当てるユーザー・アイデンティティ・ストアに、ユーザーがプロビジョニングされていることを確認します。

5. ステップの編成: 表16-14を参照して、次の手順を実行します。

   1. 「ステップ編成」サブタブをクリックします。

   2. 「最初のステップ」リストで、使用する最初のステップの名前を選択します。

   3. 表でステップ名を選択します。

   4. 「OnSuccess」リストから、条件(成功または失敗)またはステップ名を選択します。

   5. 「OnFailure」リストから必要な条件またはステップ名を選択します。

   6. 「OnError」リストから必要な条件またはステップ名を選択します。

   7. 手順cからfを繰り返し、このモジュールの各プラグインの操作を編成します。

   8. 編成を確認します。

6. 方針の検証の開始: 「適用」をクリックして、編成方針の検証を開始します。

   • 方針が正常な場合: 編成方針が適用され、認証スキームにモジュールを追加できるようになります。ステップ9と10を続行します。

   • 方針が無効な場合: 「エラー」ボックスで「OK」をクリックし、OnSuccess、OnFailure、OnErrorの方針を編集(プラグインを追加または削除)して問題を修正します。方針が成功するまでこの手順を繰り返します。

7. ナビゲーション・ツリーで新しいカスタム認証モジュールがリストされていることを確認し、終わったらページを閉じます。

8. 「認証スキームの管理」の説明に従って、カスタム・モジュールを認証スキーム内で使用します。

16.8 個別の認証用プラグインのデプロイおよび管理

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

• 独自の認証プラグインの管理について

• 個別の認証用プラグインのデプロイおよび管理

• カスタム認証プラグインの削除

16.8.1 独自の認証プラグインの管理について

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の情報を使用すると、カスタム認証プラグインを作成して、そのプラグインをカスタマイズしたマルチステップ認証モジュールの定義に使用できるようになります。

プラグインの開発後、JARファイルとして管理サーバーにデプロイする必要があり、自動的に検証されます。検証後、管理者はOracle Access Managementコンソールを使用してプラグインを構成および配布できます。

サーバーは、プラグインJARファイル内のXML構成ファイルを処理し、プラグインに関するデータを抽出します。プラグインがインポートされた後、管理者はAdminServerから使用できる情報に基づいて様々なプラグインの状態を参照し、変更できます。

図16-25は、「システム構成」タブの「共通構成」セクションにあるプラグイン・ノードおよびプラグイン・ページを示しています。この「プラグイン」ページに含まれるツールバーのコマンド・ボタンは、その多くが表で選択されたプラグインに作用します。この表は、既存のカスタム・プラグインとその状態に関する情報を提供します。ページ最下部の「プラグインの詳細」セクションは、表内の選択されたプラグインの構成詳細を反映しています。

図16-25 「プラグイン」ページ

表16-16に示すように、管理者は「プラグイン」ページ上部の表の上にあるコマンド・ボタンを使用して、プラグインの状態を制御します。

表16-16 カスタム・プラグインの管理アクション

アクション・ボタン	説明
プラグインのインポート	プラグインJARファイルをAdminServer DOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。 同一のJAR名: 新規プラグインJAR名(DOMAIN_HOME/oam/plugins内)が既存のプラグインJAR名(DOMAIN_HOME/config/fmwconfig/oam/plugins内)と一致する場合、Oracle Access ManagerはJAR(DOMAIN_HOME/oam/plugins内)のXMLファイルから新規構成メタデータを抽出し、新規プラグインのバージョンをチェックします。 XMLバージョン: 新規プラグインXMLバージョン(DOMAIN_HOME/oam/plugins内)が既存のXMLバージョン(DOMAIN_HOME/config/fmwconfig/oam/plugins内)より新しい場合、検証は成功します。そうでない場合、無効なバージョンを持つ無効なプラグイン名が戻され、新規プラグインJARが削除されます(DOMAIN_HOME/oam/pluginsから)。 異なるJAR名: 新規プラグインJAR名(DOMAIN_HOME/oam/plugins内)が既存のプラグインJAR名(DOMAIN_HOME/config/fmwconfig/oam/plugins内)と異なる場合、新規プラグインJARがアップロードされ、検証は成功します。 成功時: ステータスが「アップロード済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アップロード済」と報告し、AdminServerにおけるステータスも「アップロード済」となります。 失敗時: ステータスは「アップロードに失敗しました」と報告されます。 関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム・プラグインのライフサイクルに関する項
選択項目の配布	登録済のすべてのOAMサーバーにプラグインを伝播します。 oam-config.xmlのプラグイン・フラグをDistribute=trueに設定します。 AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。 AdminServerノードからDOMAIN_HOME/config/fmwconfig/oam/pluginsの下の各OAMサーバー・ノードに、プラグインJARを配布します。 成功時: ステータスが「配布済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「配布済」と報告し、AdminServerにおけるステータスも「配布済」となります。 失敗時: ステータスは「配布に失敗しました」と報告されます。
選択項目のアクティブ化	プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。 アクティブ化: oam-config.xmlのプラグイン・フラグをActivate=trueに更新します。 AdminServerとOAMサーバーの間で、メッセージ・リスナーおよび通知メカニズムを起動します。 AdminServerは、登録済のすべてのOAMサーバーにメッセージ「アクティブ化」を送信します。 成功時: ステータスが「アクティブ化済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アクティブ化済」と報告し、AdminServerにおけるステータスも「アクティブ化済」となります。 失敗時: ステータスは「アクティブ化に失敗しました」と報告されます。 すべてのOAMサーバーについてアクティブ化した後、認証モジュールの作成または編成でプラグインを使用および実行できます。
選択項目の非アクティブ化	プラグインをアクティブ化した後で、管理者はプラグインが認証モジュールまたはスキームで使用されていない場合などに、プラグインの非アクティブ化を選択できます。登録済のすべてのOAMサーバーから選択されたプラグイン。 非アクティブ化: oam-config.xmlのプラグイン・フラグをDe-activate=trueに更新します。 AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。 AdminServerおよび登録済の各OAMサーバー(DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。 AdminServerは、登録済のすべてのOAMサーバーにメッセージ「非アクティブ化」を送信します。 OAMサーバーは、AdminServerおよびOAMサーバーの両方のメッセージ・リスナーを使用して、AdminServerにステータス・メッセージを送信します。 成功時: ステータスが「非アクティブ化」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「非アクティブ化」と報告し、AdminServerにおけるステータスも「非アクティブ化」となります。oam-config.xmlからプラグイン構成が削除されます。 注意: 非アクティブ化の後は、認証モジュールまたは編成でプラグインを使用または実行できません。 失敗時: ステータスは「非アクティブ化に失敗しました」と報告されます。
選択項目の削除	プラグインを非アクティブ化した後、管理者は選択したプラグインを削除できます。このプロセスでは、Oracle Access Managerは次の処理を実行します。 削除: oam-config.xmlのプラグイン・フラグをRemove=trueに更新します。 AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。 AdminServerおよび登録済の各OAMサーバー(DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。 AdminServerは、登録済のすべてのOAMサーバーにメッセージ「アクティブ化」を送信します。 成功時: ステータスが「削除済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「削除済」と報告し、AdminServerにおけるステータスも「削除済」となります。oam-config.xmlからプラグイン構成が削除されます。 失敗時: ステータスは「削除に失敗しました」と報告されます。

表16-17では、プラグイン・ステータス表の要素について説明します。

表16-17 プラグイン・ステータス表

要素	説明
プラグイン名	XMLメタデータ・ファイルのプラグイン名要素から抽出されます。
説明	XMLメタデータ・ファイルの説明要素から抽出されます。
アクティブ化のステータス	AdminServerの情報に基づいてアクティブ化のステータスが報告されます。
タイプ	XMLメタデータ・ファイルのタイプ要素から抽出されます。
最終更新日	XMLメタデータ・ファイルの作成日要素から抽出されます。
最終更新者	XMLメタデータ・ファイルの作成者要素から抽出されます。

このページの「プラグインの詳細」セクションでは、表16-17に示すように、「アクティブ化のステータス」がAdminServerによって維持されます。

図16-26 「プラグインの詳細」: 選択したプラグインのアクティブ化のステータス

プラグインによっては、様々な構成詳細がXMLメタデータ・ファイルの構成要素から抽出され、「プラグインの詳細」セクションの「構成パラメータ」に移入されます。これらの例を表16-18に示します。また、表16-13も参照してください。

表16-18 XMLメタデータ・ファイルから抽出されたプラグイン詳細の例

構成要素	説明
データソース	- <configuration> - <AttributeValuePair> <Attribute type="string" length="20">DataSource</Attribute> <mandatory>true</mandatory> <instanceOverride>false</instanceOverride> <globalUIOverride>true</globalUIOverride> <value>jdbc/CISCO</value> <AttributeValuePair> <configuration>
Kerberos詳細	このプラグインを使用するには、Kerberos詳細を定義します。
ユーザー識別詳細	このプラグインを使用するには、ユーザー・アイデンティティ・ストアおよびフィルタの詳細を定義します。
ユーザー認証詳細	このプラグインを使用するには、ユーザー・アイデンティティ・ストアを定義します。
X.509詳細	このプラグインを使用するには、証明書詳細を定義します。

16.8.2 カスタム・プラグインを使用可能にする手順

有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。

前提条件

カスタム・プラグインの開発の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

カスタム認証プラグインを使用可能にする方法

1. プラグインをインポートします。

   1. Oracle Access Managementコンソールに移動し、通常どおりログインします。次に例を示します。

      https://hostname:port/oamconsole/
      

   2. 「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。

   3. 「プラグインのインポート」ボタンをクリックします。

   4. 「プラグインのインポート」ダイアログ・ボックスで、「参照」をクリックしてプラグインJARファイルの名前を選択します。

      
      

   5. ダイアログ・ボックスのメッセージを確認し、「インポート」をクリックします。

      Oracle Fusion Middleware Oracle Access Management管理者ガイドに示されているように、JARファイルが検証されます。

2. パラメータの構成: 「プラグインの詳細」セクションを開き、「構成パラメータ」をクリックして、必要に応じて適切な情報を入力します。次に例を示します。

   
   

3. プラグインをOAMサーバーに配布します。

   1. プラグイン表で、プラグイン名をクリックして選択します。

   2. 「選択項目の配布」ボタンをクリックし、「アクティブ化のステータス」をチェックします。

      
      

4. プラグイン(およびカスタム・プラグイン実装クラス)をアクティブ化し、OAMサーバーで使用できるようにします。

   1. プラグイン表で、プラグイン名をクリックして選択します。

   2. 「選択項目のアクティブ化」ボタンをクリックし、「アクティブ化のステータス」をチェックします。

      
      

5. 必要に応じて次のタスクを実行します。

   • 認証プラグインのアクティブ化ステータスのチェック

   • カスタム認証プラグインの削除

   • プラグイン・ベースのマルチステップ認証モジュールの作成と編成

16.8.3 認証プラグインのアクティブ化ステータスのチェック

有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。

前提条件

カスタム・プラグインを使用可能にする手順

カスタム認証プラグインのアクティブ化ステータスをチェックする手順は、次のとおりです。

1. 「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。

2. プラグイン表で、目的のプラグイン名をクリックして選択します。

3. サーバー・インスタンス名: 「プラグインの詳細」セクションを開き、「アクティブ化のステータス」をクリックしてプラグインの場所とステータスを表示します。次に例を示します。

   
   

4. 必要に応じて次のタスクを実行します。

   • カスタム認証プラグインの削除

   • プラグイン・ベースのマルチステップ認証モジュールの作成と編成

16.8.4 カスタム認証プラグインの削除

有効な管理者資格証明を持つユーザーは、次の手順を使用してカスタム・プラグインを非アクティブ化してから削除できます。

管理者がカスタム認証プラグインを削除した場合、その名前はプラグインのリストから削除されません。プラグインを削除するには(同じプラグインを後で再インポートするため)、管理者はWebLogic Serverを停止し、oam-config.xmlを手動で編集する必要があります。

前提条件

プラグインが追加されており、コンソールで使用可能になっている必要があります。

カスタム認証プラグインを削除する手順は、次のとおりです。

1. Oracle Access Managementコンソールに移動し、通常どおりログインします。次に例を示します。

   https://hostname:port/oamconsole/
   

2. 「システム構成」タブの「共通構成」セクションから、「プラグイン」を開きます。

3. プラグインの非アクティブ化: プラグインを削除する前に、これを実行する必要があります。

   1. プラグイン表で、プラグイン名をクリックして選択します。

   2. 「選択項目の非アクティブ化」ボタンをクリックし、プラグインの「アクティブ化のステータス」をチェックします。

4. 非アクティブ化したプラグインの削除:

   1. プラグイン表で、プラグイン名をクリックして選択します。

   2. 「選択項目の削除」ボタンをクリックします。

   3. WebLogic管理サーバーを停止し、oam-config.xmlの場所を確認し手動で編集して、非アクティブ化したプラグインを削除してから、WebLogic管理サーバーを再起動します。

5. 必要に応じて次のタスクを実行します。

   • カスタム・プラグインを使用可能にする手順

   • プラグイン・ベースのマルチステップ認証モジュールの作成と編成

16.9 認証スキームの管理

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

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

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

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

• 認証スキームおよびページについて

• マルチレベル認証およびステップアップ認証の理解

• 認証スキームの作成

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

• 認証スキームの検索

16.9.1 認証スキームおよびページについて

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

図16-27 デフォルトのLDAPSchemeページ

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

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

表16-19 認証スキームの定義

要素	説明
名前	ナビゲーション・ツリーに表示されるこのスキームの一意の名前。 関連項目: 「事前構成済認証スキーム」
説明	このスキームの使用を示す200文字までのオプションの説明。
認証レベル	認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。 信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。 注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表17-1「リソース定義の要素」を参照してください。 注意: 指定されたレベルのリソースにユーザーが認証された後、リソースが元のリソースと同等またはそれ以下の信頼レベルである場合に同じアプリケーション・ドメインまたは異なるアプリケーション・ドメインの他のリソースでユーザーが自動的に認証されます。 関連項目: 「マルチレベル認証およびステップアップ認証について」
デフォルト	「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックス。
チャレンジ・メソッド	リストの選択可能な項目からチャレンジ・メソッドを1つ選択する必要があります。 フォーム Basic(LDAP) X509(証明書) WNA(Windows固有の認証) なし DAP OAM10g 関連項目: 「チャレンジ・メソッドについて」
チャレンジ・リダイレクトURL	このURLは、資格証明コレクタ(ECCまたはDCC)を参照するエンド・ポイントを宣言します。次に例を示します。 ECC: /oam/server DCC: http://<dcc-host:port>/ 関連項目: 「ホスト識別子について」 「DCC対応の11g Webgateと認証ポリシーの構成」
認証モジュール	ユーザーに資格証明を要求するために使用する事前構成済認証モジュールを指定します。ここで指定されたモジュールまたはプラグインによって、使用する正確なユーザー・アイデンティティ・ストアが指定されます。 FederationMTPlugin FederationPlugin Kerberosプラグイン(「認証モジュール」と「カスタム認証モジュール」) MTLDAPBasic MTLDAPPlugin OIFMTLDAPPlugin パスワード・ポリシー検証モジュール TAPModule X509プラグイン(「X509認証モジュール」ノードの下) 関連項目: 「ネイティブ認証モジュールの管理」および「プラグイン・ベースのモジュールによるマルチステップ認証の編成」。
チャレンジURL	このURLは、指定されているチャレンジ・メソッド(FORMなど)に関連付けられます。 フォーム・ベースの即時利用可能な認証スキーム(LDAPSchemeおよびLDAPNoPasswordValidationScheme)の場合、チャレンジURLは「/pages/login.jsp」です。最後のURLを作成するには、コンテキスト・タイプおよびコンテキスト値を使用します。 X509ベースのチャレンジURLは、次の形式で指定します。https://managed_server_host:managed_server_ssl_port/oam/CredCollectServlet/X509 注意: デフォルトのチャレンジURLは、OAMサーバーの組込み資格証明コレクタ(ECC)に基づいています。外部資格証明コレクタが有効化されたWebゲートと、Webゲートとともにインストールされる関連DCCページを使用している場合は、「DCC対応の11g Webgateと認証ポリシーの構成」を参照してください。
チャレンジ・パラメータ	サポートされているチャレンジ・パラメータの詳細は、「認証スキームのチャレンジ・パラメータについて」を参照してください。
フォーム、X509またはDAPチャレンジ・メソッドを使用したスキーム	この後の要素は、チャレンジ・メソッドとしてフォーム、X509またはDAPを使用するスキームにのみ含まれます。他のスキームは、変更する必要がないデフォルトを使用します。
コンテキスト・タイプ	次の使用可能な値に基づいて、埋込み資格証明コレクタの最後のURLを作成するために使用します(ECC専用です。DCCには使用しません)。 デフォルト: コンテキスト値を使用して、資格証明コレクションのために送信する最後のURLを作成します。たとえば、チャレンジURLが「/pages/login.jsp」、コンテキスト値が/oamの場合、サーバーはECCによる資格証明コレクションのために「/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チャレンジ・メソッドを使用したスキームのみ、表16-19の最後に示されている追加要素が含まれます。すべてのカスタム・ログイン・ページで次の要件を満たす必要があります。

• カスタム・ログイン・ページには、2つのフォーム・フィールド(ユーザー名およびパスワード)が必要です。Access Managerは、カスタム・フォームをサポートしています(『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照)。

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

  • 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」などです。

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

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

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

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

関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびメッセージのカスタマイズの詳細

16.9.1.1 事前構成された認証スキーム

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

表16-20 事前構成済認証スキーム

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

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

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

• フォーム

• 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クライアント証明書を確認する必要があります。

Access Managerに関連付けられているユーザー・アイデンティティ・ストアに対して、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認証モジュールに基づいています。

関連項目: 第43章: Windows固有の認証との統合の詳細

なし

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

DAP

委任認証プロトコル(DAP)チャレンジ・メソッドは、認証モジュールがDAP、コンテキスト・タイプが外部であるOIFScheme (Oracle Identity Federation 11.1.1統合)で必要です(表16-19)。DAPチャレンジ・メカニズムでは、外部オプションを使用する標準チャレンジのフォーム・メカニズムと異なり、Access Managerが受け取ったトークンのアサーションを実行します。

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

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

DAPTokenは、Access ManagerとIdentity Federationによって共有されるキーで暗号化および復号化されます。DAPTokenは、Access Manager側で構築されます。

Identity Federation管理EMコンソールでは、Access ManagerとIdentity Federationの間の通信を保護するために使用される暗号化鍵を含むキーストアを生成できます。Access ManagerのWLSTコマンド(registerOIFDAPPartner)は、Identity Federationストアによって生成されるキーストアの場所を受け取り、キーを取得して、Identity Federation側に格納します。

OAM10G

このメカニズムは、OSSO 10gと共存するOracle Access Manager 10g向けに作成されています。OAM10Gメソッドは常に認証/認可のプロバイダとして動作します。また、Oracle Access Manager 10gがドメインを保護し、さらにOSSO 10g統合クラシック・アプリケーション(Portal、Discoなど)を含んでいる場合に、OAM10gSchemeとLDAPNoPasswordAuthModuleを使用して信頼関係を円滑化するために、OAM10Gメソッドが必要です。

OSSO10GはWebgateを通じてOAM10Gチャレンジ・メソッドで保護されます。OAM10Gは、常に認証/認可プロバイダとして動作します。

統合の促進: OSSO 10g統合クラシック・アプリケーションをAccess Managerにアップグレードできます。その場合、Access Managerは、アサーション・プロバイダとしてのみ動作します。Access Managerは、これらのアプリケーションがアクセスできるように、mod_ossoが消費できるトークンを作成します。mod_ossoアプリケーションは、新しい「OAM10gScheme」で保護されます。OAMサーバーのフロント・エンド処理を行い、10gアクセス・サーバーに対して構成されているWebgateが存在します。

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

関連項目: 表16-20のOAM10gScheme Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのenableCoexistModeおよびdisableCoexistModeに関する項

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

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

チャレンジ・パラメータは、次の構文で指定します。

<parmatername>=<value>

これは、Webgateのリリース(10gと11g)に固有の構文ではありません。認証スキームは、Webgateのリリースから独立しています。

表16-21は、チャレンジ・パラメータを持つ事前構成済のスキームを示しています。

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

事前構成済スキーム	チャレンジ・パラメータ
BasicSessionlessScheme	CookieLessMode=true 主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。
FederationMTScheme	initial_command=NONE 主に、複数要因認証をサポートするFusion Applicationsに使用されます。 is_rsa=true 第42章「Integrating RSA SecurID Authentication with Access Manager」および『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、RSAマルチステップ認証で使用されます。
FederationScheme Identity Federation 11.1.2のみ。Oracle Identify Federation 11.1.1の場合はOIFSchemeを使用します。	主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 コンテキスト値: /fusion_apps チャレンジ・パラメータ: initial_command=NONE is_rsa=true 主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。
OAAMBasic	oaamPostAuth=true oaamPreAuth=true OAAM関連のリソースを保護します。これらのパラメータは、OAAMとの基本統合が必要な場合に使用します。
OIFScheme Oracle Identify Federation 11.1.1のみ。Identity Federation 11.1.2の場合はFederationSchemeを使用します。	TAPPartnerId=OIFDAPPartner このスキームは、認証をOracle Identity Federation 11.1.1に委任し、その後、FederationがOAMサーバーによってアサートされているトークンを送信します。
TapScheme	TAPPartnerId=TAPPartnerName

認証スキームは、リクエストをアクセス・サーバーに送信する前に、コンテキスト固有の情報を収集できます。コンテキスト固有の情報は、情報の外部コールの形を取ることができます。表16-22に、認証スキームで使用できるユーザー定義チャレンジ・パラメータを示します。

表16-22 認証スキームのユーザー定義チャレンジ・パラメータ

チャレンジ・パラメータ	定義
initial_command=NONE	収集対象の資格証明を指示する場合に必要です。 たとえば、フォームベースの認証の場合、通常、このフレームワークではログイン・ページから送信される「username」と「password」を収集することになります。ただし、ログイン・ページの別のフィールド(たとえば、「form_username」と「form_password」)からの資格証明が必要になることがあります。このチャレンジ・パラメータを設定すると、初期制御をログイン・ページからプラグインに移すことができます。このプラグインで、ログイン・ページから収集するパラメータを判断してから、ログイン・ページに適切に転送またはリダイレクトします。 デフォルト: 空白(未設定)
action=	actionパラメータは、ハード・コードされたECCデフォルトの/oam/server/auth_cred_submitを使用しないときに、HTMLフォームのポスト先URLを指定します。 注意: ECCは、action=パラメータを使用しません。action=チャレンジ・パラメータが指定されていない場合、DCCとECCは、どちらもデフォルトの/oam/server/auth_cred_submitを使用します。 関連項目: 「PasswordPolicyValidationSchemeの構成」
creds= DCCのみ	外部資格証明コレクタ(DCC)でのみサポートされます。 次の例では、usernameとpasswordは、ログイン・フォームの該当するフィールドの名前です。 creds=username password 次に、もう一つの例を示します。 creds:source$name このsourceは、次のいずれかを指します(省略時は次の順序でソースを検索します)。 server (他のWebサーバー・プラグインによって設定される変数) header (HTTPヘッダー変数) post (ポストされたデータ) query (問合せ文字列データ) cookie (HTTP Cookie) Webサーバーのソース(サーバー・パラメータ)は、他のソースより優先されます。これにより、ユーザーが設定するリクエスト・データがWebサーバーのデータをオーバーライドすることが防止されます。たとえば、ユーザーから送信されたremote_user Cookieは、Webサーバーによって設定されたremote_user変数を上書きしません。 一般に、フォームベースのチャレンジ・メソッドを使用する認証スキームで保護されているログイン・フォームをユーザーが送信すると、DCCは、このcreds=パラメータで指定された資格証明を処理します。 METHOD=POST処理を使用するフォームの場合、リクエストの本体にフォームからの資格証明データを付けてブラウザがPOSTリクエストをWebサーバーに送信します。フォームでMETHOD=GETが使用されている場合は、credsパラメータに指定されたものと同じ名前を持つ問合せ文字列パラメータを付けてブラウザがGETリクエストを送信します。可能な場合はPOSTプロセスを使用することをお薦めします。 注意: credsパラメータは、他のタイプのチャレンジ・メソッドにも指定できます。プラグインでcredsパラメータを使用する場合、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、ObUserSessionオブジェクトのobMap資格証明パラメータで渡す内容を指定します。 関連項目: 「PasswordPolicyValidationSchemeの構成」
extracreds= DCCのみ	DCCでのみサポートされます。オプションのパラメータを指定します。オプションのパラメータが存在するときには、DCCを使用するマルチステップ認証の各反復時に、認証プラグインは、そのパラメータを収集できるようになります。 extracredsパラメータは、credsパラメータと同じ構文を使用します。extracreds=で分離した修飾名または非修飾名の[{any | cookie | header | server | query | post}:] <name>になります。ただし、値anyは、extracredsにのみ使用します。次に例を示します。 extracreds=[{any | cookie | header | server | query | post}:] <name> 関連項目: 「PasswordPolicyValidationSchemeの構成」
OverrideRetryLimit=0	ログインのRetryLimitを上書きする試行回数です。 値は正整数である必要があります。 0を指定すると、この機能は無効になります。 関連項目: 「PasswordPolicyValidationSchemeの構成」
MaxPostDataBytes=	ユーザーの資格証明として送信され、OAMサーバーに送信されるPOSTデータの最大バイト数を制限します。 関連項目: 「PasswordPolicyValidationSchemeの構成」
ssoCookie=	OAMAuthnCookie Cookieを制御します。「暗号化Cookieのチャレンジ・パラメータの構成」を参照してください。 デフォルト: ssoCookie=httponly ssoCookie=Secure 次のどちらかの設定で無効化されます。 ssoCookie=disablehttponly ssoCookie=disableSecure 注意: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。 外部資格証明コレクタが有効化された11g Webgateの場合、これらのパラメータはエージェント登録ページで直接設定します。 DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは認証スキーム内のユーザー定義チャレンジ・パラメータを通じて構成します。 関連項目: 表16-23「10g/11g暗号化Cookieのチャレンジ・パラメータ」
miscCookies=	その他の各種のAccess Manager内部Cookiesを制御します。デフォルトでは、httponlyは、その他の(各種の)すべてのCookiesに対して有効化されています。 デフォルト: miscCookies=httponly miscCookies=Secure 次のどちらかの設定で無効化されます。 miscCookies=disablehttponly miscCookies=disableSecure 注意: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。 外部資格証明コレクタが有効化されたWebgateの場合、これらのパラメータはエージェント登録ページで直接設定します。 DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは同じ名前のチャレンジ・パラメータを通じて構成します。 関連項目: 表16-23「10g/11g暗号化Cookieのチャレンジ・パラメータ」 「PasswordPolicyValidationSchemeの構成」
DCCCtxCookieMaxLength= DCCのみ	DCC Cookieの最大長を定義します。 デフォルト:4096 関連項目: 詳細は、この表のTempStateModeを参照してください。
TempStateMode=	次に示すパラメータの値(cookieまたはform)での指定に応じて、DCCがOAMサーバーの状態を格納する方法を制御します。 form: デフォルトです。OAMサーバーの状態は、フォーム・パラメータのOAM_REQを通じて格納され渡されます。これにより、OAMサーバーの構成がserverRequestCacheType=COOKIEのときに、肥大化したサーバーの状態がDCCCtxCookieの制限を超えて異常な動作が発生することを防止します。 Cookieキャッシュ・モードは、デフォルトのCOOKIEモードからFORMモードへ変更できます。FORMモードは、長いURLで機能します。動作における唯一の違いは、プログラム認証用であり、OAM_REQパラメータ・セットをフォームに渡すためには適切なフォームの提出が必要になるということです。カスタム資格証明収集ページで、フォームと一緒に提出されるOAM_REQパラメータを処理する必要があります。 cookie: このパラメータと値を追加すると、OAMサーバーの状態はDCCCtxCookieの一部(encdata=… svrctx=…)を通じて格納されます。ただし、serverRequestCacheType=COOKIEまたは=FORMのときに、結果のCookie長がブラウザの制限を超えると、異常な動作が発生することがあります。 注意: serverRequestCacheType=COOKIEの場合は、TempStateMode=formをお薦めします。 serverRequestCacheType=BASICの場合は、どちらのモードでもかまいません。 serverRequestCacheTypeを更新する場合は、WLSTコマンドのconfigRequestCacheTypeを使用します。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。Oracle Access Managementコンソールを使用したserverRequestCacheTypeの編集は、サポートされていません。 ECCの場合: serverRequestCacheTypeでは、OAMサーバーがサーバーの状態をメモリー内(BASIC)に格納するか、メモリー外(FORMまたはCOOKIE)に格納するかを指示します。serverRequestCacheType = COOKIEまたはFORMは、ECCを使用する場合にのみ効果に違いがあります。OAMサーバーは、サーバーの状態をリクエスト・トークンに格納します。ECCは、パラメータでの指定(たとえば、serverRequestCacheType=COOKIE)に応じて、Cookieまたは非表示のフォーム・フィールドにこれを保持します。 DCCの場合: serverRequestCacheType=COOKIEまたはFORMに違いはありません。TempStateModeは、DCCがOAMサーバーの状態を格納する方法(cookieまたはform)を、パラメータ値の指定(たとえば、TempStateMode=cookie)に応じて制御します。 関連項目: 「DCC対応の11g Webgateと認証ポリシーの構成」

16.9.2 マルチレベル認証およびステップアップ認証の理解

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

• マルチレベル認証およびステップアップ認証について

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

• 10g OSSOエージェントを使用したマルチレベル認証の処理

16.9.2.1 マルチレベル認証およびステップアップ認証について

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

• LDAPScheme authLevel=1

• KerbScheme authLevel=2

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

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

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

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

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

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

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

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

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

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

関連項目: 例は、Oracle Fusion Middleware Oracle Identity Management Suite統合ガイドの「Oracle Access ManagerとOracle Adaptive Access Managerの統合」の章を参照してください。すでに認証されているユーザーが、Access Managerを使用して低い認証レベルの別のリソースにアクセスします。ユーザーはすでに認証されているので、Oracle Adaptive Access Managerはユーザー名およびパスワードを入力するページを表示しません。ただし、Oracle Adaptive Access Managerで実行されるフローは、ユーザーがOracle Adaptive Access Managerにすでにログインしているかどうかによって異なります。

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

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

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

サーバー側で認証レベルの確認は行われません。次の例は、10g OAMエージェントについての説明です。

注意: 11g OAMエージェントは、エージェントごとに個別のOAMAuthnCookiesに関連付けられます。

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

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

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

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

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

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

16.9.2.3 10g OSSOエージェントを使用したマルチレベル認証の処理

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プロキシ)は再認証を要求します。

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

16.9.3 認証スキームの作成

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

前提条件

認証モジュールは、定義済であり使用できる状態であることが必要です(「個別の認証用プラグインのデプロイおよび管理」を参照)。

関連項目: 「認証スキームおよびページについて」 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」(必要な場合)

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

1. Oracle Access Managementコンソールで、次に進みます。

   
   「ポリシー構成」タブ
   「共有コンポーネント」ノード
   「認証スキーム」ノード
   

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

3. 新しい「認証スキーム」ページ(表16-19)で、デプロイメントに応じて次の情報を入力します。

   1. 名前: LDAPSimpleFormScheme

   2. 認証レベル

   3. チャレンジ・メソッド: フォーム

   4. チャレンジ・リダイレクトURL: http://CredentialCollectorhost:port

   5. 認証モジュール: LDAP

   6. チャレンジURL: /CredentialCollector/loginform...

   7. チャレンジ・パラメータ: 表16-21、表16-22、表16-23

   8. コンテキスト・タイプ

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

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

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

7. ナビゲーション・ツリーで、新しいスキームがリストされていることを確認します(必要に応じて、ツリーを更新してください)。

8. 「特定のリソースの認証ポリシーの定義」に進みます。

16.9.4 認証スキームの検索

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

関連項目: 「コンソールを使用した検索の実行」

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

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

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

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

   OA*
   

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

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

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

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

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

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

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

16.9.5 認証スキームの表示、編集または削除

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

注意: 認証ポリシーに関連付けられている認証スキームを削除しようとすると、関連付けの詳細が表示され、確認を求められます。ポリシーが関連付けられていない場合、スキームは削除されます。

関連項目: 「認証スキームおよびページについて」 「PasswordPolicyValidationSchemeの構成」

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

1. Oracle Access Managementコンソールで、目的のスキームを開きます。

   
   「ポリシー構成」タブ
   「共有コンポーネント」ノード
   「認証スキーム」ノード
   DesiredScheme
   

2. 編集:

   1. 「認証スキーム」ページで、環境に合わせて値を変更します(表16-19)。

      
      

      注意: OSSOエージェントを使用するアップグレード済のデプロイメントでは、SSOCoExistMigrateSchemeを使用するように、この認証スキームとすべての保護されたリソース・ポリシーを変更します。

      
      

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

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

3. デフォルトとして設定: 新しいアプリケーション・ドメインでポリシーを作成する際にこのスキームが自動的に使用されるようにするには、「デフォルトとして設定」ボタンをクリックして「確認」ウィンドウを閉じます。

4. 削除:

   1. この認証スキームを使用しているアプリケーション・ドメインがあるかどうかを確認し、あれば別のスキームを割り当てます。

   2. 「認証スキーム」ページを確認してこれが削除するスキームであることを確認し、ページを閉じます。

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

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

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

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

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

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

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

16.10.1 暗号化Cookieのためのチャレンジ・パラメータ

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

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

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

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

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

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

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

注意: チャレンジ・パラメータの値は、大文字/小文字が区別されません。どのリリースのWebゲートでも、構文は同じです。単一の値は、等号(=)の後ろに指定します。 ssoCookie=value 複数の値は、セミコロン(;)で区切る必要があります。次に例を示します。 ssoCookie=value1;value2;... 外部資格証明コレクタが有効化されたWebgateの場合、これらのパラメータはエージェント登録ページ(表13-2)で直接設定します。 DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは認証スキームのチャレンジ・パラメータ(表16-23)を通じて構成します。

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

表16-23 10g/11g暗号化Cookieのチャレンジ・パラメータ

暗号化Cookieの11g/10g Webgateチャレンジ・パラメータの構文	説明
ssoCookie=	SSO CookieのOAMAuthnCookieのフラグを制御するパラメータです。
miscCookies=	その他すべてのAccess Manager暗号化Cookieのフラグを制御するパラメータです。
Secure	HTTPSによってリソースにアクセスした場合のみ、暗号化Cookieが送信されるようにします。ブラウザがHTTPSを使用してサーバーにアクセスする場合のみ、セキュアなCookieが必要です。 ssoCookie=Secure miscCookies=Secure
disableSecure	セキュアCookieを明示的に無効にします。 ssoCookie=disableSecure miscCookies=disableSecure
httponly	11g Webgate SSO OAMAuthnCookieと、その他のCookieをデフォルトで有効にします。 ssoCookie=httponly miscCookies=httponly
disablehttponly	httponly機能を明示的に無効にして、クライアント側のスクリプトが暗号化Cookieにアクセスできるようにします。 ssoCookie=disablehttponly miscCookies=disablehttponly
ssoCookie=max-age=time-in-seconds	ブラウザ内に永続Cookieを作成します。これは、1つのセッションの間保持されるものではなく、Cookieの有効期限は時間間隔in-secondsで指定します。 たとえば、Cookieを30日(2592000秒)で期限切れにするには、次のように設定します。 max-age=2592000

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

チャレンジ・パラメータは、大文字/小文字が区別されません。

関連項目: 「認証スキームの作成」

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

1. 認証スキームを作成します。

2. 「チャレンジ・パラメータ」フィールドで、目的の暗号化Cookie(表16-23)の指定内容を入力します。

3. 付録Cの説明に従って、OAMサーバーとクライアント(OAMエージェント)が、Oracle Accessプロトコル・チャネルを介してセキュアに通信していることを確認します。

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

チャレンジ・パラメータは、大文字/小文字が区別されません。

関連項目: 「認証スキームの作成」

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

1. 認証スキームを定義します。

2. このスキームのチャレンジ・パラメータのセクションで、次を追加します(表16-23)。

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

16.11 パスワード・ポリシーの理解

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

• あらかじめ用意されたパスワード・フォームおよび機能のプレビュー

• Oracle Access Managementコンソールでのパスワード・ポリシー・ページのプレビュー

• 資格証明コレクタとパスワード・ポリシーの検証について

16.11.1 あらかじめ用意されたパスワード・フォームおよび機能のプレビュー

Access Managerは、資格証明の収集時にユーザーとの対話用にいくつかのページを提供します(資格証明コレクタのパスワード・ページを参照)。この場所は、デプロイする認証スキームのトポロジーに応じてカスタマイズできます。

表16-24 資格証明コレクタのパスワード・ページ

資格証明コレクタ	説明
ECCページ	デフォルトの埋込み資格証明コレクタのjspフォーム。デフォルトでOAMサーバーに配置されます。 ログイン・ページ: /pages/login.jsp ログアウト・ページ: /pages/logout.jsp エラー・ページ: /pages/servererror.jsp マルチステップ認証ページ: /pages/mfa.jsp
DCCページ	DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。Webgateホストの次の項目を参照してください。 WEBGATE_HOME/webgate/ohs/oamsso/* WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl(login、logoutおよびsecuridスクリプトの最初の行にあるPerlの場所を更新してください) WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/* 関連項目: ページおよびメッセージのカスタマイズの詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

表16-25に、提供されるパスワード・フォームを示します。デフォルト・ページは企業の要求に合せてカスタマイズしたり、すべてをカスタム・ページと置き換えたりできます。たとえば、デスクトップ・ブラウザ用のログイン・フォームと異なるものをモバイル・ブラウザ用に表示するために、カスタム・ページを設計、実装およびデプロイできます。

表16-25 パスワード管理フォームと機能

フォーム	機能
サインイン・フォーム	「ユーザーID」と「パスワード」フィールドを表示する標準的なログイン・フォームです。「ログイン」ボタンをクリックすると、認証モジュールによって制御される認証プロセスが開始されます。 ログイン・フォームのカスタマイズ方法の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
サインイン・エラー	この標準のログイン・フォームはエラーが発生したときに表示されます。赤く表示された文字は、エラーを示します。このエラーは表示と非表示を指定できます。 表示と非表示の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。
パスワードの期限切れの通知	次のメッセージは、通知ポリシーに従って、ユーザーにパスワードの期限が切れることを通知するために表示されます。
パスワードの変更フォーム	パスワードの期限切れポリシーの構成に従って、ポリシーを施行し、ユーザーにパスワードの変更を要求する次のウィンドウが表示されます。
パスワードの変更の成功	次のパスワードの変更が成功したことを確認するメッセージが表示されます。
ユーザー・アカウントのロックまたは無効化	許可される最大ログイン試行回数の範囲内で、パスワード・ポリシーに基づいて指定した資格証明が拒否された場合は、ユーザー・アカウントのロックアウトが発生します。

16.11.2 Oracle Access Managementコンソールでのパスワード・ポリシー・ページのプレビュー

図16-28は、Oracle Access Managementコンソールで表示した「パスワード・ポリシー」ページを示しています。管理者はこのページで、企業の要求に従ってポリシーを定義します。

図16-28 パスワード・ポリシー構成ページ

表16-26は、構成可能なパスワード・ポリシーの要素の説明です(コンソールの左から右の順番に記載されています)。これらの要素は、ECCとDCCの両方で使用します。

表16-26 パスワード・ポリシーの要素

要素	説明
最小大文字数	パスワードに必要な大文字の最小数を定義します。
最小小文字数	パスワードに必要な小文字の最小数を設定します。
最小英字数	パスワードで許可される特殊文字の最小数を定義します。
最小数字数	パスワードに必要な数字の最小数を設定します。
最小英数字数	パスワードに必要な英数文字の最小数を定義します。
最小特殊文字数	パスワードに必要な特殊文字の最小数を設定します。
最大特殊文字数	パスワードで許可される特殊文字の最大数を定義します。
最小Unicode文字数	パスワードに必要なUnicode文字の最小数を定義します。
最大Unicode文字数	パスワードで許可されるUnicode文字の最大数を設定します。
パスワードの最小文字数	パスワードに必要な合計の最小文字数を設定します。
最大パスワード長	パスワードで許可される合計の最大数文字数を定義します。
必須の文字	パスワードに必要な特定の文字を定義します。この定義にはデリミタは必要なく、また使用できません。
許可されていない文字	パスワードで使用可能な特定の文字を設定します。この定義にはデリミタは必要なく、また使用できません。
許可されている文字	パスワードで許可されるすべての文字を定義します。この定義にはデリミタは必要なく、また使用できません。
許可されていないサブ文字列	パスワードで許可されない特定の文字列です。この定義ではカンマをデリミタとして使用します。
アルファベットで始まる	選択時は、パスワードの先頭文字に英文字が必要であることを指定します。
姓の許可	選択時は、ユーザーの姓がパスワードに含まれることを許可します。
名の許可	選択時は、ユーザーの名がパスワードに含まれることを許可します。
ユーザーIDの許可	選択時は、ユーザーのユーザーIDがパスワードに含まれることを許可します。
警告までの時間	ユーザーにパスワードが期限切れになることをいつ(何日前に)警告するかを定義します。
最大試行回数	ユーザーがロックアウトになるまでに行えるログイン試行回数を示します。
有効期限切れまでの時間	パスワードの有効期間(日数)を定義します。
ロックアウト期間	指定された回数だけログイン試行が失敗した後に、ユーザーがロックアウトされる期間(分単位)を示します。この期間の後、ユーザーは新たにログインを試行できます。
永続的ロックアウト	指定された回数だけログイン試行が失敗した後の永続的ロックアウトを指定します。
姓の禁止	ユーザーがパスワードを変更するとき、いくつ前のパスワードまで使用できないかを定義します。
パスワード辞書ファイル	パスワードで指定できない禁止単語のリストを含むOAMサーバー上の物理ファイルを示します。
パスワード・ファイル・デリミタ	パスワード辞書ファイルでいくつかのワードを区切るために使用するデリミタを定義します。たとえば、ファイルの内容がabc,def,welcomeで、辞書のデリミタがカンマ(,)の場合、ユーザー・パスワードで禁止され、使用できない単語はabc defとwelcomeです。
パスワード・サービスURL	いくつかのパスワード・ページの場所です。

16.11.3 資格証明コレクタとパスワード・ポリシーの検証について

資格証明コレクションにどの方法を選択していても、1つのグローバル・パスワード・ポリシーを構成して、Access Managerで(認証スキームのパスワード・ポリシー検証モジュールを使用して)保護するリソースのすべてに適用することになります。また、資格証明コレクタと関連するフォームに対応するURLは、表16-27で説明したように指定する必要があります。

表16-27 認証用の資格証明コレクタと関連フォームの指定

指定する場所	ECCの場合	DCCの場合
OAMエージェント登録 DCCのみ	なし。	OAMエージェント登録ページの「管理操作の許可」の横にあるチェック・ボックスを選択します。 関連項目: 「DCCの資格証明操作の有効化」
ログイン、エラーおよびパスワード・ページ	ユーザーが資格証明を入力するページです。OAMサーバーにデフォルトで付属し、追加の設定や変更は必要ありません。 ログイン・ページ: /pages/login.jsp ログアウト・ページ: /pages/logout.jsp エラー・ページ: /pages/servererror.jsp マルチステップ認証: /pages/mfa_login.jsp	DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。 Webgateホストのディレクトリ(WEBGATE_HOME/webgate/ohs/oamsso/*、WEBGATE_HOME/webgate/ohs/oamsso-bin/*plおよびWEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*)で、次を参照してください。 ログイン・ページ: /oamsso-bin/login.pl ログアウト: /oamsso-bin/logout.pl RSA SecurIDログイン・ページ: /oamsso-bin/securid.pl DCCベースのログインおよびログアウトを行うPerlスクリプト Perl実行ファイルのパス名は、Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso-bin/*plにあるOracle提供のPerlスクリプト内で、実際の場所と一致するように更新する必要があります。 関連項目: 表16-5「DCCとECCの比較」
パスワード・ポリシー、パスワード・サービスURL	Default/ECCのパスワード・ページが自動的に使用されます。 ECCのパスワード・サービスURL: /oam/pages/pswd.jsp 関連項目: 「グローバル・パスワード・ポリシーの定義」	DCCパスワード・ページに次を入力します。 DCCのパスワード・サービスURL: /oamsso-bin/login.pl 関連項目: 「パスワード・ポリシーのDCCフォームの検索と更新」
ユーザー・アイデンティティ・ストア	Access Managerスキーマのユーザー・データー・オブジェクト定義は、パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性で拡張されます。この定義は、LDIFファイルで指定して、ldapaddツールを使用して各ユーザー・アイデンティティ・ストアに追加する必要があります。オラクル社が提供するLDIFについて表16-28に示します。	DCCとECCのどちらについても同じです。 関連項目: 「デフォルト・ストアへのキー・パスワード属性の追加」 「パスワードの変更後ユーザー属性を変更するために管理者を追加」
パスワード・ポリシー検証認証モジュール	3つの各プラグイン/ステップのKEY_IDSTORE_REFとしてデフォルト・ストアを入力します(失敗時のエラーのリダイレクトも指定します)。 関連項目: 表16-13「各種プラグインのパラメータの詳細」 「パスワード・ポリシー検証認証モジュールの構成」	DCCとECCのどちらについても同じです。
認証スキーム、チャレンジ・リダイレクトURL	資格証明コレクタのホストを入力します。 ECCの場合、相対URI形式: /oam/server (serverにhost:portを付加します) 関連項目: 「PasswordPolicyValidationSchemeの構成」	資格証明コレクタのホストを入力します。 DCCの場合、完全URL: http://dcchost:port DCCがリソースWebgateと一体化されている場合: 空のままにします 関連項目: 「PasswordPolicyValidationSchemeの構成」
認証スキーム、チャレンジURL	資格証明コレクタのログイン・フォームの相対URIを入力します。 ECCの場合: /pages/login.jsp 関連項目: 「PasswordPolicyValidationSchemeの構成」	資格証明コレクタのログイン・フォームの相対URIを入力します。 DCCの場合: /oamsso-bin/login.pl 関連項目: 「PasswordPolicyValidationSchemeの構成」
認証スキーム、チャレンジ・パラメータ	ECC: ユーザー定義のチャレンジ・パラメータ: OverrideRetryLimit=0 initial_command=NONE 関連項目: 表16-22「認証スキームのユーザー定義チャレンジ・パラメータ」 「PasswordPolicyValidationSchemeの構成」	DCC: ユーザー定義のチャレンジ・パラメータ: creds extracreds MaxPostDataBytes DCCCtxCookieMaxLength TempStateMode 関連項目: 表16-22「認証スキームのユーザー定義チャレンジ・パラメータ」 「PasswordPolicyValidationSchemeの構成」
サーバー・エラー・モード	DCCとECCのどちらについても同じです。 関連項目: 「パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定」	DCCとECCのどちらについても同じです。 関連項目: 「パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定」
認証ポリシー	認証ポリシーの資格証明コレクタ: ECC: 保護Webgate(リソースWebgate)のアプリケーション・ドメイン内のECC用に構成された認証スキームを使用します。 関連項目: 「ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加」	認証ポリシーの資格証明コレクタ: リソースWebgateから独立したDCC: ***保護(リソース)Webgateアプリケーション・ドメイン(リソースを保護する 認証ポリシー)は、DCC関連の認証スキームを使用します。 ***DCC Webgateアプリケーション・ドメイン、 リソースを保護する認証ポリシーは、 DCC関連の認証スキームを使用します。次の事項を考慮します: --アクションURLなし: DCCは、デフォルトの/oam/server/auth_cred_submitを使用します。これは、DCC関連の認証スキームで自動的に保護されます。 --アクションURLあり: 指定したアクションURLを DCCスキームで明示的に保護します。 関連項目: 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」
ログアウト構成	ECC: 保護(リソース)Webgateエージェントの登録で、「ログアウトURL」を構成します。表13-3「拡張された11gおよび10g Webgate/アクセス・クライアント登録ページの要素」を参照してください。 「11g Webgateの集中ログアウト構成」を参照	DCC: DCCエージェントの登録ページでは、「ログアウト・リダイレクトURL」は無視されます。 保護(リソース)Webgate登録で、次のように定義します。 ログアウト・リダイレクトURL: http//dcchost:port/oamsso-bin/logout.pl 注意: リソースWebgateのログアウト・リダイレクトURLがlogout.*以外の場合、そのURLはDCC Webgate登録のログアウトURLパラメータで定義する必要があります。例: リソースWebgate登録に ログアウト・リダイレクトURL http//dcchost:port/someurl.html がある場合、DCC Webgate登録には ログアウトURL: someurl.htmlを含める必要があります。 DCC: Oracle提供のスクリプト内のPerlパスは、更新する必要があります。 「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」を参照

統合デプロイメントの注意事項

Oracle Internet Directoryで、Oracle Identity ManagementとOracle Access Managementを使用する場合、2種類のパスワード・ポリシー定義および施行が存在します。

• Oracle Identity ManagementとOracle Internet Directoryの両方のパスワード・ポリシー定義

• 次のいずれかで、パスワード・ポリシーを施行します。

  Oracle Access Managementは、Webアクセスの間に状態ポリシー(間違ったパスワードなど)を施行します。Oracle Internet Directoryは独自の状態ポリシーとLDAP処理(バインドや比較など)を施行します。

  Oracle Identity Managementは、パスワード更新のユーザー作成の間に値ポリシー(パスワードの特性)を施行します。Oracle Internet Directoryは独自の値ポリシーとLDAP処理用のポリシー(追加や変更など)を施行します。

1つのポリシー・セットのみを使用する場合は、次のいずれかを実行します。

1. Oracle Internet DirectoryポリシーをOracle Identity ManagementおよびOracle Access Managementポリシーよりも低い優先度か同じ優先度にします。ただし、これにより2つの施行が発生します。

2. ネイティブのLDAPパスワード・ポリシー検証を無効にします。ただし、直接のLDAP操作に対するポリシー施行もなくなります。

16.12 グローバル・パスワード・ポリシーの管理

認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。

Access Managerの認証プロセスは、認証モジュール(またはプラグイン)を使用して、要件およびバックエンド認証スキームへの情報転送を制御するルールを定義します。デフォルトで、Access Managerは、認証処理に対するOAMサーバー埋込み資格証明コレクタ(ECC)の使用をサポートしています。ただし、外部資格証明コレクタ(DCC)を使用するように、11g Webgateを構成することもできます。

ECCとDCCは、どちらも資格証明が一度に提供されない場合のマルチステップ認証フローを簡単にできます。これにより、認証関連の情報を収集するための、ユーザーやプログラム的なエンティティとの対話処理の柔軟性が向上します。複数要因による認証の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。

資格証明コレクションにどの方法(デフォルトのECCまたはオプションのDCC)を選択していても、この項で説明するようにグローバル・パスワード・ポリシーを構成して、Access Managerで保護されたすべてのリソースに適用できます。

前提条件

• あらかじめ用意されたパスワード・フォームおよび機能のプレビュー

• Oracle Access Managementコンソールでのパスワード・ポリシー・ページのプレビュー

• 資格証明コレクタとパスワード・ポリシーの検証について

次に示す概要では、このパスワード・ポリシーを構成および使用する方法について説明している項へのリンクを示します。特に明記しないかぎり、すべてのタスクはECCとDCCに同様に適用できます。ご使用のデプロイメントに該当しないタスクは省略してください。

タスクの概要: パスワード・ポリシー管理のタスクは次のとおりです。

1. グローバル・パスワード・ポリシーの定義

2. デフォルト・ストアへのキー・パスワード属性の追加

3. パスワードの変更後ユーザー属性を変更するために管理者を追加

4. パスワード・ポリシー認証の構成

5. DCC: DCC対応の11g Webgateと認証ポリシーの構成

6. パスワード・ポリシー構成の完了

7. マルチステップ認証のテスト

16.12.1 グローバル・パスワード・ポリシーの定義

Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用して、企業で定義された要件に基づいた共通のパスワード・ポリシーを定義できます。

注意: ECCとDCCのグローバル・パスワード・ポリシーの唯一の相違点は、パスワード・サービスURLです。これは、資格証明コレクタ固有であり、デフォルトは手順2で示すようにECCページです。

この例の仕様は、説明の目的のみに使用されているものです。環境はユーザーによって異なります。

Oracle Access Managementでパスワード・ポリシーを構成するには

1. 「システム構成」タブの「共通構成」セクションから「データソース」ノードを展開します。

   
   「システム構成」タブ
   「共通構成」セクション
   「パスワード・ポリシー」
   

2. 「パスワード・ポリシー」ページで、目的の資格証明コレクタのログイン・ページ(ECCまたはDCC、表16-27)のパスワード・サービスURLを入力します。

   	ECCのパスワード・サービスURL	DCCのパスワード・サービスURL
   	/pages/login.jsp	/oamsso-bin/login.pl

   
   

3. 「パスワード・ポリシー」ページで、企業の要件に基づいた値(表16-26)を入力します。次に例を示します。

   • 警告までの時間: 3

   • 有効期限切れまでの時間: 20

   • 永続的ロックアウト: (無効)

   • ロックアウト期間: 1

   • 最小特殊文字数: 1

4. 「適用」をクリックして、ポリシーを送信します。

5. それぞれの環境に合せて次の手順に進みます。完了済のタスクはスキップしてください。

   • デフォルト・ストアへのキー・パスワード属性の追加

   • パスワードの変更後ユーザー属性を変更するために管理者を追加

16.12.2 パスワード・ポリシー用のデフォルト・ストアの指定

パスワード・ポリシーは、デフォルト・ストアが指定されている場合にのみ動作します。管理者のロールと資格証明は、システム・ストアに存在している必要があります。

関連項目: 「デフォルト・ストアおよびシステム・ストアの設定」

グローバル・パスワード・ポリシーにデフォルト・ストアを指定するには

1. Oracle Access Managementコンソールで、「システム構成」タブを開き、「ユーザー・アイデンティティ・ストア」ノードを開きます。

   
   「システム構成」タブ
   「共通構成」セクション
   「データソース」ノード
   「ユーザー・アイデンティティ・ストア」ノード
   

2. システム・ストアの設定: このストアに管理者ロールおよび証明書が存在する必要があります。

   1. システム・ストアとして指定するストアのページを開きます。

   2. 「システム・ストアとして設定」をクリックします(ドメイン全体の認証および認可操作用)。

   3. 「適用」をクリックします。

   4. 管理者の追加: 「管理者ロールの管理」を参照してください。

   5. 認証モジュール: OAMAdminConsoleScheme (認証スキーム)によって使用されるLDAP認証モジュールがシステム・ストアを使用するように設定します。

   6. このストアを使用するように、1つ以上の認証プラグインを構成します。詳細は、「プラグイン・ベースのモジュールによるマルチステップ認証の編成」を参照してください。

3. デフォルト・ストアの設定: このストアは、パッチ適用時のパスワード・ポリシー、セキュリティ・トークン・サービスおよび移行に必要です。

   1. デフォルト・ストアとして指定するストアのページを開きます。

   2. 「デフォルト・ストアとして設定」の横にあるボックスを選択します。

   3. 認証モジュール: OAMAdminConsoleSchemeを見つけて、LDAPモジュールがこのストアを参照していないことを確認します。「ネイティブ認証モジュールの管理」を参照してください。

   4. 認可ポリシー条件: 認可ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。認証ポリシー条件の定義を参照してください。

   5. トークン発行ポリシー条件: トークン発行ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。「トークン発行ポリシー、条件およびルールの管理」を参照してください。

4. 登録ページを閉じます。

16.12.3 デフォルト・ストアへのキー・パスワード属性の追加

パスワード・ポリシーは、デフォルト・ストアが指定されている場合にのみ動作します。この項では、Oracle Access Managementのパスワード・ポリシー処理のデフォルト・ストア・スキーマを拡張する手順を説明します。

• デフォルト・ストア・スキーマの拡張について

• デフォルト・ストア・スキーマのパスワード・ポリシー属性の拡張

16.12.3.1 デフォルト・ストア・スキーマの拡張について

Access Managerの一部として配布されているLDIF (Lightweight Directory Interchange Format)ファイルは、必須のオブジェクト・クラスでスキーマを拡張するためのものです。一般に、これらを適用するには、idmConfigToolを使用するか、手動で連結してあるAccess ManagerとOracle Identity Managementを使用します。

Access Managerスキーマのユーザー・データー・オブジェクト定義は、パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性で拡張されます。この定義は、LDIFファイルで指定して、ldapaddツールを使用して各ユーザー・アイデンティティ・ストアに追加する必要があります。オラクル社が提供するLDIFについて表16-28に示します。

注意: OAM_HOMEホームには、Oracle Access Managementをホストするためにインストールされているファイルが含まれます。OAM_HOMEホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。

表16-28 LDAPプロバイダ用のオラクル社提供LDIFのロケーション

LDAPプロバイダ	LDIFロケーション
OID: Oracle Internet Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif
OVD: Oracle Virtual Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OVD_PWDPersonSchema.ldif
AD: Microsoft Active Directory	$OAM_HOME/ oam/server/pswdservice/ldif/AD_PWDPersonSchema.ldif
SJS: sun Java System Directory	$OAM_HOME/ oam/server/pswdservice/ldif/IPLANET_PWDPersonSchema.ldif
eDirectory: Novell eDirectory	$OAM_HOME/ oam/server/pswdservice/ldif/ED_PWDPersonSchema.ldif
ODSEE: Oracle Directory Server Enterprise Edition	$OAM_HOME/ oam/server/pswdservice/ldif/OJD_PWDPersonSchema.ldif
OUD: Oracle Unified Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OJD_PWDPersonSchema.ldif
SLAPD: OpenLDAP Directory	$OAM_HOME/ oam/server/pswdservice/ldif/OLDAP_PWDPersonSchema.ldif
IBM: OBM Tivoli Directory	$OAM_HOME/ oam/server/pswdservice/ldif/TIVOLI_PWDPersonSchema.ldif

パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性を表16-29に示します。各ユーザー・アイデンティティ・ストアのユーザー・データ・オブジェクトには、表16-29に示す属性を含める必要があります。これらは、ldapaddツールを使用して、LDIF (Lightweight Directory Interchange Format)ファイルに追加できます。

表16-29 パスワード・ポリシーのキー・パスワード属性

属性	説明	書式および値
obPasswordCreationDate	日付と時刻(ユーザー・ログインの時点)です。パスワードの有効期限が切れているかどうか、また警告を発行する必要があるかどうかを計算するために使用します。	YYYY-MM-DDThh:mm:ssZ
obPasswordHistory	最後に使用されたパスワードの数を追跡するために使用します。Access Managerは、10g oblixPersonPwdPolicyの書式を認識して、新しい書式に変換します。	新しい書式: password1###password2### 以前の書式: passwordX = SHA256 (password+canonical userid)
obPasswordChangeFlag	初回ユーザー・ログイン時のパスワード変更の強制(または、管理者が開始したパスワード変更の強制)に使用します。	ブール文字列値。 true | false 空の文字列は、falseを意味します。
obuseraccountcontrol	無効になったユーザーを表します。	暗号化されていない文字列値。 activated | deactivated 空の文字列は、activatedを意味します。
obpasswordexpirydate	この時刻以降は、ユーザー・パスワードが期限切れであるとみなされます。	YYYY-MM-DDThh:mm:ssZ 空の値は、not expiredを意味します。
obLockoutTime	この時刻までは、ログインの試行回数が多すぎるために、ユーザーがロック・アウトされるとみなされます。	時期値(秒単位)は、将来の時間を表します。 Seconds (1970年1月1日を基点とする)
obLoginTrvCount	ユーザーによるログインが連続して失敗した回数。このカウンタは、最初に正しいパスワードが入力された時点でリセットされます。	暗号化されていない整数値。 1、2、3など。
obLastSuccessfulLoginTime	前回成功したログインの時間。	YYYY-MM-DDThh:mm:ssZ
obLastFailedLoginTime	前回失敗したログインの時間。	YYYY-MM-DDThh:mm:ssZ

16.12.3.2 パスワード・ポリシー属性によるデフォルト・ストア・スキーマの拡張

環境が idmConfigTool -prepareIDStoreを使用して構成されている場合、このタスクをスキップできます。

ユーザー・アイデンティティ・ストアがoblixスキーマで拡張されていない場合は、このスキーマを更新して、パスワード・サービスに必要なオブジェクト・クラスを含める必要があります。

LDAPツールは、OAM_HOME配下の/binディレクトリから実行する必要があります。次の手順は、Oracle Internet Directoryスキーマの拡張方法を示しています。環境によっては異なることがあります。

デフォルト・ユーザー・アイデンティティ・ストア・スキーマを拡張するには

1. 次のコマンドを使用して、パスワード・サービスに必要な、指定されたデフォルト・ストアのOracle Internet Directoryオブジェクトを更新します。

   ldapadd -D "cn=orcladmin" -w <password> –h <hostname> -p 3060 –x -f $OAM_HOME/
   oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif
   

2. 「パスワードの変更後ユーザー属性を変更するために管理者を追加」に進みます。

16.12.4 パスワードの変更後ユーザー属性を変更するために管理者を追加

この手順では、デフォルト・ストア(この例ではOracle Internet Directory)を変更して、別の権限が与えられたアカウントをバインドDNとして使用します。これにより、パスワードの変更後、ユーザー属性を変更可能な権限が与えられます。

前提条件

サポートされているLDAPストアを登録し、デフォルト・ストアに指定します。追加したユーザーがデフォルト・ストア内で定義されていることを確認します。

関連項目: 「管理者ロールの管理」

図16-29は、指定されたデフォルト・ストアの完成した登録ページを示しています。この図の次に管理者の追加手順を示します。

図16-29 新しい管理者が指定されたデフォルト・ストア

新しい管理者を追加するには

1. 通常どおり、Oracle Access Managementコンソールにログインします。

        https://hostname:port/oamconsole/
   

2. 目的の「ユーザー・アイデンティティ・ストア」登録ページを開きます。

   
   「システム構成」タブ
   「共通構成」セクション
   「データソース」ノード
   「ユーザー・アイデンティティ・ストア」ノード
   OID
   

3. 新しい管理者を追加します。

   1. このページの「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。

   2. ダイアログ・ボックスで、すべてのユーザーを検索し、desireduserを強調表示して、「選択済の追加」をクリックします。

   3. 「適用」をクリックして変更を送信します。

4. デフォルト・ストア: 指定したデフォルト・ストアであることを確認(または「デフォルト・ストア」をクリック)して、「適用」をクリックします。

5. 「パスワード・ポリシー認証の構成」に進みます。

16.13 パスワード・ポリシー認証の構成

パスワード・ポリシー、デフォルト・ストアおよび管理者の準備が完了すると、この項で説明するように、認証モジュールとスキームを作成できるようになります。

• パスワード・ポリシー検証認証モジュールの構成

• PasswordPolicyValidationSchemeの構成

• 「ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加」: DCCを使用している場合は、この項をスキップして、「DCC対応の11g Webgateと認証ポリシーの構成」に進みます。

16.13.1 パスワード・ポリシー検証認証モジュールの構成

デフォルト・ストアを使用するには、パスワード・ポリシー検証認証モジュールも構成する必要があります。

注意: 認証用のパスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。

サンプル・モジュールを図16-30に示します。ユーザー・パスワードのステータス・ステップは、UserPasswordPolicyPluginに基づく一意のステップです。

図16-30 パスワード・ポリシー検証認証モジュールと編成済プラグイン

各ステップは、特定の名前付きプラグインが提供するアクションを特定します。

関連項目: 「プラグイン・ベースのモジュールによるマルチステップ認証の編成」および 表16-18。

図16-31は、認証モジュール内でのステップの編成を示しています。モジュールとステップの詳細は、「プラグイン・ベースのマルチステップ認証モジュールについて」を参照してください。

図16-31 パスワード・ポリシー検証モジュールのステップ編成

表16-30では、指定したパスワード・ポリシー検証モジュール・ステップの詳細を説明します。

表16-30 ユーザー・パスワード・ステップの詳細

ステップ名	ステップの詳細	説明
ユーザー識別ステップ	KEY_LDAP_FILTER	KEY_LDAP_FILTER属性にLDAPフィルタを追加します。LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。次に例を示します。 (uid={KEY_USERNAME}) 関連項目: アイデンティティ・ストアの正確な構文は表17-22「Access ManagerのLDAP検索フィルタの例」 およびベンダーのドキュメントを参照
	KEY_IDENTITY_STORE_REF	モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。 デフォルト: 登録済デフォルト・ストア
	KEY_SEARCH_BASE_URL	ユーザーの検索のベースURL。次に例を示します。 dc=us,dc=example,dc=com
ユーザー認証ステップ	KEY_IDENTITY_STORE_REF	モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。 デフォルト: 登録済デフォルト・ストア
	KEY_PROP_AUTHN_EXCEPTION	LDAPエラーの伝播を有効または無効にします。
ユーザー・パスワード・ステータス・ステップ	PLUGIN_EXECUTION_MODE	プラグインの実行モード。このプラグインは、構成に従って、単独または他のプラグインとともに動作可能です。値は次のいずれかになります。 PSWDONLY: パスワードのステータスのみを決定する、最も推奨される構成です。IDと認証は、UserIdentificationおよびUserAuthenticationプラグインを使用して実行する必要があります。 AUTHWITHPSWD: このプラグインの実行によって、認証とパスワードの両方が実行されます。 AUTHONLY: ユーザーの識別と認可はこのプラグインを使用した場合にのみ実行されます。 デフォルト: PSWDONLY
	KEY_IDENTITY_STORE_REF	モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。 デフォルト: 登録済デフォルト・ストア
	NEW_USERPSWD_BEHAVIOR	新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。値は、次のどちらかになります。 FORCEPASSWORDCHANGE: パスワード変更を強制します。 NOFORCEPASSWORDCHANGE: パスワードのポリシー変更は、設定済のユーザー・パスワードには影響しません。 デフォルト: FORCEPASSWORDCHANGE
	POLICY_SCHEMA	パスワード・サービスのポリシー・スキーマ。現在はOAM10Gのみがサポートされています。 デフォルト: OAM10G
	URL_ACTION	ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。 REDIRECT_POST REDIRECT_GET FORWARD デフォルト: REDIRECT_POST
	DISABLED_STATUS_SUPPORT	無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。 デフォルト: TRUE

前提条件

グローバル・パスワード・ポリシーの定義

注意: パスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。3つの各プラグイン/ステップのKEY_IDSTORE_REFとしてデフォルト・ストアを入力します(失敗時のエラーのリダイレクトも指定します)。

パスワード・ポリシー検証モジュールを構成するには

1. 「システム構成」タブで、次の項目を開きます。

   
   「Access Manager」セクション
   「認証モジュール」
   「カスタム認証モジュール」
   パスワード・ポリシー認証モジュール
   

2. 「ステップ」タブをクリックします。3つのステップのそれぞれに、KEY_IDSTORE_REFの横のフィールドで デフォルト・ストア名を追加します(それぞれの変更で保存します)。次に例を示します。

   1. ユーザー識別ステップ

      KEY_IDSTORE_REF: OID

      保存:

   2. ユーザー認証ステップ

      KEY_IDSTORE_REF: OID

      保存:

   3. ユーザー・パスワード・ステータス・ステップ

      KEY_IDSTORE_REF: OID

      保存:

3. 「適用」をクリックします。

4. 「PasswordPolicyValidationSchemeの構成」に進みます。

16.13.2 PasswordPolicyValidationSchemeの構成

グローバル・パスワード・ポリシーには複数の認証スキームを使用することができます。管理者の資格証明を持つユーザーは、この手順に従って、PasswordPolicyValidationSchemeを構成できます。

注意: ECCとDCCの値の相違点(表16-27)には、次の項目が含まれます。 チャレンジ・リダイレクトURL: 資格証明コレクタのホストとポート チャレンジURL: 資格証明コレクタのページ チャレンジ・パラメータ: 表16-22

図16-32のスキーム例は、ECC用に構成されています。認証スキームは、ユーザーによって異なります。

図16-32 ECC PasswordPolicyValidationSchemeの例

前提条件

パスワード・ポリシー検証認証モジュールの構成

関連項目: 「認証スキームの管理」

PasswordPolicyValidationSchemeを構成するには

1. 「システム構成」タブで、次の項目を開きます。

   
   「ポリシー構成」タブ
   「共有コンポーネント」
   「認証スキーム」
   PasswordPolicyValidationScheme
   

2. 使用環境のスキームを設定します。次に例を示します。

   • 認証レベル2

   • デフォルト(空白)

   • チャレンジ・メソッド: フォーム

   • チャレンジ・リダイレクトURL: http://CredCollector_host:port/

   • 認証モジュール: パスワード・ポリシー検証モジュール

   • チャレンジURL: /CredCollector_pages/

   • コンテキスト・タイプ: 外部

   • チャレンジ・パラメータ:

     	ECCチャレンジ・パラメータ	DCCチャレンジ・パラメータ
     	OverrideRetryLimit=0 initial_command=NONE	OverrideRetryLimit=0 creds=userid password
     		関連項目: 表16-22、「認証スキームのユーザー定義チャレンジ・パラメータ」 action 指定していない場合、ECCとDCCは、どちらもデフォルトの/oam/server/auth_cred_submitになります。 DCCCtxCookieMaxLength (デフォルトは4096) TempStateMode パラメータ値での指定に応じて、DCCがOAMサーバーの状態をCookieで格納するか、フォーム(デフォルト)で格納するかを制御します。 MaxPostDataBytes ユーザーの資格証明として送信さるPOSTデータの最大バイト数を制限します。 creds 渡すパラメータをObUserSessionオブジェクトのobMap資格証明パラメータで指定する必要があります。『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。

     
     

3. 「適用」をクリックします。

4. 「ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加」に進みます。

16.13.3 ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加

管理権限を持つユーザーは、保護Webゲート(リソースWebゲート)のアプリケーション・ドメインで、ECC用に構成したPasswordPolicyValidationSchemeを使用できます。

前提条件

PasswordPolicyValidationSchemeの構成

ECC認証ポリシーにPasswordPolicyValidationSchemeを追加するには

1. ECC: コンソールで、該当するアプリケーション・ドメインを検索して開きます。(「既存のアプリケーション・ドメインの検索」を参照)。

   
   

   関連項目: 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」

   
   

2. ECC: PasswordPolicyValidationSchemeを使用してリソースを保護します。

   1. 「認証ポリシー」タブで保護されたリソース・ポリシーを探して開きます(「認証ポリシーの表示または編集」を参照)。

      
      認証ポリシー
      保護されたリソース・ポリシー

   2. 保護されたリソース・ポリシー(認証スキーム)の「PasswordPolicyValidationScheme」を選択して、「適用」をクリックします。

   3. 認可および認証ポリシーの更新を終了します(第17章を参照してください)。

3. それぞれの環境で必要に応じて次に進んでください。

   • ECC: 「パスワード・ポリシー構成の完了」

   • DCC: DCC対応の11g Webgateと認証ポリシーの構成

16.14 DCC対応の11g Webgateと認証ポリシーの構成

ECCを使用している環境の場合は、このセクションをスキップして、「パスワード・ポリシー構成の完了」に進みます。

タスクの概要: DCC対応の11g Webgateと認証ポリシーの構成

1. DCCの資格証明操作の有効化には、次の両方の構成手順が説明されています。

   リソースWebゲートと一体化されたDCC: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にします。

   独立したDCCとリソースWebゲート: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にして、「ログアウト・リダイレクトURL」にDCCのlogout.plを設定します。

2. パスワード・ポリシーのDCCフォームの検索と更新

3. DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加には、次の両方の構成手順が説明されています。

   一体化されたDCC/リソースWebゲート: 一体化されたDCC/リソースWebゲート・アプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。

   独立したDCCとWebゲート: 独立したリソースWebゲートのアプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。

16.14.1 DCCの資格証明操作の有効化

独立したDCCを使用しているか、DCCとリソースWebゲートを一体化しているかにかかわらず、DCCのOAMエージェント登録ページで「資格証明コレクタ操作の許可」を有効にする必要があります。

DCCとリソースWebゲートが独立している場合は、リソースWebゲート登録ページを編集して、手順3で示すように、「ログアウト・リダイレクトURL」にDCCのlogout.plを設定する必要があります。

次の手順は、デプロイメントでオープン・モード通信を使用していると仮定しています。デプロイメントで簡易モードまたは証明書モードの通信を使用している場合は、手順4の実行時に適切なアーティファクトをコピーしてください。

前提条件

• コンソールを使用した登録済OAMエージェントの構成および管理

• グローバル・パスワード・ポリシーの管理

• パスワード・ポリシー認証の構成(DCC固有の詳細を使用する場合)

DCCの資格証明操作を有効化するには

1. Oracle Access Managementコンソールを使用して、DCCとして動作する11.1.2 Webゲートの登録ページを検索して開きます。

   
   「システム構成」タブ
   「Access Manager」セクション
   「SSOエージェント」ノード
   DCCAgent
   

2. DCC Webゲート登録: 「資格証明コレクタ操作の許可」を選択し、「適用」をクリックして、手順4と5を実行します。

   
   

   注意: DCCをリソースWebゲートと一体化している場合は、手順3をスキップしてください。

   
   

3. 独立したWebゲート: リソースWebゲート登録を編集して、「ログアウト・リダイレクトURL」にDCCのlogout.pl (表16-27)を設定し、「適用」をクリックして、手順4と5を実行します。

4. AdminServer (コンソール)ホストからエージェント構成ファイル(簡易モード・ファイルまたは証明書モード・ファイルを含む)をエージェント・ホストにコピーします。次に例を示します。

   	エージェントおよびアーティファクト	アーティファクト
   	11g Webgate/アクセス・クライアントの場合: ObAccessClient.xmlとcwallet.sso	コピー元: AdminServer (コンソール)ホスト $DOMAIN_HOME/output/$Agent_Name/ コピー先: エージェント・ホストの$11gWG_install_dir/webgate/config。
   	簡易または証明書モード	エージェント・ホストにコピー: $11gWG_install_dir/webgate/config aaa_key.pem aaa_cert.pem aaa_chain.pem password.xml 関連項目: 付録C「通信の保護」

   
   

5. OHS Webサーバーを再起動します。

6. 「パスワード・ポリシーのDCCフォームの検索と更新」に進みます。

16.14.2 パスワード・ポリシーのDCCフォームの検索と更新

Access Managerは、DCCに対するユーザー操作のためにいくつかの動的なページを提供します。

関連項目: Oracle Fusion Middleware Oracle Access Management開発者ガイド

前提条件

DCCの資格証明操作の有効化

DCCフォームを検索して更新するには

1. Webゲート・ホストでDCCフォームを検索します(表16-27):
WEBGATE_HOME/webgate/ohs/oamsso/*、
   WEBGATE_HOME/webgate/ohs/oamsso-bin/*plおよび
WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*。

2. それらの場所は、デプロイする認証スキームのトポロジーに応じてカスタマイズします。

3. Perlの場所を更新します: Webゲート・ホストのWEBGATE_HOME/webgate/ohs/oamsso-bin/*plにあるlogin、logoutおよびsecuridスクリプトの最初の行で、Perlの場所を実際の場所と一致するように更新します(表16-27の「DCCベースのログインおよびログアウトを行うPerlスクリプト」を参照)。

4. デフォルト・ページを企業に合せてカスタマイズするか、デフォルト・ページ全体をカスタム・ページと置き換えます。たとえば、デスクトップ・ブラウザ用のログイン・フォームと異なるものをモバイル・ブラウザ用に表示するために、カスタム・ページを設計、実装およびデプロイできます。

5. 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」に進みます。

16.14.3 DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加

次に、保護されたリソースの認証ポリシーでDCC認証スキームを使用するために、実行する必要がある手順を説明します。実行する手順は、デプロイメントのタイプに応じて異なります。

• 一体化されたDCC/リソースWebゲート: 手順1を実行して、一体化されたDCC/リソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。

• 独立したリソースWebゲート: 手順3を実行して、独立したリソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。

手順2は、DCCのデプロイメント・タイプにかかわらず実行してください。デフォルトでは、ログインおよびログアウトのフォームは、OHSの/httpd.conf/webgate.confを通じて除外されるため、これらのフォームをポリシーから除外する必要はありません。ただし、Chromeブラウザの場合は、明示的にasync favicon.icoリクエストを除外する必要があります(このリクエストは、DCCCtxCookieを無視します)。

注意: この例では、以前にDCCに設定したPasswordPolicyValidationSchemeについて説明しています。

前提条件

パスワード・ポリシーのDCCフォームの検索と更新

アプリケーション・ポリシーでDCC認証スキームを使用するには

1. 一体化されたDCC/リソースWebゲート: DCCアプリケーション・ドメインを開きます。

   
   ポリシー構成
   アプリケーション・ドメイン
   DCCDomain
   

   1. 認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。

   2. このポリシーにDCC認証スキームを追加します(「特定のリソースの認証ポリシーの定義」を参照してください)。

      
      PasswordPolicyValidationScheme (DCC認証スキーム)
      

   3. Chromeブラウザを使用する場合は、手順2を実行します。それ以外の場合は、手順4に進みます。

2. Chromeブラウザ: 次の手順を実行して、DCCDomainで/favicon.icoを追加します。

   1. DCCDomainで、「リソース」タブをクリックします。

   2. HTTPリソースの/favicon.icoを見つけて開きます(または、「新規リソース」ボタンをクリックして、このリソースを追加します)。

   3. 「リソースURL」を確認または編集して、次のようにします。

      /favicon.ico
      

   4. 「保護」セクションで、「保護レベル」リストから「除外」を選択して、「適用」をクリックします。

   5. 手順4に進みます。

3. 独立したWebゲート: リソースWebゲート・アプリケーション・ドメインを開きます。

   
   ポリシー構成
   アプリケーション・ドメイン
   ResourceWGDomain
   

   1. 認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。

   2. このポリシーに、DCC認証スキームと、オプションの失敗URLを追加します(指定していない場合、失敗URLはデフォルトのエラー・ページを表示します)。「特定のリソースに対する認証ポリシーの定義」を参照してください。

      
      DCC認証スキーム
      失敗URL (オプション)
      

   3. Chromeブラウザを使用する場合は、手順2を実行します。それ以外の場合は、手順4に進みます。

4. Webサーバーを再起動して、「パスワード・ポリシーの構成の完了」に進みます。

   
   

   関連項目: 外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成

   
   

16.15 パスワード・ポリシー構成の完了

ここで説明するタスクは、どの証明書コレクタを構成していても同じです。次のタスクを実行して、パスワード・ポリシーの構成を完了します。

• パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定

• ネイティブLDAPパスワード・ポリシー検証のオーバーライド

• ECC操作の無効化とDCCの単独使用

• マルチステップ認証のテスト

16.15.1 パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定

管理権限を持つユーザーは、この手順を使用して、図16-33に示すように、パスワード・ポリシー・メッセージのサーバー・エラー・モードを設定できます。

図16-33 パスワード管理のサーバー・エラー・モード

前提条件

• グローバル・パスワード・ポリシーの管理

• パスワード・ポリシー認証の構成

• オプション: DCC対応の11g Webgateと認証ポリシーの構成

エラー・メッセージ・モードを設定するには

1. コンソールで、「Access Manager」セクションを開きます。

   
   「システム構成」
   「Access Manager」
   「Access Managerの設定」
   

2. 「ロード・バランシング」セクションで、「サーバー・エラー・モード」を「内部」に設定します。

3. 「適用」をクリックします。

4. 「ネイティブLDAPパスワード・ポリシー検証のオーバーライド」に進みます。

16.15.2 ネイティブLDAPパスワード・ポリシー検証のオーバーライド

前述のとおり、ネイティブLDAPパスワード・ポリシー検証を無効にした後でないと、非ネイティブのパスワード・ポリシーは使用できるようになりません。

たとえば、Oracle Access Managementに登録されたOracle Internet Directoryの使用時、ネイティブのパスワード・ポリシーは、通常次の場所にあります。

dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,<DOMAIN_CONTAINER>

注意: ネイティブLDAPパスワード・ポリシー検証を無効にすると、直接のLDAP操作に対するポリシー施行がなくなります。Oracle Internet Directoryには、次のうちの1つを含む様々なパスワード・ポリシーがあります。 dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext ただし、これはドメインに適用することはできません。

orclpwdpolicyenableパラメータをゼロ(0)に設定することで、Oracle Internet Directoryパスワード・ポリシーを無効にできます。

関連項目: Oracle Fusion Middleware Oracle Internet Directory管理者ガイドには、様々な属性が説明されています。

次の手順は1つの例です。環境はユーザーによって異なります。

前提条件

パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定

ネイティブLDAPポリシーをOracle Access Managementパスワード・ポリシーでオーバーライドするには

1. LDAPディレクトリ・ベンダーのマニュアルを参照してください。

2. Oracle Internet Directory: orclpwdpolicyenableをゼロ(0)に設定することで、ネイティブ・ポリシーを無効にします。

   • ドメインのパスワード・ポリシーの場所を確認します。

   • 適切なネイティブLDAPポリシーがわかっている場合は、そのポリシーを無効にします。次に例を示します。

     orclpwdpolicyenable = 0
     

3. 使用するデプロイメントに応じて、次の作業を実行します。

   • 「ECC操作の無効化とDCCの単独使用」

   • 「マルチステップ認証のテスト」

   • 第19章: 「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」

16.15.3 ECC操作の無効化とDCCの単独使用

DCCとECCの共存を許可して、両方の資格証明コレクタに認証スキームとポリシーを保持する場合、このタスクはスキップできます。

ECCを無効にする場合は、ここで説明するように、oam-config.xmlファイルを編集する必要があります。通常、oam-config.xmlファイルは編集しないことをお薦めします。このファイルを変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。ただし、他の方法でECCを完全に無効にして、DCCを選択できません。

注意: ECCを無効にすると、そのECCに依存するスキームとポリシーで保護されているリソース(Oracle Access Managementコンソールを含む)にはアクセスできなくなります。

前提条件

DCC対応の11g Webgateと認証ポリシーの構成

ECC操作を無効にして、DCCを単独で使用するには

1. AdminServerを実行されているノードで、他のAdminServerユーザーによって発生する可能性がある競合ができるだけ少なくなるように変更を加えます。

2. 必要に応じて、$DOMAIN_HOME/config/fmwconfig/にあるoam-config.xmlをバックアップし、後で使用するためにコピーを別の場所に保存します。

3. OAMServicesDescriptorセクションでECCEnabledパラメータを見つけて、次の太字で示された部分を変更します。

   <Setting Name="OAMServicesDescriptor" Type="htf:map">
     ... ...
      <Setting Name="ECCEnabled" Type="htf:map"> 
      <Setting Name="ServiceStatus" Type="xsd:boolean">false</Setting>
   </Setting>      
   

4. ファイルの先頭にある構成バージョン番号を1増加させて、この変更を関連付け、実行中のすべてのOAMサーバーに対する自動伝播と動的アクティブ化を有効にします(この例の、最後の行のすぐ上を参照してください)。

   <Setting Name="Version" Type="xsd:integer">
     <Setting xmlns="http://www.w3.org/2001/XMLSchema"
       Name="NGAMConfiguration" Type="htf:map:> 
     <Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
       <Setting Name="Version" Type="xsd:integer">2</Setting>
   </Setting> 
        
   

5. 「マルチステップ認証のテスト」に進みます。

16.15.4 マルチステップ認証のテスト

この項では、各自のデプロイメントが適切に動作していることを確認するために実行できる、いくつかの評価方法について説明します。

関連項目: 第19章「11g Webgateが関与するセッションの集中ログアウトの構成」

マルチステップ認証を確認するには

1. ログイン後のアクセスを確認します。

   1. ブラウザを開き直して、リソースをリクエストします。

   2. ユーザー資格証明を使用してログインします。

   3. リソースにアクセスできることを確認します。

2. 不正なログインでアクセスできないことを確認します。

   1. ブラウザを開き直して、リソースをリクエストします。

   2. 不正なユーザー資格証明を使用してログインします。

   3. 再認証が必要になることを確認します。

3. 不正なログインの最大試行回数を超過したときのロックアウトを確認します。

   1. ブラウザを開き直して、リソースをリクエストします。

   2. 不正なユーザー資格証明を使用して、繰り返しログインします。

   3. ユーザー・アカウントがロックされたことを確認します。

4. パスワード有効期限ポリシーを変更および評価します。

   1. Oracle Access Managementコンソールにログインします。

   2. パスワード・ポリシーで、有効期限とロックアウト期間(表16-26)をリセットして、次回のログイン時に警告が表示されるようにします。

   3. ポリシーの更新を保存します。

   4. ブラウザを開き直して、リソースをリクエストします。

   5. パスワードが期限切れになることを示す警告ページが表示されることを確認します。

   6. パスワードを変更しないで続行するリンクをクリックします。

5. パスワードを変更します。

   1. ブラウザを開き直して、リソースをリクエストします。

   2. パスワード有効期限切れの警告ページで、パスワードを変更するリンクをクリックします。

   3. パスワード変更のページで、古いパスワードを正しく入力します。

   4. 新しいパスワードのフィールドで、パスワード・ポリシーに従わない新しいパスワードを入力して、パスワード検証のエラーを確認します。

   5. 要件を満たす新しいパスワードを入力して、変更の成功とリソースへのアクセスを確認します。