ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2.2) for All Platforms
B69533-09
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

16 OAM 11gエージェントの登録および管理

この章では、コンソールまたはリモート登録コマンド行ユーティリティを使用して、11g Webゲート(およびプログラム的に同じものであるアクセス・クライアント)を登録および管理する方法について説明します。登録時には、Access Managerで保護する特定のアプリケーションを指定できます。

この章には次のトピックが含まれます:

16.1 前提条件

この章のタスクを実行する前に、Oracle Access Managementコンソールのホスト(AdminServer)と管理対象OAMサーバーが実行中であることを確認してください。

16.2 コンソール内のOAMエージェント登録パラメータの理解

この項では、OAMエージェントの登録パラメータについて説明します。特に明記しないかぎり、ここに示す情報は、11gと10gのWebGate(プログラムのアクセス・クライアントを含む)に同様に適用されます。トピックには次が含まれます:

16.2.1 OAM Webゲートの作成ページとパラメータについて

OAM ... Webゲートの作成ページでは、登録を合理化するために最小限の情報が要求されます。アスタリスク(*)は必須の詳細です。11g Webゲートまたは10g Webゲートのどちらを登録する場合でも、要求される最初の情報は同じです。

図16-1「OAM 11g Webゲートの作成」ページ

「OAM 11gエージェントの作成」ページ
「図16-1 「OAM 11g Webゲートの作成」ページ」の説明

表16-1は、11g Webゲート(またはアクセス・クライアント)の作成ページについて示しています。特に明記しないかぎり、すべての要素が11gおよび10gエージェントの両方に適用されます。

表16-1 11gおよび10g OAMエージェントの作成ページの要素

OAM Webゲートの要素 説明

名前

このエージェント登録を一意に識別できる名前。ほとんどの場合、WebGateに使用されるWebサーバーをホストするコンピュータ名です。

各エージェント登録を一意に識別する名前がお薦めされます。ただし、次のことに注意してください。

  • エージェント名が存在する場合、エラーは発生せず登録は失敗しません。かわりに、まだ使用されていなければAccess Managerによってポリシーが作成されます。

  • ホスト識別子が存在する場合、一意のエージェント・ベースURLが既存のホスト識別子に追加され、登録が先に進みます。

ベースURL

オプション

WebゲートのWebサーバーがインストールされるコンピュータのホストおよびポート。たとえば、http://example_host:portまたはhttps://example_host:portになります。ポート番号はオプションです。

: 特定のベースURLは、一度のみ登録できます。このベースURLからWebゲートがインストールされているWebサーバー・ドメイン(ホスト識別子要素で指定)へのマッピングは、1対1です。ただし、1つのドメインが複数のベースURLを持つことができます。

アクセス・クライアント・パスワード

オプション

このWebゲートのオプションかつ一意のパスワードで、この登録プロセス中に割り当てられます。

登録されたWebゲートがOAMサーバーに接続するときは、認可されていないWebゲートがOAMサーバーに接続してポリシー情報を取得しないように、認証にこのパスワードが使用されます。

セキュリティ

エージェントおよびOAMサーバー間の通信トランスポート・セキュリティのレベル(OAMサーバーに指定されたレベルと一致する必要があります)

  • オープン--トランスポート・セキュリティは適用されません。

  • 簡易--動的に生成されたセッション・キーを使用したSSL v3/TLS v1.0のセキュアなトランスポート

  • 証明書: サーバー側のx.509証明書を使用したSSL v3/TLS v1.0のセキュアなトランスポート。このオプションを選択すると、「エージェント・キー・パスワード」を入力するフィールドが表示されます。

    エージェント・キー・パスワード: 秘密鍵ファイル(aaa_key.pem)は、DESアルゴリズムを使用して暗号化されます。エージェント・キー・パスワードは、不明瞭化された形式でpassword.xmlに保存され、サーバーがpassword.xmlを生成する際に必要とされます。ただし、このパスワードはサーバーでは保持されません。11g WebGate登録の編集時に、モードがオープンから証明書へ、または簡易から証明書へ変更される場合にのみpassword.xmlが更新されます。証明書モードでは、一度生成されるとpassword.xmlは更新できません。エージェント・キー・パスワードを編集しても、新しいpassword.xmlは生成されません。

: 簡易モードと証明書モード、秘密鍵の暗号化の詳細は、付録Cを参照してください。

ホスト識別子

この識別子は、Webサーバー・ホストを表します。ここにはエージェントの「名前」フィールドの値が自動的に入力されます。

: 次に示すように、同じアプリケーション・ドメインとポリシーを使用して、1つのホスト識別子の下に、複数のOAM Webゲート(またはアクセス・クライアント)を登録できます。

  1. Webgateを登録するときに、ホスト識別子(ユーザーが名前を選択)を作成し、「ポリシーの自動作成」を有効にすることができます。

  2. 手順1と同じホスト識別子を使用して2つ目のWebゲートを登録し、「ポリシーの自動作成」ボックスの選択を解除してポリシーが作成されないようにします。

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

ユーザー定義パラメータ

特定のWebゲートの動作を有効にするために入力できるパラメータ。

関連項目: 「ユーザー定義のWebゲート・パラメータについて」

仮想ホスト

複数のWebサイトとドメイン名を含むWebサーバー上にWebゲートをインストールした場合は、「仮想ホスト」の横にあるボックスを選択します。WebGateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。

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

ポリシーの自動作成

エージェントの登録中、自動的に作成された認証および認可ポリシーを使用できます。デフォルトで、このオプションが選択(有効化)されます。

デフォルト: 有効

登録およびポリシーの共有: 別々のWebサーバーにインストールされた複数のWebゲート(またはアクセス・クライアント)は、同じリソースを保護するために1つの登録およびポリシーを共有できます。この設定は、高可用性フェイルオーバー環境で役立ちます。手順は次のとおりです。

  1. Webゲート1: 最初のWebゲートを登録し、「ポリシーの自動作成」を有効にして、ホスト識別子(任意の名前)とポリシーを生成します。

  2. Webゲート2: 2つ目のWebゲートを登録し、最初のWebゲートと同じホスト識別子を指定して、「ポリシーの自動作成」を無効にします。

2つ目のエージェントの登録後、どちらのWebゲートも同じホスト識別子とポリシーを使用します。

IPの検証

「IPの検証」の横にあるボックスを選択し、クライアントのIPアドレスが、シングル・サインオンで生成されるObSSOCookieに格納されているIPアドレスと同じであるかどうかを確認します。「IPの検証例外」ボックスに、検証から除外するIPアドレスを標準的なアドレス表記(例: 10.20.30.123)で入力します。

これを有効にした場合は、ObSSOCookieに格納されているIPアドレスがクライアントのIPアドレスに一致する必要があります。一致しない場合はCookieが拒否され、ユーザーは再認証が必要になります。

デフォルト: 無効

関連項目: 「Webゲート用IPアドレスの検証について」

エージェント・キー・パスワード

このパスフレーズは、証明書モードの通信でのみ要求され、簡易モードと証明書モードでWebゲートとOAMサーバーとの間のSSL通信に使用する秘密鍵を暗号化する際に使用されます。

: 「エージェント・キー・パスワード」は、この表で既出の「アクセス・クライアント・パスワード」とは関係ありません。

簡易モード: このモードの場合、エージェント・キー・パスワードはグローバル・パスフレーズであり、クライアントとサーバーの両方で同じであることが必要です。OAMサーバーをこの構成にすると、エージェント登録の際にパスワードを取得できます。ただし管理者は、エージェント登録の際に生成されるpassword.xmlファイルをクライアント側にコピーする必要があります。

証明書モード:: このモードの場合、エージェント・キーはグローバルではないため、クライアントとサーバーで同じである必要はありません。管理者は、エージェント登録時のpassword.xmlファイルの生成を有効にし、password.xmlファイルがエージェント側にコピーされるように、エージェント・キー・パスワードを入力する必要があります。証明書を生成するには、opensslや他のサード・パーティ製ツールでこのパスワードを使用して秘密鍵(SSLに使用する)を暗号化し、aaa_key.pem内に格納する必要があります。実行時には、Webゲートがこのキーをpassword.xmlから取得し、aaa_key.pemのキーの復号化に使用します。

  • キーが暗号化されている場合、Webゲートは内部的にコールバック機能を呼び出してパスワードを取得します。

  • キーが暗号化されていてpassword.xmlが存在しない場合、WebゲートはOAMサーバーとの接続を確立できません。

  • キーが暗号化されていない場合、password.xmlの読取りは試行されません。

詳細は、付録Cを参照してください。

リソース・リスト


保護されているリソース(URI)リスト

保護されているアプリケーションのURI: /myapp/loginなど。保護されているアプリケーションの各URIは、保護されているリソース・リストの表の新しい行で指定する必要があります。

デフォルト: /**

デフォルトは、複数のディレクトリにまたがるゼロまたは複数の中間レベル内にある任意の文字シーケンスに一致します。

リソースの追加: 各URIは、保護されているリソース・リストの表の新しい行で指定する必要があります。「+」ボタンをクリックして、保護されているリソース・リストにリソースを追加します。たとえば、/financialを追加すると(また、/myfinancialの追加を繰り返すと)、「ポリシーの自動作成」が選択されている場合は、次のURLが指定したアプリケーション・ドメインのポリシーにシードされます。


/financialから生成されるリソースURL /financial/**
/myfinancialから生成されるリソースURL /myfinancial/**
/**

関連項目: 「リソースのURL、接頭辞、パターンについて」.

パブリック・リソース(URI)リスト

それぞれのパブリック・アプリケーションは、パブリック・リソース・リストの表の新しい行で指定する必要があります。

リソースの追加: 各URIは、パブリック・リソース・リストの表の新しい行で指定する必要があります。「+」ボタンをクリックして、パブリック・リソース・リストにリソースを追加します。たとえば、/peopleを追加すると、次のURLがこの部分と、アプリケーション・ドメインに含まれます(「ポリシーの自動作成」が選択されている場合)。


/people

関連項目: 「リソースのURL、接頭辞、パターンについて」.

関連項目:

表16-3「拡張された11gおよび10g Webゲート/アクセス・クライアント登録ページの要素」



Webゲート登録を合理化するために、作成操作時に一部の要素は非表示になり、デフォルト値が適用されます。


注意:

Oracle Access Managementコンソールを使用して変更された内容は、アプリケーション・サーバーの再起動なしで反映されます。変更内容は、再構成タイムアウト期間後に、自動的に反映されます。

16.2.2 ユーザー定義のWebゲート・パラメータについて

サポートされる一部のパラメータは、管理者が、Webゲートの登録ページで値を直接入力するか、OAMエージェントのリモート登録リクエスト・テンプレートに値を入力することで定義できます。表16-2に、サポートされるユーザー定義パラメータを示します。各パラメータに指定できる値は1つのみです。

表16-2 ユーザー定義のWebゲート・パラメータ

ユーザー定義のWebゲート・パラメータ 説明

ChallengeRedirectMethod

埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対して、このユーザー定義認証POSTデータ保持パラメータを構成します。

値: GET|POST|DYNAMIC

: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebゲートが参照されます。そうでない場合、デフォルト動作はDynamicです。

関連項目: 表19-23「認証スキームのユーザー定義チャレンジ・パラメータ」

ChallengeRedirectMaxMessageBytes

obrareq.cgiおよびobrar.cgiとして受信するメッセージ・データのサイズを制限するためにこのユーザー定義Webゲート・パラメータを構成します。メッセージ・データは、問合せ文字列長(存在する場合)で構成されます。また、POSTデータが存在する場合は、POSTデータ長で構成されます。メッセージ長がこの制限を超える場合、メッセージは処理されることなく、ブラウザには既存メッセージが表示されます。イベントは通常どおり記録されます。

デフォルト: 8192バイト

注意:

obrareq.cgiは、WebゲートからOAMサーバーにリダイレクトされる問合せ文字列の形式での認証リクエストです。

obrar.cgiは、OAMサーバーからWebゲートにリダイレクトされる認証レスポンス文字列です。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表16-2「ユーザー定義のWebゲート・パラメータ」

MaxPostDataBytes

埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対する認証POSTデータ保持パラメータ。

このパラメータは、ユーザーの資格証明として送信され、OAMサーバーに転送されるPOSTデータの最大バイト数を制限する正の整数値を必要とします。

デフォルト: 8192バイト

MaxPostDataBytesをリソースWebゲートに割り当てることにより、保持するPOSTデータを転送する前にアプリケーションから受信するPOSTデータのサイズを制限するプリファレンスを指定します。

関連項目: 「PasswordPolicyValidationSchemeの構成」

「認証POSTデータ・ハンドリングの構成」

表19-23「認証スキームのユーザー定義チャレンジ・パラメータ」

MaxPreservedPostDataBytes

認証POSTデータの保持に対してこのユーザー定義Webゲート・パラメータ(またはユーザー定義認証スキームのチャレンジ・パラメータ)を構成します。

デフォルト: 8192バイト

: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebゲートが参照されます。そうでない場合、デフォルト動作は8192バイトです。

このパラメータは、Webゲートが保持できるPOSTデータの最大長を定義します。インバウンド・ロー・ユーザーPOSTデータ(または処理後に暗号化されるPOSTデータ)がこの制限を超えた場合、POSTデータは削除され、既存の認証フローが続行されます。イベントは通常どおり記録されます。

関連項目: 「認証POSTデータ・ハンドリングの構成」

表19-23「認証スキームのユーザー定義チャレンジ・パラメータ」

PostDataRestoration

埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対する認証POSTデータ保持パラメータ。このパラメータは、trueまたはfalseの値を必要とします。

デフォルト: false

trueに設定すると、WebゲートはPOSTデータの保持を開始します。

関連項目: 「認証POSTデータ・ハンドリングの構成」

serverRequestCacheType

ECCのみ

埋込み資格証明コレクタ(ECC)に対する認証POSTデータ保持パラメータ。

oam-config.xml内のこのOAMサーバー・パラメータは、リクエスト・コンテキストを記憶するために使用されるメカニズムを示します。可能な値は、FORM、COOKIEまたはCACHEです。

デフォルト: COOKIE

POSTデータを保持するにはFORMが必要です。

関連項目: 表19-23「認証スキームのユーザー定義チャレンジ・パラメータ」TempStateMode

「認証POSTデータ・ハンドリングの構成」

UrlInUTF8Format=true

Oracle HTTP Server 2を使用する環境では、このパラメータをtrueに設定してラテン1および他の文字セットを表示する必要があります。

ProxySSLHeaderVar=IS_SSL

Webゲートがリバース・プロキシの背後にあり、クライアントとリバース・プロキシの間でSSLが構成されており、リバース・プロキシとWebサーバーの間で非SSLが構成されている場合に使用します。これにより、URLがHTTPではなくHTTPSとして格納されます。プロキシを使用すると、クライアント接続にSSLと非SSLのどちらを使用するかを示すカスタム・ヘッダー変数を設定して、URLがHTTPS形式で格納されます。

ProxySSLHeaderVarパラメータの値はプロキシが設定する必要のあるヘッダー変数の名前を定義します。ヘッダー変数の値は"ssl"または"nonssl"である必要があります。

ヘッダー変数が設定されていない場合、SSL状態は現在のWebサーバーのSSL状態によって決まります。

デフォルト: IS_SSL

client_request_retry_attempts=1

WebGateとOAMサーバーのタイムアウトしきい値は、接続不可能とみなして新しい接続のリクエストを試みるまでのWebGateがOAMサーバーを待機する時間(秒単位)を指定します。

OAMサーバーがリクエストを処理する時間がタイムアウトしきい値を超える場合、Webゲートはそのリクエストを破棄し、新規接続でリクエストを再試行します。

デフォルト: 1

: 接続プールから返された新しい接続は、接続プールの設定に応じて、同じOAMサーバーへのものとなることがあります。また、別のOAMサーバーでも、リクエストの処理に必要な時間が、タイムアウトしきい値に指定された時間よりも長くなる可能性があります。場合によっては、OAMサーバーが停止するまで、Webゲートによる再試行が続行する可能性があります。client_request_retry_attemptsパラメータを使用すると、応答しないサーバーに対するWebGateの再試行の回数を制限できます。

InactiveReconfigPeriod=10

Webゲート更新スレッドは、Webゲートがアクティブなとき1分間隔で共有シークレットをOAMサーバーから読み取ります。OAMサーバーは、共有シークレットを独自のキャッシュ(OAMサーバー・キャッシュ)に入れて戻します。

デフォルト: 10(分)

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

fallbackToContainerPolicy=true

IAMSuiteAgentに使用されます。falseに設定すると、リソースへのユーザー・アクセスが拒否され、HTTPレスポンス・コード403が返されます。

trueに設定すると、リクエストはコンテナまで到達し、コンテナで構成されているポリシー(J2EEの認証/認可に関係する)を使用してユーザーにアクセス権を付与または拒否します。

デフォルト: true

logoutRedirectUrl=

デフォルト = http://OAMServer_host:14200/oam/server/logout

protectWebXmlSecuredPagesOnly=true

IAMSuiteAgentに使用されます。ユーザーが認証されると、後続のすべてのリクエストに対してこのパラメータを使用し、エージェントで着信リクエストの検証が必要かどうかが決定されます。設定によって次のようになります。

false: エージェントは常に着信リクエストを検証します。

true: デフォルト。着信リクエストを検証するかどうか、次のようにエージェントが決定します。

  • アプリケーションのweb.xmlで、"<auth-method>"構造の一部として'CLIENT-CERT'が指定されている場合、エージェントは着信リクエストを検証します。

  • アプリケーションのweb.xmlで、"<auth-method>"構造の一部として'CLIENT-CERT'が指定されていない場合、エージェントは着信リクエストを検証しません。かわりに、リクエストをそのままアプリケーションまで通過させます。

maxAuthorizationResultCacheElems

認可結果キャッシュの最大要素: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するセッションの認可結果に関する情報を保持します。例:

maxAuthorizationResultCacheElems=10000

デフォルト = 100000

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

authorizationResultCacheTimeout

認可結果のキャッシュ・タイムアウト: 認可結果キャッシュに保持される要素数。このキャッシュは、関連するセッションの認可結果に関する情報を保持します。例:

authorizationResultCacheTimeout=60

時間が指定されていない場合のデフォルトは、15(秒)です。

注意: 「認可結果キャッシュのタイムアウト」はデフォルトでは設定されません。

キャッシュが有効になっている場合は、最初のリクエスト結果がキャッシュ期間中保持されます。これにより効果が拡大され、遅延時間が短縮します。たとえば、認証ポリシー・レスポンスを設定し、カスタム・セッション属性exmpl:sampleを設定するとします。これに対応する認可ポリシー・レスポンスは、HEADER SESSION_ATTR_EXMPL=sampleとして返されます。ユーザーが、これらのポリシーによって保護されているURLにアクセスした場合、いくつか更新された後のヘッダーを受信することになります。ただし、最初は値が見つからない可能性もあります。

値が0の場合、キャッシュは無効になります。キャッシュが存在しない場合、ヘッダーのレスポンスに入力するために2つのリクエストが実行されます。1つ目のリクエストでは使用するセッション変数を設定し、2つ目でそのセッション変数を使用します。トリガーした認可リクエスト内にはレスポンス値を設定しないことをお薦めします。

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

UniqueCookieNames

WebゲートのCookie名の書式を、次のように制御します。

  • Legacy: 従来の書式(デフォルトを維持し下位互換性があります): <prefix>_<host>:<port>_<suffix>

  • Enabled: UniqueCookieNames書式を有効化します(rfc2109準拠のCookie名制約): <prefix>_<host>:<port>_<suffix>

  • Disabled: Cookie名の書式は、<prefix>_<suffix>になります。<host>:<port>および<host>_<port>は、Cookie名に追加されません。

  • その他の値は、デフォルトの従来の書式として扱われます: <prefix>_<host>:<port>_<suffix>

11g Webゲートのみ


SetKeepAlive

デフォルトでは、SetKeepAliveはONです。この場合、最初のキープアライブ・メッセージは、2分間のデフォルト・アイドル時間の後に送信されます。この動作を変更するには、パラメータに新しい値を設定します。SetKeepAlive=Offである場合、機能は無効となっておりキープアライブ・メッセージは送信されません。SetKeepAlive=x (xはなんらかの正の整数値)である場合、キープアライブ・メッセージは、チャネルがx分間アイドルであった後に送信されます。実際のエンド・パーティ(フロントエンドAccess Managerサーバー)にTCP/IPキープアライブ・メッセージを転送するために、なんらかのファイアウォールまたはロード・バランサを構成する必要があります。

アイドル時間をプログラム的に変更する方法は、Linux64、Linux32およびWindows32のWebGateに実装されています。この機能は、SPARC Solarisプラットフォームには対応してません。その場合には、SetKeepAliveを有効化して、管理者がキープアライブのアイドル時間を手動設定する必要があります。

filterOAMAuthnCookie

11g Webゲートでは、セキュリティを考慮してユーザー定義パラメータ(filterOAMAuthnCookie(デフォルトはtrue))を使用して、OAMAuthnCookieをダウンストリーム・アプリケーションに渡すことを防止できます。このCookieを渡す必要がある場合は、filterOAMAuthnCookieパラメータにfalseを設定します。

ssoCookie

OAMAuthnCookieのCookieを制御します。

デフォルト:

ssoCookie=httponly

ssoCookie=Secure

次のどちらかの設定で無効化されます

ssoCookie=disablehttponly

ssoCookie=disableSecure

: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

  • 外部資格証明コレクタが有効化された11g Webゲートの場合、これらのパラメータはエージェント登録ページで直接設定します。

  • DCC以外のエージェント(リソースWebゲート)の場合、これらのパラメータは認証スキーム内のユーザー定義チャレンジ・パラメータを通じて構成します。

関連項目:

表19-23「認証スキームのユーザー定義チャレンジ・パラメータ」

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

「DCC対応の11g Webゲートと認証ポリシーの構成」

miscCookies

その他の各種のAccess Manager内部Cookiesを制御します。デフォルトでは、httponlyは、その他の(各種の)すべてのCookiesに対して有効化されています。

デフォルト:

miscCookies=httponly

miscCookies=Secure

次のどちらかの設定で無効化されます

miscCookies=disablehttponly

miscCookies=disableSecure

: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。

  • 外部資格証明コレクタが有効化されたWebゲートの場合、これらのパラメータはエージェント登録ページで直接設定します。

  • DCC以外のエージェント(リソースWebゲート)の場合、これらのパラメータは同じ名前のチャレンジ・パラメータを通じて構成します。

関連項目:

表19-23「認証スキームのユーザー定義チャレンジ・パラメータ」

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

「DCC対応の11g Webゲートと認証ポリシーの構成」

OAMAuthAuthenticationServiceLocation

11g Webゲート非ブラウザ・クライアント機能

非ブラウザ・クライアント機能をアクティブ化し、認証サービスの場所を定義します。

OAMAuthUserAgentPrefix=: user-agent HTTPヘッダー値の接頭辞として機能する接頭辞文字列。

たとえば、Identity Connectに対してこの機能をアクティブ化する場合は、次のようになります。

OAMAuthAuthenticationServiceLocation=https://login.example.com/nbc

このパラメータが省略(または値なしで設定)された場合、非ブラウザ・クライアント機能は非アクティブになります。

関連項目: 第40.3項「Oracle Access Management Mobile and Socialの管理」

OAMAuthUserAgentPrefix

11g Webゲート非ブラウザ・クライアント機能

非ブラウザ・クライアント機能をアクティブ化し、user-agent HTTPヘッダー値の接頭辞として機能する文字列を定義します。

OAMAuthAuthenticationServiceLocation=: NBC認証サービスの完全URL。

たとえば、Identity Connectに対してこの機能をアクティブ化する場合は、次のようになります。

OAMAuthUserAgentPrefix=NBC

このパラメータが省略(または値なしで設定)された場合、非ブラウザ・クライアント機能は非アクティブになります。

関連項目: 第40.3項「Oracle Access Management Mobile and Socialの管理」

RequestContextCookieExpTime

OAMRequestContext Cookieの有効期限が切れる時間(秒単位)を制御します。Cookieライフタイムの構成は、Cookieが急増した状況に対応する必要があるデプロイメントでの制御オプションです。

デフォルト: 設定なし

リソースWebゲートの登録では、このパラメータを追加して、IEブラウザ以外のすべてのブラウザに対してMax-Ageディレクティブを使用して、構成されている秒数(デフォルトは5分)でOAMRequestContext Cookieの有効期限が切れるようにします。

: IEユーザーは、Expiresディレクティブを使用して、絶対時刻でCookieの有効期限を制御するため、Internet Explorerの場合のみ、ブラウザとWebサーバー・ホスト間の時間同期が必要です。ただし、IEブラウザで、このパラメータを設定しない場合、OAMRequestContext Cookieは一時セッションCookieになります。

IE以外の他のブラウザでは、Cookieは永続Cookieになり、Max-Ageディレクティブを使用して設定される時刻に基づいて有効期限が制御されます。

関連項目:

表18-8「SSO Cookie」のOAMRequestContext

ProxyTrustedIPList

信頼できるプロキシやロード・バランサのIPアドレスのリストを保持する複数値のパラメータです。第16.2.3.2.1項「ProxyTrustedIPListの使用」を参照してください。

ProxyRemoteIPHeaderVar

IPアドレスのリスクを含むHTTPヘッダーの名前を指定します。第16.2.3.2.2項「ProxyRemoteIPHeaderVarの定義」を参照してください。


16.2.3 Webゲート用IPアドレスの検証について

IPアドレス検証は、クライアントのIPアドレスと、シングル・サインオン用に生成されるCookieに格納されているIPアドレスが同じであるかどうかを確認する機能です。IPValidationパラメータは、IPアドレス検証のオンとオフを切り替えます。これはWebGate固有のパラメータであり、WebGateプロファイルの中にあります。IPValidationtrueの場合は、Cookieに格納されているIPアドレスとクライアントのIPアドレスが一致する必要があり、一致しない場合はSSO Cookie (表1-2)が拒否されるため、ユーザーは再認証が必要になります。IPValidationは、デフォルトでfalseです。


注意:

現在のAccess Managerは、IPv4に加えてインターネット・プロトコル・バージョン6 (IPv6)もサポートしています。

Webゲートと認証時にクライアントIPアドレスを持たないアクセス・クライアントの間のシングル・サインオンを構成する場合は、IP検証オプションを明示的に無効にできます(「IPValidation」をfalseに設定します)。「IPValidation」パラメータをfalseに設定すると、ブラウザまたはクライアントのIPアドレスは、SSO Cookieの構成要素として使用されなくなります。ただし、IP検証は、可能なかぎり有効にしておくことをお薦めします。WebGateプロファイル構成の詳細は、第16.4.3項「コンソール内のOAMエージェント登録ページの表示または編集」を参照してください。

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

16.2.3.1 IP検証例外リストの定義

IP検証パラメータによって、ある一定のWebアプリケーションのデプロイメントに問題が生じる可能性があります。たとえば、プロキシ・サーバーで管理されるWebアプリケーションは、通常、ユーザーのIPアドレスをプロキシのIPアドレスに変更します。これは、Cookieを使用したシングル・サインオンの妨げになります。「IPValidationException」パラメータには、この検証プロセスの対象として例外となるIPアドレスをリストします。IPValidationtrueの場合には、IPアドレスはIP検証例外リストと比較されます。そのアドレスがリストにある場合、そのアドレスはCookieに格納されたIPアドレスと一致する必要はありません。

必要なだけの数のIPアドレス(クライアントの実際のIPアドレスであり、ObSSOCookie SSO Cookieに格納されたIPアドレスではありません)を例外リストに追加できます。SSO Cookieが例外IPアドレスのいずれかである場合、アクセス・システムはそのSSO Cookieに格納されているアドレスの検証を省略します。(CookieのIPアドレスがリバース・プロキシ用のアドレスである場合には、IP検証例外リストのIPアドレスを使用できます。)

16.2.3.2 負荷分散環境におけるIP検証の有効化

(プロキシ・サーバーまたは)ロード・バランサの場合、攻撃者が例外リストに定義されているIPアドレスを使用する可能性があるため、Oracle Access Managerは真のIP検証を強制できません。したがって、管理されたWebアプリケーションは、通常、ユーザーのIPアドレスを(プロキシまたはロード・バランサのIPアドレスに)変更します。これによって、SSO Cookieを使用したシングル・サインオンを防止できます。

ロード・バランサは、リクエスタの本来のIP番号がカンマとスペースで区切られているリストを含むX-forwarded-forヘッダ変数を、受信したHTTPリクエストに追加します。リクエストがproxy1、proxy2そしてproxy3 (proxy3がリクエストのリモート・アドレスであるように見えます)を通過する次の例を考えてみましょう。最後のIPアドレスは、必ず、最後のプロキシに接続するIPアドレスです。

X-Forwarded-For: client1, proxy1, proxy2

ヘッダーから各IPアドレスを検索するために、一番右の値から信頼リストを参照します。一番左のIPアドレスは下流側で最も遠いクライアントであり、その後ろにリクエストが通過するプロキシがそれぞれ続きます(リクエストを受信したIPアドレスを追加)。

指定された順番の中で、信頼リストの中のどれとも一致しないIPアドレスの最初のものは、(信頼可能な通信パスに沿った最遠ノードに対する接続の起動側のIPアドレスとして定義される)見かけのクライアントIPとして取り扱われます。次の点にも留意してください:

  • ヘッダー内のすべてのIPアドレス(右側から順に)が信頼リストのエントリに一致する場合には、WebGateはエンド・クライアントIP(ヘッダー内で一番左のIPアドレス)を選択します。

  • IPアドレスが決定したところで、WebGateは見かけのクライアントIPアドレスが格納されているセッション・トークンを獲得し、IPアドレスをセッション・トークン内のアドレスと比較することによって、IP検証が評価されます。

  • 負荷分散されたデプロイメント内でIP検証機能が有効化されている場合には、認証(セッションの作成)と認可がこの機能を有するWebGateによって実行されますが、有効化されていない場合には、認証されたユーザーは再認証の必要があります。WebGateが特定のHTTPヘッダーを検索する場合には、大文字と小文字は区別されません。たとえば、X-Forwarded-ForとX-FORWARDED-FORは同じものとして扱われます。

16.2.3.2.1 ProxyTrustedIPListの使用

ProxyTrustedIPListは、信頼できるプロキシやロード・バランサのIPアドレスのリストを保持する、ユーザー定義の複数値WebGateパラメータです。値は、空白で区切られます。CookieのIPアドレスがリバース・プロキシ用のアドレスである場合には、IP検証例外リストのIPアドレスを使用できます。

図16-2 負荷分散されたデプロイメント

図16-2の説明が続きます
「図16-2 負荷分散されたデプロイメント」の説明

図16-2では、エンド・ユーザーのHTTPリクエストは、REVERSEPROXY1とREVERSEPROXY2を通過して実際のWebサーバーに到達しています。この場合、REVERSEPROXY1とREVERSEPROXY2のIPアドレスは、次のようにProxyTrustedIPListリストに追加する必要があります。

ProxyTrustedIPList=10.77.199.59 10.77.199.26

注意:

集中認証デプロイメントでは、リソースWebGate (RWG)または認証WebGate (AWG)のどれかがプロキシの先にある場合には、プロキシの先のWebGateのプロファイルの中に、すべての仲介サービスのIPアドレスを(ProxyTrustedIPListパラメータ内に)構成する必要があります。そうしないと、IP検証が失敗する可能性があります。

16.2.3.2.2 ProxyRemoteIPHeaderVarの定義

ProxyRemoteIPHeaderVarパラメータは、IPアドレスのリスクを含むHTTPヘッダーの名前を指定します。このパラメータが提供されない場合には、デフォルトヘッダーのX-Forwarded-Forが使用されます。このパラメータは、WebGateプロファイル内の他のどのユーザー定義パラメータとも同じように構成できます。たとえば、「ProxyTrustedIPListの使用」に記載したデプロイメントにおいて、X-FORWARDED-FORおよびWebサーバーに到達するそれ以外のヘッダーは、次の形式となります。

HTTP_X_FORWARDED_FOR="10.77.199.129, 10.77.199.59"
REMOTE_ADDR="10.77.199.26"

16.3 コンソールを使用したOAMエージェントの登録

この手順は、Webゲートまたはプログラム・アクセス・クライアントのどちらにも使用できます。登録手順は同じです。OAMタイプ・エージェントは、デプロイする前に登録できます。有効な管理者の資格証明を持つユーザーは、次のタスクを実行することにより、Oracle Access ManagementコンソールでWebゲートを登録できます。


関連項目:


エージェント登録の後に、必要があればOAMサーバーの通信モードを変更できます。エージェントとサーバー間の通信は、WebGateモードが少なくともOAMサーバーと同じかまたは高ければ動作を継続します。付録Cを参照してください。

前提条件

少なくとも1つのOAMサーバーが、登録するエージェントと同じモードで実行中であることを確認してください。

OAMエージェントを登録するには

  1. Oracle Access Managementコンソールの「起動パッド」で「SSOエージェント」をクリックし、次のいずれかをクリックして、新しいページを開きます。

    • 新規OAM 11gエージェント

    • 新規OAM 10gエージェント(第25章も参照)

  2. OAM ... Webゲートの作成ページで、必須項目(*がついている項目)を入力して、このエージェントを登録します。

  3. 保護されているリソース・リスト: この表では、表16-1で説明しているように、このエージェントで保護する個々のリソースのURLを入力します。

  4. パブリック・リソース・リスト: この表では、表16-1にあるように、パブリックにする(保護しない)個々のリソースのURLを入力します。

  5. ポリシーの自動作成: 選択すると、新しいアプリケーション・ドメインおよびポリシーが作成されます(または選択を解除すると、同じホスト識別子が別のWebゲートとして使用され、ポリシーは共有されます(表16-1))。

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

  7. 10g Webゲートの場合: 第25章および次を参照してください。

    1. それぞれの環境に応じて次の手順を実行します(第25章)。

      既存のWebゲートの場合: 手順8を実行してから、第22章「11g Webゲートが関与するセッションの集中ログアウトの構成」に進みます。

      新規Webゲートの場合: 「Access Manager 11g用の最新の10g Webゲートの検索およびインストール」に進みます。

  8. 次のように、簡易モード・ファイルまたは証明書モード・ファイルを含むアーティファクトをコピー(または同じ仕様でWebゲートをインストールしてからアーティファクトをコピー)します。たとえば、オープン・モード・ファイルには、次が含まれます。


    エージェントおよびアーティファクト アーティファクト

    11g Webゲート/アクセス・クライアント

    ObAccessClient.xmlとcwallet.sso

    コピー元: AdminServer (コンソール)ホスト

    $DOMAIN_HOME/output/$Agent_Name/

    コピー先のエージェント・ホスト: $11gWG_install_dir/WebGate/config。


    10g Webゲート/アクセス・クライアント

    ObAccessClient.xml

    : このタスクを実行する前に第25章を参照してください。

    コピー元: AdminServer (コンソール)ホスト

    $DOMAIN_HOME/output/$Agent_Name/

    コピー先: エージェント・ホスト

    $10gWG_install_dir/oblix/lib/


  9. 登録の検証: 次の手順は、「Oracle Access Managementコンソールによるエージェント登録の検証」の手順に似ています。

    1. ナビゲーション・ツリーでエージェント名がリストされていることを確認し、必要な場合はナビゲーション・ツリーのツールバーで「リセット」ボタンをクリックします。

    2. 登録ページの情報が適切であることを確認します。

    3. ポリシーの自動作成: アプリケーション・ドメインが生成されたことと、アプリケーションのホスト識別子が作成されたことを確認します。さらに、アプリケーション・ドメインにリソースが作成されてホスト識別子に関連付けられたことを確認します。

    4. 「リモート登録後の認証およびアクセスの検証」の説明に従って、詳細なテストを実行します。

  10. デプロイメントのニーズに合せて次の手順に進みます。

16.4 コンソールを使用した登録済OAMエージェントの構成および管理

この項では、登録済のWebゲートの管理に役立つ次の内容について説明します。

16.4.1 コンソール内の登録済OAMエージェント構成パラメータの理解

Oracle Access Managementコンソールとリモート登録ユーティリティのどちらを使用してエージェントを登録していても、図16-3に示すように、コンソールで完全なエージェントの構成ページを表示できます。

図16-3 「確認」ウィンドウと、デフォルト値で入力された11g Webゲートの拡張ページ

OAMエージェント・ページと展開された詳細
「図16-3 「確認」ウィンドウと、デフォルト値で入力された11g Webゲートの拡張ページ」の説明

11gと10gのWebゲート登録ページ間には、少しだけ相違点があります。


注意:

エージェントのページにある要素のほとんどは、拡張されたOAMテンプレートでリモート登録ツールを使用して定義する要素と同じです。使用する方法に関係なく、ObAccessClient.xmlにはエージェントの登録または変更後に値が移入されます。

表16-3は、展開された登録の要素を示しています。ここに表示された追加設定は、OAMプロキシにより使用されます。

表16-3 拡張された11gおよび10g Webゲート/アクセス・クライアント登録ページの要素

要素 説明

名前

アクセス・クライアント・パスワード

セキュリティ

ユーザー定義パラメータ

IPの検証

関連項目: 表16-1「11gおよび10g OAMエージェントの作成ページの要素」

関連項目: 「ユーザー定義のWebゲート・パラメータについて」

関連項目: 「Webゲート用IPアドレスの検証について」

プライマリCookieドメイン

10g Webゲートのみ第25章

このパラメータは、エージェントがデプロイされるWebサーバー・ドメインを記述します。たとえば、example.comなどです。

Cookieドメインを構成して、Webサーバー間のシングル・サインオンを有効にする必要があります。具体的には、シングル・サインオンを構成するWebサーバーに同じプライマリCookieドメイン値を使用する必要があります。Webゲートは、ObSSOCookie認証Cookieを作成するためにこのパラメータを使用します。

このパラメータは、Cookieドメインに参加してObSSOCookieを受信および更新する機能を持つWebサーバーを定義します。このCookieドメインはObSSOCookieの移入に使用されず、ObSSOCookieの有効なドメインおよびObSSOCookieの内容を承認および変更する機能を持つWebサーバーを定義します。

デフォルト: 登録中にクライアント側のドメインを決定できる場合、プライマリCookieドメインがその値で移入されます。ただし、ドメインが見つからない場合、値が存在しないのでWebGateはホストベースのCookieを使用します。

: ドメイン名が一般的なほど、シングル・サインオンの実装が包括的になります。たとえば、プライマリCookieドメインにb.comを指定すると、ユーザーはb.comおよびa.b.comのリソースのシングル・サインオンを実行できます。ただし、プライマリCookieドメインにa.b.comを指定すると、ユーザーはb.comのリソースのリクエスト時に再認証を行う必要があります。

状態

コンソールのみ

この登録が有効か無効かを指定します。

デフォルト = 有効

最大キャッシュ要素

キャッシュに保持される要素の数。キャッシュは次のとおりです。

  • 認証スキームに対するリソース: このキャッシュは、リソース(URL)に関する情報を保持します。そのURLが保護されているかどうか、そして保護されている場合は保護に使用されている認証スキームもその情報に含まれます。

  • (11g Webゲートのみ)認可ポリシーに対するリソース: このキャッシュは、リソースとそれに関連する認可ポリシーに関する情報を保持します。このキャッシュには、特定の認証スキームIDの認証スキーム情報が格納されます。

この設定の値は、これらのキャッシュの要素の最大合計カウントを参照します。

デフォルト = 100000

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

キャッシュされた情報が使用も参照もされないとき、Webゲートのキャッシュ(「認証スキームに対するリソース」、認証スキーム、11g Webゲートのみの「認可ポリシーに対するリソース」)にその情報が残る時間。

デフォルト = 1800(秒)

トークンの有効期間(秒)

11g Webゲートのみ

エージェント・トークン(11g WebGateのOAMAuthnCookieの内容)の有効な最大時間。

デフォルト = 3600(秒)

: 10g Webゲートの場合、「トークンの有効期間」を設定するには、「Cookieセッション時間」を使用してください。

最大接続数

このWebゲートとOAMサーバーで確立できる接続の最大数。この数値は、このエージェントに実際に関連付けられる接続の数以上にする必要があります。

デフォルト = 1

最大セッション時間(時間)

サーバーの接続が存続する最大時間。単位は、maxSessionTimeUnitsユーザー定義パラメータに基づいており、分または時間に設定できます。maxSessionTimeUnitsを定義していない場合、単位は時間にデフォルト設定されています。

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

このWebゲートがセカンダリOAMサーバーの接続を開くポイントを表す数値。

デフォルト = 1

たとえば、このフィールドに30と入力して、プライマリOAMサーバーへの接続数が29の場合、このエージェントはセカンダリOAMサーバーへの接続を開きます。

AAAタイムアウトしきい値

OAMサーバーからのレスポンスを待機する数値(秒単位)。このパラメータが設定されると、デフォルトのTCP/IPタイムアウトではなくアプリケーションのTCP/IPタイムアウトとして使用されます。

デフォルト = -1(デフォルトのネットワークのTCP/IPタイムアウトが使用されます)

簡易モードのWebゲートを使用している場合、Webゲート・プロファイルのaaaTimeoutThreshold時間パラメータを-1から10に変更することによって、OAMログイン・ページのレスポンス時間を向上させることができます。

このパラメータの一般的な値は、30から60秒です。非常に小さい値に設定すると、OAMサーバーからレスポンスを受信する前にソケット接続がクローズし、エラーが生じる可能性があります。

たとえば、Webゲートが1つのプライマリOAMサーバーと1つのセカンダリOAMサーバーと通信するように構成されているとします。ネットワークのワイヤがプライマリOAMサーバーから引き抜かれた場合、WebゲートはプライマリOAMサーバーへの接続がないことを知るために、TCP/IPタイムアウトの間だけ待ちます。Webゲートは、プライマリOAMサーバーから順に、使用可能なサーバーに対して接続の再確立を試行します。このときも、接続が確立可能かどうかを判断するために、エージェントはTCP/IPタイムアウトの間だけ待機します。確立できない場合は、リストの次のサーバーが試されます。別のOAMサーバー(プライマリまたはセカンダリ)への接続が確立できる場合、リクエストは再ルーティングされます。ただし、これは予想以上に長くかかることがあります。

WebGateは、新しい接続を検索するときには、使用可能なサーバーのリストを、その構成で指定した順序でチェックします。プライマリOAMサーバーが1つとセカンダリOAMサーバーが1つずつ指定されていて、プライマリOAMサーバーの接続がタイムアウトした場合、エージェントはまだプライマリOAMサーバーを先に試します。結果的に、エージェントはOAMサーバー・タイムアウトのしきい値設定の2倍を超える期間だけ、リクエストをOAMサーバーに送信できません。

OAMサーバーがリクエストにサービスを提供するのに、タイムアウトのしきい値よりも長い時間がかかる場合、エージェントはリクエストを放棄して、新しい接続でそのリクエストをやり直します。接続プール設定によっては、接続プールから戻される新しい接続が同じOAMサーバーの接続になる場合があります。また、しきい値で指定された時間よりも、他のOAMサーバーがリクエストの処理に時間がかかることもあります。この場合、エージェントはOAMサーバーが停止するまで、リクエストを引き続き再試行できます。

アイドル・セッション・タイムアウト

10g Webゲートのみ第25章

デフォルト: 3600

リリース7.0.4のWebGateは、独自のアイドル・セッション・タイムアウトのみを適用しました。

10.1.4.0.1のWebGateでは、トークンがアクセスしたすべてのWebGateで最も制限されているタイムアウト値を適用しました。

10g (10.1.4.3)では、この要素のデフォルトが7.0.4の動作に戻りました。

アイドル・セッション・タイムアウトのロジックを設定する方法:

  • leastComponentIdleTimeoutのデフォルト値は、アイドル・セッション・タイムアウトの施行に最も制限されているタイムアウト値を使用するようWebゲートに指示します。

  • currentComponentIdleTimeoutの値は、アイドル・セッション・タイムアウトの施行に現在のWebゲートのタイムアウト値を使用するようWebゲートに指示します。

優先ホスト

ユーザーが保護されたWebサーバーにアクセスしようとしたときに、すべてのHTTPリクエストでホスト名がどう表示されるかを指定します。HTTPリクエスト内のホスト名は、ユーザーのHTTPリクエストでどのように定義されたかに関係なく、このフィールドに入力された値に変換されます。

優先ホストの機能によって、ホストの識別子がホスト識別子リストに含まれていない場合に間違って作成される可能性があるセキュリティ・ホールを防止します。ただし、仮想Webホスティングでは使用できません。仮想ホスティングの場合、ホスト識別子の機能を使用する必要があります。

デフォルトは(Webゲート登録の)名前です。

ユーザー定義パラメータ

関連項目: 「ユーザー定義のWebゲート・パラメータについて」および『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

ログアウトURL

10gおよび11g Webゲート

ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebゲートではObSSOCookie、11g WebゲートではOAMAuthnCookie)、Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。

Default = [](未設定)

: これは、カスタマイズしたローカル・ログアウト・ページから初期ログアウトをトリガーするために使用する、標準の10g Webゲート構成パラメータです。これについては、「11g OAMサーバー使用時の10g Webゲートの集中ログアウト構成」の説明を参照してください。

11g WebGateのみのその他のログアウト

11g Webゲート・シングル・サインオンの動作については、特定のログアウト要素と値によって、中心のログアウトURL、コールバックURLおよびend_URLへのリダイレクトが自動化されます。

関連項目: 表22-2「登録後のログアウトの詳細(ObAccessClient.xml)」

ログアウト・コールバックURL

11g Webゲートのみ

コールバック時にCookieを削除するoam_logout_successへのURLです。これには、host:portのないURI形式を指定でき(推奨)、この場合、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。例:

デフォルト = /oam_logout_success

これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAMサーバーは、コールバックURLを再構築することなく直接コールバックします。

: リモート登録テンプレートでは、このパラメータの名前はlogoutCallbackUrlです(表16-10)。

関連項目: 表22-2「登録後のログアウトの詳細(ObAccessClient.xml)」

ログアウト・リダイレクトURL

11g Webゲートのみ

このパラメータはエージェントの登録完了後に自動的に格納されます。デフォルトでは、これはデフォルト・ポートが14200のOAMサーバー・ホスト名に基づいて決定されます。例:

デフォルト = http://OAMServer_host:14200/oam/server/logout

関連項目: 表22-2「登録後のログアウトの詳細(ObAccessClient.xml)」

ログアウト・ターゲットURL

11g Webゲートのみ

この値は、ログアウト中にOPSSアプリケーションがWebGateに渡す問合せパラメータの名称です。問合せパラメータは、ログアウト完了後に移動するページのターゲットURLを指定します。

デフォルト: end_url

: end_url値は、jps-config.xmlのparam.logout.targeturlを使用して構成されます。

関連項目: 表22-2「登録後のログアウトの詳細(ObAccessClient.xml)」

スリープ時間(秒)

OAMサーバーでディレクトリ・サーバーとの接続を確認する頻度(秒)。たとえば、この値を60秒に設定した場合、OAMサーバーは起動した時点から60秒ごとにその接続をチェックします。

デフォルト: 60(秒)

キャッシュ・プラグマ・ヘッダー

キャッシュ制御ヘッダー

Webゲートのみ(アクセス・クライアントは対象外)

これらの設定はWebGateにのみ適用され、ブラウザのキャッシュを制御します。

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

ただし、サイトがWebGateで保護されている場合、PDFファイルのダウンロードやレポート・ファイルの保存などの特定の操作が実行できないことがあります。

WebGateが異なるレベルで使用するAccess Manager SDKキャッシュを設定できます。詳細は、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlの14.9項を参照してください。

すべてのcache-response-directiveが許可されます。たとえば、両方のキャッシュ値をパブリックに設定してPDFファイルのダウンロードを許可する必要がある場合があります。

デフォルト: キャッシュなし

関連項目: 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』

デバッグ

デバッグは有効または無効にすることができます。

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

Webゲートのみ(アクセス・クライアントは対象外)

「保護されていない場合に拒否」は有効にすることをお薦めします。

この要素を有効にすると、ルールまたはポリシーでアクセスが明示的に許可されていないすべてのリソースへのアクセスが拒否されます。WebゲートがOAMサーバーに問い合せる回数を制限できるため、大規模またはアクセスの多いアプリケーション・ドメインのパフォーマンスを向上できます。

  • 11g Webゲートの場合: 常に有効で変更できません。

  • 10g Webゲートの場合: 無効にできます。

重要: 「保護されていない場合に拒否」は、「ホスト識別子」および「優先ホスト」をオーバーライドします。「保護されていない場合に拒否」は有効にすることをお薦めします。有効にしない場合、複数のホスト識別子、仮想ホストおよびその他の複雑な構成を持つ大規模なインストールで、セキュリティ・ホールが発生する可能性があります。

管理操作の許可

このエージェント権限機能で、次のようなエージェントごとのセッション操作のプロビジョニングを有効にできます。

  • セッションの停止

  • セッションの列挙

  • 既存のセッションに対する属性の追加または更新

  • 特定のセッションIDまたは読取りセッションのすべての属性のリスト

デフォルト: 無効

: セッション管理の操作は、権限のあるエージェントのみが起動できます。このパラメータを有効にすると、セッション管理のリクエスト(上のリスト)がOAMサーバーによって処理されます。無効にすると、エージェントに対してこのリクエストは拒否されます。

11g Webゲートのみ


資格証明コレクタ操作の許可

11.1.2移行のWebゲートのみ

シンプル・フォーム認証または動的な複数要因による認証のために、Webゲートの外部資格証明コレクタ機能を有効にします。

デフォルト: 無効

関連項目: 「DCC対応の11g Webゲートと認証ポリシーの構成」

Sharepoint偽装ユーザー

10g Webゲートのみ第25章

Active Directoryでの、偽装用の信頼できるユーザー。このユーザーは偽装以外の目的では使用できません。制約は、Active Directory内の他のユーザーと同じです。

注意: SharePoint偽装は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』で説明するように、Access Managerユーザー偽装とはまったく異なります。

Sharepoint偽装パスワード

10g Webゲートのみ第25章

偽装用の信頼できるユーザー・パスワード。制約は、Active Directory内の他のユーザー・パスワードと同じです。

信頼できるユーザーには強力な権限が付与されるので、非常に複雑なパスワードを選択することをお薦めします。さらに、「パスワードの有効期限なし」ボックスも選択します。偽装モジュールは、信頼できるユーザー・アカウントを表示する唯一のエンティティでなければなりません。パスワードの有効期限が切れたことを外部エージェンシが検出するのは非常に困難です。

プライマリ・サーバー・リスト

このエージェントのプライマリ・サーバー・リストを識別します。デフォルトは、OAMサーバーに基づきます。

  • サーバー名

  • ホスト名

  • ホスト・ポート

  • 最大数(このWebGateがOAMサーバーと確立する最大接続数。WebGateがすべてのOAMサーバーと確立可能な最大合計接続数ではありません)。

セカンダリ・サーバー・リスト

このエージェントのセカンダリOAMサーバーの詳細を識別します。手動で指定する必要があります。

  • サーバー名

  • ホスト名

  • ホスト・ポート

  • 最大数(このWebGateがOAMサーバーと確立する最大接続数。WebGateがすべてのOAMサーバーと確立可能な最大合計接続数ではありません)。


16.4.2 OAMエージェント登録の検索

図16-4に、Webゲートの「検索」コントロール、デフォルトおよび空の「検索結果」表を示します。このページでは、新しい11g Webゲート登録または10g Webゲート登録を作成したり、特定のWebゲートまたはWebゲートのグループ(たとえば、すべての11g Webゲート)を検索したりできます。

図16-4 Webゲートの「検索」コントロールと各作成ボタン

Webゲートの「検索」コントロール
「図16-4 Webゲートの「検索」コントロールと各作成ボタン」の説明

正確な名前がわからない場合には、検索文字列にワイルドカード(*)を使用できます。「検索結果」表で名前を選択すると、登録ページが開いて表示または編集が可能になります。

このページで使用できるコントロールは、表16-4のとおりです。

表16-4 OAMエージェントの「検索」コントロール

コントロール 説明

11g Webゲートの作成

クリックすると、新規11g Webゲートの登録ページが開きます。

10g Webゲートの作成

クリックすると、新規10g Webゲートの登録ページが開きます。第25章「Access Manager 11gを使用する10g Webゲートの登録および管理」を参照してください。

名前

登録ページで定義されているとおりの名前(または名前の一部とワイルドカード(*))を入力します。たとえば「a*」と入力すると、結果表で「Agent_WebGate_AccessDebugNew」が返されます。

バージョン

Webゲートのバージョンを選択して、検索と結果を絞り込みます。

  • 11g

  • 10g

優先ホスト

HTTPリクエストで使用されるとおりのホスト名の全体(または一部とワイルドカード(*))を入力します。たとえば「iam*」と入力すると、結果表で「IAMSuiteAgent」が返されます。

状態

Webゲートの状態を選択して、検索と結果を絞り込みます。

  • 有効

  • 無効

プライマリ・サーバー

プライマリ・サーバー名の全体(または一部とワイルドカード(*))を入力します。

セカンダリ・サーバー

セカンダリ・サーバー名の全体(または一部とワイルドカード(*))を入力します。


前提条件

OAMエージェントは、Access Managerの登録済エージェントであることが必要です。

OAMエージェント登録を検索するには

  1. Oracle Access Managementコンソールで、「SSOエージェント」をクリックします。

  2. 「OAMエージェント」ノードをダブルクリックします。

  3. 検索対象に応じた手順を実行します

    • 有効なすべて: 「バージョン」で「すべて」、「状態」で「すべて」を選択し、「検索」ボタンをクリックします。

    • エージェント・バージョン: 「エージェントのバージョン」リストで10gまたは11gを選択し、「検索」ボタンをクリックします。

    • エージェント名: 検索するインスタンスの正確な名前をテキスト・フィールドに入力し、「検索」ボタンをクリックします。例:

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

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

    • 削除: 「コンソールを使用したOAMエージェント登録の削除」に進みます。

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

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

  5. 完了したら変更を適用します(またはページを閉じます)。

16.4.3 コンソール内のOAMエージェント登録ページの表示または編集

この手順は、Webゲートとアクセス・クライアント登録のどちらを編集する場合でも同じです。有効な管理者の資格証明を持つユーザーは、次の手順で説明するとおり、Oracle Access Managementコンソールを使用して、登録済のWebゲートおよびプログラム・アクセス・クライアントのあらゆる設定を変更できます。たとえば、タイムアウトのしきい値やOAMプロキシで使用される他の設定を変更する場合などです。

変更後は、更新された詳細はランタイムの構成更新プロセスによって伝播されます。通常は、アーティファクトをWebGateの構成領域にコピーする必要はありません。(アーティファクトは、エージェント名やアクセス・クライアントのパスワード、セキュリティ・モードが変更になった場合にだけ、WebGateディレクトリ・パスにコピーする必要があります。)


注意:

Oracle Access Managementコンソールを使用して変更された内容は、アプリケーション・サーバーの再起動なしで反映され、再構成タイムアウト時間の後、自動的に反映されます。

前提条件

エージェントがOracle Access Managementコンソールに登録されて、使用可能であることが必要です。

登録済OAMエージェントの詳細を表示または変更するには

  1. Oracle Access Managementコンソールで、「SSOエージェント」をクリックします。

    1. 「OAMエージェント」ノードをダブルクリックして、「検索」ページを表示します。

    2. 登録を検索: 「OAMエージェント登録の検索」を参照してください。

    3. 結果表でエージェント名をクリックし、ページを開きます。

  2. 必要に応じて、エージェントの詳細とプライマリ・サーバーまたはセカンダリ・サーバーの詳細を変更します(表16-1表16-3)。

  3. ユーザー定義パラメータ: 必要に応じて追加または変更します(表16-2)。

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

  5. 次のように、簡易モード・ファイルまたは証明書モード・ファイルを含むアーティファクトをコピー(または同じ仕様でWebゲートをインストールしてからアーティファクトをコピー)します。たとえば、オープン・モード・ファイルには、次が含まれます。


    エージェントおよびアーティファクト アーティファクト

    11g Webゲート/アクセス・クライアント

    ObAccessClient.xmlとcwallet.sso

    コピー元: AdminServer (コンソール)ホスト

    $DOMAIN_HOME/output/$Agent_Name/

    コピー先のエージェント・ホスト: $11gWG_install_dir/WebGate/config。


    10g Webゲート/アクセス・クライアント

    ObAccessClient.xml

    : このタスクを実行する前に第25章を参照してください。

    コピー元: AdminServer (コンソール)ホスト

    $DOMAIN_HOME/output/$Agent_Name/

    コピー先: エージェント・ホスト

    $10gWG_install_dir/oblix/lib/ObAccessClient.xml


  6. デプロイメントのニーズに合せて次の手順に進みます。

    第V部「Access ManagerのSSO、ポリシーおよびテストの管理」

16.4.4 コンソールを使用したOAMエージェント登録の削除

有効な管理者の資格証明を持つユーザーは、次の手順を実行して、Oracle Access Managementコンソールにより登録されたWebゲートまたはアクセス・クライアントを削除できます。


注意:

エージェントの登録を削除すると、登録のみが削除されます(関連付けられているホスト識別子、アプリケーション・ドメイン、リソースまたはエージェント自身は削除されません)。

前提条件

このエージェントに関連付けられているアプリケーション・ドメイン、リソースおよびポリシーを評価して、これらが別のエージェントを使用するように構成されていること(または削除可能されていること)を確認します。

Webゲートまたはアクセス・クライアントの登録を削除するには:

  1. Oracle Access Managementコンソールで、「SSOエージェント」をクリックします。

    1. 「OAMエージェント」ノードを開いて、「検索」ページを表示します。

    2. 登録を検索: 「OAMエージェント登録の検索」を参照してください。

    3. 結果表から目的の登録を選択して開き、削除するエージェントであることを確認して、ページを閉じます。

    4. 結果表で名前を選択して「削除」(X)ボタンをクリックし、「確認」ダイアログで確認して、ページを閉じます。

    5. エージェント名がナビゲーション・ツリーにないことを確認します。

  2. 10gエージェント・インスタンスの削除: 次の手順を実行します(必要があれば「Access Manager 11gデプロイメントからの10g Webゲートの削除」を参照)。

    1. Webサーバーを停止します。

    2. 次のディレクトリ・パスに用意されているユーティリティを使用して、WebGateソフトウェアを削除します。

      $WebGate_install_dir/oui/bin

      Windows: setup.exe -d
      Unix: runInstaller -d
      
    3. WebGateのアップデート前のhttpd.confバージョンに戻します。例:

      コピー内容: httpd.conf.ORIG

      コピー先: httpd.conf

    4. Webサーバーを再起動します。

    5. エージェントのホストで、Webゲートのインスタンス・ディレクトリを手動で削除します。

      11g Webゲート/アクセス・クライアント: $11gWebGate_instance_dir/WebGate/config


      10g Webゲート/アクセス・クライアント:  $WebGate_install_dir/oblix/lib/

16.5 リモート登録ツール、モードおよびプロセスの理解

エージェントの登録にコンソールを使用する以外の方法として、Oracle提供のテンプレートとリモート登録ユーティリティのoamregを使用することもできます。Oracle Access Managementコンソールまたはリモート登録ユーティリティを使用する管理者は、システム・ストアに資格証明を格納しておく必要があります(第5章)。

この項では、リモート登録について詳細に説明します。この項の内容は、次のとおりです。

16.5.1 リモート登録コマンドの引数とモードについて

リモート登録ツールを使用する前に、表16-5のサンプルに示すように、スクリプト内の2つの環境変数を設定する必要があります。このサンプルでは、ツールの場所はLinuxシステム上の$OAM_REG_HOMEだと想定されています。環境によっては異なることがあります。

表16-5 oamreg内で設定する環境変数

環境変数 説明

OAM_REG_HOME

後に/rregが付けられるRREG.tarが展開されたディレクトリ。

$OAM_HOME/oam/server/rreg/client/rreg

JAVA_HOME

Javaがクライアント・コンピュータに格納されているロケーション。たとえば、$WLS_HOME/Middleware/jdk160_11などです。

注意: $JAVA_HOMEはJDK 1.6を参照する必要があります。


さらに、リモート登録ツールを使用する前に、リクエスト・ファイル内の複数のタグを変更する必要があります(表16-9を参照)。

リモート登録コマンドの引数

表16-6に、リモート登録スクリプトの実行に必要な引数を示します。

表16-6 リモート登録コマンドの引数: モード

引数 説明

モード

次のいずれかを適用します。

  • inband

  • outofband

input/filename.xml

入力ファイル(*request.xmlまたはagentName_Response.xml)への絶対パス、または$OAM_REG_HOMEの値に対する相対パス。

推奨される場所は、$OAM_REG_HOME/inputです。


リモート登録のサンプル・コマンド

サンプル・コマンドを表16-7に示します。このコマンドでは、ツールの場所をLinuxシステムの$OAM_REG_HOMEと想定しています。

表16-7 リモート登録コマンドのサンプル

コマンド・タイプ サンプル(Linux)

帯域内の管理者の帯域内リクエスト

./bin/oamreg.sh inband input/*Request.xml

帯域内の管理者によって送信されたリクエスト

./bin/oamreg.sh outofband input/starting_request.xml

帯域外の管理者の戻されたレスポンス

./bin/oamreg.sh outofband input/agentName_Response.xml

[prompt_flag] value: [-noprompt]

オプション。-nopromptを使用すると、oamregはプロンプト(パスワードなど)を待ちません。かわりに、これらの値は入力ファイルから、またはechoコマンドを使用してコマンド行自体から取得されます。

$OAM_REG_HOMEロケーションからの例

(echo username; echo password; echo WebGate_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt config.file

(echo username; echo password; echo WebGate_password; echo httpscert_trust_prompt;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

(echo username; echo password; echo WebGate_password; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

(echo username; echo password; echo WebGate_password; echo httpscert_trust_prompt; echo cert_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt

関連項目: 「エージェントのリモート更新」



注意:

スクリプトの起動後、管理者はユーザー名およびパスワードを求められます(表16-7で説明した-nopromptを使用する場合を除く)。

スクリプトの実行後、成功または失敗のメッセージが通知されます。登録または更新が成功したら、「更新されたエージェント構成ファイルについて」の説明に従って、アーティファクトをエージェント・ホストにコピーする必要があります。

16.5.2 リモート登録リクエスト・テンプレート内の共通要素

表16-8に、エージェント・タイプにかかわらず、すべてのリモート登録リクエスト・ファイル内で共通するグローバルな要素を示します。


注意:

表16-8では、各要素の説明を省略しています。表16-1を参照してください。

表16-8 リモート登録リクエストの共通要素


要素

<serverAddress>

<serverAddress>http://{oam_admin_ser
ver_host}:{oam_admin_server_port}
</serverAddress>

<agentName>

<agentName>RREG_OAM</agentName>

<hostIdentifier>

<hostIdentifier>RREG_HostId11G
</hostIdentifier> 

拡張されたテンプレートのみ



<agentBaseUrl>

<agentBaseUrl>http://{web_server_
host):(web_server_port}
</agentBaseUrl>

<autoCreatePolicy>

<autoCreatePolicy>true
</autoCreatePolicy>

<applicationDomain>

<applicationDomain>RREG_OAM11G
</applicationDomain>

<virtualhost>

<virtualhost>false<virtualhost>

16.5.3 キーの使用、生成、プロビジョニング、およびストレージについて

登録方式(Oracle Access Managementコンソールおよびリモート登録)にかかわらず、各登録エージェントに対称キーがあります。

mod_ossoまたはOAMエージェントの保護の有無に関係なく、各アプリケーションに対称キーがあります。登録ツールにより、このキーが生成されます。必要に応じて取得できるように、アプリケーションのマッピング、キーおよびエージェント・タイプがシステム構成に格納されます。

キーの使用

各11g Webゲート・エージェントには、エージェントおよびOAMサーバー間で共有される独自の秘密鍵があります。1つの11g Webゲートが損なわれても、他の11g Webゲートは影響を受けません。概要は次のとおりです。

  • ホストベースのWebGate固有のOAMAuthnCookie_<host:port>_<random number>を暗号化/復号化します。

  • WebゲートおよびOAMサーバー間でリダイレクトされるデータを暗号化/復号化します。

キーの生成

図16-5は、使用方式(Oracle Access Managementコンソールおよびリモート登録)に関係なくエージェントの登録時に自動的に発生するキーの生成プロセスを示しています。エージェントごとに1つの対称キーがあります。

キーのアクセス可能性およびプロビジョニング

エージェント固有の各キーは、クライアント・マシン上の保護されたローカル・ストレージを介して、対応するWebゲートからアクセスできる必要があります。暗号化キーは、データ・ストアには格納されません。かわりに、JavaキーストアまたはCSFリポジトリのエントリへの別名が格納され、パートナと信頼管理APIは、リクエストされた時点で実際のキーを取得します。エージェント固有の秘密鍵には、次の特徴があります。

  • リモート登録中にプロビジョニングされます(帯域内モードまたは帯域外モード)。

  • 各エージェントを一意に識別できるように一意の値が設定されます。

  • エージェントにセキュアに配布されます(帯域内モードのワイヤまたは帯域外モードの個別のセキュアなチャネルを使用)。

  • SSOウォレットのOracle Secret Storeに保存されます。SSOウォレットの作成は、11g Webゲートにのみ適用されます(その他の10g Webゲートなどのエージェント・タイプには適用されません)。


    注意:

    Oracle Secret Storeは、プレーン・テキストではないOracle Wallet内の秘密鍵および他のセキュリティ関連の秘密情報を統合するコンテナです。SSOウォレットは、基礎となるファイル・システムのセキュリティに基づいてデータを保護します。このウォレットを開く場合、パスワードは必要ありません。SSOウォレットのセキュリティは、オペレーティング・システムおよびファイル権限によって異なります。

  • 登録の完了時に自動ログインの編集可能なSSOウォレットのOracle Secret Storeに保存されます。

キーの格納

エージェント・キーを含むSSOウォレットをWebGate_instance_dir/WebGate/config ($WebTier_MW_Home/Oracle_WT1/instancesなど)のObAccessClient.xmlを含むディレクトリのcwallet.ssoに格納する必要があります。

SSOウォレットにユーザー・パスワードは不要で、適切なファイル権限(700)またはWindowsのレジストリで保護する必要があります。

16.6 リモート登録テンプレートの理解: OAMエージェント

Oracleでは、エージェントのリモート登録ツールのoamreg.sh (Linux)またはoamreg.bat (Windows)と一緒に使用するために、短縮版と拡張版の両方の登録リクエスト・テンプレートを提供しています。この項では、主にOAMエージェントのテンプレート(Webゲートおよびアクセス・クライアント)について説明します。

どちらのテンプレート(短縮版または拡張版)を選択した場合でも、11gと10gのOAMエージェントのテンプレート間には、表16-9に示すように少数の相違点があります。これらのテンプレートは、$OAM_REG_HOME/input/に格納されています。

表16-9 OAMエージェント用のリモート登録リクエスト・テンプレート

テンプレート・タイプ $OAM_REG_HOME/input/内のテンプレート名

簡略(短縮)版

  • OAM11GRequest_short.xml (11g Webゲート)

  • OAMRequest_short.xml (10g Webゲート)

拡張(完全)版

  • OAM11gRequest.xml (11g WebGate)

  • OAMRequest.xml (10g WebGate)

その他のテンプレート

エージェントの更新

ポリシーの作成、ポリシーの更新

帯域外レスポンス

これらの専用タスクおよびテンプレートについては、次を参照してください。



注意:

10g Webゲートと11g Webゲートでほとんど同じですが、使用しているリリースに適切なリクエストをコピーして使用してください。

16.6.1 OAMエージェントのリモート登録用パラメータ

表16-10に、OAMエージェントのリモート登録リクエストに固有の要素を示します。リクエスト・テンプレート内の要素名はOracle Access Managementコンソール内の対応する要素名と少しだけ異なる場合があります。特に明記しないかぎり、ここに記載する情報はすべて、11gおよび10gの両方のWebゲート/アクセス・クライアントのリクエストに同様に適用されます。保護されているリソース・リスト、パブリック・リソース・リスト、「除外されたリソース・リスト」は、OAMエージェントの短縮版と拡張版の両方のリクエスト・テンプレートに含まれています。


注意:

表16-10では、各要素の説明を省略しています。これらの要素の説明は、表16-3を参照してください。

表16-10 拡張されたOAMエージェントのリモート登録リクエスト内の要素


要素

<serverAddress>

<agentName>

<hostIdentifier>

<agentBaseUrl>

<autoCreatePolicy>

<applicationDomain>

<virtualhost>

表16-8「リモート登録リクエストの共通要素」を参照してください。


<hostPortVariationsList>

<hostPortVariationsList>
  <host>host1</host> 
  <port>7777</port>
 </hostPortVariations>
  <host>host2</host> 
  <port>7778</port>
 </hostPortVariations>
</hostPortVariationsList>

<protectedResourcesList>

<protectedResourcesList>
   <resource>/</resource>
</protectedResourcesList>

<publicResourcesList>

<publicResourcesList>
   <resource>/public/index.html
   </resource>
</publicResourcesList>

<excludedresourcesList>

<excludedresourcesList>
   <resource>/excluded/index.html
   </resource>
</excludedresourcesList>

<primaryCookieDomain>

10gリクエストのみ

OAMRequest.xml (10g Webゲート)では、<hostIdentifier>も優先HTTPホストとして使用されます。

<primaryCookieDomain>{client_domain}
</primaryCookieDomain>

<maxCacheElems>

<maxCacheElems>100000
</maxCacheElems>

<cacheTimeout>

<cacheTimeout>1800</cacheTimeout>

<tokenValidityPeriod>

11gリクエストのみ

<tokenValidityPeriod>3600
</tokenValidityPeriod>

<cookieSessionTime>

10g Webゲートのみ第25章

<cookieSessionTime>3600
</cookieSessionTime>

<maxConnections>

<maxConnections>1</maxConnections>

<maxSessionTime>

<maxSessionTime>24</maxSessionTime>

<idleSessionTimeout>

10g Webゲートのみ第25章

<idleSessionTimeout>3600>
</idleSessionTimeout

<failoverThreshold>

<failoverThreshold>1
</failoverThreshold>

<aaaTimeoutThreshold>-

<aaaTimeoutThreshold>-1
</aaaTimeoutThreshold>

<sleepFor>

<sleepFor>60</sleepFor>

<debug>

<debug>false</debug>

<security>

<security>open</security

<denyOnNotProtected>

<denyOnNotProtected>1
</denyOnNotProtected> 

<allowManagementOperations>

<allowManagementOperations>false/<allowManagementOperations> 

<cachePragmaHeader>


<cacheControlHeader>

<cachePragmaHeader>no-cache
</cachePragmaHeader>


<cacheControlHeader>no-cache
</cacheControlHeader

<ipValidation>

<ipValidation>0</ipValidation>

<ipValidationExceptions>

<ipValidationExceptions>
  <ipAddress>10,11,11,11</ipAddress>
  <ipAddress>10,11,11,12</ipAddress>
  <ipAddress>10,11,11,13</ipAddress>
</ipValidationExceptions>

<logOutUrls>

<logOutUrls>
    <url>/logout1.html</url>
    <url>/logout2.html</url>
</logOutUrls>

<logoutCallbackUrl>

11gリクエストのみ

<logoutCallbackUrl>/oam_logout_success
</logoutCallbackUrl>

<logoutTargetUrlParamName>

11gリクエストのみ

<logoutTargetUrlParamName>end_url
</logoutTargetUrlParamName>

ユーザー定義パラメータの名前

<userDefinedParameters>
   <userDefinedParam>
      <name>...</name>
      <value>...</value>
</userDefinedParam>

MaxPostDataLength

<userDefinedParameters>
   <userDefinedParam>
      <name>MaxPostDataLength</name>
      <value>750000</value>
</userDefinedParam>

maxSessionTimeUnits

<userDefinedParameters>
   <name>maxSessionTimeUnits</name>
   <value>hours</value>
</userDefinedParam>

useIISBuiltinAuthentication

<userDefinedParameters>
<name>useIISBuiltinAuthentication
   </name>
   <value>false</value>
</userDefinedParam>

idleSessionTimeoutLogic

10g WebGateのみ

<userDefinedParameters>
   <name>idleSessionTimeoutLogic
</name>
   <value>leastComponentIdleTimeout
</value>
</userDefinedParam>

URLInUTF8Format

<userDefinedParameters>

   <name>URLInUTF8Format</name>
   <value>true</value>
</userDefinedParam>

inactiveReconfigPeriod

共有シークレットは、10g WebGateにのみ適用されます。

構成は、11g Webゲートにのみ適用されます。

<userDefinedParameters>
<name>inactiveReconfigPeriod</name>
<value>10</value>
</userDefinedParam>

WaitForFailover

<userDefinedParameters>
   <name>WaitForFailover</name>
   <value>-1</value>
</userDefinedParam>

proxySSLHeaderVar

<userDefinedParameters>
   <name>proxySSLHeaderVar</name>
   <value>IS_SSL</value>
</userDefinedParam>

client_request_retry_attempts

<userDefinedParameters>
   <name>client_request_retry_attempts </name>
   <value>1</value>
</userDefinedParam>

ContentLengthFor401Response

<userDefinedParameters>
   <name>ContentLengthFor401Response
</name>
   <value>0</value>
</userDefinedParam>

SUN61HttpProtocolVersion

<userDefinedParameters>
   <name>SUN61HttpProtocolVersion
</name>
   <value>1.0</value>
</userDefinedParam>

impersonationCredentials

<userDefinedParameters>
   <name>username:password
</name>
   <value>cred</value>
</userDefinedParam>

UseWebGateExtForPassthrough

<userDefinedParameters>
   <name>UseWebGateExtForPassthrough
</name>
   <value>false</value>
</userDefinedParam>

syncOperationMode

<userDefinedParameters>
   <name>syncOperationMode</name>
   <value>false</value>
</userDefinedParam>

filterOAMAuthnCookie

11gリクエストのみ

<userDefinedParameters>
   <name>filterOAMAuthnCookie</name>
   <value>true</value>
</userDefinedParam>

16.7 OAMエージェントのリモート登録の実行

この項では、すべてのエージェント・タイプで同様なリモート登録の実行方法について説明します。この項の内容は、次のとおりです。

16.7.1 リモート登録ツールの取得および設定

oamregクライアント・ツールは、OAMサーバー上でなくても使用できます。oamregのホームをすでに開いている場合は、次の手順を使用することで、oamregスクリプトを入手してオペレーティング・システムに合せて更新できます。

Windowsの場合: oamreg.bat

Linuxの場合: oamreg.sh


注意:

ここで説明するように、最新のバンドル・パッチを適用し、再度RREG.tar.gzを解凍することで、最新のツールとファイルを使用することをお薦めします。

リモート登録には、JAVA_HOMEおよびOAM_REG_HOMの2つの変数が必要です(表16-11を参照してください)。

表16-11 リモート登録に必要な変数

ロケーション 変数 説明

クライアント側

JAVA_HOME

環境にすでに設定されている$JAVA_HOMEに基づくコンピュータのJDK 1.6の場所。


OAM_REG_HOME

絶対表記したRREG HOMEのファイルの場所(RREG.tarを展開したディレクトリに/rregを続けた位置で、かつスクリプトが置かれている場所のすぐ上のディレクトリ)。

例:

$OAM_HOME/oam/server/rreg/client/rreg

$ORACLE_IDM_HOMEが$MW_HOME/Oracle_IDMの場合:

export $OAM_REG_HOME=$MW_HOME/Oracle_IDM/oam/server/rreg

rregフォルダの場所(RREG.tar.gzの場所ではなく)

JAVA_HOME

環境にすでに設定されている$JAVA_HOMEに基づきます。


OAM_REG_HOME

インストール中にスクリプトにすでに設定されています。


環境変数を使用してツールを取得し、スクリプトを更新する手順

  1. 次のパスのRREG.tar.gzファイルを探します。

    $ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz 
    
  2. RREG.tar.gzファイルを解凍すると、必須のツールとテンプレートを含むディレクトリが/clientの下に作成されます。

  3. oamregスクリプト(.../rreg/client/rreg/bin)で、環境変数を次のように設定します。

    1. JAVA_HOMEをJDK 1.6に設定します(表16-11)。

    2. OAM_REG_HOMEを、環境変数に基づいてexploded_dir_for_RREG.tar/rregに設定します(クライアント側またはサーバー側、表16-11)。

  4. 「リモート登録リクエストの作成」に進みます。

16.7.2 リモート登録リクエストの作成

登録する特定のエージェントの入力を提供する適切な*Request*.xmlファイルを作成するには、次の手順を使用できます。

前提条件

リモート登録テンプレートの理解: OAMエージェント

登録リクエストを作成するには、次の手順を実行します。

  1. 登録するエージェントに必要な*Request*.xml入力ファイルを探します。

    どちらのテンプレート(短縮版または拡張版)を選択した場合でも、$OAM_REG_HOME/input/に格納されている11gと10gのエージェントのテンプレート間には少数の相違点があります。例:

    OAM11GRequest.xml

  2. リクエスト・ファイルを新しい名前でコピーします。例:


    コピー元: OAM11GRequest.xml
    コピー先: my11gagent_request.xml
  3. 次で説明する詳細を使用して、エージェントおよび保護するリソースの詳細を反映するように、リクエスト・ファイルを変更します。

  4. それぞれの環境に応じて、次のタスクを実行します。

16.7.3 帯域内リモート登録の実行

ネットワーク内のOAM管理者は、すべてのタスクを実行します。この項では、エージェント・タイプに関係なく、帯域内リモート登録を実行する手順を説明します。この例の場合、OAMエージェントは、Linuxシステムで短いリクエストを使用して登録されます。実際のエージェント・タイプ、リクエスト・テンプレートおよび出力ファイルは異なります。


関連項目:

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の「OAMのためのOracle HTTP Server 11g Webゲートのインストールと構成」の章

前提条件

帯域内リモート登録を実行するには、次の手順を実行します。

  1. エージェントをホストしているコンピュータで、登録コマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。例:

    ./bin/oamreg.sh inband input/myagent_request.xml

  2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

  3. 画面のメッセージを参照して確認します。

    • 成功: 画面のメッセージを確認します。

      帯域内登録プロセスが正常に完了しました。

      固有の構成ファイルの場所が出力フォルダに作成されます。

      出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

  4. /rreg/output/AgentName/フォルダにエージェント用に作成されるネイティブ構成ファイルを確認します。

  5. 登録の完了: 古い構成ファイルがまだ置換されていない場合、次の手順を実行して置換します。

    1. /rreg/output/AgentName/内のアーティファクトをコピーして、エージェント構成を更新します。例:

      コピー元: AdminServer (コンソール)ホスト

      /rreg/output/Agent_Name/ObAccessClient.xmlおよびcwallet.sso

      コピー先のエージェント・ホストは$11gWG_install_dir/WebGate/configです。例:


      $WebTier_MW_Home/Oracle_WT1/instances/instance1
      /config/OHS/ohs1/WebGate/config
    2. エージェントをホストしているOAMサーバーを再起動します。

  6. 「リモート登録およびリソース保護の検証」に進みます。

16.7.4 帯域外リモート登録の実行

この項では、ネットワークの外部(および内部)の管理者が連携してエージェントをリモート登録する手順について説明します。

帯域外リモート登録時に、ネットワーク外の管理者は、ネットワーク内の管理者に登録リクエストを送信します。リクエストの処理後、帯域内の管理者は、帯域外の管理者が環境を構成するために必要になる、次のファイルを戻します。

表16-12 帯域内の管理者が帯域外の管理者に戻すファイル

ファイル 説明

agentName_Response.xml

帯域外の管理者に戻され、この管理者が使用します。agentName_Response.xmlを開いたり編集したりしないようにすることをお薦めします。

固有のWebサーバー構成ファイル

帯域外の管理者に戻され、この管理者がWebサーバーを更新するために使用します。

関連項目

「更新されたエージェント構成ファイルについて」



それぞれの管理者が実行する手順は、次のように扱われます。

  • 帯域内の管理者: ネットワーク内のWebサーバー管理者が実行するタスクを扱います。

  • 帯域外の管理者: ネットワーク外のWebサーバー管理者が実行するタスクを扱います。


関連項目:

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の「OAMのためのOracle HTTP Server 11g Webゲートのインストールと構成」の章

ここでは、LinuxシステムでOAMエージェントを登録する手順を説明します。実際のテンプレートおよび出力ファイルは異なります。

前提条件

リモート登録ツールの取得および設定

帯域外リモート登録を実行するには、次の手順を実行します。

  1. 帯域外の管理者: starting_request.xmlファイルを作成して、処理するために帯域内の管理者に送信します(「リモート登録リクエストの作成」を参照してください)。

    $WLS_Home/Middleware/Oracle_$IDM1/oam/server/rreg/client/rreg/output/AgentName/starting_request.xml
    
  2. 帯域内の管理者の手順:

    1. 登録コマンドを実行し、入力ファイルとして帯域外の管理者のstarting_request.xmlを指定します。例:

      ./bin/oamreg.sh outofband input/starting_request.xml

    2. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

    3. 画面のメッセージを参照して確認します。

      成功: 登録プロセスが正常に完了しました。

      Response.xmlの場所が入力フォルダに作成されます。

      入力フォルダは、RREG.tar.gzが展開されている場所(/rreg/input/AgentName/)にあります。

    4. 他のアーティファクトとともにagentName_Response.xmlファイルを帯域外の管理者に戻します。例:

      agentName_Response.xml

  3. 帯域外の管理者: 次のように環境を更新します。

    1. エージェントをホストしているコンピュータで、リモート登録コマンドを実行し、入力ファイルとして受け取ったagentName_Response.xmlを指定します。例:

      ./bin/oamreg.sh outofband input/agentName_Response.xml

    2. /rreg/output/AgentNameに生成されるアーティファクトをコピーして、エージェント構成を更新してから、エージェントをホストするOAMサーバーを再起動します。たとえば、ObAccessClient.xmlとcwallet.ssoを次のようにコピーします。

      コピー元: AdminServer (コンソール)ホストの/rreg/output/Agent_Name/ObAccessClient.xmlおよびcwallet.sso

      コピー先のエージェント・ホストは$11gWG_install_dir/WebGate/configです。例:


      $WebTier_MW_Home/Oracle_WT1/instances/instance1
      /config/OHS/ohs1/WebGate/config
    3. 「リモート登録およびリソース保護の検証」に進みます。

16.8 エージェントのリモート更新の概要

管理者が既存のエージェント登録をすばやく更新、検証または削除できるように、複数のリモート管理モードが提供されています。この項では次のトピックを記載しています:

16.8.1 リモート・エージェント更新のモードについて

表16-13に、リモート・エージェント管理モードを示します。コマンドのパラメータには、モード、入力*Request.xmlファイル($OAM_REG_HOMEに対する相対パス、入力*Request.xmlファイルの優先ロケーション)が含まれます。

./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value

表16-13 リモート・エージェント更新のモードと入力ファイル

モードおよび入力ファイル 説明および構文

agentUpdateモード

OAM11GUpdateAgentRequest.xml

OAMUpdateAgentRequest.xml

エージェント・タイプに関係なく、管理者が既存のエージェント属性を更新できます。

./bin/oamreg.sh agentUpdate input/*UpdateAgentRequest.xml

関連項目:

OpenSSOUpdateAgentRequest第23章

OSSOUpdateAgentRequest第24章

agentValidateモード

入力ファイルは不要です

エージェントがOracle Access Managerですでにプロビジョニングされているかどうかを検証します。

./bin/oamreg.sh agentValidate agentname

agentDeleteモード

入力ファイルは不要です

管理者がエージェント登録を削除できます。

./bin/oamreg.sh agentDelete agentname

16.8.2 リモート 11g OAMエージェント更新のテンプレートについて

OAM11GUpdateAgentRequest.xmlを使用して、特定のエージェント更新値をリモート登録ツールのoamregに渡します。更新リクエストと元の登録リクエストの主な違いは、更新リクエストの次の点にあります。

表16-14 相違点: OAMエージェント更新と登録リクエスト

相違点 要素

追加

<ipValidation>

省略

<ipValidationExceptions>


<hostidentifier>


<virtualhost>


<hostportVariations>


<authCreatePolicy>と、アプリケーション・ドメイン関連の要素


<ssoServerVersion>


<idleSessionTimeout>


16.9 エージェントのリモート更新

この項では、エージェント・タイプに関係なく、Access Managerを使用して登録したエージェントに関する次のトピックについて説明します。

16.9.1 エージェントのリモート更新

このトピックでは、エージェント・タイプに関係なく、Access Managerを使用して登録したエージェントを更新する手順について説明します。

前提条件

「リモート・エージェント更新のモードについて」を確認してください。

エージェント登録をリモートで更新する手順

  1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

  2. 次のいずれかのテンプレートを使用して、更新リクエストを作成します。

    • OAM11GUpdateAgentRequest.xml

    • OAMUpdateAgentRequest.xml (10g) 第25章

    • OSSOUpdateAgentRequest.xml 第24章

    • OpenSSOUpdateAgentRequest.xml 第23章

  3. エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。例:

    ./bin/oamreg.sh agentUpdate input/*UpdateAgentRequest.xml
    
  4. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

  5. 画面のメッセージを参照して確認します。

    • 成功: 画面のメッセージを確認します。

      agentUpdateプロセスは正常に完了しました。

      固有の構成ファイルの場所が出力フォルダに作成されます。

      出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。

  6. エージェント登録を完了します。更新したObAccessClient.xmlとcwallet.ssoをコピーします。

    再配置元AdminServer (コンソール)ホスト: /rreg/output/Agent_Name/

    コピー先のエージェント・ホスト: $11gWG_install_dir/WebGate/config。例:


    $WebTier_MW_Home/Oracle_WT1/instances/instance1/ config/OHS/ohs1/WebGate/config
  7. このエージェントをホストするOAMサーバーを再起動して、「リモート・エージェント検証の実行」に進みます。

16.9.2 リモート・エージェント検証の実行

このトピックでは、エージェント・タイプに関係なく、エージェント登録を検証する手順について説明します。

前提条件

「リモート・エージェント更新のモードについて」を確認してください。

エージェント登録をリモートで検証する手順

  1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

  2. エージェント・ホストで、agentValidateモードで次のコマンドを実行します。例:

    ./bin/oamreg.sh agentValidate agentname
    
  3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

  4. 画面のメッセージを参照して確認します。

    • 成功: 画面のメッセージを確認します。

      AgentValidationプロセスは正常に完了しました。

16.9.3 リモート・エージェント削除の実行

このトピックでは、エージェント・タイプに関係なく、登録されているエージェントを削除する手順について説明します。

前提条件

「リモート・エージェント更新のモードについて」を確認してください。

エージェント登録をリモートで削除する手順

  1. 「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。

  2. エージェントをホストしているコンピュータで、次のagentDeleteコマンドを実行します。例:

    ./bin/oamreg.sh agentDelete agentname
    
  3. 求められた場合に登録管理者ユーザー名およびパスワードを入力します。

  4. 画面のメッセージを参照して確認します。

    • 成功: 画面のメッセージを確認します。

      AgentDeleteプロセスは正常に完了しました。

16.10 リモート登録およびリソース保護の検証

次の各項は、エージェント・タイプに関係なく、エージェントの登録を検証するガイドとして使用できます。Oracle Access Managementコンソールを使用してタスクを実行するには、帯域内の管理者である必要があります。帯域外の管理者は、リモートの認証およびアクセスをテストする必要があります。

16.10.1 Oracle Access Managementコンソールを使用したエージェント登録の検証

次の手順を使用できるのは、帯域内の管理者のみです。

エージェントおよびアプリケーション登録を検証するには、次の手順を実行します。

  1. Oracle Access Managementコンソールで、エージェントの登録を検証します

    1. Oracle Access Managementコンソールの「システム構成」タブでエージェントの詳細を確認します。

    2. 更新したエージェント構成ファイルが、適切な場所に配置されていることを確認します(「OAMエージェントのリモート登録の実行」を参照)。

  2. 共有コンポーネントのホスト識別子を検証します。Oracle Access Managementコンソールでホスト識別子が定義されていることを確認します。

  3. アプリケーション・ドメインを検証します。「ポリシー構成」タブで、登録されたエージェントに基づいて名付けられた新しいアプリケーション・ドメインがあることを確認します。アプリケーション・ドメインのリソースには、ホスト識別子を関連付ける必要があります。

  4. 「リモート登録後の認証およびアクセスの検証」に進みます。

16.10.2 リモート登録後の認証およびアクセスの検証

登録後は、AdminServerまたはOAMサーバーを再起動しなくても、適切な認証によって、保護されたリソースにアクセスできる必要があります。帯域内および帯域外のどちらの管理者も、次の手順を使用して、登録およびポリシーが適切であることを検証できます。

ここでの手順は、登録、認証および認可が適切に構成および動作していることを確認するいくつかの方法を示しています。手順は、すべてのエージェント・タイプでほぼ同じです。

登録後に認証およびアクセスを確認するには、次の手順を実行します。

  1. 登録されたOAMエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。例:

    http://exampleWebserverHost.sample.com:8100/resource1.html
    
  2. ログイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「ログイン」をクリックします。

  3. OAM固有のCookieがブラウザ・セッションに作成されていることを確認します。例:

    ObSSOCookie

    Set-Cookie: 
    ObSSOCookie=GGVEuvjmrMe%2FhbItbjT24CBmJo1eCIfDIwQ1atdGdnY4mt6kmdSekSFeAAFvFrZZZ
    xDfvpkfS3ZLZFbaZU2rAn0YYUM3JUWVYkYFwB%2BBK7V4x%2FeuYHj%2B8gwOyxhNYFna3iSx1MSZBE
    y51KTBfsDYOiw6R%2BCxUhOO8uZDTYHI3s0c7AQSyrEiQTuUV3nv1omaFZlk1GuZa4J7ycaGbIUyqwX
    rM0cKuBJNd6sX1LiRj9HofYQsvUV7ToqeAOpDS7z9qs5LhqU5Vq60bBn12DTX6zNX6Lcc0L5tVwvh7%
    2BnOAkz2%2BoDkLs%2BBTkeGcB3ppgC9;httponly; path=/; domain=.example.com;
    

    OAM_ID Cookie:

    Set-Cookie: 
    OAM_ID=v1.0~0~E1EBBC9846E09857060A68E79AEEB608~AA79FC43C695162B6CDE3738F40E94DA
    6408D58B879AC3B467EBBD4800743C899843672B3511141FFABCF58B2CDCB700C83CC734A913625
    7C4ABDA6913C9EF5A4E05C5D03D3514F2FECACD02F1C1B9314D76B4A68CB7A8BE42AEB09AFB98B8
    EB; path=/; HttpOnly
    
  4. 次のように進めます:

    • 成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。詳細な検証については、手順5から12に進みます。

    • 失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。

      • ログイン・エラー: 有効なユーザーIDおよびパスワードが入力されていることを確認します。

      • 使用不能なリソース: リソースが使用できることを確認します。

      • 不正なリダイレクトURL: Oracle Access ManagementコンソールのリダイレクトURLを確認します。

  5. ユーザー・バリエーション: ユーザー・バリエーションで手順1から4を再実行して、適切な動作(認可ユーザーの成功または未認可ユーザーの失敗)を確認します。

  6. リクエストの取消し: 部分的なログインを実行し、「取消」をクリックしてリソースにアクセスしていないことを確認します。

  7. 変更された認証URL: 手順1から5を実行して適切なレスポンスを確認する場合、ほとんど同じ認証URLを入力します。たとえば、1文字をURL文字列に追加します。

  8. 更新されたリソース: 次の手順を実行して、リソースにアクセスできることを確認します。例:

    元のリソース: /abc/test.html

    更新されたリソース: /abc/xyz/test.html

    Oracle WebLogic Serverを再起動しない場合

    • 更新されたリソースにアクセスし、ユーザーが認証を求められ、リソースにアクセスできることを確認します。

    • 元のリソースにアクセスし、リソースにアクセス可能で、ユーザーが認証を求められていないことを確認します。

  9. 様々なURLパターン: 手順1から5を実行する場合、様々なURLパターンの認証を確認します。

  10. 新しい認証スキーム: 次の手順を実行して、WebLogic Serverを再起動しないで認証操作を確認します。

    • 異なる認証スキームを使用する新しい認証ポリシーを追加します。

    • 新しいポリシーを使用して、リソースを保護します。

    • Oracle WebLogic Serverを再起動しないで、手順1から4を実行します。

  11. CGIリソース・ヘッダー変数およびCookie: 次の手順を実行して、WebLogic Serverを再起動しないで認証操作を確認します。

    • 新しい認証ポリシーを追加してCommon Gateway Interface (CGI)リソースを保護し、「認証に成功しました」のレスポンスを設定します。

    • 新しいポリシーを使用して、リソースを保護します。

    • CGIリソースにアクセスします。

    • CGIデータ・ダンプでレスポンスに対して構成されたヘッダー値を確認します。

  12. エージェントの無効化: WebGateがObAccessClient.xmlで無効な場合、次の手順を実行して、アクセス可能性および認証を検証します(WebGateは、oam-config.xmlから有効な値を選択する必要があります)。

    • エージェント状態を無効化します。WebサーバーおよびOAMサーバーを起動します。エージェントによって保護されているアプリケーションにアクセスして、認証を要求されることを確認します。

16.11 IAMSuiteAgentの11g Webゲートによる置換

IAMSuiteAgentを11g Webゲートと入れ替えていない場合は、この項をスキップしてください。

Access ManagerおよびOracle Identity Managerは、Oracle Fusion Middleware 11gコンポーネントの一部です。WebLogicサーバー構成ウィザードの初期構成中に、IAMSuiteAgentがIDMドメイン・ホスト識別子およびそのエージェントに指定されたアプリケーション・ドメインとともにAccess Manager 11gに登録されます。

Oracle Fusion MiddlewareはIAMSuiteAgentを使用して、保護されたOracle Identity ManagementコンソールにAccess Managerをそのまま使用します。

コンテナ外のアプリケーションを保護するために、IAMSuiteAgentを11g Webゲートに入れ替えることができます(事前登録済のIAMSuiteAgentと同じアプリケーション・ドメインとポリシーを使用して、同じアプリケーション・セットを保護する場合)。

タスクの概要: IAMSuiteAgentの11g Webゲートへの置換

  1. IAMSuiteAgentの入替え用11g Webゲートの登録

  2. IAMSuiteAgentの入替え用11g Webゲートのインストール

  3. WebLogicサーバー・プラグインの更新

  4. オプション: OAM/OIM統合用のAutoLoginホスト識別子の確認

  5. オプション: WebLogic用のOAMセキュリティ・プロバイダの構成

  6. オプション: IAMSuiteAgentの無効化

  7. 11g Webgateの集中ログアウト構成

  8. 検証

16.11.1 IAMSuiteAgentの入替え用11g Webゲートの登録

次に示す手順では、帯域内モードでリモート登録ツールを使用して、入替え用11g Webゲートを登録する方法を順に説明します。


関連項目:

  • リモート登録ツール、処理、リクエスト・ファイルの詳細は、第16章を参照


この例では、OAMRequest_short.xmlをテンプレートとして使用して、11g4IAMという名前のエージェントを作成し、/.../*の保護と、パブリック・リソース/public/index.htmlの宣言を行います。実際の値はこれとは異なります。


注意:

入替え用のWebゲートでIAM Suiteポリシーを使用するには、IAMSuiteAgentホスト識別子と優先ホストを使用するようにWebゲートの登録が構成されていることを確認します。

11g Webゲートを登録してIAMSuiteAgentと入れ替えるには:

  1. Access Managerのリモート登録ツールを入手して、環境に合ったスクリプトを設定します。例:

    1. 次のパスのRREG.tar.gzファイルを探します。

      $ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz 
      
    2. RREG.tar.gzファイルを別な場所に解凍します。たとえば、exploded_dir_for_RREG.tar/rreg/input/oamregなどです。

    3. oamregスクリプトに、状況(クライアント側またはサーバー側)と 表16-5の情報に応じた次の環境変数を設定します。


      OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
      JAVA_HOME = Java_location_on_the_computer
  2. 登録リクエストを作成し、autoCreatePolicyパラメータがfalseに設定されていることを確認します。

    1. OAMRequest_short.xmlを探して、新しいファイルにコピーします。例:

      exploded_dir_for_RREG.tar/rreg/input/oamreg/ 
      

      コピー元: OAM11gRequest_short.xml

      コピー先: 11g4IAM.xml

    2. 環境の詳細を含むように、11g4IAM.xmlを編集します。たとえば、IAMSuiteAgentから11g Webゲート・エージェントに変更する場合は、次のようなリクエストになります。

      <OAM11gRegRequest>
          <serverAddress>http://ruby.uk.example.com:7001</serverAddress>
          <hostIdentifier>11g4IAM</hostIdentifier>
          <agentName>11g4IAM</agentName>
          <autoCreatePolicy>false</autoCreatePolicy>
          <logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
          ...retain defaults for remaining elements...
          ...
          ...
      </OAM11gRegRequest>
      
  3. エージェントを登録します。例:

    1. リモート登録スクリプトを探します。


      Linuxの場合: rreg/bin/oamreg.sh

      Windowsの場合: rreg\bin\oamreg.bat

    2. スクリプトが含まれているディレクトリから、インバンド・モードを使用してスクリプトを実行します。例:

      $ ./bin/oamreg.sh inband input/11g4IAM.xml

      Welcome to OAM Remote Registration Tool!
      Parameters passed to the registration tool are:
      Mode: inband
      Filename: ...
      
    3. プロンプトが表示されたら、環境に応じた値を使用して次の情報を入力します。

      Enter your agent username: userame
         Username:  userame
      Enter agent password: ********
      Do you want to enter a WebGate password?(y/n)
          n
      iv.     Do you want to import an URIs file?(y/n)
          n
      
    4. 最後のメッセージを確認して、登録が成功したことを確かめます。

      Inband registration process completed successfully! Output artifacts are 
      created in the output folder"
      
  4. Oracle Access Managementコンソールにログインして、新規登録を確認します。

    1. 「システム構成」タブの「Access Manager」セクションで、「OAMエージェント」ノートを開いて、エージェント登録を見つけます。

    2. エージェント名をダブルクリックして、登録ページを表示し、詳細を確認します。例:


      注意:

      新しいWebゲートをインストールする場合、インストール中に一致する情報を入力します。

    3. OAMプロキシ・ポート: 「システム構成」タブの「共通構成」セクションで、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが実行中のポートを検索します。

  5. 「IAMSuiteAgentの入替え用11g Webゲートのインストール」で説明されているとおり、次のようにアーティファクトをコピー(または同じ仕様でWebゲートをインストールしてからアーティファクトをコピー)します。


    エージェントおよびアーティファクト アーティファクト

    11g Webゲート/アクセス・クライアント

    ObAccessClient.xmlとcwallet.sso

    コピー元: AdminServer (コンソール)ホスト

    $DOMAIN_HOME/output/$Agent_Name/

    コピー先のエージェント・ホスト: $11gWG_install_dir/WebGate/config。


  6. 「WebLogicサーバー・プラグインの更新」に進みます。

16.11.2 IAMSuiteAgentの入替え用11g Webゲートのインストール

プロビジョニング後、IAMSuiteAgentと入れ替えるために11g Webゲートをインストールする必要があります。インストール中は、プロビジョニング時と同じWebGateの情報を提供する必要があります。

前提条件

IAMSuiteAgentの入替え用11g Webゲートの登録

タスクの概要: 11g Webゲートのインストールには次の手順が含まれています。

  1. 『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』で説明されているように、11g Webゲートをインストールします。

  2. 「WebLogicサーバー・プラグインの更新」で説明されているように、IAMSuiteAgent登録を置換します。

16.11.3 WebLogicサーバー・プラグインの更新

11g Webゲートのプロビジョニングとインストールを行い、IAMSuiteAgentと入れ替えたら、mod_wl_ohs.confファイルに特定の入力をして、WebゲートWebサーバーがWebLogicサーバー上のアプリケーションにリクエストを転送するように指示する必要があります。


注意:

WebLogicサーバーのApache用プラグインの汎用名はmod_weblogicです。Oracle HTTP Server 11gの場合は、このプラグインの名前はmod_wl_ohsです(実際のバイナリ名はmod_wl_ohs.soです)。例では実装のための正確な構文を示します。

例16-1は入力サンプルを使用して変更が必要な部分を示します。使用する環境によって入力内容は異なります。

例16-1 mod_wl_ohs.confでの11g Webゲート用の更新

<IfModule weblogic_module>
   <Location /oamconsole>
         SetHandler weblogic-handler
         WebLogicHost ruby.uk.example.com
         WebLogicPort    6162
   </Location>
   <Location apmmconsole>
         SetHandler weblogic-handler
         WebLogicHost ruby.uk.example.com
         WebLogicPort    6162
   </Location>
...

</IfModule>

注意:

WebLogicサーバーで直接アクセスしたことがあるすべてのアプリケーションの各URIに対して、類似の場所エントリが必要です。

前提条件

IAMSuiteAgentの入替え用11g Webゲートのインストール

環境に合ったmod WebLogic構成の更新手順

  1. 次のパスにあるmod_wl_ohs.confファイルを探します。

    $OHS-INSTANCE_HOME/config/OHS/INSTANCE_NAME/mod_wl_ohs.conf
     
    
  2. WebLogicサーバーで直接アクセスしたことがあるすべてのアプリケーションの各URIに対して、Locationエレメントを含むようにファイルを編集します(例16-1を参照)。

  3. ファイルを保存します。

  4. Webサーバーを再起動します。

  5. 必要に応じて次のタスクに進みます。

16.11.4 OAM/OIM統合用のAutoLoginホスト識別子の確認

このトピックではAccess ManagerがOracle Identity Manager (OIM)と統合されている場合に、OIMの自動ログイン機能を確認(または構成)する方法を説明します。


注意:

Access Manager 11gをOracle Identity Manager 11gに統合していない場合、この手順は省略します。

Oracle Identity ManagerがAccess Manager 11gに統合されている場合、AutoLogin機能では、IAMSuiteAgentのホスト識別子リスト内に10g WebゲートWebサーバーのホスト名とポートが含まれている必要があります。


注意:

11g WebゲートWebサーバーの前にロード・バランサがある場合、手順3でロード・バランサのホスト名とポートを含める必要があります。

agentBaseUrlパラメータを使用して特定のホスト識別子を更新します。ただし、自動ポリシーの作成がfalseに設定されている場合、リモート登録ユーティリティはアプリケーション・ドメインを作成せず、agentBaseUrlパラメータを参照しません。

次の手順では、Access Manager/Oracle Identity Manager統合のためにAutoLoginホスト識別子を確認(または構成)する方法を示します。実際の値はこれとは異なります。

前提条件

WebLogicサーバー・プラグインの更新

OAM/OIM統合用のAutoLoginホスト識別子の構成手順

  1. 「ポリシー構成」タブの「ホスト識別子」ノードで、IAMSuiteAgentを選択します。

  2. 「操作」パネルで、このホスト識別子のすべてのホスト名とポートの組合せがリストされていることを確認します。

  3. 「WebLogic用のOAMセキュリティ・プロバイダの構成」に進みます。

16.11.5 WebLogic用のOAMセキュリティ・プロバイダの構成

この項では、Access Manager 11gと10g Webゲートを使用してシングル・サイン・オンが行えるように、WebLogicセキュリティ・プロバイダを構成する方法を説明します。


注意:

Access Manager 11gをOracle Identity Manager 11gに統合していない場合、この手順は省略します。

11g Webゲート用のセキュリティ・プロバイダの設定の詳細は、次のトピックを参照してください。

16.11.5.1 セキュリティ・プロバイダについて

IAMSuiteAgentを11g Webゲートに入れ替える場合に、Access Manager 11g SSOの構成を完了するには、WebLogicサーバー・ドメイン内で次のセキュリティ・プロバイダを構成する必要があります。

  • OAM Identity Asserter: トークンベースの認証を使用し、OAM SSOヘッダーとトークンをアサートします。

  • OID (またはOVD) Authenticator: サブジェクトを作成し、正しいプリンシパルを移入します。

    ユーザーが保存されているストアに応じて、Oracle Internet Directory AuthenticatorまたはOracle Virtual Directory Authenticatorのいずれかをプライマリ資格証明オーセンティケータとして構成します。

  • デフォルト・オーセンティケータ: このデフォルトWebLogic認証プロバイダによって、ユーザーとグループを、組み込まれたWebLogicサーバーLDAPサーバーという1つの場所で管理できます。Oracle WebLogic Serverはこのオーセンティケータを使用して、管理ユーザーのログインを行います。

複数の認証プロバイダを構成する場合、各プロバイダにJAAS制御フラグを使用して、ログイン順序での認証プロバイダの使用方法を制御します。たとえば次のJAAS制御フラグ設定を使用できます。

  • REQUIRED - 認証プロバイダは常に呼び出され、ユーザーは必ずその認証テストに合格する必要があります。認証の成否にかかわらず、プロバイダ・リストの残りの認証が続行されます。OAM Identity Asserterが必要です。

  • SUFFICIENT - ユーザーは認証プロバイダの認証テストに合格する必要はありません。認証に合格した場合は、以降の認証プロバイダは実行されません。認証が失敗下場合は、プロバイダ・リストの残りの認証が続行されます。Oracle Internet Directory (またはOracle仮想ディレクトリ)およびデフォルト・オーセンティケータの両方がSUFFICIENTです。

  • OPTIONAL - 追加の認証プロバイダが既存のセキュリティ・レルムに加わると、デフォルト設定で制御フラグがOPTIONALに設定されます。各認証プロバイダが認証順序で正しく機能するように、制御フラグの設定とプロバイダの順序を変更する必要があるかもしれません。

    ユーザーは認証プロバイダの認証テストを合格しても、不合格になってもかまいません。ただし、JAAS制御フラグがOPTIONALに設定されたセキュリティ・レルムですべての認証プロバイダが構成されている場合は、ユーザーは構成されたいずれかのプロバイダの認証テストに合格する必要があります。


関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項に、すべての認証プロバイダのリストと、ユーザーおよびグループ属性のLDAPスキーマに見合ったOracle Internet Directoryプロバイダの構成詳細が記載されています。

Access Manager JARは、Oracle Fusion Middleware製品(Oracle Identity Management、Oracle SOA Suite、またはOracle WebCenter)のインストール時に使用可能な認証プロバイダのWARファイルです。Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っています。

  • oamAuthnProvider.jar: シングル・サインオン用のAccess Managerアイデンティティ・アサータのファイルとOracle WebLogic Server 10.3.1以降のオーセンティケータのファイルが含まれています。ユーザーやアプリケーションからのWebリソースおよび非Web(非HTTP)リソースに対するリクエストを処理するために、カスタムのAccess Managerアクセス・ゲートも用意されています。

  • oamauthenticationprovider.war: Oracle WebLogic Serverコンソールに表示されるプロバイダ・リストを、Access Managerで使用する必要があるもののみに限定します。

    拡張をデプロイする際に、管理コンソールでは、そのWARファイルに記述されたファイルおよびディレクトリと、拡張のWARファイルに記述されたファイルおよびディレクトリとのメモリー内結合が作成されます。デプロイした拡張機能は、管理コンソールの完全なメンバーになります。この拡張機能は、WebLogic Serverのセキュリティ・レルムで保護され、管理コンソールの他のセクションに移動できます。また、拡張機能からWebLogic Serverリソースを変更する場合、拡張機能は変更管理プロセスに関与します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server管理コンソールの拡張』を参照してください。

16.11.5.2 11g Webゲート用のセキュリティ・プロバイダの設定

次の手順にはWebLogicサーバー管理コンソールが必要です。この例では、Oracle Internet DirectoryプロバイダをOAM Identity Asserterおよびデフォルト・オーセンティケータで設定する方法を示します。OVDの場合も必要な手順は同じです。


注意:

Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っているので、次の手順1をスキップできます。ただしFusion Middlewareアプリケーションがない場合は、スタンドアロンOracle WebLogic Serverなので、手順1で説明したようにOracle Technology NetworkからJARおよびWARファイルを入手する必要があります。

前提条件

WebLogicサーバー・プラグインの更新

Access Manager 11gを使用する11g Webゲート用にWebLogic Serverドメインでプロバイダを設定するには:

  1. Oracle Fusion Middlewareアプリケーションがない場合: Access Managerプロバイダを次の手順で入手します。

    1. 次のOracle Technology Networkにログインします。

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      
    2. WebゲートでoamAuthnProvider ZIPファイルを検索します。

      oamAuthnProvider<version number>.zip  
      
    3. oamAuthnProvider.jarを、Oracle WebLogic Serverをホスティングしているコンピュータの次のパスに解凍し、コピーします。

      $BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
      
  2. Oracle Fusion Middlewareアプリケーションがインストールされている場合:

    1. 次のパスでoamauthenticationprovider.warを探します。

      $ORACLE_HOME/modules/oracle.oamprovider_11.1.2/oamauthenticationprovi
      der.war
      
    2. oamauthenticationprovider.warを次の場所にコピーします:

      $BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
      provider.war  
      
  3. WebLogicサーバー管理コンソールにログインして、セキュリティ・レルムデフォルト・レルム名をクリックし、プロバイダをクリックします。

  4. OAM Identity Asserter: 次の手順を実行してこのプロバイダを追加します。

    1. 「認証」をクリックして「新規」をクリックし、次に名前を入力して、タイプを選択します。

      名前: OAM ID Asserter

      タイプ: OAMIdentityAsserter

      OK

    2. 認証プロバイダ表内で、新しく追加されたオーセンティケータをクリックします。

    3. 共通タブで、制御フラグをREQUIREDに設定して、「保存」をクリックします。

  5. OIDオーセンティケータ: 次の手順を実行してこのプロバイダを追加します。

    1. 「セキュリティ・レルム」デフォルト・レルム名をクリックし、「プロバイダ」をクリックします。

    2. 「新規」をクリックし、次に名前を入力して、タイプを選択します。

      名前: OID Authenticator

      タイプ: OracleInternetDirectoryAuthenticator

      OK

    3. 認証プロバイダ表内で、新しく追加されたオーセンティケータをクリックします。

    4. 設定ページの共通タブで、制御フラグをSUFFICIENTに設定して、「保存」をクリックします。

    5. プロバイダ固有タブをクリックして、環境に合った値を使用して、次のような必要な設定を行います。

      ホスト: ご使用のLDAPホスト。例: localhost

      ポート: ご使用のLDAPホスト・リスナー・ポート。例: 6050

      プリンシパル: LDAP管理ユーザー。例: cn=orcladmin

      資格証明: LDAP管理ユーザー・パスワード。

      ユーザー・ベースDN: Access Managerと同じ検索ベース。

      すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))

      ユーザー名属性: LDAPディレクトリ内のユーザー名のデフォルト属性として設定。例: uid

      グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)

      すべてのグループフィルタをデフォルト作業として設定しないでください。

      保存します。

  6. デフォルト・オーセンティケータ: 次の手順を実行して、Identity Asserterで使用するデフォルト・オーセンティケータを設定します。

    1. 「セキュリティ・レルム」デフォルト・レルム名に移動して、「プロバイダ」をクリックします。

    2. 「認証」をクリックして、DefaultAuthenticatorをクリックし、確認ページを表示します。

    3. 共通タブをクリックして制御フラグをSUFFICIENTに設定します。

    4. 保存します。

  7. プロバイダの並替え:

    1. 「セキュリティ・レルム」デフォルト・レルム名「プロバイダ」をクリックします。

    2. プロバイダがリストされたサマリーページで、並替えボタンをクリックします

    3. 認証プロバイダの並替えページで、プロバイダ名を選択し、リストの横にある矢印を使用してプロバイダの並替えを行います。

      OAMアイデンティティ・アサータ(REQUIRED)

      OIDオーセンティケータ(SUFFICIENT)

      デフォルト・オーセンティケータ(SUFFICIENT)

    4. 「OK」をクリックして変更を保存します

  8. 変更のアクティブ化: チェンジ・センターで「変更のアクティブ化」をクリックします。

  9. Oracle WebLogic Serverを再起動します。

  10. 次のように進めます:

16.11.6 IAMSuiteAgentの無効化

この手順はオプションで、必須ではありません。

IAMSuiteAgentは、Webゲートが認証を行い、サイレント状態になると検知します。ただし、エージェントを無効にする必要がある場合、エージェントを無効にする必要がある各サーバーに対して、WLSAGENT_DISABLEDシステム・プロパティまたは環境変数をtrueに設定する必要があります。これはAdminServerとOAMサーバーの両方に適用されます。

エージェントの無効化は次の2つの方法のいずれかで行えます。

  • WLSAGENT_DISABLEDをtrueに設定するか、

  • WLSAGENT_DISABLEDをシステム・プロパティとして渡します

前提条件

必要に応じて WebLogic用のOAMセキュリティ・プロバイダの構成を行います。

IAMSuiteAgentの無効化手順

  1. IAMSuiteAgentをホスティングしているコンピュータ上で、次のタスクのいずれかを実行します。

    • WLSAGENT_DISABLEDをtrueに設定するか、

      setenv WLSAGENT_DISABLED true
      
    • DWLSAGENT_DISABLED=trueをシステム・プロパティとして渡します。

      -DWLSAGENT_DISABLED=true
      
  2. Webサーバーを再起動します。

  3. 「11g Webgateの集中ログアウト構成」に進んでから、「検証」に戻ります。

16.11.7 検証

11g Webゲートを使用してそれぞれの環境をテストし、IAMSuiteAgentで保護されていたすべてのアプリケーションが、10g Webゲートの構成後も保護されていることを確認するようお薦めします。

前提条件

「11g Webgateの集中ログアウト構成」

16.12 10g Webゲートでの優先ホストの管理

前の10gリリースでは、優先ホストは必須パラメータでしたが、構成によりオプションにできました。現在のAccess Managerの実装では、エージェント・プロファイルの優先ホスト・パラメータの値は、プロファイルの作成時に移入される必須フィールドです。したがって、Access Manager 10gからエージェント・プロファイルを移行すると、このパラメータの値がない可能性があります。移行されたエージェント・プロファイル内の優先ホストの値が空であるため、Access Manager 11gコンソールでは、管理者がエージェント・プロファイルを変更することはできません。現在の移行プロセスでは、このパラメータが空の場合の移行をサポートしていないため、移行プロセスに、次のアクションが組み込まれました。

  • 優先ホストの値を持たないエージェント・プロファイルの移行の際、AUTO_UPDATE_HOSTIDという値で定義されたホスト識別子が優先ホストとして設定されます。これは、11g Webゲートでも10g Webゲートでも機能します。


    注意:

    getClientConfigResponse()メソッドで、AUTO_UPDATE_HOSTIDホスト識別子は空の文字列に置換されるため、優先ホストはObAccessClient.xmlには設定されません。このような場合、WebゲートはHTTPヘッダーからホストを読み取ります。ユーザーはHTTPヘッダーを変更できるため、この脆弱性は次のように示されます。
    • 11g Access Managerコンソールには、優先ホストの値が空であることを示す赤いマークとともに、エージェント・プロファイルが表示されます。

    • エージェントのGetClientConfig()メソッドは、空の優先ホストがnullであることを示します。


  • ALLOWBLANKPREFERREDHOSTフラグが追加され、その値に基づくアクションが実行されます。trueに設定されている場合、優先ホストであるエージェントに空の文字列が送信されます。falseに設定されている場合、サーバーはエージェントに致命的エラーを送信します。

この機能の管理には、次の項で説明するsetAllowEmptyHostIdentifier WLSTコマンドを使用します。

16.12.1 setAllowEmptyHostIdentifier

空の優先ホスト・パラメータの使用を有効および無効にします。

16.12.1.1 説明

空の優先ホスト・パラメータの使用を有効または無効にします。(oam-config.xmlファイルに追加される)次のパラメータが、ObAccessClient.xmlファイル内の空の優先ホスト・パラメータを有効または無効にするために設定されます。

<Setting Name="AutoUpdateHostIdentifier" 
 Type="xsd:string">AUTO_UPDATE_HOSTID</Setting>
<Setting Name="AllowEmptyHostIdentifier" 
 Type="xsd:boolean">true</Setting>

16.12.1.2 構文

setAllowEmptyHostIdentifier(enable="true/false")
引数 定義
enable
空のホスト識別子を許可する場合はtrue、許可しない場合はfalseに設定します。

16.12.1.3

setAllowEmptyHostIdentifier(enable ="true")