| Oracle® Fusion Middleware Oracle Access Manager管理者ガイド 11g リリース1（11.1.1） B62265-01 |
|
 戻る |
 次へ |
登録されたポリシー強制エージェントだけが、OAM 11gの認証および認可サービスと通信することができます。OAM管理者は、保護するパートナ・アプリケーションをホスティングするコンピュータに存在するエージェントを登録する必要があります。パートナ・アプリケーションとは、認証機能をSSOプロバイダ（Oracle Access Manager 11g）に委任して、複数のリソースにアクセスする際にユーザーが再度認証しなくて済むようにするものです。
この章では、OAM管理コンソールを使用したエージェント登録および管理の実行を中心に説明します。この章の内容は次のとおりです。
この章のタスクを実行する前に、OAM管理consoleと管理対象OAMサーバーが実行中であることを確認してください。
この章にあるタスクのナレッジ・ベースの要件は、以下のとおりです。
「ポリシーの強制エージェントの概要」を見直してください。
OAM 10g WebGatesを登録する場合は、第17章「OAM 10g WebGatesとOAM 11gの管理」を見直してください。
この項では、アクセス・クライアント（ポリシー強制エージェント）と、エージェントとOracle Access Manager 11g SSO間の信頼メカニズムを設定するために必要な登録プロセスの情報を提供します。
Oracle Access Manager 11gでは、それぞれのポリシー強制エージェントはHTTPリクエストのフィルタとして機能します。デプロイメントには以下のエージェントを任意の組合せで含めることができます。
OAMエージェント:
OAM 11g WebGates
OAM 10g WebGates
OSSOエージェント: mod_ossoは、中央のOSSOサーバーでユーザーを認証する（まだサポートされている）OracleAS 10gシングル・サインオン（OSSO）ソリューションの一部です。
10g mod_ossoをエージェントとして登録した後、OAM 11gはリソースに定義されたOAMポリシーに関連付けられた認証スキームに基づいて、mod_ossoにユーザーのためのリダイレクトURLを渡します。
|
注意: mod_ossoモジュールは、OracleASアプリケーションに認証を提供するOracle HTTPサーバー・モジュールの一部です。 |
明示的に記述されてる場合を除いて、OAMエージェントの詳細はWebGatesとAccessGatesに均等に適用されます。
WebGateは設定不要のクライアントです。このWebサーバーのアクセス・クライアントは、WebリソースのHTTPリクエストを捕捉して、これらをOAM 11gサーバーに転送します。様々なWebサーバーのWebGatesは、Oracle Access Managerに同梱されています。
AccessGateは、Web以外のアプリケーション用に作成されたカスタムのアクセス・クライアントです。このカスタム・アクセス・クライアントは、具体的にソフトウェア開発キット（SDK）およびOracle Access Manager APIを使用して、ユーザーかオラクル社が開発する必要があります。AccessGateは、ユーザーやアプリケーションからのWebおよびWeb以外（非Web）のリソースのリクエストを処理するアクセス・クライアントの形態の1つです。
表5-1は、OAM 11gのすべてのエージェントに関する情報を示します。
表5-1 OAM 11gのエージェント
| エージェント | 説明 |
|---|---|
|
OSSOエージェント（mod_osso 10g） |
OAM 11gに登録された後、mod_ossoモジュールは以下の処理を行います。
|
|
11g WebGates |
OAM 11gへのインストールと登録が終わった後、11g WebGatesはOAMプロキシを使用してOracle Access Manager 11gサービスと通信し、リクエストを"掃除"して、すべてのエージェントに同じように応答します。 |
|
10g WebGates |
インストールおよび登録の後、OAM 10g WebGatesはブリッジとして機能するJavaベースのOAMプロキシを通じてOracle Access Manager 11gサービスと直接通信します。OAM 10g WebGatesには以下が含まれます。
この表の「IDMDomainAgent」も参照してください。 |
|
AccessGates |
AccessGatesでは認証と認可のみがサポートされています（ポリシー変更はサポート対象外です）。 |
|
IDMDomainAgent |
IDMドメイン・エージェントは、IDM管理コンソールにシングル・サインオン機能を提供します。IDMドメイン・エージェントは、Oracle Access Manager 11gサーバーのインストールおよび構成の一部としてインストールされ、あらかじめ構成されます。 |
表5-2は、OAM 11gと互換性のあるエージェント・タイプの比較、およびOAM 11gと以前のエージェントとの違いを説明しています（列ごとに記載）。
表5-2 エージェント・タイプの比較および違い
| OAM 11g | OAM 10g | OSSO 10g | |
|---|---|---|---|
|
使用可能なエージェント |
OAMエージェント
OSSOエージェント
|
WebGateとAccessGate
OAM 10gの場合、WebGateのインストールにはWebサーバーの構成が含まれていました。 |
|
|
リモート登録ツール |
OAM 11gとともに動作するエージェントの登録で使用可能。 |
OAM 11gとともに動作するエージェントの登録で使用可能。 注: OAM 10gではリモート登録に該当するものはありませんでした。 |
OAM 11gとともに動作するエージェントで使用可能。 注: OAM 11g以前はリモート登録に該当するものはありませんでした。 |
|
ログイン・フォーム |
/oam/pages/css/login_page.css |
10g WebGateで同梱され使用されたログイン・フォームは、OAM 11gには適していません。 |
変更なし |
|
logout.html |
10gおよび11gのエージェントのログアウトの構成について詳しくは、第11章を参照してください。 |
10g WebGateとOAM 11gを併用する場合、logout.htmlでは特定の詳細が必要です。第11章を参照してください。 |
mod_osso（OSSOエージェント）を持つOAM 11gでは変更は必要ありません。 動的ディレクティブを使用するアプリケーションは、mod_osso.confにエントリを必要としません。代わりに、1つまたは複数の動的ディレクティブとして保護がアプリケーションに書き込まれます。 |
|
複数のネットワーク・ドメインのサポート |
OAM 11gは、ネットワーク間ドメインの設定不要なシングル・サインオンをサポートします。 この場合は、Oracle Identity Federationを使用することをお薦めします。 |
OAMには、Oracle Identity Federationより前から存在する独自の複数ネットワーク・ドメインSSO機能があります。これがOAM 10gデプロイメントに実装されている場合、OAM 10gエージェントをOAM 11gに登録すればこのサポートを引き続き受けられます。 |
|
|
暗号化キー 注: インターネット上での情報交換の保護に使用されるプロトコル。 |
注: 登録されたmod_ossoまたは11g WebGateごと1つのキーが生成され、使用されます。ただし、すべての10g WebGatesで単一のキーが生成されます。 |
OAMデプロイメントごとにグローバルで共有される秘密鍵が1つあり、これがすべてのWebGatesで使用されます。 |
|
|
キー・ストレージ |
|
ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ（WebGateに対してはアクセス不可） |
|
管理者はOAM管理コンソールまたはリモート登録ツールを使用して、以下のことが行えます。
新しくインストールされたOAM 11gエージェントの登録
OAM 11gと使用するためのレガシー（または新しくインストールされた）OAM 10 WebGateのプロビジョニング。詳細は第17にあります。
OSSO 10gエージェント（mod_osso）の登録
|
注意: 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』の説明のとおりに、OracleAS 10g SSOをアップグレードできます。アップグレード中に、OSSOエージェントがOAM 11gに登録されます。「付録B「共存環境の概要: OAM 11gおよびOSSO 10g」を参照してください。 |
IDMドメイン・エージェントは、IDM管理コンソールにシングル・サインオン機能を提供します。IDMドメイン・エージェントは、Oracle Access Manager 11gサーバーのインストールおよび構成の一部としてインストールされ、あらかじめ構成されます。
IDMドメイン・エージェントは、ドメイン全体のエージェントです。
一度デプロイされると、IDMドメイン・エージェントはドメイン内のすべてのサーバーにインストールされます。
無効にしない限り、WebLogicアプリケーション・サーバーに入ってくるすべてのリクエストは、IDMドメイン・エージェントによって評価および処理されます。
構成の詳細は、OAM管理コンソールの「10g Webゲート」ノード（「ポリシー構成」タブ）の下にあります。
特定のIDMドメイン・エージェント構成の要素はWebLogic管理コンソール（「セキュリティ・プロバイダ」セクション）に、その他の要素はOAM管理コンソールにあります。
WebLogic管理コンソール、「セキュリティ・プロバイダ」の設定
WebLogic管理コンソールの「セキュリティ・プロバイダ」セクションには、ブートストラップ構成パラメータが5つあります。
これらは変更せずに保持することをお薦めしますが、以下のパラメータのいずれかを変更しなければならないときがあります。
プライマリ・アクセス・サーバー: この値は実際のOAMサーバーの情報に置換できます。デフォルト値（localhost:5575）は、複数のホストがIDMドメインの一部である場合、実際のOAMサーバーの情報と置換できます。 エージェント・パスワード: デフォルトではパスワードはありません。ただし、NetPoint（現在はOracle）のアクセス・プロトコル（NAPまたはOAP）を介したOAMサーバーへのIDMDomainAgent接続のパスワードを設定する場合は、ここで追加できます。
図5-2は、IDMドメイン・エージェントのデフォルトのセキュリティ・プロバイダ設定を示します。
OAM管理コンソール、IDMDomainAgent登録ページ
IDMDomainAgent登録ページは、他のすべてのOAMエージェント登録のページと似ています。
セキュリティ・モード: IDMDomainAgentで使用できるセキュリティ・モードはオープンのみです。これは変更できません。
優先ホスト: IDMDomainはこのエージェントで必要な、あらかじめ構成されたホストです。
|
注意: ここのアクセス・クライアント・パスワードは、WebLogic管理コンソールのエージェント・パスワードと一致する必要があります。エージェント・パスワードを変更した場合、アクセス・クライアント・パスワードも変更する必要があります。 |
図5-2は、IDMドメイン・エージェントのデフォルト構成の特性を示します。
少数の例外を除いて、エージェント登録の要素はすべて同じです。表5-3は大まかな違いを示します。すべての要素は、表5-6「展開されたOAM 11gおよび10g WebGateエージェントの要素とデフォルト」に記載されています。
表5-3
| 要素 | 11g Webgate | 10g WebGate | IDMDomainAgent |
|---|---|---|---|
|
プライマリCookieドメイン |
なし |
x |
x |
|
トークンの有効期間 |
x |
なし |
なし |
|
優先ホスト |
x |
x |
IDMDomain |
|
ログアウト・コールバックURL |
x |
なし |
なし |
|
ログアウト・リダイレクトURL |
x |
なし |
なし |
|
ログアウト・ターゲットURL |
x |
なし |
なし |
表5-4は、IDMドメイン・エージェントに保護されているリソースを示します。追加や変更は一切行わないことをお薦めします。WebLogic管理コンソール（/console/.../*）およびFusion Middleware Enterprise Manager（/em/.../*）は、保護されていません。
表5-4 IDMDomainAgentで保護されているリソース
| リソース | 説明 |
|---|---|
|
OAMコンソール |
/oamconsole/.../* |
|
OINAV |
/oinav/.../* |
|
APM |
/apm/.../* |
|
OAAMコンソール |
/oaam_admin/.../* |
|
LDAPSchemeを使用したOIMリソース |
/admin/faces/pages/Admin.jspx /oim/faces/pages/Self.jspx /oim/faces/pages/Admin.jspx /xlWebApp/.../* /Nexaweb/.../* |
|
OIMSchemeを使用したOIMリソース |
/admin/faces/pages/pwdmgmt.jspx |
|
AnonymousSchemeを使用したOIMリソース |
/oim/faces/pages/USelf.jspx /admin/faces/pages/forgotpwd.jspx /admin/faces/pages/accountlocked.jspx /admin/.../*.js /admin/.../*.css /admin/.../*.png /admin/.../*.gif /oim/.../*.js /oim/.../*.css /oim/.../*.png /oim/.../*.gif |
このエージェントは10g WebGateに置換することができます。詳細は第17章「OAM 10g WebGatesとOAM 11gの管理」に記載されています。
登録されたポリシー強制エージェントのみがOAMサーバーと通信することができ、保護されたリソースにユーザーがアクセスを試みるときに情報を処理します。
OAM管理者は、保護するアプリケーションをホスティングするコンピュータに存在するOAMエージェントまたはOSSOエージェントを登録する必要があります。アプリケーション・ドメインとデフォルトのポリシーを自動的に作成することで、エージェントの登録にパートナの登録を含めることができます。
登録の後、エージェントの詳細がOAM管理コンソールに表示され、クラスタ内のすべての管理対象サーバーに伝播されます。エージェント登録時にポリシーを自動作成するよう選択した場合、パートナ・アプリケーションに登録されたアプリケーション・ドメインとポリシーを表示、管理することもできます。
|
注意: エージェントの登録は、「パートナ・アプリケーションの登録」または「パートナ・アプリケーションのOAMへの登録」ともいいます。 |
登録時に、エージェントは自身が保護するアプリケーションと同じWebサーバー上にあると想定されます。ただし、エージェントがプロキシWebサーバー上にあったり、アプリケーションが異なるホスト上にあることも可能です。
エージェント登録時:
エージェントごとに1つのキーが生成され、クライアント・ホスト上のローカル・ウォレット・ファイルを介してWebGateから、サーバー側ではJavaキー・ストアを介してOAMサーバーからそれぞれアクセス可能になります。
エージェント固有のキーは、クライアント・マシン上の保護されたローカル・ストレージを介してWebGatesからアクセス可能である必要があります。表5-2を参照してください。
キーは、登録時にパートナ（アプリケーション）に対して生成されます。（ただし、10g WebGateエージェントを除きます）。
OAMアプリケーション・ドメインが作成されて、エージェントにちなんだ名称が付けられ、デフォルトの認証および認可ポリシーが移入されます。新しいアプリケーション・ドメインは、登録中にエージェントに対して指定されたものと同じホスト識別子を使用します。アプリケーション・ドメインの詳細については、第9章を参照してください。
登録の後、エージェントはWebサイトにアクセスする試みをモニターし、リクエストを完了する前にOAMサーバーを使用して認証および認可サービスを提供できます。管理者は、管理コンソールまたはカスタムのOAM 11g用WLSTコマンドを使用して、登録されたエージェントの閲覧や変更、削除を行えます。
詳細は以下を参照してください。
OAM管理コンソールを使用してエージェントを登録する際、OAM管理コンソールのホスト上でエージェントに新しいファイル・システム・ディレクトリが作成されます。
<MW_HOME>/user_projects/domains/<domain_name>/output/<agent_name>
この新しいディレクトリには、エージェントのインストール・ディレクトリにコピーする必要がある、登録済エージェントに生成されたファイルが格納されます。
11g WebGate: 生成されたファイルをWebGate_instance_dir/webgate/config（たとえば、WebTier_Middleware_Home/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config）にコピー
10g WebGate: 生成されたファイルをWebGate_install_dir/webgate/configにコピー
mod_osso: 生成されたファイルをOHS_webserver_dir/oracle/product /11.1.1/as_1/instances/instance1/config/OHS/ohs1/osso/にコピー
生成されたファイルには以下が含まれます。
ObAccessClient.xml（WebGatesの場合）
事前登録されたIDMドメイン・エージェントは、ブートストラップや構成にObAccessClient.xmlを使用しません。
OAM 10gでは、configureWebGateツールの実行時にエージェント側でObAccessClient.xmlが生成されていました。OAM 11gでは、管理コンソールまたはリモート登録ツールを使用して、ObAccessClient.xmlを作成できます。
cwallet.sso（トランスポート・セキュリティ・モードに関係なく11g WebGatesの場合）
安全な通信のための証明書とパスワード（必要な場合）。たとえば、password.xmlファイルやaaa_cert.pem、aaa_key.pemファイルなど。
|
注意: 11g WebGateの登録を編集する場合、モードがオープンから証明書、あるいは簡易から証明書に変わったときにだけpassword.xmlが更新されます。証明書モードでは、一度生成されるとpassword.xmlは更新できません。エージェントのキー・パスワードを編集しても、新しいpassword.xmlは作成されません。 |
osso.confファイル（OSSOエージェントの場合）
WebGateの起動前に、ObAccessClientファイルを、生成元の場所からWebGateインスタンスをホストするコンピュータ上のWebGateのインストール先ディレクトリにコピーします。
WebGateの実行時に、定期的な更新チェックの際に変更が発見されると、ObAccessClientファイルが自動的に更新されます。
最小限に暗号化されたファイルに格納される簡易モードのグローバル・パスフレーズ: password.xml
証明書モード:
PEMキーストア別名
PEMキーストア別名パスワード
この項では、管理コンソールを使用したOAMエージェントの管理方法について説明します。トピックは以下のとおりです。
|
関連項目: 必要に応じて以下の章を参照してください。 |
このトピックでは、OAM管理コンソールを使用したOAMエージェントの登録について説明します。
図5-3は、管理コンソールの「システム構成」タブの下にある「OAM 11gエージェントの作成」ページを示します。「OAM 11gエージェントの作成」ページには、同じ要素が含まれます。このページでは、登録を合理化するために最小限の情報が要求されます。アスタリスク（*）は必須の情報です。
このページには、要求された情報を入力する名前付きのテキスト・フィールドが含まれます。表5-5は、「OAM 11gエージェントの作成」ページの各要素を示します。これは、簡略化されたOAMリクエスト・テンプレートとリモート登録ツールを使用するときに要求される情報と同じです。詳細は第6章にあります。
表5-5 OAM 10gおよび11gエージェントの「OAMエージェントの作成」ページ
| OAMエージェントの要素 | 説明 |
|---|---|
|
エージェント名 |
このWebGateエージェントを識別する名称。ほとんどの場合、WebGateに使用されるWebサーバーをホストするコンピュータ名です。 注: エージェント名が存在する場合、エラーが発生して登録が失敗します。ホスト識別子が存在する場合、一意のエージェント・ベースURLが既存のホスト識別子に追加され、登録が先に進みます。 |
|
エージェント・ベースURL OAM 10gおよび11gエージェントではオプション。 |
エージェントのWebサーバーがインストールされるコンピューターのホストとポート。たとえば、http://my_host:port or https://my_host:portとなります。ポート番号はオプションです。 注: 特定のエージェント・ベースURLは、一度だけ登録できます。エージェント・ベースURLからWebGateがインストールされているWebサーバー・ドメイン（<hostidentifier>要素で指定）へのマッピングは、1対1です。ただし、1つのドメインが複数のエージェント・ベースURLを持つことができます。 |
|
アクセス・クライアント・パスワード |
このWebGateのオプションかつ一意のパスワードで、WebGateの登録時に割り当てられています。 登録されたWebGateがOAM 11gサーバーに接続するときは、認可されていないWebGatesがOAM 11gサーバーに接続してポリシー情報を取得しないように、認証にこのパスワードが使用されます。 |
|
エージェントとOAMサーバー間の通信トランスポート・セキュリティのレベル（これはOAMサーバーに指定したレベルと一致する必要があります）。
注: 簡易モードと証明書モード、DESアルゴリズムを使用した秘密鍵の暗号化の詳細については、付録Eを参照してください。 |
|
|
ホスト識別子 |
この識別子はWebサーバー・ホストを表します。 |
|
ポリシーの自動作成 |
エージェントの登録時に、認証と認可のポリシーを自動的に作成することができます。このオプションは、デフォルトでチェック（有効）されています。 デフォルト: 有効 注: ドメインとポリシーがすでに登録されている場合、それに新しいリソースを追加できます。このオプションを解除（チェックなし）すると、アプリケーション・ドメインやポリシーは自動的に生成されません。 |
|
保護されているリソース（URI）リスト |
保護されているアプリケーションのURI: /myapp/loginなど。保護されているアプリケーションの各URIは、保護されているリソース・リストの表の新しい行で指定する必要があります。 デフォルト: 2つのリソースがデフォルトで保護されます。 /.../* / デフォルトは、複数のディレクトリにまたがるゼロまたは複数の中間レベル内にある任意の文字シーケンスに一致します。 関連項目: 「リソースのURLについて」 |
|
パブリック・リソース（URI）リスト |
それぞれのパブリック・アプリケーションは、パブリック・リソース・リストの表の新しい行で指定する必要があります。 フィールドを追加して、パブリック・アプリケーションとリソースのURI値を入力してください。それぞれのURIは、パブリック・リソース・リストの表の新しい行で指定する必要があります。 |
エージェントの登録を合理化するために、追加の要素は非表示になり、デフォルト値が適用されます。管理コンソールでエージェントのページを閲覧または編集する場合、図5-4にあるように、すべての要素と値が表示されます。ほとんどの要素は、リモート登録ツールとともに拡張されたOAMテンプレートを使用する際に定義するものと同じです。詳細は第6章にあります。
表5-6は、展開された登録の要素をまとめています。ここに表示された追加設定は、OAMプロキシにより使用されます。ObAccessClient.xmlは、ここに記載されているようにOAM管理コンソールを使用するか、または第6章にあるようにリモート登録ツールを使用するかに関わらず、エージェントの登録後に値が移入されます。
表5-6 展開されたOAM 11gおよび10g WebGateエージェントの要素とデフォルト
| OAMエージェントの要素 | 説明 |
|---|---|
|
エージェント名 |
OAMエージェントの名称。 |
|
オプションで一意のOAMエージェントのパスワード。エージェントがOAMサーバーに接続する場合、サーバーに対して自身を認証するときにこのパスワードを使用します。これによって、認可されていないエージェントが接続してポリシー情報を取得するのを防ぎます。 |
|
|
10g WebGateのみ。 |
このパラメータは、OAMエージェントがデプロイされるWebサーバー・ドメインを記述します。たとえば、acompany.comなどです。 Webサーバーでシングル・サインオンを有効にするために、cookieドメインを構成する必要があります。特に、シングル・サインオンを構成する対象のWebサーバーには、同じプライマリCookieドメインの値が必要です。OAMエージェントは、ObSSOCookie認証cookieを作成するためにこのパラメータを使用します。 このパラメータは、どのWebサーバーがcookieドメイン内に参加し、ObSSOCookieを受信して更新する権限を持つかを定義します。このcookieドメインは、ObSSOCookieの移入には使用されません。むしろ、ObSSOCookieがどのドメインに対して有効か、どのWebサーバーがObSSOCookieのコンテンツを受け入れて変更する権限があるかを定義します。 デフォルト: 登録時にクライアント側のドメインが確定できる場合、この値が「プライマリCookieドメイン」に移入されます。ただし、ドメインが見つからない場合は値はなく、WebGateはホスト・ベースのcookieを使用します。 注: ドメイン名が一般的であるほど、シングル・サインオンの実装がより包括的になります。たとえば、b.comをプライマリcookieドメインに指定した場合、ユーザーはb.comとa.b.com上のリソースに対してシングル・サインオンを実行できるようになります。しかし、a.b.comをプライマリcookieドメインに指定すると、ユーザーはb.com上のリソースをリクエストする場合、再び認証しなければならなくなります。 |
|
OAM管理コンソールでのみ設定します。 |
OAMエージェントが有効か無効かを指定します。 デフォルト = 有効 |
|
キャッシュ内の要素の数。以下のキャッシュ要素があります。 この設定の値は、これら両方のキャッシュの要素の最大合計カウントを参照します。 デフォルト = 100000 |
|
|
キャッシュ化された情報が、使用されなかったり参照されない場合に、OAMエージェントのキャッシュ内に残る時間。 デフォルト = 1800（秒） |
|
|
11g WebGateのみ |
エージェント・トークンの最大有効時間（11g WebGateのOAMAuthnCookieのコンテンツ）。10g WebGatesのtokenValidityPeriodフィールドに該当するものは、cookieSessionTimeと呼ばれます。 デフォルト = 3600（秒） 注: OAM 10g WebGatesの場合、トークンの有効期間を設定するには、Cookieセッション時間を使用してください。 |
|
このOAMエージェントがOAMサーバーと確立できる最大接続数。この数値は、実際にこのエージェントと関連付けられる接続数と同じか、それ以上でなければなりません。 デフォルト = 1 |
|
|
アクティビティに関わらず、ユーザーの認証セッションが有効な最大時間（秒）。このセッション時間が終了すると、ユーザーは認証をやり直すことになります。これは強制的なログアウトです。 デフォルト = 24（時間） 値0を指定すると、このタイムアウト設定は無効になります。 |
|
|
このOAMエージェントが、接続をセカンダリOAMサーバーに開くポイントを表す数値。 デフォルト = 1 たとえば、このフィールドに30と入力して、プライマリOAMサーバーへの接続数が29の場合、このOAMエージェントはセカンダリOAMサーバーへの接続を開きます。 |
|
|
OAMサーバーからの応答を待つ時間（秒）。このパラメータが設定されている場合、デフォルトのTCP/IPタイムアウトではなく、アプリケーションのTCP/IPタイムアウトとして使用されます。 デフォルト = -1（デフォルトのネットワークTCP/IPタイムアウトが使用されます） このパラメータの一般的な値は、30秒から60秒です。非常に低い値に設定された場合、アクセス・サーバーからの応答を受信する前にソケット接続が閉じられ、エラーとなる可能性があります。 たとえば、OAMエージェントが1つのプライマリOAMサーバーと1つのセカンダリOAMサーバーに通信するように構成されているとします。ネットワークのワイヤーがプライマリOAMサーバーから引き抜かれた場合、OAMエージェントはプライマリOAMサーバーへの接続がないことを知るために、TCP/IPタイムアウトの間だけ待ちます。WebGateは、プライマリ・アクセス・サーバーから開始して、使用可能なサーバーへの接続を再度確立しようとします。このときも、接続が確立可能かどうかを判断するために、OAMエージェントはTCP/IPタイムアウトの間だけ待機します。確立できない場合は、リストの次のサーバーが試されます。別のOAMサーバー（プライマリまたはセカンダリ）への接続が確立できる場合、リクエストは再ルーティングされます。ただし、これは予想以上に長くかかることがあります。 新しい接続を検索する際、OAMエージェントは使用可能なサーバーのリストを、構成で指定した順に確認します。プライマリOAMサーバーが1つとセカンダリOAMサーバーが1つずつ指定されていて、プライマリOAMサーバーの接続がタイムアウトした場合、OAMエージェントはまだプライマリOAMサーバーを先に試します。結果的に、OAMエージェントはOAMサーバー・タイムアウトのしきい値設定の2倍を超える期間だけ、リクエストをOAMサーバーに送信できません。 OAMサーバーがリクエストにサービスを提供するのに、タイムアウトのしきい値よりも長い時間がかかる場合、OAMエージェントはリクエストを放棄して、新しい接続でそのリクエストをやり直します。接続プールから返された新しい接続は、接続プールに設定に応じて、同じOAMサーバーへのものとなることがあります。また、しきい値で指定された時間よりも、他のOAMサーバーがリクエストの処理に時間がかかることもあります。この場合、OAMエージェントはOAMサーバーが停止するまで、リクエストを引き続き再試行できます。 |
|
|
アイドル・セッション・タイムアウト 10g WebGatesのみ |
デフォルト: 3600 リリース7.0.4のWebGatesは、独自のアイドル・セッション・タイムアウトのみを強制していました。 10.1.4.0.1 WebGatesは、トークンが訪問したすべてのWebGatesの中で、最も制限の多いタイムアウト値を強制しました。 10g（10.1.4.3）では、この要素のデフォルトとして、7.0.4の動作が復活しました。 idleSessionTimeoutLogicを設定する手順
|
|
優先ホスト |
ユーザーが保護されたWebサーバーにアクセスしようとしたときに、すべてのHTTPリクエストでホスト名がどう表示されるかを指定します。HTTPリクエスト内のホスト名は、ユーザーのHTTPリクエストでどのように定義されたかに関係なく、このフィールドに入力された値に変換されます。 優先ホストの機能によって、ホストの識別子がホスト識別子リストに含まれていない場合に間違って作成される可能性があるセキュリティ・ホールを防止します。ただし、仮想Webホスティングでは使用できません。仮想ホスティングの場合、ホスト識別子の機能を使用する必要があります。 |
|
保護されていない場合に拒否 |
アクセスがルールやポリシーによって明示的に許可されていないすべてのリソースへのアクセスを却下します。 11g WebGateの登録では常に有効化されており、変更はできません。 10g WebGate登録ページで、これを無効にするよう選択できます。 |
|
ログアウトURL |
ログアウトURLは、ログアウト・ハンドラをトリガーします。これは、cookie（10g WebGatesではObSSOCookie、11g WebGatesではOAMAuthnCookie）を削除して、ユーザーが次回Oracle Access Managerにより保護されたリソースにアクセスするときに、再認証を義務付けます。
デフォルト = 注: これは初回のログアウトをトリガーするときに使用される、標準のOAM 10g WebGate構成パラメータです。 関連項目: OAM 11gに登録されたOAM 10g WebGatesでのログアウトの構成に必要なその他の手順については、第11章 |
|
11g WebGateのみのその他のログアウト |
OAM 11g WebGateシングル・サインオンの動作については、特定のログアウト要素と値によって、中心のログアウトURL、コールバックURLおよびend_URLへのリダイレクトが自動化されます。これは、カスタマイズされたローカルのログアウト・ページからのみ、10g WebGateのシングル・サインオンを置き換えます。 |
|
ログアウト・コールバックURL 11g WebGateのみ |
oam_logout_successのURL。コールバック時にcookieを消去します。host:port（推奨）を持たないURIフォーマットを使用できます。この場合、OAMサーバーは元のリソース・リクエストのhost:portをコールバックします。例: デフォルト = /oam_logout_success host:portを持つ完全なURLフォーマットを使用できます。この場合、OAM 11gサーバーはコールバックURLを再構築せずに、直接コールバックします。 リクエストURLがログアウト・コールバックURLに一致したとき、WebGateは自身のcookieを消去してレスポンスでgifイメージをストリーミングします。これはOSSOエージェントの動作に似ています。 WebGateがサーバーのログアウト・ページにリダイレクトすると、"end" URLが問合せパラメータ（ 他のOAM 11gサービスは、サーバー上の中央のログアウト・ページをサポートします。end_urlは、OPSSが統合されたアプリケーションから渡されるターゲットURLの問合せパラメータに依存します。 |
|
ログアウト・リダイレクトURL 11g WebGateのみ |
このパラメータは、エージェントの登録が完了した後に自動的に移入されます。デフォルトでは、これはOAMサーバーのホスト名とデフォルトのポート14200に基づきます。たとえば以下のようになります。 デフォルト = http://OAMServer_host:14200/oam/server/logout ログアウトURLは、ログアウト・ハンドラをトリガーします。これは、OAMAuthnCookie_<host:port>_<random number>を削除して、ユーザーが次回Oracle Access Managerにより保護されたリソースにアクセスするときに、再認証を義務付けます。 |
|
ログアウト・ターゲットURL 11g WebGateのみ |
この値は、ログアウト中にOPSSアプリケーションがWebGateに渡す問合せパラメータの名称です。問合せパラメータは、ログアウト完了後に移動するページのターゲットURLを指定します。 デフォルト: end_url |
|
プライマリ・サーバー・リスト |
このエージェントのプライマリ・サーバー・リストを識別します。デフォルトは、OAMサーバーに基づきます。
|
|
セカンダリ・サーバー・リスト |
このエージェントのセカンダリOAMサーバーの詳細を識別します。手動で指定する必要があります。
|
有効なOAM管理者の資格証明を持つユーザーは、以下の手順を実行して、管理者コンソールによりOAMエージェントを検索できます。
前提条件
WebGateは、Oracle Access Manager 11gの登録されたエージェントである必要があります。
OAMエージェント登録を検索する手順
「システム構成」タブをアクティブ化します。
検索タイプ・リストから、適切なタイプ（10g Webgatesまたは11g Webgates）を選択して、検索を定義します。
テキスト・フィールドに、検索するインスタンスの正確な名称を入力します。例:
my_OAM_Agent
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、以下を実行します。
編集: ツール・バーの「編集」コマンド・ボタンをクリックし、構成ページを表示します。
削除: ツール・バーの「削除」ボタンをクリックして、インスタンスを削除し、「確認」ウィンドウで削除を確認します。
デタッチ: 表を1ページ全面に展開するには、ツール・バーの「デタッチ」をクリックします。
表示: 結果表の外観を変更するには、「表示」メニューの項目を選択します。
検索結果の処理を完了してナビゲーション・ツリーに戻るには、「参照タブをクリックします。
WebGateエージェントは、インストールする前に登録できます。有効なOAM管理者の資格証明を持つユーザーは、以下のタスクを実行して、管理者コンソールによりOAMエージェントを登録できます。
|
注意: エージェント登録時には、少なくとも1つのOAMサーバー・インスタンスが、エージェントと同じモードで実行中である必要があります。そうでなければ、エージェント登録が失敗します。 |
エージェント登録の後に、必要があればOAMサーバーの通信モードを変更できます。エージェントとサーバー間の通信は、WebGateモードがOAMサーバーのモードと同じか、またはそれ以上であれば続けて機能します。付録Eを参照してください。
前提条件
少なくとも1つのOAMサーバーが、登録するエージェントと同じモードで実行中であることを確認してください。
WebGateエージェントを登録する手順
通常のようにOAM管理コンソールにログインします。
OAM管理コンソールの「ようこそ」ページの「エージェント構成」パネルで、次のリンクのいずれかをクリックして、新しいページを開きます。
OAM 11gエージェントの追加
OAM 10gエージェントの追加（第17章も参照）
または、「システム構成」タブから、「エージェント」ノード、「OAMエージェント」、さらに「11g Webゲート」または「10g Webゲート」ノードを展開してから、ツール・バーのコマンドの作成ボタンをクリックします。
「OAMエージェントの作成」ページで、表5-5にあるように、必要な詳細（*の付いたもの）を入力して、このOAMエージェントを登録します。
保護されているリソース・リスト: この表では、表5-5にあるように、このOAMエージェントで保護する個々のリソースのURLを入力します。
パブリック・リソース・リスト: この表では、表5-5にあるように、パブリックにする（保護しない）個々のリソースのURLを入力します。
「適用」をクリックして、登録を送信します（または変更を適用しないでページを閉じます）。
「確認」ウィンドウで、生成されたアーティファクトの場所を確認し、ウィンドウを閉じます。
ナビゲーション・ツリーで、エージェント名がリストされていることを確認します。
以下の手順を実行して、アーティファクトをWebGateのインストール先ディレクトリにコピーします（またはWebGateをインストールしてから、これらのアーティファクトをコピーします）。
OAM管理コンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml（およびすべての証明書アーティファクト）を検索します。例:
$DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml
OAMエージェントのホストで、アーティファクトを（以下のWebGateディレクトリ・パスに）コピーします。例:
エージェントをホストするOAMサーバーを再起動して、第III部「シングル・サインオン、ポリシー、およびテスト」に進みます。
有効なOAM管理者の資格証明を持つユーザーは、以下に説明する手順にあるように、管理コンソールを使用して、登録済のOAMエージェントのあらゆる設定を変更できます。たとえば、タイムアウトのしきい値やOAMプロキシで使用される他の設定を変更する場合などです。
変更後は、更新された詳細はランタイムの構成更新プロセスによって伝播されます。通常は、アーティファクトをWebGateの構成領域にコピーする必要はありません。
|
注意: アーティファクトは、エージェント名やアクセス・クライアントのパスワード、セキュリティ・モードが変更になった場合にだけ、WebGateディレクトリ・パスにコピーする必要があります。 |
前提条件
エージェントがOracle Access Manager管理コンソールに登録されて、使用可能である必要があります。
登録されたWebGateエージェントの詳細を閲覧または変更する手順
「システム構成」タブから、ナビゲーション・ツリーで必要に応じて次のノードを展開します。
希望するエージェント名をダブルクリックして、登録のページを表示します。
「適用」をクリックして変更を送信し、「確認」ウィンドウを閉じます（または変更を適用しないでページを閉じます）。
必要があれば、以下の手順を実行してアーティファクトをコピーします。
|
注意: アーティファクトは、エージェント名やアクセス・クライアントのパスワード、セキュリティ・モードが変更になった場合にだけ、WebGateディレクトリ・パスにコピーする必要があります。OAM 10g WebGateをプロビジョニングする場合は、第17章を参照してください。 |
OAM管理コンソールのホストで、更新されたOAMエージェントの構成ファイルObAccessClient.xml（およびすべての証明書アーティファクト）を検索します。例:
$DOMAIN_HOME/output/$Agent_Name/ObAccessClient.xml
OAMエージェントのホストで、アーティファクトを（以下のWebGateディレクトリ・パスに）コピーします。例:
エージェントをホストするOAMサーバーを再起動して、第III部「シングル・サインオン、ポリシー、およびテスト」に進みます。
必要があれば、付録E「OAM 11gとの通信の保護」を参照してください。
有効なOAM管理者の資格証明を持つユーザーは、以下の手順を実行して、管理者コンソールにより登録されたOAMエージェントを削除できます。
|
注意: エージェントの登録を削除すると、登録（関連のホスト識別子、アプリケーション・ドメイン、リソース、エージェント自身を含みません）のみが削除されます。 |
前提条件
このエージェントに関連するアプリケーション・ドメイン、リソースおよびポリシーを評価して、これらが別のエージェントを使用するように構成されていることや、削除可能なことを確認します。
OAMエージェントの登録を削除する手順
「システム構成」タブから、ナビゲーション・ツリーで以下を展開します。
オプション: 希望するエージェント名をダブルクリックして登録を閲覧してから、ページを閉じます。
希望するエージェント名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。
エージェント名がナビゲーション・ツリーにないことを確認します。
WebGateインスタンスの削除: 以下の手順を実行すると同時に、必要があれば「OAM 11gデプロイメントからの10g WebGateの削除」を参照してください。
Webサーバーを停止します。
以下のディレクトリ・パスに用意されているユーティリティを使用して、WebGateソフトウェアを削除します。
$WebGate_install_dir/oui/bin
Windows: setup.exe -d Unix: runInstaller -d
WebGateのアップデート前のhttpd.confバージョンに戻します。例:
コピー内容: httpd.conf.ORIG
コピー先: httpd.conf
Webサーバーを再起動します。
エージェントのホストで、WebGateのインスタンス・ディレクトリを手動で削除します。例:
この項では、管理コンソールを使用したOSSOエージェント登録（mod_osso）の管理方法について説明します。詳細は以下を参照してください。
OSSOエージェントとは、OSSOサーバーのパートナ・アプリケーションとして機能し、リソースを保護するOracle HTTPサーバー上にデプロイされた任意のmod_ossoモジュールです。
OSSOプロキシは、OAMとOSSOエージェント間の相互運用性をサポートします（OSSOエージェントを使用して、OAMエージェントのために作成された有効なSSOセッション、あるいはSSOセッションのために作成された有効なOAMエージェントにアクセスします）。
| OSSOプロキシのサポート対象 | 説明 |
|---|---|
| SSOログイン | OSSOエージェントからOAMサーバー（およびOSSO固有のトークン） |
| SSOログアウト | OSSOエージェントからOAMサーバー |
| OSSOエージェントのリクエストおよびプロトコル | OSSOプロキシは、OSSOプロトコルをOracle Access Manager 11gサービスのプロトコルに変換します。 |
このトピックでは、管理コンソールを使用したOSSOエージェントの登録について説明します。
|
注意: OSSOエージェントを登録する前に、Oracle HTTPサーバーがクライアント・コンピュータ上にインストールされて、mod_ossoにWebサーバーが構成済であることを確認してください。 |
図5-5は、管理コンソールの「システム構成」タブの下にある「OSSOエージェントの作成」ページを示します。
「OSSOエージェントの作成」ページでは、必要な情報にアスタリスク（*）で印が付けられています。表5-7 は、新しいエージェントを登録する際に指定できる必須およびオプションの詳細を示します。
表5-7 「OSSOエージェントの作成」ページの要素
| 要素 | 説明 |
|---|---|
|
エージェント名 |
このmod_ossoエージェントを識別する名称。 |
|
エージェント・ベースURL OSSOエージェントで必須です。 |
必要なプロトコル、ホスト、およびエージェントのWebサーバーがインストールされるコンピューターのポート。たとえば、http://host:portまたはhttps://host:portなどです。 注: ホストとポートは、展開された登録のデフォルトとして使用されます。表5-8を参照してください。 |
|
管理者ID |
このmod_ossoインスタンスの管理者のログインID（オプション）。たとえば、SiteAdminなどです。 |
|
管理者情報 |
このmod_ossoインスタンスの管理者の詳細（オプション）。たとえば、アプリケーション管理者などです。 |
|
ホスト識別子 |
ホスト識別子は、エージェント名に基づいて自動的に入力されます。 |
|
ポリシーの自動作成 |
エージェントの登録時に、認証と認可のポリシーを自動的に作成することができます。このオプションは、デフォルトでチェック（有効）されています。 OSSOプロキシには、汎用のURL（/.../*）を持ったリソースを含み、LDAPスキーム（デフォルト）に基づくポリシーに保護されているアプリケーション・ドメインが必要です。サーバー側で汎用のURLが使用されるのは、このためです。 デフォルト: 有効 注: ドメインとポリシーがすでに登録されている場合、それに新しいリソースを追加できます。このオプションを解除（選択解除）すると、アプリケーション・ドメインやポリシーは自動的に生成されません。 |
エージェントの登録を合理化するため、いくつかの要素は非表示にされ、コンソールで登録時にはデフォルト値が使用されます。エージェントの登録ページを管理コンソールで閲覧すると、すべての要素と値が表示されます。
図5-6は、管理コンソールで見た場合のエージェント・ページ全体を示します。「確認」ウィンドウはそのまま表示されます。指定された詳細のすべてとデフォルト値が表示されます。
表5-8は、OSSOエージェントで使用される展開済の要素とデフォルトの概要を示します。
表5-8 展開されたOSSOエージェントの要素
| 要素 | 説明 |
|---|---|
|
トークン・バージョン |
このトークンのバージョンは3.0です。これは編集できません。 |
|
サイト・トークン |
認証をリクエストする際にパートナにより使用されるアプリケーション・トークン。これは編集できません。 |
|
成功URL |
認証が成功したときに使用されるリダイレクトURL。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポート上のosso_login_successが使用されます。例: デフォルト: http://myhost:5678/osso_login_success |
|
失敗URL |
認証が失敗したときに使用されるリダイレクトURL。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポート上のosso_login_failureが使用されます。 デフォルト: http://myhost:5678/osso_login_failure |
|
開始日 |
アプリケーションへのログインがサーバーにより許可される第1日目の年月日。 デフォルト: エージェントの登録日。 |
|
ホームURL |
認証後にホーム・ページとして使用されるリダイレクトURL。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポートが使用されます。 デフォルト: http://myhost:5678 |
|
ログアウトURL |
ログアウトするときに使用されるリダイレクトURL。これは、ユーザーをサーバー上のグローバル・ログアウト・ページにリダイレクトします: osso_logout_success。デフォルトでは、エージェント・ベースURLにより指定される完全修飾されたホストおよびポートが使用されます。 デフォルト: http://myhost:5678/osso_logout_success 関連項目: 「一元化されたOAM 11gのログアウトの概要」。 |
有効なOAM管理者の資格証明を持つユーザーは、以下の手順を実行して、管理者コンソールによりOSSOエージェントを検索できます。
前提条件
OSSOエージェントがOracle Access Manager管理コンソールに登録されて、使用可能である必要があります。
OSSOエージェント登録を検索する手順
「システム構成」タブをアクティブ化します。
検索タイプのリストから、OSSOエージェントのタイプを選択して検索を定義します。
テキスト・フィールドに、検索するインスタンスの正確な名称を入力します。例:
my_OSSO_Agent
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、以下を実行します。
編集: ツール・バーの「編集」コマンド・ボタンをクリックし、構成ページを表示します。
削除: ツール・バーの「削除」ボタンをクリックして、インスタンスを削除し、「確認」ウィンドウで削除を確認します。
デタッチ: 表を1ページ全面に展開するには、ツール・バーの「デタッチ」をクリックします。
表示: 結果表の外観を変更するには、「表示」メニューの項目を選択します。
検索結果の処理を完了してナビゲーション・ツリーに戻るには、「参照タブをクリックします。
有効なOAM管理者の資格証明を持つユーザーは、以下の手順を実行して、管理者コンソールによりOSSOエージェントを登録できます。
前提条件
Oracle HTTPサーバーがクライアント・コンピュータにインストールされて実行中であり、mod_ossoに対して構成されていることを確認してください。
OSSOエージェントを登録する手順
通常のようにOAM管理コンソールにログインします。
「ようこそ」ページから、「エージェント構成」パネルで以下のリンクをクリックして、新しいページを開きます。
OSSOエージェントの追加
または、「システム構成」タブから、「エージェント」ノードと「OSSOエージェント」ノードを展開し、ツール・バーの「作成」ボタンをクリックします。
ツール・バーで「作成」ボタンをクリックします。
「OAMエージェントの作成」ページで、表5-7にある必要な詳細を入力します。
エージェント名
エージェント・ベースURL
「OAMエージェントの作成」ページで、オプションの詳細を入力します（表5-7を参照）。
「適用」をクリックして、登録を送信します（または変更を適用しないでページを閉じます）。
「確認」ウィンドウで、生成されたアーティファクトのパスを確認し、ウィンドウを閉じます。例:
Artifacts are generated in following location : /.../base_domain/output/OSSO1
更新されたosso.confファイルをOSSOエージェントのホストにコピーします。
OAM管理コンソールのホストで、更新されたOSSOエージェントのosso.confファイルを検索します。例:
$DOMAIN_HOME/output/$Agent_Name/osso.conf
OSSOエージェントのホストで、osso.confをmod_ossoディレクトリ・パスにコピーします。
$OHS_dir/osso.conf
OSSOをホストするOAMサーバーを再起動します。
有効なOAM管理者の資格証明を持つユーザーは、以下に説明する手順にあるように、管理コンソールを使用して、登録済のOSSOエージェントのあらゆる設定を変更できます。たとえば、終了日を変更したり、管理者の情報を追加する場合があります。
前提条件
Oracle HTTPサーバーがクライアント・コンピュータにインストールされて実行中であり、mod_ossoに対して構成されていることを確認してください。
OSSOエージェント登録の閲覧または変更の手順
「システム構成」タブから、ナビゲーション・ツリーで「エージェント」ノードを展開します。
「OSSOエージェント」ノードを展開して、希望するエージェント名をダブルクリックし、登録のページを表示します。
「適用」をクリックして変更を送信し（または変更を適用せずにページを閉じます）、「確認」ウィンドウを閉じます。
更新されたosso.confファイルをOSSOエージェントのホストにコピーします。
OAM管理コンソールのホストで、更新されたOSSOエージェントのosso.confファイルを検索します。例:
$DOMAIN_HOME/output/$Agent_Name/osso.conf
OSSOエージェントのホストで、osso.confをmod_ossoディレクトリ・パスにコピーします。
$OHS_dir/osso.conf
OSSOエージェントをホストするOAMサーバーを再起動して、第III部「シングル・サインオン、ポリシー、およびテスト」に進みます。
有効なOAM管理者の資格証明を持つユーザーは、以下の手順を実行して、管理者コンソールにより登録されたOSSOエージェントを削除できます。
|
注意: エージェントの登録を削除すると、登録（関連のホスト識別子、アプリケーション・ドメイン、リソース、エージェント・インスタンス自身を含みません）のみが削除されます。 |
前提条件
このエージェントに関連するアプリケーション・ドメイン、リソースおよびポリシーを評価して、これらが別のエージェントを使用するように構成されていることや、削除可能なことを確認します。
OSSOエージェントの登録を削除する手順
「システム構成」タブから、ナビゲーション・ツリーで「エージェント」ノードを展開します。
「OSSOエージェント」ノードを展開します。
オプション: 希望するエージェント名をダブルクリックして、登録ページを表示します。これが削除するエージェントであることを確認し、ページを閉じます。
エージェント名をクリックして、ツール・バーで「削除」ボタンをクリックし、「確認」ウィンドウで削除を確認します。
