| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
前 |
次 |
Oracle Access Manager 11gには、パートナ登録を効率化するコマンドライン・ユーティリティが用意されています。ネットワーク内の管理者はリモート登録ツールを使用して、テンプレートでWebgateパラメータおよび値を指定できます。ネットワーク外の管理者は、ネットワーク内の管理者に情報を提供するユーティリティを使用できます。
この章では、コマンドライン・ユーティリティを使用したパートナ登録の実行を中心に説明します。この章の内容は次のとおりです。
この章のタスクを実行する前に、Oracle Access Managerコンソールと管理対象OAMサーバーが稼動していることを確認してください。
Oracle Access Manager認証および認可サービスと通信するには、サポートされているポリシー施行エージェントをOracle Access Manager 11gに登録する必要があります。パートナ・アプリケーション(認証機能をOracle Access Manager SSOプロバイダに委任して複数のリソースのアクセス時のユーザーの再認証を省略するアプリケーション)も登録する必要があります。
Oracle Access Manager 11gでアプリケーションを保護するには、Oracle Access Managerコンソールに登録されたOAMエージェント(Webgate)またはOSSOエージェント(mod_osso)と、特定の認証ポリシーおよび認可ポリシーでアプリケーションを保護するように構成されているアプリケーション・ドメインが必要です。
次のコマンドライン登録機能がサポートされています。
次の管理者によるアプリケーション・ドメインのセキュアな登録および作成
帯域内の管理者(エージェントをホストするWebサーバーを管理するネットワーク内の管理者)
帯域内の管理者は、登録タスクに登録ツールまたはOracle Access Managerコンソールを使用できます。この章では、コマンドライン登録に焦点を当てています。
帯域外の管理者(ネットワーク外の管理者)
ネットワーク外の管理者は、登録リクエストをネットワーク内の管理者に送信する必要があります。リクエストを処理した後、帯域内の管理者は、ファイルを使用して環境を構成する帯域外の管理者に必要なファイルを戻します。
パートナ・アプリケーションごとの対称キーの生成
登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成および使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。
レガシー・システムと下位互換性のある以前のOracle Access Manager WebgateおよびOSSOエージェントの登録が用意されています。詳細は、Oracle Technology Networkの動作保証マトリックスを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
次のリストの機能はサポートされていません。
キーおよびエージェント情報の永続性
Oracle Access Manager内部コンポーネントで使用されるキーの生成
エージェント情報を読み取るAPIサポート
詳細は、次の項を参照してください。
登録ツールを使用してパートナ・アプリケーションをプロビジョニングする帯域内のWebサーバーの管理者タスクの概要は、次のとおりです。リソースを保護するOAMエージェント(Webgate)またはOSSOエージェント(mod_osso)の使用の有無に関係なく、タスクは同じです。
|
注意: mod_ossoは、認証にOracleASアプリケーションを提供するOracle HTTP Serverモジュールです。ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onで保護されるアプリケーションを有効化してユーザー名およびパスワードのかわりにHTTPヘッダーを受け入れるOracle HTTP Serverにこのモジュールが存在します。これらのヘッダーの値がmod_osso Cookieに格納されます。 |
mod_ossoモジュールは、パートナ・アプリケーションの統合に以前のリリースのOracleAS Single Sign-Onで使用されたシングル・サインオンSDKに置き換わります。アプリケーション・サーバーに格納されるmod_ossoは、シングル・サインオン・サーバーの唯一のパートナ・アプリケーションとして認証プロセスを簡易化します。このため、mod_ossoは、OracleASアプリケーションに透過的な認証を実現します。これらのアプリケーションの管理者は、アプリケーションをSDKに統合する負担がなくなります。ユーザーの認証後、mod_ossoは、ユーザーの認可にアプリケーションで使用される可能性のある単純なヘッダー値を送信します。
ユーザー名
ユーザーGUID(グローバル・ユーザー・アイデンティティ)
言語および地域
この概要の「管理者」という用語は、Oracle Access Managerに登録されるデフォルト・システム・ユーザーのアイデンティティ・ストアの管理者に指定されるLDAPグループの一部であるネットワーク内のユーザーを示します。
タスクの概要: リモート登録を実行する帯域内の管理者
Oracle Access Manager 11gリリース1(11.1.1)登録ツールを取得します(「登録ツールの取得および設定」を参照してください)。
エージェントおよびアプリケーション・ドメインの一意の値で入力ファイルを更新します(「登録リクエストの作成」を参照してください)。
登録ツールを実行してエージェントを構成し、リソースのデフォルトのアプリケーション・ドメインを作成します(「帯域内リモート登録の実行」を参照してください)。
構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。
アクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。
帯域外登録という用語は、帯域内および帯域外の管理者の両方の調整およびアクションを含む手動登録を示します。
タスクの概要: 帯域外リモート登録(ネットワーク外のエージェント)
帯域外の管理者は、特定のアプリケーションおよびエージェントの詳細を含む開始リクエストの入力ファイルを作成し、帯域内の管理者に送信します。
Oracle Access Manager 11g登録ツールを取得します(「登録ツールの取得および設定」を参照してください)。
テンプレートをコピーおよび編集して、エージェントおよびアプリケーション・ドメインの一意の値を入力します(「登録リクエストの作成」を参照してください)。
選択した方法(電子メールまたはファイル転送)を使用して、開始リクエストの入力ファイルを帯域内の管理者に送信します。
帯域内の管理者の手順
Oracle Access Manager 11g登録ツールを取得します(「登録ツールの取得および設定」を参照してください)。
登録ツールで帯域外の開始リクエストを使用してエージェントをプロビジョニングし、次のファイルを作成して帯域外の管理者に戻します。次のファイルの詳細は、「帯域内リモート登録の実行」を参照してください。
agentName_Response.xmlは帯域外の管理者用に生成され、手順3で使用されます。
Webgateエージェントには、帯域外の管理者が使用してWebgateをブートストラップできる変更されたObAccessClient.xmlファイル(および11g Webgateのcwallet.ssoファイル)が作成されます。
SSOウォレットの作成は、OAM 10gエージェントやOSSOエージェントではなくOAM 11g Webgateにのみ適用されます。
OSSOエージェントには、帯域外の管理者がOSSOモジュールをブートストラップするために変更されたosso.confファイルが作成されます。
帯域外の管理者は、agentName_Response.xmlファイルと一緒に登録ツールを使用し、エージェント構成および他の生成されたアーティファクトを適切なファイル・システム・ディレクトリにコピーします。
帯域内の管理者は、構成を検証します(「リモート登録およびリソース保護の検証」を参照してください)。
帯域外の管理者は、いくつかのアクセス・チェックを実行して構成が有効なことを検証します(「リモート登録後の認証、リソース保護およびアクセスの検証」を参照してください)。
登録方式(Oracle Access Managerコンソールおよびリモート登録)にかかわらず、各登録エージェントに対称キーがあります。
mod_ossoまたはOAMエージェントの保護の有無に関係なく、各アプリケーションに対称キーがあります。登録ツールにより、このキーが生成されます。必要に応じて取得できるように、アプリケーションのマッピング、キーおよびエージェント・タイプがシステム構成に格納されます。
キーの使用
各Webgateエージェントには、エージェントおよびOAM 11gサーバー間で共有される独自の秘密鍵があります。1つのWebgateが損なわれても、他のWebgateは影響を受けません。概要は次のとおりです。
ホストベースのWebgate固有のOAMAuthnCookie_<host:port>_<random number>を暗号化/復号化します。
WebgateおよびOAM 11gサーバー間でリダイレクトされるデータを暗号化/復号化します。
キーの生成
図10-1は、使用方式(Oracle Access Managerコンソールおよびリモート登録)に関係なくエージェントの登録時に自動的に発生するキーの生成プロセスを示しています。エージェントごとに1つの対称キーがあります。
キーのアクセス可能性およびプロビジョニング
エージェント固有の各キーは、クライアント・マシン上の保護されたローカル・ストレージを介して、対応するWebgateからアクセスできる必要があります。暗号化キーは、データ・ストアには格納されません。かわりに、JavaキーストアまたはCSFリポジトリのエントリへの別名が格納され、パートナと信頼管理APIは、リクエストされた時点で実際のキーを取得します。エージェント固有の秘密鍵には、次の特徴があります。
リモート登録中にプロビジョニングされます(帯域内モードまたは帯域外モード)。
各エージェントを一意に識別できるように一意の値が設定されます。
エージェントにセキュアに配布されます(帯域内モードのワイヤまたは帯域外モードの個別のセキュアなチャネルを使用)。
SSOウォレットのOracle Secret Storeに保存されます。SSOウォレットの作成は、OAM 10gエージェントやOSSOエージェントではなくOAM 11g Webgateにのみ適用されます。
|
注意: Oracle Secret Storeは、プレーン・テキストではないOracle Wallet内の秘密鍵および他のセキュリティ関連の秘密情報を統合するコンテナです。SSOウォレットは、基礎となるファイル・システムのセキュリティに基づいてデータを保護します。このウォレットを開く場合、パスワードは必要ありません。SSOウォレットのセキュリティは、オペレーティング・システムおよびファイル権限によって異なります。 |
パートナ登録の完了時に自動ログインの編集可能なSSOウォレットのOracle Secret Storeに保存されます。
キーの格納
エージェント・キーを含むSSOウォレットをWebgate_instance_dir/webgate/config(WebTier_Middleware_Home/Oracle_WT1/instancesなど)のObAccessClient.xmlを含むディレクトリのcwallet.ssoに格納する必要があります。
SSOウォレットにユーザー・パスワードは不要で、適切なファイル権限(700)またはWindowsのレジストリで保護する必要があります。
この項では、登録ツールの概要、要件、使用方法および結果について説明します。
ロケーション
登録ツールoamregは、次の場所にあります。
<OAM_HOME>/oam/server/rreg/client/RREG.tar.gz
エージェントをホストしているコンピュータでRREG.tar.gzを解凍した後、登録ツールoamregは次のパスに格納されます。
<OAM_HOME>/oam/server/rreg/client/rreg/bin/oamreg
| プラットフォーム | oamregのパス |
|---|---|
| Linux | /rreg/bin/oamreg.sh |
| Windows | \rreg\bin\oamreg.bat |
要件
スクリプトを使用する前に、この項の説明に従ってスクリプト内に2つの環境変数を設定する必要があります。
| 環境変数 | 説明 |
|---|---|
| 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を参照する必要があります。 |
また、登録リクエストのいくつかのタグを変更する必要があります。詳細は、「リモート登録リクエスト・ファイルについて」を参照してください。
登録管理者
ユーザーは、プライマリ・ユーザー・アイデンティティ・ストアの管理者のロールに対してマップされるグループの一部になることができます。詳細は、表5-2「ユーザー・アイデンティティ・ストア要素」を参照してください。
リモート登録モードおよびリクエスト・ファイル
スクリプトを実行するコマンドには、次の2つの引数が必要です。
モード: inbandまたはoutofband
input/file: 入力ファイル(*request.xmlまたはagentName_Response.xml)への絶対パス、またはOAM_REG_HOMEの値に対する相対パス。
優先ロケーションは、前述の「要件」表で説明されているとおり、$OAM_REG_HOME/inputです。
エージェント・タイプおよび関連付けられるリクエスト・ファイル
inbandとoutofbandのどちらのモードも、次のようにinput引数を使用するリクエスト・ファイルを使用します(前述の「要件」表を参照)。
表10-1 リモート登録のリクエスト・ファイル
| エージェント・タイプ | リクエスト・ファイル |
|---|---|
|
10g Webgate |
$OAM_REG_HOME/input/OAMRequest_short.xml |
|
$OAM_REG_HOME/input/OAMRequest.xml |
|
|
$OAM_REG_HOME/input/OAMUpdateAgentRequest.xml |
|
|
11g Webgate |
$OAM_REG_HOME/input/OAM11GRequest.xml |
|
$OAM_REG_HOME/input/OAM11GRequest_short.xml |
|
|
$OAM_REG_HOME/input/OAM11GUpdateAgentRequest.xml |
|
|
OSSOエージェント(mod_osso) |
$OAM_REG_HOME/input/OSSORequest.xml |
|
$OAM_REG_HOME/input/OSSOUpdateAgentRequest.xml |
|
|
エージェントを登録せずに新しいホスト識別子とアプリケーション・ドメインを作成 |
$OAM_REG_HOME/input/CreatePolicyRequest.xml 関連項目: 「エージェントのリモート管理」 |
|
既存のホスト識別子と、エージェント登録に関連付けられていないアプリケーション・ドメインを更新 |
$OAM_REG_HOME/input/UpdatePolicyRequest.xml 関連項目: 「エージェントのリモート管理」 |
生成されたファイル
outofbandモードで、帯域内の管理者は帯域外の管理者が送信した開始リクエスト・ファイルを使用し、追加処理のために生成されたagentName_Response.xmlファイルを帯域外の管理者に戻します。帯域外の管理者は、エージェント構成ファイルを生成する入力としてagentName_Response.xmlと一緒にリモート登録ツールを実行します。
サンプルのリモート登録コマンドおよび結果
表10-2に示したサンプルのコマンドでは、ツールのロケーションをLinuxシステムの$OAM_REG_HOME (前述の「要件」表)と想定しています。
表10-2 リモート登録のサンプル・コマンド
| コマンド・タイプ | サンプル(Linux) |
|---|---|
|
帯域内の管理者の帯域内リクエスト |
./bin/oamreg.sh inband input/*Request.xml |
|
帯域内の管理者によって送信されたリクエスト |
./bin/oamreg.sh outofband input/starting_request.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 |
スクリプトの起動後、管理者はユーザー名およびパスワードを求められます(表10-2で説明した-nopromptを使用する場合を除く)。スクリプトの実行後、成功または失敗のメッセージが通知されます。入力ファイルおよび登録ツールを実行しているモードに基づいて、表10-3に示されている結果を予期できます。
表10-3 リモート登録の結果
| サーバー側の結果 | クライアント側の結果 |
|---|---|
|
帯域内のクライアント側の結果 エージェント固有の構成ファイルが生成され、*Request.xmlファイルの<agentName>タグに基づくディレクトリ(RREG_Home/output/agentName/など)に格納されます。生成された構成ファイルを以前のエージェント構成ファイルと置き換える必要があります。 次のいずれかを適用します。
|
|
帯域外のクライアント側の結果: 使用する入力ファイル(開始リクエストまたは生成されたagentName_Response.xmlファイル)に応じて、次の結果が発生します。
|
この項では、登録ツールと一緒に使用できる登録リクエスト・ファイルおよび共通の要素について説明します。
例10-1は、登録ツールのoamreg.sh(Linux)またはoamreg.bat(Windows)と一緒に使用するOSSO登録リクエストの更新バージョンを示しています。太字でハイライト表示されている情報をmod_ossoエージェント用に変更する必要があります。ただし、他のすべてのフィールドはデフォルト値を使用できます。
例10-1 OSSORequest.xml
...
<OSSORegRequest>
<serverAddress>http://{oam_admin_server_host}:{oam_admin_server_port}
<http://%7boam_admin_server_host%7d:%7boam_admin_server_port%7d>
</serverAddress>
<hostIdentifier>RREG_HostId</hostIdentifier>
<agentName>RREG_OSSO</agentName>
<agentBaseUrl>http://{web_server_host}:{web_server_port}
<http://%7bweb_server_host%7d:%7bweb_server_port%7d>
</agentBaseUrl>
<applicationDomain>RREG_OSSO</applicationDomain>
<autoCreatePolicy>true</autoCreatePolicy>
<ssoServerVersion>v3.0</ssoServerVersion>
<oracleHomePath>$ORACLE_HOME</oracleHomePath>
<virtualHost></virtualHost>
<updateMode></updateMode>
<adminInfo></adminInfo>
<adminId></adminId>
<logoutUrl></logoutUrl>
<failureUrl></failureUrl>
</OSSORegRequest>
例10-2は、エージェント登録ツールのoamreg.sh(Linux)またはoamreg.bat(Windows)と一緒に使用する短いOAM登録リクエストの更新されたサンプルを示しています。OAM 10g WebgateとOAM 11g Webgateの短いOAMリモート登録リクエストの唯一の違いは、次のコンテナです。
OAMRegRequest
OAM11GRegRequest
|
注意: 短いOAMリモート登録リクエストはOAM 10g WebgateとOAM 11g Webgateでほとんど同じですが、使用しているWebgateリリースに適切なテンプレートをコピーしてください。 |
例10-2では、太字でハイライト表示されている情報のみ、環境に応じた値に変更する必要があります。このファイルの他のすべてのフィールドには、デフォルト値を使用できます。oamregを実行する場合、完全なOAMリモート登録リクエストに存在する可能性のある他のすべてのエージェント定義に対して、デフォルト値が自動的に提供されます。
例10-2 サンプルの簡易リクエスト: OAMRequest_short.xml
<OAMRegRequest>
.
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>RREG_HostId11G</hostIdentifier>
<agentName>Remote_Reg_OAM</agentName>
<protectedResourcesList>
<resource>/</resource>
<resource>/.../*</resource>
</protectedResourcesList>
<publicResourcesList>
<resource>/public/index.html</resource>
</publicResourcesList>
<excludedResourcesList>
<resource>/excluded/index.html</resource>
</excludedResourcesList>
</OAMRegRequest>
特に指定のないかぎり、表10-4は、すべてのリクエスト・ファイル内のグローバル要素を示します。
表10-4 リモート登録リクエストに共通の要素
| 要素 | 説明 | 例 |
|---|---|---|
|
<serverAddress> |
ホストおよびポートを含むOracle Access Managerコンソールの実行中のインスタンスを参照します。 |
<serverAddress>http://{oam_admin_ser
ver_host}:{oam_admin_server_port}
</serverAddress>
|
|
<agentName> |
OAM(管理)サーバーのエージェントの一意の識別子を定義します。 各エージェント登録を一意に識別する名前が推奨されます。ただし、次のことに注意してください。
|
<agentName>RREG_OAM</agentName>
|
|
<hostIdentifier> |
この識別子は、Webサーバー・ホストを表します。OAMエージェント名の値を指定すると、フィールドに自動的に入力されます。同じ名前のエージェント名またはホスト識別子がすでに存在する場合、登録中にエラーが発生します。 注意: < 同じ名前のホスト識別子がすでに存在する場合、新しいエージェントのWebサーバーのhost:port(指定されている場合)が既存のホスト識別子に追加されます。 |
<hostIdentifier>RREG_HostId11G
</hostIdentifier>
|
表10-5は、OSSO固有のリモート登録要素を示しています。
表10-5 リモート登録リクエストのOSSO固有の要素
| 要素 | 説明 | 例 |
|---|---|---|
|
<OracleHomePath> |
mod_ossoエージェントへのファイル・システム・ディレクトリの絶対パス。 |
<oracleHomePath> $ORACLE_HOME </oracleHomePath> |
|
<virtualHost> |
デフォルト: 指定なし |
<virtualHost></virtualHost> |
|
<updateMode> |
デフォルト: 指定なし |
<updateMode></updateMode> |
|
<adminInfo> |
このmod_ossoインスタンスのオプションの管理者詳細。たとえば、アプリケーション管理者などです。 デフォルト: 指定なし> |
<adminInfo></adminInfo> |
|
<adminId> |
このmod_ossoインスタンスのIDのオプションの管理者ログ。たとえば、SiteAdminなどです。 デフォルト: 指定なし> |
<adminId></adminId> |
|
<logoutUrl> |
リモート登録中の消費のためのログアウトURLを含めます。 デフォルト: 指定なし> |
<logoutUrl>logout1.html</logoutUrl> |
|
<failureUrl> |
リモート登録中の消費のための失敗URLを含めます。 デフォルト: 指定なし> |
<failureUrl>failure1.html</failureUrl> |
表10-6は、表10-4の短いバージョンのリクエストに含まれる情報に加えて、完全なOAMリモート登録リクエストの個々の要素の情報を示しています。
OAM11gRequest.xml (11g Webgate)
OAMRequest.xml (10g Webgate)
|
注意: 特に明記しないかぎり、各要素が10gおよび11g Webgateリクエストに表示されます。要素名は、コンソールの要素名と多少異なる場合があります。 |
表10-6 完全なリモート登録リクエストに共通の要素
| 要素 | 説明 | 例 |
|---|---|---|
|
<agentBaseUrl> |
エージェントで保護するコンピュータのWebサーバーのhost:portを定義します。保護するすべてのURLがhttp://host:portのように指定する必要があるこのベースURLと相対的になります。 注意: 各agentBaseUrlを一度のみ登録できます。エージェントのベースURLからWebgateがインストールされるWebサーバー・ドメイン(< |
<agentBaseUrl>http://{web_server_
host):(web_server_port}
</agentBaseUrl>
|
|
<virtualhost> |
これが仮想ホストかどうかを指定します。 値: trueまたはfalse デフォルト: false 関連項目: 「仮想Webホスティングについて」 |
<virtualhost>false<virtualhost> |
|
<hostportVariations> |
特定のホストのバリエーションをすべて指定します。 登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、OAMはリソースを保護するポリシーを適用できます。 関連項目: 「ホスト識別子について」 |
<hostPortVariationsList> <host>host1</host> <port>7777</port> </hostPortVariations> <host>host2</host> <port>7778</port> </hostPortVariations> </hostPortVariationsList> |
|
<applicationDomain> |
指定されたエージェント名に基づくアプリケーション・ドメインの名前を定義します(表10-4を参照してください)。 |
<applicationDomain>RREG_OAM11G </applicationDomain> |
|
<autoCreatePolicy> OAM 11g短縮バージョンにはなし |
エージェントの登録時に、認証と認可のポリシーを自動的に作成できます。デフォルトで、このオプションが選択(有効化)されます。 デフォルト: true(有効) 注意: ドメインおよびポリシーをすでに登録している場合、新しいリソースを追加できます。このオプションを消去(選択解除)すると、アプリケーション・ドメインまたはポリシーが自動的に生成されません。 |
<autoCreatePolicy>true </autoCreatePolicy> |
|
<protectedResourcesList> |
認証スキームでOAMエージェントを保護するリソースURLを指定します。リソースURLは、agentBaseUrlの相対パスにする必要があります。 |
<protectedResourcesList> <resource>/</resource> <resource>/.../*</resource> </protectedResourcesList> |
|
<publicResourcesList> |
公開する(OAMエージェントで保護しない)リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。 |
<publicResourcesList> <resource>/public/index.html </resource> </publicResourcesList> |
|
<excludedresourcesList> |
公開する(OAMエージェントで保護されない)HTTPタイプ・リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。 HTTPリソース・タイプのみが除外できます。通常は、セキュリティの影響を受けにくく、認証や認可、レスポンス処理、セッション管理、監査を必要としない画像(*.jpg、*.png)などのファイル。除外されたリソースは、コンソール内のユーザー定義ポリシーには追加できません。 関連項目: 除外されるリソース・リストの詳細は、表13-1「リソース定義要素」 |
<excludedresourcesList> <resource>/excluded/index.html </resource> </excludedresourcesList> |
|
<primaryCookieDomain> 10gリクエストのみ OAMRequest.xml(10g Webgate用)では、優先HTTPホストとして<hostIdentifier>も使用されます。 |
acompany.comなどのOAM 10gエージェントがデプロイされるWebサーバー・ドメイン(クライアント・ドメイン)を示します。 Cookieドメインを構成して、Webサーバー間のシングル・サインオンを有効にする必要があります。具体的には、シングル・サインオンを構成するWebサーバーに同じプライマリCookieドメイン値を使用する必要があります。OAMエージェントは、このパラメータを使用して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のリソースのリクエスト時に再認証を行う必要があります。 |
<primaryCookieDomain>{client_domain}
</primaryCookieDomain>
|
|
<maxCacheElems> |
キャッシュに保持される要素の数。キャッシュ要素は次のとおりです。 この設定の値は、これらの両方のキャッシュの要素の統合された最大数を示します。 デフォルト = 100000 |
<maxCacheElems>100000 </maxCacheElems> |
|
<cacheTimeout> |
キャッシュされた情報が使用および参照されない場合にOAMエージェント・キャッシュに保持される時間。 デフォルト = 1800(秒) |
<cacheTimeout>1800</cacheTimeout> |
|
<tokenValidityPeriod> 11gリクエストのみ |
エージェント・トークン(11g WebgateのOAMAuthnCookieの内容)の有効な最大時間。 デフォルト = 3600(秒) |
<tokenValidityPeriod>3600 </tokenValidityPeriod> |
|
<cookieSessionTime> 10gリクエストのみ |
アクティビティに関係なくユーザーの認証セッションが有効な秒単位の最大時間。このセッション時間の終了時に、ユーザーは再認証を要求されます。これは強制ログアウトになります。 デフォルト = 3600(秒) 0(ゼロ)を指定すると、このタイムアウト設定が無効になります。 |
<cookieSessionTime>3600 </cookieSessionTime> |
|
<maxConnections> |
このOAMエージェントとOAMサーバーで確立できる接続の最大数。この数値は、このエージェントに実際に関連付けられる接続の数以上にする必要があります。 デフォルト = 1 |
<maxConnections>1</maxConnections> |
|
<maxSessionTime> |
WebgateおよびOAMサーバー間の接続に使用される時間単位の最大期間。 デフォルト = 24(時間) 0(ゼロ)を指定すると、このタイムアウト設定が無効になります。 |
<maxSessionTime>24</maxSessionTime> |
|
<ssoServerVersion> |
SSOトークン・バージョン値。
|
<ssoServerVersion> >...</ssoServerVersion> > |
|
<idleSessionTimeout> 10gリクエストのみ |
アクセス・ゲートで保護されたリソースにアクセスしないでユーザーの認証セッションを保持する秒単位の時間。 デフォルト = 3600 0(ゼロ)を指定すると、このタイムアウト設定が無効になります。 |
<idleSessionTimeout>3600> </idleSessionTimeout |
|
<failoverThreshold> |
このOAMエージェントがセカンダリOAMサーバーの接続を開くポイントを表す数値。 デフォルト = 1 たとえば、このフィールドに30と入力し、プライマリOAMサーバーの接続数が29の場合、このOAMエージェントはセカンダリOAMサーバーの接続を開きます。 |
<failoverThreshold>1 </failoverThreshold> |
|
<aaaTimeoutThreshold>- |
OAMサーバーからのレスポンスを待機する数値(秒単位)。このパラメータが設定されると、デフォルトのTCP/IPタイムアウトではなくアプリケーションのTCP/IPタイムアウトとして使用されます。 デフォルト = -1(デフォルトのネットワークのTCP/IPタイムアウトが使用されます) このパラメータの一般的な値は、30から60秒です。非常に低い値を設定すると、アクセス・サーバーからリプライを受け取る前にソケット接続がクローズしてエラーが発生する可能性があります。
関連項目: このパラメータの詳細は、表9-5を参照してください。 |
<aaaTimeoutThreshold>-1 </aaaTimeoutThreshold> |
|
<sleepFor> |
アクセス・サーバーでディレクトリ・サーバーとの接続を確認する頻度。たとえば、60秒の値を設定すると、アクセス・サーバーが起動してから60秒間隔で接続を確認します。 |
<sleepFor>60</sleepFor> |
|
<debug> |
デバッグをオンまたはオフにします。 デフォルト: false(オフ) |
<debug>false</debug> |
|
<セキュリティ> |
エージェントおよびOAMサーバー間の通信トランスポート・セキュリティのレベル(OAMサーバーに指定されたレベルと一致する必要があります) 注意: 詳細は、付録Eを参照してください。 |
<security>open</security |
|
<denyOnNotProtected> |
ルールまたはポリシーでアクセスが明示的に許可されないすべてのリソースのアクセスを拒否します。 11g Webgateの登録では常に有効化されており、変更できません。 10g Webgate登録ページで、これを無効にできます。 有効な場合、匿名認証方式を作成して、匿名アクセス・ポリシーを使用した内容へのアクセスを許可する必要があります。 |
<denyOnNotProtected>1 </denyOnNotProtected> |
|
<allowManagementOperations> |
このエージェント権限機能で、次のようなエージェントごとのセッション操作のプロビジョニングを有効にできます。
デフォルト: false 注意: セッション管理の操作を呼び出せるのは、権限のあるエージェントのみです。このパラメータを有効にすると、セッション管理のリクエスト(上のリスト)がOAMサーバーによって処理されます。無効にすると、エージェントに対してこのリクエストは拒否されます。 |
<allowManagementOperations> false/<allowManagementOperations> |
|
<cachePragmaHeader> <cacheControlHeader> |
この設定は、Webgateのみに適用して、ブラウザのキャッシュを制御します。 デフォルトでは、どちらもキャッシュなしに設定されます。これにより、WebgateによるWebサーバー・アプリケーションおよびユーザー・ブラウザのデータのキャッシュが防止されます。 ただし、サイトがWebgateで保護されている場合、これはPDFファイルのダウンロードやレポート・ファイルの保存など、特定の操作にとって妨げとなることがあります。 Webgateが異なるレベルで使用するAccess Manager SDKキャッシュを設定できます。詳細は、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlの14.9項を参照してください。 すべてのcache-response-directiveが許可されます。たとえば、両方のキャッシュ値をパブリックに設定してPDFファイルのダウンロードを許可する必要がある場合があります。 |
<cachePragmaHeader>no-cache </cachePragmaHeader> <cacheControlHeader>no-cache </cacheControlHeader> |
|
IPアドレス検証はWebgateに固有のもので、シングル・サインオン用に生成されるObSSOCookie(10g Webgate)またはOAMAuthnCookie(11g Webgate)に格納されるIPアドレスとクライアントのIPアドレスを同じにするかどうかを決定するために使用されます。 |
<ipValidation>0</ipValidation> |
|
|
IPアドレス検証の例外。 |
<ipValidationExceptions> <ipAddress>10,11,11,11</ipAddress> <ipAddress>10,11,11,12</ipAddress> <ipAddress>10,11,11,13</ipAddress> </ipValidationExceptions> |
|
|
<logOutUrls> |
ログアウトURLはログアウト・ハンドラをトリガーします。ログアウト・ハンドラはCookieを削除し(10g WebgateではObSSOCookie、11g WebgateではOAMAuthnCookie)、Oracle Access Managerに保護されたリソースにユーザーが再アクセスしたときに改めて認証を要求します。
注意: これは、最初のログアウトをトリガーするために使用される標準OAM 10g Webgate構成パラメータです。 関連項目: OAM 11gに登録されるOAM 10g Webgateのログアウトを構成する手順は、第15章を参照してください。 |
<logOutUrls>
<url>/logout1.html</url>
<url>/logout2.html</url>
</logOutUrls>
|
|
<logoutCallbackUrl> 11gリクエストのみ |
コールバック中にCookieを消去するoam_logout_successのURL。これには、host:portのないURI形式を指定でき(推奨)、この場合、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。次に例を示します。 /oam_logout_success これはhost:portのある完全なURLフォーマットとすることもでき、この場合OAM 11gサーバーは、コールバックURLを再構築することなく直接コールバックします。 関連項目: OAM 11g Webgateのログアウトを構成する手順は、第15章を参照してください。 |
<logoutCallbackUrl>/oam_logout_success </logoutCallbackUrl> |
|
<logoutTargetUrlParamName> 11gリクエストのみ |
ログアウト中にOPSSアプリケーションがWebgateに渡す問合せパラメータの名前の値。問合せパラメータには、ログアウトの完了後のランディング・ページのターゲットURLを指定します。 デフォルト: end_url 注意: jps-config.xmlのparam.logout.targeturlによって、end_url値が構成されます。 関連項目: OAM 11g Webgateのログアウトを構成する手順は、第15章を参照してください。 |
<logoutTargetUrlParamName>end_url </logoutTargetUrlParamName> |
|
ユーザー定義パラメータの名前 |
説明
|
例
<userDefinedParameters>
<userDefinedParam>
<name>...</name>
<value>...</value>
</userDefinedParam>
|
|
MaxPostDataLength |
POSTデータの長さを決定します。 100未満の値を設定しないことをお薦めします。デフォルトまたは指定された範囲を超える値をこのパラメータに設定すると、POSTデータの長さがデフォルト・サイズの0.75MBに制限されます。 デフォルト: 750000 関連項目: WebgateのIIS Webサーバーの構成の詳細は、第29章を参照してください。 |
<name>MaxPostDataLength</name> <value>750000</value> |
|
maxSessionTimeUnits |
一部のファイアウォールは、特定の期間またはアイドル時間にOAMサーバー接続を強制的に切断します。ファイアウォールのタイムアウト設定を変更できない場合、 デフォルト: hours 使用可能な値: minutes |
<name>maxSessionTimeUnits</name> <value>hours</value> |
|
RetainDownstreamPostData |
このユーザー定義パラメータを追加して値を デフォルト: false |
<name>RetainDownstreamPostData </name> <value>false</value> |
|
useIISBuiltinAuthentication |
エージェントがインストールされているOAMサーバーでMicrosoft PassportまたはIntegrated Windows Authenticationを使用する場合は、trueに設定します。これはIISのみに使用され、Webgateが他のタイプのWebサーバーにインストールされている場合には無視されます。 デフォルト: false |
<name>useIISBuiltinAuthentication </name> <value>false</value> |
|
idleSessionTimeoutLogic 10g Webgateのみ |
リリース7.0.4のWebgateは、独自のアイドル・セッション・タイムアウトのみを強制していました。 10.1.4.0.1 Webgateは、トークンが訪問したすべてのWebgateの中で、最も制限の多いタイムアウト値を強制しました。 10g(10.1.4.3)では、この要素のデフォルトが7.0.4の動作に戻りました。
|
name>idleSessionTimeoutLogic </name> <value>leastComponentIdleTimeout </value> |
|
URLInUTF8Format |
Oracle HTTP Server 2を使用する環境では、このパラメータをtrueに設定してラテン1および他のキャラクタ・セットを表示する必要があります。 デフォルト: true |
<name>URLInUTF8Format</name> <value>true</value> |
|
inactiveReconfigPeriod 共有シークレットは、10g Webgateにのみ適用されます。 構成は、11g Webgateにのみ適用されます。 |
アイドル状態で、Webgateは、 デフォルト: 10(分) |
<name>inactiveReconfigPeriod</name> <value>10</value> |
|
WaitForFailover 10g Webgateのみ |
下位互換性の目的でのみ使用され、このパラメータは
|
<name>WaitForFailover</name> <value>-1</value> |
|
proxySSLHeaderVar |
このパラメータは、Webgateがリバース・プロキシの背後にあり、クライアントとリバース・プロキシの間でSSLが構成されており、リバース・プロキシとWebサーバーの間で非SSLが構成されている場合に使用します。これにより、URLがHTTPではなくHTTPSとして格納されます。プロキシを使用すると、クライアント接続にSSLと非SSLのどちらを使用するかを示すカスタム・ヘッダー変数を設定して、URLがhttps形式で格納されます。 デフォルト: IS_SSL |
<name>proxySSLHeaderVar</name> <value>IS_SSL</value> |
|
client_request_retry_attempts |
WebgateとOAMサーバーのタイムアウトしきい値は、接続不可能とみなして新しい接続のリクエストを試みるまでの、WebgateがOAMサーバーを待機する時間(秒単位)を指定します。 これは、10gおよび11g Webgate (OAMエージェント)とOAM 11gの接続で同じです。 OAMサーバーでリクエストの処理に要する時間が、タイムアウトしきい値の値よりも長い場合、OAMエージェントはリクエストを中止して新しい接続のリクエストを再試行します。 接続プール設定によっては、接続プールから戻される新しい接続が同じOAMサーバーの接続になる場合があります。OAMエージェントは、使用可能な場合にプライマリOAMサーバーを最初に試行し、使用可能な場合にセカンダリOAMサーバーを次に試行します。 また、他のOAMサーバーでは、タイムアウトしきい値で指定された時間よりもリクエストの処理時間が多く必要になる場合があります。場合によっては、OAMサーバーが停止するまで、OAMエージェントがリクエストを再試行することがあります。 OAMエージェントが 値を-1に設定する(または何も設定しない)と、再試行が無制限に許可されます。 |
<name>client_request_retry_attempts </name> <value>1</value> |
|
ContentLengthFor401Response |
すべての401レスポンスのContent-Lengthを設定するには、次のユーザー定義パラメータおよび値を追加します。 ゼロ(0)は、使用できる唯一の値です。他の値は無視されます。このパラメータおよび値を使用しないと、コンテンツおよびコンテンツ長が一致しないことがあります。これにより、ブラウザにデータが表示されない場合やエラー・メッセージが表示される場合があります。 |
<name>ContentLengthFor401Response </name> <value>0</value> |
|
SUN61HttpProtocolVersion |
SUN v6.1 Webサーバーでは、POSTデータを読み取った後にリダイレクトの問題が発生する場合があります。
デフォルト: 1.0 1.0以外の値は無視されます。 |
<name>SUN61HttpProtocolVersion </name> <value>1.0</value> |
|
UseWebgateExtForPassthrough |
このIIS Webサーバー固有のパラメータは、ワーカー・プロセス分離モードのIIS v6およびv7でのみ使用されます。 デフォルト: false ワーカー・プロセス分離モードで実行しているIISバージョン6.xおよびIIS 7.xでは、次の場合に値をtrueに設定します。
注意: ISAPIフィルタとして構成する以外に、ISAPI拡張機能としてwebgate.dllを構成する必要もあります。第29章を参照してください。 付記: IIS 5.0分離モードで実行されているIIS 5.0またはIIS6.0の場合、このパラメータを定義しないでください(またはfalseに設定してください)。この場合、postgate.dllをISAPIフィルタとして構成し、パススルー機能を実行する必要があります。詳細は、「POSTデータのパススルー機能の有効化」を参照してください。 |
<name>UseWebgateExtForPassthrough </name> <value>false</value> |
|
syncOperationMode |
デフォルト: false |
<name>syncOperationMode</name> <value>false</value> |
|
filterOAMAuthnCookie 11gリクエストのみ |
trueに設定すると、OAMAuthnCookieが常にフィルタ処理され、ダウンストリーム・アプリケーションにアクセスできなくなります。 デフォルト: true |
<name>filterOAMAuthnCookie</name> <value>true</value> |
リクエストされた操作の実行後、帯域内の管理者は、追加処理のために次のファイルを帯域外の管理者に送信します。
帯域外の管理者がそのまま使用する必要があるagentName_Response.xml。
agentName_Response.xmlを開いたり編集したりしないことが推奨されているため、表示されません。
帯域外の管理者がWebサーバーの更新に使用する必要がある固有のWebサーバー構成ファイル。
オペレーティング・システムのoamregスクリプトを取得および更新するには、次の手順を使用できます。
Windowsの場合: oamreg.bat
Linuxの場合: oamreg.sh
登録する特定のエージェントの入力を提供する適切な*Request*.xmlファイルを更新します。
|
注意: 最新のバンドル・パッチを適用し、再度RREG.tar.gzを解凍して、最新のツールとファイル・リリースを使用することをお薦めします。 |
リモート登録には、JAVA_HOMEおよびOAM_REG_HOMの2つの変数が必要です(表10-7を参照してください)。
表10-7 リモート登録に必要な変数
| ロケーション | 変数 | 説明 |
|---|---|---|
|
クライアント側 |
JAVA_HOME |
環境にすでに設定されている$JAVA_HOMEに基づくコンピュータのJDK 1.6の場所。 |
|
OAM_REG_HOME |
絶対表記したRREG HOMEのファイルの場所(RREG.tarを展開したディレクトリに/rregを続けた位置で、かつスクリプトが置かれている場所のすぐ上のディレクトリ)。 たとえば、次のようになります。 <OAM_HOME>/oam/server/rreg/client/rreg IM_ORACLE_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 |
インストール中にスクリプトにすでに設定されています。 |
環境変数を使用してツールを取得し、スクリプトを更新する手順
次のパスのRREG.tar.gzファイルを探します。
ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz
RREG.tar.gzファイルを解凍すると、必須のツールとテンプレートを含むディレクトリが/clientの下に作成されます。
oamregスクリプト(.../rreg/client/rreg/bin)で、環境変数を次のように設定します。
「登録リクエストの作成」に進みます。
登録する特定のエージェントの入力を提供する適切な*Request*.xmlファイルを作成するには、次の手順を使用できます。
登録リクエストを作成するには、次の手順を実行します。
この項では、帯域内リモート登録の実行に使用できる手順を説明します。
前提条件
ネットワーク内のリモート登録を実行するには、次の手順を使用できます。
|
注意: この場合、ネットワーク内の管理者は、すべてのタスクを実行します。リソースを保護するOAMエージェント(Webgate)またはOSSOエージェント(mod_osso)の使用の有無に関係なく、タスクは同じです。 |
この例は、Linuxシステムの短い登録リクエストを使用したOAMエージェントの登録を示しています。または、Oracle Access Managerコンソールを使用してエージェントを登録し、アプリケーション・ドメインを追加できます(第9章および第13章を参照してください)。
帯域内リモート登録を実行するには、次の手順を実行します。
エージェントをホストしているコンピュータで、登録コマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。
./bin/oamreg.sh inband input/myagent_request.xml
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージを参照して確認します。
成功: 画面のメッセージを確認します。
帯域内登録プロセスが正常に完了しました。
固有の構成ファイルの場所が出力フォルダに作成されます。
出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。
出力フォルダのエージェント用に作成した固有の構成ファイルのObAccessClient.xmlを確認し、まだ置換されていない場合は以前のエージェント構成ファイルを置換します。
エージェント登録を完了します。このエージェント登録を完了するには、次の手順を実行します。
ObAccessClient.xmlをOAMエージェントのホスト・コンピュータにコピーして、Webgate構成を手動で更新します。
10g Webgate/アクセス・クライアントの場合: $WG_install_dir/oblix/lib/ObAccessClient.xml
11g Webgate/アクセス・クライアント: $Webgate_instance_dir/webgate/config (cwallet.ssoも含む)、次に例を示します。
config/OHS/ohs1/webgate/config
OAMエージェントをホストしている管理対象サーバーを再起動します。
「リモート登録およびリソース保護の検証」に進みます。
この項では、ネットワーク内外の管理者が連携してリモート・エージェントを登録し、デフォルトのアプリケーション・ドメインを設定してリソースを保護する手順を説明します。
前提条件
|
注意: この場合、帯域内の管理者および帯域外の管理者は、異なるタスクを実行します。エージェント・タイプ(OAMエージェントまたはOSSOエージェント(mod_osso))にかかわらず、タスクは同じです。 |
次の手順は、LinuxシステムのみにOAMエージェントを登録する手順を示しています。
帯域内は、ネットワーク内のWebサーバー管理者が実行するタスクを示します。
帯域外は、ネットワーク外のWebサーバー管理者が実行するタスクを示します。
帯域外リモート登録を実行するには、次の手順を実行します。
帯域外の管理者: starting_request.xmlファイルを作成して、処理するために帯域内の管理者に送信します(「登録リクエストの作成」を参照してください)。
WLS_Home/Middleware/Oracle_IDM1/oam/server/rreg/client/rreg/output/agentName/starting_request.xml
帯域内の管理者の手順:
登録コマンドを実行し、入力ファイルとして帯域外の管理者のstarting_request.xmlを指定します。次に例を示します。
./bin/oamreg.sh outofband input/starting_request.xml
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージを参照して確認します。
成功: 登録プロセスが正常に完了しました。
Response.xmlの場所が入力フォルダに作成されます。
入力フォルダは、RREG.tar.gzが展開されている場所(/rreg/input/AgentName/)にあります。
他のアーティファクトとともにagentName_Response.xmlファイルを帯域外の管理者に戻します。次に例を示します。
agentName_Response.xml
帯域外の管理者: 次のように環境を更新します。
エージェントをホストしているコンピュータで、リモート登録コマンドを実行し、入力ファイルとして受け取ったagentName_Response.xmlを指定します。次に例を示します。
./bin/oamreg.sh outofband input/agentName_Response.xml
ObAccessClient.xmlおよびcwallet.sso(11gエージェント用)が出力フォルダ/rreg/output/AgentName/に生成されます。
ObAccessClient.xmlをOAMエージェントのホスト・コンピュータにコピーして、Webgate構成を手動で更新します。
10g Webgate/アクセス・クライアントの場合: $WG_install_dir/oblix/lib/ObAccessClient.xml
11g Webgate/アクセス・クライアント: $Webgate_instance_dir/webgate/config (cwallet.ssoも含む)。次に例を示します。
config/OHS/ohs1/webgate/config
OAMエージェントをホストしているWebサーバーを再起動します。
「リモート登録およびリソース保護の検証」に進みます。
この項の内容は次のとおりです。
エージェント・タイプに関係なくエージェントおよびアプリケーションの登録を検証するガイドとして、次の手順を使用できます。
Oracle Access Managerコンソールを使用してタスクを実行するには、帯域内の管理者であることが必要です。帯域外の管理者は、リモートの認証およびアクセスをテストする必要があります。
エージェントおよびアプリケーション登録を検証するには、次の手順を実行します。
エージェント登録: Oracle Access Managerコンソールの「システム構成」タブのエージェント詳細を確認します(第9章を参照してください)。
OAMエージェント: WebgateとOAMサーバー間の通信をブートストラップするために変更されたObAccessClient.xmlがWebgateインストール・ディレクトリにあることを確認します。
Webgate_install_dir\access\
OSSOエージェント: 変更されたosso.confがエージェントのWebサーバーと同じディレクトリにあることを確認します。これを使用して、OSSOエージェントとOAMサーバー間の通信をブートストラップします。
共有コンポーネント、ホスト識別子: ホスト識別子がOracle Access Managerコンソールに定義されていることを確認します。
アプリケーション・ドメイン: 「ポリシー構成」タブで、登録されたエージェントに基づいて名付けられた新しいデフォルトのアプリケーション・ドメインがあることを確認します。
アプリケーション・ドメインのリソースは、ホスト識別子に関連付けられます。
登録後、管理サーバーまたは管理対象サーバーを再起動することなく適切な認証とともに保護されたリソースにアクセスできる必要があります。
ここでの手順は、登録、認証および認可が適切に構成および動作していることを確認するいくつかの方法を示しています。手順は、OAMエージェント(Webgate)およびOSSOエージェント(mod_osso)でほとんど同じです。
帯域外の管理者がこれらの検証を行うことをお薦めします。
登録後に認証およびアクセスを確認するには、次の手順を実行します。
登録されたOAMエージェントで保護されたアプリケーションのURLを入力して、ログイン・ページが表示されていることを確認します(認証リダイレクトURLが適切に指定されたことが証明されます)。次に例を示します。
http://myWebserverHost.us.abc.com:8100/resource1.html
ログイン・ページで、求められた場合に有効なユーザー名およびパスワードを入力し、「ログイン」をクリックします。
OAM固有のCookieがブラウザ・セッションに作成されていることを確認します。次に例を示します。
ObSSOCookie
Set-Cookie: ObSSOCookie=GGVEuvjmrMe%2FhbItbjT24CBmJo1eCIfDIwQ1atdGdnY4mt6kmdSekSFeAAFvFrZZZ xDfvpkfS3ZLZFbaZU2rAn0YYUM3JUWVYkYFwB%2BBK7V4x%2FeuYHj%2B8gwOyxhNYFna3iSx1MSZBE y51KTBfsDYOiw6R%2BCxUhOO8uZDTYHI3s0c7AQSyrEiQTuUV3nv1omaFZlk1GuZa4J7ycaGbIUyqwX rM0cKuBJNd6sX1LiRj9HofYQsvUV7ToqeAOpDS7z9qs5LhqU5Vq60bBn12DTX6zNX6Lcc0L5tVwvh7% 2BnOAkz2%2BoDkLs%2BBTkeGcB3ppgC9;httponly; path=/; domain=.us.oracle.com;
OAM_ID Cookie
Set-Cookie: OAM_ID=v1.0~0~E1EBBC9846E09857060A68E79AEEB608~AA79FC43C695162B6CDE3738F40E94DA 6408D58B879AC3B467EBBD4800743C899843672B3511141FFABCF58B2CDCB700C83CC734A913625 7C4ABDA6913C9EF5A4E05C5D03D3514F2FECACD02F1C1B9314D76B4A68CB7A8BE42AEB09AFB98B8 EB; path=/; HttpOnly
次の作業を実行します。
成功: 正しく認証され、リソースへのアクセスが付与された場合、構成が正常に動作します。詳細な検証については、手順5から12に進みます。
失敗: ログイン中にエラーを受け取った場合またはリソースへのアクセスが拒否された場合、次の項目を確認します。
ログイン・エラー: 有効なユーザーIDおよびパスワードが入力されていることを確認します。
使用不能なリソース: リソースが使用できることを確認します。
不正なリダイレクトURL: Oracle Access ManagerコンソールのリダイレクトURLを確認します。
ユーザー・バリエーション: ユーザー・バリエーションで手順1から4を再実行して、適切な動作(認可ユーザーの成功または未認可ユーザーの失敗)を確認します。
リクエストの取消し: 部分的なログインを実行し、「取消」をクリックしてリソースにアクセスしていないことを確認します。
変更された認証URL: 手順1から5を実行して適切なレスポンスを確認する場合、ほとんど同じ認証URLを入力します。たとえば、1文字をURL文字列に追加します。
更新されたリソース: 次の手順を実行して、リソースにアクセスできることを確認します。次に例を示します。
元のリソース: /abc/test.html
更新されたリソース: /abc/xyz/test.html
Oracle WebLogic Serverを再起動しない場合
更新されたリソースにアクセスし、ユーザーが認証を求められ、リソースにアクセスできることを確認します。
元のリソースにアクセスし、リソースにアクセス可能で、ユーザーが認証を求められていないことを確認します。
様々なURLパターン: 手順1から5を実行する場合、様々なURLパターンの認証を確認します。
新しい認証スキーム: 次の手順を実行して、WebLogic Serverを再起動しないで認証操作を確認します。
異なる認証スキームを使用する新しい認証ポリシーを追加します。
新しいポリシーを使用して、リソースを保護します。
Oracle WebLogic Serverを再起動しないで、手順1から4を実行します。
CGIリソース・ヘッダー変数およびCookie: 次の手順を実行して、WebLogic Serverを再起動しないで認証操作を確認します。
新しい認証ポリシーを追加してCommon Gateway Interface(CGI)リソースを保護し、「認証に成功しました」のレスポンスを設定します。
新しいポリシーを使用して、リソースを保護します。
CGIリソースにアクセスします。
CGIデータ・ダンプでレスポンスに対して構成されたヘッダー値を確認します。
エージェントの無効化: WebgateがObAccessClient.xmlで無効な場合、次の手順を実行して、アクセス可能性および認証を検証します(Webgateは、oam-config.xmlから有効な値を選択する必要があります)。
エージェント(OAMエージェント(Webgate)またはOSSOエージェント(mod_osso))を無効化します。WebサーバーおよびOAMサーバーを起動します。OAMエージェントで保護されたアプリケーションにアクセスして、認証が求められていることを確認します。
ここでは、次の内容について説明します。
いくつかのリモート管理モードで、管理者は既存のエージェント登録を更新、検証または削除できます。表10-8に、リモート・エージェント管理モードを示します。コマンドのパラメータには、モード、入力*Request.xmlファイル(OAM_REG_HOMEに対する相対パス、入力*Request.xmlファイルの優先ロケーション)が含まれます。
./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value
表10-8 リモート・エージェントとポリシーの更新
| モードおよび入力ファイル | 説明および構文 |
|---|---|
|
agentUpdateモード OSSOUpdateAgentRequest.xml OAM11GUpdateAgentRequest.xml OAMUpdateAgentRequest.xml |
管理者がエージェント属性を更新できます。 ./bin/oamreg.sh agentUpdate input/OAM11GUpdateAgentRequest.xml |
|
agentValidateモード 入力ファイルは不要です。 |
エージェントがOracle Access Manager 11gですでにプロビジョニングされているかどうかを検証します。
./bin/oamreg.sh agentValidate agentname
|
|
agentDeleteモード 入力ファイルは不要です。 |
管理者がエージェント登録を削除できます。
./bin/oamreg.sh agentDelete agentname
|
agentUpdateモードのテンプレートについては、次の項を参照してください。
OSSOUpdateAgentRequest.xmlを使用して、特定の値をリモート登録ツールoamregに渡します。更新テンプレートと元の登録テンプレートの主な違いは、更新テンプレートの次の点にあります。
変更を追跡する<startDate>yyyy_mm_dd</startDate>要素があります。
agent_base_url_portを指定する<homeUrl>要素があります。
<hostidentifier>要素が省略されます。
<agentbaseURL>要素が省略されます。
図10-2は、OSSOエージェントの更新テンプレートを示しています。
OAM11GUpdateAgentRequest.xmlを使用して、特定のエージェント更新値をリモート登録ツールoamregに渡します。更新テンプレートと元の登録テンプレートの主な違いは、更新テンプレートの次の点にあります。
<ipValidation>要素がありますが、<ipValidationExceptions>は省略されます。
<authCreatePolicy>と、アプリケーション・ドメイン関連の要素が省略されます。
<hostidentifier>、<virtualhost>、<hostportVariations>の各要素が省略されます。
<agentbaseURL>要素が省略されます。
<ssoServerVersion>要素が省略されます。
<idleSessionTimeout>要素が省略されます。
図10-2は、OAM 11gエージェントの更新テンプレートを示しています。
OAMUpdateAgentRequest.xmlを使用して、特定のOAM 10gエージェント更新値をリモート登録ツールoamregに渡します。この更新テンプレートと元のOAM 10gエージェント登録テンプレートの主な違いは、更新テンプレートの次の点にあります。
<ipValidation>要素がありますが、<ipValidationExceptions>は省略されます。
<authCreatePolicy>と、アプリケーション・ドメイン関連の要素が省略されます。
<hostidentifier>、<virtualhost>、<hostportVariations>の各要素が省略されます。
<agentbaseURL>要素が省略されます。
<ssoServerVersion>要素が省略されます。
<idleSessionTimeout>要素が省略されます。
図10-4は、OAM 10gエージェントのOAMUpdateAgentRequest.xmlを示しています。
Oracle Access Manager 11gには、エージェントを登録または変更せずにアプリケーション・ドメインを管理する2つのモードがあります。
|
注意: リモート・アプリケーション・ドメイン管理でサポートされるのは、作成および更新の機能のみです。アプリケーション・ドメイン管理の削除は、アプリケーション・ドメインのリモート削除をサポートしていません。アプリケーション・ドメインの削除は手動のタスクであり、Oracle Access Managerコンソールを使用して実行する必要があります。 |
表10-9に、リモート・アプリケーション・ドメイン管理のモードを示します。ここでもコマンドのパラメータには、モード、OAM_REG_HOMEに対する相対パスを使用する入力*Request.xmlファイル、入力ファイルの優先ロケーションが含まれます。
./oamreg.sh <mode> <input_file> [prompt_flag] [component.oam.config_file] <mode> value
表10-9 リモート・アプリケーション・ドメイン管理モード
| モード | 説明 |
|---|---|
|
policyCreate CreatePolicyRequest.xml |
管理者が、エージェントを登録せずにホスト識別子とアプリケーション・ドメインを作成できます。 ./bin/oamreg.sh policyCreate input/CreatePolicyRequest.xml 次の機能があります。
|
|
policyUpdate UpdatePolicyRequest.xml |
管理者が、エージェントを更新せずに既存のホスト識別子とアプリケーション・ドメインを更新できます。 ./bin/oamreg.sh policyUpdate input/UpdatePolicyRequest.xml 次の機能があります。
|
|
[prompt_flag] value: [-noprompt] |
オプション。-nopromptフラグを使用すると、oamregはechoおよびpipeを使用してsystem.inから入力を読み取り、データを渡すことができます。 OAM_REG_HOMEロケーションからの例 (echo username; echo password; echo webgate_password;) | ./bin/oamreg.sh inband input/Request.xml -noprompt component.oam.conf (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 |
|
component.oam.config_file |
オプション。リモート登録は、URIリストを引数に持つ構成ファイルを受け取ります。component.oam.config_fileには、任意の数の保護URIまたはパブリックURIを含むファイルへのフルパスを定義します。このファイルでは次の構文および形式が使用されていることを確認します。
注意: 次の形式を使用して、保護ポリシーに対して認証スキームを構成できます(ポリシー名と認証スキーム名はタブ文字で区切る必要があります)。 <Policy Name> 'tab' <Authentication Scheme Name> 次に例を示します。
########################
protected_uris
########################
protected policy1 Basic Over LDAP
/finance/protected1/*
/finance/protected2/*
protected policy2 Client Certificate
/finance/protected3/.../{*.js,*.png,*.gif}
########################
public_uris
########################
/finance/public
/finance/test1/public
|
詳細は、次を参照してください。
policyCreateモードとCreatePolicyRequest.xmlを使用すると、エージェント登録を作成または更新することなく、次のように情報を作成できます。
複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を作成します。
アプリケーション・ドメインを作成します。
複数の保護リソース、パブリック・リソース、除外リソースを追加します。リソースは、問合せ文字列の有無にかかわらずどちらもサポートされます。
カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを作成します。
CreatePolicyRequest.xmlファイルのパラメータの一部は新規であり、エージェント登録XMLファイル全体には含まれず、元のエージェント登録ファイルの特定の要素を使用して作成または更新されます。ただし、同じ要素もあります。CreatePolicyRequest.xml固有の主な違いは、次のとおりです。
認証および認可のポリシーおよびリソースの要素があります。
<agentName>要素または関連する要素はありません。
図10-5に、CreatePolicyRequest.xmlを示します。
前述のとおり、CreatePolicyRequest.xmlファイルと、エージェント登録XMLファイル全体には、同じパラメータが多数存在します。CreatePolicyRequest.xmlファイルには、認証および認可のポリシーおよびリソースの要素があります(<agentName>要素はない)。
図10-6に、CreatePolicyRequest.xmlとほぼ同一の、UpdatePolicyRequest.xmlを示します。
UpdatePolicyRequest.xmlにはCreatePolicyRequest.xmlと同じ要素がありますが、<protectedAuthnScheme>要素のみ例外です。UpdatePolicyRequest.xmlを使用して、管理者は次の操作が可能です。
複数のhostPortVariations(ホストとポートのペア)を追加して、ホスト識別子を更新します。
アプリケーション・ドメインを更新します。
複数の保護リソース、パブリック・リソース、除外リソースを追加します。リソースは、問合せ文字列の有無にかかわらずどちらもサポートされます。
カスタマイズしたポリシーを必要としないリソースに対するデフォルトの認証ポリシーおよび認可ポリシーを更新します。
次を含む、カスタマイズしたポリシーを作成します。
ポリシーの表示名
ポリシーの説明
認証スキーム(認証ポリシーのみ)およびポリシーに関連付けられるリソースのサブセット
この項では、図10-7に示すアプリケーション・ドメインに固有のリモート管理要素について説明します。これらはCreatePolicyRequest.xmlファイルとUpdatePolicyRequest.xmlファイルにあり、説明は表10-10のとおりです。
表10-10 <rregApplicationDomain>リモート管理テンプレートの要素
| 要素 | 説明 | 例 |
|---|---|---|
<rregAuthenticationPolicies> <rregAuthenticationPolicy> |
認証ポリシーの名前と説明を指定します(新規作成または既存ポリシーの更新時に使用)。 |
<rregAuthenticationPolicies>
<rregAuthenticationPolicy>
<name>AuthenticationPolicy1</name>
<description>Authentication policy
created using policyUpdate mode of
rreg tool</description>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies>
|
<authnSchemeName>
|
認証ポリシーで使用する認証スキームを指定します。 |
<rregAuthenticationPolicies>
.
.
authnSchemeName>LDAPScheme
</authnSchemeName>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies>
|
|
<uriList> |
認証ポリシーを使用する認証を必要とするリソースを識別します。 |
<rregAuthenticationPolicies>
.
.
<uriList>
- <uriResource>
<uri>/res1</uri>
<queryString />
</uriResource>
</uriList>
.
.
</rregAuthenticationPolicy>
</rregAuthenticationPolicies>
|
<rregAuthorizationPolicies> <rregAuthorizationPolicy> |
認可ポリシーの名前と説明を指定します(新規作成または既存ポリシーの更新時に使用)。 |
<rregAuthorizationPolicies>
<rregAuthorizationPolicy>
<name>AuthorizationPolicy1</name>
<description>Authorization policy
created using policyUpdate mode of
rreg tool</description>
.
.
</rregAuthorizationPolicy>
</rregAuthorizationPolicies>
|
|
<uriList> |
認可ポリシーを使用する認可を必要とするリソースを識別します。 |
<rregAuthorizationPolicies>
.
.
<uriList>
- <uriResource>
<uri>/res1</uri>
<queryString />
</uriResource>
</uriList>
.
.
</rregAuthorizationPolicy>
</rregAuthorizationPolicies>
|
ここでは、次の内容について説明します。
前提条件
「リモート・エージェント管理モードについて」を確認してください。
エージェント登録をリモートで更新する手順
「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。
次のいずれかのテンプレートを使用して更新リクエストを作成します。
エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。
./bin/oamreg.sh agentUpdate input/*UpdateAgentRequest.xml
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージを参照して確認します。
成功: 画面のメッセージを確認します。
agentUpdateプロセスは正常に完了しました。
固有の構成ファイルの場所が出力フォルダに作成されます。
出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。
出力フォルダのエージェント用に作成した固有の構成ファイルのObAccessClient.xmlを確認し、まだ置換されていない場合は以前のエージェント構成ファイルを置換します。
エージェント登録の完了: OAMエージェント登録を完了するには、次の手順を実行します。
ObAccessClient.xmlをOAMエージェントのホスト・コンピュータにコピーして、Webgate構成を手動で更新します。
10g Webgate/アクセス・クライアントの場合: $WG_install_dir/oblix/lib/ObAccessClient.xml
11g Webgate/アクセス・クライアント: $Webgate_instance_dir/webgate/config (cwallet.ssoも含む)、次に例を示します。
config/OHS/ohs1/webgate/config
OAMエージェントをホストしている管理対象サーバーを再起動します。
前提条件
「リモート・エージェント管理モードについて」を確認してください。
エージェント登録をリモートで検証する手順
「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。
エージェントをホストしているコンピュータで、agentValidateモードで次のコマンドを実行します。次に例を示します。
./bin/oamreg.sh agentValidate agentname
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージを参照して確認します。
成功: 画面のメッセージを確認します。
AgentValidationプロセスは正常に完了しました。
固有の構成ファイルの場所が出力フォルダに作成されます。
出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。
前提条件
「リモート・エージェント管理モードについて」を確認してください。
エージェント登録をリモートで削除する手順
「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。
エージェントをホストしているコンピュータで、agentDeleteモードで次のコマンドを実行します。次に例を示します。
./bin/oamreg.sh agentDelete agentname
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージを参照して確認します。
成功: 画面のメッセージを確認します。
AgentDeleteプロセスは正常に完了しました。
前提条件
「リモート・アプリケーション・ドメイン管理モードについて」を確認してください。
エージェントを使用しないアプリケーション・ドメインを作成または更新する手順
「登録ツールの取得および設定」の説明に従って、登録ツールを設定します。
次のいずれかのテンプレートを使用してポリシー更新リクエストを作成します。
ポリシー作成リクエスト・ファイル
ポリシー更新リクエスト・ファイル
エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。次に例を示します。
作成する場合:
./bin/oamreg.sh policyCreate input/CreatePolicyRequest.xml
更新する場合:
./bin/oamreg.sh policyUpdate input/UpdatePolicyRequest.xml
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージを参照して確認します。
成功: 画面のメッセージを確認します。
agentUpdateプロセスは正常に完了しました。
固有の構成ファイルの場所: ...が出力フォルダ...に作成されました。
出力フォルダは、RREG.tar.gzが展開されている場所(/rreg/output/AgentName/)にあります。
