| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2) B69533-02 |
|
 前へ |
 次へ |
『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のインストールにはいくつかの違いがあります。表22-1に違いをまとめます。
表22-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の技術を使用して、分散されて集中化された信頼のできるセッション管理が可能です。
表22-2は、Access Manager 11gと10gの比較を示しています。Access Manager 11gで変更された名前のリストについては、「11.1.2で変更された製品およびコンポーネントの名前」を参照してください。
表22-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 |
|
|
|
レスポンス・トークンの再生防止 |
|
なし |
|
複数のネットワーク・ドメインのサポート |
ネットワーク間ドメインの設定不要なシングル・サインオン。 複数のネットワーク・ドメインをサポートする場合は、Oracle Federationを使用することをお薦めします。 |
独自の複数のネットワーク・ドメインSSO機能が、Oracle Identity Federationより前から存在します。これが10gデプロイメントに実装されている場合、10gエージェントをAccess Manager 11gに登録すればこのサポートを引き続き受けられます。
|
|
一元化されたログアウト |
第19章を参照してください。 |
10g WebgateとAccess Manager 11gを併用する場合、logout.htmlでは特定の詳細が必要です。第19章を参照してください。
|
明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。
Access Manager 10gは、ポリシー・ドメイン内のポリシーに基づく認証と認可を提供します。アクセス・サーバーへのWebgate問合せの数を制限するためにアクセスを明示的に拒否したルールまたはポリシーでリソースが保護されなかった場合Access Manager 10gのデフォルトの動作ではアクセスが許可されていました。
表22-3は、Access Manager 11gポリシー・モデルと10gモデルを比較しています。明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Manager 11gのデフォルトの動作でアクセスが拒否されます。対照的に、Access Manager 10gのデフォルトの動作では、リソースがアクセスを明示的に指定するルールやポリシーによって保護されていない場合に、アクセスが許可されていました。
表22-3 Access Manager 11gと10gのポリシー・モデルの比較
| ポリシーの要素 | 11gポリシー・モデル | 10gポリシー・モデル |
|---|---|---|
|
ポリシー・オーサリング |
Oracle Access Managementコンソール |
ポリシー・マネージャ |
|
ポリシー・ストア |
データベース |
LDAPディレクトリ・サーバー |
|
ドメイン |
アプリケーション・ドメイン |
ポリシー・ドメイン |
|
リソース |
|
|
|
ホスト識別子 |
|
|
|
認証ポリシー |
|
|
|
認証スキーム |
認証スキームはグローバルに定義され、共有されます(認証ポリシー内から参照できます)。 信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。 注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。 関連項目: 表16-19 認証スキームの定義 |
認証スキームをポリシーの外部で定義し、認証ポリシー内で参照できます。 |
|
認可ポリシー |
1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。ポリシーには、それぞれ1つ以上の条件およびルールを含めることができます。 関連項目: 「ルール」、この表の以降の項目および「特定のリソースの認証ポリシーの定義」 |
リソースを保護するには、1つ以上の条件を含んだ認可ルールを定義します。また、1つ以上の認可ルール使用する認可条件式を構成します。ポリシー・ドメイン(およびポリシー)には、それぞれ1つの認可条件式のみを含めることができます。 |
|
トークン発行ポリシー |
生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。条件やルールは自動的に生成されません。これらは手動で追加する必要があります。 関連項目: トークン発行ポリシー・ページについて |
なし |
|
レスポンス |
すべてのポリシー・タイプで使用可能。
|
|
|
Cookie |
関連項目: 表15-8 および |
関連項目: 表15-8 および |
|
問合せ文字列ベースのHTTPリソース定義 |
アクセス・ポリシー内でサポートされます。表17-1「リソース定義の要素」を参照してください。 |
このポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。 ベース・リソースURLの場合と同様に、実行時にOAMプロキシは、URLエンコーディングの後に問合せ文字列をポリシー・レイヤーに渡します。HTTP GETリクエストの一部である問合せ文字列のみが渡されます。問合せ文字列のパターンはHTTP POSTデータに適用されません。 |
|
ルール |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシーには、保護対象のリソースへのアクセスを許可または拒否するかどうかを定義したルールが含まれています。 ルールは、次で説明されている認可条件を参照します。 関連項目: 認可ポリシー・ルールおよび条件の概要 |
ポリシーは(いくつかのポリシー要素の中で)認証ルールを使用して定義します。認可ルールの概要は次のとおりです。
各ルールは、誰(どのユーアー、グループまたはIP4アドレス)がアクセスを許可または拒否されるか、およびそのルールが適用される期間を指定します。 また、許可を拒否よりも優先するかどうかの条件も指定できます。 |
|
条件 |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシー・ルールは、ルールの適用対象、時間の条件が存在するかどうか、および評価結果の適用方法を定義する条件を参照します。 条件は、ルールの外部で宣言され、ルール内から参照されます。 関連項目: 認可ポリシー・ルールおよび条件の概要 |
なし |
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)に、状況(クライアント側またはサーバー側)と 表13-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を参照)。
リソースをアプリケーション・ドメインに追加します(「表17-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の集中ログアウト構成」に進みます。
表22-4に、10g Webgateのインストール開始前に満たしておく必要のある要件を示します。
表22-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リバース・プロキシ・サーバーをサポートしています。 詳細は第23章を参照してください |
|
|
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つずつ存在していることを検証する必要があります。 関連項目: 第25章「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インストーラを起動します。例:
「ようこそ」画面を閉じます(管理者権限で画面に表示された指示に従います)。
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分以内に終了します。詳細は、第25章「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サーバー: 第23章「Apache、OHS、IHSの10g Webgate用の構成」
IIS Webサーバー: Webgateのインストール後に、net stop iisadminおよびnet start w3svcを使用してメタベースが破損していないことを確認します。第25章「10g Webgate用のIIS Webサーバーの構成」も参照してください。
ISA Webサーバー: 第24章「10g Webgate用のISAサーバーの構成」
Lotus Domino Webサーバー: 第26章「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の集中ログアウト構成」に示すようにエージェント登録をさらに詳細に構成する必要があります。 |
例22-1は、ユーザー固有の環境に合せて一定の行を編集することによりテンプレートとして使用できる、logout.htmlスクリプトです(編集の必要性についてはスクリプトの最上部に記述されています)。たとえば、SERVER_LOGOUTURLを変更する必要があります。この例の後に追加的情報を示します。
例22-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内のログアウト・リンク指定方法を表22-5に示します。
次の手順では、Access Manager使用時の10g Webgateの集中ログアウト構成方法を示します。
|
注意: オプションのタスクや、マルチDNSドメインのログアウトだけに必要なタスクは識別されているので、必要な場合以外はスキップすることができます。 |
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』に記載された手順例には、WebLogic Serverドメインにアプリケーションをデプロイする手順が含まれています。
タスクの概要: 10g Webgateの集中ログアウトの構成
デフォルトのログアウト・ページ(logout.html)を作成し、Webgateインストール・ディレクトリ上でそのページを使用できるようにします。
例22-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"
IAMSuiteAgentを10g Webgateと入れ替えていない場合は、この項をスキップしてください。
Access ManagerおよびOracle Identity Managerは、Oracle Fusion Middleware 11gコンポーネントの一部です。WebLogicサーバー構成ウィザードの初期構成中に、IAMSuiteAgentがIDMドメイン・ホスト識別子およびそのエージェントに指定されたアプリケーション・ドメインとともにAccess Manager 11gに登録されます。
Oracle Fusion MiddlewareはIAMSuiteAgentを使用して、保護されたOracle Identity ManagementコンソールにAccess Manager 11gをそのまま使用します。
コンテナ外のアプリケーションを保護するために、IAMSuiteAgentを10g Webgateに入れ替えることができます(事前登録済のIAMSuiteAgentと同じアプリケーション・ドメインとポリシーを使用して、同じアプリケーション・セットを保護する場合)。
タスクの概要: IAMSuiteAgentの10g Webgateへの置換
オプション: WebLogic用のOAMセキュリティ・プロバイダの構成
オプション: IAMSuiteAgentの無効化
次に示す手順では、帯域内モードでリモート登録ツールを使用して、入替え用10g Webgateを登録する方法を順に説明します。
この例では、OAMRequest_short.xmlをテンプレートとして使用して、10g4IDMという名前のエージェントを作成し、/.../*の保護と、パブリック・リソース/public/index.htmlの宣言を行います。実際の値はこれとは異なります。
|
注意: 入替え用のWebgateでIAM Suiteポリシーを使用するには、IAMSuiteAgentホスト識別子と優先ホストを使用するようにWebgateの登録が構成されていることを確認します。 |
10g Webgateを入替え用のIAMSuiteAgentに登録するには:
リモート登録ツールを入手して、環境に合ったスクリプトを設定します。例:
次のパスにあるRREG.tar.gzファイルを探します。
ORACLE_HOME/oam/server/rreg/client/RREG.tar.gz
RREG.tar.gzファイルを別な場所に解凍します。例: rreg/bin/oamregなど。
oamregスクリプトに、状況(クライアント側またはサーバー側)と 表13-5の情報に応じた次の環境変数を設定します。
登録リクエストを作成し、autoCreatePolicyパラメータがfalseに設定されていることを確認します。
OAMRequest_short.xmlを探して、新しいファイルにコピーします。例:
WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
コピー元: OAMRequest.xml
コピー先: 10g4IAM.xml
環境の詳細を含むように、10g4IAM.xmlを編集します。たとえば、IAMSuiteAgentから10g Webgateエージェントに変更する場合は、次のようなリクエストになります。
<OAMRegRequest>
<serverAddress>http://ruby.uk.example.com:7001</serverAddress>
<hostIdentifier>10g4IAM</hostIdentifier>
<agentName>10g4IAM</agentName>
<autoCreatePolicy>false</autoCreatePolicy>
<primaryCookieDomain>.uk.example.com</primaryCookieDomain>
<logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
...retain defaults for remaining elements...
...
...
</OAMRegRequest>
エージェントを登録します。例:
リモート登録スクリプトを探します。
Windowsの場合: rreg\bin\oamreg.bat
スクリプトが含まれているディレクトリから、インバンド・モードを使用してスクリプトを実行します。例:
$ ./bin/oamreg.sh inband input/10g4IAM.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"
Oracle Access Managementコンソールにログインして、新規登録を確認します。
「システム構成」タブの「Access Manager」セクションで、次のノードを開きます。
エージェント名をダブルクリックして、登録ページを表示し、詳細を確認します(新規Webgateをインストールする場合は、インストール中に次の詳細を入力する必要があります)。例:
エージェント名—Webgateのインストール中にWebgate IDとして入力します。
アクセス・クライアント・パスワード—Webgateのインストール中に、Webgateのパスワードとして入力します。パスワードを入力しない場合は、このフィールドを空白にしておきます。
アクセス・サーバー・ホスト名—このWebgateを登録するプライマリOAMサーバーのDNSホスト名を入力します。
OAMプロキシ・ポート: 「システム構成」タブの「共通構成」セクションで、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが実行中のポートを検索します。
プロビジョニングの結果作成されるObAccessClient.xmlファイルは無視してください。
「WebLogicサーバー・プラグインの更新」に進みます。
プロビジョニング後、IAMSuiteAgentと入れ替えるために10g Webgateをインストールする必要があります。インストール中は、プロビジョニング時と同じWebgateの情報を提供する必要があります。
前提条件
IAMSuiteAgentの入替え用10g Webgateの登録
IAMSuiteAgentの入替え: 「WebLogicサーバー・プラグインの更新」に進みます。
10g Webgateのプロビジョニングとインストールを行い、IAMSuiteAgentと入れ替えたら、mod_wl_ohs.confファイルに特定の入力をして、Webgate WebサーバーがWebLogicサーバー上のアプリケーションにリクエストを転送するように指示する必要があります。
|
注意: WebLogicサーバーのApache用プラグインの汎用名はmod_weblogicです。Oracle HTTP Server 11gの場合は、このプラグインの名前はmod_wl_ohsです(実際のバイナリ名はmod_wl_ohs.soです)。例では実装のための正確な構文を示します。 |
例22-2では入力サンプルを使用して変更が必要な部分を示します。使用する環境によって入力内容は異なります。
例22-2 mod_wl_ohs.confでの10g Webgate用の更新
<IfModule weblogic_module> <Location /oamconsole> SetHandler weblogic-handler WebLogicHost ruby.uk.example.com WebLogicPort 6162 </Location> <Location apmmconsole> SetHandler weblogic-handler WebLogicHost ruby.uk.example.com WebLogicPort 6162 </Location> ... </IfModule>
|
注意: WebLogicサーバーで直接アクセスしたことがあるすべてのアプリケーションの各URIに対して、類似の場所エントリが必要です。 |
前提条件
IAMSuiteAgentの入替え用10g Webgateのインストール
環境に合ったmod WebLogic構成の更新手順
次のパスにあるmod_wl_ohs.confファイルを探します。
OHS-INSTANCE_HOME/config/OHS/INSTANCE_NAME/mod_wl_ohs.conf
WebLogicサーバーで直接アクセスしたことがあるすべてのアプリケーションの各URIに対して、Location要素を含むようにファイルを編集します(例22-2を参照)。
ファイルを保存します。
Webサーバーを再起動します。
必要に応じて次のタスクに進みます。
このトピックではAccess ManagerがOracle Identity Manager(OIM)と統合されている場合に、OIMの自動ログイン機能を確認(または構成)する方法を説明します。
|
注意: Access Manager 11gをOracle Identity Manager 11gに統合していない場合、この手順は省略します。 |
Oracle Identity ManagerがAccess Manager 11gに統合されている場合、AutoLogin機能では、IAMSuiteAgentのホスト識別子リスト内に10g Webgate Webサーバーのホスト名とポートが含まれている必要があります。
|
注意: 10g Webgate Webサーバーの前にロード・バランサがある場合、ステップ3でロード・バランサのホスト名とポートを含む必要があります。 |
agentBaseUrlパラメータを使用して特定のホスト識別子を更新します。ただし、自動ポリシーの作成がfalseに設定されている場合、リモート登録ユーティリティはアプリケーション・ドメインを作成せず、agentBaseUrlパラメータを参照しません。
次の手順では、Access Manager/Oracle Identity Manager統合のためにAutoLoginホスト識別子を確認(または構成)する方法を示します。実際の値は異なります。
前提条件
OAM/OIM統合用のAutoLoginホスト識別子の構成手順
「ポリシー構成」タブのナビゲーション・ツリーから、「共有コンポーネント」と「ホスト識別子」ノードを必要に応じて展開し、「IAMSuiteAgent」を選択します。
「操作」パネルで、このホスト識別子のすべてのホスト名とポートの組合せがリストされていることを確認します。
「操作」パネルで、10g Webgateが構成されている(または構成が予定されている)Webサーバーのホストとポートがリストされていることを確認します。ない場合は、エントリを追加します。
「操作」パネルの+ボタンをクリックします。
ホスト名: 「操作」パネルの「ホスト名」列に、10g Webgate Webサーバーのホスト名を入力します。
ポート: 「操作」パネルの「ポート」列に、10g Webgate Webサーバーのポート番号を入力します。
ロード・バランサ: 10g Webgate Webサーバーの前にロード・バランサがある場合、「操作」パネルにロード・バランサのホスト名とポートを追加します。
「ホスト識別子」ページの「適用」をクリックします。
この項では、Access Manager 11gと10g Webgateを使用してシングル・サイン・オンが行えるように、WebLogicセキュリティ・プロバイダを構成する方法を説明します。
|
注意: Access Manager 11gをOracle Identity Manager 11gに統合していない場合、この手順は省略します。 |
10g Webgate用のセキュリティ・プロバイダの設定の詳細は、次のトピックを参照してください。
IAMSuiteAgentを10g Webgateに入れ替える場合に、Access Manager 11g SSOの構成を完了するには、WebLogicサーバー・ドメイン内で次のセキュリティ・プロバイダを構成する必要があります。
OAM Identity Asserter: トークンベースの認証を使用し、OAM SSOヘッダーとトークンをアサートします。
OID (またはOVD) Authenticator: サブジェクトを作成し、正しいプリンシパルを移入します。
ユーザーが保存されているストアに応じて、Oracle Internet Directory AuthenticatorまたはOracle Virtual Directory Authenticatorのいずれかをプライマリ資格証明オーセンティケータとして構成します。
デフォルト・オーセンティケータ: このデフォルトWebLogic認証プロバイダによって、ユーザーとグループを、組み込まれたWebLogicサーバーLDAPサーバーという1つの場所で管理できます。Oracle WebLogicサーバーはこのオーセンティケータを使用して、管理ユーザーのログインを行います。
複数の認証プロバイダを構成する場合、各プロバイダにJAAS制御フラグを使用して、ログイン順序での認証プロバイダの使用方法を制御します。たとえば次のJAAS制御フラグ設定を使用できます。
REQUIRED—認証プロバイダは常に呼び出され、ユーザーは必ずその認証テストに合格する必要があります。認証の成否にかかわらず、プロバイダ・リストの残りの認証が続行されます。OAM Identity Asserterが必要です。
SUFFICIENT—ユーザーは認証プロバイダの認証テストに合格する必要はありません。認証に合格した場合は、以降の認証プロバイダは実行されません。認証が失敗下場合は、プロバイダ・リストの残りの認証が続行されます。Oracle Internet Directory (またはOracle仮想ディレクトリ)およびデフォルト・オーセンティケータの両方がSUFFICIENTです。
OPTIONAL—追加の認証プロバイダが既存のセキュリティ・レルムに加わると、デフォルト設定で制御フラグがOPTIONALに設定されます。各認証プロバイダが認証順序で正しく機能するように、制御フラグの設定とプロバイダの順序を変更する必要があるかもしれません。
ユーザーは認証プロバイダの認証テストを合格しても、不合格になってもかまいません。ただし、JAAS制御フラグがOPTIONALに設定されたセキュリティ・レルムですべての認証プロバイダが構成されている場合は、ユーザーは構成されたいずれかのプロバイダの認証テストに合格する必要があります。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項に、すべての認証プロバイダのリストと、ユーザーおよびグループ属性のLDAPスキーマに見合ったOracle Internet Directoryプロバイダの構成詳細が記載されています。 |
Access Manager JARは、Oracle Fusion Middleware製品(Oracle Identity Management、Oracle SOA Suite、またはOracle WebCenter)のインストール時に使用可能な認証プロバイダのWARファイルです。Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っています。
oamAuthnProvider.jar: シングル・サインオン用のAccess Manager IDアサーション・プロバイダのファイルとOracle WebLogic Server 10.3.1以降の認証プロバイダのファイルが含まれています。ユーザーやアプリケーションからのWebリソースおよび非Web(非HTTP)リソースに対するリクエストを処理するために、カスタムのAccess Managerアクセス・ゲートも用意されています。
oamauthenticationprovider.war: Oracle WebLogicサーバー・コンソールに表示されるプロバイダ・リストを、Access Managerで使用する必要があるもののみに限定します。
拡張をデプロイする際に、管理コンソールでは、そのWARファイルに記述されたファイルおよびディレクトリと、拡張のWARファイルに記述されたファイルおよびディレクトリとのメモリー内結合が作成されます。デプロイした拡張機能は、管理コンソールの完全なメンバーになります。この拡張機能は、WebLogic Serverのセキュリティ・レルムで保護され、管理コンソールの他のセクションに移動できます。また、拡張機能からWebLogic Serverリソースを変更する場合、拡張機能は変更管理プロセスに関与します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server管理コンソールの拡張』を参照してください。
次の手順にはWebLogicサーバー管理コンソールが必要です。この例では、Oracle Internet DirectoryプロバイダをOAM Identity Asserterおよびデフォルト・オーセンティケータで設定する方法を示します。OVDの場合も必要な手順は同じです。
|
注意: Fusion Middlewareアプリケーションをご使用の場合は、必要なファイルをすでに持っているので、次の手順1をスキップできます。ただしFusion Middlewareアプリケーションがない場合は、スタンドアロンOracle WebLogicサーバーなので、手順1で説明したようにOracle Technology NetworkからJARおよびWARファイルを入手する必要があります。 |
前提条件
10g WebgateとAccess Manager 11g用のプロバイダをWebLogicサーバー・ドメインに設定する手順
Oracle Fusion Middlewareアプリケーションがない場合: Access Managerプロバイダを次の手順で入手します。
次のOracle Technology Networkにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Webgates (10.1.4.3.0)で、oamAuthnProvider ZIPファイルを検索します。
oamAuthnProvider<version number>.zip
oamAuthnProvider.jarを、Oracle WebLogicサーバーをホスティングしているコンピュータの次のパスに解凍し、コピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle Fusion Middlewareアプリケーションがインストールされている場合:
次のパスでoamauthenticationprovider.warを探します。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi der.war
次の場所にoamauthenticationprovider.warをコピーします。
BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication provider.war
WebLogicサーバー管理コンソールにログインして、セキュリティ・レルム、デフォルト・レルム名をクリックし、プロバイダをクリックします。
OAM Identity Asserter: 次の手順を実行してこのプロバイダを追加します。
認証をクリックして新規をクリックし、次に名前を入力して、タイプを選択します。
名前: OAM ID Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダテーブル内で、新しく追加されたオーセンティケータをクリックします。
共通タブで、制御フラグをREQUIREDに設定して、保存をクリックします。
OIDオーセンティケータ: 次の手順を実行してこのプロバイダを追加します。
セキュリティ・レルム、デフォルト・レルム名をクリックし、プロバイダをクリックします。
新規をクリックし、次に名前を入力して、タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
OK
認証プロバイダテーブル内で、新しく追加されたオーセンティケータをクリックします。
設定ページの共通タブで、制御フラグをSUFFICIENTに設定して、保存をクリックします。
プロバイダ固有タブをクリックして、環境に合った値を使用して、次のような必要な設定を行います。
ホスト: ご使用のLDAPホスト。例: localhost
ポート: ご使用のLDAPホスト・リスナー・ポート。例: 6050
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin
資格証明: LDAP管理ユーザー・パスワード。
ユーザー・ベースDN: Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリ内のユーザー名のデフォルト属性として設定。例: uid
グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)
すべてのグループフィルタをデフォルト作業として設定しないでください。
保存します。
デフォルト・オーセンティケータ: 次の手順を実行して、Identity Asserterで使用するデフォルト・オーセンティケータを設定します。
セキュリティ・レルム、デフォルト・レルム名に移動して、プロバイダをクリックします。
認証をクリックして、DefaultAuthenticatorをクリックし、確認ページを表示します。
共通タブをクリックして制御フラグをSUFFICIENTに設定します。
保存します。
プロバイダの並替え:
セキュリティ・レルム、デフォルト・レルム名、プロバイダをクリックします。
プロバイダがリストされたサマリーページで、並替えボタンをクリックします
認証プロバイダの並替えページで、プロバイダ名を選択し、リストの横にある矢印を使用してプロバイダの並替えを行います。
OAM IDアサーション・プロバイダ: (REQUIRED)
OIDオーセンティケータ(SUFFICIENT)
デフォルト・オーセンティケータ(SUFFICIENT)
OKをクリックして変更を保存します
変更のアクティブ化: チェンジ・センターで変更のアクティブ化をクリックします。
Oracle WebLogicサーバーを再起動します。
次のように進みます。
成功した場合: 「IAMSuiteAgentの無効化」に進みます。
失敗した場合: すべてのプロバイダが環境に合った仕様になっており、正しい順序で、oamAuthnProvider.jarが[セキュリティ・プロバイダについて」に記載された正しい場所にあることを確認します。
この手順はオプションで、必須ではありません。IDMDomainエージェントは、Webgateが認証を行い、サイレント状態になると検知します。ただし、エージェントを無効にする必要がある場合、エージェントを無効にする必要がある各サーバーに対して、WLSAGENT_DISABLEDシステム・プロパティまたは環境変数をtrueに設定する必要があります。これはAdminServerとOAMサーバーの両方に適用されます。
エージェントの無効化は次の2つの方法のいずれかで行えます。
WLSAGENT_DISABLEDをtrueに設定するか、
WLSAGENT_DISABLEDをシステム・プロパティとして渡します
前提条件
必要に応じて WebLogic用のOAMセキュリティ・プロバイダの構成を行います。
IAMSuiteAgentの無効化手順
IAMSuiteAgentをホスティングしているコンピュータ上で、次のタスクのいずれかを実行します。
WLSAGENT_DISABLEDをtrueに設定するか、
setenv WLSAGENT_DISABLED true
DWLSAGENT_DISABLED=trueをシステム・プロパティとして渡します。
-DWLSAGENT_DISABLED=true
Webサーバーを再起動します。
「11g OAMサーバー使用時の10g Webgateの集中ログアウト構成」に進んでから、「検証」に戻ります。
必要に応じて、次の手順を使用して、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サーバーに関する詳細は、第23章、 第25章、第24章、および第26章を参照してください。
Webサーバーを再起動します。
特に再インストールを予定している場合、Webgate_install_dirディレクトリが残っていれば削除します。
