| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.1) B69533-05 |
|
 前 |
 次 |
『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』に、Oracle HTTP ServerへのOracle Access Manager 11gの初期デプロイメントについての説明が記載されています。ただし、Oracle HTTP Server以外のWebサーバー・タイプがある企業では、既存の10g Webgateを使用するか、新規に10g Webgateをインストールして、Access Managerで使用できます。また、事前登録済のIAMSuiteAgentから、10g Webgateの使用に切り替えて、Oracle Identity Managementコンソールを保護することもできます。
次の項では、10g Webgateの新規インスタンスをインストールしてAccess Managerで使用する方法を説明します。
Oracle Technology Networkの最新の証明書マトリックスを確認して、ご自身のデプロイメント用の最新のWebgateを検索してください。
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
Oracle Access Managementコンソールが稼動していること、および次の項目を理解していることを確認してください。
この項では次のトピックを提供します:
IAMSuiteAgentは、Access Manager 11.1.2に事前登録済のJavaエージェント・フィルタです。このエージェントと付属アプリケーション・ドメインは、Access Managerによる事前構成済でインストールされます。
IAMSuiteAgentは、ドメイン全体のエージェントです。
Access Managerがデプロイされると、ドメイン内の各サーバーにIAMSuiteAgentがインストールされます。
無効にしないかぎり、WebLogicアプリケーション・サーバーに入ってくるすべてのリクエストは、IAMSuiteAgentによって評価および処理されます。
特定のIAMSuiteAgent構成の要素はWebLogic管理コンソール(「セキュリティ・プロバイダ」セクション)に、その他の要素はOracle Access Managementコンソールにあります。
IAMSuiteAgentおよび関連ポリシーは、IDM管理コンソール、Oracle Identityコンソール、Oracle Access Managementコンソール、およびアイデンティティ管理ドメインの特定リソースに、SSO保護を提供します。
IAMSuiteAgentを10g Webgateに置き換えると、Oracle Identity Managementコンソールと、アイデンティティ管理ドメイン(選択した場合)を保護できます。
11g OAMサーバーは、Access Manager 11.1.2で操作するように登録されている10g Webgateをサポートします。このようなWebgateには、次のものがあげられます。
Oracle Access Manager 10gで現在稼働中のレガシー10g Webgate。
SSO用にIDアサーション・プロバイダ(IAP)として構成されているレガシー10g Webgate(『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』に記載されているように、Oracle Access Manager 10gでIAP WebLogicコンテナベースのセキュリティを使用しているアプリケーション用)。
Oracle ADFセキュリティとOPSS SSOフレームワーク用にコードが記述されたWebアプリケーションで現在操作しているレガシー10g Webgate。
Oracle Access Managementコンソールまたはリモート登録ツールを使用して、Access Manager SSOを使用するように、これらのエージェントを登録できます。登録後は、10g Webgateはブリッジとして機能するJAVAベースのOAMプロキシを使用して、Access Managerと直接通信できます。
次の概要では、既存の10g WebgateをAccess Managerで使用するための設定に必要なタスクをまとめています。
タスクの概要: レガシー10g WebgateをAccess Managerで使用できるようにする設定
オプション: 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明するように、アプリケーションをWebLogicコンテナにデプロイします。
この章で説明しているように、新しい10g WebgateをインストールしてAccess Manager 11gで使用できます。10g Webgateは、いくつかのWebサーバー・プラットフォーム用に提供されています。
インストールおよび登録の後で、10g Webgateはブリッジとして機能するJAVAベースのOAMプロキシを使用して、Access Managerと直接通信できます。
|
注意: Access Manager用に新規10g Webgateをインストールする場合、最新のWebgateを使用することをお薦めします。また、フェイルオーバーやロード・バランシング用に、複数のWebgateをインストールすることをお薦めしています。 |
11g Access Managerデプロイメントへの10g Webgateのインストールと、Oracle Access Manager 10gデプロイメントへの10g Webgateのインストールにはいくつかの違いがあります。表23-1に違いをまとめます。
表23-1 10g Webgateのインストールの比較
| 11gデプロイメントへの10g Webgate | 10gデプロイメントへの10g Webgate |
|---|---|
|
|
次の概要では、この章でAccess Manager 11g用の10g Webgateのインストールおよび登録タスクについて詳細に説明したトピックをあげています。Access Manager 11gを正しく操作するために、すべての手順を完了する必要があります。
タスクの概要: 10g WebgateのAccess Manager 11g用の登録とインストール
10g Webgateの登録:
オプション: 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』で説明するように、アプリケーションをWebLogicコンテナにデプロイします。
登録された10g Webgateに対して構成されたlogout.htmlファイルがアプリケーションによって起動されると、ログアウトが開始されます。
一般的に、10g Webgate使用時の集中ログアウトの際には、SSOエンジンがユーザー・セッションの有無を問う要求を受け取ります。セッション管理エンジンはセッションを参照し、セッションが存在するという応答をします。SSOエンジンはセッション削除要求を送信します。セッション管理エンジンはトークンとセッション・コンテキストを削除します。SSOエンジンはセッション削除完了レスポンスを送信します。
ユーザー・トークンとセッション・コンテキストを削除するとサーバー側の状態が削除されますが、これにはサーバー側に設定されたOAM_ID Cookieを削除することが含まれます。エージェントに通知が行われると、エージェントはアプリケーションのクライアント側状態を削除します。詳細は、「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」を参照してください。
この項では、Access ManagerおよびOSSOの10gアーキテクチャとの比較について説明します。次のトピックが含まれます。
Access Manager 11gは、アイデンティティ管理機能がOracle Identity Manager 11g(ユーザー・セルフサービス、セルフ登録、ワークフロー機能、動的グループ管理、委任されたアイデンティティ管理を含む)に移管されたという点で、10gとは異なります。
Access Manager 10gは、認証レベルが同じかより低いターゲット・リソースへのアクセスに必要なユーザー・アイデンティティおよびセッションの情報を含む単一のセッションcookie (ObSSOCookie)を使用して、シングル・サインオンをサポートしていました。ObSSOCookieは、グローバル共有の秘密鍵を使用して暗号化、復号化され、秘密鍵の値はディレクトリ・サーバーに格納されていました。ObSSOCookieは、ユーザー・アイデンティティを検証して保護されたリソースへのアクセスを許可または却下するために、アクセス・システム・コンポーネントによって消費されていました。
あらゆるセキュリティ・ギャップを埋めるために、Access Manager 11gでは、既存のAccess Manager 10gポリシー施行エージェント(Webgate)およびOSSO 10gエージェント(mod_osso)との下位互換性を維持するサーバー側コンポーネントが新たに提供されます。新しいAccess Manager 11g Webgateは10g Webgateの強化バージョンで、シングル・サインオン(SSO)・ソリューションのためにエージェントごとの秘密鍵をサポートしています。したがって、Cookieリプレイ型の攻撃が阻止されます。11g Webgateは、すべて同じレベルで信頼されます。つまり、Webgate固有のCookieが設定され、それを使用しても、他のWebgateで保護されたアプリケーションにユーザーの代理でアクセスすることはできません。
特に明記しないかぎり、「Webgate」という用語は新規のWebgateまたはカスタムのアクセス・クライアントの両方を指します。
Access Manager 11gでは、Oracle Coherenceの技術を使用して、分散されて集中化された信頼のできるセッション管理が可能です。
表23-2は、Access Manager 11gと10gの比較を示しています。Access Manager 11gで変更された名前のリストについては、「11.1.2で変更された製品およびコンポーネントの名前」を参照してください。
表23-2 比較: Access Manager 11g対10g
| Access Manager 11g | 10g | |
|---|---|---|
|
エージェント |
注意: 8つの管理者言語がサポートされています。 |
注意: 8つの管理者言語がサポートされています。 |
|
サーバー側のコンポーネント |
|
|
|
コンソール |
Oracle Access Managementコンソール |
アクセス・システム・コンソール アイデンティティ・システム・コンソール |
|
インターネット上での情報交換の保護に使用されるプロトコル。 |
エージェントとサーバー間で交換されるフロント・チャネル・プロトコル: HTTP/HTTPS 11g Webゲートでは、エージェント・キーを使用して情報交換が保護されます。 -関連項目: 暗号化キー |
プレーン・テキストでの10gエージェントの情報交換は保護されません。 |
|
暗号化キー |
注意: 登録されたmod_ossoエージェントごとに1つのキーが生成され、使用されます。 |
すべての10g Webゲートが使用するAccess Managerデプロイメントごとに1つのグローバル共有秘密鍵 |
|
キー・ストレージ |
|
ディレクトリ・サーバーに格納されるグローバルで共有される秘密のみ(Webgateに対してはアクセス不可) |
|
Cookie |
ホストベースの認証Cookie。表1-3「概要: Access Manager 11.1.2」を参照してください。 |
|
|
暗号化 / 復号化(暗号化されたデータを元の形式に変換するプロセス) |
クライアント側の暗号化を導入して、エージェントとサーバーの両側で暗号化が実行されるようにします。
|
|
|
セッション管理 |
|
|
|
クライアントIP |
|
|
|
レスポンス・トークンの再生防止 |
|
N/A |
|
複数のネットワーク・ドメインのサポート |
ネットワーク間ドメインの設定不要なシングル・サインオン。 複数のネットワーク・ドメインをサポートする場合は、Oracle Federationを使用することをお薦めします。 |
独自の複数のネットワーク・ドメインSSO機能が、Oracle Identity Federationより前から存在します。これが10gデプロイメントに実装されている場合、10gエージェントをAccess Manager 11gに登録すればこのサポートを引き続き受けられます。
|
|
一元化されたログアウト |
第20章を参照してください。 |
10g WebgateとAccess Manager 11gを併用する場合、logout.htmlでは特定の詳細が必要です。第20章を参照してください。
|
明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。
Access Manager 10gは、ポリシー・ドメイン内のポリシーに基づく認証と認可を提供します。アクセス・サーバーへのWebgate問合せの数を制限するためにアクセスを明示的に拒否したルールまたはポリシーでリソースが保護されなかった場合Access Manager 10gのデフォルトの動作ではアクセスが許可されていました。
表23-3は、Access Manager 11gポリシー・モデルと10gモデルを比較しています。明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。対照的に、Access Manager 10gのデフォルトの動作では、リソースがアクセスを明示的に指定するルールやポリシーによって保護されていない場合に、アクセスが許可されていました。
表23-3 Access Manager 11gと10gのポリシー・モデルの比較
| ポリシーの要素 | 11gポリシー・モデル | 10gポリシー・モデル |
|---|---|---|
|
ポリシー・オーサリング |
Oracle Access Managementコンソール |
ポリシー・マネージャ |
|
ポリシー・ストア |
データベース |
LDAPディレクトリ・サーバー |
|
ドメイン |
アプリケーション・ドメイン |
ポリシー・ドメイン |
|
リソース |
|
|
|
ホスト識別子 |
|
|
|
認証ポリシー |
|
|
|
認証スキーム |
認証スキームはグローバルに定義され、共有されます(認証ポリシー内から参照できます)。 信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。 注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。 関連項目: 表17-20 認証スキームの定義 |
認証スキームをポリシーの外部で定義し、認証ポリシー内で参照できます。 |
|
認可ポリシー |
1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。ポリシーには、それぞれ1つ以上の条件およびルールを含めることができます。 関連項目: 「ルール」、この表の以降の項目および「特定のリソースの認証ポリシーの定義」 |
リソースを保護するには、1つ以上の条件を含んだ認可ルールを定義します。また、1つ以上の認可ルール使用する認可条件式を構成します。ポリシー・ドメイン(およびポリシー)には、それぞれ1つの認可条件式のみを含めることができます。 |
|
トークン発行ポリシー |
生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。条件やルールは自動的に生成されません。これらは手動で追加する必要があります。 関連項目: トークン発行ポリシー・ページについて |
N/A |
|
レスポンス |
すべてのポリシー・タイプで使用可能。
|
|
|
Cookie |
関連項目: 表16-8 および |
関連項目: 表16-8 および |
|
問合せ文字列ベースのHTTPリソース定義 |
アクセス・ポリシー内でサポートされます。表18-1「リソース定義の要素」を参照してください。 |
このポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。 ベース・リソースURLの場合と同様に、実行時にOAMプロキシは、URLエンコーディングの後に問合せ文字列をポリシー・レイヤーに渡します。HTTP GETリクエストの一部である問合せ文字列のみが渡されます。問合せ文字列のパターンはHTTP POSTデータに適用されません。 |
|
ルール |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシーには、保護対象のリソースへのアクセスを許可または拒否するかどうかを定義したルールが含まれています。 ルールは、次で説明されている認可条件を参照します。 関連項目: 認可ポリシー・ルールおよび条件の概要 |
ポリシーは(いくつかのポリシー要素の中で)認証ルールを使用して定義します。認可ルールの概要は次のとおりです。
各ルールは、誰(どのユーアー、グループまたはIP4アドレス)がアクセスを許可または拒否されるか、およびそのルールが適用される期間を指定します。 また、許可を拒否よりも優先するかどうかの条件も指定できます。 |
|
条件 |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシー・ルールは、ルールの適用対象、時間の条件が存在するかどうか、および評価結果の適用方法を定義する条件を参照します。 条件は、ルールの外部で宣言され、ルール内から参照されます。 関連項目: 認可ポリシー・ルールおよび条件の概要 |
N/A |
IAMSuiteAgentは、OAMサーバーに対して集中ログアウトを行うために必要なログアウト・パラメータによって事前構成されています。IAMSuiteAgentは10g Webgateに似ていますが、構成の必要があるlogout.htmlページがありません。かわりに、IAMSuiteAgentにはデプロイ済のアプリケーション(oamsso_logout)が同梱されており、エージェントはこれを使用してログアウトします。
IAMSuiteAgentのログアウト機能を使用するには、IAMSuiteAgentを使用するサーバー上にoamsso_logoutアプリケーションがデプロイされている必要があります。最初のインストール時には、このアプリケーションはAdminServerとOAMサーバーに追加されます。ただし、このアプリケーションのターゲット・サーバーを更新して、IAMSuiteAgentを使用しているすべてのサーバーを含めることが必要です。
IAMSuiteAgentのログアウトの構成手順
WebLogicサーバーの管理コンソールにログインします。
「ドメイン」→「デプロイメント」→「oamsso_logout」→「ターゲット」へナビゲートします。
IAMSuiteAgentが有効でログアウトが実行されるすべてのサーバーを選択します。たとえば、oim_server、oaam_admin、oaam_serverなどです。
「保存」をクリックします。
次の項目へ進みます。
レガシー10g Webgateがインストールされているか、Access Manager 11gで使用する新しい10g Webgateインスタンスをインストールするかにかかわらず、Access Manager 11gの認証および認可サービスを使用するようにWebgateを登録する必要があります。
Oracle Access Managementコンソールまたはリモート登録ツールを使用して、このタスクを実行できます。リモート登録ツールでは、テンプレートを使用して、登録前にすべてのWebgateパラメータを指定できます。
次の手順によって、リモート登録ツールを使用してインバンド・モードでのプロビジョニングのウォーク・スルーが行えます。この例では、OAMRequest_short.xmlをテンプレートとして使用してmy-10g-agent1という名前のエージェントを作成し、/.../*の保護と、パブリック・リソース、/public/index.htmlの宣言を行います。実際の値はこれとは異なります。完全な登録テンプレートを使用して、パブリック・リソース、プライベート・リソースおよび除外されたリソースを指定できます。
Access Manager 11g用の10g Webgateでリモート登録を使用する手順
リモート登録ツールを入手して、環境に合ったスクリプトを設定します。例:
次のパスにあるRREG.tar.gzファイルを探します。
$ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz
RREG.tar.gzファイルを別な場所に解凍します。例: rreg/bin/oamregなど。
oamregスクリプト(oamreg.batまたはoamreg.sh)に、状況(クライアント側またはサーバー側)と 表14-5の情報に応じた次の環境変数を設定します。
登録リクエストを作成します。
OAMRequest_short.xmlを探して、新しいファイルにコピーします。例:
$OAM_REG_HOME/input/OAMRequest_short.xml/
コピー元: OAMRequest_short.xml
コピー先: my-10g-agent1.xml
環境の詳細情報を含むように、my-10g-agent1.xmlを編集します。例:
<OAMRegRequest>
<serverAddress>http://ruby.uk.example.com:7001</serverAddress>
<hostIdentifier>my-10g</hostIdentifier>
<agentName>my-10g-agent1</agentName>
<autoCreatePolicy>true</autoCreatePolicy>
<primaryCookieDomain>.uk.example.com</primaryCookieDomain>
<logOutUrls>
<url>/oamsso/logout.html</url>
</logOutUrls>
</OAMRegRequest>
エージェントを登録します。例:
リモート登録スクリプトを探します。
Windowsの場合: rreg\bin\oamreg.bat
スクリプトが含まれているディレクトリから、インバンド・モードを使用してスクリプトを実行します。例:
$ ./bin/oamreg.sh inband input/my-10g-agent1.xml
Welcome to OAM Remote Registration Tool! Parameters passed to the registration tool are: Mode: inband Filename: ...
プロンプトが表示されたら、環境に応じた値を使用して次の情報を入力します。
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
最後のメッセージを確認して、登録が成功したことを確かめます。
Inband registration process completed successfully! Output artifacts are created in the output folder"
登録時に作成されたObAccessClient.xmlファイルは、ここでは無視します。
Oracle Access Managementコンソールにログインして、次のようにリソースを新しい登録に追加します。
「システム構成」タブの「Access Manager」セクションで、次のノードを開いて「検索」コントロールを表示します。
「検索」コントロールを使用して、目的のWebgate登録ページを見つけて、そのページを開くために「結果」表内の名前をクリックします。
OAMプロキシ・ポート: 「システム構成」タブの「共通構成」セクションで、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが実行中のポートを検索します(表5-3を参照)。
リソースをアプリケーション・ドメインに追加します(表18-1)。
それぞれの環境で必要に応じて次に進んでください。
Webgateの終了: 「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」
アンインストールしたWebgate: 「Access Manager 11g用の最新の10g Webgateの検索およびインストール」
オプション: 「10g OAMエージェントのリモート登録」
この項では、「エージェントのリモート更新の概要」で説明したリモート登録テンプレートとモードを使用して、OAM 10gエージェントを更新、検証および削除する方法について説明します。
OAM 10gエージェント登録をリモート更新するには
「リモート登録ツールの取得および設定」の説明に従って、登録ツールを設定します。
エージェントの更新:
OAMUpdateAgentRequest.xmlテンプレートを使用して、更新リクエストを作成します。
エージェントをホストしているコンピュータで、agentUpdateモードで次のコマンドを実行し、入力ファイルとして独自の*Request*.xmlを指定します。例:
./bin/oamreg.sh agentUpdate input/*OAMUpdateAgentRequest.xml
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージで成功したことを確認します。
次のように、エージェント・ホストObAccessClient.xmlを再配置します。
再配置元AdminServer(コンソール)ホスト: /rreg/output/Agent_Name/
再配置先エージェント・ホスト: $10gWG_install_dir/oblix/lib例:
このエージェントをホストするOAMサーバーを再起動します。
エージェントの検証:
エージェント・ホストで、agentValidateモードで次のコマンドを実行します。例:
./bin/oamreg.sh agentValidate agentname
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージで成功したことを確認します。
エージェントの削除:
エージェントをホストしているコンピュータで、次のagentDeleteコマンドを実行します。例:
./bin/oamreg.sh agentDelete agentname
求められた場合に登録管理者ユーザー名およびパスワードを入力します。
画面のメッセージで成功したことを確認します。
成功: 画面のメッセージを確認します。
AgentDeleteプロセスは正常に完了しました。
Access Manager 11gで使用する新規10g Webgateをインストールする場合は、この項の手順を使用します。それ以外の場合は、この項はスキップして「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に進みます。
表23-4に、10g Webgateのインストール開始前に満たしておく必要のある要件を示します。
表23-4 Access Manager 11gで使用する10g Webgateのインストールの準備
| 情報 | 説明 |
|---|---|
|
サポートされている最新のWebgate |
Access Manager 11gでは、サポートされている最新の10g (10.1.4.3) Webgateを必ず使用してください。ただし、該当する10g (10.1.4.3) Webgateが提供されていない場合は、その次に新しいWebgate 10g (10.1.4.2.0)を使用してください。 |
|
インストール場所 |
次の場所を検討してください。
|
|
ユーザー・アカウント |
Webgateのインストールに使用するアカウントは、Webgateを実行するアカウントとは異なります。
|
|
rootレベルとサイト・レベル |
|
|
トランスポート・セキュリティ・モード |
インストールするエージェントと同じモードを使用するように、1つ以上のOAMサーバーを構成していることを確認します。 付録Cも参照してください |
|
コンピュータ・レベルと仮想Webサーバー・レベル |
Webgateは、コンピュータ・レベルまたは仮想Webサーバー・レベルで実行するように構成できます。コンピュータ・レベルと仮想Webサーバー・レベルの両方にインストールしないでください。 |
|
Oracle HTTP Server Webサーバー: |
Oracle HTTP Server用の10g Webgateは、オープン・ソースApacheに基づいています。Webgateパッケージ名には次が含まれています。
|
|
Access Manager 11gは、SSLが有効または無効なApacheをサポートするコンポーネント用に単一パッケージを提供しています。
注意: SSL対応の通信用に、Access ManagerはApache-SSLではなく、mod_sslのApacheのみをサポートしています。mod_sslはApache-SSLから派生した代替品です。 |
|
|
IHS2_WebgateはIBM-AIX上でApache v2により稼動しています。Access Managerは、SSLが有効または無効なIHS v2およびIHS v2リバース・プロキシ・サーバーをサポートしています。 詳細は第24章を参照してください |
|
|
10g WebgateをDomino Webサーバーにインストールする前に、Domino Enterprise Server R5を正しくインストールし、設定しておく必要があります。 |
|
|
Webgateのインストール前に、IIS Webサーバーがロック・ダウン・モードになっていないことを確認します。これを行わなかった場合、サーバーが再起動され、メタベースが再度初期化され、IISがロック・ダウン後に発生したアクティビティを無視するまで、問題なく稼動しているように見えます。 クライアント証明書認証を使用している場合は、Webgateに対してクライアント証明書を有効にする前に、WebgateをホストするIIS WebサーバーでSSLを有効にする必要があります。 NTFSをサポートしているファイル・システム上にインストールする場合にかぎり、IIS Webgate用に/accessディレクトリの各種許可を設定する必要があります。たとえば、FAT32ファイル・システムを実行しているWindows 2000コンピュータで、簡易または証明書モードでISAPI Webgateをインストールすると仮定します。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示を無視できます。 各IIS仮想Webサーバーには、独自のWebgate.dllファイルを仮想レベルでインストールするか、全サイトに影響を与える1つのWebgateをサイト・レベルでインストールできます。Webgate.dllをサイト・レベルでインストールしてすべての仮想ホストを制御するか、Webgate.dllを1つまたはすべての仮想ホストに対してインストールします。 コンピュータ・レベルでpostgate.dllファイルをインストールする必要もあります。postgate.dllは、「ポストゲートISAPIフィルタのインストール」で説明しているように、\Webgate_install_dir内にあります。複数のインストールを実行すると、このファイルのバージョンが複数作成されることがあり、そのためにAccess Managerの動作に異常が現れる可能性があります。この場合は、webgate.dllとpostgate.dllが1つずつ存在していることを検証する必要があります。 関連項目: 第26章「10g Webgate用のIIS Webサーバーの構成」 削除: Webgateおよび関連するファイルをIISから完全に削除するには、IIS内のリストからフィルタを削除するだけでは不十分です。IISにはすべての設定がメタベース・ファイルに含まれています。Windows 2000以降では、これは手動で変更できるXMLファイルです。メタベースを編集するためのツールとして、MetaEditも提供されています。MetaEditはRegeditに似ており、一貫性チェッカとブラウザ/エディタが含まれています。WebgateをIISから完全に削除するには、MetaEditを使用してメタベースを編集します。 |
|
|
ISAプロキシ・サーバー上では、すべてのISAPIフィルタをISAインストール・ディレクトリ内にインストールする必要があります。ISAインストール・ディレクトリ構造内の任意の場所でかまいません。
|
必要に応じて、次の手順を使用して10g Webgateを取得します。ご使用のWebサーバーに適したインストール・パッケージを選択してください。
10g Webgateを検索およびダウンロードする手順
次のOracle Technology Networkで、最新のOracle Access Manager 10g証明書を確認します。
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
次のOracle Fusion Middleware 11gR1ソフトウェア・ダウンロードに移動します。
http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html
ページの一番上のライセンス契約に同意をクリックします。
Access Manager Webgates (10.1.4.3.0)の行から、該当するプラットフォームのダウンロード・リンクをクリックし、画面の指示に従います。
インストールする10gアクセス・システムの言語パックに、Webgateインストーラを格納します。
「Webgate 10gのインストールの開始」に進みます。
次の手順によって、Webサーバー・タイプに関係なく共通のウォーク・スルーを行います。
インストール・オプションを識別し、自分の環境に合わない場合はスキップできます。Webgateのインストール中は、特定の時点で情報が保存されます。Webgateのインストール処理は必要に応じて取り消すことができます。ただし、Webgateのインストールを知らせるメッセージを受領後にWebgateのインストールを取り消す場合は、コンポーネントのアンインストールが必要です。
|
注意: HP-UXおよびAIXシステムでは、-is:tempdirパス・パラメータを使用して、十分な領域があるディレクトリにインストールを指示できます。パスは、十分な領域があるファイル・システムへの絶対パスでなければなりません。 |
Webgate 10gをホスティングするコンピュータ上で、Webサーバーの管理者権限のあるユーザーとしてログインします。
Webサーバー・インスタンスを停止します。
該当するプラットフォーム、インストール・モード、Webサーバー用のWebgateインストーラを起動します。例:
GUIメソッド:
Windows— Oracle_Access_Manager10_1_4_3_0_Win32_API_Webgate.exe
コンソール・メソッド:
Solaris—./ Oracle_Access_Manager10_1_4_3_0_sparc-s2_API_Webgate Linux—./ Oracle_Access_Manager10_1_4_3_0_linux_API_Webgate
ここでAPIは、Webサーバーで使用するAPI (IIS Webサーバーの場合はISAPIなど)を示します。
「ようこそ」画面を閉じます(管理者権限で画面に表示された指示に従います)。
Webgateのインストール・ディレクトリを指定します。
LinuxまたはSolaris: このコンピュータ上のGCCランタイム・ライブラリの場所を指定します。
言語パック - デフォルトのロケールとインストールするその他のロケールを選択して、次へをクリックします。
プレゼンテーション・ワークシートにインストール・ディレクトリをまだ記録していない場合は記録し、次へをクリックして続行します。
Webgateのインストールが開始し、数秒間かかることがあります。Windowsシステムでは、Microsoft管理インタフェースの構成を知らせる画面が表示されます。
インストール・プロセスはまだ完了していません。トランスポート・セキュリティ・モードの指定を求められます。この時点では、情報のリストアに戻れません。
必要に応じて、ダウンロード済のGCCライブラリを解凍した場所を指定します。
少なくとも1つのOAM Server間のトランスポート・セキュリティは一致する必要があります。
Webgate用に、「オープン」、「簡易」または「証明書」を選択します。
指定したトランスポート・セキュリティ・モードに従って進みます。
簡易または証明書モード - 「セキュアな通信のための証明書のリクエストまたはインストール」に進みます。
オープン・モード - 「Webgate Webサーバー構成の更新」までスキップします。
Access Manager 11g環境でオープン・モード・トランスポート・セキュリティを使用する場合は、「Webgate Webサーバー構成の更新」までスキップできます。
Webgate証明リクエスト: OAMサーバーに信頼されているルートCAに送信する必要があるリクエスト・ファイル(aaa_req.pem)を生成します。ルートCAは、Webgate用にインストール可能な署名付きの証明書を返します。
リクエストした証明書を\Webgate_install_dir\access\oblix\configディレクトリにコピーし、Webgate Webサーバーを再起動する必要があります。
Webgate 10g用の証明書をリクエストまたはインストールする手順
証明書をリクエストするのか、インストールするのかを指定し、次へをクリックして続行します。例:
証明書をリクエストする場合は、手順2に進みます。
証明書をインストールする場合は、手順3に進みます。
リクエストされた情報を入力し、次に次へをクリックして、証明書のリクエストをCAに発行します。
証明書のファイルの場所が表示された場合は、それを記録します。
証明書がある場合ははいをクリックして、手順3から続行します。それ以外の場合は、「Webgate Webサーバー構成の更新」までスキップします。
インストール中に証明書をインストールする場合: 次のファイルへの絶対パスを指定して、次へをクリックします。
Webgate_install_dir\access\oblix\config
cacert.pemはOracleが提供したopenSSL認証局の署名を受けた証明書リクエストです。
password.xmlには、インストール中に指定されたランダムなグローバル・パスフレーズが不明瞭化された形式で含まれています。これを使用して、他の顧客が同一CAを使用しないようにします。Access Managerは、OAM AgentとOAM Server間の初期ハンドシェイク中に追加のパスワード・チェックを行います。
aaa_key.pemには秘密鍵(openSSLによって生成)が含まれています。
aaa_cert.pemはPEM形式の署名済証明書です。
「Webgate Webサーバー構成の更新」に進みます。
Access Manager 11gでのWebgateのプロビジョニングと登録の間に指定した情報を使用して次のタスクを実行します。
アクセス・システム・コンソールで指定した、Webgateに必要な情報を提供します。
次へをクリックして続行します。
WebサーバーがWebgateと連動するように構成する必要があります。インストール時に自動的にWebサーバー構成を更新することをお薦めします。ただし、自動および手動の両方の更新手順が含まれています。
|
注意:
|
はいをクリックしてWebサーバーの自動更新を行い、次へをクリックします(またはいいえをクリックして「Webサーバーの手動構成」を参照します)。
ほとんどのWebサーバー - Webサーバー構成ファイルを含むディレクトリの絶対パスを指定します。
IIS Webサーバー - プロセスがすぐに開始し、1分以内に終了します。詳細は、第26章「10g Webgate用のIIS Webサーバーの構成」を参照してください。
続行する前に特殊な指示があるかもしれません。NTFSをサポートしているファイル・システム上にインストールする場合にかぎり、IIS Webgate用に/accessディレクトリの各種許可を設定する必要があります。最後のインストール・パネルには、FAT32ファイル・システムに設定できない各種の許可を手動設定するための指示が表示されます。この場合、これらの指示を無視できます。
Webサーバーの構成が更新されたことを知らせる画面が表示されます。
「次へ」をクリックして「Webgateのインストール終了」に進みます。
Webgateのインストール中にWebサーバーの自動更新を取り消した場合は、手動でタスクを実行する必要があります。
|
注意: Webgateのインストール中に手動構成プロセスを起動した場合は、次のステップ1をスキップできます。 |
Webブラウザを起動し、必要に応じて次のファイルを開きます。例:
\Webgate_install_dir\access\oblix\lang\langTag\docs\config.htm
ここで、\Webgate_install_dirはWebgateがインストールされているディレクトリです。
|
注意: 64ビットのWebgateインストール中にIISの手動構成を選択した場合は、次のパスで詳細を入手できます。 Webgate_install_dir\access\oblix\lang\en-us\docs\dotnet_isapi.htm |
サポートされているWebサーバーから選択し、各Webサーバー・タイプに固有のすべての指示に従います。
Webgateの設定中に修正が必要なファイルのバックアップ・コピーを作成し、やり直しが必要になる場合に備えます。
Webサーバーが該当するAccess Managerファイルを認識できるように、元の設定指示に戻って、すべての指示内容を完了したことを確認します。
|
注意: 間違ってウィンドウを閉じてしまった場合は、手順1に戻って、該当するリンクを再度クリックします。一部の設定では新しいブラウザ・ウィンドウが開いたり、コマンドウィンドウへの入力が求められることがあります。 |
「Webgateのインストール終了」に進みます。
ReadMe情報に、マニュアルとOracleに関する詳細が記載されています。
ReadMeの情報を確認し、次に次へをクリックして閉じます。
終了をクリックして、インストールを終了します。
Webサーバーを再起動して構成の更新を反映します。
先に次のトピックに進んでから、アーティファクトと証明書をインストールします。
ネイティブPOSIXスレッド・ライブラリ: NPTLを使用する場合は、Access ManagerのWebgateのインストール時に、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。
Apache2、OHS2、IHS2 Webサーバー: 第24章「Apache、OHS、IHSの10g Webgate用の構成」
IIS Webサーバー: Webgateのインストール後に、net stop iisadminおよびnet start w3svcを使用してメタベースが破損していないことを確認します。第26章「10g Webgate用のIIS Webサーバーの構成」も参照してください。
ISA Webサーバー: 第25章「10g Webgate用のISAサーバーの構成」
Lotus Domino Webサーバー: 第27章「10g Webgate用のLotus Domino Webサーバーの構成」
「アーティファクトと証明書のインストール」に進みます。
ObAccessClient.xmlファイルはプロビジョニングで生成されるものの1つです。Webgateのインストール後、このファイルをWebgateインストール・ディレクトリ・パスにコピーする必要があります。Webgateのインストール後に署名済のWebgate 10g証明書を受領した場合、次の手順に従ってインストールできます。
前提条件
Webサーバーの構成
Webgate 10g用のアーティファクト(および証明書)をインストールする手順
Webgate 10gのプロビジョニング・アーティファクト(および必要に応じて証明書ファイル)を入手します。例:
ObAccessClient.xml
password.xml(必要に応じて)
aaa_key.pem (openSSLによって生成された秘密鍵)。
aaa_cert.pem (PEM形式の署名済証明書)
Webgateホストにファイルをコピー: Webgate_install_dir\access\oblix\config
Webgate Webサーバーを再起動します。
WebgateのインストールとWebサーバーの更新後、Webgateの診断を有効にしてWebgateが正しく実行されていることを確認できます。
Webgateの診断確認手順
Access Manager 11gコンポーネントが稼動していること確認します。
Webgate診断用に次のURLを指定します。例:
ほとんどのWebサーバー - http(s)://hostname:port/access/oblix/apps/webgate/bin/webgate.cgi?progid=1
IIS Webサーバー - http(s)://hostname:port/access/oblix/apps/ webgate/bin/webgate.dll?progid=1
ここで、hostnameはWebgateをホストするコンピュータ名、portはWebサーバー・インスタンスのポート番号です。
Webgateの診断ページが表示されます。
成功した場合: Webgateの診断ページが表示される場合、Webgateが正常に機能しています。ページを閉じてください。「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に進みます。
失敗した場合: 「Access Manager 11gデプロイメントからの10g Webgateの削除」の説明に従って、Webgateをアンインストールして再インストールする必要があります。
この項では次のトピックを提供します:
次のプロセス概要では、Access Managerの集中ログアウト・プロセスを要約して示しますが、このプロセスが発生するのは、保護機能を果たす10g Webgateが構成されたWebサーバー上にアプリケーションがデプロイされたときです。
ログアウトは、登録されたOAMエージェント(この場合は10g Webgate)に対して構成されたlogout.htmlファイルがアプリケーションによって起動されると開始されます。
プロセス概要: 11g OAMサーバー使用時の10g Webgateの集中ログアウト
アプリケーションが、10g Webgateに対して構成されたlogout.htmlファイルを起動します。
アプリケーションはend_urlも問合せ文字列としてlogout.htmlに渡します。end_urlパラメータはURIまたはURLとすることができます。例:
/oamsso/logout.html?end_url=/welcome.html or /oamsso/logout.html?end_url=http://my.site.com/welcome.html
WebgateはそのドメインのObSSOCookieを削除して、logout.htmlスクリプトをロードします。
end_urlパラメータにhost:portが含まれていない場合、logout.htmlスクリプトはローカル・サーバーのhost:portを取得してend_urlパラメータをURLとして構成します。例:
http://serverhost:port/oam/server/logout?end_url=http://my.site.com/
welcome.html
logout.html内のロジックがOAMサーバーにリダイレクトします。例:
http://myoamserverhost:port/oam/server/logout?end_url=http://my.site.com/
welcome.html
OAMサーバーが以下のようにログアウトを実行します。
サーバー側のユーザーに関連付けられたセッション情報をクリーン・アップします。
end_urlを確認して、コールバックURLを含むページをユーザーのブラウザに送信します。
|
注意:
|
コールバック・ページから、各Webgateの特定URIに対して新しいリクエストが開始されます。このリクエストが特定ドメインの特定Webgateに届くと、そのドメインのObSSOCookieは消去されます。
ユーザーは、ログアウト・スクリプト内のend_urlにリダイレクトされます。ただし、end_urlパラメータがない場合はOAMサーバーによって適切なメッセージが送信されます。
詳細は、「11g OAMサーバー使用時の10g WebGateの集中ログアウト・スクリプトについて」を参照してください。
10g Webgateでは、シングルおよびマルチ両方のDNSドメイン集中ログアウト処理にlogout.htmlスクリプトが必要です。logout.htmlは、実際にログアウトを行うJavaScriptsをアクティブにします。
|
注意: 11g Webgateではlogout.htmlスクリプトを使用しないかわりに、「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に示すようにエージェント登録をさらに詳細に構成する必要があります。 |
例23-1は、ユーザー固有の環境に合せて一定の行を編集することによりテンプレートとして使用できる、logout.htmlスクリプトです(編集の必要性についてはスクリプトの最上部に記述されています)。たとえば、SERVER_LOGOUTURLを変更する必要があります。この例の後に追加的情報を示します。
例23-1 logout.htmlスクリプト
<html>
<head>
<script language="javascript" type="text/javascript">
///////////////////////////////////////////////////////////////////////////////
//Before using, you need to change the values of:
//a. "oamserverhost" to point to the host where the OAM Server is running.
//b. "port" to point to the port where the OAM Server is running.
///////////////////////////////////////////////////////////////////////////////
var SERVER_LOGOUTURL = "http://oamserverhost:port/oam/server/logout";
///////////////////////////////////////////////////////////////////////////////
function handleLogout() {
//get protocol used at the server (http/https)
var webServerProtocol = window.location.protocol;
//get server host:port
var webServerHostPort = window.location.host;
//get query string present in this URL
var origQueryString = window.location.search.substring(1);
var newQueryString = "";
//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;
if (origQueryString != null && origQueryString != "") {
params = origQueryString.split("&");
for (var i=0; i<params.length; i++) {
if (i == 0)
newQueryString = "?";
if (i > 0)
newQueryString = newQueryString + "&";
par = params[i].split("=");
//prepare a new query string, if the end_url value needs to be changed
newQueryString = newQueryString + (par[0]);
newQueryString = newQueryString + "=";
val = par[1];
if ("end_url" == par[0]) {
//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (val.substring(0,1) == "/" || val.substring(0,1) == "%") {
//modify the query string now
val = webServerProtocol + "//" + webServerHostPort + val;
}
}
newQueryString = newQueryString + val;
}
}
//redirect the user to this URL
window.location.href = SERVER_LOGOUTURL + newQueryString;
}
</script>
</head>
<body onLoad="handleLogout();">
</body>
</html>
プロセス概要: logout.htmlのロジック
着信リクエストからホストとポートを取得します。
問合せ文字列からend_urlパラメータを取得します。
end_urlパラメータがURLでない場合は、logout.htmlスクリプトがタスク1のホストとポートを使用してURLを作成します。「logout.html内のend_urlパラメータのガイドライン」を参照してください。
OAMサーバーのログアウトURL (SERVER_LOGOUTURL)へのリダイレクト。例: http://myoamserver/host:port/oam/server/logout
プロセス2で作成したend_urlを問合せ文字列として使用。
問合せ文字列内の他のすべての問合せ文字列パラメータを保存。
logout.html内のend_urlパラメータのガイドライン
end_urlパラメータはURIまたはURLとすることができます。
end_url問合せ文字列がホストとポートを持たないURIの場合、logout.htmlは、logout.htmlがホストされるWebサーバーのホストとポートを決定することによってURLを作成しなければなりません。例:
http://myoamserverhost:port/oam/server/logout?end_url=http://my
.site.com/welcome.html
end_urlパラメータがホストとポートを持つURLである場合、logout.htmlスクリプトは、URLを作り直すことなくそのURLをそのまま渡します。
|
注意: ADFアプリケーションは、「Oracle ADFコード・アプリケーションの集中ログアウト構成」に示すように、ログアウト後にユーザーをどこへリダイレクトするかを示す /<app context root>/adfAuthentication?logout=true&end_url=<any uri> |
logout.html内のログアウト・リンク指定方法を表23-5に示します。
次の手順では、Access Manager使用時の10g Webgateの集中ログアウト構成方法を示します。
|
注意: オプションのタスクや、マルチDNSドメインのログアウトだけに必要なタスクは識別されているので、必要な場合以外はスキップすることができます。 |
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』に記載された手順例には、WebLogic Serverドメインにアプリケーションをデプロイする手順が含まれています。
タスクの概要: 10g Webgateの集中ログアウトの構成
デフォルトのログアウト・ページ(logout.html)を作成し、Webgateインストール・ディレクトリ上でそのページを使用できるようにします。
例23-1「logout.htmlスクリプト」に基づいて、Webgate用のlogout.htmlを作成および編集します。
作成または編集したogout.htmlスクリプトを以下のディレクトリ・パスに保存します。
Webgate_install_dir/oamsso/logout.html
|
注意: logout.htmlを他の場所に置く場合は、エージェント登録時にログアウト・リンクを正しく指定してlogout.htmlファイルの正しい場所を参照するようにしてください。 |
必要に応じて以下のステップを実行します。
ステップ1にあるlogout.htmlで、ユーザーを11g OAMサーバー上のこの中央管理ログアウトのURI(/oam/server/logout)にリダイレクトする設定になっていることを確認します。
オプション: 「logout.html内のend_urlパラメータのガイドライン」に示すように、アプリケーションが、ログアウト後にユーザーがリダイレクトされる場所を示すend_urlパラメータを渡せるようにします。
10g Webgateが構成されているWebサーバー・ファイルを確認し、次の説明に従って適切な手順を実行します。
OHS Webサーバーのhttpd.confファイル: 次の行が存在する場合、それらを削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
その他のWebサーバーの構成ファイル: 次の行を追加します。
Alias /oamsso "WebgateInstallationDirectory/oamsso"
必要に応じて、次の手順を使用して、Access Manager 11gデプロイメントから10g Webgateを削除します。
|
注意: エージェントの登録を削除しても、関連付けられたホスト識別子、アプリケーション・ドメイン、リソースまたはエージェント・インスタンスは削除されません。 |
考慮事項
Webサーバーの構成変更: Webサーバーの構成変更は、Webgateのアンインストール後に手動で元に戻す必要があります。追加内容の詳細は、お使いのWebサーバーに該当する章を参照してください。
Webgate IISフィルタ: Webgateおよび関連するフィルタをIISから完全に削除するには、IIS内のリストからフィルタを削除するだけでは不十分です。IISにはすべての設定がメタベース・ファイルに含まれています。Windows 2000以降では、これは手動で変更できるXMLファイルです。詳細は、「Access Manager 11gデプロイメントからの10g Webgateの削除」を参照してください。
前提条件
このエージェントに関連付けられたアプリケーション・ドメイン、リソースおよびポリシーを評価し、別のエージェントを使用するように構成されているのか、削除できるのかを確認してください。
削除するWebgateのWebサーバーを無効にします。
|
注意: Webサーバーを無効にしなかった場合、アンインストールは失敗し、バックアップ・フォルダは削除されません。この場合、バックアップ・フォルダを手動で削除する必要があります。 |
Oracle Access ManagementコンソールのWebgate登録ページで、「状態」オプションの横の「無効」ボックスをクリックしてWebgateを無効化します。
言語パック: インストールされている言語パック(デフォルトの管理者言語(ロケール)として選択されているものを除く)を次のように削除します。
コンポーネントのアンインストール・ディレクトリ内にある、該当する言語パックを検索します。例:
言語パック・アンインストーラ・プログラムを実行して、ファイルを削除します。
このプロセスを繰り返し実行して、関連するコンポーネントから同じ言語パックを削除します。
Webgate Webサーバーを停止して再起動し、適切な言語サポートを再初期化します。
このプロセスを繰り返し実行して、各言語パックを削除します(デフォルトの管理者言語(ロケール)として選択されているものを除く)。
次の手順を実行して10g Webgateの構成データを削除します。
Access Managerコンポーネントのインスタンスが1つしかない場合は、手順4を完了して削除します。
コンポーネントのインスタンスが複数ある場合は、手順5も参照してください。
特定のプログラムのアンインストール・プログラムを検索して実行し、Access Managerファイルを削除します。例:
Webgate_install_dir\access\_uninstWebgate\uninstaller.exe
|
注意: UNIXシステムではuninstaller.binを使用します |
複数のインスタンス: 複数のWebgateインスタンスがあり、そのうちの1つ、またはすべてを削除する場合は、プラットフォーム固有のメソッドを使用する必要があります。
Windows: 最後のコンポーネントは、プログラムの追加/削除でアンインストールできます。それ以外は、\access \uninstComponentディレクトリからアンインストール・プログラムを実行してアンインストールできます。
UNIX: 常にuninstaller.binを実行する必要があります。
Webサーバー構成に対するAccess Manager関連の更新を削除します。特定のWebサーバーに関する詳細は、第24章、 第26章、第25章、および第27章を参照してください。
Webサーバーを再起動します。
特に再インストールを予定している場合、Webgate_install_dirディレクトリが残っていれば削除します。
