1. Oracle Access Management管理者ガイド
  2. Access ManagerのSSO、ポリシーおよびテストの管理
  3. 認証コンポーネントと共有ポリシー・コンポーネントの管理

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

管理者は、共有ポリシー・コンポーネントを構成し、認証スキームを管理して、認証用プラグインをデプロイおよび管理できます。

22.1 認証コンポーネントと共有ポリシー・コンポーネントを管理するための前提条件

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

この項で説明するアクティビティを実行する前に、「Access Managerでのシングル・サインオンの理解」に記載されている情報を確認することをお薦めします。

22.2 共有ポリシー・コンポーネントの構成

リソースを保護し、シングル・サインオンを可能にするAccess Manager認証ポリシーで使用するために必要な共有ポリシー・コンポーネントを構成できます。

関連項目:

Access Managerでのシングル・サインオンの理解

  1. この章の説明に従って、必要なリソース・タイプが定義されていることを確認します。
  2. 次の説明に従って、エージェントに由来する名前が付けられたホスト識別子の定義がエージェント登録時に作成された(またはユーザーが手動で作成した)ことを確認します。
  3. Access Managerによる資格証明コレクションについて理解します。
  4. 複数ステップの認証を可能にする認証プラグインについて学習してから使用します。
  5. 認証ポリシーに追加できる認証スキームを作成して管理します(次の項目を参照)。
  6. デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタに独自のグローバル・パスワード・ポリシーを設定します(特に明記しないかぎり、このタスクはECCとDCCの両方に適用されます。わずかな違いについては、説明内に示しています)。
  7. 「リソースの保護およびSSOの有効化ポリシーの管理」に進み、認証ポリシーを設定します。

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

管理者は、アプリケーション・ドメインへのリソースの追加、定義されているリソース・タイプの検索、または定義されているリソース・タイプの作成を行うことができます。

22.3.1 リソース・タイプおよびその使用

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

Oracle提供のリソース・タイプには、次が含まれます。

  • HTTP

  • wl_authen

  • TokenServiceRP

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

ノート:

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

22.3.2 「リソース・タイプ」ページ

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

ノート:

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

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

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

図22-1の説明が続きます
「図22-1 デフォルトのHTTPリソース・タイプ定義」の説明

図22-2は、wl_authenリソース・タイプを示しています。これは、次のいずれかのAccess Manager IDアサーション・プロバイダ構成(『Oracle Platform Security Servicesによるアプリケーションの保護』を参照)を使用するFusion Middlewareアプリケーションに使用します。

  • アイデンティティ・アサータ

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

  • 認証プロバイダ機能

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

図22-2の説明は次にあります。
「図22-2 デフォルトのリソース・タイプwl_authen」の説明

図22-3に示すように、TokenServiceRPリソース・タイプは、トークン・サービス・リライイング・パーティを表します。このリソース・タイプの操作は発行です。

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

図22-3の説明は次にあります。
「図22-3 デフォルト・リソース・タイプのTokenServiceRPリソース・タイプ」の説明

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

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

要素 説明

名前

必須。最大30文字の英数字の一意の名前。

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

説明

オプション。このフィールドを使用して、このリソース・タイプの目的を最大200文字の英数字で説明します。

たとえば、WebLogic認証スキームを表すリソースなどです。

操作

オプション。特定のリソースを制御するポリシーは、そのリソースに定義されている、指定されたすべての操作に適用されます。このリソース・タイプに文字列として操作を追加(または削除)して、アプリケーション・ドメイン内でこのタイプのリソースを定義すると、操作が使用可能になります。リソース・タイプに追加できる操作の数に制限はありません。

  • Get

  • Post

  • Put

  • Head

  • Issue (TokenServiceRP)

  • Login (wl_authen)

  • 削除

  • トレース

  • オプション

  • 接続

  • その他 (Oracle Access Manager 10では使用可能、11gではサポートされていません。)

リモート登録: 自動ポリシー作成時に、指定された操作がサポートされます。自動ポリシー作成時に何も操作が指定されていない場合は、そのタイプに対して定義されたすべての操作がサポートされます。

関連項目: 「リソース・タイプおよびその使用」および「アプリケーション・ドメインのリソース」。

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

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

関連項目:

「SSOエージェントの検索ページ」

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「リソース・タイプ」をクリックします。
  3. 「名前」フィールドに、(必要に応じてワイルド・カード(*)を使用して)検索するリソース・タイプの名前を入力し、「検索」をクリックします。たとえば: 
    h*

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

  4. 結果表で、次の操作を実行できます。

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

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

    • デタッチ: ツール・バーの「デタッチ」をクリックして、表をページ全体にまで拡大します。

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

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

有効な管理者の資格証明を持つユーザーは、定義されているリソース・タイプを作成できます。

たとえば、わずか1つまたは2つ(またはそれ以上)の操作に適用されるカスタム・リソース・タイプを定義できます。定義されているカスタム・リソース・タイプは、リソースを認証ポリシーまたは認可ポリシーに追加する際に、デフォルト・リソース・タイプとともにリストに表示されます。

関連項目:

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「リソース・タイプ」をクリックします。
  3. 「リソースの作成」タイプをクリックします。
  4. 表示されるページで、次の情報を入力します。

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

    • 説明: オプション。

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

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

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

22.4 ホスト識別子の管理

管理者は、ホスト識別子を手動で作成、変更および削除できます。

22.4.1 ホストの識別子について

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

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

表22-2 ホスト識別子の例

ホスト識別子のサンプル 説明

hrportal.intranet.company.com

従業員が覚えやすい名前。これはロード・バランシングされたプロキシで、このリクエストによってHRアプリケーションをホストするいくつかのサーバーのいずれかを実際に利用できます。

hr-sf-02.intranet.company.com

直接アクセスできるアプリケーションをホストする単一のマシン。

hrportal.company.com

以前の従業員の福利厚生や401k情報などの確認に主に使用するため、同じアプリケーションで企業ファイアウォールの外部にもアクセスできます。また、これはロード・バランシングされたリバース・プロキシです。

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

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

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

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

22.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対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。

ノート:

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

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

各ホスト識別子を定義して、1つ以上のWebサーバー・ホストを表すことができます。

ホスト識別子のいくつかの重要なガイドラインは、次のとおりです。

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

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

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

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

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

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

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

22.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

22.4.2 仮想Webホストについて

複数のWebサイトとドメイン名を含むWebサーバー上にWebgateをインストールできます。Webgateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。

多くの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認証のログイン・フォームが表示されます。

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

OAM Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。Apacheベースのサーバー以外のほとんどのWebサーバーでは、「優先ホスト」の値をHOST_HTTP_HEADERに設定する必要があります。これにより、ユーザーのブラウザからリクエストが送信されると、Webgateにより、「優先ホスト」の値がリクエストのホスト値に設定されます。

たとえば、次に示すように、ユーザーがURLに文字列example2を入力したとします。

http://example2

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

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

HOST_HTTP_HEADER

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

  • ホスト・ヘッダー名

  • IPアドレス

  • ポート

関連項目:

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

OAM Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。ApacheベースのWebサーバー(Apache、Apache 2、IBM HTTP Server、Oracle HTTP Serverなど)では、「優先ホスト」の値をSERVER_NAMEに設定する必要があります。

ノート:

SERVER_NAME値は、Apacheベースのサーバー以外のホストでサポートされません。この値をApacheベース以外のサーバーに設定すると、ユーザーはそのWebサーバーのWebgateで保護されるリソースにアクセスできません。かわりに、ユーザーはWebgate構成が正しくないことを示すエラーを受け取ります。

ServerNameディレクティブは、hostNameとともに明示的に7777に設定する必要があります。これはListenディレクティブが正しく設定されているかどうかには関係ありません。サーバーは、自己識別のためにこの値を明示的に要求する場合がありますが、通常は自動的に自己識別が可能です。

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

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

AuthType Oblix
require valid-user

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

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

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

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

22.4.3 「ホスト識別子」ページ

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

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

図22-4は、ホストの正規名や、ユーザーが同じホストの指定に使用できるその他すべての名前を入力するための、入力コンソールの「ホスト識別子の作成」構成ページを示しています。

ノート:

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

図22-4 「ホスト識別子の作成」ページ

図22-4の説明が続きます
「図22-4 「ホスト識別子の作成」ページ」の説明

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

表22-3 ホスト識別子の定義

プロパティ 説明

名前

この定義の一意の名前。大文字および小文字の英字のみ使用します。句読点および特殊文字は使用できません。

説明

この構成の使用を示す200文字までのオプションの説明。

ホスト名のバリエーション

22.4.4 ホスト識別子の作成

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

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

関連項目:

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「ホスト識別子」をクリックします。

  3. 「ホスト識別子の作成」をクリックします。

  4. 「ホスト識別子の作成」ページで、次の情報を入力します。

    1. 名前

    2. 説明

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

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

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

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

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

  7. 「確認」ウィンドウを閉じて、新しい定義が結果表にリストされていることを確認します。

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

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

ノート:

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

関連項目:

「SSOエージェントの検索ページ」

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「ホスト識別子」をクリックします。
  3. 「ホスト識別子の検索」ページで、「名前」フィールドに名前(または名前の一部とワイルドカード(*))を入力するか、またはすべてのホスト識別子を表示するために「名前」フィールドを空白のままにします。たとえば: 
    my_h*
  4. 「検索」ボタンをクリックして検索を開始し、表に結果が表示されたら、次の操作を実行します。

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

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

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

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

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

有効な管理者の資格証明を持つユーザーは、ホスト識別子の定義を変更できます。

これには、個々のホスト識別子の定義の追加、変更または削除が含まれます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加する場合、既存のホスト識別子定義を変更して新しいホスト名バリエーションを追加する必要がある場合があります。

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

ノート:

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

関連項目:

「「ホスト識別子」ページ」

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

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

    1. 名前

    2. 説明

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

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

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

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

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

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

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

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

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

Prerequisites

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

関連項目:

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

  1. このホスト識別子を使用するアプリケーション・ドメインの関連するリソース定義を検索して変更します。「リソース定義の検索」を参照してください。
  2. 「ホスト識別子定義の検索」の説明に従って、目的のホスト識別子を検索します。
  3. 表示: 結果表で名前をダブルクリックして構成ページを表示し、削除可能であることを確認します。
  4. 削除: ツール・バーの「削除」ボタンをクリックして、結果表で選択されたアイテムを削除し、「確認」ウィンドウで削除を確認します。

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

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

この項では次のトピックを記載しています:

22.5.1 Access Managerでサポートされる認証方式

認証は、ユーザーを証明するプロセスです。Access Managerを使用してユーザーのアイデンティティを認証することは、事前定義された一連のプロセスを実行してユーザーのデジタル・アイデンティティを確認することを示します。Access Managerを使用すると、認証スキームという単一の認証プロセスでリソースまたはリソースのグループを保護できます。認証スキームは、事前定義済の認証モジュールまたはプラグインに依存します。

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

マルチレベル認証

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

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

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

関連項目:

「マルチステップ認証」

マルチステップ認証

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

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

Windowsネイティブ認証

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

その他の認証タイプ

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

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

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

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

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

ノート:

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

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

22.5.2 埋込み資格証明コレクタと外部資格証明コレクタ

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

ノート:

資格証明コレクションでは、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)には、本質的な違いはありませんが、これらの比較を表22-4に示します。

関連項目:

「資格証明コレクションおよびログインの理解」

表22-4 DCCとECCの比較

機能 DCC ECC

デプロイメント

外部資格証明コレクタは、サーバーの論理部分に存在し続けて、OAMサーバーのフロント・チャネル通信のエンドポイントとして機能します。ただし、DCCは次のようにも構成できます。

  • スタンドアロン(OAMサーバーからデタッチされ、アプリケーション・サーバーを必要としません)。

  • RSA SecurIDのパスコード検証、次回のトークンの取得、新規PIN作成のワークフローをサポートします。

  • サーバーのスケールアウト、攻撃リジリエンスに対する優れた柔軟性に加え、資格証明コレクションUIの作成、フローおよびライフサイクル管理を使用して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ファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。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

ノート: /oamsso-bin内の、login、logoutおよびsecuridスクリプトの最初の行にあるPerlの場所を更新してください。

関連項目:

ユーザーが資格証明を入力するページです。OAMサーバーにデフォルトで付属し、追加の設定や変更は必要ありません。

  • ログイン・ページ: /pages/login.jsp

  • ログアウト・ページ: /pages/logout.jsp

  • エラー・ページ: /pages/servererror.jsp

  • マルチステップ: /pages/mfa_login.jsp

DCCベースのログインおよびログアウトを行うPerlスクリプト

DCCベースのログインおよびログアウトを行うPerlスクリプト

Perl実行ファイルのパス名は、Webgateホストの$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へのパスに更新する必要があります。

N/A

パスワード・ポリシーの強制

はい。

「DCC対応のOAM Webゲートと認証ポリシーの構成」を参照してください

はい

関連項目: 「グローバル・パスワード・ポリシーの管理」

認証スキームのコレクション・メソッド

DCCはフォーム・ベースの認証のみサポートします。

ECCはすべてのチャレンジ・メソッドをサポートしています。

ECCは、認証スキームのチャレンジ・メソッドに基づいてユーザーの資格証明を収集し、その資格証明を検証するためにOAMサーバーに送り返します。

カスタム認証プラグインとチャレンジ・メソッド

可。ECCと同じです。

すべてのチャレンジ・メソッドとマルチステップ認証(パスワード・ポリシーと、その他のカスタム認証プラグイン)がサポートされます。

シングル・ステップ(単純フォーム)認証

可。ECCと同じです。

はい。次の場合、DCCとECCの両方がこれを処理ます。

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

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

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

マルチステップ認証

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

この場合、次のようになります。

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

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

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

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

「マルチレベル認証およびステップアップ認証の理解」を参照

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

認証処理

ECCと比較すると、DCCがOAMサーバーの認証機能を制限することはありません。

DCC:

  1. OAM Webゲートからの認証リダイレクトを処理します。

  2. ユーザーの資格証明(単純フォームまたはマルチファクタ)に対するチャレンジを含むフォームベース認証を処理します。

  3. エージェント・キーを使用するエージェントからの認証リクエスト・メッセージを復号化し、基本的な整合性チェックを実行し、リクエストの時刻を検証し、リクエスト・コンテキストを含むリクエストからすべてのパラメータを抽出します。

  4. 最初に取得したリクエスト・コンテキストを含む認証レスポンス・メッセージを作成し、エージェント・キーを使用してobrarを復号化します。

  5. エージェント・キーを使用してログアウト・リダイレクト・リクエストを復号化し、ログアウト処理を起動します。

認証時:

  1. ECCは、プロトコル・バインディング・レイヤー(PBL)に着信するリクエストを処理します。PBLでは、リクエストを変換してSSOエンジンに送信します。

  2. SSOエンジンは、有効なセッションについてチェックします。有効なセッションが存在しない場合は、認証エンジンに制御を移します。

  3. 認証エンジンは、リソースの保護についてチェックし、そのリソースに関連付けられた認証スキームをフェッチします。

  4. ECCはクライアントと対話し、データを受け入れて、これをPBLに送信します。

ECCのオーバーライド

DCCをデプロイしてECCを無効にする場合、管理者は次のタスクを実行して、関連するDCC URLとフォームを指定する必要があります。

  • OAMエージェント登録: 資格証明コレクタ操作の許可(DCCに対して有効化)

  • 認証モジュール、ステップ編成: エラー(失敗時)

  • 認証スキーム: チャレンジ・リダイレクトURL (DCCホストおよびポート)

  • 認証スキーム: チャレンジURL /oamsso-bin/login.pl (DCCログイン・ページ)

  • 認証スキーム: チャレンジ・メソッド

  • パスワード・ポリシー: DCCのパスワード・サービスURL (デフォルト: /oamsso-bin/login.pl)

「DCC対応のOAM Webゲートと認証ポリシーの構成」を参照してください

N/A

ログアウト構成

「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」を参照

「OAM Webゲートの集中ログアウト構成」を参照

Cookie/トークン

  • DCCCtxCookie

  • OAM Webゲート: OAMAuthnCookie

  • OAM Webゲート: OAMRequestContext

関連項目: 「ユーザー・ログイン時のシングル・サインオンCookie」

  • OAM Webゲート: OAMAuthnCookie

  • OAM Webゲート: OAM_REQ

  • OAM Webゲート: OAM_ID

  • OAM Webゲート: OAMRequestContext

関連項目: 「ユーザー・ログイン時のシングル・サインオンCookie」

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

管理イベント以外に、認証の成功および失敗イベントが監査されます。監査には、認証スキーム、モジュールおよびポリシーの作成、変更、表示および削除が含まれます。

認証するユーザーに関して収集される情報は、次のとおりです。

  • IPアドレス

  • ユーザーのログインID

  • アクセス時間

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

関連項目:

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

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

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

この項では、次の情報について説明します。

22.6.1 ネイティブのAccess Manager認証モジュール

ネイティブのAccess Manager認証モジュールには、LDAP、LDAPNoPasswordAuthModule、Kerberos、X509およびカスタム認証モジュールがあります。

表22-5に、ネイティブのAccess Manager認証モジュールとその説明をまとめます。

表22-5 ネイティブ認証モジュール

モジュール名 説明

LDAP

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

関連項目: 「ネイティブのLDAP認証モジュール」。

LDAPNoPasswordAuthModule

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

関連項目: 「ネイティブのLDAP認証モジュール」。

Kerberos

キー・タブ・ファイル名、krb5.configurationファイル名およびプリンシパルを指定します。

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

関連項目: 「ネイティブのKerberos認証モジュール」。

X509

LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示す追加プロパティを使用するLDAPPluginに似ています。

関連項目: 「ネイティブのX.509認証モジュール」。

カスタム認証モジュール

このタイプのモジュールは、バンドルされているプラグイン(またはAccess Manager認証拡張機能Java APIを使用して開発されたプラグイン)に依存しています。このタイプのモジュールは、通常、複数のプラグインを使用します。これらのプラグインは、各プラグインが固有の認証機能を実行することが保証されるように編成できます。各プラグインに定義されている成功アクションまたは失敗アクションに応じて、別の認証プラグインがコールされます。

関連項目: プラグインの開発とデプロイ、カスタム認証モジュールおよびカスタム・モジュールを使用するスキームの詳細は、「マルチステップ認証モジュールによるAccess Managerの構成のための事前移入済プラグイン」および『Oracle Access Management開発者ガイド』の「カスタム認証プラグインの開発」を参照してください。

関連項目:

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

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

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

図22-5の説明が続きます
「図22-5 ネイティブのKerberos認証モジュール」の説明

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

表22-6 ネイティブの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キー配布センターの場所)。

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

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

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

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

図22-6の説明が続きます
「図22-6 ネイティブのLDAP認証モジュール」の説明

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

ノート:

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

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

要素 説明

名前

このモジュールの一意の名前。

ユーザー・アイデンティティ・ストア

指定されたLDAPユーザー・アイデンティティ・ストアは、このモジュールの認証に必要なユーザー資格証明を含んでいる必要があります。LDAPストアはAccess Managerに登録されていなければなりません。

関連項目: 「ユーザー・アイデンティティ・ストアの登録および管理」。

複数のアイデンティティ・ストア・ベンダーがサポートされています。インストール時には、ユーザー・アイデンティティ・ストアは1つのみで、それが指定されたシステム・ストアでもあります。アイデンティティ・ストアを追加し、別のストアをシステム・ストアとして指定する場合には、必ずそのシステム・ストアを参照するようにLDAPモジュールを変更してください。認証スキームOAMAdminConsoleSchemeは、管理者ロールと資格証明をLDAPモジュールに依存します。

関連項目: 「ユーザー・アイデンティティのシステム・ストアの使用について」および「管理者のロックアウト」。

22.6.1.3 ネイティブのX.509認証モジュール

Access Managerには、デフォルトとして事前構成済X.509認証モジュールが用意されています。管理者が新しいX.509認証モジュールも作成することもできます。暗号化の表現の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応答者です。

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

図22-7 ネイティブのX.509認証モジュール

図22-7の説明が続きます
「図22-7 ネイティブのX.509認証モジュール」の説明

表22-8では、ネイティブのX.509認証モジュールの要件について説明します。

ノート:

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

表22-8 X509認証モジュールの定義

要素 説明

名前

一意の名前でこのモジュール定義を識別します。

一致するLDAP属性

特定の「X509証明書属性」値に対して検索されるLDAP識別名属性を定義します。

たとえば、証明書のサブジェクトEMAILがme@example.comで、それがLDAP属性の"mail"に一致する必要がある場合、LDAP問合せは、me@example.com (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サーバーにアクセスできる期限が切れた証明書を使用するユーザーの猶予期間を指定します。

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

有効な管理者の資格証明を持つユーザーは、既存の認証モジュールを変更できます。

これには、既存のモジュール名の変更および他の属性の変更が含まれます。

Prerequisites

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

ノート:

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

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「認証モジュール」をクリックします。
  3. 「検索結果」リストで、目的のモジュールを選択して、そのプロパティ・ページを開きます。
  4. プロパティ・ページで、必要に応じて情報を変更します。

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

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

    • X.509モジュール: 表22-8および表22-14を参照してください

  5. 「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。
  6. 「認証スキームの管理」の説明に従って、更新された認証モジュールを認証スキームに追加します(または、このモジュールを参照する各認証スキームで、別の認証モジュールに変更します)。

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

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

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

Prerequisites

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

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「認証モジュール」をクリックします。
  3. オプション: モジュールを開いて削除するモジュールであることを確認してから、ページを閉じます。
  4. 「検索結果」リスト内で目的のモジュール名をクリックし、「削除」ボタンをクリックします。
  5. 削除を確認します(またはモジュールを保持する確認ウィンドウを閉じます)。

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

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

認証処理では、1つの認証モジュールを使用して、バックエンド認証スキームに対する情報の要件および転送を制御するルールを定義します。プラグインにより収集され、コンテキストに保存された情報は、プラグインが認証プロセスを介してアクセスできます。

コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。

ノート:

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

この項では次のトピックを記載しています:

関連項目:

カスタム・プラグインを開発するには、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム認証プラグインの開発に関する項を参照してください。

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

単純フォームベースの認証は、デフォルトであるため、フォームをカスタマイズしないときには、追加の設定は必要ありません。認証プラグインは、特定のマルチステップ認証のニーズを満たす処理を実現します。

単純フォームベースの認証は、デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタと、Access Manager認証メカニズムでユーザー・ログインを処理するWebフォームに依存します。単純フォームベースの認証を使用する場合:

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

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

  • 認証は失敗時、再試行できます。

関連項目:

ログイン・ページおよびフォームのカスタマイズの詳細は、「カスタム・ページの開発」

動的なマルチステップ認証のために、Access Managerは、独自にカスタマイズした認証モジュールで設計および編成できる、いくつかのプラグインを提供しています。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、反復および変数)の認証プロセスを、次のように処理します。

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

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

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

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

ノート:

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

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

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

認証方式 説明

フォームベースの簡易認証

単純フォームベースの認証は、資格証明コレクタ(ECCおよびDCC)と、Access Manager認証メカニズムを使用してユーザー・ログインを処理するWebフォームに依存します。これはデフォルトであるため、フォームをカスタマイズしないときには、追加の構成は必要ありません。

関連項目:

ログイン・ページおよびフォームのカスタマイズの詳細は、「カスタム・ページの開発」

マルチステップ認証

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

マルチステップ認証は、次のものに依存しています。

  • 認証のチェーン化: 複数の認証プラグインを新しい認証モジュールにチェーンして、そのモジュールを認証スキームに追加できます。

  • チャレンジ・メカニズム: 必要な資格証明の収集方法を制御します。現在は、認証スキームに関連付けられています。ECCとDCCは同じチャレンジ・メカニズムを使用します。

  • 資格証明コレクション: マルチステップ認証には、ECCまたはDCCのどちらかを使用できます。(DCCにより、ユーザーのアイデンティティを確立するための様々な方法を使用して認証関連情報を収集する際の、ユーザーとの対話またはプログラム・エンティティとの通信の柔軟性が大幅に向上します)。

関連項目:

DCC対応のOAM Webゲートと認証ポリシーの構成

「カスタマイズされたステップアップ認証モジュール内のステップとプラグイン」

カスタム認証プラグインの詳細は、「カスタム認証プラグインの開発」

22.7.2 マルチステップ認証モジュールのAccess Managerプラグイン

プラグインは、デフォルトの埋込み資格証明コレクタ(ECC)か、オプションの外部資格証明コレクタ(DCC対応のWebゲート)のいずれかと連動します。各認証プラグインは個別の機能部分を提供しており、これらは単独で使用するか、一連のステップにつなぎ合わせて使用することができます。プラグインのライフサイクルは、プラグインを追加および使用して、OAMサーバーの拡張機能として動作する機能やワークフローを構築できるようにすることに中心が置かれています。各プラグインはJARファイルとしてデプロイされるので、各プラグインの構成要件はXML形式で指定する必要があります。

カスタム・プラグイン・ベースの認証モジュールは、既存のAccess Managerを使用して作成できます。独自のプラグインを作成するには、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム認証プラグインの開発に関する項を参照してください。

ノート:

標準(ネイティブの)認証モジュールは、非推奨になる予定です。将来の拡張機能は、標準モジュールでは使用できなくなる予定です。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースのモジュールを使用することをお薦めします。

図22-8は、即時利用可能なプラグインを示しています。カスタム認証モジュールを構築するためのステップを追加すると、これらのプラグインと、ユーザーがSDKや使用して作成したりインポートしたプラグインが、リストに表示されます。

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

図22-8の説明が続きます
「図22-8 カスタマイズした認証モジュールのAccess Managerプラグイン」の説明

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

関連項目:

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

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

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

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

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

ノート:

マルチファクタ認証を使用している場合、認証プロセス中の最後のパスでUserIdentificationPluginを起動する必要があります。

図22-9は、「システム構成」ツリーの「Access Manager」セクションにある「カスタム認証モジュール」を示しています。各モジュールには3つの構成タブがあります。

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

図22-9の説明が続きます
「図22-9 カスタム認証モジュールの作成: 「一般」」の説明

表22-10は、「一般」タブの内容の説明です。

表22-10 「一般」タブ

要素 説明

名前

一意の名前で、60文字以内です。

説明

オプション。250文字以内です。

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

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

図22-10の説明が続きます
「図22-10 ステップの追加とプラグインの関連付け」の説明

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

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

要素 説明

ステップ名

ステップを識別するために入力する一意の名前で、60文字以内です。

説明

ステップを追加するときにオプションで入力する、このステップの説明(250文字以内)。

プラグイン名

特定のステップに対して選択するプラグインです。インポートされアクティブ化されているプラグインのリストから選択します。

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

ステップの詳細

正しい操作を確実に実行するために、プラグインの構成詳細を指定する必要があります。詳細の内容は、選択したプラグインと、そのプラグインの要件によって異なることがあります。

関連項目: 表22-12。

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

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

プラグイン・パラメータ 表示名 説明

KEY_IDENTITY_STORE_REF

アイデンティティ・ストア名

認証時に適切なユーザー・アイデンティティ・ストアが呼び出されるようにするために、ほとんどのプラグインでこの属性が必要になります。

次のプラグインは、このプロパティのみを使用します。

  • TAPAssertionPlugIn

このプロパティを採用するプラグインに必要な追加の詳細は、次を参照してください。

  • UserIdentificationPlugIn

  • UserAuthenticationPlugIn

  • UserPasswordPolicyPlugin

  • TAPUserAuthenticationPlugin

  • TenantDisambiguationPlugin

CredentialCollectorPlugIn

CredentialCollectorPlugIn

このプラグインにより、管理者は、認証用にどの資格証明を収集するかを構成できます。収集される資格証明は、ステップ・パラメータとして構成されます。プラグインは、これらのパラメータを検証して、資格証明を収集するUIを表示します。ユーザーの入力後、資格証明パラメータを解析し、資格証明オブジェクトでユーザー・コンテキストを構築します。

ノート: 資格証明が無効で、プラグインが失敗を返した場合、プラグイン・エラー・レスポンスがコンテキストに設定されます。

このプラグインは、ステップ・レベル・パラメータとして4つの資格証明のコレクションをサポートします。

  1. CRED_PARAM_1

  2. CRED_PARAM_2

  3. CRED_PARAM_3

  4. CRED_PARAM_4

次の例は、ユーザー名とパスワードを収集する方法を示しています。

CRED_PARAM_1=
{ID=KEY_USERNAME},{DISPLAY_NAME=KEY_USERNAME},{TYPE=text}
{ID=KEY_PASSWORD},{DISPLAY_NAME=KEY_PASSWORD},{TYPE=password}

ID、DISPLAY_NAMEおよびTYPEは定数です。

Actiontype

アクション・タイプ

プラグインが資格証明を収集するログイン・ページにリダイレクト(REDIRECT)するか転送(FORWARD)するかを示します。

loginPageURL

ログイン・ページのURL

資格証明の収集においてユーザーを転送またはリダイレクトするURL。

NO_OF_CREDENTIALS

プラグイン・インスタンスに対して提供される資格証明の数。インスタンス数が5つ以上ある場合、ユーザーは、oam-configファイルを更新して、プラグイン・パラメータのCRED_PARAMSを追加する必要があります。

UserIdentificationPlugIn

UserIdentificationPlugIn

このネイティブ・プラグインは、ユーザーを特定のLDAPユーザー・レコードにマップします。

KEY_LDAP_FILTER

LDAPフィルタ

ユーザーを特定するために必要な検索フィルタです。LDAP検索フィルタを定義するときは、LDAP属性を使用します。

KEY_SEARCHBASE_URL

LDAP検索ベース

問合せに必要な検索ベースです。ディレクトリ情報ツリー(DIT)のノードです。このノード以下にユーザー・データが格納されるため、すべてのユーザー・データ検索の最高位のベースになります。

UserAuthenticationPlugIn

UserAuthenticationPlugIn

このネイティブ・プラグインは、提供されたユーザー名とパスワードの資格証明をLDAPディレクトリに対して認証します。

KEY_PROP_AUTHN_EXCEPTION

LDAPエラーの伝播

LDAPエラーの伝播を有効(または無効)にします。UserAuthenticationPlugInは、この属性を採用しています。

UserAuthnLevelCheckPlugin

UserAuthnLevelCheckPlugin

このネイティブ・プラグインは、ユーザーが認証レベルXに対して認証済かどうかを判断します(Xの値は、プラグイン・パラメータAUTHN_LEVEL_FOR_PLUGINによって提供される値です)。たとえば、指定値で、現在のユーザーの認証レベルをチェックします。加えて、このプラグインは、認証レベル・チェックが成功したか失敗したかに応じて、収集するパラメータのリストを指定します。

AUTHN_LEVEL_FOR_PLUGIN

AUTHN_LEVEL_FOR_PLUGIN

認証レベルを整数で指定します。

複数のステップの場合はUserAuthnLevelCheckPluginを使用できます。ただし、各ステップに一意の名前とAUTHN_LEVEL_FOR_PLUGINがある必要があります。

関連項目: 「カスタマイズされたステップアップ認証モジュール内のステップとプラグイン」

UserPasswordPolicyPlugin

UserPasswordPolicyPlugin

PLUGIN_EXECUTION_MODE

操作モード

UserPasswordPolicyPluginの実行モード。UserPasswordPolicyPluginは、LDAPベースの認証モジュールを使用する場合にのみサポートされます。非LDAP認証モジュールを使用する場合は使用できません。構成に応じて、単独で、または他のプラグインとともに動作できます。値は次のいずれかになります。

  • PSWDONLY: デフォルト。パスワードのステータスのみを決定する、最もお薦めされる構成です。IDと認証は、UserIdentificationおよびUserAuthenticationプラグインを使用して実行する必要があります。

  • AUTHWITHPSWD: このプラグインの実行によって、認証とパスワードの両方が実行されます。

  • AUTHONLY: ユーザーの識別と認可はこのプラグインを使用した場合にのみ実行されます。
     

NEW_USERPSWD_BEHAVIOR

初回ログイン時にパスワードの変更を強制

新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。UserPasswordPolicyPluginに使用します。値は、次のどちらかになります。

  • FORCECHANGEPASSWORD: パスワード変更を強制します。

  • NOFORCEPASSWORDCHANGE: パスワードのポリシー変更は、設定済のユーザー・パスワードには影響しません。

デフォルト: FORCECHANGEPASSWORD

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プラグイン

ユーザー名

ユーザー名パラメータ

ユーザー名プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

パスコード

パスコード・パラメータ

パスコード・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

nexttoken

次のトークン・パラメータ

次のトークン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

newpin

新規PINパラメータ

新規ピン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

confirmnewpin

新規PINの確認パラメータ

新規pinの確認プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。

HTTPTokenExtractor

KEY_HEADER_PROPERTY

HTTPヘッダー名

HTTPヘッダーのカンマ区切りのリストです。「HTTPTokenエクストラクタ・プラグインの構成」を参照してください。

KEY_COOKIE_PROPERTY

HTTP Cookie名

Cookieのカンマ区切りのリストです。「HTTPTokenエクストラクタ・プラグインの構成」を参照してください。

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

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

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

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

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

図22-12の説明が続きます
「図22-12 プラグイン・ベースの認証モジュールの「ステップ編成」」の説明

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

  • success

  • 失敗

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

表22-13 「ステップ編成」タブ

要素 説明

初期ステップ

リストから開始ステップを選択します。リストに含まれるのは、このモジュールに定義されているステップのみです。

名前

このモジュールに追加された各ステップが、追加するときに入力した名前別にリストされます。

説明

ステップを追加するときにオプションで入力した、このステップの説明。

OnSuccess

操作が成功した場合に選択されるアクション。選択できるアクションがリストに示されます。

  • 成功

  • 失敗

  • StepName (次のステップをアクティブ化します)

OnFailure

このステップが失敗した場合に選択されるアクション。選択できるアクションがリストに示されます。

  • 成功

  • 失敗

  • StepName (次のステップをアクティブ化します)

OnError

このステップを実行してエラーになる場合に選択されるアクション。選択できるアクションがリストに示されます。

  • 成功

  • 失敗

  • StepName (次のステップをアクティブ化します)

22.7.3 マルチステップ認証モジュールによるAccess Managerの構成のための事前移入済プラグイン

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

関連項目:

KerberosPlugin

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

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

図22-13 KerberosPlugin

図22-13の説明が続きます
「図22-13 KerberosPlugin」の説明

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

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

図22-14の説明が続きます
「図22-14 デフォルトのKerberosPluginステップと詳細」の説明

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

図22-15の説明が続きます
「図22-15 デフォルトのKerberosPluginステップと編成」の説明

LDAPPlugin

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

図22-16 LDAPPlugin

図22-16の説明が続きます
「図22-16 LDAPPlugin」の説明

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

図22-17の説明が続きます
「図22-17 デフォルトのLDAPPluginステップと詳細」の説明

図22-18 LDAPpluginのステップのデフォルト編成

図22-18の説明が続きます
「図22-18 LDAPpluginのステップのデフォルト編成」の説明

X509Plugin

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

図22-19 X509Plugin

図22-19の説明が続きます
「図22-19 X509Plugin」の説明

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

図22-20の説明が続きます
「図22-20 X509Pluginのデフォルト・ステップと詳細」の説明

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

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

関連項目:

表22-14 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

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

図22-21の説明が続きます
「図22-21 X509Pluginのステップのデフォルト編成」の説明

関連項目:

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

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

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

  • ユーザー識別ステップ

  • ユーザー認証ステップ

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

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

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

図22-22の説明が続きます
「図22-22 パスワード・ポリシー検証モジュールのプラグイン」の説明

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

関連項目:

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

図22-23の説明が続きます
「図22-23 「ステップ編成」: パスワード・ポリシー検証プラグイン」の説明

22.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属性を指定します。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「プラグイン」セクションで、「認証モジュール」をクリックします。

  3. モジュールのリストで、「X509Plugin」モジュールを選択します。

  4. 開かれたページで、「複製」をクリックして、各フィールドに次のように入力します。

    関連項目:

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

    「全般」タブ:

    1. 名前: CustomX509Plugin。

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

    「ステップ」タブ:

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

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

    ステップの詳細:

    1. KEY_IS_CERT_VALIDATION_ENABLED: true

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

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

    別のプラグインの追加:

    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. 「保存」ボタンをクリックします。

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

  5. ステップの編成:

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

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

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

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

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

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

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

    関連項目:

    「証明書の検証と失効」

    1. Oracle Access Managementコンソールで、ウィンドウの上部にある「構成」をクリックします。

    2. 「構成」コンソールで、「証明書検証」をクリックします。

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

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

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

      ノート:

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

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

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

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

関連項目:

前提条件

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

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「作成」(+)ドロップダウン・リストから「カスタム認証モジュールの作成」を選択します。

  3. 表示されるページで、「名前」を入力し、オプションで「説明」を入力します。たとえば、順に「CustomX509Plugin」と「X509のプラグイン」とします。

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

  4. ステップの追加:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  6. ステップの編成: 表22-13を参照して、次のステップを実行します。

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

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

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

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

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

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

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

    8. 編成を確認します。

  7. 戦略の検証の開始: 「適用」をクリックして、編成戦略の検証を開始します。

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

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

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

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

22.7.6 カスタマイズされたステップアップ認証モジュール内のステップとプラグイン

このカスタマイズされたステップアップ認証モジュール内の処理は、表22-15で説明されているステップとプラグインによって発生します。詳細は、表22-12を参照してください。

表22-15 カスタマイズされたステップアップ認証モジュール内のステップとプラグイン

ステップ番号 ステップ名 プラグイン名 説明

1

StandardLevelCheck-2

UserAuthnLevelCheckPlugin

LevelCheckルールと、チェック結果としてSUCCESSまたはFAILUREに関連付けられる資格証明パラメータで構成します。

このプラグインは、認証エンジンにアクセスして、ユーザーの現在の認証レベルを決定し、これを、プラグイン・レベル・パラメータAUTHN_LEVEL_FOR_PLUGINと比較します。また、カスタム資格証明コレクタとやり取りして、ユーザーの現在の認証レベルを指定値と比較します。たとえば、X値が2の場合:

  • 認証レベル >= Xの場合、ExecutionStatus.SUCCESSが返され、次のステップに進みます。たとえば、次に高いレベルの認証チェックが行われます。

  • 認証レベル < Xの場合、ExecutionStatus.FAILUREが返され、プラグイン内の次のステップに進みます。たとえば、レベル2用の標準資格証明(ユーザー名とパスワード)を収集します。

認証レベル・チェックが成功したか失敗したかに応じて収集するパラメータのリストを指定します。

  • ON SUCCESSの場合、SensitiveLevelCheck-6に進みます。

  • ON FAILUREの場合、CollectUserNamePasswordに進みます。

  • ON ERRORの場合、失敗になります。

2

CollectUserNamePassword

CredentialCollectorPlugin

フローは、収集する資格証明パラメータを伝えるプラグインから開始する必要があります。アクションは、サーバーがパラメータを不変としてマークできることをサポートする必要があります。

このプラグインは、資格証明コレクタ(CustomReadServlet)と対話して、管理者が、認証用に収集した資格証明を構成できるようにします。収集される資格証明は、ステップ・パラメータとして構成されます。プラグインは、これらのパラメータを検証して、資格証明を収集するUIを表示します。

ユーザーが、ステップ・パラメータで収集する必要がある資格証明を提供します。この例では、前のステップで、ユーザーがレベル2の認証を受けていないので、ユーザーはユーザー名とパスワードを入力するように要求されます。

  • loginPageURL: /CustomRead/Servlet(プラグイン指定の資格証明を取得するインタフェースを表示するUserAuthnLevelCheckPlugin用の汎用資格証明コレクタ)

  • No_OF_CREDENTIALS: 4

  • CRED_PARAM_4

  • CRED_PARAM_3

  • CRED_PARAM_2: {ID=KEY_PASSWORD},{DISPLAY_NAME=KEY_PASSWORD},{TYPE=password}

  • CRED_PARAM_1: {ID=KEY_USERNAME},{DISPLAY_NAME=KEY_USERNAME },{TYPE=text}

  • actiontype: FORWARD

収集する資格証明は、UIインタフェースを表示する資格証明コレクタ用に、この形式で指定する必要があります。

また、次のアクションも指定します。

  • ON SUCCESSの場合、UserIdentificationProcessに進みます。

  • ON FAILUREの場合、失敗になります。

  • ON ERRORの場合、失敗になります。

3

UserIdentificationProcess

UserIdentificationPlugIn

ユーザーを特定のLDAPユーザー・レコードにマップする即時使用プラグイン。

  • ON SUCCESSの場合、UserAuthenticationStepに進みます。

  • ON FAILUREの場合、失敗になります。

  • ON ERRORの場合、失敗になります。

4

UserAuthenticationStep

UserAuthenticationPlugin

提供されたユーザー名とパスワードの資格証明をLDAPディレクトリに対して認証する即時使用可能プラグイン。

  • ON SUCCESSの場合、SensitiveLevelCheck-6に進みます。

  • ON FAILUREの場合、CollectSensitiveLevelCredsに進みます。

  • ON ERRORの場合、失敗になります。

5

SensitiveLevelCheck-6

UserAuthnLevelCheckPlugin

このプラグインは、認証エンジンにアクセスして、ユーザーの現在の認証レベルを決定し、これを、プラグイン・レベル・パラメータAUTHN_LEVEL_FOR_PLUGINと比較します。また、カスタム資格証明コレクタとやり取りして、ユーザーの現在の認証レベルを指定値と比較します。チェックが成功したか失敗したかに応じて収集するパラメータを指定します。

  • ON SUCCESSの場合、成功になります。

  • ON FAILUREの場合、CollectSensitiveLevelCredsに進みます。

  • ON ERRORの場合、失敗になります。

6

CollectSensitiveLevelCreds

CredentialCollectorPlugin

レベル6認証用に資格証明を収集するためのUIを表示します。これはCollectUserNamePwdと似ています。

  • ON SUCCESSの場合、ValidateSensitiveLevelCredsに進みます。

  • ON FAILUREの場合、失敗になります。

  • ON ERRORの場合、失敗になります。

  • CRED_PARAM_1: {ID=securitycode},{DISPLAY_NAME=form_securecode},{TYPE=text}

7

ValidateSensitiveLevelCreds

SubjectSetPlugin

このカスタム・プラグインは、サーバーに対してセキュリティ・コードを検証します。

  • ON SUCCESSの場合、成功になります。

  • ON FAILUREの場合、失敗になります。

  • ON ERRORの場合、失敗になります。

プラグインを定義して、認証モジュールに編成した後、認証スキームでモジュールを使用して、そのスキームをポリシーで使用できます。

関連項目:

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

22.7.7 ステップアップ認証の構成

カスタマイズしたモジュール内でプラグインを使用してステップアップ認証を定義できます。

この例では、社内ポータルのページにアクセスするための標準レベルのアクセス権を必要とするユーザーと、機密情報にアクセスするためのアクセス権を必要とするユーザーがいます。標準アプリケーションに対する認証資格証明にはユーザー名とパスワードが含まれます。センシティブ・アプリケーションに対する資格証明には、ユーザー名、パスワードおよびセキュリティ・コード(コードの検証を行うカスタム・プラグインで取得)が含まれます。

  1. ステップアップ認証用に認証モジュールを作成または編集します。
  2. ここで示したステップに基づいてカスタム認証モジュールを定義します。
  3. 表22-15で説明したステップとプラグインをここに示すように編成します。
  4. センシティブ・スキーム: カスタマイズしたステップアップ認証モジュールを使用するセンシティブ・アプリケーション用の認証スキームを作成または編集します。たとえば:
  5. 下位レベル・スキーム: カスタマイズされたステップアップ認証モジュールを使用して、下位レベル・アプリケーション用の認証スキームを作成または編集します。次に例を示します。
  6. センシティブ・ポリシー: カスタマイズしたステップアップ認証スキームを使用するセンシティブレベル・リソース用の認証ポリシーを作成または編集します。たとえば:
  7. 下位レベル・ポリシー: カスタマイズしたステップアップ認証スキームを使用する下位レベル・リソース用の認証ポリシーを作成または編集します。たとえば:
  8. 検証: リソースと、リソースを保護するポリシーを検証します。

22.7.8 HTTPTokenエクストラクタ・プラグインの構成

HTTPTokenエクストラクタ・プラグインを構成できます。

構成するには、次のようにします。

  1. 認証を行うアプリケーションにユーザーをリダイレクトする、サンプル・プラグインを作成します。

    認証を行うアプリケーションは、ユーザーを認証し、HTTPヘッダーまたはCookieにユーザー名を設定します。

  2. 任意の該当するプラグインにアクセスする、カスタム認証モジュールを作成します。

    たとえば、前のステップで作成したプラグインとHTTPTokenエクストラクタおよびユーザー識別のプラグインを追加すると、この3つのプラグインすべての処理が正常に完了したときに、認証が成功します。

  3. ヘッダー名およびユーザー検索フィルタのプロパティの値を追加します。

    KEY_HEADER_PROPERTYはHTTPTokenエクストラクタ・プラグインで設定され、KEY_LDAP_FILTERはUIプラグインで設定されます。たとえば:

    • KEY_HEADER_PROPERTY = cookieorheadername

    • KEY_LDAP_FILTER = (uid={cookieorheadername})

    ノート:

    使用されるデータ・ストアにユーザーが存在する必要があります。

22.7.9 JSON Webトークン・プラグイン

Oracle Access Manager (OAM)には、ユーザーとアプリケーションの両方に対する完全ではあるが異なるアクセス管理ソリューションが用意されています。OAM認証後、WebゲートやOracle API Gatewayなどの製品で使用できるSSOトークンが発行されます。ただし、これらのトークンはOAMに固有であり、多くの場合は、WebサービスやRESTサービスを保護するというビジネス要件があります。 Webサービスの保護にはOAMトークンを使用できますが、通常は標準のトークンによって保護されます。JSON Webトークン(JWT)は、広く使用されている標準のトークンの1つです。

RSPS2リリースのOAMでは、Oracle Access Manager Mobile and Social (OAMMS)サービスで提供されるOAuth認可サービスの完全なサポートが導入されました。OAuthサービスは、ユーザーの認証または認可(あるいはその両方)の後にWebサービスにアクセスするためのJSON Webトークン(JWT)を発行します。したがって、ユーザーはOAM認証メカニズムにより認証された後、様々なリソースにアクセスするためにOAMとJWTの両方を持つことができます。これを使用できる典型的なシナリオは、Webゲートで保護されたアプリケーションにアクセスする場合です。ユーザーはOAM認証モジュールによって認証され、OAMトークンとJWTの両方が提供されます。Webゲートを介するアクセスにはOAMトークンが使用されますが、WebサービスまたはRESTサービスへのアクセスには必要に応じてJWTを使用できます。(WebサービスまたはRESTサービスは、Oracle API GatewayやOracle Web Services Managerなどの製品によって保護されます。)

OAMでは、JSON Webトークン・プラグインが使用できるようになりました。このJSON Webトークン・プラグインは、標準トークンでRESTサービスまたはWebサービスを保護する必要がある場合に使用します。JSON Webトークン・プラグインは、OAMトークンと、Webサービスへのアクセスに使用できるMobile and Social JWTの両方を発行します。Oracle API GatewayおよびOracle Web Services Managerでも、Webサービスの保護のためにこのJWTを使用できます。詳細は、次の各項を参照してください。

22.7.9.1 JSON Webトークン・プラグインの理解

デプロイメントでJSON Webトークン・プラグインを使用できます。

次のフローでは、JSON Webトークン・プラグインが使用される仕組みについて説明します。

  • OAM認証およびJSON Webトークン・プラグインの両方を使用するように、Oracle Access Management WebGateを構成します。

  • ユーザーがWebGateで保護されたリソースにアクセスする場合、WebGateはユーザーをリダイレクトしてAccess Managerで認証します。

  • 認証時に、プラグインは、どのOAuthサービス・エンド・ポイントでJWTを生成するかを特定します。(OAuthサービス・エンド・ポイントは一意であるため、特定のアイデンティティ・ドメイン内で特定のOAuthサービス・プロファイルを指すように構成できます。)Oracle Access Manager Mobile and SocialがJWTを作成し、プラグインがこれをCookieとして返します。(プラグイン構成でcookie名を構成できます。)

  • Webアプリケーションは、Webサービス・アクセス用に後で使用できるように、レスポンスを捕捉してcookieにアクセスします。Webアプリケーションのデプロイ方法によっては、JWTを取得するために他のオプションを使用できる場合があります。ユーザーは、これでWebリソースにアクセスできます。

  • WebリソースはWebサービスにアクセスする必要がある場合、OAM Mobile and Social JWTを抽出してOracle API Gatewayに送信します。

  • Oracle API Gatewayは、Oracle OAuth Service REST APIを使用してトークンを検証します。その後、Webサービスにアクセス権を付与します。Oracle API Gatewayは、OAuthサービスをリモートからコールせずに、ローカルにJWTを検証することもできます。

ノート:

現在、OAM認証でJWTを発行している間にOAuthサービスにスコープを渡すメカニズムはありません。したがって、トークンはグローバル・スコープを持つとみなされます。

OAMトークンのタイムアウトとJWTのタイムアウトの両方を同じ値に設定して、同じ有効期間にすることができます。OAMトークンとJWTはリンクされていないため、シングル・ログアウトを使用してこれらを終了することはできません。

22.7.9.2 JSON Webトークン・プラグインの構成

JSON Webトークン・プラグインを構成できます。

カスタム認証モジュールを作成します。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

    「認証モジュールの検索」画面が表示されます。

  2. 「プラグイン」セクションの「作成」(+)ドロップダウン・メニューから、「カスタム認証モジュールの作成」を選択します。

    「一般」タブが表示されます。

  3. カスタム認証モジュールの名前および説明(オプション)を入力します。

    この例のために、モジュールにJWTToken AuthnModuleという名前を付けます。

  4. 「ステップ」タブおよび+ (プラス記号)をクリックして、新しいステップを追加します。

    「新規ステップの追加」ダイアログが表示されます。3つの新しいステップが追加されます。

  5. ステップ名と説明(オプション)を指定し、「プラグイン名」ドロップダウン・リストからアクティブなプラグインを選択し、「OK」をクリックします。

    この例では、値はStepUIおよびUserIdentificationPluginです。このプラグインのフロー・パラメータは、ステップに追加後、編集できるようになります。

  6. UserIdentificationPluginパラメータの値を入力して、「保存」をクリックします。

  7. + (プラス記号)をクリックして2つ目のステップを追加します。名前としてStepUAと入力し、ドロップダウン・リストから「UserAuthenticationPlugin」を選択して「OK」をクリックします。

  8. UserAuthenticationPluginパラメータの値を入力して、「保存」をクリックします。

  9. + (プラス記号)をクリックして3つ目のステップを追加します。名前としてStepOAuthと入力し、ドロップダウン・リストから「OAuthTokenResponsePlugin」を選択して「OK」をクリックします。

  10. OAuthTokenResponsePluginパラメータの値を入力して、「保存」をクリックします。

  11. 「ステップ編成」タブをクリックして、次の順序でステップの編成を構成します。

    1. StepUI

    2. StepUA

    3. StepOAuth

  12. 「適用」をクリックして、「カスタム認証モジュール」タブを閉じます。

  13. 「起動パッド」から「認証スキーム」をクリックします。

  14. 「LDAPScheme」を選択して、「複製」をクリックします。

    LDAPSchemeのコピー画面が表示されます。

  15. 「名前」の値をJWTToken AuthnSchemeに、認証モジュールの値をJWTToken AuthnModuleに変更します。

  16. 「保存」をクリックします。

  17. 新しく定義されたJWTToken AuthnScheme認証スキームを使用して認証ポリシーを構成します。

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

管理者は、カスタム・プラグインを作成して、カスタマイズされたマルチステップ認証を定義するためにそれらを追加、検証、配布およびアクティブ化できます。

この項では次のトピックを記載しています:

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

カスタム認証プラグインを作成し、そのプラグインを使用して、カスタマイズされたマルチステップ認証モジュールを定義できます。

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム認証プラグインの開発に関する項の説明に従ってカスタム・プラグインを開発します。プラグインの開発後、JARファイルとして管理サーバーにデプロイする必要があり、自動的に検証されます。検証後、Oracle Access Managementコンソールを使用してプラグインを構成および配布できます。

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

「プラグイン」ページは、「システム構成」タブの「共通構成」セクションにある「プラグイン」ノードについても説明しています。「プラグインの詳細」ページは、表内の選択されたプラグインの構成詳細を反映しています。

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

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

Prerequisites

『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム認証プラグインの開発に関する項の説明に従ったカスタム・プラグインの開発。

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

    1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

    2. 「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「認証プラグイン」をクリックします。

    3. 表示されるページで、「プラグインのインポート」をクリックします。

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

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

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

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

    1. 「プラグイン」表で、ターゲット・プラグインを選択します。

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

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

    1. 「プラグイン」表で、ターゲット・プラグインを選択します。

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

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

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

有効な管理者の資格証明を持つユーザーは、カスタム・プラグインをアクティブ化し、アクティブ化ステータスをチェックできます。

Prerequisites

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

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「認証プラグイン」をクリックします。
  3. 「プラグイン」表で、ターゲット・プラグインを選択します。
  4. サーバー・インスタンス名: 「プラグインの詳細」セクションを開き、「アクティブ化のステータス」をクリックしてプラグインの場所とステータスを表示します。
  5. 必要に応じて次のタスクを実行します。

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

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

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

Prerequisites

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

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「認証プラグイン」をクリックします。

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

    1. 「プラグイン」表で、ターゲット・プラグインを選択します。

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

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

    1. 「プラグイン」表で、ターゲット・プラグインを選択します。

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

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

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

22.8.5 プラグイン・ページ

「システム構成」タブおよび「プラグイン」ページの「共通構成」セクションの下に、プラグイン・ノードに関する情報を表示します。

「プラグイン」ページには、表で選択されたプラグインを操作するコマンド・ボタンが多く含まれるツール・バーがあります。この表は、既存のカスタム・プラグインとその状態に関する情報を提供します。

図22-24 プラグイン・ページ

図22-24の説明が続きます
「図22-24 「プラグイン」ページ」の説明

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

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

アクション・ボタン 説明

プラグインのインポート

データベースのOAM_FILE_ARTIFACTS表にプラグイン情報をアップロードし、プラグイン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におけるステータスも「アップロード済」となります。

関連項目: 『Fusion Middleware Oracle Access Management開発者ガイド』のカスタム認証プラグインの開発に関する項を参照してください。

選択項目の配布

AdminServer上でのみ、データベースから$DOMAIN_HOME/config/fmwconfig/oam/pluginsディレクトリに、インポートしたプラグインをダウンロードします

  • 登録済のすべてのOAMサーバーにプラグインを伝播します。

  • AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

  • データベースから$DOMAIN_HOME/config/fmwconfig/oam/pluginsの下の各OAMサーバー・ノードに、プラグインJARを配布します。

成功時: ステータスが「配布済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「配布済」と報告し、AdminServerにおけるステータスも「配布済」となります。

失敗時: ステータスは「配布に失敗しました」と報告されます。

選択項目のアクティブ化

プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。

アクティブ化:

  • AdminServerとOAMサーバーの間で、メッセージ・リスナーおよび通知メカニズムを起動します。

  • AdminServerは、すべての登録済OAMサーバーにアクティブ化通知を送信します

成功時: ステータスが「アクティブ化済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アクティブ化済」と報告し、AdminServerにおけるステータスも「アクティブ化済」となります。

失敗時: ステータスは「アクティブ化に失敗しました」と報告されます。

すべてのOAMサーバーについてアクティブ化した後、認証モジュールの作成または編成でプラグインを使用および実行できます。

選択項目の非アクティブ化

プラグインをアクティブ化した後で、管理者はプラグインが認証モジュールまたはスキームで使用されていない場合などに、プラグインの非アクティブ化を選択できます。登録済のすべてのOAMサーバーから選択されたプラグイン。

非アクティブ化:

  • AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

  • AdminServerおよび登録済の各OAMサーバー($DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。

  • AdminServerは、登録されたすべてのOAMサーバーに非アクティブ化通知を送信します

成功時: ステータスが「非アクティブ」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「非アクティブ」と報告した場合、AdminServerのステータスも「非アクティブ」となります。oam-config.xmlからプラグイン構成が削除されます。

ノート: 非アクティブ化の後は、認証モジュールまたは編成でプラグインを使用または実行できません。

失敗時: ステータスは「非アクティブ化に失敗しました」と報告されます

選択項目の除去

プラグインを非アクティブ化した後、管理者は選択したプラグインを削除できます。このプロセスで、Access Managerは次のことを行います。

削除:

  • AdminServerとOAMサーバーの間で、配布リスナーおよび通知メカニズムを起動します。

  • AdminServerおよび登録済の各OAMサーバー($DOMAIN_HOME/config/fmwconfig/oam/plugins)からプラグインJARを削除します。

成功時: ステータスが「削除済」として報告されます(OAMサーバーが停止している場合も同様)。プラグイン構成は、「削除済」という更新されたステータスでoam-config.xmlにそのまま残ります。

失敗時: ステータスは「削除に失敗しました」と報告されます。

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

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

要素 説明

プラグイン名

XMLメタデータ・ファイルのプラグイン名要素から抽出されます。

説明

XMLメタデータ・ファイルの説明要素から抽出されます。

アクティブ化のステータス

AdminServerの情報に基づいてアクティブ化のステータスが報告されます。

タイプ

XMLメタデータ・ファイルのタイプ要素から抽出されます。

Last Updated on

XMLメタデータ・ファイルの作成日要素から抽出されます。

最終更新者

XMLメタデータ・ファイルの作成者要素から抽出されます。

22.8.6 プラグイン詳細ページ

「プラグインの詳細」ページに関する情報を提供します。

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

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

図22-25の説明が続きます
「図22-25 「プラグインの詳細」: 選択したプラグインのアクティブ化のステータス」の説明

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

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

構成要素 説明

DataSource

 
- <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詳細を定義します。

KEY_KEYTAB_FILE, KEY_PRINCIPAL, KEY_KRB_CONFIG_FILE

ユーザー識別詳細

このプラグインが使用するユーザー・アイデンティティ・ストアおよびLDAPフィルタのパラメータを定義します。

KEY_IDENTITY_STORE_REF, KEY_LDAP_FILTER

ユーザー認証詳細

このプラグインが使用するユーザー・アイデンティティ・ストアを定義します。

KEY_IDENTITY_STORE_REF

X.509詳細

このプラグインが使用するX.509証明書詳細を定義します。

KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT, KEY_IS_CERT_VALIDATION_ENABLED

22.9 認証スキームの管理

リソースまたはリソースのグループへのアクセスは、認証スキームという単一の認証プロセスで制御できます。認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。

各認証スキームには、定義済の認証モジュール(「個別の認証用プラグインのデプロイおよび管理」で説明した標準またはカスタムのモジュール)も含める必要があります。

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

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

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

22.9.1 認証スキームおよびページ

すべての認証スキームには、異なる値を使用した同じ要素が含まれます。

図22-26は、例としてデフォルトのLDAPSchemeページを示しています。

図22-26 デフォルトのLDAPSchemeページ

図22-26の説明が続きます
「図22-26 デフォルトのLDAPSchemeページ」の説明

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

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

要素 説明

名前

ナビゲーション・ツリーに表示されるこのスキームの一意の名前。

関連項目: 「事前構成済の認証スキーム」

説明

このスキームの使用を示す200文字までのオプションの説明。

認証レベル

認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。

信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。

ノート: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表25-1を参照してください。

ノート: 指定されたレベルのリソースにユーザーが認証された後、リソースが元のリソースと同等またはそれ次の信頼レベルである場合に同じアプリケーション・ドメインまたは異なるアプリケーション・ドメインの他のリソースでユーザーが自動的に認証されます。

関連項目: 「マルチレベル認証およびステップアップ認証について」。

デフォルト

「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックス。

チャレンジ・メソッド

リストの選択可能な項目からチャレンジ・メソッドを1つ選択する必要があります。

  • フォーム

  • Basic (LDAP)

  • X509(証明書)

  • WNA(Windows固有の認証)

  • なし

  • DAP

関連項目: 「資格証明チャレンジ・メソッド」

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

このURLは、資格証明コレクタ(ECCまたはDCC)を参照するエンド・ポイントを宣言します。たとえば:

ECC: /oam/server

DCC: http://<dcc-host:port>/

関連項目:

認証モジュール

ユーザーに資格証明を要求するために使用する事前構成済認証モジュールを指定します。ここで指定されたモジュールまたはプラグインによって、使用する正確なユーザー・アイデンティティ・ストアが指定されます。

  • 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対応のOAM Webゲートと認証ポリシーの構成」を参照してください。

チャレンジ・パラメータ

サポートされているチャレンジ・パラメータの詳細は、「認証スキームのチャレンジ・パラメータ」を参照してください。

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

  • カスタム・ログイン・ページには、2つのフォーム・フィールド(ユーザー名およびパスワード)が必要です。Access Managerはカスタム・フォームをサポートしています(『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 Access Managementでのアプリケーションの開発』を参照してください。

22.9.1.1 事前構成済の認証スキーム

BasicFASchemeやKerberosSchemeなどの事前構成済の認証スキームは、Access Managerで使用できます。

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

表22-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
  • チャレンジ・メソッド: FORM
  • 認証モジュール: LDAP
  • コンテキスト: customWar
  • コンテキスト値: /fusion_apps

この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。

http://www.oracle.com/technetwork

FederationMTScheme

Oracle Fusion Applicationsのみ

  • 認証レベル: 2
  • チャレンジ・メソッド: FORM
  • 認証モジュール: 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
  • チャレンジ・メソッド: FORM
  • 認証モジュール: FederationPlugin
  • コンテキスト・タイプ: customWar
  • コンテキスト値: /oam
  • チャレンジ・パラメータ: initial_command=NONE
  • is_rsa=true

関連項目: 「Oracle Access Management Identity Federationの管理」。

KerberosScheme
  • 認証レベル: 2
  • チャレンジ・メソッド: WNA
  • 認証モジュール: Kerberos
  • コンテキスト・タイプ: customWar
  • コンテキスト値: /fusion_apps

Active DirectoryのWindows固有の認証チャレンジ・メソッドおよび有効なWNA資格証明に基づいて、ほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。

LDAPNoPasswordValidationScheme
  • 認証レベル: 2
  • チャレンジ・メソッド: FORM
  • 認証モジュール: LDAPNoPasswordAuthModule
  • コンテキスト・タイプ: デフォルト
  • コンテキスト値: /oam

ノート: LDAPNoPasswordAuthModuleは、DAP(アサータ)メカニズムに似ています。

フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。

WebLogicコンテナのリソースを使用している場合にSSOのアイデンティティ・アサータとともに使用されます。『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

LDAPScheme
  • 認証レベル: 2
  • チャレンジ・メソッド: FORM
  • 認証モジュール: LDAP
  • コンテキスト・タイプ: customWar
  • コンテキスト値: /fusion_apps

フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。
     
     
 

Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスの「enableCoexistMode」および「disableCoexistMode」

  

OAMAdminConsoleScheme
  • 認証レベル: 2
  • チャレンジ・メソッド: FORM
  • 認証モジュール: LDAP
  • コンテキスト・タイプ: デフォルト
  • コンテキスト値: /oam

Oracle Access Managementコンソールの認証スキーム。

     

OIFScheme

Oracle Identity Federation 11.1.1のみ

Identity Federation 11.1.2の場合はFederationSchemeを使用します。
  • 認証レベル: 2
  • チャレンジ・メソッド: DAP
  • 認証モジュール: DAP
  • コンテキスト・タイプ: 外部

このスキームは、認証をOIFに委任し、その後、Oracle Identity FederationがOAMサーバーによってアサートされているトークンを送信します。

委任認証プロトコル(DAP)チャレンジ・メソッドを使用して、認証をサード・パーティ(この場合はOIF)に委任します。

チャレンジ・パラメータ: TAPPartnerId=OIFDAPPartner

関連項目: 「認証スキームのチャレンジ・パラメータ」。

     

PasswordPolicyValidationScheme
  • 認証レベル: 2
  • チャレンジ・メソッド: FORM
  • 認証モジュール: パスワード・ポリシー検証モジュール
  • Context: External

パスワード・ポリシー評価を有効にします。

TAPResponseOnlyScheme
  • 認証レベル: 2
  • チャレンジ・メソッド: DAP
  • 認証モジュール: DAP

   

  1. IAM Suiteアプリケーション・ドメインの「Protected Higher Level Policy」から、IAMSuiteAgent:/oamTAPAuthenticateを削除します。

  2. IAM Suiteアプリケーション・ドメインで、LDAPSchemeを使用する新しい認証ポリシーを作成します。

  3. 新規作成したポリシーを使用して、IAMSuiteAgent:/oamTAPAuthenticateを保護します。

チャレンジ・パラメータ: TAPPartnerId=TAPPartnerName

X509Scheme
  • 認証レベル: 5
  • チャレンジ・メソッド: X509
  • 認証モジュール: X509

この認証スキームは、証明書ベースのユーザー識別方法です。この方法を使用するには、ユーザーのブラウザに証明書をインストールし、WebサーバーをSSL対応にする必要があります。

ノート: このスキームは、SSLに依存して、ユーザーのX.509証明書をOAMサーバーに送ります。

22.9.1.2 資格証明チャレンジ・メソッド

認証には、リソースへのアクセスのリクエスト、HTTPを介した資格証明の収集および資格証明の検証結果に基づくHTTPレスポンスの応答の実行時にユーザーが指定する必要がある資格証明の決定が含まれます。

Access Managerは、認証スキームに使用する次の資格証明チャレンジ・メソッドを提供します。

FORM

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

「送信」ボタンを使用して、フォームのコンテンツを転送します。ユーザーが「送信」ボタンをクリックすると、フォーム・データがWebサーバーに転送されます。フォームで収集されたユーザー資格証明の検証時に、ユーザーが認証されます。

ノート:

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

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

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

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

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

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

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

BASIC

この組込みのWebサーバー・チャレンジ・メカニズムは、ユーザーにログインIDおよびパスワードの入力を要求します。提供された資格証明は、LDAPディレクトリ・サーバーのユーザー定義と比較されます。したがって、Basicチャレンジは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに依存します。

ノート:

URLがAccess ManagerによってBasic認証を使用して保護されており、OIDがアイデンティティ・ストアとして構成されている場合は、OIDで定義されたユーザーはログインできません。これを解決するには、次に示す行を、config.xmlファイルの中の終了</security-configuration>タグの前に追加します。 

<enforce-valid-basic-auth-credentials>false
   </enforce-valid-basic-auth-credentials>

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認証モジュールに基づいています。

関連項目:

Windowsネイティブ認証との統合の詳細は、「Windowsネイティブ認証のためのAccess Managerの構成」を参照してください。

NONE

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

DAP

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

DAPModuleはアサーション・モジュールですが、このアプリケーション専用であり、Oracle Access Managementコンソールの認証モジュールのリストには表示されません。

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側に格納します。

22.9.1.3 認証スキームのチャレンジ・パラメータ

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

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

<parmatername>=<value>

この構文はWebゲート・リリースに固有のものではありません。認証スキームは、Webgateのリリースから独立しています。

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

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

事前構成済スキーム チャレンジ・パラメータ

BasicSessionlessScheme

CookieLessMode=true

主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。

FederationMTScheme
  • initial_command=NONE

主に、複数要因認証をサポートするFusion Applicationsに使用されます。

  • is_rsa=true

RSAマルチステップ認証で使用されます。「RSA SecurID認証とAccess Managerとの統合」および『Oracle Access Managementでのアプリケーションの開発』の「プロセス概要: マルチステップ認証」を参照してください。

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をサポートしないクライアントに使用されます。
   

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

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

表22-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)でのみサポートされます。

次の11gの例では、usernameとpasswordは、ログイン・フォームの該当するフィールドの名前です。

creds=username password

ノート: このチャレンジ・パラメータのフォーマットは10gリリースより変更されています。

Webサーバーのソース(サーバー・パラメータ)は、他のソースより優先されます。これにより、ユーザーが設定するリクエスト・データがWebサーバーのデータをオーバーライドすることが防止されます。たとえば、ユーザーから送信されたremote_user Cookieは、Webサーバーによって設定されたremote_user変数をオーバーライドしません。

一般に、フォームベースのチャレンジ・メソッドを使用する認証スキームで保護されているログイン・フォームをユーザーが送信すると、DCCは、このcreds=パラメータで指定された資格証明を処理します。

METHOD=POST処理を使用するフォームの場合、リクエストの本体にフォームからの資格証明データを付けてブラウザがPOSTリクエストをWebサーバーに送信します。フォームでMETHOD=GETが使用されている場合は、credsパラメータに指定されたものと同じ名前を持つ問合せ文字列パラメータを付けてブラウザがGETリクエストを送信します。可能な場合はPOSTプロセスを使用することをお薦めします。

ノート: credsパラメータは、他のタイプのチャレンジ・メソッドにも指定できます。プラグインでcredsパラメータを使用する場合、『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の構成」

ChallengeRedirectMethod

埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対する認証POSTデータ保持パラメータ。

値: GET|POST|DYNAMIC

ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作はDynamicです。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

MaxPreservedPostDataBytes

認証POSTデータの保持に対してこの認証スキーム・チャレンジ・パラメータ(またはユーザー定義Webgateパラメータ)を構成します。

デフォルト: 8192バイト

ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作は8192バイトです。

このパラメータは、Webgateが保持できるPOSTデータの最大長を定義します。インバウンド・ロー・ユーザーPOSTデータ(または処理後に暗号化されるPOSTデータ)がこの制限を超えた場合、POSTデータは削除され、既存の認証フローが続行されます。イベントは通常どおり記録されます。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

MaxPostDataBytes=

DCCのみ

この認証スキーム・チャレンジ・パラメータを構成して、ユーザーの資格証明として送信され、OAMサーバーに転送されるPOSTデータの最大バイト数を制限します。

このチャレンジ・パラメータは、DCCによるPOSTデータ保持に対してのみ構成します。そして、フォーム上の資格証明としてポストして、OAMサーバーに送信できるPOSTデータの最大バイト数を制限します。DCCは、Content-Lengthヘッダーの値と、設定されている制限値とを比較します。

デフォルト: 8192バイト

このチャレンジ・パラメータは、正の整数値を必要とします。

関連項目:

表15-2

「PasswordPolicyValidationSchemeの構成」

「認証POSTデータ・ハンドリングの構成」

ssoCookie=

OAMAuthnCookie Cookieを制御します(「暗号化Cookieのチャレンジ・パラメータの構成」を参照)。

デフォルト:

ssoCookie=httponly

ssoCookie=Secure

どちらかの設定を無効にします。

ssoCookie=disablehttponly

ssoCookie=disableSecure

ノート: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

  • 外部資格証明コレクタが有効化されたOAM Webゲートの場合、これらのパラメータはエージェント登録ページで直接設定します。

  • DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは認証スキーム内のユーザー定義チャレンジ・パラメータを通じて構成します。

関連項目:

表22-29

miscCookies=

その他の各種のAccess Manager内部Cookiesを制御します。デフォルトでは、httponlyは、その他の(各種の)すべてのCookiesに対して有効化されています。

デフォルト:

miscCookies=httponly

miscCookies=Secure

どちらかの設定を無効にします。

miscCookies=disablehttponly

miscCookies=disableSecure

ノート: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

  • 外部資格証明コレクタが有効化されたWebgateの場合、これらのパラメータはエージェント登録ページで直接設定します。

  • DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは同じ名前のチャレンジ・パラメータを通じて構成します。

関連項目:

表22-29

「PasswordPolicyValidationSchemeの構成」

DCCCtxCookieMaxLength=

DCCのみ

DCC Cookieの最大長を定義します。

デフォルト: 4096

関連項目: 詳細は、この表のTempStateModeを参照してください。

TempStateMode=

次に示すパラメータの値(cookieまたはform)での指定に応じて、DCCがOAMサーバーの状態を格納する方法を制御します。

  • form: デフォルト値。認証POSTデータを保持する場合は、この値である必要があります。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を使用します(『WebLogic Server WLSTコマンド・リファレンス』を参照)。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では、フォームベース認証スキームによるPOSTデータのリストアには、チャレンジ・パラメータTempStateMode=formが必要です。

関連項目:

allowedAccessGateList=

このスキームにより認証の強制が許可されるWebゲートを定義する、スペースで区切られたWebゲートIDのリストで構成された認証スキームのチャレンジ・パラメータ。たとえば:

allowedAccessGateList=WebgateID1 WebgateID2

TunneledUrls

  • OAMの場合: TunneledUrls=/oam

  • OIFの場合: TunneledUrls=/oamfed

  • OIGの場合: TunneledUrls=/oam

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

この項では次のトピックを記載しています:

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

各認証スキームに強度レベルが必要になります。数字が大きいほど、認証メカニズムのセキュリティが高く、数字が小さいほど、スキームの強度は低くなります。

たとえば:

  • LDAPScheme authLevel=1

  • KerbScheme authLevel=3

ノート:

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

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

ノート:

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

Access Managerポリシーでは、同じアプリケーションの複数のリソースを複数の認証レベルで保護できます。

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

22.9.2.2 認証プロセス時における認証スキームのセキュリティ・レベルの変更

認証プロセス時に認証スキームのセキュリティ・レベルを変更するカスタム・プラグインを作成できます。

特定の条件に基づいて認証プロセス時に認証スキームのセキュリティ・レベルを上げることが必要となる場合があります。認証スキームのセキュリティ・レベルを、ユーザーのログイン元のアプリケーションによって変更する場合などです。たとえば、Active Directoryおよびリバース・プロキシはユーザーのログイン元として使用可能なソースです。認証プロセス時に、Active Directoryからログインするユーザーにはある認証セキュリティ・レベルが使用されるように、リバース・プロキシからログインするユーザーには別のセキュリティ・レベルが使用されるように動的に設定できます。

カスタム認証プラグインを使用すると、認証レベルをプラグイン・レスポンスとして設定できます。構成可能な認証レベルがプラグイン・ステップ・パラメータとしてプラグイン・レスポンスに設定される新しいカスタム認証プラグインを作成します。たとえば、PLUGIN_AUTHN_LEVELをプラグイン・レスポンスで構成します。これにより、使用している認証メカニズムに基づいて動的に認証レベルを設定できます。

カスタム・プラグインによってもたらされるセキュリティへの影響を回避するには、オプションの認証スキーム・チャレンジ・パラメータMAX_AUTHN_LEVELを使用します。MAX_AUTHN_LEVELの値は、リソースを保護するカスタム認証プラグインで設定できる最大認証レベルです。カスタム認証スキームでは、このパラメータはデフォルトで無効になっています。認証プロセス時にプラグインによって認証レベルの値が動的に変更されるようにするには、PLUGIN_AUTHN_LEVELよりも高い値でこの必須パラメータを設定する必要があります。

カスタム認証プラグインを作成し、MAX_AUTHN_LEVELより低い値でKEY_AUTHN_LEVELを構成します。新しい認証プラグインを使用するカスタム認証モジュールを作成し、カスタム認証スキームに関連付けます。リソースを保護する認証ポリシーにそのスキームを指定します。ユーザー・セッションが作成されると、管理者が設定した最大認証値をオーバーライドするプラグインに関する警告メッセージがOAMサーバーによって記録されます。MAX_AUTHN_LEVELが構成されていない場合やプラグインによってMAX_AUTHN_LEVELよりも大きい値が設定される場合は、認証レベルが認証スキームに設定されて認証が成功します。

認証レベルをプラグイン・レスポンスとして設定するサンプル・コードを次に示します。

String stepName = context.getStringAttribute(PluginConstants.KEY_STEP_NAME);
String pluginLevel = PlugInUtil.getFlowParam(stepName, " PLUGIN_AUTH_LEVEL ", context);
PluginResponse rsp = new PluginResponse();
rsp.setName(PluginConstants.KEY_AUTHN_LEVEL);
rsp.setType(PluginAttributeContextType.LITERAL);
rsp.setValue(pluginLevel);
context.addResponse(rsp);

22.9.3 認証スキームの作成

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

前提条件

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

関連項目:

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。

  2. 「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「認証スキーム」をクリックします。

  3. 「認証スキームの作成」をクリックします。

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

    1. 名前: LDAPSimpleFormScheme

    2. 認証レベル

    3. チャレンジ・メソッド: FORM

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

    5. 認証モジュール: LDAP

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

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

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

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

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

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

  8. スキームのリストに新しいスキームが表示されていることを確認します(必要な場合はリフレッシュします)。

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

22.9.4 認証スキームの検索

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

関連項目:

「SSOエージェントの検索ページ」

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
  2. 「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「認証スキーム」をクリックします。
  3. 「名前」フィールドに、(必要に応じてワイルド・カード(*)を使用して)ターゲット・スキーム名を入力します。たとえば: 
    OA*
  4. 「検索」ボタンをクリックして検索を開始します。
  5. 「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。

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

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

    • デタッチ: ツール・バーの「デタッチ」をクリックして、表をページ全体にまで拡大します。

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

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

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

ノート:

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

関連項目:

  1. 前の項の説明に従って、ターゲット・スキームを検索します。

  2. 検索結果のリストで、ターゲット・スキームを選択し、「編集」をクリックします。

  3. 編集:

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

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

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

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

  5. 削除:

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

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

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

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

22.10 拡張ルールによる認証スキームの拡張

拡張ルールが追加され、既存の認証ポリシーを拡張できるようになりました。

次の構成は認証後ルールではサポートされていませんが、認証前ルールと認証後ルールの両方を適用できます。

  • 2つ以上のリソースが同じOHS/Webゲートによりフロントエンドされ、同じ認証スキームにより保護されている。

  • 1つの認証後ルールが、ステップアップ認証で定義されたリソースの1つに対して構成されている。

  • ユーザーが、認証後ルールが構成されていないリソースにアクセスした後で、ステップアップ認証用に認証後ルールが構成されているリソースにアクセスする。この場合、そのリソースに構成されている認証後ルールは無効になります。

ノート:

拡張ルールは、ライセンスが必要なアダプティブ認証サービスの一部です。「アダプティブ認証サービスについて」を参照してください。

拡張ルールには、ブール式が含まれています。トリガーされた認証スキーム結果が複数存在する場合は、実行順序が最も早い結果が最終的な結果として選択されます。表22-23は、拡張ルールの作成時に定義する必要のある属性をまとめたものです。

表22-23 拡張ルールの属性

名前 説明

名前

認証ルール名。名前はチェックポイント内で一意であることが必要です。

説明

ルールの説明

実行順

結果が複数ある場合の結果の実行順序

Condition

スクリプト。ユーザーはHTTPリクエスト・ヘッダーの可用性に基づいて条件を構成し、目的の結果を設定できます。

Outcome
ルールが適用される認証スキームのID。Access / Deny.

ノート:

「アクセスの拒否」オプションが選択されている場合は、リクエストされたURLが見つかりませんでしたというエラー・メッセージが表示されます。

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

22.10.1 拡張ルールのユースケース

特定のシナリオに対して拡張ルールを構成できます。

次のユースケースの場合、拡張ルールを構成します。

  • 非ブラウザ・クライアント - ユーザー認証では、ユーザーが入力するためのフォームベースのログイン・ページがブラウザを介して表示されます。非ブラウザ・クライアント(スイッチ、ルーターなど)が、リクエスト・ヘッダーを介して渡された資格証明に基づいてBasic認証を行うことが必要な場合もあります。非ブラウザ・クライアント認証は、認証前拡張ルールとしてのみ構成できます。非ブラウザ・クライアント認証をサポートするには、目的の条件を(HTTPリクエスト・ヘッダーの可用性に基づいて)認証ルール内で構成し、目的の結果を設定します。

  • Windowsネイティブ認証オプション - ユーザーがVPNと企業ネットワークのどちらを使用しているかに応じてWindowsネイティブ認証(WNA)とフォームベース・ユーザー認証を切り替えできるように、拡張ルールを構成できます。

  • ユーザー認証スキーム・オプション - ユーザーが認証方式を選択できるように拡張ルールを構成できます。選択した内容はリクエスト・パラメータとして渡されます。

  • 第2ファクタ認証 - 定義されたユーザーまたはリクエスト属性に基づいて第2ファクタ認証を許可するように、拡張ルールを構成できます。SFAの詳細は、「アダプティブ認証サービスの概要」を参照してください。

表22-24に、これらの拡張ルール・ユースケースで条件を構成する方法の例を示します。

表22-24 拡張ルールのサンプル

Sample Rule Jythonスクリプト・ベースの条件のサンプル ノート

プライベートまたはパブリックのIPルールに基づいて認証スキームを切り替える

location.clientIP.startswith('10.')またはlocation.clientIP.startswith('172.16')またはlocation.clientIP.startswith('192.168')

このルールは、認証前および認証後のチェックポイントで使用できます。

ブラック・リストIP

['130.35.50.115', '130.35.50.112', '130.35.50.113']のlocation.clientIP

このルールは、認証前および認証後のチェックポイントで使用できます。

クライアント・ブラウザ・タイプ

request.userAgent.lower().find('firefox') > 0

このルールは、認証前および認証後のチェックポイントで使用できます。

ユーザー属性'description'が'test'のユーザーへのアクセスをブロック

user.userMap['description'] == 'test'

このルールを使用できるのは、認証後チェックポイントのみです。

非ブラウザ・クライアント

request.authorization.lower().startswith('basic')

このルールを使用できるのは、認証前チェックポイントのみです。

カスタムHTTPヘッダー値

request.requestMap['param'] == 'test'

このルールは、認証前および認証後のチェックポイントで使用できます。

範囲内のIPアドレスに基づいて認証スキームを切り替える

location.isIPinRange('192.35.50.180','192.35.50.188')

このルールは、認証前および認証後のチェックポイントで使用できます。

22.10.2 拡張ルールのコンテキスト・データ

Access Managerサーバーは、認証条件を実行する前に、(条件に基づいてブール式を作成するために)使用可能なデータを使用してリクエスト・コンテキストを用意します。

次の表では、様々なコンテキスト・データの詳細について説明します。

表22-25 リクエスト・コンテキスト・データ

属性名 説明

requestMap

すべてのリクエスト・ヘッダー、パラメータおよびPOSTデータ値のマップ。この例では、カスタム・ヘッダー・キーをリクエスト・ヘッダーから取得して値'test'と比較できます。

request.requestMap['custom-header'].lower().find('test') > 0

resourceMap

一致するリソースの詳細のマップ

accept

'Accept'ヘッダー値を返します。

acceptCharset

'Accept-Charset'ヘッダー値を返します。

acceptEncoding

'Accept-Encoding'ヘッダー値を返します。

acceptLanguage

'Accept-Language'ヘッダー値を返します。

認可

'Authorization'ヘッダー値を返します。

connection

'Connection'ヘッダー値を返します。

contentLength

'ContentLength'ヘッダー値を返します。

cookie

'Cookie'ヘッダー値を返します。

host

'Host'ヘッダー値を返します。

ifModifiedSince

'ifModifiedSince'ヘッダー値を返します。

pragma

'Pragma'ヘッダー値を返します。

referer

'Referer'ヘッダー値を返します。

userAgent

'UserAgent'ヘッダー値を返します。

resourceHost

一致したリソースのHost値を返します。

resourcePost

一致したリソースのPort値を返します。

resourceOperation

一致したリソースのOperation値を返します。

resourceQueryString

一致したリソースのQueryStringを返します。

resourceName

一致したリソースの名前を返します。

resourceType

一致したリソースのタイプを返します。

resourceURL

一致したリソースのURLを返します。たとえば、’landingPage’がrequest.resourceURLの中にある場合、resourceURLの中にlandingPageがあると、条件はtrueに評価されます。

isIPinRange('start IP' ,'end IP')

location.clientIPが指定された範囲内にある場合、trueに評価されます。例: 

location.isIPinRange('192.35.50.180','192.35.50.188')

表22-26 ロケーション・コンテキスト・データ

属性名 説明

locationMap

すべてのロケーション・データ値のマップ。たとえば:

location.locationMap['CLIENT_IP'] == '10.1.23.4'

clientIP

クライアントIPアドレスを返します。たとえば:

location.clientIP.startswith('10.2')

proxyIP

プロキシIPアドレスを返します。

表22-27 セッション・コンテキスト・データ

属性名 説明

sessionMap

すべてのセッション・データ値のマップ。たとえば:

session.sessionMap['count'] > 2;

count

現在のユーザーのセッション数を返します。たとえば: session.count > 2

表22-28 ユーザー・コンテキスト・データ

属性名 説明

userMap

すべてのユーザー・プロファイル・データのマップ。たとえば: user.userMap['email'] == 'john.joe@example.com'

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

OAMが提供するチャレンジ・パラメータは、暗号化Cookieのフラグを制御するために任意の認証スキーム内で使用できます。

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

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

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

    ノート: 有効なOAMAuthnCookieがセッションに必要です。

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

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

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

ノート:

チャレンジ・パラメータの値は、大文字/小文字が区別されません。どのリリースのWebゲートでも、構文は同じです。単一の値は、等号(=)の後ろに指定します。

ssoCookie=value

複数の値は、セミコロン(;)で区切る必要があります。たとえば:

ssoCookie=value1;value2;...

  • 外部資格証明コレクタが有効化されたWebgateの場合、これらのパラメータはエージェント登録ページ(表15-2)で直接設定します。

  • DCC以外のエージェント(リソースWebgate)の場合、これらのパラメータは認証スキームのチャレンジ・パラメータ(表22-29)を通じて構成します。

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

表22-29 11g暗号化Cookieのチャレンジ・パラメータ

暗号化CookieのOAM Webゲート・チャレンジ・パラメータの構文 説明 
ssoCookie=

SSO CookieのOAMAuthnCookieのフラグを制御するパラメータです。

 
miscCookies=

その他すべてのAccess Manager暗号化Cookieのフラグを制御するパラメータです。

 
       Secure

HTTPSによってリソースにアクセスした場合のみ、暗号化Cookieが送信されるようにします。ブラウザがHTTPSを使用してサーバーにアクセスする場合のみ、セキュアなCookieが必要です。

ssoCookie=Secure
miscCookies=Secure

disableSecure

セキュアCookieを明示的に無効にします。

ssoCookie=disableSecure
miscCookies=disableSecure
 
       httponly

OAM Webゲート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

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

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

関連項目:

「認証スキームの作成」

  1. 認証スキームを作成します。
  2. 「チャレンジ・パラメータ」フィールドで、目的の暗号化Cookie(表22-29)の指定内容を入力します。
  3. 「通信の保護」の説明に従って、OAMサーバーとクライアント(OAMエージェント)が、Oracle Accessプロトコル・チャネルを介して安全に通信していることを確認します。

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

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

関連項目:

「認証スキームの作成」

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

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

22.12 認証POSTデータ・ハンドリングの構成

POSTデータの保持/リストア機能は、両方の資格証明コレクタ(ECCまたはDCC)に適用されます。

この項では次のトピックを記載しています:

22.12.1 認証POSTデータの保持とリストア

POSTデータの保持/リストア機能は、アプリケーションに、ユーザーが資格証明(または他のデータ)を入力しているフォームがあり、ユーザーがフォームを送信したときには、セッションの有効期限が切れたり、アイドル・セッション・タイムアウトが発生したり、トークンの有効期限が切れてしまった場合に、効力を発揮する機能です。このような場合、POSTデータの保持/リストアが行われなければ、ユーザーには新しいログイン・フォーム(認証スキームによります)が表示されます。

管理者は、有効期限切れになったユーザーと新しく認証されるユーザーが同じ場合にPOSTデータを保持するようにリソースWebgateを構成できます。表22-30に、POSTデータに対するリソースWebgateのサポートと動作を示します。

ノート:

Access Managerがカスタム・エージェントを使用して認証を行う場合は、認証POSTデータの保持/リストアはサポートされません。

表22-30 POSTデータの保持/リストアに対するリソースWebgateのサポート

リソースWebゲート 説明

認証スキームのサポート

LDAP、Basic、Sessionless Basic、X509、WNA

フォーム・エンコーディングのサポート

アプリケーション・フォームからポストされるtext/html、text/plain、multipart/form-dataおよびapplication/x-www-form-urlencodedタイプのデータ。

保持

ファイル・タイプの入力フィールドを除く、元のアプリケーション・フォームからポストされたデータのエンコーディング・タイプ。

保証

ダウンストリーム・アプリケーションは、元のアプリケーション・フォームからポストされた同じPOSTデータを取得します。

制約

インバウンド・リクエスト・データまたはインバウンド・フロント・チャネル・メッセージの全体サイズ。コード・デフォルト値をオーバーライドする構成パラメータを設定する必要があります。このパラメータは、アプリケーション単位になります。

アプリケーション・データの機密性と整合性の維持

リソースWebgateも資格証明コレクタも、アプリケーションPOSTデータの解釈または記録は行いません。

有効期限後、および再認証中、ユーザーが別の資格証明で認証を行った場合、前回のユーザーのPOSTデータはリソースWebgateによってクリアされ、リストアされません。ただし、元のアプリケーション・フォームからポストされていたダウンストリーム・アプリケーションURLへのポストは行われます。

保持が無視される場合...

メッセージが記録される場合...

標準認証が実行される場合...

エラーが表示される場合...

POSTデータが構成済またはハードコーディングされた制限値より大きい場合、保持は無視されます。

POSTデータが許可された制限値より大きいためにスキップされた場合、メッセージが記録されます。

POSTデータがハードコーディングされた制限値(または構成された値)より大きい場合、標準承認フローが使用されます。

フロント・チャネル・メッセージ・データとアプリケーションPOSTデータの両方が大きい場合、エラーが発生します。

POSTデータ・ハンドリングに対する資格証明コレクタのサポート

  • ECCとDCC

  • 旧11g Webgateと互換性あり

  • 即時使用可能なデフォルト・ログイン・フォーム付きフォームベース認証スキーム用のPOSTデータの保持をサポートします。

  • 次の方法により、認証中、アプリケーションPOSTデータが保持されます。

    • ユーザーの本人確認

    • 資格証明が無効であったため発生したユーザーの本人再確認

    アプリケーションPOSTデータの解釈は行われません。

  • アプリケーション単位で、デフォルト値をオーバーライドする構成パラメータを使用して、インバウンド・フロント・チャネル・メッセージの全体サイズを制御します。

  • POSTデータが許可される制限値より大きいためにスキップされた場合、警告が記録されます。

  • 次の場合、アプリケーションPOSTデータの保持は行われません。

    • 認証ポリシーが成功/失敗認証URLで構成されている

    • パスワード管理(パスワードの有効期限など)が含まれている

    • Access Managerがカスタム・エージェント経由の認証用に使用されている

  • ECCのみ

    • 埋込み資格証明コレクタは、外部ログイン・ページによるPOSTデータ・ハンドリングをサポートしません。

  • DCCのみ

    • POSTデータはHTTPヘッダー経由で保持され、処理できるPOSTデータ・サイズは8192文字です。

    • フォームベース認証スキームによるPOSTデータのリストアには、チャレンジ・パラメータTempStateMode=formが必要です。

    • DCCはカスタム・ログイン・ページをサポートしません。

    • DCCは、パスワード管理操作中(パスワードの有効期限管理など)、パスワード・ポリシー・プラグイン内のURL_ACTIONがFORWARD以外の値に設定されている場合、POSTデータのリストアをサポートしません。

22.12.2 認証POSTデータ・ハンドリング

WNA、Basic、X509などの認証スキームでは、POSTデータ・ハンドリングをサポートしています。

次に、POSTデータ・ハンドリングをサポートする認証スキームを示します。

  • FORMチャレンジ・メソッド(即時使用可能ログイン・ページでサポート)

  • WNA

  • Basic

  • Basic+Sessionless

  • X509

  • OIF

表22-31に、認証POSTデータ・ハンドリングの完全構成要件の概要を示します。表22-31で示すすべての要件は、指定された認証スキームで、エンドツーエンドでサポートされます。

表22-31 認証POSTデータ・ハンドリングに必要なパラメータ

パラメータ 説明

MaxPostDataBytes

この認証スキーム・チャレンジ・パラメータは、DCCによるPOSTデータ保持に対してのみ構成します。ログイン・フォームからポストできるPOSTデータの最大サイズを制限します。DCCは、Content-Lengthヘッダーの値と、設定されている制限値とを比較します。

デフォルト: unlimited

この認証スキーム・チャレンジ・パラメータは、ユーザーの資格証明として送信され、OAMサーバーに転送されるPOSTデータの最大バイト数を制限する正の整数値を必要とします。

MaxPreservedPostDataBytes

認証POSTデータの保持に対してこの認証スキーム・チャレンジ・パラメータ(またはユーザー定義Webgateパラメータ)を構成します。

デフォルト: 8192バイト

ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作は8192バイトです。

このパラメータは、Webgateが保持できるPOSTデータの最大長を定義します。インバウンド・ロー・ユーザーPOSTデータ(または処理後に暗号化されるPOSTデータ)がこの制限を超えた場合、POSTデータは削除され、既存の認証フローが続行されます。イベントは通常どおり記録されます。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

TempStateMode=form

DCCのみ

DCCでのフォームベース認証スキーム用のPOSTデータ・リストアには、チャレンジ・パラメータTempStateMode=formが必要です。フォーム認証スキームに対して、このパラメータが定義されていない場合、値はformになります。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

ChallengeRedirectMaxMessageBytes

obrareq.cgiおよびobrar.cgiとして受信するメッセージ・データのサイズを制限するためにこのユーザー定義Webgateパラメータを構成します。メッセージ・データは、問合せ文字列長(存在する場合)で構成されます。また、POSTデータが存在する場合は、POSTデータ長で構成されます。メッセージ長がこの制限を超える場合、メッセージは処理されることなく、ブラウザには既存メッセージが表示されます。イベントは通常どおり記録されます。

デフォルト: 8192バイト

ノート:

obrareq.cgiは、Webgateから資格証明コレクタ(OAMサーバーまたはDCC)にリダイレクトされる問合せ文字列の形式での認証リクエストです。

obrar.cgiは、資格証明コレクタ(OAMサーバーまたはDCC)からWebgateにリダイレクトされる認証レスポンス文字列です。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

PostDataRestoration

このユーザー定義Webgateパラメータは、リソースWebgateに対する認証POSTデータの保持を開始するために構成します。このパラメータは、trueまたはfalseの値を必要とします。

デフォルト: false

trueに設定すると、WebgateはPOSTデータの保持を開始します。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

serverRequestCacheType

ECCのみ

このOAMパラメータは、埋込み資格証明コレクタ(ECC)によってリクエスト・コンテキストを記録するために使用されるメカニズムを定義します。

$DOMAIN_HOME/config/fmwconfig/oam-config.xml内のこのOAMサーバー・パラメータは、リクエスト・コンテキストを記憶するために使用されるメカニズムを示します。可能な値は、FORM、COOKIEまたはCACHEです。

デフォルト: COOKIE

POSTデータの保持、長いURLの処理およびフォームベース認証スキームでは、FORMであることが必要です。

関連項目: この表内のTempStateMode

「認証POSTデータ・ハンドリングの構成」

22.12.3 POSTデータ・サイズの制限

ユーザーが入力する通常のフォーム・データは数キロバイトであることが前提になっているので、着信リクエストから発生するデータ消費に制限を設けることは一般的な要件になります。フロント・チャネル・プロトコルで転送されるデータも(リクエスト、レスポンスともに)、サイズ・チェックを受けることが必要です。

次のような状況があります。

  • MaxPostDataBytes認証チャレンジ・パラメータを使用して、バック・チャネル上のOAMサーバーに渡されるデータのサイズを制限します。

    DCCが使用されている場合、MaxPostDataBytes認証チャレンジ・パラメータはPOSTデータ全体に対してこのチェックを実行します。

  • MaxPreservedPostDataBytes認証スキーム・チャレンジ・パラメータを使用して、エンド・ユーザー・アプリケーションからのPOSTデータのサイズを制限します。

    MaxPreservedPostDataBytes認証スキーム・チャレンジ・パラメータがこれを処理します。加えて、ユーザー定義Webgateパラメータとしてこれを設定することもできます。

  • Webgateユーザー定義パラメータChallengeRedirectMaxMessageBytesでobrar.cgiまたはobrareq.cgiのフロント・チャネル・ペイロードのサイズを制限します。

22.12.4 認証POSTデータ・ハンドリングの構成

この手順を実行する前に、この項のすべてのPOSTデータについてのトピックに目を通しておく必要があります。認証スキームに明示的な変更を加える必要はありません。

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

    1. Oracle Access Managementコンソールを使用して、目的のスキームを作成するか見つけます(認証POSTデータ・ハンドリング)。

    2. 「認証スキーム」ページで、POSTデータ・ハンドリングの値を変更します。

      この例では、埋込み資格証明コレクタ(表22-19)とPOSTデータ・ハンドリングに対する値(表22-22)を使用します。

      • 名前: DesiredScheme
      • 認証レベル 2
      • チャレンジ・メソッド: フォーム
      • チャレンジ・リダイレクトURL: /oam/server/
      • 認証モジュール: LDAP
      • チャレンジURL: /pages/login.jsp
      • コンテキスト・タイプ: 外部
      • チャレンジ・パラメータ
      ECCでのPOSTデータに対する認証スキーム・チャレンジ・パラメータ DCCでのPOSTデータに対する認証スキーム・チャレンジ・パラメータ
      • MaxPreservedPostDataBytes=9000
      • MaxPreservedPostDataBytes=9000
      • TempStateMode=form

    3. 「適用」をクリックして変更を送信します。

  2. ECC: ECCを使用する場合は、serverRequestCacheType (oam-config.xml内のOAMパラメータ)を構成します。

    1. 管理対象サーバーを停止します。

    2. 管理サーバーを停止します。

    3. oam-config.xmlを開いて、serverRequestCacheType値を変更します。

      「OAM構成の更新」を参照してください。

    4. 管理サーバーを再起動します。

    5. 管理対象サーバーを再起動します。

  3. POSTデータ・ハンドリング用のWebgateパラメータを構成します。

    1. 「システム構成」タブの「Access Manager」セクションで、目的のOAMエージェント登録を作成するか、見つけます。

    2. エージェント登録ページで、POSTデータ・ハンドリングの値を送信します(表22-22)。

      • 名前: DesiredAgent
      • ユーザー定義パラメータ
      ECCでのユーザー定義Webgate POSTデータ・パラメータ DCCでのユーザー定義Webgate POSTデータ・パラメータ
      • PostDataRestoration=true
      • PostDataRestoration=true

    3. 「適用」をクリックして変更を送信します。

22.12.5 認証POSTデータ・ハンドリング構成のテスト

POSTデータ・ハンドリング構成をテストするには、次の一連のアクションを順番に実行します。

  1. 説明されているすべての構成を完了します。
  2. Webgateにより保護されるPOSTデータとURLを出力するシンプルなスクリプトを作成します。
  3. ブラウザを使用して保護されたリソースにアクセスします。
  4. 資格証明を提供し、SSOを構築します。アイドル・セッション・タイムアウトが発生するのを待ちます。
  5. 同じブラウザで、フォームからPOSTデータを出力できるURLを使用して同じWebgateにデータをポストします。資格証明コレクタにリダイレクトされます。
  6. 前回使用した同じ資格証明を入力します。

    HTTPヘッダーで、資格証明コレクタからobrar.cgiを取得した後に、保護されているリソースWebgateが200レスポンスを返していること(以前は302)を確認できます。また、スクリプトによりPOSTデータを出力できます。

22.13 認証時における長いURLの処理

長いURLの処理は、両方の資格証明コレクタ(ECCまたはDCC)に適用され、デフォルトの操作になります。

22.13.1 長いURLと認証処理について

認証には、ユーザーのリクエストを一元化されたコンポーネントにリダイレクトする操作が含まれます。このコンポーネント(資格証明コレクタと呼びます)が、認証を実行します。ユーザーをポリシー強制点(OAMエージェント)から資格証明コレクタにリダイレクトするメカニズムは、HTTP上のフロント・チャネル・プロトコル専用です。このプロトコルは、現時点では、リクエストのコンテキストと、問合せ文字列に対する認証レスポンスを提供します。リクエストされたページのURLが大きい場合、コンテキスト全体が大きくなり、ブラウザで許容されているサイズを超えてしまうことがあります。これに対応するのが長いURLの処理機能です。

デフォルトでは、リソースWebgateが、フロント・チャネル・プロトコル・メッセージのサイズをチェックし、コーディングされている制限値より大きくないかどうか判断します。長いURLの処理機能が明示的に有効になっている場合、この制限は無視され、影響は発生しません。

資格証明コレクタは、次の場合、フロント・チャネル・レスポンス・ペイロードをHTTP POSTデータとして送信するかどうか決定します。

  • 着信リクエストにより、エージェントがHTTP POSTまたはREDIRECTのレスポンス・タイプを処理できることが示されている。

  • 資格証明コレクタがペイロードを常にHTTP POSTデータとして送信するように構成されている。

  • 資格証明コレクタがペイロードを常に問合せ文字列として送信するように構成されている。

明示的な構成がされていない場合、そしてペイロード・サイズが事前定義済制限を超えている場合、ペイロードはHTTP POSTデータとして送信されます。ペイロード・サイズが事前定義済の制限を下回っている場合は、問合せ文字列で送信されます。

ノート:

アプリケーションPOSTデータも保持される場合、影響はありません。

表22-32に、ECCとDCC両方での長いURLの処理機能を説明します。

表22-32 ECCとDCC: 長いURLの処理

ECCでの長いURLの処理 DCCでの長いURLの処理

ECCはすべてのOAM Webゲートと互換性があります。

ECCと同じです。

N/A

長いURLの処理は、DCCContextCookieの最大許容サイズに制限されます。

DCCは、明示的な長いURLの処理には対応しません。

フォーム上のフロント・チャネル・ペイロードを保持することはできません。

22.13.2 長いURLの処理のための構成要件

次に、長いURLの処理をサポートする認証スキームを示します。

  • FORMチャレンジ・メソッド(即時使用可能ログイン・ページでサポート)

  • WNA

  • Basic

  • Basic+Sessionless

  • X509

  • OIF

表22-33に、認証時に長いURLの処理用に必要とされるパラメータと構成内容の概要を示します。表22-33で示すすべての要件は、指定された認証スキームで、エンドツーエンドでサポートされます。

表22-33 長いURLの処理に必要なパラメータ

パラメータ 説明

ChallengeRedirectMethod

これは、埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対して、POSTデータ保持のための認証スキーム・チャレンジ・パラメータ(またはユーザー定義Webgateパラメータ)として構成します。

ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作はDynamicです。

値: GET|POST|DYNAMIC

各値のときの動作:

  • POST: WebgateはPOSTデータをencqueryとして送信し、資格証明コレクタはPOSTデータをencreplyとして送信します。

  • GET: Webgateはencqueryを問合せ文字列として送信し、encreplyを問合せ文字列として待機します。

  • DYNAMIC: デフォルトの動作。encquery/encreplyの長さに基づきます。Webgate/資格証明コレクタは、データを問合せ文字列またはPOSTデータのいずれかで送信します。コード・デフォルト最大長は2000文字です。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

ChallengeRedirectMaxMessageBytes

obrareq.cgiおよびobrar.cgiとして受信するメッセージ・データのサイズを制限するためにこのユーザー定義Webgateパラメータを構成します。メッセージ・データは、問合せ文字列長(存在する場合)で構成されます。また、POSTデータが存在する場合は、POSTデータ長で構成されます。メッセージ長がこの制限を超える場合、メッセージは処理されることなく、ブラウザには既存メッセージが表示されます。イベントは通常どおり記録されます。

デフォルト: 8192バイト

ノート:

obrareq.cgiは、Webgateから資格証明コレクタ(OAMサーバーまたはDCC)にリダイレクトされる問合せ文字列の形式での認証リクエストです。

obrar.cgiは、資格証明コレクタ(OAMサーバーまたはDCC)からWebgateにリダイレクトされる認証レスポンス文字列です。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表15-2

serverRequestCacheType

ECCのみ

このOAMパラメータは、埋込み資格証明コレクタ(ECC)によってリクエスト・コンテキストを記録するために使用されるメカニズムを定義します。

このOAMサーバー・パラメータは、リクエスト・コンテキストを記憶するために使用されるメカニズムを示します。可能な値は、FORM、COOKIEまたはCACHEです。

デフォルト: COOKIE

POSTデータの保持、長いURLの処理およびフォームベース認証スキームでは、FORMであることが必要です。

関連項目: この表内のTempStateMode

「認証POSTデータ・ハンドリングの構成」

長いURLの処理機能は、デフォルトで有効になっています。Webgate/資格証明コレクタは、データを問合せ文字列またはPOSTデータのいずれかで送信します。obrareq.cgiおよびbrar.cgiとともに送信されるquerystringパラメータの長さは最大2000文字です。

22.14 アプリケーションで開始される認証の使用

機密性の高いURLや操作にユーザーがアクセスしている場合、Access Managerはアプリケーションが起動する可能性のある再認証URLを公開します。この再認証は、そのユーザーに有効なセッションがあるかどうかにかかわらずトリガーされます。

アプリケーションでは、次の/oamreauthenticate URLを呼び出して、再認証をトリガーできます。 

http://<ohs_host>:<ohs_port>/oamreauthenticate

Access Managerは、/oamreauthenticateが登録済で認証ポリシーに関連付けられているものとして動作します。再認証の実行には、このポリシーに関連付けられたスキームが使用されます。再認証URLは、問合せパラメータとしてリダイレクトURLを取ります。再認証の完了後に、Access ManagerによってユーザーがこのURLにリダイレクトされます。ユーザー再認証のリクエストは、次のようになります。

http://<host>:<port>/oamreauthenticate?
  redirect_url=http://<host>:<port>/<redirection_resource_url>

リダイレクトURLが指定されていない場合は、404エラー・コードが返されます。再認証時に指定された資格証明が正しくない場合は、ユーザーに対してログイン・ページが表示されたままになり、再試行回数の上限に達すると、ユーザーは該当するエラー・ページにリダイレクトされます。アプリケーションで開始される認証を構成する方法は次のとおりです。

  1. http://<ohs_host>:<ohs_port>/oamreauthenticateリソースを作成し、目的の認証スキームを割り当てます。
  2. リダイレクトURLの中で、再認証に成功したことを確認し、再認証のレスポンスについてアプリケーションに伝えるための適切なレスポンスを設定します。

Access Managerによって、最後の再認証日時がOAM_LAST_REAUTHENTICATION_TIMEヘッダーとして設定され、この値はユーザーが再認証されるたびに更新されます。