プライマリ・コンテンツに移動
Oracle® Fusion MiddlewareOracle Adaptive Access Manager開発者ガイド
11gリリース2 (11.1.2.3.0)
E67356-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

20 OAM 10g、Access Manager 11gおよびOAAM 11gの統合

Oracle Adaptive Access Manager (OAAM)とOracle Access Managerを統合すると、認証プロセスのファイングレイン制御とOracle Adaptive Access Managerポリシーに対する認証前および認証後チェックが可能になります。

この章では、Oracle Adaptive Access Manager 11gをOAM 10gと統合する方法について説明します。OAAMとOAM 10gの統合では、同時統合のためのAccess Manager 11gあり、またはなしのシナリオが含まれることがあります。

内容は次のとおりです。

20.1 OAAM 11gとOracle Access Manager 10gの統合

この項では、Oracle Access ManagerをOracle Adaptive Access Manager (OAAM)と統合してリスクベース認証を介してリソースを保護する手順を示します。次の項目が含まれます。

20.1.1 リソース保護フロー

この項では、Oracle Access ManagerとOAAM統合内の保護されたリソースにユーザーがアクセスを試みるときのプロセス・フローについて説明します。

  1. ユーザーがOracle Access Managerによって保護されたリソースにアクセスしようとすると、Oracle Access ManagerのログインではなくOAAMのログイン・ページにリダイレクトされます。

  2. Oracle Adaptive Access Managerにより、ユーザー認証がOracle Access Managerに委任されます。

  3. その後、Oracle Adaptive Access Managerにより、ユーザーのリスク分析が実行されます。

20.1.2 OAAM 11gとOracle Access Manager 10gの統合のロードマップ

表20-1は、Oracle Adaptive Access ManagerとOracle Access Managerとの統合のための大まかなタスクのリストです。

別途明記されている場合を除き、Oracle Access Adaptive Manager 11gとOracle Access Manager 10gの統合を完了するために次の手順が必要です。

表20-1 Oracle Access ManagerとOracle Adaptive Access Managerとの統合フロー

番号 タスク 情報

1

統合の前に必要なすべてのコンポーネントがインストールおよび構成されていることを確認します。

詳細は、「OAAM 11gとOracle Access Manager 10gの統合の前提条件」を参照してください。

2

OAAM Webサーバー用のOAMアクセス・ゲートを構成します。

詳細は、「OAAM Webサーバー用のOAMアクセス・ゲートの構成」を参照してください。

3

OAM認証スキームを構成します。

詳細は、「OAM認証スキームの構成」を参照してください。

4

Oracle Access Managerの接続を構成します(オプション)。

詳細は、「Oracle Access Managerの接続の構成(オプション)」を参照してください。

5

OAAM Webサーバー用のWebゲートを設定します。

詳細は、「OAAM Webサーバー用のWebゲートの設定」を参照してください。

6

OAAM認証を使用するOAMドメインを構成します。

詳細は、「OAAM認証を使用するOAMドメインの構成」を参照してください。

7

OHSを構成します。

詳細は、「Oracle HTTP Server (OHS)の構成」を参照してください。

8

OAAMプロパティを構成します。

詳細は、「Oracle Access Manager用のOAAMプロパティの構成」を参照してください。

9

IP検証を無効化します。

詳細は、「IP検証の無効化」を参照してください。

10

Oracle Access ManagerとOracle Adaptive Access Managerの統合を検証します。

詳細は、「Oracle Adaptive Access ManagerとOracle Access Managerの統合のテスト」を参照してください。

20.1.3 OAAM 11gとOracle Access Manager 10gの統合の前提条件

統合を実行する前に、次の前提条件が満たされていることを確認してください。

  • 次のすべての必要なコンポーネントが適切にインストールされ、構成されています。

    • Oracle Adaptive Access Manager 11g

    • Oracle Access Manager 10.1.4.3

    • アプリケーション・サーバー

    Oracle Adaptive Access Manager 11gのインストール情報については、『Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。

    Oracle Access Manager 10gのインストール情報については、『Oracle Access Managerインストレーション・ガイド 10g (10.1.4.3)』を参照してください。

  • 次の2つの異なる認証スキームを使用して単純なHTMLリソースを保護するようにOracle Access Manager環境が構成されています。

    • 最初の認証スキームではBasic Over LDAPを使用します。

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

    • 2つ目の認証スキームは、さらに高いセキュリティ・レベルを提供し、カスタム・フォームベースの認証スキームを使用することによってOAAMサーバーを統合します。

      この方法は、Basicチャレンジ・メソッドに似ていますが、ユーザーは情報をカスタムHTMLフォームに入力します。作成するフォームで、ユーザーに入力を要求する情報を選択できます。チャレンジ・パラメータが使用されます。チャレンジ・パラメータの詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』の第5章「ユーザー認証の構成」のチャレンジ・パラメータに関する項を参照してください。

      認証スキームの詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』の第5章「ユーザー認証の構成」を参照してください。

20.1.4 OAAM Webサーバー用のOAMアクセス・ゲートの構成

Oracle Access ManagerとOracle Adaptive Access Managerの統合では、Oracle Access Managerアクセス・ゲートはOAAMサーバーへのWebサーバー(従来のWebゲート)に面します。アクセス・ゲートの詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』の第3章「Webゲートおよびアクセス・サーバーの構成」を参照してください。

OAAMサーバーへのWebサーバーに面するOracle Access Managerアクセス・ゲートを構成するには、次の手順を実行します。

  1. アクセス・システム・コンソールに移動します。

    アクセス・システムへのログインの詳細は、『Oracle Access Manager IDおよび共通管理ガイド 10g (10.1.4.3)』の第1章「管理の準備」を参照してください。

  2. 「アクセス・システム・コンソール」リンクをクリックし、マスター管理者としてログインします。

  3. 「アクセス・システム構成」をクリックして、新規アクセス・ゲートの追加を選択します。

  4. 次の表の設定を使用して新しいアクセス・ゲートを作成し、それにアクセス・サーバーを割り当てます。

    アクセス・ゲートのアクセス・サーバーへの割当ての詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』のアクセス・サーバーへのアクセス・ゲートとWebゲートの関連付けに関する項を参照してください。

    表20-2 Oracle HTTP Server (OHS) Webゲートの構成

    パラメータ 値 説明

    アクセス・ゲート名

    ohsWebGate

    このアクセス・ゲート・インスタンスの名前。

    説明

    OAAMサーバーをホストするWebサーバー用のアクセス・ゲート

    このアクセス・ゲートを後で識別するのに役立つ概要。

    ホスト名

    hostname

    このアクセス・ゲートをホスティングしているサーバーの名前またはIPアドレス。

    ポート番号

    port_number

    Webゲートとしてデプロイされたときのアクセス・ゲートによって保護されるWebサーバーのポート。

    アクセス・ゲートのパスワード

    passwd

    このアクセス・ゲートのパスワード。アクセス・ゲートは、このパスワードを使用してアクセス・サーバーに対して自身であることを証明します。

    デバッグ

    <Off>

    Offではアクセス・ゲートとアクセス・サーバー間のデバッグ・メッセージが書き込まれません。

    最大ユーザー・セッション時間(秒)

    3600

    アクティビティに関係なくユーザーの認証セッションが有効な秒単位の最大時間。このセッション時間の終了時に、ユーザーは再認証を要求されます。

    アイドル・セッション時間(秒)

    3600

    アクセス・ゲートで保護されたリソースにアクセスしないでユーザーの認証セッションを保持する秒単位の時間。

    最大接続数

    1

    このアクセス・ゲートが関連付けられたアクセス・サーバーと確立できる最大接続数。

    トランスポート・セキュリティ

    <Open>

    このアクセス・ゲートと、接続先として設定されたアクセス・サーバーとの間のメッセージの暗号化方式。

    IPの検証

    <Off>

    クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。

    IPの検証例外

    空欄

    IPアドレスの検証から除外されるIPアドレス。

    最大クライアント・セッション時間(時間)

    24

    アクセス・ゲートがアクセス・サーバーとの接続を維持する時間。

    フェイルオーバーしきい値

    1

    このアクセス・ゲートがセカンダリ・アクセス・サーバーへの新規接続を開始する接続数を示す数値。

    アクセス・サーバー・タイムアウトしきい値

    空欄

    アクセス・ゲートがアクセス・サーバーからのレスポンスに対して待機する最長時間(秒単位)。

    スリープ時間(秒)

    60

    このアクセス・ゲートがアクセス・サーバーへの接続をチェックする周期を示す秒数。

    キャッシュ内の最大要素

    10000

    URLおよび認証スキーム・キャッシュ内で維持できる要素の最大数。

    キャッシュ・タイムアウト(秒)

    1800

    キャッシュ内の情報が使用も参照もされないときにアクセス・ゲート・キャッシュ内にとどまる時間。

    偽装ユーザー名

    空欄

    偽装に使用するために作成した、信頼できるユーザーの名前。

    偽装パスワード

    空欄

    偽装ユーザー名のパスワード。

    アクセス管理サービス

    <On>

    アクセス管理サービスがオンまたはオフのどちらであるか。アクセス・サーバーが(SDKのAPIを使用して通信する)アクセス・ゲートに関連付けられており、アクセス・ゲートと通信する場合は、「オン」にします。

    プライマリHTTP Cookieドメイン

    domain_name

    アクセス・ゲートがデプロイされている先のWebサーバー・ドメインを説明します。

    優先HTTPホスト

    hostname:port_number

    保護されたWebサーバーにアクセスしようとしたときに、すべてのHTTPリクエストでホスト名がどう表示されるかを指定します。

    保護されていない場合に拒否

    <Off>

    Trueを指定すると、ポリシーで許可されないかぎり、Webゲートで保護されたWebサーバー上のリソースへのアクセスがすべて拒否されます。

    CachePragmaHeader

    no-cache

    デフォルトでは、「CachePragmaHeader」および「CacheControlHeader」は「キャッシュなし」に設定されています。これにより、WebGateによるWebサーバー・アプリケーションおよびユーザー・ブラウザのデータのキャッシュが防止されます。

    CacheControlHeader

    no-cache

    デフォルトでは、「CachePragmaHeader」および「CacheControlHeader」は「キャッシュなし」に設定されています。これにより、WebGateによるWebサーバー・アプリケーションおよびユーザー・ブラウザのデータのキャッシュが防止されます。

    LogOutURLs

    空欄

    ユーザーがログアウトする特定のURLを1つ以上構成できます。

    ユーザー定義パラメータ

    空欄

    Webゲートが特定のブラウザ、プロキシなどと動作するように構成します。

    アクセス・サーバーの割当て(プライマリ)

    oam_hostname:port_number

    アクセス・サーバー。

    接続数

    1

    アクセス・サーバーへの接続数。

  5. 「アクセス・ゲート構成」をクリックします。

  6. 「OK」をクリックして、すべてのアクセス・ゲートを検索します。

    これで、新しいアクセス・ゲートが表示されるようになります。

20.1.5 OAM認証スキームの構成

OAAMサーバーを認証メカニズムとして利用するには、Oracle Access Managerに、OAAMサーバーへの認証の転送方法を理解するための定義済の認証スキームが備わっている必要があります。認証スキームの詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』の第5章「ユーザー認証の構成」を参照してください

Oracle Adaptive Access Managerの認証スキームを定義するには、次の手順に従います。

  1. アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。

  2. 左側のナビゲーション・ペインにある「認証管理」をクリックします。

  3. 「新規」をクリックします。

  4. 次の表の設定を使用して、新しいOAAMサーバー認証スキームの作成を開始します。

    表20-3 OAAMサーバー認証スキームの構成

    パラメータ 値 説明

    名前

    Adaptive Strong Authentication

    スキームの一意の名前。

    説明

    Oracle Adaptive Access Manager-OAAMサーバー仮想認証パッドの認証スキーム

    スキームの動作の簡単な説明。

    レベル

    3

    認証スキームのセキュリティ・レベル。スキームのセキュリティ・レベルは、ユーザーからの資格証明の送信の保護に使用されるチャレンジ・メソッドとセキュリティの強度を示します。

    チャレンジ・メソッド

    フォーム

    認証の実行方法と、ユーザーの認証に必要な情報を指定します。

    チャレンジ・パラメータ

    form:/oaam_server/oamLoginPage.jsp

    Webゲートに認証を実行するための追加情報を提供します

    form - HTMLフォームの場所を、ホストのドキュメント・ディレクトリからの相対パスで示します。

    creds:userid password

    Webゲートに認証を実行するための追加情報を提供します

    creds - ログインに使用されるHTMLフォーム内のすべてのフィールドをリストします。

    action:/oaam_server/

    Webゲートに認証を実行するための追加情報を提供します

    action - HTMLフォームがポスティングされる先のURL。

    SSL必須

    <No>

    ユーザーを、Secure Sockets Layer(SSL)対応のサーバーを使用して認証する必要があるかどうか

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

    リダイレクトURL

    認証がリソースWebサーバーで行われない場合に、このリクエストをリダイレクトする先の別のサーバーのURL。

    有効

    <無効/グレー表示>

    認証スキームを有効化または無効化します。

  5. 「保存」をクリックします。「認証スキームの詳細」ページが表示されます。このページには、新規認証スキーム用に入力した情報が表示されます。

  6. 「OK」をクリックして保存操作を確認します。

  7. 「プラグイン」タブを選択してこの認証スキームのプラグインを表示します。

  8. 「変更」をクリックします。「認証スキームのプラグイン」ページが変更され、「追加」ボタン、「削除」ボタンおよび「キャッシュの更新」チェック・ボックスが表示されます。

  9. 「追加」をクリックします。ページが変更され、追加するプラグインを選択および定義するためのオプション・リストとテキスト・ボックスが表示されます。

  10. 次の表に示されている情報を使用して、プラグイン構成を作成します。

    表20-4 OAAMサーバー認証スキームの構成プラグイン

    プラグイン名 プラグイン・パラメータ

    credential_mapping

    obMappingBase="dc=<domain>,dc=com",obMappingFilter="(uid=%userid%)"

    validate_password

    obCredentialPassword="password"

    credential_mappingプラグインは、ユーザーIDをディレクトリ内の有効な識別名(DN)にマッピングします。

    validate_passwordプラグインは、ユーザーのパスワードをLDAPデータ・ソースに対して検証するために使用されます。

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

  12. 「一般」をクリックします。

  13. 「変更」をクリックします。

  14. 「有効」を「はい」に設定します。

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

20.1.6 Oracle Access Managerの接続の構成(オプション)

OAAMサーバーによって使用されるアクセス・ゲートには、ホスト識別子のエントリがある必要があります。ホスト識別子機能を使用して、ホストの正式名と、ホストのアドレスを指定する際にユーザーが使用できるその他の名前をすべて入力します。

リストにある任意のアドレスに送信されたリクエストはホストの正式名にマップされ、適用可能なルールおよびポリシーが実装されます。これは、仮想サイトのホスティング環境で主に使用されます。

ホスト識別子の構成の詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』の第3章「Webゲートおよびアクセス・サーバーの構成」のホスト識別子の構成に関する項を参照してください。

20.1.7 OAAM Webサーバー用のWebゲートの設定

認証用のCookieおよびOAAMサーバーの必要なHTTPヘッダーを正しく処理するには、OAAMサーバーを標準WebゲートおよびWebサーバーで保護する必要があります。

OAAMサーバーで使用するWebゲートを設定する手順:

  1. アプリケーション・サーバー(およびWebサーバー)を停止します。

  2. Webゲートのインストール・プログラムを実行します。

Webゲートの構成では、次の設定を使用します。

表20-5 OAAMサーバーとともに使用するWebゲートの設定

属性 値 説明

WebゲートID

ohsWebGate

アクセス・システム・コンソールで指定されている一意のID。

Webゲートのパスワード

password

アクセス・システム・コンソールでユーザーが定義したパスワード。

アクセス・サーバーID

Access ServerId

このWebゲートに関連付けられているアクセス・サーバーID。

DNSホスト名

OAAM_hostname

このWebゲートに関連付けられているアクセス・サーバーが対象。

ポート番号

Access_Server_port_number

このWebゲートに対してアクセス・サーバーがリスニングする対象。

詳細は、『Oracle Access Managerインストレーション・ガイド 10g (10.1.4.3)』のWebゲート構成の詳細の指定に関する項と、『Oracle Access Manager統合ガイド 10g (10.1.4.3)』の第2章「Oracle HTTP Serverの統合」に関する項を参照してください。

20.1.8 OAAM認証を使用するOAMドメインの構成

これでOAAMサーバー認証は、Oracle Access Managerポリシー・ドメインに対して動作可能になっています。

OAAM認証スキーム(厳密認証)を使用するようにOracle Access Managerポリシー・ドメインを変更するには、次の手順に従います。

  1. アクセス・システム・コンソールで、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。

  2. 左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。ポリシー・ドメインのリストが表示されます。

  3. 表示するポリシー・ドメインのリンクをクリックします。選択したポリシー・ドメインの「一般」ページが表示されます。

  4. 「デフォルト・ルール」をクリックします。「認証ルール」タブの「一般」ページが表示されます。ルールの現在の構成が表示されます。

  5. 「変更」をクリックします。表示される「一般」ページの各フィールドが変更可能になります。

  6. 「認証スキーム」ドロップダウン・セレクタから、「Adaptive Strong Authentication」を選択します。

  7. 「OK」をクリックして認証スキームの変更を確認します。

  8. 「キャッシュの更新」が選択されていることを確認します。

  9. 「保存」をクリックして変更を保存します。

  10. ブラウザを閉じます。

ポリシー・ドメインの認証ルールの変更の詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』の第5章「ユーザー認証の構成」のポリシー・ドメインの認証ルールの変更に関する項を参照してください。

20.1.9 Oracle HTTP Server (OHS)の構成

mod_wl_ohsは、Oracle HTTP ServerからOracle WebLogic Serverへのリクエストをプロキシ処理するためのプラグインです。mod_wl_ohsモジュールはOracle HTTP Serverのインストールに含まれています。別途ダウンロードしてインストールする必要はありません。OAAMサーバーのプロキシになるようにOHSを構成します。11g OHSでは、mod_wl_ohs.confファイルを変更することによってこの作業を行います。

プロキシを設定する手順:

  1. mod_wl_ohs.confファイルを探します。

    mod_wl_ohs.confファイルは次のディレクトリにあります。

    ORACLE_INSTANCE/config/OHS/component_name

  2. mod_wl_ohs.confファイルを開いて次の例のようなエントリを追加します。

    <Location /oaam_server>
SetHandler weblogic-handler
WebLogicHost name.mycompany.com
WebLogicPort 24300
</Location>

20.1.10 Oracle Access Manager用のOAAMプロパティの構成

この統合を機能させるには、Oracle Access Manager用のOAAMのプロパティ、およびCredential Store Framework (CSF)内のOracle Access Managerの資格証明を設定する必要があります。

20.1.10.1 Oracle Access ManagerのOAAMプロパティの設定

Oracle Access ManagerのOAAMプロパティを設定する手順:

  1. OAAMサーバーをホストしている管理対象サーバーを起動します。

  2. http://oaam_managed_server_host:oaam_admin_server_port/oaam_adminにあるOAAM管理コンソールにナビゲートします。

  3. プロパティ・エディタにアクセス可能なユーザーとしてログインします。

  4. Oracle Access Managerのプロパティを設定するため、OAAMプロパティ・エディタを開きます。

    プロパティが存在しない場合は、追加する必要があります。

    次のプロパティについて、デプロイ内容に従って値を設定します。

    表20-6 Oracle Access Managerのプロパティ値の構成

    プロパティ名 プロパティ値

    bharosa.uio.default.password.auth.provider.classname

    com.bharosa.vcrypt.services.OAMOAAMAuthProvider

    bharosa.uio.default.is_oam_integrated

    false

    oracle.oaam.httputil.usecookieapi

    true

    oaam.uio.oam10.host

    アクセス・サーバー・ホスト・マシン名

    例: host.example.com

    oaam.uio.oam10.port

    アクセス・サーバー・ポート(例: 3004)

    oaam.uio.oam.obsso_cookie_domain

    アクセス・サーバーWebゲート・エージェントに定義されているCookieドメイン

    oaam.uio.oam.java_agent.enabled

    false

    oaam.uio.oam10.webgate_id

    20.1.4項「OAAM Webサーバー用のOAMアクセス・ゲートの構成」で構成されるWebゲートID。

    oaam.uio.oam10.authenticate.withoutsession

    false

    oaam.uio.oam10.secondary.host

    セカンダリ・アクセス・サーバー・ホスト・マシンの名前。

    このプロパティはデフォルトでは設定されないため、追加する必要があります。

    このプロパティは高可用性のために使用されます。このプロパティを使用してフェイルオーバー・ホスト名を指定できます。

    oaam.uio.oam10.secondary.host.port

    セカンダリ・アクセス・サーバーのポート番号

    このプロパティはデフォルトでは設定されないため、追加する必要があります。

    このプロパティは高可用性のために使用されます。このプロパティを使用してフェイルオーバー・ポートを指定できます。

    oaam.oam10.csf.credentials.enabled

    true

    このプロパティにより、資格証明をプロパティ・エディタを使用して管理するのではなく資格証明ストア・フレームワークで構成するように有効化できます。この手順は、資格証明をCSFに安全に保存するために実行します。

Oracle Adaptive Access Managerのプロパティの設定の詳細は、『Oracle Adaptive Access Managerの管理』のプロパティ・エディタの使用方法に関する項を参照してください。

20.1.10.2 資格証明ストア・フレームワークでのOracle Access Manager資格証明の設定

Oracle Access Manager Webゲートの資格証明を資格証明ストア・フレームワークに安全に保存できるように、次の手順に従ってパスワード資格証明をOAAMドメインに追加します。

  1. http://weblogic_server_host:admin_port/emにあるOracle Fusion Middleware Enterprise Managerコンソールにナビゲートします。

  2. WebLogic管理者としてログインします。

  3. 左側ペインのナビゲーション・ツリーで「Base_Domain」を展開します。

  4. 使用するドメイン名を選択して右クリックし、メニュー・オプションで「セキュリティ」、サブ・メニューで「資格証明」を選択します。

  5. 「マップの作成」をクリックします。

  6. 「oaam」をクリックしてマップを選択します。次に「キーの作成」をクリックします。

  7. ポップアップ・ウィンドウで「マップの選択」が「oaam」に設定されていることを確認します。

  8. 次のプロパティを指定し、「OK」をクリックします。

    表20-7 OAAMドメインへのパスワード資格証明の追加

    名前 値

    マップ名

    oaam

    キー名

    oam.credentials

    キー・タイプ

    パスワード

    ユーザー名

    管理者権限を持つOracle Access Managerユーザー

    パスワード

    Oracle Access Manager Webゲート・エージェントのパスワード

20.1.11 IP検証の無効化

Oracle Adaptive Access Managerにより認証後にユーザーを保護されたURLに転送するには、IP検証を無効化する必要があります。IP検証の構成の詳細は、『Oracle Access Managerアクセス管理ガイド 10g (10.1.4.3)』の第3章「Webゲートおよびアクセス・サーバーの構成」のWebゲートのIPアドレス検証の構成に関する項を参照してください。

IP検証を無効化するには、次の手順に従います。

  1. 「アクセス・システム(Access System)」メイン・ページで、「アクセス・システム・コンソール」リンクをクリックし、管理者としてログインします。

  2. 「アクセス・システム・コンソール」メイン・ページで、「アクセス・システム構成」をクリックし、左ペインで「アクセス・ゲート構成」リンクをクリックし、アクセス・ゲート検索ページを表示します。

  3. 適切な検索条件を入力して、「実行」をクリックし、アクセス・ゲートのリストを表示します。

  4. 「アクセス・ゲート」を選択します。

    たとえば、ohsWebGateなどです。

  5. ページの一番下にある「変更」をクリックします。

  6. 「IPの検証」を「オフ」に設定します。

  7. ページの下部にある「保存」をクリックします。

20.1.12 Oracle Adaptive Access ManagerとOracle Access Managerの統合のテスト

構成をテストするには、アプリケーションにアクセスしてみます。Oracle Access Managerにより、未認証のリクエストが捕捉され、資格証明のチャレンジのためにOAAMサーバーにリダイレクトされます。

20.2 OAAM 11gとAccess Manager 11gおよびOAM 10gの統合

デプロイメントが共存する場合に、OAAM Server 11gをOracle Access Manager 10gとOracle Access Management Access Manager (Access Manager) 11gリリース2 (11.1.2.3)の両方に同時に統合できます。

  • 統合により、Oracle Access Manager 10gとAccess Manager 11gの両方が複数のOAAMサーバーではなく同じOAAMサーバーを指すことができます。統合では、複数のOAAMサーバーが使用される場合よりフットプリントが小さくなります。

  • OAAMは、拡張モードおよびTAPモードでOracle Access Manager 10gおよびAccess Manager 11gと統合できます。OAAMサーバーは、拡張モードでOracle Access Manager 10gと統合され、OAAMサーバーはTAPモードでAccess Manager 11gと統合されます。

  • デバイスのフィンガープリント処理、リスク分析、KBAチャレンジ・メカニズムおよびステップ・アップ認証機能は、共存モードのOAAM 11gおよびOracle Access Manager 10g統合で使用できるようになりました。

  • 強力なマルチファクタ認証と高度なリアルタイム不正行為防止機能が提供される一方、Access Manager 11gは移行されたアプリケーションおよびAccess Manager 11gに登録された新規アプリケーションを保護し、Oracle Access Manager 10gはAccess Manager 11gに移行されておらず依然としてOracle Access Managerに登録されているアプリケーションを保護します。

  • ステップ・アップ認証機能を通じて、エンドユーザーは、Oracle Access Manager 11gで保護されるアプリケーションとAccess Manager 11gで保護されるアプリケーションの間を移動する際に、シームレスなシングル・サインオン(SSO)を利用できます。Access Manager 11gで認証されているユーザーは、Oracle Access Manager 10gサーバーで保護されている各リソースにアクセスする場合、資格証明を再度入力する必要がなく、その逆も同様です。

  • Oracle Access Manager 10gとAccess Manager 11gサーバーは、それらにルーティングされるすべての認証リクエストと認可リクエストを、相互に依存せず独立して処理できます。

  • Oracle Access Manager 10gおよびAccess Manager 11gは、相互に関係のない異なるリソースを完全に保護します。

OAAM 11gをAccess Manager 11gと統合する方法は、『Oracle Identity Management Suite統合ガイド』のOracle Adaptive Access ManagerとAccess Managerの統合に関する項を参照してください。

Oracle Access Manager 10gとOracle Access Management Access Manager 11gの共存の設定の詳細は、『Oracle Identity and Access Management移行ガイド』の「Oracle Access Manager 10gとOracle Access Management Access Manager 11.1.2.3.0の共存」の章を参照してください。

20.2.1 OAAM 11gとAccess Manager 11gおよびOAM 10gの統合ワークフロー

OAAM Server 11g、Oracle Access Manager 10gおよびAccess Manager 11g統合環境のプロセス・フローを次に説明します。

20.2.1.1 OAM 10gで保護されているリソースへのアクセスに続いてAccess Manager 11gで保護されているリソースへのアクセス

この項では、、ユーザーが、Oracle Access Manager 10gサーバーで保護されているリソースにアクセスし、次にAccess Manager 11gサーバーで保護されているリソースにアクセスするときの、共存モードでの統合の動作について説明します。

  1. ユーザーは、Webブラウザを通じてOAM 10gで保護されたリソースへのアクセスをリクエストします。

  2. Webゲートがリクエストをインターセプトし、OAMサーバーでリソースが保護されているかどうかを確認します。

  3. リソースが保護されている場合、OAMサーバーはポリシー・マネージャでそのリソースに対して構成されている認証スキームを確認します。OAMサーバーは、認証のためにユーザーをOAAMにリダイレクトし、リダイレクトURLを渡します。

  4. ユーザーは、リソースに対して定義されている認証スキームに従って資格証明の入力を求められます。そのときに、フィンガープリント処理と事前認証ルールが実行されます。OAAMがこれらの資格証明を収集した後、埋込みOAM Access SDKクライアント(またはカスタム・アクセス・ゲート)を使用してこれらの資格証明をOAMサーバーに渡します。

  5. OAMは、構成されたLDAPアイデンティティ・ストアに対して資格証明を検証し、結果をOAAMに返します。

  6. OAAMは、ユーザーが登録またはチャレンジ・フローを通じて取得される必要があるかどうかを評価します。

  7. 該当するフローでOAAMがユーザーとやり取りし、ユーザーが成功した場合、OAMはOAM Cookieを設定し、ユーザーをリダイレクトURLにリダイレクトし、シングル・サインオン・セッションが作成されます。

  8. ユーザーは、OAM 10gで保護されたリソースにアクセスできます。

  9. ユーザーは、Webブラウザを通じてAccess Manager 11gで保護されたリソースへのアクセスをリクエストします。

    Oracle Access Manager 10gサーバーで認証されているユーザーは、Access Manager 11gサーバーで保護されている各リソースにアクセスする場合、資格証明を再度入力する必要がありません。

  10. WebGate 11gは、ObSSOCookieを読み取り、認証レベル情報を取得して、さらに認証が必要かどうかを判断します。

    セットアップ認証機能を使用すると、下位レベルでOAMに認証されているユーザーが、比較的高い認証レベルで構成されたOAAMTAPSchemeによって保護されたリソースにアクセスできます。ユーザーが高いレベルで構成されている保護されたリソースにアクセスしようとすると、OAAMは保護されたリソースへのアクセスに必要な認証レベルを取得するためにさらにユーザーを認証する方法を決定するポリシーを実行します。ユーザーはすでに認証されているので、通常のログイン・フローには進みません。

  11. ユーザーがさらに認証を必要とする場合、制御はOAAMに移り、ユーザーがチャレンジされます。

  12. ユーザーが適切なレスポンスを提供できる場合は、Access ManagerがOAM Cookieを設定し、ユーザーがログインし、シングル・サインオン・セッションが作成されます。ユーザーは、資格証明のプロンプトを表示されずにAccess Manager 11gで保護されたリソースにアクセスできます。

  13. ユーザーがいずれかのサーバーからログアウトした場合、セッションは終了し、ユーザーはAccess Manager 11gとOracle Access Manager 10gサーバーの両方からログアウトされます。ユーザーは、再認証した場合のみ、保護されているリソースにアクセスできます。

20.2.1.2 Access Manager 11gで保護されているリソースへのアクセスに続いてOracle Access Manager 10gで保護されているリソースへのアクセス

この項では、、ユーザーが、Access Manager 11gサーバーで保護されているリソースにアクセスし、次にOracle Access Manager 10gサーバーで保護されているリソースにアクセスするときの、共存モードでの統合の動作について説明します。

  1. ユーザーは、Webブラウザを通じてAccess Manager 11gで保護されたリソースへのアクセスをリクエストします。

  2. Webゲートがリクエストをインターセプトし、OAMサーバーでリソースが保護されているかどうかを確認します。

  3. OAMサーバーは、ポリシー・マネージャをチェックし、リソースがTAPスキームによって保護されていることを確認します。OAMサーバーは、ログインのためにユーザーをOAAMにリダイレクトします。

  4. OAAMは、ユーザー名ページからユーザー名を収集し、デバイスのフィンガープリント処理を行い、事前認証ルールを実行してからパスワード・ページを表示します。

  5. OAAMは、これらの資格証明を収集した後、Access ManagerにOAP APIコールを送信して資格証明を検証します。

  6. OAMは、構成されたLDAPアイデンティティ・ストアに対して資格証明を検証し、TAPトークンをOAAMに送信します。Access Managerが送信するTAPトークンにより、認証レベルに関連するパラメータが提供されます。

  7. OAAMは、事後認証を評価して、登録およびチャレンジ・チェックポイントを実行する必要があるかどうかを判断します。

  8. 該当するフローでOAAMがユーザーとやり取りし、ユーザーが成功した場合、OAAMはOAM Cookieを設定し、ユーザーをリクエストされたリソースにリダイレクトします。

  9. ユーザーは、Webブラウザを通じてOracle Access Manager 10gで保護されたリソースへのアクセスをリクエストします。

  10. セットアップ認証機能を使用すると、下位レベルでOAMに認証されているユーザーが、比較的高い認証レベルで構成されたOAAMTAPSchemeによって保護されたリソースにアクセスできます。ユーザーが高いレベルで構成されている保護されたリソースにアクセスしようとすると、OAAMは保護されたリソースへのアクセスに必要な認証レベルを取得するためにさらにユーザーを認証する方法を決定するポリシーを実行します。ユーザーはすでに認証されているので、通常のログイン・フローには進みません。

  11. ユーザーは、資格証明のプロンプトを表示されずにOracle Access Managerで保護されたリソースにアクセスできます。

    Access Manager 11gサーバーで認証されているユーザーは、Oracle Access Manager 10gサーバーで保護されている各リソースにアクセスする場合、資格証明を再度入力する必要がありません。

  12. ユーザーがいずれかのサーバーからログアウトした場合、セッションは終了し、ユーザーはAccess Manager 11gとOracle Access Manager 10gサーバーの両方からログアウトされます。ユーザーは、再認証した場合のみ、保護されているリソースにアクセスできます。

20.2.2 OAM 10gおよびAccess Manager 11gとOAAMの統合用のOAAMサーバーの構成

OAM 10gとAccess Manager 11gがユーザーを同じOAAMサーバーにリダイレクトできるようにOAAMサーバーを構成するには、次に説明する構成プロパティを編集または追加します。これらのプロパティを定義しない場合、既存の11gプロパティの値が使用されます。oaam_cli.propertiesファイルまたはプロパティ・エディタを使用して、これらのプロパティを編集できます。

oaam_cli.propertiesファイルでの10g OAM統合プロパティの編集

プロパティ・エディタを使用してパラメータを手動で編集しない場合は、oaam_cli.propertiesファイルで次のプロパティを編集できます。

表20-8 OAMサーバー値の構成

プロパティ名 プロパティ値

oam.config.10g

false

oaam.uio.oam10.host

OAP接続を確立する必要のあるプライマリOAMホスト名を定義します。

oaam.uio.oam10.port

プライマリOAMホストのOAPポートを定義します。

oaam.uio.oam10.webgate_id

IAMSuiteAgent

oaam.uio.oam10.secondary.host

セカンダリまたはフェイルオーバーOAMホスト名を定義します。プライマリOAMホストへの接続に失敗した場合、OAP接続はこのホストに対してのみ確立されます。

oaam.uio.oam10.secondary.host.port

セカンダリOAMホストのOAPポートを定義します。

oaam.uio.oam10.security.mode

OAAMとOAM間の通信セキュリティを定義します。1 (open)、2 (simple)または3 (cert)にすることができます。

1

oam.uio.oam10.rootcertificate.keystore.filepath

これは、OAM 10gがSimpleまたはCertモードの場合に必要です。

oam.uio.oam10.privatekeycertificate.keystore.filepath

プロパティを設定できますが、必ずしも変更する必要はありません。

oaam.oam10.csf.credentials.enabled

このプロパティが設定されている場合、Fusion Middleware Credential Store Framework (CSF)を使用してWebゲート・パスワードなどのパスワードを安全に格納します。

true

プロパティ・エディタを使用した10g OAM統合プロパティの編集

表20-9 OAAMサーバー値の構成

プロパティ名 プロパティ値

oaam.uio.oam10.host

OAP接続を確立する必要のあるプライマリOAMホスト名を定義します。

oaam.uio.oam10.port

プライマリOAMホストのOAPポートを定義します。

0

oaam.uio.oam10.secondary.host

セカンダリまたはフェイルオーバーOAMホスト名を定義します。プライマリOAMホストへの接続に失敗した場合、OAP接続はこのホストに対してのみ確立されます。

oaam.uio.oam10.secondary.host.port

セカンダリOAMホストのOAPポートを定義します。

0

oaam.uio.oam10.webgate_id

OAAMで使用されるWebゲートIDを定義します。

oaam.uio.oam10.security.mode

OAAMとOAM間の通信セキュリティを定義します。1 (open)、2 (simple)または3 (cert)にすることができます。

oaam.uio.oam10.user

デフォルトのCSFを使用している場合は不要です。

oaam.uio.oam10.password

デフォルトのCSFを使用している場合は不要です。

oaam.oam10.oamclient.debugFlag

false

プロパティを設定できますが、必ずしも変更する必要はありません。

oaam.uio.oam10.virtual_host_name

IDMDomain

プロパティを設定できますが、必ずしも変更する必要はありません。

oaam.uio.oam10.authenticate.withoutsession

false

プロパティを設定できますが、必ずしも変更する必要はありません。

oaam.oam10.csf.credentials.enabled

このプロパティが設定されている場合、Fusion Middleware Credential Store Framework (CSF)を使用してWebゲート・パスワードなどのパスワードを安全に格納します。

true

プロパティを設定できますが、必ずしも変更する必要はありません。

oaam.oam10.csf.credentials.key

oam.credentials

共存環境では、プロパティをoam.credentials以外の値に設定する必要があります(oam10.credentialsなど)。

oaam.uio.oam10.java_agent.enabled

false

プロパティを設定できますが、必ずしも変更する必要はありません。

oam.uio.oam10.rootcertificate.keystore.filepath

これは、OAM 10gがSimpleまたはCertモードの場合に必要です。

oam.uio.oam10.privatekeycertificate.keystore.filepath

プロパティを設定できますが、必ずしも変更する必要はありません。

oaam.oam10.globalpp.credentials

これは、OAM 10gがSimpleまたはCertモードに設定されている場合に必要です。これは、OAM 10gキーストア資格証明(たとえば、値: oam10.globalpp.credentials)を含むCSF資格証明を指します。

oaam.oam10.keystore.credentials

これは、OAM 10gがSimpleまたはCertモードに設定されている場合に必要です(たとえば、値がoam10.keystore.credentialsなど)。

oracle.oaam.httputil.usecookieapi

OAAMAdvancedスキームをOAM 10gまたはAccess Manager 11gとのOAAM拡張統合で使用している場合は、このプロパティを設定する必要があります。

true

oaam.uio.oam10.nap_version

オプションのプロパティ

oaam.uio.oam10.num_of_connections

オプションのプロパティ

OAAMがプール内に保持する、プライマリOAMサーバーに対するOAP接続の目標(最大)数を定義します。

oaam.uio.oam10.secondary.host.num_of_connections

オプションのプロパティ

OAAMがプール内に保持する、セカンダリOAMサーバーに対するOAP接続の目標(最大)数を定義します。

oaam.oam10.oamclient.minConInPool

オプションのプロパティ

OAAMがプール内に保持するOAP接続の最小数を定義します。

oaam.oam10.oamclient.periodForWatcher

オプションのプロパティ

OAAM Pool Watcherスレッドの休止期間(ミリ秒)を定義します。このスレッドはプール内の接続のヘルスを定期的にチェックします。頻繁に接続不良になる場合は、これを低い値に保ちます。

oaam.oam10.oamclient.initDelayForWatcher

オプションのプロパティ

OAAM Pool Watcherスレッドが接続チェックを開始するまでの初期遅延(ミリ秒)を定義します。

oaam.oam10.oamclient.timeout

オプションのプロパティ

リクエストが使用可能なOAP接続を待機する期間(ミリ秒)。この期間が経過した後で、プールに使用可能な接続がないとタイムアウトになります。この値は小さく設定してください。

20.2.3 Oracle Access Manager 10gおよびOAAM 11g統合環境でのステップアップ認証の構成

Oracle Access Manager 10gおよびOAAM 11g統合環境では、ユーザーがOAM基本認証スキーム(レベル1)で保護されているリソースにアクセスしてから、より高いレベルの認証スキーム(レベル2など)で保護されているリソースにアクセスしようとしたときに、ユーザーがすでに認証されていることをOAAMが検出できるように、OAAMおよびOAMをステップアップ認証用に構成できます。ユーザーは、ユーザーが再度ログインする必要のあるOAAMログイン・ページにリダイレクトされません。

Oracle Access ManagerおよびOracle Adaptive Access Managerを構成するには、この項の手順に従います。

Oracle Access Manager側

  1. 実際のホストにマップされないホスト識別子(STEP_UP_HOSTなど)を作成します。

  2. Oracle Adaptive Access Manager以外のどのコンポーネントでも使用されていない新しいアクセス・ゲートをOAM 10gコンソールのステップアップ認証に追加します。手順1で指定したホスト/ホスト識別子を使用します。

  3. 表20-10に示す設定で、第20.1.5項「OAM認証スキームの構成」と同様の新規認証スキームを作成します。

    表20-10 ステップアップ認証の構成

    パラメータ 値

    名前

    ステップアップ認証

    説明

    ステップアップの認証スキーム

    レベル

    4 (Adaptive Strong Authenticationと同じレベル)

    チャレンジ・メソッド

    なし

    チャレンジ・パラメータ

    (空のままにします)

    SSL必須

    いいえ

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

    (空のままにします)

    有効

    はい

    「プラグイン」セクションで、次の設定を指定します。

    credential_mappingobMappingBase="dc=<domain>,dc=com",obMappingFilter="(uid=%userid%)"

    この認証スキームはユーザー名のマップにのみ使用されるため、"validate_password"プラグインが存在してはなりません。

  4. 新規OAMアプリケーション・ドメインを作成し、/step-up-noauthなどのダミー・リソースを保護します。手順3で作成した認証スキームに使用される認証スキームを設定します。

Oracle Adaptive Access Manager側

  1. 次のWebゲートおよびURL詳細でOAAMステップアップ認証関連プロパティを指定します。

    oaam.uio.oam.10g.stepup.webgate.name=Name_of_Step-Up_AccessGate
oaam.uio.oam.10g.stepup.authn.relative.url=Relative_URL_of_the_protected_Resource
oaam.uio.oam.10g.stepup.authn.preferred.host=Preferred_Hostname_as_set_in_the_accessgate_and_policy

    oaam.uio.oam.10g.stepup.authn.relative.urlの値は、Oracle Access Manager側構成の手順4で指定した相対ダミーURLです。たとえば、/step-up-noauthなどです。

  2. 次のAccess ManagerおよびOAAM統合プロパティが次に示すように設定されていることを確認します。

    oaam.uio.oam.integration.tap.enabled=true
bharosa.uio.default.is_oam_integrated=false
oaam.uio.login.page=/login.do

    oaam.uio.oam.integration.tap.enabledプロパティは、統合がTAP関連でない場合でもtrueに設定する必要があります。そうでない場合、ユーザーはステップアップ・フローを正常に完了できません。

    oaam.uio.login.pageプロパティは、値が/login.doとして設定されたファイルタイプ・プロパティのままである必要があります。oaam.uio.login.pageが正しく設定されていないと、間違ったパスワードが入力された場合またはユーザーがブロックされている場合にエラー・メッセージは表示されません。

  3. Oracle Enterprise Manager Fusion Middleware Controlを使用して、"OAMステップアップ・アクセス・ゲート" (Oracle Access Manager側構成の手順2で構成)のパスワードをOAAM Weblogicドメインのマップ名oaamにキー名oam.stepup.webgate.credentialsのパスワード資格証明として追加します。

20.3 OAM 10g、Access Manager 11gおよびOAAM 11g統合環境でのロード・バランシングの構成

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

20.3.1 ロード・バランシング・シナリオでホスト名とパスを読み取るためのOAAMの構成

デフォルトでは、Oracle Adaptive Access Managerは、OAM Cookie ObFormLoginCookieからそれぞれwhおよびwuを使用してホスト名とパスを読み取ります(元のリクエストwhはホスト識別子の値で、wuはURLの値)。ロード・バランシング・シナリオでは、ホスト名とパスはrhおよびruを使用してObFormLoginCookieから解析する必要があります(rhはリクエスト内のホスト名で、ruはリクエスト内のURI)。これらは次のプロパティを使用して設定できます。

oaam.uio.oam.cookie.redirect.hostname.attribute=rh (default=wh)
oaam.uio.oam.cookie.redirect.path.attribute=ru (default=wu)

20.3.2 ロード・バランシングのためのプライマリ・サーバーとしてのOAMサーバーの指定

ロード・バランシングのために複数のOAMサーバーをプライマリおよびセカンダリ・サーバーとして指定できます。OAMホスト名は、システム・プロパティとして設定し、"-D"オプションを使用してWebLogic JVMに渡すことで各OAAMインスタンスに渡すことができます。手順は次のとおりです。

  1. OAAM管理コンソールを使用して、次のプロパティを削除します。

    oaam.uio.oam.host=ExistingValue

  2. setenvを使用して、OAMホストを次のように設定します。

    JAVA_OPTIONS "-Doaam.uio.oam.host=OAM_Host_Name"

  3. OAAM WebLogic管理対象サーバーoaam_server_server1を起動します。

  4. サーバー・コンソールで、Starting WLS with lineの次に表示される行を参照して、システム・プロパティとして渡されていることを確認します。

20.3.3 リダイレクト用のロード・バランシングされたURLと認証用の実際のホストURLの別々の読取りの有効化

OAMOAAMUtil.getRedirectURLFromCookie()およびOAMOAAMUtil.getIsProtectedResourceURLFromCookie()は、OAM10gIntegrationProcessorを通じて使用可能であるため、リダイレクト用のロードバランシングURLとOAM認証APIによる認証用の実際のホストURLは、ObFormLoginCookieとは別に解析できます。その手順を次に示します。

  1. Oracle Access Manager 10gおよびOracle Adaptive Access Manager 11gが、OAMIntegrationProcessorではなくOAM10gIntegrationProcessorに設定された統合プロセッサおよびロード・バランス・フロント・エンドWebサーバーと統合されていることを確認します。

    プロパティoaam.server.integration.processor.oamの値がcom.bharosa.uio.processor.integration.OAM10gIntegrationProcessorであることを確認します。

  2. すべての実際のホスト名を事前定義済ホストとしてOAMポリシーに追加します。

  3. OAAM管理コンソールのOAAMプロパティ・エディタを使用して、次のOAAMプロパティを使用して認証チェックとリダイレクトの属性を指定します。デフォルト値はそれぞれwhとwuです。

    oaam.uio.oam.cookie.isprotected.hostname.attribute (default=wh)
oaam.uio.oam.cookie.isprotected.path.attribute (default=wu)
oaam.uio.oam.cookie.redirect.hostname.attribute (default=wh)
oaam.uio.oam.cookie.redirect.path.attribute (default=wu)

20.3.4 DN属性のCookieからの読取りの有効化

識別名(DN)のユーザーID属性値は、LDAP/OAM設定で構成できます。

たとえば、DNから取得されたuserid属性の名前が"uid"の場合は、次のプロパティを= uidで設定する必要があります。

oaam.uio.oam.obsso_cookie_dn_cn_attr_name=uid

OAMとの統合時にDN属性を正しく識別できるようにOAAMを構成する必要もあります。

oaam.uio.oam.obsso_cookie_dn_cn_attr_nameのデフォルト値はuid,cnです。OAAMは、DN内でuidという属性を探し、存在する場合はユーザーIDとして使用します。このような属性(uid)が存在しない場合、OAAMはDNでcn属性を探し、ユーザーIDとして使用します。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次