| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11gリリース1（11.1.1） B56235-02 |
|
 戻る |
 次へ |
この章では、Oracle Fusion Middlewareに対して推奨される一連のシングル・サインオン・ソリューションについて説明します。また、Oracle Fusion Middleware環境で認証とシングル・サインオンを構成する際の一般的なガイドラインとユースケースについても説明します。この章の内容は次のとおりです。
Oracle Platform Security Servicesは、Oracle WebLogic Serverの内部セキュリティ・フレームワークを構成します。WebLogicドメインは、認証プロバイダと呼ばれる個別のソフトウェア・コンポーネントを使用してセキュリティ・データの格納、トランスポート、およびセキュリティ・データへのアクセスを提供します。認証プロバイダでは、各種システムを使用してセキュリティ・データを格納できます。WebLogic Serverによってインストールされる認証プロバイダは、組込みLDAPサーバーを使用します。
Oracle Fusion Middleware 11gは、アプリケーションによる境界認証の確立および実施のために使用できる、次の新しいシングル・サインオン・ソリューションをサポートしています。
ニーズに応じたソリューションを注意深く選択する必要があります。適切なSSOソリューションの選択は、十分な検討を必要とし、それぞれの要件に応じて異なります。この項では、ニーズにあわせて最適なソリューションを選択するための一般的な情報とガイドラインについて説明します。
|
注意: Access Manager 11g Single Sign-onソリューションが提供する多くの機能とアーキテクチャを活用するために、このソリューションへのアップグレードを検討することをお薦めします。 |
|
関連項目: 『Oracle Fusion Middlewareセキュリティ概要』 |
開発環境または小規模なスタンドアロン環境: デプロイされたアプリケーションをエンタープライズ・レベルのシングル・サインオン・フレームワークに統合しない場合、軽量なSSOソリューションの使用をお薦めします。
この場合は、Oracle WebLogic ServerのSAML資格証明マッピング・プロバイダを使用するSAMLベース・ソリューションが最適です。デフォルト・ユーザー・リポジトリとして、組込みLDAPサーバーが使用されます。また、外部LDAPサーバーをユーザー・リポジトリとして使用するようにLDAP認証プロバイダを構成することもできます。
|
関連項目: 『Oracle Fusion Middleware Securing Oracle WebLogic Server』のWebブラウザおよびHTTPクライアントでのシングル・サインオンの構成に関する項 |
Oracle Fusion Middleware 11gによるエンタープライズ・レベルのSSO: Oracle Access Managerは次の機能をサポートしています。
ユーザー・リポジトリおよびグループ・リポジトリとして多様なLDAPベンダーをサポートし、Oracle Virtual Directoryでの使用も可能です。
Oracle以外のアプリケーション・サーバー・ベンダーおよび多彩なOSプラットフォーム上のWeb層コンポーネントとの統合をサポートし、柔軟性の高いソリューションを提供します。
Oracle Access Manager 11gは、特別な設定を必要とせずにOracle Fusion Middlewareアプリケーションと統合できます。
Oracle Access Manager 11g（リリース1）: Oracle Access Manager 11gをお薦めできる状況は次のとおりです。
Oracle Fusion Middlewareを初めて使用する場合
OSSOからの移行を検討している場合
エンタープライズ・レベルのSSOソリューションを検討している場合
Oracle Access Manager 10g（10.1.4.3）: 次のものがあれば、このアプリケーションを継続して使用できます。
既存のOracle Access Manager 10gの実装
エンタープライズ・レベルのSSOソリューション
エンタープライズ・レベルのSingle-Sign-onソリューションとして、Oracle Access Managerソリューションの10g（10.1.4.3）または11gのどちらを選択するかは、現実の要件に応じて異なります。この章の製品ドキュメントおよび各管理ガイドを参照して、全体の要件に最適なリリースを評価してください。
現在OSSO 10gを使用しているお客様: Oracle Single Sign-Onは、10g Oracle Application Serverスイートに同梱されています。OSSOは、Oracle Internet DirectoryおよびOracle HTTP Server 11gと組み合せたOC4Jアプリケーション・サーバーで使用できるエンタープライズ・レベルのシングル・サインオン・ソリューションです。
既存のOracleデプロイメントにOSSOがエンタープライズ・ソリューションとしてすでにデプロイされている場合、Oracle Fusion Middlewareは、既存のOSSOソリューションを引き続きサポートします。それであっても、戦略的Oracle SSOソリューションである、Oracle Access Manager 11g Single Sign-onソリューションへのアップグレードを検討することをお薦めします。アップグレードの計画で必要となる情報の詳細は、http://www.oracle.com/support/lifetime-support-policy.htmlのLifetime Support Middleware PolicyでOSSOのサポート終了日を確認してください。
|
関連項目:
|
Portal、Forms、ReportsおよびDiscoverer 11g: Oracle Access Manager 11gは、Oracle Portal、Forms、ReportsおよびDiscover 11gで認定済です。Oracleの代表的な各種コンポーネントでは、Oracle Delegated Administration Services 10gがOracle Identity Managementインフラストラクチャに必須で重要な機能となっています。
次のURLで、Oracle Identity Management 10g（10.1.4.0.1）オンライン・ドキュメント・ライブラリの『Oracle Identity Management委任管理ガイド』を参照してください。
http://www.oracle.com/technology/documentation/oim1014.html
詳細は、次のURLで、Oracle Fusion Middlewareがサポートしているシステム構成に関するページを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
|
関連項目: この章の次の項、および他の11gのマニュアル
|
Oracle Access ManagerとOSSOの統合: Oracle Access Manager 11gは、エンタープライズ規模のソリューションとしてお薦めできます。従来からOracleAS Single Sign-Onを必要とするアプリケーション（Oracle Portalなど）をデプロイしている場合は、OSSO 10gからOracle Access Manager 11gに認証を委任できます。Oracle Access ManagerとOSSOの統合を必要とするアプリケーションでは、Oracle Internet Directoryが必要です。
|
関連項目:
|
MicrosoftクライアントのWindowsネイティブ認証: OSSOとOracle Access Manager 11gは、どちらもこの統合をサポートしています。Simple and Protected Negotiate（SPNEGO）認証メカニズムを使用するようにOracle WebLogic Serverを構成して、Windowsネイティブ認証を提供できます。
|
関連項目:
|
特に明記されていなければ、ここで説明する情報はOracle Access Manager 11gと10gの両方のデプロイに同じように当てはまります。
Oracle Access Manager認証プロバイダは、Oracle WebLogic Serversで動作するプロバイダの1つです。Oracle Access Manager 11gまたは10gでOracle Access Manager認証プロバイダが動作するには、Oracle WebLogic Suite全体もOracle Java Required Files（JRF）も必要としません。
JRFをインストールしたWebLogic Serverドメインには、Oracle Fusion Middleware製品のドメインの一部としてJRFテンプレートが存在します。この場合、OAM IDアサーション・プロバイダとOAM認証プロバイダは自動的に構成に使用できるようになっています。WebLogicドメインにJRFがインストールされていない場合には、後述するようにドメインの特定の場所にOAMAuthnProvider.jarを追加する必要があります。
|
注意: Oracle Fusion Middleware製品のドメインの一部としてJRFテンプレートが存在します。 |
認証プロバイダを使用できるのは、次の場合です。
Identity Managementドメイン外にあるWebLogicコンテナにアプリケーションをデプロイ済であるか、そこにアプリケーションをデプロイする予定である。
認証プロバイダのフロントエンドにWebGateをデプロイ済であるか、デプロイする予定である。
WebLogicユーザーが次の機能のいずれか（または両方）を使用できるように認証プロバイダを構成できます。
シングル・サインオン機能のためのIDアサーション・プロバイダ
Web専用アプリケーションの実装では、SSOの用途のほとんどすべてを扱うことができます。例外は、Oracle Web Services ManagerによってWebサービスが保護されている場合です。この場合、信頼できるWebゲートがありません。かわりに、IDアサーション・プロバイダが提供するアクセス・ゲートにアクセスすると、このアクセス・ゲートがOAM 10gアクセス・サーバー（または11g OAM Server）と対話します。それ以外の処理は基本的には同じです。
IDアサーション・プロバイダは着信ID（OAM_REMOTE_USER）のみをアサートし、構成済の認証プロバイダに制御を渡して残りの認証プロセス（適切なプリンシパルを持つサブジェクトの移入）を続行します。
IDアサーション・プロバイダは、リクエストを提供するWebゲートのリリース（10gまたは11g）に応じて異なる方法で構成する必要があります。たとえば、アプリケーションを保護する場合の各リリースの構成方法は次のとおりです。
10g Webゲート: トークン（ObSSOCookie）を対象としてIDアサーション・プロバイダをトリガーします。
OAM 10g Webゲートで保護しているアプリケーション用のトークンOAM_REMOTE_USERを対象として、IDアサーション・プロバイダをトリガーすることもできます。詳細は、「OAM 11gおよび10gのWebゲートでのSSO用のIDアサーション・プロバイダの使用について」を参照してください。
11g Webゲート: トークン（OAM_REMOTE_USER）を対象としてIDアサーション・プロバイダをトリガーします。ObSSOCookieはありません。
認証プロバイダの機能
認証プロバイダでは、シングル・サインオン機能は提供されません。認証プロバイダは、Oracle Access Manager認証スキームに従うのではなく、アプリケーション構成ファイルweb.xmlに指定されている認証方式に基づいてユーザーに資格証明を要求します。ただし、アプリケーション・ドメインではOracle Access Manager認証スキームが必要です。
詳細は、次の各項を参照してください。
この項では、Oracle Access Manager 11gおよびOAM 11g Webゲートでのシングル・サインオン用のIDアサーション・プロバイダの使用について説明します。
すべてのリクエストは、まずリバース・プロキシWebサーバーにルーティングされます。リクエストはWebゲートでインターセプトされます。Oracle Access Manager 11gに構成されている認証スキームに基づいて、ユーザーに資格証明の提示が要求されます。認証スキームとしては、フォームの使用（フォームベースのログイン）をお薦めします。
|
注意: この章では、Apache用WebLogic Serverプラグインの汎用名（mod_weblogic）を使用します。Oracle HTTP Server 11gでは、このプラグインの名前はmod_wl_ohsですが、実際のバイナリ名はmod_wl_ohs.soになります。後述する例は、実装可能な正確な構文を示しています。 |
Oracle Access Manager 11g WebゲートでSSO向けに使用するIDアサーション・プロバイダは、Web層でWebゲートが実行する境界認証を利用しています。IDアサーション・プロバイダは、選択済のアクティブなタイプとしてOAM_REMOTE_USERを使用するように構成し、OAM_REMOTE_USERが存在するとトリガーされるようにする必要があります。
続いて、IDアサーション・プロバイダは、サブジェクトを作成して適切なプリンシパルを移入するために、構成済の任意の認証プロバイダ（ログイン・モジュール）を呼び出します。
|
注意: SSO用のIDアサーション・プロバイダとして11g Webゲートを使用する場合と10g Webゲートを使用する場合の相違点は、選択済のアクティブ・タイプのみです。 |
プロバイダで選択するアクティブなタイプ: OAM 11gおよび11g Webゲート
IDアサーション・プロバイダの「アクティブなタイプ」構成パラメータには、使用可能なUIセクションにObSSOCookieとOAM_REMOTE_USERという2つの値があります。ObSSOCookieまたはOAM_REMOTE_USERが存在するとIDアサーション・プロバイダがトリガーされるようにするには、2つの値のいずれかを「選択済み」タイプに指定する必要があります。
|
注意: OAM 11gで使用するIDアサーション・プロバイダは、OAM_REMOTE_USERを選択済のアクション・タイプとして構成する必要があります。これに対して、OAM 10gではObSSOCookieを指定します。 |
OAM_REMOTE_USERヘッダーには、ログイン・ユーザーのuidが記述されています。IDアサーション・プロバイダで使用する選択済のアクティブなタイプとしてOAM_REMOTE_USERを構成する場合、認可成功のレスポンス・ヘッダーの中でOAM_REMOTE_USERを設定したOracle Access Managerポリシーが必要です。
構成済の認証スキームを使用してWebゲートがユーザーを認証した時点での概要プロセスは次のとおりです。
WebGate 11gがOAMAuthnCookieを設定すると、OHS Webサーバーのmod_weblogicモジュールは該当のリクエストをOracle WebLogic Serverに転送します。
OAM_REMOTE_USERヘッダーが存在することで、構成済のIDアサーション・プロバイダが呼び出され、リクエストをアサートします。
アサーション・プロセスの後、セキュリティ・レルムに構成されている認証プロバイダが呼び出されて、サブジェクトにプリンシパル（ユーザーとグループ）が移入されます。
図9-1および次の概要では、Web専用アプリケーションでシングル・サインオン用のIDアサーション・プロバイダを使用する場合にコンポーネント間で発生する処理について説明します。この実装は、ほとんどすべてのSSOユースケースに対応します。ただし、Oracle Web Services Managerによって保護されているWebサービスは例外です。この場合、信頼できるWebゲートがありません。かわりに、IDアサーション・プロバイダが提供するアクセス・ゲートにアクセスすると、このアクセス・ゲートが11g OAM Serverと対話します。それ以外の処理は基本的には同じです（図中の点線参照）。
正しい構成のリストについては、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
プロセス概要: OAM 11g、11g WebゲートおよびWeb専用アプリケーションを使用したIDアサーション・プロバイダ
Oracle WebLogic ServerにデプロイしてOracle Access Manager 11gで保護しているWebアプリケーションに、ユーザーがアクセスしようとします。
リバース・プロキシWebサーバーのWebゲート11gがリクエストをインターセプトし、リクエストされたリソースが保護されているかどうかを11g OAM Serverに問い合せます。
リクエストされたリソースが保護されている場合、Webゲート11gは、そのリソースに対して構成されているOracle Access Manager認証スキームのタイプ（フォーム・ログインを推奨）に基づいてユーザーの資格証明を要求します。ユーザーは、ユーザー名やパスワードなどの資格証明を入力します。
Webゲート11gは、認証リクエストを11g OAM Serverに転送します。
OAM Serverは、ユーザー資格証明をプライマリ・ユーザー・アイデンティティ・ストアに格納されている情報と照合した後、レスポンスをWebゲートに返します。次のように処理が選択されます。
正常な認証: 手順6に進みます。
認証失敗: ログイン・フォームが表示され、ユーザーは資格証明の再入力を求められます。エラーは報告されません。
OAM Server 11gはセッション・トークンを作成し、Webゲートに送信します。
11g WebGateでOAMAuthn Cookieが設定されて返されます。
Webサーバーはこのリクエストをプロキシに転送し、プロキシはmod_weblogicプラグインを使用してリクエストをOracle WebLogic Serverに転送します。
mod_weblogicは、その構成設定に従ってリクエストを転送します。
WebLogic Serverのセキュリティ・サービスは、タイプOAM_REMOTE_USERのトークンを受け入れるように構成されているOracle Access Manager IDアサーション・プロバイダを呼び出します。このIDアサーション・プロバイダは、ヘッダーを使用してCallbackHandlerを初期化します。さらに、ダウンストリームLoginModule用として、NameCallbackにユーザー名を設定します。
Oracle WebLogicセキュリティ・サービスがユーザーを認可し、リクエストしたリソースへのアクセスを許可します。
レスポンスがリバース・プロキシWebサーバーに返されます。
レスポンスがブラウザに返されます。
この項では、Oracle Access Manager 11gおよび10g Webゲートでのシングル・サインオン用のIDアサーション・プロバイダの使用について説明します。これはOAM 10gおよび10g Webゲートでの処理とよく似ています。
すべてのリクエストは、まずリバース・プロキシWebサーバーにルーティングされます。リクエストはWebゲートでインターセプトされます。Oracle Access Manager内に構成されている認証スキームに基づいて、ユーザーに対して資格証明の提示が要求されます。認証スキームとしては、フォームの使用（フォームベースのログイン）をお薦めします。
|
注意: この章では、Apache用WebLogic Serverプラグインの汎用名（mod_weblogic）を使用します。Oracle HTTP Server 11gでは、このプラグインの名前はmod_wl_ohsですが、実際のバイナリ名はmod_wl_ohs.soになります。後述する例は、実装可能な正確な構文を示しています。 |
Oracle Access Manager 10g WebゲートでSSO向けに使用するIDアサーション・プロバイダは、Web層でWebゲートが実行する境界認証を利用しています。IDアサーション・プロバイダは、選択済のアクティブなタイプとしてObSSOCookieを使用するように構成し、ObSSOCookieが存在するとトリガーされるようにする必要があります。
続いて、IDアサーション・プロバイダは、サブジェクトを作成して適切なプリンシパルを移入するために、構成済の任意の認証プロバイダ（ログイン・モジュール）を呼び出します。
|
注意: SSO用のIDアサーション・プロバイダとして10g Webゲートを使用する場合と11g Webゲートを使用する場合の相違点は、選択済のアクティブ・タイプのみです。 |
プロバイダで選択するアクティブなタイプ: OAM（10gまたは11g）および10g Webゲート
IDアサーション・プロバイダの「アクティブなタイプ」構成パラメータには、使用可能なUIセクションにObSSOCookieとOAM_REMOTE_USERという2つの値があります。ObSSOCookieまたはOAM_REMOTE_USERが存在するとIDアサーション・プロバイダがトリガーされるようにするには、2つの値のいずれかを「選択済み」タイプに指定する必要があります。
|
注意: 10g WebゲートからWebLogic ServerへのリクエストにはOAM_REMOTE_USERヘッダーが含まれている可能性が高いため、IDアサーション・プロバイダは選択済のアクション・タイプとしてOAM_REMOTE_USERを使用して構成できます。 |
OAM_REMOTE_USERヘッダーには、ログイン・ユーザーのuidが記述されています。IDアサーション・プロバイダで使用する選択済のアクティブなタイプとしてOAM_REMOTE_USERを構成する場合、認可成功のレスポンス・ヘッダーの中でOAM_REMOTE_USERを設定したOracle Access Managerポリシーが必要です。詳細は、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
構成済の認証スキームを使用してWebゲートがユーザーを認証した時点での概要プロセスは次のとおりです。
WebゲートがObSSOCookieを設定すると、OHS Webサーバーのmod_weblogicモジュールはそのリクエストをOracle WebLogic Serverに転送します。
構成済のIDアサーション・プロバイダがObSSOCookieの存在によって呼び出され、続いてOAM_REMOTE_USERヘッダーをアサートします。
アサーション・プロセスの後、セキュリティ・レルムに構成されている認証プロバイダが呼び出されて、サブジェクトにプリンシパル（ユーザーとグループ）が移入されます。
図9-2は、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダをOracle Fusion Middlewareで構成した場合のコンポーネントの配置と情報フローを示しています。図の後に詳細を示します。
|
注意: Oracle Access Manager 11gでは、アクセス・サーバーをOAM Serverと呼んでいます。それ以外は、10g WebゲートでのOAM 11gは、10g WebゲートでのOAM 10gと同様に処理されます。 |
図9-2 Webリソースのみを対象としたIDアサーション・プロバイダ・シングル・サインオン・ソリューション
この実装は、ほとんどすべてのSSOユースケースに対応します。ただし、Oracle Web Services Managerによって保護されているWebサービスは例外です。この場合、IDアサーション・プロバイダが提供するアクセス・ゲートにアクセスすると、そのアクセス・ゲートがアクセス・サーバー（または11g OAMサーバー）と対話します。それ以外の処理は基本的には同じです。
次のプロセス概要では、Web専用アプリケーションおよび10g Webゲートでシングル・サインオン用のIDアサーション・プロバイダを使用する場合にコンポーネント間で発生する処理を説明します。
|
注意: IDアサーション・プロバイダは、その実装において信頼できるWebゲートを使用しているか、またはoamAuthnProvider.jarが提供するカスタム・アクセス・ゲートを使用しているかどうかに関係なく、すべて同様の方法で処理されます。 |
プロセス概要: 10g WebゲートおよびWeb専用アプリケーションを使用したIDアサーション・プロバイダ
ユーザーが、Oracle WebLogic Serverにデプロイされている、Oracle Access Managerによって保護されたWebアプリケーションにアクセスしようとします。
リバース・プロキシWebサーバーのWebゲート10gがリクエストをインターセプトし、リクエストされたリソースが保護されているかどうかをOracle Access Managerアクセス・サーバー（または11g OAMサーバー）に問い合せます。
リクエストされたリソースが保護されている場合、Webゲートは、そのリソースに対して構成されているOracle Access Manager認証スキームのタイプ（フォーム・ログインを推奨）に基づいてユーザーの資格証明を要求します。ユーザーは、ユーザー名やパスワードなどの資格証明を入力します。
Webゲート10gは、認証リクエストをアクセス・サーバー（または11g OAMサーバー）に転送します。
アクセス・サーバー（または11g OAMサーバー）は、ユーザー資格証明をユーザー・ディレクトリの格納情報と照合した後、レスポンスをWebゲートに返します。次のように処理が選択されます。
正常な認証: 手順6に進みます。
認証失敗: ログイン・フォームが表示され、ユーザーは資格証明の再入力を求められます。エラーは報告されません。
アクセス・サーバー（または11g OAMサーバー）はセッション・トークンを作成し、Webゲートに送信します。
10g Webゲートは、返信に応じてObSSOCookieと値を設定します。
11g WebゲートでOAMAuthn_<Host:port> Cookieが設定され、返されます。
Webサーバーはこのリクエストをプロキシに転送し、プロキシはmod_weblogicプラグインを使用してリクエストをOracle WebLogic Serverに転送します。
mod_weblogicは、その構成設定に従ってリクエストを転送します。
WebLogic Serverセキュリティ・サービスは、タイプObSSOCookieまたはOAMAuthn_<Host:port> Cookieのトークンを受け入れるように構成されているOracle Access Manager IDアサーション・プロバイダを呼び出します。IDアサーション・プロバイダは、このCookieを使用してCallbackHandlerを初期化します。さらに、ダウンストリームLoginModule用として、NameCallbackにユーザー名を設定します。
Oracle WebLogicセキュリティ・サービスがユーザーを認可し、リクエストしたリソースへのアクセスを許可します。
レスポンスがリバース・プロキシWebサーバーに返されます。
レスポンスがブラウザに返されます。
この項では、Oracle Access ManagerでのWebリソースおよび非Webリソースへのアクセスを保護するために構成した認証プロバイダの使用について説明します。
|
注意: 特に明記されていなければ、ここで説明する情報はOracle Access Manager 11gと10gに同じように当てはまります。 |
この認証プロバイダは、Oracle Access Manager認証サービスを使用して、WebLogic Serverにデプロイしたアプリケーションにアクセスするユーザーを認証します。ユーザーは、ユーザー名やパスワードなどの資格証明に基づいて認証されます。
ユーザーが保護されたリソースへのアクセスを試みると、Oracle WebLogic Serverによって、アプリケーションのweb.xmlファイルで指定されている認証方式に基づいたユーザー資格証明が要求されます。次に、Oracle WebLogic Serverが認証プロバイダを呼び出し、認証プロバイダは資格証明をOracle Access Managerアクセス・サーバーに転送します。この資格証明は、エンタープライズ・ディレクトリ・サーバーによって検証されます。
図9-3は、Webおよび非Webリソースに対してOracle Access Manager認証を行う場合のコンポーネントの配置と情報フローを示しています。詳細は、図の後に説明します。この場合、認証プロバイダはカスタム・アクセス・ゲートを介して11g OAMサーバー（またはOAM 10gアクセス・サーバー）と通信します。
プロセス概要: Webおよび非Webリソース用の認証プロバイダ
ユーザーが、Oracle WebLogic Serverにデプロイされている（アプリケーションのweb.xmlファイルにある認証方式で保護されている）J2EEアプリケーションにアクセスしようとします。
Oracle WebLogic Serverがリクエストをインターセプトします。
Oracle WebLogicセキュリティ・サービスが、Oracle Access Manager認証プロバイダのLoginModuleを呼び出します。LoginModuleは、OAPライブラリを使用して11g OAMサーバー（または10gアクセス・サーバー）と通信し、ユーザー資格証明を検証します。
ユーザー・アイデンティティが正常に認証されると、WLSUserImplプリンシパルとWLSGroupImplプリンシパルがサブジェクトに移入されます。
Oracle Access ManagerのLoginModuleがユーザーのアイデンティティを正常に認証できない場合は、LoginException（認証失敗）が返され、Oracle WebLogicリソースへのアクセスは拒否されます。
Oracle Access Manager認証プロバイダは、Oracle WebLogic ServerのUserNameAssertionをサポートします。
Oracle Access Manager認証プロバイダは、任意のIDアサーション・プロバイダとともに使用できます。この場合、Oracle Access Manager認証プロバイダはユーザー名を解決し、そのユーザー名に関連付けられているロールとグループを取得します。
この項では、現在のアプリケーション設定に応じて、Oracle Access Managerと認証プロバイダを使用するアプリケーションの選択について説明します。認証プロバイダでOracle Access Manager 11gまたは10gのどちらを使用する場合でも、詳細はよく似ています。
アプリケーションでOracle Access Manager認証プロバイダを初めて使用する場合、使用する機能に応じて、次の項を参照してください。
シングル・サインオン用のIDアサーション・プロバイダ: Web専用アプリケーションの実装では、SSOを使用するほとんどすべての状況を扱うことができます。「Oracle Access Manager 11gでの認証プロバイダのインストール」を参照してください。
Oracle Web Services Managerによって保護されているWebサービス: これらのサービスでOAMサーバーと通信するには、IDアサーション・プロバイダが提供するアクセス・ゲートが必要です。「Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成」を参照してください。
認証プロバイダ: シングル・サインオン機能は提供されません。認証プロバイダは、アプリケーション構成ファイルweb.xmlに指定されている認証方式に基づいてユーザーに資格証明を要求します。「Oracle Access Manager 11g用の認証プロバイダの構成」を参照してください。
旧型のOracle Application Server（OC4J）にアプリケーションをデプロイしている場合、次のわずかな手順を実行すると、Oracle WebLogic Serverでそのアプリケーションから認証プロバイダを使用できるようになります。
すべてのOC4J固有の設定をアプリケーション構成から削除します。
シングル・サインオン用のIDアサーション・プロバイダ: Web専用アプリケーションの実装では、SSOを使用するほとんどすべての状況を扱うことができます。ご使用の環境に該当する項を参照してください。
—OAM 11g: 「Oracle Access Manager 11gでのSSO用のOAM IDアサーションの構成」
—OAM 10g: 「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」
Oracle Web Services Managerによって保護されているWebサービス: IDアサーション・プロバイダが提供するアクセス・ゲートが必要です。ご使用の環境に該当する項を参照してください。
—OAM 11g: 「Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成」
—OAM 10g: 「Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成」
認証プロバイダ: シングル・サインオン機能は提供されません。認証プロバイダは、アプリケーション構成ファイルweb.xmlに指定されている認証方式に基づいてユーザーに資格証明を要求します。ご使用の環境に該当する項を参照してください。
—OAM 11g: 「Oracle Access Manager 11g用の認証プロバイダの構成」
—OAM 10g: 「Oracle Access Manager 10g用の認証プロバイダの構成」
Oracle Access ManagerのWebLogic SSPI用セキュリティ・プロバイダは、WebLogicプラットフォームにデプロイした複数のJ2EEアプリケーションにわたって認証、認可およびシングル・サインオンを提供します。WebLogic SSPI用セキュリティ・プロバイダでは、Oracle Access Managerを使用して、ビジネス・アプリケーションへのユーザー・アクセスも管理できます。
|
注意: WebLogic SSPI用セキュリティ・プロバイダは、10g（10.1.4.3）の『Oracle Access Manager統合ガイド』ではセキュリティ・プロバイダとも呼ばれています。 |
Oracle Access ManagerのWebLogic SSPI用セキュリティ・プロバイダは、Oracle WebLogic Portalリソースへのアクセスを認証し、Oracle Access ManagerとOracle WebLogic Portal Webアプリケーション間のシングル・サインオンをサポートします。さらに、ユーザーおよびグループの管理機能も提供します。
Oracle Access Manager認証プロバイダは、WebLogic SSPI用セキュリティ・プロバイダよりも簡単にインストールおよび構成できます。認証プロバイダは、認証とシングル・サインオン（SSO）のサービスを提供するほか、Oracle WebLogic Serverがサポートするすべてのプラットフォームで機能します。
認証とSSOの目的でのみアプリケーションでOracle Access Manager WebLogic SSPI用セキュリティ・プロバイダを使用している場合は、最新の認証プロバイダのデプロイメントをお薦めします。ただし、最新のOracle Access Manager認証プロバイダでは得られない機能を使用している場合は、引き続きOracle Access Manager 10g WebLogic SSPI用セキュリティ・プロバイダを使用してもかまいません。
|
注意: WebLogic SSPIコネクタは、Oracle Access Manager 10gでは使用できますが、Oracle Access Manager 11gではサポートされていません。 |
多少の違いはありますが、OAM 11gまたはOAM 10gのどちらを使用してWebLogicコンテナでアプリケーションを保護しても、実装ソリューションはよく似ています。
表9-1では、OAM 11gで認証プロバイダをデプロイする場合とOAM 10gでデプロイする場合の違いを説明しています。項の見出しが強調表示されています。
表9-1 OAM 11gとOAM 10gでの認証プロバイダ実装タスクの違い
| OAM 11gの実装の詳細 | OAM 10gの実装の詳細 |
|---|---|
|
OAM 11gの実装では次のタスクを実行します。詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。
|
OAM 10gでSSOソリューションを実装するタスクは、この章の次の項を参照してください。
|
認証プロバイダの実装に必要なコンポーネントとファイルは、SSOソリューションとしてOAM 11gまたはOAM 10gのどちらを使用してもほとんど同じです。次のようなわずかな例外があります。
Oracle Access ManagerとOracle WebLogic Serverで使用するエンタープライズ・ディレクトリ・サーバー（Oracle Internet DirectoryまたはOracle Sun Oneディレクトリ・サーバー）
Oracle Access Manager認証プロバイダを使用するように構成した10.3.1以降のOracle WebLogic Server（この章の後半にある説明を参照）
オプション: Fusion Middleware製品（Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど）
認証プロバイダ: WebLogicコンテナにデプロイしたアプリケーションの場合、Oracle Fusion Middleware製品（Oracle Identity Management、Oracle SOA SuiteまたはOracle WebCenter）をインストールすると、Oracle Access ManagerのJARファイルおよびWARファイルを利用できるようになります。
|
注意: Fusion Middlewareを組み込まずにスタンドアロンのOracle WebLogic Serverを使用している場合は、この章の後半にある手順の手順1に従ってOracle Technology NetworkからJARファイルおよびWARファイルを取得する必要があります。 |
oamAuthnProvider.jar: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダのファイルとOracle WebLogic Server 10.3.1以降の認証プロバイダのファイルが含まれています。ユーザーやアプリケーションからのWebリソースおよび非Web（非HTTP）リソースに対するリクエストを処理するために、カスタムのOracle Access Managerアクセス・ゲートも用意されています。
oamauthenticationprovider.war: Oracle WebLogic Serverコンソールに表示されるプロバイダを、Oracle Access Managerで使用するために必要なプロバイダのみに制限します。
拡張をデプロイする際に、WebLogic管理コンソールでは、そのWARファイルに記述されたファイルおよびディレクトリと、拡張のWARファイルに記述されたファイルおよびディレクトリとのメモリー内結合が作成されます。デプロイした拡張機能は、WebLogic管理コンソールの完全なメンバーになります。この拡張機能は、WebLogic Serverのセキュリティ・レルムで保護され、管理コンソールの他のセクションに移動できます。また、拡張機能からWebLogic Serverリソースを変更する場合、拡張機能は変更制御プロセスに参加します。詳細は、Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソールの拡張を参照してください。
Oracle Access Manager 11g: リモート登録コマンドライン・ユーティリティは、Webゲートのプロビジョニングを合理化し、セキュリティ・ポリシーを備えた新しいアプリケーション・ドメインを作成します。管理者は、テンプレートを使用してWebゲートのパラメータと値を指定できます。
Oracle Access Manager 10g: プラットフォーム非依存のOAMCfgToolとスクリプト（oamcfgtool.jar）で、シングル・サインオン用のIDアサーション・プロバイダ向けに、Oracle Access Managerのフォームベース認証スキーム、ポリシー・ドメイン、アクセス・ポリシーおよびWebゲート・プロファイルを自動的に作成できます。OAMCfgToolでは、JRE 1.5または1.6が必要です。
Webゲートのリバース・プロキシとして、OHS 11gを構成する必要があります（Oracle Access Manager IDアサーション・プロバイダで必要）。
Oracle Access Manager:
OAM 11g: Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明されているように、Oracle Fusion Middleware構成ウィザードを使用して初期構成でデプロイされます。「Oracle Access Manager 11g SSOソリューションのデプロイ」を参照してください。
OAM 10g: Oracle Access Managerインストレーション・ガイドで説明されているように、初期設定でインストールされます。「Oracle Access Manager 10gを使用したSSOソリューションのデプロイ」を参照してください。
Webゲート/アクセス・ゲート: Oracle Access ManagerでWebゲートまたはアクセス・ゲートのどちらのプロビジョニングが必要であるかは、OAM認証プロバイダの使用方法によって決まります。
シングル・サインオン用のIDアサーション・プロバイダ: 境界認証を定義するために、アプリケーションごとに個別のWebゲートが必要です。
認証プロバイダ（またはOracle Web Services Manager）: 認証プロバイダで使用できるカスタム10gアクセス・ゲートが必要です。
この項では、WebLogicコンテナにデプロイしたアプリケーションまたはそこにデプロイする予定のアプリケーションがある場合に、認証プロバイダでOAM 11gを実装する方法を説明します。
この項の内容は次のとおりです。これらは、アプリケーションをWebLogicコンテナにデプロイする場合のOAM 11g SSOの実装で役に立ちます。ここで取り上げているOAMソリューションの実装は、OAM 11gに固有なもの以外は、OAM 11gとOAM 10gのどちらでも同じです。
Oracle Access Manager 11gは、Oracleのエンタープライズ・クラス・スイートのセキュリティ製品に属しています。新規のSSOデプロイメントと既存のSSOデプロイメントでの使用を目的としたOracle Access Manager 11gは、Webシングル・サインオン、認証と認可、ポリシー管理などの広範なWeb境界セキュリティ機能を提供します。
Oracle Access Manager 11gシングル・サインオン（SSO）およびシングル・ログアウト（SLO）は、次のような様々なアプリケーション・プラットフォームをサポートします。
SOA
WebCenter
Fusion Applications
Oracle Fusion Middleware Oracle Access Manager統合ガイドの説明にあるように、Oracle Access Manager 11gは次のような様々なアプリケーションとの統合をサポートしています。
Oracle Identity Navigator
Oracle Identity Federation
Oracle Identity Manager
Oracle Adaptive Access Manager
Oracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Manager 11gは、アイデンティティ管理機能がOracle Identity Manager 11gに委ねられるという点でOracle Access Manager 10gと異なります。Oracle Access Manager 11gには、ユーザー・セルフサービスおよび自己登録、ワークフロー機能、動的グループ管理、アイデンティティ管理の委任などの機能が用意されています。
Oracle Identity Managementアプリケーションのコンソール保護
Oracle Access Manager 11gおよびその他のOracle Identity Managementアプリケーションは、WebLogicコンテナにデプロイされています。個々の管理コンソールには、Oracle Access Manager、Oracle Adaptive Access Manager、Oracle Identity Navigator、Oracle Identity Manager、Oracle WebLogic Server、Oracle Authorization Policy Managerなどがあります。
これらは、デフォルトで、WebLogic管理コンソールの事前構成済の認証プロバイダおよび事前登録済のOracle Access Manager 11gのIDMドメイン・エージェントで保護されています。OAM 11g SSOポリシーは事前シード済です。コンソールをこれ以上構成する必要はありません。
OAM 11gデプロイメントのプレビュー
新規WebLogic管理ドメインまたは既存のWebLogic管理ドメインで、Oracle Fusion Middleware構成ウィザードを使用してOracle Access Managerを構成できます。
「Oracle Access Managerで認証プロバイダを使用する際の要件」を参照してください。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』 |
Oracle Access Manager 11gには、新規または既存のポリシー適用エージェントとの下位互換性を保持する新しいサーバー側のコンポーネントが用意されています。サーバー側で開始する動的な更新が、ポリシーや構成に対するあらゆる変更で実行されます。
OAM 10gポリシー・マネージャにかわって、OAM管理コンソール（WebLogic Administration Serverにインストール）が稼働します。
OAM 10gアクセス・サーバーにかわって、OAMサーバー（WebLogic管理下サーバーにインストール）が稼働します。
Oracle Access Manager 11gは、リソースを保護する次のような登録済エージェントの任意の組合せに対し、シングル・サインオン（SSO）、認証、その他の認可などのサービスを提供します。
11g Webゲート
10g Webゲート
JavaベースのIDMドメイン・エージェント
OSSOエージェント（10g mod_osso）
Oracle Access Manager 11gは、現在Oracle ADFのセキュリティとOPSS SSOフレームワークを使用しているどのWebアプリケーションとも統合できます。
Oracle Access Manager管理コンソールへのログインやOAM管理コマンドライン・ツールの使用は、適切な権限を持ったユーザーにのみ許可されています。企業によっては、OAM管理を担当するユーザー向けとWebLogic管理を担当するユーザー向けに別々の管理者グループが必要になることがあります。詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの新しいOAM管理者の役割の定義に関する項を参照してください。
OAM 11gの概要
Oracle Access Manager 11gの基本機能の概要は、次のとおりです。
プロビジョニング/リモート登録: 新しいリモート登録ツールにより、ネットワーク内外の管理者はエージェントとポリシーを登録できます。OAM 11gのプライマリ・ユーザー・アイデンティティ・ストアにユーザー名とパスワードを設定する必要があります。
認証: Oracle Access Manager 11gアプリケーション・ドメインは、リソースとセキュリティ・ポリシー（リソースごとに1つのポリシー）を集約します。Oracle Access Manager 11gの認証ポリシーには、固有のスキームがあります。サポートされる認証モジュールには、LDAP、X.509、Kerberosなどがあります。認証ユーザーは、集中管理された資格証明コレクタによってプライマリ・ユーザー・アイデンティティ・プロバイダにマッピングされます。
認可: アプリケーション・ドメインで定義して、データベースで永続化したセキュリティ・ポリシーに基づいて、Oracle Access Manager 11gで認可が実行されます。認可ポリシーはリソースと制約の評価を定義します。
レスポンス: 管理者は、認証レスポンスと認可レスポンスを使用してセッション属性を設定できます。セッションの属性以外に、ユーザー関連のデータおよびリクエスト関連のデータもレスポンスで取得できます。設定したレスポンスは、その立証に効果的なエージェントにHTTPヘッダーまたはCookieとして送信されます。Cookieの値およびヘッダーの変数に対し、レスポンスは別のレスポンスで事前に設定されたセッション属性を取得できます。たとえば、レスポンスによって認証時に設定されたセッション属性を、認可の際にヘッダー値として取得できます。
セッション管理: Oracle Access Manager 11gセッション管理サービスでは、Oracle Coherenceのテクノロジに基づく高パフォーマンス分散キャッシュ・システムを介してアクティブ・ユーザー・セッションを追跡します。各Oracle Access Managerの実行時インスタンスは、この分散キャッシュ・システムにあるノードとなります。これらのノード間のセキュアな通信は、対称鍵を使用すると容易に実行できます。Oracle Access Managerの実行時インスタンスは、ローカルのキャッシュにあるユーザー・セッション・データを分散キャッシュに移動して、他のノードから選択できるようにします。また、Oracle Access Managerの実行時インスタンスごとにレプリケーション・ファクタを構成して、セッション・データをどのように分散するかを指定することもできます。管理者は、セッションのライフサイクルの構成、固有のアクティブ・セッションの検索と削除、任意の時点でユーザーが同時に実行できるセッション数の制限などが可能です。バンド外のセッションを終了すると、ユーザーがセッションを終了した後でシステムへの認可されないアクセスを防止します。
キー: Oracle Access Manager 11gのランタイムは、アプリケーションとしてWebLogic管理対象サーバーまたはクラスタにデプロイされます。新しいOracle Access Manager 11g WebGatesは、エージェントの信頼モデルごとに機密情報の共有をサポートします。11g Webゲートでは、エージェントとホストに固有のCookieを使用して優れたセキュリティを実現できます。Oracle Access Manager 11g Webゲートは、すべて同レベルで信頼されます。Webゲートにはそれぞれに固有のCookieが設定されるので、あるWebゲートのCookieを使用しても、他のWebゲートで保護されたアプリケーションにユーザーにかわってアクセスすることはできません。これにより、Cookieリプレイ・タイプの攻撃から防御できます。
SSOおよびSLO: Oracle Access Manager 11gサーバー・セッション・トークンは、Oracle Access ManagerとOSSOエージェント間のSSOの基礎を形成します。ログアウトは、Oracle Access Manager 11gサーバーのグローバル・ログアウトで実行します。これにより、中央のセッションは終了し、ユーザーはアクセスした各エージェントからログアウトします。
Oracle Access Manager 10g Webゲートでは、ログアウトによりObSSOCookieが削除され、グローバル・ログアウト・ページにリダイレクトされます。
Oracle Access Manager 11gのWebゲートおよびmod_ossoエージェントでは、ログアウトはグローバル・ログアウト・ページにリダイレクトされ、各エージェントはエージェント固有のCookieを削除するためにコールバックされます。
ロギングと監査: Oracle Access Manager 11gコンポーネントでは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとロギング・ガイドラインを使用します。Oracle Access Manager 11gでは、エージェントとサーバーの監視機能が用意されています。Oracle Access Manager 11gの監査機能は共通監査フレームワークに基づいています。監査レポートの生成は、Oracle Business Intelligence Publisherによりサポートされています。
アクセス・テスター: Oracle Access Manager 11gの新しいアクセス・テスターを使用すると、IT専門家や管理者は登録されたOracle Access Managerエージェントとサーバー間の相互作用をシミュレートできます。これは、セキュリティ・ポリシー定義のテストやエージェントの接続が関係する問題のトラブルシューティングで役立ちます。
テストから本番への移行: Oracle Access Manager 11gを使用して、構成やポリシーのデータを1つのOracle Access Manager 11gデプロイメントから別のデプロイメントに移動できます（小規模なテストデプロイメントから本番デプロイメントへの移動など）。テンプレートに基づく新規トポロジの作成がサポートされています。ポリシーに対する変更のコピーや移動も可能です。
OSSO 10gとの共存およびOSSO 10gのアップグレード: Oracleが提供するUpgrade Assistantは、既存のOracleAS 10g SSOサーバー構成をスキャンし、10g OSSOポリシー・プロパティ・ファイルおよびスキーマ情報を入力として受け入れ、構成済のパートナ・アプリケーションを移行先のOracle Access Manager 11g SSOに転送します。
|
関連項目:
|
次の概要では、認証プロバイダを使用してOracle Access Manager 11g SSOソリューションに必要なコンポーネントとファイルをインストールする際に完了する必要があるタスクについて説明します。Oracle Access Manager 11gとOracle Access Manager 10gとでは、これらのタスクの多くはほとんど同じですが、いくつかの相違点があります。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Access Manager 11gのインストールと初期構成の詳細に関する項 |
タスクの概要: 認証プロバイダおよびOAM 11gで使用するコンポーネントのインストール
Oracle Access ManagerのOracle Internet Directoryをインストールおよび設定します。
|
関連項目:
|
Oracle WebLogic Server 10.3.1以降をインストールおよび設定します。
|
関連項目: このリストの手順3および『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』 |
オプション: Fusion Middleware製品（Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど）をインストールします。
|
注意: Fusion Middlewareアプリケーションがインストールされていない場合は、以降の手順に従って、必要なJARファイルおよびWARファイルを入手する必要があります。 |
必要に応じて、Oracle Access Manager Webゲート用にOHS 11gをインストールします。
IDアサーション・プロバイダ: Oracle HTTP Server 11gのWebサーバーが、Oracle WebLogic Serverのフロントエンドにリバース・プロキシとして構成されている必要があります。
認証プロバイダまたはOracle Web Services Manager: カスタム・アクセス・ゲートでは、Webサーバーは必要ありません。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。
認証プロバイダ・ファイル: 次のように必要なJARファイルとWARファイルを確認します。
次のFusion Middlewareパスで、必要なJARファイルの場所を確認します。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
次のパスで、コンソール拡張WARファイルを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov ider.war
WARファイルを、WebLogic Serverホームの次のパスにコピーします。
WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
Oracle Access Manager 11g:
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明されているように、Oracle Access Managerをインストールして、初期構成を実行します。
Webゲートに1つのプライマリOAMサーバーと1つのセカンダリOAMサーバーを組み込みます。設定できるセカンダリ・サーバーは1つのみです。
Webゲート（シングル・サインオン用のIDアサーション・プロバイダで使用）: 1つ以上のWebゲートが存在する既存のWeb層では、プロビジョニングのみが必要です。新規Web層では、新しいWebゲートをインストールする必要があります。
どちらの場合にも、「Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」を参照してください。
認証プロバイダ（またはOracle Web Services Manager）用のアクセス・ゲート:
「Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」（または、認証プロバイダの構成時に既存のOAMエージェントの登録を参照）に説明されているように、10gアクセス・ゲートをプロビジョニングできます。
oamAuthnProvider.jarで使用できるカスタム10gアクセス・ゲートをデプロイします。
実装するには、次の手順を実行します。
シングル・サインオン用のIDアサーション・プロバイダ: 「Oracle Access Manager 11gでのSSO用のIDアサーションの構成」を参照してください。
認証プロバイダ: 「Oracle Access Manager 11g用の認証プロバイダの構成」を参照してください。
Oracle Web Services Manager: 「Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成」を参照してください。
Application Authenticatorアプリケーション・ドメインはOAM 11gで提供されます。このドメインは、OAM認証プロバイダをセキュリティ・プロバイダとしてWebLogic環境にデプロイしたアプリケーションとの統合を実現するポリシー・オブジェクトによって事前シードされています。これは、Webゲートのプロビジョニングに関連付けられていません。このドメイン（または既存のアプリケーション・ドメイン）を使用するためにWebゲートまたはアクセス・ゲートをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。
OAM認証プロバイダ（およびOracle Web Services Manager用IDアサーション・プロバイダ）で使用するカスタムの10gアクセス・ゲートで、Application Authenticatorアプリケーション・ドメインが機能するようになりました。この場合、カスタムのアクセス・ゲート（Webゲートではありません）が、OAM 11gにアクセスする前のユーザーを認証するためのトークンを使用して、WebLogic Serverに直接アクセスします。
Application Authenticatorアプリケーション・ドメインは、タイプwl_authenのリソースのみを保護し、2つの認証ポリシーと1つの認可ポリシーでシードされます。次のwl_authenリソースもこのドメインにシードされます。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion protected by LDAPNoPasswordValidationScheme
|
注意: このドメインで許可されているのは、タイプwl_authenのリソースのみです。他のリソース・タイプは追加できません。wl_authenリソースのポリシーとレスポンスは追加可能です。ただし、このドメインの変更が不要であることが理想です。 |
図9-4は、OAM 11g管理コンソールのシードされたApplication Authenticatorアプリケーション・ドメインの詳細を示しています。このページは、/Authen/UsernameAssertionリソースを保護する、事前シード済の認証ポリシーUser ID Assertionを示しています。このポリシーで保護しているリソースとともに、ポリシーの認証スキームも表示されています。
図9-5は、User ID Assertion認証ポリシーに対して事前シードされたレスポンスを示しています。レスポンスの詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。
図9-6は、事前シード済の認証ポリシーApplication SSO、このポリシーで保護されたリソースおよび認証スキームを示しています。
図9-7は、認証ポリシーApplication SSOに対してアプリケーション・ドメインで事前シードされたリソースを示しています。
図9-8は、アプリケーション・ドメインで事前シードされた認可ポリシーApplication SSOとリソースを示しています。
認可の制約: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOの制約がありません。ただし、Oracle Fusion Middleware Oracle Access Manager管理者ガイドで説明されているように、制約を追加することはできます。
認可のレスポンス: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOのレスポンスがありません。ただし、Oracle Fusion Middleware Oracle Access Manager管理者ガイドで説明されているように、レスポンスを追加することはできます。
プロビジョニングとは、OAM 11gの認証と認可のサービスを使用するために、エージェントを登録してアプリケーション・ドメインを作成するプロセスです。新しい11gインスタンスまたは10gインスタンスをインストールする場合でも、レガシーの10g Webゲートがインストール済の場合でも、OAM 11gでWebゲートをプロビジョニングする必要があります。
用語としてのWebゲートは、複数のWebゲートを表します（Oracle Web Services Managerの認証プロバイダおよびIDアサーション・プロバイダで使用するカスタムの10gアクセス・ゲートも指します）。特に明記されていなければ、この項の内容は両方に同様に当てはまります。
複数のエージェントがある場合、それぞれを別々にプロビジョニングできるほか、複数のエージェントに単一のOAMエージェント登録を使用することもできます。
|
注意: Application Authenticatorアプリケーション・ドメインは事前シード済で、OAM 11gで提供されます。このアプリケーション・ドメイン（または別の既存のアプリケーション・ドメイン）を使用するためにOAMエージェントをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。 |
この項の内容は次のとおりです。
表9-2は、OAM 11gで使用するためにWebゲートをプロビジョニングする際に使用できるメソッドとツールについて説明しています。リモート登録ツールにより、テンプレートを使用して少量またはすべてのWebゲート・パラメータを指定できます。
表9-2 OAM 11g用のメソッドのプロビジョニング
| メソッド | 説明 |
|---|---|
|
Oracle Access Manager管理コンソール |
Oracle Access ManagerでOAMの管理者が手動で情報を入力し、直接パラメータを設定できるようにします。この方法は、認証プロバイダを使用している場合、またはOracle Web Services ManagerポリシーでWebサービスを保護している場合に必要です。 |
|
リモート登録 |
アプリケーションの管理者は、シングル・サインオン用のIDアサーション・プロバイダを実装する際に、コマンドラインを使用してWebゲートを登録できます。また、これによって新しいWeb層または既存のWeb層のセキュリティ・ポリシーを持つ新規アプリケーション・ドメインが作成されます。 必須パラメータは、テンプレートで指定する、環境に適した値を使用してプロビジョニングします。必須ではないパラメータについては、デフォルト値を使用します。登録が終了すると、OAM管理コンソールで値を変更できるようになります。 |
リモート登録の際には、表9-3で説明されている詳細を指定する必要があります。
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイドのすべてのWebゲート・パラメータのリストに関する項 |
表9-3 OAMエージェントに必須の登録の詳細
| OAMエージェントの要素 | 説明 |
|---|---|
|
<serverAddress> |
ホストとポートを含む、Oracle Access Manager管理コンソールの実行中のインスタンスを指します。 |
|
<webDomain> OSSOリクエスト専用 |
エージェント・ベースのURLが内部的に保存されているWebサーバー・ドメインを定義します。 |
|
<agentName> |
OAM（管理）サーバーでのエージェントの一意な識別子を定義します。 同じサーバー・インスタンス上のエージェントごとにこのタグは一意にして、同一エージェントの再登録を回避する必要があります。 同一のサーバー・インスタンス上で1つのエージェントを再登録することはできません。 |
|
<hostIdentifier> |
この識別子は、Webサーバーのホストを表しています。このフィールドは、OAMエージェント名の値を指定すると自動的に入力されます。同じ名前のエージェント名またはホスト識別子がすでに存在する場合には、登録時にエラーが発生します。 |
|
<protectedResourcesList> |
一部の認証スキームでOAMエージェントを保護するリソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。 |
|
<publicResourcesList> |
公開する（OAMエージェントで保護しない）リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。 |
Webゲートやアクセス・ゲートのプロビジョニングには、前述と同じ手順を実行します。認証プロバイダで使用する新規インスタンスのプロビジョニングや、プロバイダを構成する際に既存の登録の参照などができます。
この例では、OAMRequest_short.xmlテンプレートを使用してOAM 10g Webゲートをプロビジョニングします。登録されたエージェントは、my-wl-agent1と名付けられ、/.../*を保護し、パブリック・リソースの/public/index.htmlを宣言します。なお、実際に指定する値は各環境によって異なります。
|
注意: OAM 11g Webゲートのプロビジョニングでは、OAM11gRequest_short.xmlテンプレートを使用します。 |
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイド |
ツールの入手: Webゲートをホストするコンピュータ上でリモート登録ツールを入手し、使用する環境に合せてスクリプトを設定します。次に例を示します。
次のパスでRREG.tar.gzファイルを見つけます。
WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz
RREG.tar.gzファイルを任意の適切な場所に展開します。例: rreg/bin/oamreg。
oamregスクリプトで、実際の状況がクライアント側であるかサーバー側であるかに応じて次の環境変数を設定し、さらにOracle Fusion Middleware Oracle Access Manager管理者ガイドの表6と表7にある情報を設定します。
登録リクエストの作成:
*Request_short.xmlファイルを探し、新しい場所にコピーして名前を付けます。次に例を示します。
WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
コピー元ファイル: OAMRequest_short.xml（またはOAM 11gRequest.xml）
コピー先ファイル: my-wl-agent1.xml
my-wl-agent1.xmlを編集して、環境の詳細を指定し、自動ポリシーの作成をfalseに設定します。次に例を示します。
<OAMRegRequest>
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>my-wl</hostIdentifier>
<agentName>my-wl-agent1</agentName>
<primaryCookieDomain>.us.example.com</primaryCookieDomain>
<autoCreatePolicy>false</autoCreatePolicy>
<logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
</OAMRegRequest>
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイドの登録リクエストの作成に関する項 |
エージェントをプロビジョニングします。次に例を示します。
リモート登録スクリプトを見つけます。
chmod +x oamreg.shWindowsの場合: rreg\bin\oamreg.bat
スクリプトが存在するディレクトリから、inbandモードを使用してこのスクリプトを実行します。次に例を示します。
$ ./bin/oamreg.sh inband input/my-wl-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"
コンソールの確認: OAM管理コンソールにログインして、新規登録を確認します。
OAM 11gコンソールの「システム構成」タブでナビゲーション・ペインに移動して「エージェント」ノードを開き、次のようにプロビジョニングしたエージェントを見つけます。
エージェント名をダブルクリックして登録のページを表示し、詳細を確認します。これは後で使用します。次に例を示します。
エージェント名: Webゲートのインストール時に、WebゲートIDとして入力します。カスタム10gアクセス・ゲートをデプロイする場合は、WebLogic管理コンソールでOAM認証プロバイダを構成する際に、これをアクセス・ゲート名として入力します。
アクセス・クライアント・パスワード: Webゲートのインストールの際に、Webゲートのパスワードとして入力します。パスワードを入力しなかった場合、このフィールドは空白のままでかまいません。
アクセス・サーバー・ホスト名: このWebゲートの登録先とするプライマリOAM 11gサーバーのDNSホスト名を入力します。
OAMプロキシ・ポート: OAM管理コンソールの「システム構成」タブでナビゲーション・ペインに移動し、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが稼働しているポートを見つけます。
プロビジョニングの際に作成されたObaccessclient.xmlファイルは、この段階では無視します。
それぞれの環境に応じて次の手順を実行します。
エージェントをインストール済の環境: 実装に応じて、次の適切な項に移動します。
エージェントをインストールしていない環境:
11g WebGateの場合: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
10g Webゲートの場合: Oracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。
この項では、シングル・サインオン用のOracle Access Manager 11g IDアサーションの構成に必要な固有の手順について説明します。
前提条件
Oracle Access Manager 11gでの認証プロバイダのインストール
Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
アプリケーションでシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを構成するには、次のタスクの概要で説明されている手順を実行します。
タスクの概要: OAM 11gでのSSO用IDアサーション・プロバイダのデプロイ
前提条件のすべてのタスクが実行されていることの確認
次の項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。
|
注意: このタスクはOAM 11g WebゲートとOAM 10g Webゲートの両方で同じです。 |
この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager IDアサーション・プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をCLIENT-CERTに指定する必要があります。
WebLogic Serverのhost:portを介して直接アプリケーションにアクセスし、コンテナで認証されるようにする場合は、ここにカンマで区切った複数の値を指定できます。たとえば、<auth-method>CLIENT-CERT,FORM</auth-method>とします。
auth-methodには、BASIC、FORMまたはCLIENT-CERTの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
IDアサーション・プロバイダのweb.xmlで認証を指定するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
my_app/WEB-INF/web.xml
login-configでauth-methodを検索し、CLIENT-CERTと入力します。
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
「Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認」に進みます。
Oracle HTTP Serverには、mod_weblogicプラグイン・モジュール（11gではmod_wl_ohs.so）が含まれており、すでに有効になっています。次の手順を実行してこれを確認するか、またはこの手順を省略できます。
Oracle HTTP Server 11gでは、mod_weblogic構成はデフォルトでmod_wl_ohs.confに存在し、このファイルのパスはhttpd.confに含まれています。mod_weblogic構成が存在しない場合は、httpd.confを編集する必要があります。
Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicを構成するには
httpd.confを見つけます。たとえば、次の場所にあります。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
ファイル内に次の文があり、デプロイメントに適した値が指定されていることを確認します（必要に応じてコメントを追加または削除する）。
<IfModule mod_weblogic.c> WebLogicHost myHost.myDomain.com WebLogicPort myWlsPortNumber </IfModule> <Location http://request-uri-pattern> SetHandler weblogic-handler </Location>
ファイルを保存します。
Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。
|
注意: この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。 |
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。このフィルタを使用すると、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。ネットワーク接続フィルタは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。
接続フィルタを構成してmod_weblogicとOHS 11gが実行されているホストからのリクエストのみを許可するには、ここで説明する手順を実行します。
|
注意: この章では、Apache用WebLogic Serverプラグインの汎用名（mod_weblogic）を使用します。Oracle HTTP Server 11gでは、このプラグインの名前はmod_wl_ohsですが、実際のバイナリ名はmod_wl_ohs.soになります。後述する例は、実装可能な正確な構文を示しています。 |
WebLogic Serverでは、デフォルト接続フィルタweblogic.security.net.ConnectionFilterImplが提供されます。このフィルタは、すべての着信接続を受け入れ、サーバーによる現在の接続フィルタの取得を許可する静的ファクトリ・メソッドも提供します。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力します。
また、weblogic.security.netパッケージにクラスを実装することにより、カスタム接続フィルタを使用することもできます。デフォルト接続フィルタと同様、カスタム接続フィルタはWebLogic Server管理コンソールで構成します。
接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。
targetAddress localAddress localPort action protocols
表9-4は、接続フィルタの各パラメータを説明しています。
表9-4 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
target |
フィルタ対象の1つ以上のシステムを指定します。 |
|
localAddress |
WebLogic Serverインスタンスのホスト・アドレスを定義します（アスタリスク（*）を指定すると、すべてのローカルIPアドレスが返される）。 |
|
localPort |
WebLogic Serverインスタンスのリスニング・ポートを定義します（アスタリスク（*）を指定すると、サーバー上のすべての使用可能なポートが返される）。 |
|
action |
実行するアクションを指定します。この値は、allowまたはdenyである必要があります。 |
|
protocols |
フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。 |
「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項 |
11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」の下の「ドメイン」をクリックします。
「セキュリティ」タブ→「フィルタ」タブをクリックします。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
「WebLogicドメインでのプロバイダの構成」に進みます。
ここでの情報は、OAM 11gおよびOAM 10gに同じように当てはまります。この項の内容は次のとおりです。
この項では、WebLogicセキュリティ・レルムの認証プロバイダを初めて使用するユーザーのために、いくつかのタイプの認証プロバイダのみを説明します。
WebLogicセキュリティ・レルムごとに、少なくとも1つの認証プロバイダを構成する必要があります。WebLogicセキュリティ・フレームワークは、マルチパート認証用に複数の認証プロバイダ（および複数のLoginModule）をサポートするように設計されています。このため、1つのセキュリティ・レルムで複数の認証プロバイダと複数のタイプの認証プロバイダを使用できます。制御フラグ属性により、認証プロセスにおいて各認証プロバイダのLoginModuleがどのように使用されるかが決定されます。
Oracle WebLogic Serverは、次のものを含め、複数のタイプの認証プロバイダとIDアサーション・プロバイダを提供します。
デフォルトのWebLogic認証プロバイダ（デフォルトの認証プロバイダ）では、ユーザーとグループを1箇所で、つまり、WebLogic Serverの組込みLDAPサーバーで管理できます。この認証プロバイダは、Oracle WebLogic Serverでの管理ユーザー・ログインに使用されます。
IDアサーションは、トークンベース認証を使用します。Oracle Access Manager IDアサーション・プロバイダはその一例です。これは、インストール済Webゲート（10gまたは11g）の適切なアクションを使用するように構成する必要があります。詳細は、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
LDAP認証プロバイダは、ユーザーおよびグループ情報を外部LDAPサーバーに格納します。このプロバイダは主に、一般的なディレクトリ・スキーマが反映されるように、対応するLDAPサーバーがデフォルトで構成されている点が異なります。
Oracle WebLogic Server 10.3.1以降では、OracleInternetDirectoryAuthenticatorを使用できます。
複数の認証プロバイダを構成する場合、各プロバイダに対してJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの使用方法を制御します。たとえば、次のJAAS制御フラグ設定を選択できます。
REQUIRED: 認証プロバイダが常に呼び出され、ユーザーはその認証テストを常にパスする必要があります。認証の成否に関係なく、プロバイダ・リストの最後まで認証が続行されます。
SUFFICIENT: ユーザーは、認証プロバイダの認証テストをパスする必要はありません。認証に成功した場合、後続の認証プロバイダは実行されません。認証に失敗した場合、プロバイダ・リストの最後まで認証が続行されます。
OPTIONAL: ユーザーは、認証プロバイダの認証テストをパスしても失敗してもかまいません。ただし、セキュリティ・レルムに構成されているすべての認証プロバイダでJAAS制御フラグがOPTIONALに設定されている場合は、ユーザーは構成されているプロバイダのいずれかの認証テストをパスする必要があります。
既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。場合によっては、認証シーケンスで各認証プロバイダが適切に機能するように、制御フラグの設定とプロバイダの順序を変更する必要があります。
|
関連項目: すべての認証プロバイダのリストと、ユーザーおよびグループ属性をLDAPスキーマと一致させるためのOracle Internet Directoryプロバイダの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項を参照してください。 |
この項では、WLSTを初めて使用するユーザーのために、WLSTについて説明します。
Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool（WLST）コマンドライン・ツールを使用して、WebLogicドメインにプロバイダを追加できます。
WLSTはJythonベースのコマンドライン・スクリプト環境で、WebLogic Serverドメインの管理と監視のために使用できます。通常、このツールはオンラインまたはオフラインで使用できます。このツールは、ファイルで提供されるバッチ（ユーザーの入力を介在せずに、スクリプトが一連のWLSTコマンドを呼び出すスクリプト・モード）において、コマンドラインで対話的に実行することができます。また、Javaコードに組み込むことも可能です。
WebLogicドメインに認証プロバイダを追加する場合、WLSTをオンラインで使用して認証プロバイダと対話し、ユーザー、グループおよびロールを追加、削除または変更できます。
WLSTをオフラインで使用してドメイン・テンプレートを作成する場合、WLSTによって認証プロバイダのデータ・ストアとその他のドメイン文書がパッケージ化されます。ドメイン・テンプレートからドメインを作成すると、新しいドメインは、ドメイン・テンプレートの認証プロバイダのデータ・ストアとまったく同じコピーになります。ただし、WLSTをオフラインで使用して認証プロバイダのデータ・ストア内のデータを変更することはできません。
|
注意: WLSTをオフラインで使用して、認証プロバイダのデータ・ストア内のデータを変更することはできません。 |
|
関連項目:
|
Oracle Application Development Framework（Oracle ADF）セキュリティを使用し、Oracle Access Manager Single Sign On（SSO）と統合し、ユーザー認証にOracle Platform Security Services（OPSS）SSOを使用するWebアプリケーションをOracle WebLogic Server上で実行できます。ただし、Webアプリケーションを実行する前に、アプリケーションのターゲットのOracle WebLogic Server上で、Oracle Access Managerセキュリティ・プロバイダ用にドメインレベルのjps-config.xmlファイルを構成する必要があります。
ドメインレベルのjps-config.xmlファイルは次のパスに存在します。デプロイ済のアプリケーションのjps-config.xmlファイルと混同しないでください。
domain_home/config/fmwconfig/jps-config.xml
Webアプリケーションのデプロイ前またはデプロイ後に、Oracle Access Manager固有のWLSTスクリプトを使用して、ドメインレベルのjps-config.xmlファイルを構成できます。このOracle JRF WLSTスクリプトの名前は次のとおりです。
Linux: wlst.sh
Windows: wlst.cmd
JDevを使用して実行している場合、Oracle JRF WLSTスクリプトは次のパスにあります。
$JDEV_HOME/oracle_common/common/bin/
JRF WebLogicをスタンドアロンでインストールしている場合のパスは次のとおりです。
$Middleware_home/oracle_common/wlst
|
注意: Oracle JRF WLSTスクリプトが必要です。Oracle Java Required Files（JRF）用のWLSTを実行している場合は、$JDEV_HOME/wlserver_10.3/common/binにあるWLSTスクリプトを使用しないでください。 |
コマンド構文
addOAMSSOProvider(loginuri, logouturi, autologinuri)
表9-9では、addOAMSSOProviderコマンドラインにおける各引数の予想される値を定義しています。
表9-5 addOAMSSOProviderコマンドライン引数
| 引数 | 定義 |
|---|---|
|
loginuri |
ログイン・ページのURIを指定します。 |
|
autologinuri |
自動ログイン・ページのURIを指定します。 |
|
logouturi |
ログアウト・ページのURIを指定します。 |
|
関連項目:
|
前提条件
Oracle ADFセキュリティが有効なFusion Webアプリケーション用のドメインレベルのjps-config.xmlを変更するには:
Oracle WebLogic ServerおよびOracle ADFセキュリティを使用しているWebアプリケーションをホストするコンピュータ上で、Oracle JRF WLSTスクリプトを見つけます。次に例を示します。
cd $ORACLE_HOME/oracle_common/common/bin
Oracle WebLogic Serverをホストするコンピュータに接続します。
connect login_id password hostname:port
たとえば、Oracle WebLogic管理サーバーのホストは、ポート7001を使用するlocalhostであることが考えられます。ただし、これは使用する環境によって異なる可能性があります。
ADFセキュリティが有効なアプリケーション用の値を使用して、次のコマンドライン引数を入力します。
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
Oracle WebLogic Serverを停止して起動します。
この章で説明されているように次のタスクを実行します。
この項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンを実行するために、WebLogicセキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。
OAM IDアサーション・プロバイダ: REQUIRED（OAM 11gで使用しているWebゲートのリリースに基づいて選択したアクション・タイプ（表9-10）も指定します)
次の手順では、WebLogic管理コンソールを使用します。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。手順1を省略してください。 |
シングル・サインオン用のOracle Access ManagerプロバイダをWebLogicドメインに設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート（10.1.4.3.0）を使用してoamAuthnProvider ZIPファイルを見つけます。
oamAuthnProvider<version number>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
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 IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブをクリックし、「制御フラグ」をREQUIREDに設定します。
「共通」タブをクリックし、インストール済のWebゲートに選択した「アクション・タイプ」を指定します（表9-10）。
保存します。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース（ユーザー・ベースDNと同じ）。
デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。
保存します。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
保存します。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: （REQUIRED）
OID認証プロバイダ: （SUFFICIENT）
デフォルトの認証プロバイダ: （SUFFICIENT）
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次の手順を実行します。
成功: 「Oracle Access Manager IDアサーション・プロバイダのログイン・ページの確認」を参照してください。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
前述のとおり、10g Webゲートに付属のログイン・フォームは、OAM 10gアクセス・サーバーでのみ使用します。OAM 11gの場合、10g Webゲートでも11g Webゲートでもログイン・ページは提供されません。
|
注意: OAM 11g Serverでは、ログイン・ページが表示されます。設定は必要ありません。 |
次の手順を実行します。
次の手順では、Oracle Access Manager IDアサーションの設定をテストする方法について説明します。
また、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
シングル・サインオン用のOracle Access Manager IDアサーションを検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。次に例を示します。
http://ohs_server:port/<protected url>
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
認証プロバイダを使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、Oracle Access Manager認証スキームが必要です。これは、Oracle Access Manager 11gで提供されている事前シード済アプリケーション・ドメインにあります。この認証スキームは、次のリソース（resource type wl_authen）を保護します。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
ポリシーにはレスポンスと制約を追加できます。ただし、それ以外の構成は必要ありません。
事前シード済のアプリケーション・ドメインの詳細は、「OAM 10gアクセス・ゲートによって使用される事前シード済のOAM 11gポリシーの確認」を参照してください。
前提条件
Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
|
注意: 認証プロバイダ用のカスタム10gアクセス・ゲートをプロビジョニングできます。または、認証プロバイダの構成時に既存のOAMエージェントの登録を参照できます。どちらの場合にも、認証プロバイダの実装では事前シード済のFusion Apps Integrationドメインのポリシーが使用されます。 |
Oracle Access Manager認証プロバイダを構成するためのタスクについては、次の概要で説明します。
タスクの概要: Oracle Access Manager認証プロバイダの構成
前提条件のすべてのタスクが実行されていることの確認
この項では、WebLogicドメインに適切な認証プロバイダを追加および構成するための手順について説明します。
Oracle Access Manager認証プロバイダは、WebLogicドメインのデフォルト認証プロバイダに従って構成する必要があります。
次の手順では、WebLogic管理コンソールを使用してこのタスクを実行する方法について説明します。これらは、Oracle WebLogic Scripting Tool（WLST）を使用して追加することもできます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なファイルはすでにインストールされているので、手順1は省略できます。 |
WebLogicドメインにOracle Access Manager認証プロバイダを構成するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート（10.1.4.3.0）を使用してoamAuthnProvider ZIPファイルを見つけます。次に例を示します。
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic管理コンソールに移動します。
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
Oracle WebLogic管理コンソールに移動します。
必要に応じて、「ロックして編集」をクリックします。
OAM認証プロバイダ:
「セキュリティ・レルム」をクリックし、構成するレルムを選択します。
「プロバイダ」→「認証」を選択し、「新規」をクリックして、「新しい認証プロバイダの作成」ページを表示します。
名前を入力して、タイプを選択します。
名前: OAMAuthN
タイプ: OAMAuthenticator
OK
作成した認証プロバイダの名前をクリックして、「プロバイダ構成」ページを表示します。
「プロバイダ構成」ページで、次のように必要な値を設定します。
アクセス・ゲート名: プロバイダによって使用されるアクセス・ゲートの名前。これは、OAM管理コンソールのOAMエージェント登録の名前と完全に一致している必要があります。
|
注意: OAM 11gでは1つ以上の10g OAMエージェントを登録できます。正しいエージェント登録名を選択してください。 |
アクセス・ゲートのパスワード: エージェント登録に対してパスワードが定義されている場合は、それと同じパスワード（OAM管理コンソールを参照）。
プライマリ・アクセス・サーバー: OAM管理コンソールでこのアクセス・ゲートに関連付けられているプライマリ・アクセス・サーバーのhost:port。
詳細構成: 次に、いくつかの詳細構成の値を示します。
トランスポート・セキュリティ: アクセス・サーバーとアクセス・ゲート間の通信モード（オープン、簡易、証明書）。
トランスポート・セキュリティが簡易または証明書である場合、次のパラメータと値を含めてください。
トラスト・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSトラスト・ストアの絶対パス。
キー・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSキー・ストアの絶対パス。
キー・ストアのパスフレーズ: キー・ストアにアクセスするためのパスワード。
簡易モード・パスフレーズ: アクセス・ゲートとOAM Serverで共有する簡易通信モード用パスワード。
セカンダリOAMサーバー: OAM管理コンソールでこのアクセス・ゲートに関連付けられているセカンダリOAMサーバーのhost:port。
プール内の最大OAMサーバー接続数: アクセス・ゲートがOAMサーバーに対してオープンする最大接続数。デフォルト値は10です。
|
注意: WebLogic管理コンソールで指定するプール内の最大OAMサーバー接続数（またはプール内の最小OAMサーバー接続数）の設定は、OAM管理コンソールで指定する「最大接続数」や「最小接続数」とは異なります。 |
プール内の最小アクセス・サーバー接続数: 認証プロバイダからアクセス・サーバーへの認証リクエストの送信に使用する最小接続数。デフォルト値は5です。
パラメータ「制御フラグ」がOPTIONALに初期設定されていることを確認します。
|
注意: 認証プロバイダが機能し、正しく構成されていることを確認するまで、パラメータ「制御フラグ」をREQUIREDに設定しないでください。 |
チェンジ・センターで、変更のアクティブ化をクリックします。
DefaultAuthenticator: 「プロバイダ」タブでDefaultAuthenticatorを選択します。これにより、その制御フラグがSUFFICIENTに変更されます。
並べ替え: 「プロバイダ」タブで、DefaultAuthenticatorが先頭になるように（DefaultAuthenticatorの後にOAMAuthenticator)プロバイダを並べ替えます。
|
注意: Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。 |
Oracle Access Manager認証プロバイダのREQUIREDまたは唯一の認証プロバイダである場合: 次の手順を実行して、Oracle WebLogic Serverを起動するためのユーザー権限を設定します。
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ（または、起動権限を付与する必要があるその他のグループ）を作成します。
|
注意: その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。 |
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
Adminロールの「構成の表示」を選択します。
グループを追加して「保存」をクリックします。
WebLogic Serverを再起動します。
サーバーを起動すると、認証プロバイダ・パラメータ「制御フラグ」が適切な値（REQUIRED、OPTIONAL、またはSUFFICIENT）にリセットされます。
「認証プロバイダのアプリケーション認証方式の構成」に進みます。
この項では、Oracle Access Manager認証プロバイダのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager認証プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をBASICに指定する必要があります。
auth-methodには、BASICまたはFORMの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
|
注意: Oracle Access Manager認証プロバイダの場合、web.xml内のlogin-configにauth-method BASICを指定することをお薦めします。 |
認証プロバイダのアプリケーション認証方式を構成するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
WEB-INF/web.xml
login-configでauth-methodを検索し、BASICと入力します。次に例を示します。
<security-constraint> <web-resource-collection> <web-resource-name>protected</web-resource-name> <url-pattern>/servlet</url-pattern> </web-resource-collection> <auth-constraint> <role-name>auth-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <description>Authenticated Users</description> <role-name>auth-users</role-name> </security-role>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
「LDAP内のグループへの認証ユーザーのマッピング」に進みます。
この項では、認証ユーザーをLDAP内のグループにマップする方法について説明します。このためには、weblogic.xmlファイルを編集する必要があります。たとえば、ロール名auth-usersをLDAP内のmanagersというグループにマップできます。
Oracle Access Manager認証プロバイダ用に認証ユーザーをLDAP内のグループにマップするには
アプリケーションのweblogic.xmlファイルに移動します。
ファイル内の任意の場所に、環境に応じて次の情報を追加します。
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<security-role-assignment>
<principal-name>managers</principal-name>
<role-name>auth-users</role-name>
</security-role-assignment>
</weblogic-web-app>
ファイルを保存します。
WebLogic Serverを再起動します。
「Oracle Access Manager 11g用の集中管理ログアウトの構成」に説明されているように集中管理ログアウトを構成し、ここに戻ってOracle Access Manager認証プロバイダの実装のテストを実行します。
認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。
次の手順では、認証プロバイダの設定をテストする方法について説明します。また、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
Oracle Access Manager認証プロバイダの実装を検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。次に例を示します。
http://yourdomain.com:port
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
この項では、Oracle Web Services ManagerでWebサービスを保護している場合に、トークンの検証を有効にするようにOracle Access Manager IDアサーション・プロバイダを設定する方法について説明します。
前述のとおり、Oracle Access Manager IDアサーション・プロバイダは2つのモードで機能します。デフォルト・モードの操作では、Webゲートが境界で設定したヘッダーがアサートされます。これで、ほとんどのSSOの処理を扱うことができます。もう1つのモードでは、oamAuthnProvider.jarにあるカスタム・アクセス・ゲートを使用します。この場合、ヘッダーが存在しないと、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager 11gでの認証プロバイダのインストール」を参照してください。
|
注意: Oracle Web Services ManagerのIDアサーション・プロバイダには、認証プロバイダが提供する10gカスタム・アクセス・ゲートが必要です。 |
OAM 10gでは、ポリシー・ドメインおよびこの構成に対応するポリシーの手動での作成が必要になることがあります。一方、OAM 11gでは、次のリソース（resource type wl_authen）を保護するポリシーを設定した事前シード済アプリケーション・ドメインが提供されます。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
ype wl_authenタイプのリソースのポリシー、レスポンスまたは制約を追加できます。ただし、これ以上の構成をせずにこのアプリケーション・ドメインを使用できることが理想的です。詳細は、「OAM 10gアクセス・ゲートによって使用される事前シード済のOAM 11gポリシーの確認」を参照してください。
Oracle Access Manager IDアサーション・プロバイダがヘッダーとトークンの両方の検証モードで構成されている場合、ヘッダー検証モードが優先します。ヘッダーが存在しない場合、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
前提条件
Oracle Access Manager 11gでの認証プロバイダのインストール
Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
タスクの概要: Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ
この項では、Oracle Web Services Managerポリシーを構成してWebサービスを保護する方法について概説します。
Oracle Web Services ManagerでIDアサーション・プロバイダを使用するには、Webサービスにoracle/wss_oam_token_service_policyを設定し、対応するクライアントにoracle/wss_oam_token_client_policyを設定する必要があります。
oracle/wss_oam_token_service_policyについて
このOracle Web Services Managerポリシーには、ポリシー・アサーションoracle/wss_oam_token_service_templateが含まれています。このテンプレートは、WSセキュリティ・ヘッダーのバイナリ・セキュリティ・トークンの資格証明を使用して、Oracle Access Managerアイデンティティ・ストアに対してユーザーを認証します。
Oracle Access Manager IDアサーション・プロバイダは、ObSSOCookieトークンを使用して、oracle/wss_oam_token_service_policyポリシーによって保護されているWebサービスにアクセスしようとしているユーザーのアイデンティティをアサートします。このポリシーによって保護されているWebサービスは、SOAPヘッダーのObSSOCookieトークンで提示される必要があります。つまり、WebサービスはObSSOCookieトークンを使用し、トークンの生成方法には関与しません。具体的には、WebLogic Serverセキュリティ・サービスがトークン・タイプを検出し、Oracle Access Manager IDアサーション・プロバイダを呼び出します。Oracle Access Manager IDアサーション・プロバイダは、Oracle Access Managerアクセス・サーバーに対してObSSOCookieトークンを検証し、ユーザー名を取得します。ユーザー名がプリンシパルとして認証済サブジェクトに移入されます。
Webサービス・クライアント（Webアプリケーションなど）は、ObSSOCookieトークンを取得してWebサービスに送信する必要があります。通常、これはアクセス・ゲートを使用して行われます。アクセス・ゲートは、（Oracle Access Managerで構成された認証スキームに応じて）Webサービス・クライアントのユーザーに資格証明を要求し、ユーザーを認証します。認証が成功すると、WebゲートによってObSSOCookieがユーザーのブラウザに送信されます。
Webサービス・クライアントは、ObSSOCookieトークンをSOAPリクエストとしてWebサービスに送信します。
|
注意: wss_oam_token_service_templateの設定は、クライアント・バージョンのアサーションwss_oam_token_client_templateと同じです。サービス・テンプレートのアイデンティティ・ストア構成は、クライアント・バージョンのアサーションと同じです。 |
oracle/wss_oam_token_client_policyについて
このOracle Web Services Managerポリシーには、ポリシー・アサーションoracle/wss_oam_token_client_templateが含まれています。このテンプレートは、Oracle Access Manager資格証明をバイナリ・セキュリティ・トークンの一部としてWSセキュリティ・ヘッダーに挿入します。
oracle/wss_oam_token_client_policyは、oracle/wss_oam_token_service_policyサービス・エンドポイント・ポリシーに対応するクライアント・ポリシーです。このポリシーは、任意のSOAPベースのエンドポイントで実施できます。
次のタスクの概要に、実行する必要のある手順の概要を示します。
タスクの概要: Oracle Web Services Managerのポリシーの設定
Oracle Web Services Managerを使用して、Webサービスにoracle/wss_oam_token_service_policyポリシーを設定します。
Oracle Web Services Managerを使用して、Webサービスに対応するクライアントにoracle/wss_oam_token_client_policyポリシーを設定します。
|
関連項目:
|
Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダを使用するには、WebLogicドメインでいくつかの認証プロバイダを構成し、並べ替える必要があります。
この手順は、OAM 11gでのOracle Access Manager IDアサーション・プロバイダの場合とほとんど同じです。この場合の相違点は、Oracle Web Services Managerはカスタム・アクセス・ゲートを必要とし、追加のプロバイダ固有の値が必要になることです。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: mnop:8888。
アクセス・ゲート名: アプリケーションを保護するアクセス・ゲート登録の名前。例: AG1。
アクセス・ゲートのパスワード: OAM管理コンソールで指定したアクセス・ゲート・パスワード。
これらは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool（WLST）コマンドライン・ツールを使用して追加できます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダ・ファイルはすでにインストールされています。手順1を省略してください。 |
WebLogicドメインでプロバイダを設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート（10.1.4.3.0）を使用してoamAuthnProvider ZIPファイルを見つけます。次に例を示します。
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic管理コンソールにログインします。
OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブで、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。
「共通」タブをクリックして10gカスタム・アクセス・ゲート用に選択したアクション・タイプとしてObSSOCookieを指定し、「保存」をクリックします。
「プロバイダ固有」タブをクリックし、次のパラメータを構成します。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。
アクセス・ゲート名: アプリケーションを保護するOAMエージェントの登録名。例: AG1。
アクセス・ゲートのパスワード: プロビジョニングの際に指定したアクセス・ゲート・パスワードがあれば、そのパスワード。
保存します。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
「OK」をクリックします。
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース（ユーザー・ベースDNと同じ）。
|
注意: デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。 |
「保存」をクリックします。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
「保存」をクリックします。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: （REQUIRED）
OID認証プロバイダ: （SUFFICIENT）
デフォルトの認証プロバイダ: （SUFFICIENT）
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次の手順を実行します。
成功: 「Oracle Access Manager 11g用の集中管理ログアウトの構成」に進み、ここに戻って「Oracle Web Services Manager用IDアサーション・プロバイダのテスト」を実行します。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「Oracle Access Manager 11gでの認証プロバイダのインストール」の説明にあるように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
Oracle Web Services Managerを使用している場合にOracle Access Manager IDアサーション・プロバイダの使用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスに成功した場合、実装は機能しています。失敗した場合は、「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
この項では、Oracle Access Manager 11g用の集中管理ログアウトについて説明します。
OAM 11gでは、集中管理ログアウトとはアクティブなユーザー・セッションを終了するプロセスを意味します。ガイドラインの内容は次のとおりです。
SSO環境で使用するアプリケーションは、自身のログアウト・ページを表示しないようにする必要があります。
アプリケーションは、OAM Webゲート管理者が指定したログアウトURLを指す値でログアウト・リンクを構成できるようにする必要があります。
|
注意: アプリケーションでADF認証サーブレットを使用することを強くお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。 |
詳細は、次の各項を参照してください。
OAM 11gエージェントの登録ページのいくつかの要素によって、OAM 11g Webゲートの中央管理されたログアウトが有効になります。エージェントの登録後、その情報がObAccessClient.xmlファイルに移入されます。
エージェントの登録の際に指定する必要のある11g Webゲートのログアウトオプションには、次のものがあります。
ログアウトURL: ログアウト・ハンドラをトリガします。これにより、Cookie（10g Webゲート用ObSSOCookie、11g Webゲート用OAMAuthnCookie）が削除されるので、Oracle Access Managerで保護されたリソースにこのユーザーが次回アクセスする際には再認証が必要になります。
ログアウト・コールバックURL: oam_logout_successへのURLです。コールバックの際にCookieを消去します。これには、host:portのないURI形式を指定できます（推奨）。これにより、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。
ログアウト・リダイレクトURL: このパラメータには、エージェントの登録が完了すると自動的に情報が移入されます。デフォルトでは、ポートをデフォルトの14200としたOAMサーバーのホスト名に基づきます。
ログアウト・ターゲットURL: この値は、ログアウトの際にOPSSアプリケーションがWebゲートに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。
詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドのOAM 11gサーバーを使用した11g Webゲートに対する中央管理ログアウトの構成に関する項を参照してください。
OAMエージェント（この場合は10g Webゲート）向けに構成されたlogout.htmlファイルをアプリケーションで呼び出すと、ログアウトが始まります。アプリケーションは、logout.htmlへの問合せ文字列としてend_urlも渡します。end_urlパラメータの値は、URIまたはURLのいずれかです。
タスクの概要: 10g Webゲート向けの中央管理ログアウトの構成。
デフォルトのログアウト・ページ（logout.html）を作成して、それをWebゲートのインストール・ディレクトリに置きます。例: WebGate_install_dir/oamsso/logout.html。
logout.htmlで、logOutUrlsパラメータが各リソースWebゲートに構成されていること、および<callBackUri>が「logOutUrls」の2番目の値であることを確認します。
手順1にあるlogout.htmlで、ユーザーをOAM 11gサーバー上のこの中央管理ログアウトのURI（/oam/server/logout）にリダイレクトする設定になっていることを確認します。
オプション: ログアウトしたユーザーのリダイレクト先を示すend_urlパラメータをアプリケーションで渡すことができます。
10g Webゲートを構成したOHS Webサーバー構成ファイルhttpd.confを確認し、次の行が存在する場合には削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドのOAM 11gサーバーを使用した10g Webゲートに対する中央管理ログアウトの構成に関する項を参照してください。
この項の内容は次のとおりです。
この項では、Oracle Access Managerのインストールおよび初期設定の概要と、Oracle Access Manager認証プロバイダのデプロイ時に使用するコンポーネントとファイルのインストール方法の追加情報を示します。
特に明記されていないかぎり、次の各項では、Oracle Access Manager IDアサーション・プロバイダとOracle Access Manager認証プロバイダの要件を両方とも説明します。
この項では、Oracle Access Managerを初めて使用するユーザーのために、インストールと設定の概要を簡潔に説明します。
アクセス・サーバー: Oracle Access Manager認証プロバイダでは、Webゲートまたはアクセス・ゲート用のアクセス・サーバーが2つ必要になります（1つのプライマリ・サーバーと1つのセカンダリ・サーバー）。現時点では、セカンダリ・アクセス・サーバーは1つしかサポートされません。アクセス・サーバーのインストールには、次の手順が含まれます。
アクセス・システム・コンソールで、プライマリ・サーバーのアクセス・サーバー構成プロファイルを追加します。「アクセス管理サービス」が「オン」（ポリシー・マネージャAPIのサポート・モードとも呼ばれる）になっていることを確認します。
「アクセス管理サービス」を「オン」にして、セカンダリ・アクセス・サーバー構成プロファイルを追加します。
プライマリ・アクセス・サーバーのインスタンスをインストールします。
セカンダリ・アクセス・サーバーのインスタンスをインストールします。
Webゲート/アクセス・ゲート: Webゲートまたはアクセス・ゲートのどちらが必要であるかは、使用するOracle Access Manager認証プロバイダによって決まります。次に例を示します。
シングル・サインオン用のIDアサーション・プロバイダ: 境界認証を定義するために、アプリケーションごとに個別のWebゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。
認証プロバイダまたはOracle Web Services Manager: アプリケーションごとに個別のアクセス・ゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。
OAM 10g Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメインについて
この項では、Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメイン、およびこれらの作成方法について説明します。
Webゲートとアクセス・ゲートには微妙な違いがありますが、多くの場合、これらの用語は同じ意味で使用されます。アクセス・システム・コンソールでは、Webゲートまたはアクセス・ゲートの構成プロファイルがアクセス・ゲート・プロファイルと呼ばれています。ポリシー・マネージャでは、Oracle Access Managerのポリシー・ドメインが作成されます。
アクセス・システム・コンソールを使用する方法: 特定のOracle Access Manager管理者権限を持つユーザーが、Oracle Access Managerで直接情報を入力して、パラメータを設定できます。この方法は、認証プロバイダを使用している場合、またはOracle Web Services ManagerポリシーでWebサービスを保護している場合に必要です。
OAMCfgToolを使用する方法: シングル・サインオン用のIDアサーション・プロバイダを実装するアプリケーション管理者は、OAMCfgToolを使用して新しいWeb層用の新しいWebゲート・プロファイルを作成できます。必須パラメータは、コマンドラインで指定する、環境に適した値を使用してプロビジョニングされます。必須ではないパラメータについては、デフォルト値が受け入れられます。アクセス管理サービスはオンに設定されます。プロファイルを作成したら、アクセス・システム・コンソールで値を変更できます。
各アクセス・ゲート・プロファイルには、次のパラメータが含まれている必要があります。アスタリスク（*）付きのパラメータは、OAMCfgToolを使用してプロビジョニングされます。
*アクセス・ゲート名: 空白を含まない一意の名前。OAMCfgToolツールでは、この名前はapp_domain値から導出され、末尾に_AGが付けられます。
*ホスト名: Webゲートまたはアクセス・ゲートがインストールされている（またはインストールされる）コンピュータの名前。OAMCfgToolでは、ホスト名としてapp_domain値が使用されます。
*アクセス・ゲートのパスワード: コンポーネントを検証および識別するための一意のパスワード。これにより、認可されていないアクセス・ゲートがアクセス・サーバーに接続してポリシー情報を取得する事態を防ぐことができます。OAMCfgToolでは、app_agent_passwordパラメータを使用して指定されます。このパスワードは、Webゲート/アクセス・ゲート・インスタンスごとに異なっている必要があります。
トランスポート・セキュリティ: アクセス・サーバーと関連するWebゲート間のトランスポート・セキュリティ・レベル（同じものにする）。デフォルト値はOpenです。OAMCfgToolのoam_aaa_mode値を使用して、別の値を指定できます。
*優先HTTPホスト: ユーザーが保護されたWebサーバーへのアクセスを試みたときに、すべてのHTTPリクエストに表示されるホスト名。ユーザーのHTTPリクエストでどのように定義されたかに関係なく、HTTPリクエストのホスト名は、このフィールドに入力した値に変換されます。OAMCfgToolの優先HTTPホストはapp_domain値です。
優先ホスト機能により、ホストの識別子がホスト識別子リストに含まれていない場合に、セキュリティ・ホールが誤って作成される事態を防ぐことができます。ただし、この機能は仮想Webホスティングには使用できません。仮想ホスティングでは、ホスト識別子機能を使用する必要があります。
*プライマリHTTP Cookieドメイン: WebゲートがデプロイされているWebサーバー・ドメイン。Cookieドメインは、Webサーバー間のシングル・サインオンを有効にするために必要です。各Webサーバーの「プライマリHTTP Cookieドメイン」の値は一致している必要があります。この値を設定するには、OAMCfgToolのcookie_domainパラメータを使用します。
|
関連項目:
|
アクセス・ゲート・プロファイルとポリシー・ドメインの管理要件について
この項では、Oracle Access Managerの新しいWebゲート/アクセス・ゲート・プロファイル、ポリシー・ドメインの作成方法、およびその際に必要な管理権限について説明します。
Oracle Access Managerのマスター・アクセス管理者は、ポリシー・ドメイン・ルートを定義した後、最初のポリシー・ドメインを作成する必要があります。その後、最初のポリシー・ドメインの下にURLのポリシー・ドメインを作成し、それらのポリシー・ドメインの管理を他の管理者に委任できます。
アクセス・システム・コンソールを使用する方法: アクセス・システム・コンソールを使用して新しいアクセス・ゲート・プロファイルを作成し、それをアクセス・サーバーに関連付けて、認証スキームを作成するには、マスター・アクセス管理者または委任アクセス管理者である必要があります。マスター・アクセス管理者または委任アクセス管理者は、ポリシー・マネージャを使用してポリシー・ドメインを作成することもできます。この方法は、次のデプロイメントで必要です。
認証プロバイダ
Oracle Web Services ManagerによってWebサービスが保護されている場合にはIDアサーション・プロバイダ
OAMCfgToolを使用する方法: OAMCfgToolを使用するために、特定のOracle Access Manager管理者権限は必要ありません。OAMCfgToolにより、Webゲート・プロファイルの作成と関連付け、および新しいポリシー・ドメインの作成が自動化されます。ただし、この方法はIDアサーションでのみ使用できます。次のことが可能です。
新規Web層: OAMCfgToolを使用して、IDアサーション・プロバイダ専用の新しいWebゲート・プロファイルとポリシー・ドメインの作成を合理化できます。
OAMCfgToolを使用してプロファイルとポリシー・ドメインを作成した後、アクセス・システム・コンソールでこれらを変更できます。
既存Web層: Web層に1つ以上のWebゲートが存在する場合、新しいWebゲートは必要ありません。ただし、既存のホスト識別子を指定して、既存のWebゲートが新たに確立されたポリシーを実施できるようにすることができます。
|
関連項目:
|
次のタスク概要は、インストールする必要のあるコンポーネントとファイル、および詳細情報の参照先を示しています。
|
注意: コンポーネントがすでにインストールおよび設定されている場合は、新たにコンポーネントをインストールする必要はありません。ご使用のデプロイメントに該当しない手順は省略してください。 |
特に明記されていないかぎり、シングル・サインオン用のIDアサーション・プロバイダまたは認証プロバイダのどちらがデプロイされているか、またはOracle Web Services ManagerポリシーによってWebサービスが保護されているかどうかに関係なく、すべての詳細が適用されます。
タスクの概要: Oracle Access Manager認証プロバイダの必須コンポーネントおよびファイルのインストール
Oracle Access Managerアクセス・サーバーで使用するようにOracle Internet DirectoryまたはOracle Sun One LDAPディレクトリ・サーバーを構成します。ディレクトリ・サーバーがデプロイメント用に調整されていることを確認してください。
|
関連項目: 次のリリース11g（11.1.1.1.0）のマニュアル
|
Oracle WebLogic Server 10.3.1以降をインストールおよび設定します。
|
関連項目: このリストの手順3および『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』 |
オプション: Fusion Middleware製品（Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど）をインストールします。
|
注意: Fusion Middlewareアプリケーションがインストールされていない場合は、以降の手順に従って、必要なJARファイルおよびWARファイルを入手する必要があります。 |
次のFusion Middlewareパスで、必要なJARファイルの場所を確認します。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
次のパスで、コンソール拡張WARファイルを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov ider.war
WARファイルを、WebLogic Serverホームの次のパスにコピーします。
WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
必要に応じて、Oracle Access Manager 10g（10.1.4.3）のWebゲート用にOHS 11gをインストールします。
認証プロバイダまたはOracle Web Services Manager: カスタム・アクセス・ゲートでは、Webサーバーは必要ありません。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。
Oracle Access Manager IDアサーション・プロバイダ: Oracle HTTP Server 11gのWebサーバーが、Oracle WebLogic Serverのフロントエンドにリバース・プロキシとして構成されている必要があります。
Oracle Access Manager 10g（10.1.4.3）のコンポーネントをインストールし、次の手順に従って初期設定を行います。
アイデンティティ・サーバー、Webパスをインストールして、アイデンティティ・システムを設定します。
ポリシー・マネージャをインストールおよび設定します。ポリシー・マネージャを保護するポリシー（/access）とデフォルト認証スキームが作成および有効化されていることを確認してください。
アクセス・サーバー（Webゲートのプライマリ・サーバーとセカンダリ・サーバーとして1つずつ）をインストールします。
アクセス・システム・コンソールで、Webゲートのプライマリ・サーバーのアクセス・サーバー構成プロファイルを追加します。「アクセス管理サービス」が「オン」（ポリシー・マネージャAPIのサポート・モードとも呼ばれる）になっていることを確認します。
「アクセス管理サービス」を「オン」にして、セカンダリ・アクセス・サーバー構成プロファイルを追加します。
プライマリ・アクセス・サーバーのインスタンスをインストールしてから、セカンダリ・アクセス・サーバーのインスタンスをインストールします。
|
注意: 1つのセカンダリ・アクセス・サーバーのみがサポートされています。 |
シングル・サインオン用のIDアサーション・プロバイダのWebゲート: 1つ以上のWebゲートが存在する既存Web層では、新しいWebゲートまたはプロファイルは必要ありません。
新規Web層では、次の手順に従って、境界認証のWebゲートを定義するためのプロファイルを作成する必要があります。
アクセス・ゲート: 認証プロバイダまたはOracle Web Services Managerを使用する場合は、アクセス・システム・コンソールでカスタム・アクセス・ゲート用の新しいプロファイルを追加する必要があります。
アクセス・システム・コンソールでアクセス・ゲート構成プロファイルを追加し、「アクセス管理サービス」が「オン」になっていることを確認します。
アクセス・ゲート・プロファイルをプライマリおよびセカンダリ・アクセス・サーバーに関連付けます。
oamAuthnProvider.jarに含まれているカスタム・アクセス・ゲートをデプロイします。
それぞれのアプリケーションを保護するプロファイルとアクセス・ゲートがインストールされるまで、手順を繰り返します。
次の手順を実行します。
リソース・タイプの作成: Oracle Access Manager認証プロバイダを使用する場合、またはOracle Web Services ManagerポリシーによってWebサービスが保護されている場合は、「Oracle Access Managerでのリソース・タイプの作成」を実行します。
シングル・サインオン用のIDアサーション・プロバイダ: 「Oracle Access Manager 10gでのSSO用のIDアサーションの構成」で説明されているタスクを実行します。
認証プロバイダ: 「Oracle Access Manager 10g用の認証プロバイダの構成」で説明されているタスクを実行します。
Oracle Web Services Manager: 「Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成」で説明されているタスクを実行します。
この項では、ポリシー・ドメインによって保護されるリソース・タイプを識別するために、Oracle Access Managerでリソース・タイプを作成する方法について説明します。この項で説明されているように、リソース・タイプを定義するには、Oracle Access Managerアクセス・システム・コンソールを使用します。
|
注意: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを使用している場合、このタスクは省略できます。その場合、デフォルトのhttpリソース・タイプのみが使用されます。 |
Oracle Access Managerでwl_authenリソース・タイプを定義する必要があるのは、次のコンポーネントを使用している場合のみです。
Oracle Access Manager認証プロバイダ
Oracle Web Services Manager用のIDアサーション・プロバイダ
Oracle Access Manager 10gでリソース・タイプを定義するには
アクセス・システム・コンソールに移動して、ログインします。
「アクセス・システム・パッケージ」タブを選択して、「共通情報の構成」、「リソース・タイプ定義」をクリックし、「すべてのリソース・タイプをリスト」ページを表示します。
「すべてのリソース・タイプをリスト」ページで、「追加」をクリックし、「新規リソース・タイプの定義」ページを表示します。
次の詳細を指定して、リソース・タイプを定義します。
名前: wl_authen
表示名: wl_authen
リソースの一致: 大/小文字を区別しない
リソース操作: LOGIN
定義したリソース・タイプを保存します。
次の手順を実行します。
認証プロバイダ: 「Oracle Access Manager 10g用の認証プロバイダの構成」
Oracle Web Services Manager: 「Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成」
この項では、シングル・サインオン用のOracle Access Manager IDアサーションの構成に固有の手順について説明します。
前提条件
認証プロバイダまたはOracle Web Services Managerに関して特に明記されていないかぎり、次のタスクを含め、「OAM 10g用の認証プロバイダのインストールおよび設定」で説明されているすべてのタスクを実行する必要があります。
認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール
|
注意: 実装に応じて、次の処理を実行します。
|
アプリケーションでシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを構成するには、次のタスクの概要で説明されている手順を実行します。
タスクの概要: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダのデプロイおよび構成
次の項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。
|
注意: このタスクはOAM 11gとOAM 10gの両方で同じです。 |
この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager IDアサーション・プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をCLIENT-CERTに指定する必要があります。
auth-methodには、BASIC、FORMまたはCLIENT-CERTの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
|
注意: WebLogicを介して直接アプリケーションにアクセスして、WebLogic認証スキームを呼び出すようにする場合には、CLIENT-CERT、FORMを指定できます。 |
IDアサーション・プロバイダおよびOAM 10gに対してweb.xmlで認証を指定するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
your_app/WEB-INF/web.xml
login-configでauth-methodを検索し、CLIENT-CERTと入力します。
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
「Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認」に進みます。
Oracle HTTP Serverには、mod_weblogicプラグイン・モジュール（11gではmod_wl_ohs.so）が含まれており、すでに有効になっています。次の手順を実行してこれを確認するか、またはこの手順を省略できます。
Oracle HTTP Server 11gでは、mod_weblogic構成はデフォルトでmod_wl_ohs.confに存在し、このファイルのパスはhttpd.confに含まれています。mod_weblogic構成が存在しない場合は、httpd.confを編集する必要があります。
IDアサーション・プロバイダおよびOAM 10gに対してmod_weblogicを構成するには
httpd.confを見つけます。たとえば、次の場所にあります。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
ファイル内に次の文があり、デプロイメントに適した値が指定されていることを確認します（必要に応じてコメントを追加または削除する）。
<IfModule mod_weblogic.c> WebLogicHost yourHost.yourDomain.com WebLogicPort yourWlsPortNumber </IfModule> <Location http://request-uri-pattern> SetHandler weblogic-handler </Location>
ファイルを保存します。
Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。
|
注意: この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。 |
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。このフィルタを使用すると、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。ネットワーク接続フィルタは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。
接続フィルタを構成してmod_weblogicとOHS 11gが実行されているホストからのリクエストのみを許可するには、ここで説明する手順を実行します。
|
注意: この章では、Apache用WebLogic Serverプラグインの汎用名（mod_weblogic）を使用します。Oracle HTTP Server 11gでは、このプラグインの名前はmod_wl_ohsですが、実際のバイナリ名はmod_wl_ohs.soになります。後述する例は、実装可能な正確な構文を示しています。 |
WebLogic Serverでは、デフォルト接続フィルタweblogic.security.net.ConnectionFilterImplが提供されます。このフィルタは、すべての着信接続を受け入れ、サーバーによる現在の接続フィルタの取得を許可する静的ファクトリ・メソッドも提供します。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力します。
また、weblogic.security.netパッケージにクラスを実装することにより、カスタム接続フィルタを使用することもできます。デフォルト接続フィルタと同様、カスタム接続フィルタはWebLogic Server管理コンソールで構成します。
接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。
targetAddress localAddress localPort action protocols
表9-16は、接続フィルタの各パラメータを説明しています。
表9-6 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
target |
フィルタ対象の1つ以上のシステムを指定します。 |
|
localAddress |
WebLogic Serverインスタンスのホスト・アドレスを定義します（アスタリスク（*）を指定すると、すべてのローカルIPアドレスが返される）。 |
|
localPort |
WebLogic Serverインスタンスのリスニング・ポートを定義します（アスタリスク（*）を指定すると、サーバー上のすべての使用可能なポートが返される）。 |
|
action |
実行するアクションを指定します。この値は、allowまたはdenyである必要があります。 |
|
protocols |
フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。 |
「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項 |
11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」の下の「ドメイン」をクリックします。
「セキュリティ」タブ→「フィルタ」タブをクリックします。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
この項では、OAM 10g用のOAMCfgToolの使用を中心に説明します。OAM 11gを使用している場合には、この項を省略して「Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」の説明にあるタスクを実行してください。
アプリケーションを設定したら、Oracle Access Managerを使用して保護する必要があります。このタスクの自動化を支援する、OAMCfgToolというコマンドライン・ツールが用意されています。このツールは、Fusion MiddlewareアプリケーションのOAM 10g用oamcfgtool.jarファイル内にあります。
この手順は、アクセス・システム・コンソールとポリシー・マネージャで手動で実行できますが、オプションのOAMCfgToolを使用して、フォームベース認証スキーム、アプリケーションのポリシー・ドメイン、およびシングル・サインオン用IDアサーションで必要とされるOracle Access Managerアクセス・ポリシーを設定および検証することができます。また、新規Web層に新しいWebゲート・プロファイルを作成したり、既存Web層のWebゲート・プロファイルを変更することもできます。
詳細は、次の各項を参照してください。
この項では、OAMCfgToolについて説明します。このツールは、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダをデプロイしている場合にのみ使用できます。
OAMCfgToolは、一連のスクリプトを起動して情報をリクエストし、必要なプロファイルとポリシーをOracle Access Managerに設定します。OAMCfgToolは、次のモードで実行されます。
CREATEモード
java -jar oamcfgtool.jar mode=CREATE param=value
VALIDATEモード
java -jar oamcfgtool.jar mode=VALIDATE param=value
LDIF出力ファイルを指定しないかぎり、構成変更は、Oracle Access Managerで構成されているLDAPディレクトリ・サーバーに直接書き込まれます。構成変更をLDIFファイルに書き込む場合、そのファイルをOracle Access Manager用のディレクトリ・サーバーに後でロードできます。LDIFファイルを使用しない場合、Oracle Access Managerのキャッシュ・フラッシュがトリガーされ、即時に変更が反映されます。
ログ・レベルとログ詳細の出力ファイルも指定できます。OAMCfgToolの実行中にエラーが発生した場合は、コマンドラインでエラーが報告されます。
表9-7は、OAMCfgToolの必須パラメータとオプション・パラメータ、およびCREATEモードでの各値を示しています。パラメータは、一度に複数個指定できます。「既知の問題: JARファイルとOAMCfgTool」も参照してください。
|
注意:
|
表9-7 OAMCfgToolのCREATEモードでのパラメータと値
| パラメータ | CREATEモードの値 |
|---|---|
|
必須パラメータ |
値 |
|
app_domain |
アプリケーションを保護するOracle Access Managerポリシー・ドメインの名前。ポリシー・マネージャ内では、ポリシー・ドメイン名と呼ばれています。 |
|
protected_uris |
保護されるアプリケーションのURIのカンマ区切りリスト（空白あり/なし）（例: /myapp/login）。 |
|
app_agent_password |
Webゲートに対してプロビジョニングされるパスワード。アクセス・システム・コンソール内のアクセス・ゲート・プロファイルでは、このパラメータがアクセス・ゲート・パスワードと呼ばれています。入力したパスワードは、コマンドラインにクリアテキストで表示されますが、ログ・ファイルには記録されません。 |
|
ldap_host |
Oracle Access ManagerのLDAPディレクトリ・サーバーをホスティングしているコンピュータのDNS名。 注意: ディレクトリ・サーバーとのSSL対応通信はサポートされていません。 |
|
ldap_port |
LDAPディレクトリ・サーバーのポート。 |
|
ldap_userdn |
引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。 |
|
ldap_userpassword |
LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。 |
|
oam_aaa_host |
アクセス可能なアクセス・サーバーをホスティングしているコンピュータのDNS名。 OAMCfgToolでは、プライマリおよびセカンダリ・アクセス・サーバーの指定は認識されません。アクセス可能な単一アクセス・サーバーを使用して、Webゲート・プロファイルを設定してください。Oracle Access Managerでプロファイルを、指定したアクセス・サーバーに後で関連付けることができます。 |
|
oam_aaa_port |
アクセス可能なアクセス・サーバーのリスニング・ポート。 |
|
オプション |
値 |
|
-help |
パラメータと説明のリストを提供します。 |
|
web_domain |
新規Web層: web_domainを省略して、新しいWebゲート・プロファイルを作成します。次に示すように、すべて同じapp_domain値を使用して、プロファイルにWebゲート名、ホスト名、および優先HTTPホストが移入されます。
既存Web層: web_domainを含めてOracle Access Managerの既存のホスト識別子の名前を指定し、新しいポリシーを既存のホストIDに関連付けます。次に例を示します。 web_domain=existing_host_Identifier Webゲートによってリクエストがインターセプトされると、リクエストのアドレスがチェックされます。アドレスがホスト識別子リストに含まれている場合は、そのアドレスが正式なホスト名にマップされ、アクセス・システムによってリソースを保護するためのルールとポリシーが適用されます。仮想Webホスティングがサポートされている場合は、「優先HTTPホスト」フィールドに、ホスト名バリエーションではなく予約名を入力します。詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。 |
|
cookie_domain |
ObSSOCookieに使用するドメインの名前。アクセス・システム・コンソールのアクセス・ゲート・プロファイル内では、プライマリHTTP Cookieドメインと呼ばれています。 このパラメータは、新規Web層に新しいWebゲート・プロファイルを作成するときに使用します。 |
|
public_uris |
匿名認証スキームを使用する非保護のURI。 パブリックURIは、カンマ区切りリストを指定することによって識別できます（"uri1,uri2,uri3"など）。URIの一部であるデフォルトURLパターンが作成されます（/.../public/.../）。たとえば、"uri1,uri2,uri3"と指定した場合、デフォルトURLパターンとして"/.../public/.../"を含む3つのパブリックURLが作成されます。ユーザーは、必要に応じてポリシー・マネージャにログインしてURLパターンを変更できます。 |
|
ldap_base |
すべてのLDAP検索が実行されるベース。 注意: Oracle Access Managerのユーザー・データと構成データが別個のディレクトリ・サーバーに格納されている場合、それぞれのディレクトリ・サーバーでは次の情報が必要になります。
|
|
oam_aaa_mode |
アクセス可能なAccess Serverのトランスポート・セキュリティ・モード。OPEN、SIMPLEまたはCERTを指定します。デフォルト値はOPENです。 |
|
oam_aaa_passphrase |
SIMPLEトランスポート・セキュリティ・モード専用のパスフレーズ。パスフレーズはクリアテキストで表示されますが、ログ・ファイルには記録されません。 |
|
log_file |
OAMCfgToolログ・ファイルの名前。デフォルトでは、画面出力されます。 |
|
log_level |
OAMCfgToolロギング・レベル: ALL、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTおよびOFF（デフォルト）。 |
|
output_ldif_file |
OAMCfgTool操作の詳細が格納されるLDIFファイルの名前。このファイルは、後でLDAPディレクトリ・サーバーにロードされます。何も指定しない場合、変更は即時にLDAPディレクトリ・サーバーに書き込まれ、Oracle Access Managerのキャッシュがフラッシュされて新しい情報が使用可能になります。 |
マスター・アクセス管理者または委任アクセス管理者は、Oracle Access Managerを直接チェックして、ポリシー・ドメインとWebゲート・プロファイルの設定を検証できます。
|
注意: アクセス・ゲート・プロファイル作成の検証には、OAMCfgToolモードを使用できません。 |
OAMCfgToolをVALIDATEモードで使用することにより、シングル・サインオン構成のポリシー・ドメインが正しいことを確認できます。この場合、一連のリクエストは保護されたリソースに自動的に送信されます。
表9-8は、OAMCfgToolの必須パラメータとオプション・パラメータ、およびVALIDATEモードでの各値を示しています。
表9-8 OAMCfgToolのVALIDATEモードでのパラメータと値
| VALIDATEモードのパラメータ | 必須パラメータのVALIDATEモード値 |
|---|---|
|
必須パラメータ |
値 |
|
app_domain |
アプリケーションを保護するために作成されたOracle Access Managerポリシー・ドメインの名前。 |
|
ldap_host |
Oracle Access ManagerのLDAPディレクトリ・サーバーをホスティングしているコンピュータのDNS名。 |
|
ldap_port |
LDAPディレクトリ・サーバーのポート。 |
|
ldap_userdn |
引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。 |
|
ldap_userpassword |
LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。 |
|
oam_aaa_host |
アクセス・サーバーをホスティングしているコンピュータのDNS名。 |
|
oam_aaa_port |
アクセス・サーバー・ホストのリスニング・ポート。 |
|
test_username |
ポリシー検証に使用するユーザー名。 |
|
test_userpassword |
ポリシー検証に使用するユーザー・パスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。 |
|
オプション・パラメータ |
値 |
|
web_domain |
ホスト識別子。 |
|
ldap_base |
すべてのLDAP検索が実行されるベース。Oracle Access Managerでは、検索ベースまたは構成ベースと呼ばれています。たとえば、dc=company、c=usのように指定します。 注意: Oracle Access Managerのユーザー・データと構成データが別個のディレクトリ・サーバーに格納されている場合、それぞれのディレクトリ・サーバーでは次の情報が必要になります。
|
|
oam_aaa_mode |
アクセス可能なAccess Serverのトランスポート・セキュリティ・モード。OPEN、SIMPLEまたはCERTを指定します。デフォルト値はOPENです。 |
|
oam_aaa_passphrase |
SIMPLEトランスポート・セキュリティ・モード専用のパスフレーズ。入力はクリアテキストで表示されます。しかし、ログ・ファイルには記録されません。 |
|
log_file |
OAMCfgToolログ・ファイルの名前。デフォルトでは、画面出力されます。 |
|
log_level |
OAMCfgToolロギング・レベル: ALL、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTおよびOFF（デフォルト）。 |
この項では、環境に適した各種パラメータと値を指定してOAMCfgToolを使用する場合の処理について説明します。
この項では、OAM 10g用のOAMCfgToolの使用を中心に説明します。OAM 11gを使用している場合、この項を省略して、Oracle Fusion Middleware Oracle Access Manager管理者ガイドのリモート登録に関する章を参照してください。
プロセスの概要: OAMCfgToolによる認証スキーム、ポリシー・ドメインおよびWebゲート・プロファイルの作成
app_domainパラメータは、ポリシー・マネージャのポリシー・ドメインを作成することでアプリケーション認証を可能にします。
web_domainパラメータは、リクエストの送信元であるWebゲート・ホストを送信先のアプリケーションに接続したり、ポリシーを既存Webゲートにリンクするためのホスト識別子を作成します。このホスト識別子を使用するアクセス・ポリシーが存在しない場合、新しいポリシーが設定されます。
|
注意: 新規Web層において、CREATEモードで新しいWebゲート・プロファイルを作成する場合、web_domainパラメータを省略する必要があります。この場合は、表9-7の説明に従ってください。
|
protected_urisパラメータは、ホスト識別子（または手順2で作成した新しいWebゲート/アクセス・ゲート・プロファイル）を使用して、HTTPリソースを保護するためのアプリケーション固有のURLを定義します。
public_urisパラメータは、app_domain nameにあるhttpリソースの特定のURIを（GETおよびPOST操作で）非保護にするためのPublic_URI_Policyを作成します。
LDAPパラメータは、Oracle Access Managerが使用するディレクトリ・サーバーを指定します。ここで指定した検索ベースで、すべてのLDAP問合せが実行されます。詳細は、表9-7を参照してください。
log fileおよびlog levelパラメータは、OAMCfgToolの出力ファイルとログ・レベルを指定します。
output_ldif_fileパラメータは、LDIFファイルの名前を定義します。ここで作成したLDIFファイルは、ユーザーの指定に応じて後でディレクトリ・サーバーにロードできます。このファイルを使用しない場合、構成変更はディレクトリ・サーバーに書き込まれます。
この項では、Oracle Access Managerで表示した場合のOAMCfgToolの実行結果について説明します。
|
注意: この項では、OAM 10g用のOAMCfgToolの使用を中心に説明します。OAM 11gを使用している場合、Oracle Fusion Middleware Oracle Access Manager管理者ガイドのリモート登録に関する章を参照してください。 |
ポリシー・ドメイン
「ポリシー・ドメイン」の「一般」タブ
図9-9は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「一般」タブを示しています。説明は、自動的に表示されます。
|
注意: 説明について、Java APIは稼働プラットフォームの現在のユーザーとコンピュータ・ホスト名user@hostnameを取得します。 |
「ポリシー・ドメイン」の「リソース」タブ
図9-10は、OAMCfgToolで作成しサンプル・ポリシー・ドメインの「リソース」タブを示しています。デフォルトは、httpリソース・タイプです。ホスト識別子とURL接頭辞は、入力したOAMCfgToolパラメータとその値から導出されます。説明は、自動的に表示されます。
「ポリシー・ドメイン」の「認可ルール」タブ
図9-11は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「認可ルール」タブを示しています。図の後にサブ・タブの詳細を示します。OAMCfgToolを使用すると、ポリシー・ドメインに対して認可ルールが自動的に構成されます。
「ポリシー・ドメイン」の「デフォルト・ルール」タブ
図9-12は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「デフォルト・ルール」タブを示しています。すべての値は、ポリシー・ドメインに対して自動的に構成されます。図の後にサブ・タブの詳細を示します。
「ポリシー・ドメイン」の「ポリシー」タブ
図9-13は、OAMCfgToolで指定したパラメータと値を使用して作成した、サンプル・ポリシー・ドメインの「ポリシー」タブにある「一般」サブ・タブを示しています。ホスト識別子は、app_domain値に基づきます。図の後に他のサブ・タブの詳細を示します。
「ポリシー・ドメイン」の「委任アクセス管理」タブ
図9-14は、OAMCfgToolを使用して作成されたサンプル・ポリシー・ドメインの「委任アクセス管理」タブを示しています。マスターWebリソース管理の委任権限を設定するパラメータは、このツールでは指定されません。
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイドのポリシー・ドメインでのリソース保護に関する項 |
ホスト識別子
OAMCfgToolで作成したホスト識別子は、アクセス・システム・コンソールの「アクセス・システム構成」タブで確認できます。
図9-15は、OAMCfgToolを使用して作成されたサンプル・ホスト識別子を示しています。ここで説明されているように、必須パラメータはOAMCfgToolのapp_domainパラメータに入力した値から導出されます。説明は、OAMCfgToolが表示します。
アクセス・ゲート・プロファイル
図9-16は、web_domainパラメータを省略した場合にOAMCfgToolによって作成されるサンプル・アクセス・ゲート・プロファイルを示しています。このプロファイルは、アクセス・システム・コンソールにあります。ここで説明されているように、必須のプロファイル・パラメータはOAMCfgToolを使用して入力された値から導出されます。他のプロファイル・パラメータでは、デフォルト値が使用されます。説明は、OAMCfgToolが表示します。
この項では、OAMCfgToolの実行時にモデルとして使用できる手順について説明します。
この例では、新しいWebゲート・プロファイルを必要とする新規Web層を想定しています。このため、web_domain=パラメータは省略されます。新しいプロファイルが作成され、app_domain値から名前が付けられます（_AGが付加される）。
次の手順は、このツールの使用方法の一例にすぎません。その値は、使用する環境によって異なります。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、OAMCfgToolはすでにインストールされています。この場合、手順1を省略します。 |
OAMCfgToolを使用してフォーム認証スキーム、ポリシー・ドメインおよびアクセス・ポリシーを作成するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Fusion Middlewareアプリケーションがない場合には、OAMCfgTool を入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Managerのコア・コンポーネント（10.1.4.3.0）を使用してOAMCfgTool ZIPファイルを見つけます。
oamcfgtool<version>.zip
oamcfgtool.jarを抽出し、Webゲートをホスティングしているコンピュータにコピーします。
JDK 1.6（または最新バージョン）がインストール済および構成済であることを確認します。
保護するアプリケーションをホスティングしているコンピュータにログインし、OAMCfgToolが含まれているファイル・システム・ディレクトリに移動します。
|
注意:
|
Webゲート・プロファイル、認証スキームおよびポリシー・ドメインを作成します。表9-7の説明に従い、環境に適した値を使用して次のコマンドを実行します。次に例を示します。
java -jar oamcfgtool.jar mode=CREATE app_domain=IASSO_App1 protected_uris=/myapp/login app_agent_password=<WebGate_password> cookie_domain=<preferred_http_cookie_domain> ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin ldap_userpassword=<ldap_userpassword> oam_aaa_host=abcd oam_aaa_port=7789 oam_aaa_mode=cert log_file=OAMCfg_date.log log_level=INFO output_ldif_file=<LDIF_filename>
このツールで指定した情報を確認します。たとえば、手順3のパラメータと値は次のとおりです。
Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain : IASSO_App1
Host Identifier: IASSO_App1
Access Gate ID : IASSO_App1_AG
出力LDIFの作成: LDIFをインポートし、その情報をディレクトリ・サーバーに書き込みます。該当しない場合は、この手順を省略します。
検証: OAMCfgToolを実行して、作成されたポリシー・ドメインを検証します（表9-8を参照）。次に例を示します。
java -jar oamcfgtool.jar mode=VALIDATE app_domain=IASSO_App1 protected_uris=/myapp/login ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin ldap_userpassword=<ldap_userpassword> oam_aaa_host=abcd oam_aaa_port=7789 log_file=OAMCfg_date.log log_level=INFO test_username=gcf test_userpassword=<test_userpassword>
Webゲートがインストールされていない新規Webゲート・プロファイル: Webゲートをインストールするときに、プロファイルの作成時に指定した値と同じ値（および、インストールの完了に必要なその他の値）を指定します。
Webゲートがインストールされている新規Webゲート・プロファイル: OAMCfgToolのCreateコマンド出力を使用してOracle Access ManagerのconfigureWebGateツールを実行し、インストールされているWebゲートを設定します。次に例を示します。
次の場所に移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate
ここで、WebGate_install_dirは、Webゲートのインストール先ディレクトリです。
次のコマンドを実行し、OAMCfgToolで指定した値とプロファイルの完了に必要なその他の値を使用して、Webゲートを構成します。次に例を示します。
configureWebGate -i WebGate_install_dir -t WebGate WebGate_Name -P WebGate_password -m <open|simple|cert> -h Access_Server_Host_Name -p Access_Server_Port -a Access_Server_ID -r Access_Server_Pass_Phrase (must be the same as the WebGate_password) -Z Access_Server_Retry count
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイドのアクセス・ゲートおよびWebゲートの構成に関する項 |
アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。
マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。次に例を示します。
http://hostname:port/access/oblix
hostnameはWebパスのWebサーバーをホストするコンピュータで、portはWebパスのWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
「アクセス・システム構成」→「アクセス・ゲート構成」をクリックします。
「すべて」ボタンをクリックしてすべてのプロファイルを検索し（または、リストから検索属性と条件を選択し）、「実行」をクリックします。
Webゲートの名前をクリックして、その詳細を表示します。
「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの説明に従って値を変更します。
保護するアプリケーションごとに、手順3〜8を繰り返します。
「WebLogicドメインでのプロバイダの構成」に進みます。
この項の内容は次のとおりです。
この項では、WebLogicセキュリティ・レルムの認証プロバイダを初めて使用するユーザーのために、いくつかのタイプの認証プロバイダのみを説明します。
WebLogicセキュリティ・レルムごとに、少なくとも1つの認証プロバイダを構成する必要があります。WebLogicセキュリティ・フレームワークは、マルチパート認証用に複数の認証プロバイダ（および複数のLoginModule）をサポートするように設計されています。このため、1つのセキュリティ・レルムで複数の認証プロバイダと複数のタイプの認証プロバイダを使用できます。制御フラグ属性により、認証プロセスにおいて各認証プロバイダのLoginModuleがどのように使用されるかが決定されます。
Oracle WebLogic Serverは、次のものを含め、複数のタイプの認証プロバイダとIDアサーション・プロバイダを提供します。
デフォルトのWebLogic認証プロバイダ（デフォルトの認証プロバイダ）では、ユーザーとグループを1箇所で、つまり、WebLogic Serverの組込みLDAPサーバーで管理できます。この認証プロバイダは、Oracle WebLogic Serverでの管理ユーザー・ログインに使用されます。
IDアサーション・プロバイダは、トークンベース認証を使用します。Oracle Access Manager IDアサーション・プロバイダはその一例です。
LDAP認証プロバイダは、ユーザーおよびグループ情報を外部LDAPサーバーに格納します。このプロバイダは主に、一般的なディレクトリ・スキーマが反映されるように、対応するLDAPサーバーがデフォルトで構成されている点が異なります。
Oracle WebLogic Server 10.3.1以降は、OracleInternetDirectoryAuthenticatorを提供します。
複数の認証プロバイダを構成する場合、各プロバイダに対してJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの使用方法を制御します。たとえば、次のJAAS制御フラグ設定を選択できます。
REQUIRED: 認証プロバイダが常に呼び出され、ユーザーはその認証テストを常にパスする必要があります。認証の成否に関係なく、プロバイダ・リストの最後まで認証が続行されます。
SUFFICIENT: ユーザーは、認証プロバイダの認証テストをパスする必要はありません。認証に成功した場合、後続の認証プロバイダは実行されません。認証に失敗した場合、プロバイダ・リストの最後まで認証が続行されます。
OPTIONAL: ユーザーは、認証プロバイダの認証テストをパスしても失敗してもかまいません。ただし、セキュリティ・レルムに構成されているすべての認証プロバイダでJAAS制御フラグがOPTIONALに設定されている場合は、ユーザーは構成されているプロバイダのいずれかの認証テストをパスする必要があります。
既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。場合によっては、認証シーケンスで各認証プロバイダが適切に機能するように、制御フラグの設定とプロバイダの順序を変更する必要があります。
|
関連項目: すべての認証プロバイダのリストと、ユーザーおよびグループ属性をLDAPスキーマと一致させるためのOracle Internet Directoryプロバイダの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項を参照してください。 |
この項では、WLSTを初めて使用するユーザーのために、WLSTについて説明します。
Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool（WLST）コマンドライン・ツールを使用して、WebLogicドメインにプロバイダを追加できます。
WLSTはJythonベースのコマンドライン・スクリプト環境で、WebLogic Serverドメインの管理と監視のために使用できます。通常、このツールはオンラインまたはオフラインで使用できます。このツールは、ファイルで提供されるバッチ（ユーザーの入力を介在せずに、スクリプトが一連のWLSTコマンドを呼び出すスクリプト・モード）において、コマンドラインで対話的に実行することができます。また、Javaコードに組み込むことも可能です。
WebLogicドメインに認証プロバイダを追加する場合、WLSTをオンラインで使用して認証プロバイダと対話し、ユーザー、グループおよびロールを追加、削除または変更できます。
WLSTをオフラインで使用してドメイン・テンプレートを作成する場合、WLSTによって認証プロバイダのデータ・ストアとその他のドメイン文書がパッケージ化されます。ドメイン・テンプレートからドメインを作成すると、新しいドメインは、ドメイン・テンプレートの認証プロバイダのデータ・ストアとまったく同じコピーになります。ただし、WLSTをオフラインで使用して認証プロバイダのデータ・ストア内のデータを変更することはできません。
|
注意: WLSTをオフラインで使用して、認証プロバイダのデータ・ストア内のデータを変更することはできません。 |
|
関連項目:
|
Oracle Application Development Framework（Oracle ADF）セキュリティを使用し、Oracle Access Manager Single Sign On（SSO）と統合し、ユーザー認証にOracle Platform Security Services（OPSS）SSOを使用するWebアプリケーションをOracle WebLogic Server上で実行できます。ただし、Webアプリケーションを実行する前に、アプリケーションのターゲットのOracle WebLogic Server上で、Oracle Access Managerセキュリティ・プロバイダ用にドメインレベルのjps-config.xmlファイルを構成する必要があります。
ドメインレベルのjps-config.xmlファイルは次のパスに存在します。デプロイ済のアプリケーションのjps-config.xmlファイルと混同しないでください。
domain_home/config/fmwconfig/jps-config.xml
Webアプリケーションのデプロイ前またはデプロイ後に、Oracle Access Manager固有のWLSTスクリプトを使用して、ドメインレベルのjps-config.xmlファイルを構成できます。このOracle JRF WLSTスクリプトの名前は次のとおりです。
Linux: wlst.sh
Windows: wlst.cmd
JDevを使用して実行している場合、Oracle JRF WLSTスクリプトは次のパスにあります。
$JDEV_HOME/oracle_common/common/bin/
JRF WebLogicをスタンドアロンでインストールしている場合のパスは次のとおりです。
$Middleware_home/oracle_common/wlst
|
注意: Oracle JRF WLSTスクリプトが必要です。Oracle Java Required Files（JRF）用のWLSTを実行している場合は、$JDEV_HOME/wlserver_10.3/common/binにあるWLSTスクリプトを使用しないでください。 |
コマンド構文
addOAMSSOProvider(loginuri, logouturi, autologinuri)
表9-9では、addOAMSSOProviderコマンドラインにおける各引数の予想される値を定義しています。
表9-9 addOAMSSOProviderコマンドライン引数
| 引数 | 定義 |
|---|---|
|
loginuri |
ログイン・ページのURIを指定します。 |
|
logouturi |
ログアウト・ページのURIを指定します。 |
|
autologinuri |
自動ログイン・ページのURIを指定します。 |
|
関連項目:
|
前提条件
このタスクを開始する前に、次の項の説明にあるとおりにこれまでのすべてのタスクが実行済であることを確認します。
Oracle ADFセキュリティが有効なFusion Webアプリケーション用のドメインレベルのjps-config.xmlを変更するには:
Oracle WebLogic ServerおよびOracle ADFセキュリティを使用しているWebアプリケーションをホストするコンピュータ上で、Oracle JRF WLSTスクリプトを見つけます。次に例を示します。
cd $ORACLE_HOME/oracle_common/common/bin
Oracle WebLogic Serverをホストするコンピュータに接続します。
connect login_id password hostname:port
たとえば、Oracle WebLogic管理サーバーのホストは、ポート7001を使用するlocalhostであることが考えられます。ただし、これは使用する環境によって異なる可能性があります。
ADFセキュリティが有効なアプリケーション用の値を使用して、次のコマンドライン引数を入力します。
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
Oracle WebLogic Serverを停止して起動します。
この章で説明されているように次のタスクを実行します。
アプリケーションを実行します。
この項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンを実行するために、WebLogicセキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。
次の手順では、WebLogic管理コンソールを使用します。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。手順1を省略してください。 |
シングル・サインオン用のOracle Access ManagerプロバイダをWebLogicドメインに設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート（10.1.4.3.0）を使用してoamAuthnProvider ZIPファイルを見つけます。
oamAuthnProvider<version number>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
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 IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブをクリックし、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース（ユーザー・ベースDNと同じ）。
デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。
保存します。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
保存します。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: （REQUIRED）
OID認証プロバイダ: （SUFFICIENT）
デフォルトの認証プロバイダ: （SUFFICIENT）
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次の手順を実行します。
成功: 「IDアサーション・プロバイダおよびOAM 10gのログイン・フォームの設定」に進みます。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
この項では、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダで提供されるログイン・フォームの概要を示し、このフォームをデプロイするための手順について説明します。
図9-17のフォームは、Oracle HTTP Server 11g Webサーバー用のWebゲート・インストールで提供されます。このフォームには、2つのフィールド（「ユーザーID」および「パスワード」）と「ログイン」ボタンがあります。このフォーム上の変数は、フォーム・ログイン認証スキームで必要とされます。この認証スキームはOAMCfgToolによって生成され、IDアサーション用にリソースを保護しているポリシー・ドメインで使用されます。
|
注意: このログイン・フォームの変数は変更しないでください。これらの変数は、Oracle Access Manager IDアサーション・プロバイダで使用する必要があります。 |
Webゲートのインストールおよび構成中に、Oracle HTTP Server 11g Webサーバーのhttpd.confファイルに次の情報が追加されます。これにより、Oracle HTTP Server 11gのWebゲートがデフォルト・ログイン・フォームを検索できるようになります。
Alias /oamsso "/oam/webgate/access/oamsso"
次の3行が存在する場合には、削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
次の手順を参考にして、環境に適したログイン・フォームを設定してください。
|
注意: このログイン・フォームは、OAM 10gでの10g Webゲート専用です。 |
IDアサーション・プロバイダおよびOAM 10gのログイン・フォームを設定するには
アプリケーションをホスティングしているコンピュータの次のOracle HTTP Server11g Webゲート・パスに、ログイン・フォームが存在することを確認します。
WebGate_install_dir/access/oamsso/login.html
ブラウザから、次のURLにアクセスします。
http://WebGatehost:port/oamsso/login.html
ログイン・プロセスで認証ユーザーを、元のリクエストしたアプリケーションURLにリダイレクトできるようにするために、ポリシー・マネージャのリソースを保護するように/accessポリシーが作成および有効化されていることを確認します。
次の手順に進みます。
次の手順では、Oracle Access Manager IDアサーションの設定をテストする方法について説明します。
また、10g Oracle Access Manager Access管理者ガイドの説明にあるように、Oracle Access Manager 10gのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
OAM 10gでのSSO用のIDアサーションを検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。次に例を示します。
http://ohs_server:port/<protected url>
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
Oracle Access Manager認証プロバイダを構成するには、この項の各タスクを実行する必要があります。
前提条件
IDアサーション固有の手順として特に明記されていないかぎり、「OAM 10g用の認証プロバイダのインストールおよび設定」で説明されているすべてのタスクを完了する必要があります。
認証プロバイダおよびOAM 10g用のコンポーネントとファイルをインストールし、その際にアクセス・システム・コンソールでカスタム・アクセス・ゲートのアクセス・ゲート・プロファイルを手動で作成し、ポリシー・マネージャの設定でデフォルト値を受け入れます。
Oracle Access Manager認証プロバイダを構成するためのその他のタスクについては、次のタスク概要で説明します。
|
注意: この項のタスクを実行するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。Oracle Access Manager以外に、このタスクを自動化できるツールはありません。 |
タスクの概要: Oracle Access Manager認証プロバイダの構成
前提条件のすべてのタスクが実行されていることの確認
この項では、ポリシー・ドメインにおける認証スキームの作成方法について説明します。ポリシー・ドメインは、後で認証プロバイダに対して定義します。Oracle Access Manager認証スキームは、ポリシー・ドメインの前に作成しておく必要があります。
認証プロバイダを使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、ポリシー・ドメインではOracle Access Manager認証スキームが必要です。
認証プロバイダの認証スキームを作成した後、そのスキームを使用するには、Oracle Access Managerでポリシー・ドメインを作成する必要があります。
Oracle Access Managerのポリシー・ドメインには、各種の情報が含まれています。図9-18に示されているように、個別のタブにそれぞれの詳細を入力できます。
図9-18 Oracle Access Managerポリシー・マネージャの「ポリシー・ドメインの作成」ページ
詳細は、次の各項を参照してください。
この項では、ポリシー・マネージャの各タブについて説明します。これらのタブを使用してポリシー・ドメインとアクセス・ポリシーの詳細を入力できます。ポリシー・ドメインのすべてのタブを使用しない場合もありますが、次のような一般情報が提供されます。
「一般」タブ: このポリシー・ドメインの名前を指定する簡潔な英数字の文字列を入力します。「名前」フィールドでは、空白を使用できます。説明はオプションです。すべての詳細を保存し、ドメインを使用する準備が整うまで、このポリシー・ドメインを有効にしないでください。
「リソース」タブ: このポリシー・ドメインによって保護されるリソースを追加します。URL接頭辞を使用して、ポリシー・ドメインのコンテンツを定義します。説明はオプションです。
「認可ルール」タブ: 認可ルールを指定します。認可ルールは、一般情報、「アクセスの許可」と「アクセスの拒否」の各条件、および後で認可条件式で使用されるルールのアクション（存在する場合）で構成されます。定義するそれぞれの認可ルールに対し、1つの認証スキームを指定する必要があります。
「デフォルト・ルール」タブ: リソースが特定のポリシーによって保護されている場合を除き、ポリシー・ドメインによって保護されるリソースに適用するデフォルト・ルールを作成します。このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加します。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームと複数の認証アクションを指定します。
認可条件式: これには、認可ルールとそれらを組み合せる演算子が含まれています。
監査ルール: マスター監査ルールが定義されていない場合は、アクセス・システム管理者に連絡するよう指示されます。
「ポリシー」タブ: ルールが定義されていない場合、ポリシー・ドメインのデフォルト・ルールが有効です。作成した各ポリシーに対して、特定の認証ルール、認可条件式および監査ルールを割り当てることができます。詳細に記載されたURLパターンを使用して、ポリシーを作成できます。ポリシーを設定する前に、保護するURLに対して必要なアクセス制御レベルを決定してください。
委任管理者タブ: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。
|
関連項目: 「認証プロバイダのポリシー・ドメインとアクセス・ポリシーの作成」、およびOracle Fusion Middleware Oracle Access Manager管理者ガイドの次の各項
|
認証プロバイダの実装では、ポリシー・ドメインにいくつかのデフォルト値と一意の値を指定する必要があります。ポリシー・ドメインを作成、表示または変更するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。
次の手順では、認証プロバイダに対して次のようなポリシー・ドメインを作成します。
（ポリシー・マネージャで設定された）デフォルトのBasic認証スキームを内部的に使用して、ユーザーを認証し、/Authen/Basicという接頭辞の付いたURLリソースを保護します。
以前に定義されたタイプwl_authenのリソースを保護します。「Oracle Access Manager 10gでのリソース・タイプの作成」も参照してください。
以前に作成したOracle Access Manager認証スキームを使用して、ユーザーの資格証明をリクエストします。
|
注意: 認証プロバイダでは、アプリケーションのweb.xmlファイルで定義されているBasic認証方式が必要です。この認証方式は、「認証プロバイダのアプリケーション認証方式の構成」の説明に従って後で設定します。 |
デフォルト認証ルールとアクションが必要です。次の手順で、認証の成功時にユーザーとグループが返されるようにこれらを構成します。
アクションが定義されていないデフォルト認可ルールが必要です。これは、次の手順で構成します。
|
注意: 認証プロバイダでは、認可は実行されません。このため、認可条件式は必要ありません。 |
次の例は、説明のみを目的としています。環境に応じて適切な値を入力してください。
Oracle Access Manager認証プロバイダのポリシー・ドメインを作成するには
ポリシー・マネージャに移動して、ログインします。次に例を示します。
http://Webserver:port/access/oblix
ここで、Webserverはポリシー・マネージャのWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システムに接続します。
ポリシー・マネージャをクリックします。
左側のナビゲーション・ペインの「ポリシー・ドメインの作成」をクリックして、「ポリシー・ドメインの作成」ページを表示します。
「一般」タブ: ポリシー・ドメイン・リストを示すページに表示される名前とオプションの説明を入力し、「保存」をクリックします。次に例を示します。
名前: Default OAM Authenticator
説明: For Username Resolution
|
注意: すべての指定が完了するまで、このポリシー・ドメインを有効にしないでください。 |
「リソース」タブ: 「リソース」タブ→「追加」ボタンをクリックし、リソース・タイプを選択してURL接頭辞を入力します。次の内容を保存します。
リソース・タイプ: wl_authen
ホスト識別子（オプション）: アクセス・ゲートの優先HTTPホストを選択します。
URL接頭辞: /Authen/Basic
説明: OAM Authenticator validates user name, password
「追加」をクリックします。
リソース・タイプ: wl_authen
URL接頭辞: /Authen/UsernameAssertion
説明: Authenticator Resource to validate user name
「保存」をクリックします。
「デフォルト・ルール」タブ: このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加します。リソースが特定のポリシーによって保護されている場合を除き、ポリシー・ドメインのデフォルト・ルールがポリシー・ドメイン内のリソースに適用されます。
「デフォルト・ルール」をクリックし、「追加」をクリックしてBasic認証スキームのルールを作成します。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームと複数の認証アクションを指定します。名前とオプションの説明を入力し、「認証スキーム」を選択します。
「認証ルール」をクリックし、「一般」タブに次の情報を入力します。
名前: Basic Authentication Scheme
説明: User name and password based authentication
認証スキーム: Basic Over LDAP
「保存」をクリックします。
|
注意: 認証プロバイダでは、ObMyGroups属性のルールでAuthentication Success Returnアクションのみが必要です。このアクセス・サーバー固有の属性は、ユーザーが属しているすべてのグループを返します。手順Cで説明されているように、他の2つの実装でもこのアクションが必要です。 |
認証ルール、アクション: 認証プロバイダを使用する場合（またはOracle Access Managerに存在する管理者ユーザーとしてOracle WebLogicを起動する場合、あるいはOracle Web Services Managerを使用している場合）に指定します。
「アクション」タブ→「追加」をクリックします。
「認証成功」に、次の情報を入力します。
リダイレクションURL: 空白
戻り
タイプ： WL_REALM
名前: obmygroups
戻り属性: obmygroups
この戻り属性は、ユーザーが属しているすべてのグループを返すようにアクセス・サーバーに指示します。
次に、LDAPディレクトリ・サーバーでユーザーを一意に識別するために、ユーザー名のログイン・パラメータの名前を入力します。
タイプ： WL_REALM
名前: uid
戻り属性: uid
この戻り属性は、ユーザー名のログイン・パラメータの名前を返します。これは、Oracle Access Managerで使用されるLDAPディレクトリ・サーバーのユーザーを一意に識別するために役立ちます。
「ポリシー」タブ: 「ポリシー」タブ→「追加」をクリックします。
情報を入力し、「一般」の詳細を保存します。
名前: Default Username Resolution Policy
説明: Default Username Policy for Authenticator
リソース・タイプ: wl_authen
リソース操作: LOGIN
リソース: /Authen/UsernameAssertion
他の項目は変更せず、そのままにしておきます。
「保存」をクリックします。
「認証ルール」サブ・タブ→「追加」をクリックし、「一般」の詳細を入力します（名前、オプションの説明、認証スキーム）。
名前: Username Resolution Authentication Rule
認証スキーム: UsernameAssertion認証スキーム
「認証プロバイダの認証スキームの作成」を参照してください。
「保存」をクリックします。
「アクション」サブ・タブをクリックし、「認証成功」に次の情報を追加します。
戻り型: WL_REALM
戻り名: uid
戻り属性: uid
|
注意: 「戻り属性」には、必ず値を入力してください。uidは、LDAP ObjectClassのログイン属性名で、Oracle Access Managerによって使用されるディレクトリ・サーバーでユーザーを一意に識別するために役立ちます。 |
「アクション」サブ・タブをクリックし、「認証成功」に次の情報を追加します。
戻り型: WL_REALM
戻り名: obmygroups
戻り属性: obmygroups
|
注意: obmygroupsは、メンバーが属しているすべてのグループを返します。 |
委任アクセス管理: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイドのポリシー・ドメイン管理の委任に関する項 |
この項では、WebLogicドメインに適切な認証プロバイダを追加および構成するための手順について説明します。
Oracle Access Manager認証プロバイダは、WebLogicドメインのデフォルト認証プロバイダに従って構成する必要があります。
次の手順では、WebLogic管理コンソールを使用してこのタスクを実行する方法について説明します。これらは、Oracle WebLogic Scripting Tool（WLST）を使用して追加することもできます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なファイルはすでにインストールされているので、手順1は省略できます。 |
WebLogicドメインにOracle Access Manager認証プロバイダを構成するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート（10.1.4.3.0）を使用してoamAuthnProvider ZIPファイルを見つけます。次に例を示します。
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic管理コンソールに移動します。
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
Oracle WebLogic管理コンソールに移動します。
必要に応じて、「ロックして編集」をクリックします。
OAM認証プロバイダ:
「セキュリティ・レルム」をクリックし、構成するレルムを選択します。
「プロバイダ」→「認証」を選択し、「新規」をクリックして、「新しい認証プロバイダの作成」ページを表示します。
名前を入力して、タイプを選択します。
名前: OAMAuthN
タイプ: OAMAuthenticator
OK
作成した認証プロバイダの名前をクリックして、「プロバイダ構成」ページを表示します。
「プロバイダ構成」ページで、次のように必要な値を設定します。
アクセス・ゲート名: プロバイダによって使用されるアクセス・ゲートの名前。これは、アクセス・システム・コンソールのアクセス・ゲート構成プロファイル内の名前と完全に一致している必要があります。
|
注意: 認証プロバイダ用のアクセス・ゲート構成プロファイルが1つしかない場合もあります。 |
アクセス・ゲートのパスワード: アクセス・システム・コンソールでアクセス・ゲート構成プロファイルに対してパスワードが定義されている場合は、それと同じパスワード。
プライマリ・アクセス・サーバー: アクセス・システム・コンソールでこのアクセス・ゲートに関連付けられているプライマリ・アクセス・サーバーのhost:port。
詳細構成: 次に、いくつかの詳細構成の値を示します。
トランスポート・セキュリティ: アクセス・サーバーとアクセス・ゲート間の通信モード（オープン、簡易、証明書）。
トランスポート・セキュリティが簡易または証明書である場合、次のパラメータと値を含めてください。
トラスト・ストア: プロバイダとOracle Access Server間のSSL通信で使用されるJKSトラスト・ストアの絶対パス。
キー・ストア: プロバイダとOracle Access Server間のSSL通信で使用されるJKSキー・ストアの絶対パス。
キー・ストアのパスフレーズ: キー・ストアにアクセスするためのパスワード。
簡易モード・パスフレーズ: アクセス・ゲートとアクセス・サーバーで共有される簡易通信モード用パスワード。
セカンダリ・アクセス・サーバー: アクセス・システム・コンソールでこのアクセス・ゲートに関連付けられているセカンダリ・アクセス・サーバーのhost:port。
プール内の最大アクセス・サーバー接続数: アクセス・ゲートがアクセス・サーバーに対してオープンする最大接続数。デフォルト値は10です。
|
注意: WebLogic管理コンソールでの「プール内の最大アクセス・サーバー接続数」（または「プール内の最小アクセス・サーバー接続数」）の設定は、アクセス・システム・コンソール内でプロファイルに指定されている「最大接続数」または「最小接続数」とは異なります。 |
プール内の最小アクセス・サーバー接続数: 認証プロバイダからアクセス・サーバーへの認証リクエストの送信に使用する最小接続数。デフォルト値は5です。
パラメータ「制御フラグ」がOPTIONALに初期設定されていることを確認します。
|
注意: 認証プロバイダが機能し、正しく構成されていることを確認するまで、パラメータ「制御フラグ」をREQUIREDに設定しないでください。 |
チェンジ・センターで、変更のアクティブ化をクリックします。
DefaultAuthenticator: 「プロバイダ」タブでDefaultAuthenticatorを選択します。これにより、その制御フラグがSUFFICIENTに変更されます。
並べ替え: 「プロバイダ」タブで、DefaultAuthenticatorが先頭になるように（DefaultAuthenticatorの後にOAMAuthenticator)プロバイダを並べ替えます。
|
注意: Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。 |
Oracle Access Manager認証プロバイダのREQUIREDまたは唯一の認証プロバイダである場合: 次の手順を実行して、Oracle WebLogic Serverを起動するためのユーザー権限を設定します。
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ（または、起動権限を付与する必要があるその他のグループ）を作成します。
|
注意: その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。 |
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
Adminロールの「構成の表示」を選択します。
グループを追加して「保存」をクリックします。
WebLogic Serverを再起動します。
サーバーを起動すると、認証プロバイダ・パラメータ「制御フラグ」が適切な値（REQUIRED、OPTIONAL、またはSUFFICIENT）にリセットされます。
この項では、Oracle Access Manager認証プロバイダのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager認証プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をBASICに指定する必要があります。
auth-methodには、BASICまたはFORMの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
|
注意: Oracle Access Manager認証プロバイダの場合、web.xml内のlogin-configにauth-method BASICを指定することをお薦めします。 |
認証プロバイダのアプリケーション認証方式を構成するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
WEB-INF/web.xml
login-configでauth-methodを検索し、BASICと入力します。次に例を示します。
<security-constraint> <web-resource-collection> <web-resource-name>protected</web-resource-name> <url-pattern>/servlet</url-pattern> </web-resource-collection> <auth-constraint> <role-name>auth-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <description>Authenticated Users</description> <role-name>auth-users</role-name> </security-role>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
この項では、認証ユーザーをLDAP内のグループにマップする方法について説明します。このためには、weblogic.xmlファイルを編集する必要があります。たとえば、ロール名auth-usersをLDAP内のmanagersというグループにマップできます。
Oracle Access Manager認証プロバイダ用に認証ユーザーをLDAP内のグループにマップするには
アプリケーションのweblogic.xmlファイルに移動します。
ファイル内の任意の場所に、環境に応じて次の情報を追加します。
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<security-role-assignment>
<principal-name>managers</principal-name>
<role-name>auth-users</role-name>
</security-role-assignment>
</weblogic-web-app>
ファイルを保存します。
WebLogic Serverを再起動します。
次の手順に進みます。
認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。
次の手順では、認証プロバイダの設定をテストする方法について説明します。また、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
Oracle Access Manager認証プロバイダの実装を検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。次に例を示します。
http://yourdomain.com:port
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
この項では、Oracle Web Services ManagerがWebサービスを保護している場合に、ObSSOCookieトークンの検証を有効にするようにOracle Access Manager IDアサーション・プロバイダを設定する方法について説明します。
Oracle Access Manager IDアサーション・プロバイダがヘッダーとObSSOCookieトークンの両方の検証モードで構成されている場合、ヘッダーが優先されます。ヘッダーが存在しない場合は、IDアサーション・プロバイダはアクセス・サーバーにアクセスしてObSSOCookieトークンを検証します。
Oracle Access Manager IDアサーション・プロバイダは、次の2つのモードで機能します。
デフォルト・モードの操作では、Webゲートが境界に設定したヘッダーがアサートされます。
もう1つのモードでは、oamAuthnProvider.jarにあるカスタム・アクセス・ゲートを使用します。この場合（ヘッダーも存在しない場合）、IDアサーション・プロバイダはアクセス・サーバーにアクセスしてObSSOCookieトークンを検証します。
|
注意: Oracle Web Services Managerでは、アクセス・ゲートが必要です。 |
前提条件
認証プロバイダおよびOAM 10g用のコンポーネントとファイルをインストールし、その際にアクセス・システム・コンソールでカスタム・アクセス・ゲートのアクセス・ゲート・プロファイルを手動で作成し、ポリシー・マネージャの設定でデフォルト値を受け入れます。
タスクの概要: Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ
前提条件のすべてのタスクが実行されていることの確認
この項では、Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダによって使用されるポリシー・ドメインを設定する方法について説明します。ポリシー・ドメインを作成、表示または変更するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。
このポリシー・ドメインでは、次の一意の値が必要です。
（ポリシー・マネージャで設定された）デフォルトのBasic Over LDAP認証スキームを内部的に使用して、ユーザーを認証し、/Authen/SSOTokenという接頭辞の付いたURLリソースを保護します。
「Oracle Access Manager 10gでのリソース・タイプの作成」で定義した、タイプwl_authenのリソースを保護します。
アクションが定義されていないデフォルト認証ルールが必要です。これは、次の手順で設定します。
アクションが定義されているデフォルト認可ルールが必要です。これは、次の手順で設定します。
次の手順では、Oracle Web Services ManagerとOracle Access Manager IDアサーション・プロバイダによって使用されるポリシー・ドメインを作成する方法について説明します。
Oracle Web Services Managerを使用するIDアサーション・プロバイダのポリシー・ドメインを作成するには
ポリシー・マネージャに移動して、ログインします。次に例を示します。
http://Webserver:port/access/oblix
ここで、Webserverはポリシー・マネージャのWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
ポリシー・マネージャをクリックします。
左側のナビゲーション・ペインの「ポリシー・ドメインの作成」をクリックして、「ポリシー・ドメインの作成」ページを表示します。
「一般」タブ: ポリシー・ドメイン・リストを示すページに表示される名前とオプションの説明を入力し、「保存」をクリックします。次に例を示します。
名前: OAM IA OWSM
説明: Used by Identity Asserter with Oracle Web Services Manager
|
注意: すべての詳細が完了するまで、このポリシー・ドメインを有効にしないでください。 |
「リソース」タブ: 「リソース」タブ→「追加」ボタンをクリックし、リソース・タイプを選択してURL接頭辞を入力します。次の内容を保存します。
リソース・タイプ: wl_authen
URL接頭辞: /Authen/SSOToken
説明: Used by IA OWS to validate SSO token
保存します。
「認可ルール」タブ: 後で認可条件式で使用する認可ルールを追加します。
「認可ルール」タブ→「追加」ボタンをクリックします。
「一般」タブ: 認可ルールの名前と、オプションで簡潔な説明を入力します。
名前: Default_OAM_IA_OWS_AuthZ_Rule
説明: For use with OWS and Identity Asserter
有効: はい
許可を優先: いいえ
タイミング条件: このシナリオには必要ありません。
アクション: このタブでの設定は必要ありません。かわりに、「デフォルト・ルール」タブでこれらを設定します。
アクセスの許可: ルールの「アクセスの許可」部分を適用するユーザーの詳細を追加します。
ロール: 任意の個人
アクセスの拒否: このシナリオでは必要ありません。
認可ルールの「一般」タブに戻り、ルールを有効にして、後で認可条件式に追加できるようにします。
|
関連項目: 認可スキームとルールの構成方法の詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの第6章を参照してください。 |
「デフォルト・ルール」タブ: このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加できます。リソースが特定のポリシーによって保護されている場合を除き、これらのデフォルト・ルールがポリシー・ドメイン内のリソースに適用されます。
「デフォルト・ルール」→「追加」をクリックします。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームとオプションの認証アクションを指定します。名前とオプションの説明を入力し、「認証スキーム」を選択します。
「一般」タブ: 次のように入力します。
名前: Default AuthN Rule
説明: Default Rule for OAM IA OSW
認証スキーム: Basic Over LDAP
「保存」をクリックします。
「アクション」タブ: Oracle Web Services Managerのデフォルト・ルールでは、認証アクションは必要ありません。
|
注意: Oracle Web Services Managerを使用している場合は、認可ルールが必要です。 |
認可条件式: 条件式を含むポリシーによってリソースが保護されている場合を除き、ポリシー・ドメインのデフォルト・ルールの認可条件式は、ドメイン内のすべてのリソースに適用されます。
「認可条件式」タブ→「追加」をクリックします。
「式」タブ: 手順6で作成した認可ルールを選択します。
認可ルールDefault_OAM_IA_OWS_AuthZ_Ruleを選択します。
「追加」をクリックします。
「保存」をクリックします。
「アクション」タブ: 手順6で、ルールの「アクセスの許可」部分を適用するユーザーを定義しました。ここでは、ルールと式の両方について、認証成功のアクションを指定します。
「アクション」→「追加」をクリックし、次のように認証が成功した場合に呼び出されるアクションを指定して、「認可成功」の戻りアクションを作成します。
認可成功: 「アクセスの許可」の条件に適用されます。
戻り型: WL_REALM
戻り名: uid
戻り属性: uid
「保存」をクリックします。
|
注意: 戻り属性uidは、Oracle Access ManagerのLDAPリポジトリでユーザーを一意に識別するために、ユーザー名のログイン・パラメータの値に一致させる必要があります。uidは、ログイン属性の正規名です。LDAPディレクトリで異なる属性がログイン属性として使用されている場合でも、名前はuidになります。ただし、戻り属性は、ログイン属性の構成に一致します（mailなど）。これらの値は、（「戻り値」ではなく）「戻り属性」に入力する必要があります。 |
「ポリシー」タブ: ポリシーは必要ありません。デフォルト・ルールが適用されます。
委任アクセス管理: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイドのポリシー・ドメイン管理の委任に関する項 |
ポリシー・ドメインの検証: 「ポリシー・ドメイン」をクリックし、作成した新しいポリシー・ドメインをクリックした後、「ページとして表示」をクリックしてすべての詳細をまとめて表示します。
この項では、Oracle Web Services Managerポリシーを構成してWebサービスを保護する方法について概説します。
Oracle Web Services ManagerでIDアサーション・プロバイダを使用するには、Webサービスにoracle/wss_oam_token_service_policyを設定し、対応するクライアントにoracle/wss_oam_token_client_policyを設定する必要があります。
oracle/wss_oam_token_service_policyについて
このOracle Web Services Managerポリシーには、ポリシー・アサーションoracle/wss_oam_token_service_templateが含まれています。このテンプレートは、WSセキュリティ・ヘッダーのバイナリ・セキュリティ・トークンの資格証明を使用して、Oracle Access Managerアイデンティティ・ストアに対してユーザーを認証します。
Oracle Access Manager IDアサーション・プロバイダは、ObSSOCookieトークンを使用して、oracle/wss_oam_token_service_policyポリシーによって保護されているWebサービスにアクセスしようとしているユーザーのアイデンティティをアサートします。このポリシーによって保護されているWebサービスは、SOAPヘッダーのObSSOCookieトークンで提示される必要があります。つまり、WebサービスはObSSOCookieトークンを使用し、トークンの生成方法には関与しません。具体的には、WebLogic Serverセキュリティ・サービスがトークン・タイプを検出し、Oracle Access Manager IDアサーション・プロバイダを呼び出します。Oracle Access Manager IDアサーション・プロバイダは、Oracle Access Managerアクセス・サーバーに対してObSSOCookieトークンを検証し、ユーザー名を取得します。ユーザー名がプリンシパルとして認証済サブジェクトに移入されます。
Webサービス・クライアント（Webアプリケーションなど）は、ObSSOCookieトークンを取得してWebサービスに送信する必要があります。通常、これはアクセス・ゲートを使用して行われます。アクセス・ゲートは、（Oracle Access Managerで構成された認証スキームに応じて）Webサービス・クライアントのユーザーに資格証明を要求し、ユーザーを認証します。認証が成功すると、WebゲートによってObSSOCookieがユーザーのブラウザに送信されます。
Webサービス・クライアントは、ObSSOCookieトークンをSOAPリクエストとしてWebサービスに送信します。
|
注意: wss_oam_token_service_templateの設定は、クライアント・バージョンのアサーションwss_oam_token_client_templateと同じです。サービス・テンプレートのアイデンティティ・ストア構成は、クライアント・バージョンのアサーションと同じです。 |
oracle/wss_oam_token_client_policyについて
このOracle Web Services Managerポリシーには、ポリシー・アサーションoracle/wss_oam_token_client_templateが含まれています。このテンプレートは、Oracle Access Manager資格証明をバイナリ・セキュリティ・トークンの一部としてWSセキュリティ・ヘッダーに挿入します。
oracle/wss_oam_token_client_policyは、oracle/wss_oam_token_service_policyサービス・エンドポイント・ポリシーに対応するクライアント・ポリシーです。このポリシーは、任意のSOAPベースのエンドポイントで実施できます。
次のタスクの概要に、実行する必要のある手順の概要を示します。
タスクの概要: Oracle Web Services Managerのポリシーの設定
Oracle Web Services Managerを使用して、Webサービスにoracle/wss_oam_token_service_policyポリシーを設定します。
Oracle Web Services Managerを使用して、Webサービスに対応するクライアントにoracle/wss_oam_token_client_policyポリシーを設定します。
|
関連項目:
|
Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダを使用するには、WebLogicドメインでいくつかの認証プロバイダを構成し、並べ替える必要があります。
この手順は、Oracle Access Manager IDアサーション・プロバイダの場合とほとんど同じです。この場合の相違点は、Oracle Web Services Managerはカスタム・アクセス・ゲートを必要とし、追加のプロバイダ固有の値が必要になることです。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。
アクセス・ゲート名: アプリケーションを保護するアクセス・ゲートの名前。例: mmmm。
アクセス・ゲートのパスワード: アクセス・システム・コンソールで指定したアクセス・ゲート・パスワード。
これらは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool（WLST）コマンドライン・ツールを使用して追加できます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダ・ファイルはすでにインストールされています。手順1を省略してください。 |
WebLogicドメインでプロバイダを設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート（10.1.4.3.0）を使用してoamAuthnProvider ZIPファイルを見つけます。次に例を示します。
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic管理コンソールにログインします。
OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブで、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。
プラットフォーム固有のタブをクリックし、次のパラメータを構成します。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。
アクセス・ゲート名: アプリケーションを保護するアクセス・ゲートの名前。例: mmmm。
アクセス・ゲートのパスワード: アクセス・システム・コンソールで指定したアクセス・ゲート・パスワード。
保存します。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
「OK」をクリックします。
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース（ユーザー・ベースDNと同じ）。
|
注意: デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。 |
「保存」をクリックします。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
「保存」をクリックします。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: （REQUIRED）
OID認証プロバイダ: （SUFFICIENT）
デフォルトの認証プロバイダ: （SUFFICIENT）
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次の手順を実行します。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
Oracle Web Services Managerを使用している場合にOracle Access Manager IDアサーション・プロバイダの使用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスに成功した場合、実装は機能しています。失敗した場合は、「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
この項では、Oracle Access Manager認証プロバイダに関係する共通およびプロバイダ固有のパラメータを列挙します。これらのパラメータは、Oracle WebLogic管理コンソールで指定します。詳細は、次の各項を参照してください。
表9-10 Oracle Access Manager認証プロバイダの共通パラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
名前 |
プロバイダの名前。読取り専用。 |
|
説明 |
プロバイダの説明。読取り専用。 |
|
バージョン |
プロバイダのバージョン。読取り専用。 |
|
制御フラグ |
プロバイダJAAS制御フラグ。REQUIRED、REQUISITE、OPTIONALまたはSUFFICIENTの1つを設定します。複数の認証プロバイダを構成する場合、このフラグを使用してログイン・シーケンスでのそれらの使用方法を制御します。「JAAS制御フラグ」を参照してください。 |
|
アクティブなタイプ |
このパラメータは、Oracle Access Manager IDアサーション・プロバイダにのみ関連しています。このパラメータは、IDアサーション・プロバイダによって処理されるトークン・タイプを決定します。次のとおり設定します。
注意: OAM 10gまたは11gでの10g Webゲートの場合、OAM_REMOTE_USERも存在するので、選択済のアクティブ・タイプとしてOAM_REMOTE_USERを使用するようにIDアサーション・プロバイダを構成できます。 |
|
Base64でのデコーディングが必要 |
Falseは読取り専用（デフォルト）。 |
新しいセキュリティ・プロバイダを作成すると、WebLogic Server管理コンソールによって、JAAS制御フラグがOPTIONALに設定されます。すぐに使用できるセキュリティ・プロバイダのデフォルト値はREQUIREDです。制御フラグの詳細は、オンライン・ヘルプを参照してください。
表9-11は、Oracle Access Manager認証プロバイダまたはOracle Web Services ManagerのIDアサーション・プロバイダのプロバイダ固有のパラメータを示しています。
|
注意: OAM 11gでは、アクセス・サーバーはOAMサーバーと呼ばれています。 |
表9-11 プロバイダ固有のパラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
トランスポート・セキュリティ |
アクセス・ゲートとアクセス・サーバーの間の通信モード。 |
|
プール内の最小アクセス・サーバー接続数 |
許可される最小接続数。デフォルト値は5です。 |
|
アクセス・ゲートのパスワード |
プロバイダによって使用されるアクセス・ゲートのパスワード。 |
|
キー・ストアのパスフレーズ |
キー・ストアにアクセスするためのパスワード。 |
|
アクセス・ゲート名 |
プロバイダによって使用されるアクセス・ゲートの名前。必須です。 |
|
プライマリ・アクセス・サーバー |
プライマリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。必須です。「OAM 10g用の認証プロバイダのインストールおよび設定」を参照してください。 |
|
プール内の最大アクセス・サーバー接続数 |
許可される最大接続数。デフォルト値は10です。1に設定します。 |
|
簡易モードのパスフレーズ |
簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。 |
|
トラスト・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。 |
|
SSOヘッダー名 |
OAM_REMOTE_USER |
|
セカンダリ・アクセス・サーバー |
セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。「OAM 10g用の認証プロバイダのインストールおよび設定」を参照してください。 |
|
キー・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。 |
表9-12は、Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータを示しています。
表9-12 Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
トランスポート・セキュリティ |
アクセス・ゲートとアクセス・サーバーの間の通信モード。 |
|
プール内の最大アクセス・サーバー接続数 |
許可される最大接続数。デフォルト値は10です。1に設定します。 |
|
簡易モードのパスフレーズ |
簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。 |
|
プール内の最小アクセス・サーバー接続数 |
許可される最小接続数。デフォルト値は5です。 |
|
トラスト・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。 |
|
取得したユーザー名をプリンシパルとして使用する |
Oracle Access Managerから取得したユーザー名をサブジェクトのプリンシパルとして使用するかどうかを指定します。 |
|
アクセス・ゲートのパスワード |
プロバイダによって使用されるアクセス・ゲートのパスワード。 |
|
キー・ストアのパスフレーズ |
キー・ストアにアクセスするためのパスワード。 |
|
アクセス・ゲート名 |
プロバイダによって使用されるアクセス・ゲートの名前。必須です。 |
|
セカンダリ・アクセス・サーバー |
セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。次の各項を参照してください。 |
|
キー・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。 |
|
プライマリ・アクセス・サーバー |
プライマリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。必須です。次の各項を参照してください。 |
この項では、Oracle Access Manager 10gでの10g Webゲートで保護されたアプリケーションのログアウトの構成について説明します。Oracle Access Manager 10gでは、様々な方法でグローバル・ログアウト（シングル・ログアウト（SLO）ともいいます）を処理できます。この項では、推奨方法について説明します。
|
注意: Oracle Access Manager SSOユーザー・セッションの追跡は、ドメインのCookie、つまりObSSOCookieを使用して実行されます。Webゲートは、ObSSOCookieを検索します。Oracle Access Managerのグローバル・ログアウトまたはSLOは、単にObSSOCookieをクリアすることを意味します。ObSSOCookieがない場合、Webゲートは再認証ワークフローを実施します。 |
ObSSOCookieをクリアする方法の詳細は、次の各項を参照してください。
ログアウトを構成するための推奨方法には、次の2つの手順があります。
Webゲートの構成は、次のもので構成されています。
logout.html: ログアウト・ページは、Webゲートのインストール・ディレクトリ内のWebサーバーで使用可能である必要があります（WebGate_install_dir/oamsso/logout.html）。
ファイルがWebサーバー上の別の場所に格納されている場合には、logout.htmlをロードするためのログアウト・リンクが正しく指定されていることを確認します。例9-1のlogout.htmlを参照してください。この例を参照すると、ニーズに応じてさらにカスタマイズすることができます。
logOutUrls（オプション）: このパラメータがすでにWebゲートに対して構成されている場合には、値「/oamsso/logout.html」を既存のリストに追加する必要があります。
Webサーバーの構成: 10g Webゲートが構成されている、Oracle HTTP Server Webサーバーの構成ファイルhttpd.confを確認し、次の行が存在する場合には、それを削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
例9-1を使用して、OAM 10gデプロイメントで10g Webゲートによって保護されているアプリケーションのログアウト構成用のlogout.htmlを作成します。
例9-1 logout.htmlのスクリプト
<html>
<head>
<script language="javascript" type="text/javascript">
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);
//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;
if (origQueryString != null && origQueryString != "") {
params = origQueryString.split("&");
//search for end_url and redirect the user to this
for (var i=0; i<params.length; i++) {
par = params[i].split("=");
if ("end_url" == par[0]) {
endUrlVal = par[1];
//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (endUrlVal.substring(0,1) == "/" || endUrlVal.substring(0,1) == "%") {
if (endUrlVal.substring(0,1) == "%")
endUrlVal = "/" + endUrlVal.substring(3);
//modify the end_url value now
endUrlVal = webServerProtocol + "//" + webServerHostPort + endUrlVal;
}
//redirect the user to this URL
window.location.href = endUrlVal;
}
}
}
}
</script>
</head>
<body onLoad="handleLogout();">
<h3>You have been logged out<h3>
</body>
</html>
ログアウト用のアプリケーション構成は、ADFアプリケーションがOPSSと統合されているか統合されていないに応じて異なります。
|
注意: ログアウトの構成は、アプリケーションが1つのDNSドメイン内に存在することが前提となっています。別のDNSドメインにデプロイしたアプリケーション全体にわたってシングル・ログアウト（SLO）する場合には、各Webゲートを処理できるようにログアウト・スクリプトをカスタマイズする必要があります。複数のDNSドメインのデプロイを指定している場合には、Oracle Access Manager Access管理ガイドを参照してください。 |
アプリケーションのログアウトを構成する際には、次のいずれかを実行する必要があります。
非ADFアプリケーションは、ログアウト・リンク（/oamsso/logout.html?end_url=<target uri>）を呼び出すようにコード化されている必要があります。
OPSSと統合されているADFアプリケーションでは、OAM SSOプロバイダのOPSSが構成されている必要があり、アプリケーションではend_urlパラメータを送信する必要があります。
非ADFアプリケーション
非ADFアプリケーションは、ログアウト・リンク（/oamsso/logout.html?end_url=<target uri>）を呼び出すようにコード化されている必要があります。
このアプリケーションは、ログアウトしたユーザーの最終的なリダイレクト先を示すパラメータ（end_url）を渡すことができます。end_urlの一部であるパラメータの値は、URLまたはURIのいずれかです。たとえば、アプリケーションのログアウト・リンクは次のように指定できます。
/oamsso/logout.html?end_url=<someUri>
または
/oamsso/logout.html?end_url=<someUrl>
end_urlの問合せ文字列がURIの場合、logout.htmlがホスティングされるサーバーのhost:portを決定することにより、logout.htmlはURLを構成する必要があります。
ADFコード化アプリケーション
アプリケーションがOPSSと統合されたADFアプリケーションの場合、次の手順に従ってログアウトを構成できます。
ADFコード化アプリケーションの集中管理ログアウトを構成するには
OAM管理者にエージェントで構成されたlogout.htmlスクリプトの場所を確認します。それには、次の手順を実行する必要があります。
OAMのOPSSをSSOプロバイダとして構成し、次のようにWebLogic管理ドメインのjps-config.xmlを更新します。
次のディレクトリ・パスからwlst.sh（Linux）またはwlst.cmd（Windows）を実行します。
WLST_install_dir/middleware/oracle_common/common/bin
WLSのプロンプトで、OAM管理者IDとパスワード、およびWebゲートのホストとポートを入力します
wls:/> /connect("admin_ID", "admin_pw", "hostname:port"
デフォルト・ポート（7001）でローカルホスト上でサーバーが実行している場合、最後のパラメータはオプションです。
ADF認証のloginuriとlogouturi（エージェントで構成されたlogout.htmlスクリプトの場所）を入力します。ホストとポートは必要ありません。
wls:/>addOAMSSOProvider(loginuri="/$<loginuri>",
logouturi="<logouturival>," autologinuri=None")
この場合、logouturivalはログアウト・スクリプト/oamsso/logout.htmlのURIです。logouturlはどちらの場合も「logout」で始めます（例外はlogout.gifおよびlogout.jpg）。または、OAM管理者が構成した別の値にすることもできます。
必須: ADFアプリケーションは、ログアウトしたユーザーのリダイレクト先を示すend_urlパラメータを渡す必要があります。ADFアプリケーションの場合、アプリケーションによって次のURIが呼び出されたときにログアウトが開始されます。
/<app context root>/adfAuthentication?logout=true&end_url=<any uri>
アプリケーションにすでにカスタムのログアウトページがあり、いかなる理由でも変更しない場合を除いて、この方法を使用しないようお薦めします。
Webゲートは、文字列「logout.」が含まれているURLへのリクエストをすべてログアウトします。例外: logout.gifやlogout.jpgなどのイメージ・ファイルは例外です。これは、アプリケーションをOAM SLOと統合するための最も簡単な方法です。ログアウト・ページが「logout.」で始まっている場合（例: logout.jsp）は、何もする必要はありません。
|
注意: ログアウト・ページが「logout.」で始まっている場合（例: logout.jsp）は、何もする必要はありません。 |
ログアウト・ページが「logout.」で始まっていない場合、ログアウトURLをWebGate LogOutUrlsパラメータに追加する必要があります。例: LogOutUrls = "/myapplication /customscript.jsp"。
表9-13に、このリリースに関する既知の問題を示します。ツール、パラメータおよび値の詳細は、「OAMCfgToolの使用について」を参照してください。
表9-13 OAMCfgToolの既知の問題
| Bug番号 | 説明 |
|---|---|
|
該当なし |
Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするOracle Access Manager認証プロバイダとOAMCfgToolのJARファイルのダウンロード元は、変更される可能性があります。この章に記載されている場所とは異なっている場合、リリース・ノートを参照して最新情報を確認してください。 |
|
8362080 |
OAMCfgToolツールでは、CreateおよびValidateオプションが提供されます。DeleteまたはOverwriteオプションは提供されません。 |
|
8362039 |
OAMCfgToolでは、Web層のホストおよびポートを指定するための明示的なオプションは提供されません。かわりに、web_domainが指定されていない場合、app_domain値によってWebゲート名、ホストおよび優先HTTPホストが指定されます。次に例を示します。
|
|
該当なし |
OAMCfgToolでは、web_domainパラメータがコマンドラインに含まれている場合、Webゲートのパスワードを指定する必要があります。指定しない場合、コマンドラインは失敗する可能性があります。 app_agent_passwordパラメータは、等号（=）に続く任意の文字列をパスワードとして受け入れます。たとえば、app_agent_password=と入力し、空白を入力してからweb_domain=valueと入力すると、app_agent_passwordは、空白の後にweb_domainが付いた文字列であるとみなされます。 |
|
該当なし |
ディレクトリ・サーバーとのSSL対応通信は、OAMCfgToolによってサポートされていません。 |
この項の内容は次のとおりです。
Oracle Fusion MiddlewareとOracle Access Managerは、Internet Protocol Version 4（IPv4）とInternet Protocol Version 6（IPv6）をサポートしています。IPv6の機能の中で特に重要なのは、IPv6がサポートするアドレス空間（128ビット）です。これは、IPv4（32ビット）のアドレス空間よりもかなり大きいため、Web上で指定可能なコンピュータの数が飛躍的に増えます。
|
関連項目: IPv6の使用の詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。 |
Apacheブリッジが失敗する場合、接続できるバックエンド・サーバーが存在しないことを示すメッセージが表示されることがあります。この場合、接続はタイムアウトします。
Oracle WebLogic Serverが停止しているか、mod_weblogicに不正な値が設定されている可能性があります。
Apacheブリッジの失敗からリカバリするには
Oracle WebLogic Serverが使用可能であることを確認します。
WebゲートのWebサーバーのhttpd.confで、ホスト情報とポート情報が正しく指定されていることを確認します。次に例を示します。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>
認証されたユーザーが、リクエストしたリソースへのアクセス権限を持っていない可能性があります。
ユーザー・ログインが決定的ではない場合や無効な場合、ユーザーは認証されますが、リスエストしたリソースに対して認可されたとは認識されません。この場合、問題を指摘する明示的なエラー・メッセージは表示されません。かわりに、再度ログインするよう求められます。
認証に成功した後、ブラウザ・ウィンドウの「戻る」ボタンを押すと、access/oblix/apps/webgate/bin/webgate.soに対するエラーが表示されることがあります。
フォームベース認証を使用している場合、Oracle Access Managerにより、リクエストされたリソースに関する情報を保持するフォーム・ログインCookieが作成されます。認証に成功すると、Cookieの状態が変更されます。ユーザーが「戻る」ボタンをクリックすると、ログイン・フォームが表示されます。再ポストされると、フォーム・ログインCookieにはリダイレクトの詳細が含まれなくなります。
また、フォーム・ログインCookieと一緒にObSSOCookieも送信されます。ObSSOCookieは正しくチェックされます。フォーム・ログインCookieの状態が変更されているため、フォームベース認証は行われず、フォーム・アクションはリソースのリクエストとみなされます。
解決策
元のURLを使用して、リクエストを再試行してください。
Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。
その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。
WebLogic Serverを再起動できるようにするには
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ（または、起動権限を付与する必要があるその他のグループ）を作成します。
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
Adminロールの「構成の表示」を選択します。
グループを追加して「保存」をクリックします。
初期状態のOracle Access Managerでは、ロード・バランシングされるアクセス・ゲートはサポートされていません。かわりに、サード・パーティのロード・バランサを使用する必要があります。
WebGateAおよびWebGateBという2つのWebゲートがあるとします。OAMCfgToolを使用して、2つのWebゲートで共有されるプロファイルを作成できます。
Oracle Fusion Middlewareアプリケーションをインストール済の場合、OAMCfgToolはすでにインストールされています。この場合、手順1を省略します。
解決策:
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Fusion Middlewareアプリケーションがインストールされていない場合には、OAMCfgToolを入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Managerのコア・コンポーネント（10.1.4.3.0）を使用してOAMCfgTool ZIPファイルを見つけます。
oamcfgtool<version>.zip
oamcfgtool.jarを抽出し、Webゲートをホスティングしているコンピュータにコピーします。
WebGateAのコンピュータにログインします（Webゲートがまだインストールされていない場合も含む）。
OAMCfgToolが含まれているファイル・システム・ディレクトリに移動し、次のようなコマンドを実行して、2つのWebゲートによって共有される1つのアクセス・ゲート・プロファイルを作成します。次に例を示します。
java -jar oamcfgtool.jar mode=CREATE app_domain=SharedA_B app_agent_password=<WebGate_password> cookie_domain=<preferred_http_cookie_domain> ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin ldap_userpassword=<ldap_userpassword> oam_aaa_host=abcd oam_aaa_port=7789 oam_aaa_mode=cert log_file=OAMCfg_date.log log_level=INFO output_ldif_file=<LDIF_filename>
このツールで指定した情報を確認します。たとえば、手順3のパラメータと値は次のとおりです。
Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain : SharedA_B
Host Identifier: SharedA_B_WD
Access Gate ID : SharedA_B_AG
|
注意:
|
出力LDIFの作成: LDIFをインポートし、その情報をディレクトリ・サーバーに書き込みます。該当しない場合は、この手順を省略します。
Webゲートがインストールされていない場合: WebGateAとWebGateBをインストールし、プロファイルの作成時に指定した値と同じ値（および、インストールの完了に必要なその他の値）を指定します。
Webゲートがインストールされている場合: OAMCfgToolのCreateコマンド出力を使用してOracle Access ManagerのconfigureWebGateツールを実行し、Webゲートを設定します。次に例を示します。
次の場所に移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate
ここで、WebGate_install_dirは、Webゲートのインストール先ディレクトリです。
次のコマンドを実行し、OAMCfgToolで指定した値とインストールの完了に必要なその他の値を使用して、Webゲートを構成します。次に例を示します。
configureWebGate -i WebGate_install_dir -t WebGate SharedA_B_AG -P WebGate_password -m <open|simple|cert> -h Access_Server_Host_Name -p Access_Server_Port -a Access_Server_ID -r Access_Server_Pass_Phrase (must be the same as the WebGate_password) -Z Access_Server_Retry count
|
関連項目: Oracle Fusion Middleware Oracle Access Manager管理者ガイドのアクセス・ゲートおよびWebゲートの構成に関する項 |
前述の手順を繰り返して、WebGateBを構成します。
アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。
マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。次に例を示します。
http://hostname:port/access/oblix
hostnameはWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
「アクセス・システム構成」→「アクセス・ゲート構成」をクリックします。
「すべて」ボタンをクリックしてすべてのプロファイルを検索し（または、リストから検索属性と条件を選択し）、「実行」をクリックします。
Webゲートの名前をクリックして、その詳細を表示します。
「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、Oracle Fusion Middleware Oracle Access Manager管理者ガイドの説明に従って値を変更します。
ロード・バランサのホスト識別子に、両方のWebゲートのホスト名バリエーション（WebGateAおよびWebGateB）を追加します。
次のようなエラー・メッセージが表示されます。
401 Authorization Required
これは通常、Oracle Access Manager認証プロバイダが正しく構成されていないことを意味します。正しい構成のリストについては、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
次のようなエラー・メッセージが表示されます。
403 Forbiden
これは通常、ポリシー・ドメインで認証後のアクションが正しく構成されていないことを意味します。ポリシー・ドメインの認証成功アクションで、（「戻り値」フィールドではなく）「戻り属性」フィールドにobmygroupsとuidが設定されていることを確認してください。
詳細は、「Oracle Access Manager認証プロバイダのポリシー・ドメインの構成」を参照してください。
このエラーは通常、サーバーがリクエストURIに合致するものを見つけられなかったことを示します。このメッセージは、Oracle WebLogic Serverがリソースを見つけられないことを通知します。
状況が一時的であるか、永続的であるかどうかは示されません。
サーバーが一時的または永続的にクライアントに情報を提供できない場合、ステータス・コード403（Forbidden）が使用されることがあります。
内部的に構成できるなんらかのメカニズムによって、古いリソースが永続的に使用不可で、転送アドレスが存在しないことを通知できる場合は、410（Gone）ステータス・コードが使用されます。
エラー404からリカバリするには
リソースがOracle WebLogic Serverにデプロイされていることを確認します。たとえば、パターンが/private1/Helloである場合、ルートがprivate1のサーバー上でHelloにアクセスできるかどうかを確認します。
この問題は、Oracle Access Managerでフォーム認証スキームが適切に構成されていない場合に発生します。ただし、OAMCfgToolを使用してポリシー・ドメインを設定する場合、この問題は発生しません。次に例を示します。
次のような兆候があります。
ログイン・フォームの「ユーザー名」フィールドと「パスワード」フィールドが、フォーム認証スキームの詳細と合致している必要があります。
フォーム認証スキームで、credential_mappingフィルタが正しく指定されている必要があります。
ログイン・フォームのアクションURLがポリシーによって保護されている必要があります。
ログイン・フォームのアクションURLが、認証スキームのチャレンジ・パラメータに指定されたアクション値と合致している必要があります。
WebLogic ServerユーザーがOracle Access Managerの管理者グループに含まれていない場合、Oracle WebLogic Serverが再起動し、認証プロバイダの初期化に失敗する可能性があります。この場合、$DOMAIN_HOME/servers/AdminServer/logs/AdminServer.logのAdminServer.logに、次のいずれかのメッセージが表示されます。
)<Failed ---- FatalError:InvalidSchemeMapping ... Authentication Failed. ... Login failed. ...
解決策
実装で、Oracleが提供するデフォルト・ログイン・フォームが使用されていることを確認します。
Oracle Access Managerアイデンティティ・システムでAdministratorsという名前のグループを作成し、Oracle WebLogic Serverユーザーを含めます。
|
関連項目: 「Oracle Access Manager IDおよび共通管理ガイド」 |
Oracle Access Managerアイデンティティ・システム内で定義されたAdministratorsグループに属するユーザーの資格証明を使用して、Oracle WebLogic Serverにログインします。
Oracle WebLogic Serverを再起動します。
このフラグをREQUIREDに設定し、他のパラメータを不適切な値に設定した場合、サーバーは起動しません。
この問題を回避するには、このパラメータ値をOPTIONALに設定して、Oracle Access Manager認証プロバイダが適切に構成されていることを確認します。この方法で適切に動作することを確認した後にのみ、制御フラグをREQUIREDにリセットしてください。
詳細は、「WebLogicドメインでの認証プロバイダの構成」を参照してください。
この問題は通常、ユーザー名またはパスワードが正しくないことを示しています。エラーは表示されません。
正しいユーザー名とパスワードが入力されていることを確認してください。ユーザーのログイン名は、フォーム・ログイン認証スキームで構成された属性の値である必要があります。たとえば、チャレンジ・パラメータcreds: useridのようになります。
ユーザーがログアウトした場合、またはユーザーのセッションがタイムアウトした場合は、ユーザーは再認証を要求されます。ただし、次のことが発生する場合があります。
ログアウト: ログアウトした後、ユーザーが同じブラウザ・ウィンドウでアプリケーションにアクセスしようとすると、再認証なしでアプリケーションにアクセスできます。
セッション・タイムアウト: ユーザーがセッション・タイムアウトした後、再認証が要求されます。ただし、ユーザーが別のユーザーIDを入力した場合に、前のユーザーと同じ権限が付与されます。
ObSSOCookieがまだ存在しています。ObSSOCookieをクリアするには、いくつかの構成をアプリケーション・レベルで行う必要があります。適切に動作させるには、WebLogicアプリケーションのセッション・タイムアウト値とWebゲートのセッション・タイムアウト値を合致させる必要があります。
WebLogicアプリケーション・コンソールでIDアサーション・プロバイダを設定している場合、IDアサーション・プロバイダを使用するWebアプリケーションのauth-methodがCLIENT-CERTに設定されている必要があります。詳細は、「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」を参照してください。
リクエストされたURLまたはリソースがこのサーバーに見つからなかったことを示すメッセージが表示された場合、リバース・プロキシWebサーバーがリクエストをOracle WebLogic Serverに転送していない可能性があります。
リバース・プロキシがリクエストをOracle WebLogic Serverに転送していることを確認するには
リバース・プロキシWebゲートのWebサーバーで、httpd.confファイルを検索します。次に例を示します。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
Oracle WebLogic Serverの正しいホストとポートにリクエストが転送されるように、正しく設定されていることを確認します。
#httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost <host>
WebLogicPort yourWlsPortNumber
</IfModule>
<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>
Oracle WebLogic Serverの起動に失敗する場合、次の操作を実行できます。
Oracle Access Manager認証プロバイダが、Oracle WebLogic Serverレルムに構成されている唯一のプロバイダであるかどうかを確認します。そうである場合は、手順2に進みます。
Oracle Access Manager認証プロバイダが正しく構成されていることを確認し、必要に応じて変更します。
Oracle Access Manager認証プロバイダの制御フラグがREQUIREDに設定されているかどうかを確認します。設定されている場合は、次の手順を実行します。
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ（または、起動権限を付与する必要があるその他のグループ）を作成します。
|
注意: その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。 |
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「Your Realm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
管理者（またはその他の）ロールの「構成の表示」を選択します。
グループを追加して「保存」をクリックします。
問題
Microsoft Officeドキュメント（.xls、.docなど）をダウンロードできる特定のURLにアクセスしたときに、Webゲートのキャッシュ・ディレクティブの構成が特定のブラウザのバージョン（特にInternet Explorer v7）に対応していない可能性があります。
たとえば、Oracle Access Managerの証明書ベースの環境に、Oracle ADFアプリケーションと一緒にExcelワークブックがデプロイされているとします。
ADFDiコンポーネントが2つのURLにアクセスする際に、2番目のURLへのアクセスを先に試行すると、ADFDiのクライアント側のコードに関係なく失敗します。Oracle Access Manager WebゲートからSSL対応エンドポイントへのリダイレクトを処理できずに失敗し、次のスタック・トレースが生成されます。
WebException: The request was aborted: Could not create SSL/TLS secure channel
ワークブックにアクセスしようとすると、次のメッセージが表示されます。
Microsoft Office Excel cannot access the file
次の原因が考えられます。
ファイル名またはパスが存在しない。
ファイルが別のプログラムによって使用されている。
保存しようとしているワークブックと現在開いてるワークブックの名前が同じである。
ただし、ワークブックのURLをInternet Explorer v7のアドレス・バーに明示的に貼り付けたときにこのメッセージが表示された場合は、Webゲートのデフォルト・キャッシュ・ディレクティブが原因である可能性があります。
Webゲートには、デフォルト・キャッシュ・ディレクティブ（Pragma=no-cacheおよびCacheControl=no-cache）があります。これらは、Internet Explorer v7で.xlsワークブックのURLをブラウザのアドレス・バーに直接貼り付けた場合に問題を引き起こします。
解決策
ワークブックのURLをInternet Explorer v7のアドレス・バーに明示的に貼り付けたときにこのメッセージが表示された場合は、アクセス・システム・コンソールのWebゲート構成の各ページからキャッシュ・ディレクティブを削除することをお薦めします。
各Webゲート構成からキャッシュ・ディレクティブを削除するには
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
「アクセス・システム構成」をクリックし、検索ページの「実行」をクリックした後、該当するアクセス・ゲート構成ページへのリンクをクリックします。
「アクセス・ゲートの詳細」ページで、「変更」をクリックします。
「アクセス・ゲートの変更」ページで「Webサーバー・クライアント」ラベルを検索し、次のフィールドをクリアします。
CachePragmaHeader
CacheControlHeader
「保存」をクリックします。
アプリケーション・リソース（URL）へのアクセス時にJSESSIONID Cookieが見つからない場合、WebLogic Serverは、JSESSIONIDをURLの一部として含めることによりURLの再書込みを行います。対象のURLが保護されているときは、再書込みしたURLのマッチングが、Oracle Access ManagerとOSSO Webエージェントでは困難な場合があります。
Oracle Access Managerとの不一致を回避するには、URLをJSESSIONIDに一致させるポリシーを作成できます。たとえば、次のような保護されたURLがあるとします。
/myapp/login
適切なポリシー・ドメイン内でポリシーを作成して、URLをJSESSIONIDに一致させることができます。
再書込みされたURLの一致に関する問題を回避するには
ポリシー・マネージャに移動して、ログインします。次に例を示します。
http://Webserver:port/access/oblix
ここで、Webserverはポリシー・マネージャのWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システムに接続します。
「ポリシー・マネージャ」→「ポリシー・ドメイン」をクリックして、該当するポリシー・ドメインへのリンクをクリックします。
「ポリシー」タブ→「追加」をクリックします。
情報を入力し、「一般」の詳細を保存します。
名前: JSESSIONID Matching Policy。
リソース操作: 適用可能なすべてのHTTP操作を選択します。
リソース: コンテキスト・ルートを選択します（必要な場合は作成）。例: /myapp。
URLパターン: login。
「保存」をクリックします。
OracleAS Single Sign-Onソリューションは、Webアプリケーションへのシングル・サインオン・アクセスを提供します。Oracle Internet Directoryは、LDAPベースのリポジトリです。
このソリューションは、Oracle WebLogic Serverにデプロイされていて、シングル・サインオンがまだ実装されていないアプリケーションを対象としています。OSSOソリューションの構成に関する要件と手順については、「OSSO IDアサーション・プロバイダの新規ユーザー」を参照してください。
JPSログイン・モジュールを介してOracleAS Single Sign-Onソリューションを使用していて、OSSOにリクエストを動的にリダイレクトするアプリケーションは、新しいOSSOソリューションの影響を受けることはありません。この場合、この項の説明に従って新しいOSSO認証プロバイダを構成する必要はありません。
この項の内容は次のとおりです。
この項では、OracleAS Single Sign-On IDアサーション・プロバイダの実装時に想定される動作について説明します。この項の内容は次のとおりです。
図9-19は、OSSO IDアサーション・プロバイダを含む、Oracle WebLogicセキュリティ・フレームワーク内のコンポーネントの配置を示しています。詳細は、図の後に説明します。
図9-19 Oracle WebLogicセキュリティ・フレームワーク内のOSSOコンポーネントの配置
図の最上部に、Oracle HTTP Serverがインストールされています。このインストールにはmod_weblogicとmod_ossoが含まれています。これらは、アイデンティティ・トークンをプロバイダとOracle WebLogic Serverに渡すために必要になります。Oracle WebLogic Serverには、パートナ・アプリケーションとIDアサーション・プロバイダが含まれています。図の右側にある10g OracleAS Single Sign-Onサーバー（OSSO Server）は、ディレクトリ・サーバーおよびOracle HTTP Serverと直接通信します。
|
注意: 説明を簡潔にするために、この章では、Apache用WebLogic Serverプラグインの汎用名（mod_weblogic）を使用します。Oracle HTTP Serverの10gと11gでは、このプラグインが次の名前になります。
|
図9-20は、IDアサーション・プロバイダでOSSOを実装した場合に発生する処理を示しています。詳細は、図の後に説明します。
保護されたリソースに対するリクエストが初めて中間層のWebサーバーに到達すると、そのリクエストは、ユーザー資格証明を要求する10g OracleAS Single Sign-Onサーバーにリダイレクトされます。証明書ベースの認証の場合は、ログイン・ページは表示されません。ユーザーが正常に認証されると、そのユーザーによるすべての後続リクエストでは、JAASサブジェクトの移入前に、OSSO IDアサーション・プロバイダがユーザー・アイデンティティをアサートするだけで済みます。サブジェクトは、ダウンストリーム・アプリケーションによって使用されます。
たとえば、フロントエンドにOracle HTTP ServerがデプロイされているOracle WebLogic Serverにアプリケーションが存在するとします。このアプリケーションは、mod_osso構成のリソース・マッピングを使用して保護されます。これについては、次のプロセス概要で説明します。
ユーザーが保護されたアプリケーションをリクエストします。
Oracle HTTP Serverはリクエストをインターセプトし、mod_ossoを使用してリクエストを処理して、既存の有効なOracle HTTP Server Cookieがあるかどうかをチェックします。
有効なOracle HTTP Server Cookieがない場合、mod_ossoはOracleAS SSO Serverにリダイレクトし、SSO Serverは認証中にディレクトリと通信します。
正常に認証されると、mod_ossoはOSSOサーバーによって移入された暗号化済のユーザー・アイデンティティを復号化し、ヘッダーにユーザー属性を設定します。
mod_weblogicが後続処理を完了し、リクエストをOracle WebLogic Serverにリダイレクトします。
WebLogicセキュリティ・レイヤーにより、設定と指定された順序に従ってプロバイダが呼び出されます。たとえば、セキュリティ・レイヤーによって次のものが呼び出されます。
Oracle HTTP Serverを介してレスポンスがユーザーに送信され、アプリケーションへのアクセスが許可されます。
この項では、Oracle HTTP Serverによって送信されるヘッダーとヘッダーに設定されるトークン、およびOSSO IDアサーション・プロバイダが使用するヘッダーについて説明します。アプリケーションでJAASサブジェクトを使用する必要がある場合は、OSSO IDアサーション・プロバイダを構成してください。
表 9-14は、Oracle HTTP Serverによって設定されるヘッダー（mod_ossoおよびmod_weblogic）のリストを示しています。アプリケーション・ロジックで、ユーザー情報の識別にJAASサブジェクトを使用するアプリケーションは、OSSO IDアサーション・プロバイダを使用するよう構成されている必要があります。OSSO IDアサーション・プロバイダは、表内の太字で示されているOracleAS SSOトークン・タイプ（Proxy-Remote-User）を使用します。OSSO IDアサーション・プロバイダはProxy-Remote-Userヘッダーを検索し、ユーザーのアイデンティティをアサートします。その後、OID認証プロバイダがJAASサブジェクトを移入します。
表 9-14 Oracle HTTP Serverによって送信されるヘッダー
| 属性 | サンプル値 | 説明 |
|---|---|---|
|
Cookie |
OHS-Stads42.us.oracle.com:7777=....... |
Cookie |
|
Osso-User-Guid |
4F4E3D2BF4BFE250E040548CE9816D7E |
認証されたユーザーのGUID |
|
Osso-User-Dn |
cn=orcladmin,cn=users, dc=us,dc=oracle,dc=com |
認証されたユーザーのDN |
|
Osso-Subscriber |
DEFAULT COMPANY |
サブスクライバ名 |
|
Osso-Subscriber-Dn |
dc=us,dc=oracle,dc=com |
サブスクライバのベースDN |
|
Osso-Subscriber-Guid |
4F4E3D2BF410E250E040548CE9816D7E |
サブスクライバのGUID |
|
Proxy-Remote-User |
ORCLADMIN |
認証されたユーザー |
|
Proxy-Auth-Type |
Basic SSO |
認証タイプ |
ユーザー情報の識別にJAASサブジェクトを必要としないアプリケーションは、request.getHeader() APIを使用してヘッダーを直接読み取ることができます。このようなアプリケーションは、必要なヘッダーを自由に読み取ることができます。ユーザー情報を含むヘッダーは、Osso-User-Dn、Osso-User-GuidおよびProxy-Remote-Userです。
新しいOracleAS Single Sign-Onソリューションでは、OSSO IDアサーション・プロバイダが提供されています。これは、Oracle WebLogic Serverで使用可能な2つの新しい認証プロバイダの1つです。
アプリケーションでOSSOソリューションを使用するには、次のタスクで説明されているコンポーネントが必要です。
|
注意: コンポーネントがすでにインストールおよび設定されている場合、新しいコンポーネントは必要ありません。デプロイメントに該当しない手順は省略できます。 |
タスクの概要: OSSO IDアサーション・プロバイダのデプロイおよび構成
次のコンポーネントをインストールします。
OracleAS Single Sign-On Server 10g（10g OSSO Server）
|
関連項目: Oracle Technology NetworkにあるOracle Application Serverのインストレーション・ガイド（http://www.oracle.com/technology/documentation/oim1014.html） |
10g OSSO Serverで使用するように構成されたOracle Internet Directory。ディレクトリ・サーバーがデプロイメント用に調整されていることを確認してください。
|
関連項目: 次のリリース11g（11.1.1.1.0）のマニュアル
|
次のWebサーバーのいずれか1つ（Apache 2に基づく）。
Oracle WebLogic ServerのフロントエンドとしてのOracle HTTP Server 11g。このインストールには、mod_ossoとmod_weblogicが含まれています。
リリース10.1.3のOracle HTTP ServerのCompanion CDに含まれているOHS 10g。これには、mod_ossoが含まれています。ただし、mod_weblogicを追加する必要があります。
|
関連項目: 次のリリース11g（11.1.1.1.0）のマニュアル
|
Oracle WebLogic Server 10.3.1以降
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』 |
Oracle Identity Management、Oracle SOA Suite、Oracle WebCenterなどのOracle Fusion Middleware製品が必要です。該当する製品の次のパスに、Oracle WebLogic ServerによるOSSOのために必要なプロバイダが含まれています。
ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
|
関連項目:
|
「mod_weblogicの構成」の説明に従って、Oracle WebLogic Serverにリクエストを転送するようにmod_weblogicを構成します。
「OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録」の説明に従って、モジュールmod_ossoをパートナ・アプリケーションとして10g SSO Serverに登録します。
「Webリソースを保護するためのmod_ossoの構成」の説明に従って、mod_ossoを構成します。
「OSSO用WebLogicドメインへのプロバイダの追加」の説明に従って、OSSO IDアサーション・プロバイダを適切なドメインに追加します。
「Oracle WebLogic Serverとその他のエンティティの間の信頼の確立」の説明に従って、接続フィルタを構成します。
「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明に従って、アプリケーションによるソリューションの使用を構成します。
「OSSO IDアサーション・プロバイダのデプロイメントのトラブルシューティング」を参照して、OSSO IDアサーション・プロバイダの実装に関する問題を特定して解決します。
Oracle HTTP Serverのhttpd.confファイルを直接編集するか、別のファイルにmod_weblogic構成を追加して、そのファイルをhttpd.confに含めることができます。
次に、2つの異なるWebサーバー・リリース向けの手順について説明します。デプロイメントに応じて、必要な手順を実行してください。
OHS 11gにはmod_wl_ohs.soが含まれています。この場合、手順1を省略します。
OHS 10gには、mod_weblogic（mod_wl_.so）が含まれていません。Oracle HTTP Server 10gがインストールされている場合、手順1から開始して、構成を行う前に、mod_wl_20.soをコピーしてください。
|
注意: Oracle HTTP Serverの10gと11gでは、このプラグインが次の名前になります。
|
mod_weblogicをインストールして構成するには
Oracle HTTP Server 10.1.3: 次の例のように、mod_wl_20.soをOracle HTTP Serverモジュール・ディレクトリにコピーします。
コピー元: WL_HOME/wlserver_10.0/server/plugin/linux/i686
コピー先: ORACLE_HOME/ohs/modules
Oracle HTTP Serverのhttpd.confファイルを見つけます。次に例を示します。
Oracle HTTP Server 10.1.3:
ORACLE_HOME/ohs/conf/httpd.conf
Oracle HTTP Server 11g:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
適切な構成ファイルを含めるか、構成自体を直接含めて、mod_weblogic構成がhttpd.confに含まれていることを確認します。たとえば、Oracle HTTP Server 10gの場合は次のようにします。
LoadModule weblogic_module ${ORACLE_INSTANCE}/ohs/modules/mod_wl_20.so
<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>
<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>
mod_ossoモジュールは、OracleASアプリケーションへの認証を提供するOracle HTTP Serverモジュールです。このモジュールはOracle HTTP Server上に存在します。これにより、ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onによって保護されているアプリケーションが、ユーザー名とパスワードのかわりにHTTPヘッダーを受け入れるようになります。これらのヘッダーの値は、mod_osso Cookieに格納されます。
mod_ossoモジュールは着信リクエストを調べて、リクエストされたリソースが保護されているかどうかを特定することにより、Oracle HTTP Serverに対するシングル・サインオンを可能にします。保護されている場合、Oracle HTTP Server Cookieが取得されます。
状況によっては、10.1.4のOracle Identity Managerのシングル・サインオン登録ツール（ssoreg.shまたはssoreg.bat）を使用して、Oracle HTTP Serverのmod_ossoを登録する必要があります。表9-15は、このために使用するパラメータと値の概要を示しています。登録ツールを実行すると、osso.confファイル内のmod_osso登録レコードが更新されます。このツールを実行するたびに、このファイルが生成されます。
表9-15 Oracle HTTP Serverのmod_ossoを登録するためのssoregパラメータ
| パラメータ | 説明 |
|---|---|
|
-oracle_home_path |
10.1.4 SSO Oracle_Homeのパス。 |
|
-site_name |
対象となる任意のサイト名。 |
|
-config_mod_osso |
TRUE。TRUEに設定すると、このパラメータは、登録中のアプリケーションがmod_ossoであることを示します。osso.confを生成するには、config_mod_ossoを含める必要があります。 |
|
-mod_osso_url |
フロンドエンドOracle HTTP Serverのホスト:ポートのURL。これは、パートナ・アプリケーションへのアクセスに使用されるURLです。値は、URL形式（http://oracle_http_host.domain:port）で指定する必要があります。 |
|
-update_mode |
オプション。デフォルト値のCREATEでは、新しいレコードが生成されます。 |
|
-remote_midtier |
登録するmod_ossoパートナ・アプリケーションがリモート中間層にあることを指定します。このオプションは、構成するmod_ossoパートナ・アプリケーションが別のORACLE_HOMEに存在し、OracleAS Single Sign-Onサーバーが現在のORACLE_HOMEでローカルに実行されている場合にのみ使用してください。 |
|
-config_file |
osso.confが生成されるパス。 |
|
[-admin_info |
オプション。mod_osso管理者のユーザー名。このパラメータを省略すると、「パートナ・アプリケーションの編集」ページの「管理者情報」フィールドが空白になります。 |
|
admin_id |
オプション。電子メール・アドレスや管理者などに関する追加情報。このパラメータを省略すると、「パートナ・アプリケーションの編集」ページの「管理者の電子メール」フィールドが空白になります。 |
|
<VirtualHost ...> |
ホスト名。オプションです。このパラメータは、Oracle HTTP仮想ホストをシングル・サインオン・サーバーに登録している場合にのみ指定してください。仮想ホストを登録していない場合、このパラメータは省略します。 HTTP仮想ホストを作成している場合、httpd.confファイルを使用して、保護された各URLに対するディレクティブを入力します。 |
|
関連項目: Oracle Technology Networkにある（http://www.oracle.com/technology/documentation/oim1014.html）次のマニュアル
|
次の手順には、mod_ossoを登録するためのサンプル・コマンドが記載されています。その値は、使用する環境によって異なります。
mod_ossoを登録するには
次の10.1.4のOracle Identity Managerディレクトリのパスに移動します。
ORACLE_HOME/sso/bin/ssoreg
環境に応じて、次のパラメータと値を指定してssoregを実行します。たとえば、Unixでは、次のようになります。
./ssoreg.sh -oracle_home_path \OraHome -site_name wls_server -config_mod_osso TRUE -mod_osso_url http://oracle_http_host.domain:7788 -update_mode CREATE -remote_midtier -config_file \tmp\osso.conf
必要なOracle HTTP Serverのモジュールmod_ossoが登録されていることを確認します。
mod_ossoは、リクエストしたURLが保護されるよう構成されている場合にのみ、ユーザーをシングル・サインオン・サーバーにリダイレクトします。URLは、静的または動的に保護できます。静的ディレクティブは、ユーザー操作からmod_ossoに制御を渡すことでアプリケーションを保護します。動的ディレクティブは、アプリケーションを保護するだけでなく、アプリケーションによるユーザー・アクセスの規制も可能にします。
詳細は、次の各項を参照してください。
mod_osso.confファイルにディレクティブを適用することにより、mod_ossoを使用してURLを静的に保護できます。リクエストが適切にインターセプトされるように、mod_ossoを構成する必要があります。さらに、保護されるURIの場所、タイムアウト時間および認証方式を指定します。httpd.confファイルにおけるweblogic_module文のロード箇所より前に、mod_osso.confのinclude文を配置することをお薦めします。
次の手順では、mod_osso.confファイルを編集してmod_ossoを構成する方法について説明します。この手順には、2つの異なるリリース向けの詳細が示されています。OHSデプロイメントの指示に従ってください。
Oracle HTTP Server 11g: 手順2と手順4のAuthType Ossoが必要です。手順5のパス名は、Oracle HTTP Server 11gでは異なります。
Oracle HTTP Server 10g: 手順3と手順4のAuthType Basicが必要です。手順5のパス名は、Oracle HTTP Server 10gでは異なります。
Webリソースを保護するためにmod_ossoを構成するには
osso.confを生成場所から次の場所にコピーします。
コピー元: /tmp/osso.conf
コピー先:
ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
Oracle HTTP Server 11g: 編集するために、mod_osso.confを無効なディレクトリからmoduleconfディレクトリにコピーします。次に例を示します。
コピー元:
ORACLE_INSTANCE/config/OHS/<ohs_name>/disabled/mod_osso.conf
コピー先:
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
Oracle HTTP Server 10g: 編集するために、mod_osso.confを見つけます。次に例を示します。
ORACLE_HOME/ohs/conf/mod_osso.conf
mod_osso.confを編集して、デプロイメントに応じた値を使用して次の情報を追加します。ここでは、例としてOracle HTTP Serverを使用します（10gの場合はパスが異なる）。
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
#Location is the URI you want to protect
<Location />
require valid-user
#OHS 11g AuthType Osso
#OHS 10g AuthType Basic
AuthType Osso
</Location>
</IfModule>
編集するために、httpd.confファイルを見つけます。次に例を示します。
Oracle HTTP Server 10.1.3:
ORACLE_HOME/ohs/config/httpd.conf
Oracle HTTP Server 11g:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
httpd.confで、環境に応じたmod_osso.confファイルのパスが含まれていることを確認します。次に例を示します。
include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
Oracle HTTP Serverを再起動します。
|
ヒント: リクエストのインターセプトが正常に機能しない場合、httpd.conf内でLoadModule weblogic_module文の前にmod_osso.confのinclude文を配置してください。 |
動的ディレクティブを使用するアプリケーションでは、mod_ossoによる保護が1つ以上の動的ディレクティブとして直接アプリケーションに書き込まれるため、mod_osso.confへの入力は必要ありません。
動的ディレクティブは、特殊なエラー・コードを含むHTTPレスポンス・ヘッダーです。これにより、アプリケーションは複雑なシングル・サインオン・プロトコルを実装することなく、シングル・サインオン・システムから詳細な機能をリクエストできます。アプリケーションからシンプルなHTTPレスポンスの一部としてディレクティブを受け取ると、mod_ossoは適切なシングル・サインオン・プロトコル・メッセージを作成し、それをシングル・サインオン・サーバーに通信します。
OracleASでは、JavaサーブレットおよびJSP向けの動的ディレクティブがサポートされています。現時点では、PL/SQLアプリケーション向けの動的ディレクティブはサポートされていません。次のJSPは、このようなディレクティブの組込み方法を示しています。対応する静的アプリケーションと同様、これらの動的サンプル・アプリケーションではユーザー情報が生成されます。
例9-2 動的ディレクティブによるSSO認証
home.jspには、request.getUserPrincipal().getName()メソッドを使用してセッション内のユーザーをチェックするssodynauth.jspが含まれています。ユーザーが存在しない場合、動的ディレクティブ499（簡易認証のリクエスト）が発行されます。重要な行は太字で示されています。
//home.jsp <%@ include file="ssodynauth.jsp" %> <% //page content goes here %> //ssodynauth.jsp <% response.setHeader("Cache-Control", "no-cache"); response.setHeader("Pragma", "no-cache"); response.setHeader("Expires", "0"); %> <% // Check for user String ssoUser = null; try ( //ssoUser = request.getRemoteUser(); ssoUser = request.getUserPrincipal( ).getName( ); ssoUser = ssoUser.trim( ); } catch(Exception e) { ssoUser = null; } // If user is not authenticated then generate // dynamic directive for authentication if((ssoUser == null) || (ssoUser.length() < 1)) { response.sendError(499, "Oracle SSO"); return; }%>
|
関連項目: Oracle Technology Networkの『Oracle Identity Managementアプリケーション開発者ガイド』（http://www.oracle.com/technology/software/products/ias/htdocs/101401.html） |
例9-3 動的ディレクティブによるSSOログアウト
グローバル・ログアウト（シングル・ログアウトとも呼ばれる）を実現するには、アプリケーションによってセッションが無効化された後にOSSOログアウトがコールされる必要があります。logout.jspにより、動的ディレクティブ470（OSSOログアウトのリクエスト）が発行されます。ログアウト後の戻りURLを指定するために、アプリケーションによってosso-return-logoutが設定されます。
動的ディレクティブによるSSOログアウトの重要な行は、次の例で太字で示されています。11gでは、SSOFilterによってセッション同期が処理されます。
//logout.jsp
<%@page session="false"%>
<%
response.setHeader("Osso-Return-Url", "http://my.oracle.com/");
HttpSession session = null;
session = request.getSession();
if (null != session )
{
// necessary for achieving SLO
session.invalidate();
}
response.sendError(470, "Oracle SSO");
%>
|
関連項目:
|
OSSO IDアサーション・プロバイダをWebLogicドメインに追加する必要があります。OSSO IDアサーション・プロバイダに加えて、次の認証プロバイダをお薦めします。
これらのプロバイダは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool（WLST）コマンドライン・ツールを使用して追加できます。
|
関連項目:
|
次の手順では、Oracle WebLogic管理コンソールを使用して認証プロバイダを追加する方法を示します。開始する前に、次の条件に注意してください。
手順10: アプリケーションでOracle Internet Directoryユーザーと大/小文字が一致しているユーザー（大文字、小文字、先頭大文字）が要求される場合は、「取得したユーザー名をプリンシパルとして使用する」を選択します。要求されない場合は、選択しないでください。
OSSO IDアサーション用のWebLogicドメインにプロバイダを追加するには
WebLogic管理コンソールにログインします。
OSSO IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
デフォルト認証プロバイダ:
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「デフォルト認証プロバイダ」をクリックします。
制御フラグをOPTIONALに設定し、「保存」をクリックします。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして、名前とタイプを入力します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
「保存」をクリックします。
新しく追加された認証プロバイダをクリックして、「設定」ページを表示します。デフォルト設定を保持します。Oracle Internet Directory構成が有効であることを確認するまで、制御フラグを変更しないでください。
|
注意: OID認証プロバイダが唯一のプロバイダである場合、WebLogic Serverのユーザー・アカウントとそのアカウントに付与されたグループ・メンバーシップがOracle Internet Directoryで作成されていることを確認してください。作成されていない場合、WebLogicドメインは正常に開始されません。 |
「プロバイダ固有」タブをクリックして、次の必要な設定を指定します。
ログイン例外の原因を伝播: 選択。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
ホスト: Oracle Internet Directoryのホスト名。
取得したユーザー名をプリンシパルとして使用する: 選択。
資格証明: LDAPの管理ユーザー・パスワード。例: password。
資格証明の確認: 例: password。
グループ・ベースDN: Oracle Internet Directoryのグループ検索ベース。
ユーザー・ベースDN: Oracle Internet Directoryのユーザー検索ベース。
ポート: Oracle Internet Directoryのポート。
プロバイダの並べ替え: プロバイダによってサブジェクトにプリンシパルが移入される順序は重要であり、レルム内のすべてのプロバイダのリストを並べ替えて、新しく追加されたプロバイダをリストの先頭に移動できます。
すべての構成設定を保存します。
変更を有効にするために、Oracle WebLogic Serverを停止してから再起動します。
WebLogic管理コンソールにログインします。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「ユーザーとグループ」タブを選択して、構成された認証プロバイダに含まれているユーザーとグループのリストを確認します。
Oracle Internet Directory構成のユーザー名が表示されます。これは、この構成が機能していることを暗黙的に表しています。
- Oracle Internet Directoryインスタンスが正常に構成されている場合、制御フラグを変更できます。
- Oracle Internet Directory認証のみでアプリケーションのユーザーを識別できる場合、SUFFICIENTフラグを選択します。SUFFICIENTは、ユーザーがOracle Internet Directoryに対して認証された場合、その他の認証は処理されないことを意味します。REQUIREDは、別のプロバイダによってユーザーがすでに認証されている場合でも、認証プロバイダによって正常に認証される必要があることを意味します。
アプリケーションでOracle Internet Directoryユーザーと大/小文字が一致しているユーザーが要求される場合: 「取得したユーザー名をプリンシパルとして使用する」を選択します。要求されない場合は、選択しないでください。
変更を保存します。
変更をアクティブ化して、Oracle WebLogic Serverを再起動します。
Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。
|
注意: この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。WebLogic管理コンソールで。 |
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。このフィルタを使用すると、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。ネットワーク接続フィルタは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。
接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。
targetAddress localAddress localPort action protocols
|
関連項目: 『Oracle Fusion Middleware Securing Oracle WebLogic Server』のWebLogicドメインのセキュリティの構成に関する項 |
表9-16は、接続フィルタの各パラメータを説明しています。
表9-16 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
target |
フィルタ対象の1つ以上のシステムを指定します。 |
|
localAddress |
WebLogic Serverインスタンスのホスト・アドレスを定義します（アスタリスク（*）を指定すると、すべてのローカルIPアドレスが返される）。 |
|
localPort |
WebLogic Serverインスタンスのリスニング・ポートを定義します（アスタリスク（*）を指定すると、サーバー上のすべての使用可能なポートが返される）。 |
|
action |
実行するアクションを指定します。この値は、allowまたはdenyである必要があります。 |
|
protocols |
フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。 |
「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。
11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」の下の「ドメイン」をクリックします。
「セキュリティ」タブ→「フィルタ」タブをクリックします。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
この項では、OSSO IDアサーション・プロバイダ用のアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle WebLogic Serverは、複数のauth-methodsの追加をサポートしています。WebLogicアプリケーション・コンソールでOSSO IDアサーション・プロバイダを設定している場合、OSSO IDアサーション・プロバイダを使用するWebアプリケーションのauth-methodがCLIENT-CERTに設定されている必要があります。
Oracle WebLogic Serverにアプリケーションをデプロイした後、次の手順で説明されているように、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素にCLIENT-CERTが含まれている必要があります。
OSSO IDアサーション・プロバイダ用にweb.xmlを編集するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。次に例を示します。
WEB-INF/web.xml
該当するレルムのauth-methodを検索し、CLIENT-CERTと入力します。次に例を示します。
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myRealm</realm-name>
</login-config>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
この項で説明するトラブルシューティング項目は、次のカテゴリに分かれています。
|
関連項目:
|
この項では、次のトラブルシューティング項目について説明します。
OHSがSSOにリダイレクトしない - 内部サーバー・エラー500
この問題の原因として可能性が高いのは、不適切な構成です。
次のサンプルでは、Oracle HTTP Server 11gを使用しています。Oracle HTTP Server 10gを使用している場合は、パス名が異なります。
それに対処する手順は、次のとおりです。
ファイルmod_osso.confを開き、リソースが保護されていることを確認します。次に例を示します。
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
<Location /protected-resource-uri> require valid-user AuthType Basic </Location>
osso.confが存在しており、mod_osso.confに組み込まれていることを確認します。ここでは、例としてOracle HTTP Server 11gを使用します（10gの場合はパスが異なる）。
OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
|
注意: osso.confの場所は特に設定されていません。値は登録時に決定され、任意の絶対パスになります。 |
httpd.confに、mod_osso.confが組み込まれていることを確認します。ここでは、例としてOracle HTTP Server 11gを使用します（10gの場合はパスが異なる）。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
前述の設定をすべて適切に指定してもSSOの登録が正常に完了しない場合、SSOの再登録が必要になります。
SSOを登録するには、プラットフォームに適したssoregツールを使用して次の手順を実行します。次に例を示します。
10.1.4のORACLE_HOME/sso/binにあるssoreg.shを実行し、ファイルosso.confを作成します。次に、ファイル/tmp/osso.confを作成するこのユーティリティの使用例を示します（例示のためにのみ、引数を別の行に記述している）。
>ssoreg.sh -oracle_home_path /OraHome
-site_name wls_server
-config_mod_osso TRUE
-mod_osso_url http://host.domain.com:6666
-update_mode CREATE
-remote_midtier
-config_file /tmp/osso.conf
生成されたosso.confを、別のファイル・システム・ディレクトリにコピーします。例: ORACLE_INSTANCE/config/OHS/<ohs_name>/osso。
OHSを再起動します。
属性AuthNameは必要か
ログ・メッセージは、属性AuthNameが必要なことを示している場合があり、特定のバージョンのApacheにはこの属性が必要です。
この例では、Oracle HTTP Server 11gを使用しています。Oracle HTTP Server 10gを使用している場合は、パス名が異なります。
この属性を組み込むには、ファイルmod_osso.confを編集し、次の断片を挿入します。
LoadModule osso_module modules/mod_osso.so <IfModule mod_osso.c> OssoIdleTimeout off OssoIpCheck on OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf <Location /> AuthName "Oracle Single Sign On" require valid-user AuthType Basic </Location> </IfModule>
URLリクエストがSSOにリダイレクトされない
URLリクエストを発行したとき、SSOにリダイレクトされるかわりに基本ポップアップが表示される場合は、URLリクエストがApache認証モジュールにインターセプトされた可能性が高いです。
この問題に対処する方法は、次のとおりです。
ファイルhttpd.confを編集し、次の断片に示すように、認可モジュールのロードをコメント・アウトします。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
LoadModule access_module modules/mod_access.so #LoadModule auth_module modules/mod_auth.so #LoadModule auth_anon_module modules/mod_auth_anon.so #LoadModule auth_db_module modules/mod_auth_dbm.so LoadModule proxy_module modules/mod_proxy.so
OHSを再起動します。
エラー404 - 「見つかりません」が発行される（OHS側）
このエラーは通常、次の形式です。
The requested URL <request-uri> was not found on this server
WebLogicリダイレクトが実行されておらず、リクエストが、使用できないOHSリソースを使用しようとしている可能性が高いです。
この問題に対処するには、次の断片に示すようにmod_weblogicがファイルhttpd.confに組み込まれていることと、WebLogicハンドラがリクエスト・パターンに対して設定されていることを確認します。
#httpd.conf <IfModule mod_weblogic.c> WebLogicHost <host> WebLogicPort yourWlsPortNumber </IfModule> <Location /request-uri-pattern> SetHandler weblogic-handler </Location>
エラー404 - 「見つかりません」が発行される（Oracle WebLogic Server側）
このエラーは通常、次の形式です。
Error 404--Not Found
原因
このメッセージは、Oracle WebLogic Serverがリソースを見つけられないことを通知します。
解決策
この問題に対処するには、リソースがサーバーにデプロイされていることを確認します。たとえば、パターンが/private1/Helloである場合、ルートがprivate1であるサーバー上でHelloにアクセスできるかどうかを確認します。
Oracle SSOの失敗 - リクエストを処理できません
問題
次のようなメッセージを受信します。
Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or Oracle HTTP Server single sign-on is incorrectly configured. Please notify your administrator.
解決策
Oracle HTTP Server httpd.confファイルを変更し、ServerNameにポート番号を追加してWebサーバーを再起動します。次に例を示します。
変更前: ServerName host.domain.com
変更後: ServerName host.domain.com:port
スタンドアロンのWebLogic Serverにデプロイされたアプリケーション用のOSSOソリューション
この章では、Oracle Fusion Middleware Oracle WebLogic Serverにデプロイされたアプリケーションのシングル・サインオン（SSO）の構成方法を説明しています。一方、（Fusion Middlewareが組み込まれていない）スタンドアロンのOracle WebLogic Serverにデプロイされたアプリケーションの詳細は次のとおりです。
OSSOでのOracle Fusion Middleware: 必須OSSO IDアサーション・プロバイダ（ossoiap.jar）は、Oracle Fusion MiddlewareのOracle Identity Management、Oracle SOA SuiteまたはOracle WebCenterのインストール時に自動的に設定されます。
|
注意: OSSOでのOracle Fusion Middlewareにより、Oracle HTTP Server 10gまたは11g Webサーバーのどちらでも使用できます。 |
OSSOでのスタンドアロンOracle WebLogic Server: 必須OSSO IDアサーション・プロバイダ（ossoiap.jar）を、ここで説明したように、Oracle Web層から入手する必要があります。
|
注意: Fusion Middlewareがない場合には、OSSOにはOracle HTTP Server 11gが必要です。 |
OSSOをOracle Fusion Middlewareアプリケーションで使用しても、他のアプリケーションで使用しても、IDアサーション・プロバイダは「OSSO IDアサーション・プロバイダの使用」の説明にある同じ機能を実行します。
以下に記載されているのは、セッションを無効するためのシングル・ログアウトおよびSSO CookieとJSESSIONID Cookieの間の同期を構成してテストする際に使用できる、追加事項、オプション、詳細などです。必須のファイルはOracle Web層から入手する必要があります。
タスクの概要: スタンドアロンのWebLogic Server上のアプリケーションで使用するOSSO IDアサーション･プロバイダのデプロイおよび構成
Oracle WebLogic Server 10.3.1以降とその他の必須コンポーネントを次のとおりインストールします。
「タスクの概要: スタンドアロンのWebLogic Server上のアプリケーション用OSSO IDアサーション・プロバイダのデプロイおよび構成」の説明にある手順1のa〜dを実行します。
手順1eを省略して、使用するアプリケーションをかわりにデプロイします。
webloginドメイン拡張テンプレートを使用してWebLogicセキュリティ・ドメインを作成します。この拡張テンプレートは、Oracle WebLogic Serverに付属しており、$WLS_HOME/common/bin/config.shから使用できます。
「mod_weblogicの構成」の説明に従って、Oracle WebLogic Serverにリクエストを転送するようにmod_weblogicを構成します。
「OSSO IDアサーション・プロバイダの新規ユーザー」の説明に従って、モジュールmod_ossoをパートナ・アプリケーションとして10g SSO Serverに登録して構成します。
「OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録」で説明されている手順を実行します。
「Webリソースを保護するためのmod_ossoの構成」で説明されている手順を実行します。
認証プロバイダを、次のように適切なセキュリティ・ドメインに追加します。
OSSO IDアサーション・プロバイダ（ossoiap.jar）を次のOracle Web層から入手します。
$ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
ossoiap.jarを$WLS_HOME/wlserver_10.x/server/lib/mbeantypeにコピーし、Oracle WebLogic Serverを再起動します。
「OSSO用WebLogicドメインへのプロバイダの追加」の説明に従って、プロバイダを構成します。
「Oracle WebLogic Serverとその他のエンティティ間の信頼の確立」の説明に従って、Oracle WebLogicの接続フィルタ・メカニズムを構成し、アクセス制御リストを作成して、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストからのリクエストを受け入れます。
|
注意: Oracle WebLogic Serverのホストとポートを使用し、保護されたアプリケーションをテストして、デフォルトの認証プロバイダでそのアプリケーションが機能していることを確認します。 |
「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明に従って、OSSO IDアサーション・プロバイダ用のアプリケーション認証メソッドを構成します（アプリケーションEARファイル内のすべてのweb.xmlファイルで、要素auth-methodにCLIENT-CERTが含まれている必要があります）。
|
注意: Oracle HTTP Serverのホストとポートを使用してアプリケーションにアクセスする際に、OSSOが認証したユーザーを使用してアプリケーションをテストします。 |
オプション: 次のように、シングル・ログアウト（セッション無効化およびSSO CookieとJSESSIONID Cookieとの同期）を構成およびテストできます。
次のとおり、ssofilter.jarを入手し、それを使用できるようにOracle WebLogic Serverを構成します。
1. ssofilter.jarを次のOracle Web層から入手します。
$ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar
2. それをOracle Middlewareホームの適切なディレクトリにコピーします（例: WLS_INSTALL/Oracle/Middleware/modules）。
3. Oracle WebLogic Serverのクラスパスにssofilter.jarの絶対パスを追加します（setDomainEnv.shスクリプトのPOST_CLASSPATH変数またはCLASSPATH変数を編集します）。
次のように、system-filters.warをシステム・フィルタとしてデプロイします。
1. system-filters.warを次のOracle Web層から入手します。
$ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war
2. system-filters.warをOracle Middlewareホームの適切なディレクトリにコピーします（例: WLS_INSTALL/Oracle/Middleware/modules directory）。
3. system-filters.warをアプリケーション・ライブラリとしてデプロイします。WebLogic管理コンソールから、「デプロイ」をクリックして、「新規」を選択してファイルの場所を選択します。
4. プロンプトが表示されたら、Oracle WebLogic Serverを再起動します。
次のようにログを有効化してSSOFilterが機能していることを確認します。
1. WebLogic管理コンソールから、「ドメイン」→「環境」→「サーバー」→「管理サーバー」をクリックします。
2. 「ロギング」タブをクリックします。
3. 「詳細」ドロップダウンで、「デバッグ」として「ログの最低の重大度」を選択します。
4. 「詳細」ドロップダウンで「メッセージの宛先」を選択し、「デバッグ」として「ログ・ファイル: 重大度」を選択します。
5. 変更内容を保存して、Oracle WebLogic Serverを再起動します。
SSOFilterがシステム・フィルタとしてロードされていることを確認します。
1. DomainHome/Servers/AdminServer/log/AdminServer.logファイルを開きます。
2. 「SSOFilter」を検索して、<Debug>メッセージが表示されることを確認します。このメッセージは、SSOFilterの初期化を示し、フィルタのロードを確認するものです。
フィルタの機能をテストして、SSO CookieおよびJSESSIONID Cookieがユーザのログアウト後にクリーンアップされ、ログアウト後のアプリケーションへのアクセス試行では、再度ログインする必要があることを確認します。
|
注意: OSSO IDアサーション・プロバイダがWebLogicセキュリティ・ドメインで構成されるようにする必要があります。そうしないと、フィルタの初期化実行中にフィルタが自動的に無効になります。 |
アプリケーションでログアウトのテストをして、セッションが正確に終了していることを確認します。
「常に監査するユーザー」で指定したSSOユーザーに対する大文字指定
Oracle HTTP Serverの監査の構成にある「常に監査するユーザー」セクションでSSOユーザーを指定する場合、SSOユーザー名を大文字で指定する必要があります。
カンマ区切りのリストで複数のユーザーを指定して、これらのユーザーが開始した監査イベントにこの監査フレームワークが適用されるようにすることができます。監査は、指定された監査レベルやフィルタとは関係なく行われます。これは、あらゆるタイプの認証に当てはまります。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査ポリシーの管理」の章で監査の構成と管理に関する項を参照してください。
この項では、次のトラブルシューティング項目について説明します。
エラー403 - 禁止
このメッセージは、ユーザーがリソースにアクセスするために必要なパーミッションを持っていないことを通知します。このメッセージは、たとえば、アプリケーションがWLSグループSSOUsersに属するユーザーにアクセスを許可するように構成されていて、アサートされたユーザーが別のグループに属している場合に表示されます。
これがパーミッションの問題ではないと確認した場合は、デフォルトのID認証プロバイダのJAAS制御フラグがREQUIREDに設定されているかどうかを確認し、設定されている場合は、その設定を必要に応じてOPTIONALまたはSUFFICIENTに変更します。
エラー401 - 未認可
このメッセージは、リソースにアクセスするには、ユーザーは最初に認証が必要なことを通知します。
解決策
ユーザーが本当に認証されているかどうかを確認します。
SSOを使用した認証を最初に受けずにサーバーにアクセスしようとしていないかどうかを確認します。
OSSO IDアサーションが起動されていない
保護されたソースに対してOSSO IDアサーション・プロバイダを呼び出せない状況には、通常、不適切な構成が関与しています。環境に、「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明のような構成が正確に組み込まれていることを確認してください。
アプリケーション・リソース（URL）へのアクセス時にJSESSIONID Cookieが見つからない場合、WebLogic Serverは、JSESSIONIDをURLの一部として含めることによりURLの再書込みを行います。対象のURLが保護されているときは、再書込みしたURLのマッチングが、Oracle Access ManagerとOSSO Webエージェントでは困難な場合があります。
不一致の問題を回避するには、mod_osso.confに指定されている保護されたリソースの最後にアスタリスク（*）を追加します。たとえば、次のような保護されたURLがあるとします。
/myapp/login
これは、mod_ossoエントリの次の場所にあります。
<Location /myapp/login*> valid user AuthType OSSO </Location>
Mod_ossoモジュールは、SSO対応ログイン・サーバーとOracle HTTP Serverリスナー間の通信を提供します。mod_ossoモジュールは、mod_osso.confファイルを編集することで制御されます。
Oracle HTTP Server 11gのインストールには、mod_ossoとmod_weblogicが含まれています。
Oracle HTTP Server 10.1.3のリリースのCompanion CDに含まれているOHS 10gには、mod_ossoが含まれています。
|
関連項目: 次の各項とリリース1（11.1.1）のマニュアル
|
この項の内容は次のとおりです。
OSSO CookieにHTTPOnlyフラグ設定を構成するための新しい構成ディレクティブがmod_ossoに追加されました。新しいディレクティブは、OssoHTTPOnlyです。値は、On（フラグの有効化）またはOff（フラグの無効化）です。デフォルトでは、HTTPOnlyフラグはOnに設定されます。このディレクティブは、構成では設定されません。
このディレクティブは、ブラウザに設定されたOSSO CookieにHttpOnlyフラグを追加します。このフラグの目的は、クロスサイト・スクリプティングを防止することです。このフラグが設定されたCookieは、ブラウザで実行されているJavaScriptコードまたはアプレットからはアクセスできません。このフラグが設定されたCookieは、特定のドメインにhttpまたはhttpsを介してCookieを設定したサーバーにのみ送信されます。
これは、VirtualHost別のディレクティブで、グローバル・スコープまたはVirtualHostセクション内でのみ設定できます。次の例は、新しいディレクティブを示しています。
<VirtualHost *.7778> OssoConfigFile conf/osso.conf OssoHTTPOnly On --- --- --- <Location /osso> AuthType Osso --- --- </Location> </VirtualHost>
mod_osso 10gでは、OssoSecureCookiesディレクティブはデフォルトで無効になっています。ただし、mod_osso 11gでは、この動作はデフォルトで有効になっています。mod_osso 11gでOssoSecureCookiesディレクティブを無効にするには、対応する構成ファイルでOssoSecureCookiesをOffに設定する必要があります。mod_ossoを有効にすると、次の場所にmod_osso.confファイルが作成されます。
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
OssoSecureCookiesディレクティブを設定する手順は、次のとおりです。
OssoSecureCookies "Off"
ログアウトのためにOracle SSO Serverにリダイレクトしたときに、mod_ossoが問合せに戻りURLをURLエンコードしません。
この問題を修正するには、エンコードされたURLを渡す必要があります。例: response.setHeader("Osso-Return-Url", encoded-url)。
Oracle Fusion Middlewareは、Internet Protocol Version 4（IPv4）とInternet Protocol Version 6（IPv6）をサポートしています。IPv6の機能の中で特に重要なのは、IPv6がサポートするアドレス空間（128ビット）です。これは、IPv4（32ビット）のアドレス空間よりもかなり大きいため、Web上で指定可能なコンピュータの数が飛躍的に増えます。
|
関連項目: Oracle Single Sign-on ServerでのIPv6の使用方法の詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。 |
Fusion Middleware 11gには、コンテナ・ユーザー・セッションとSSOセッションを同期する新しいコンポーネントが導入されています。SSO同期フィルタは、Oracle WebLogicシステム・フィルタの実装です。SSO同期フィルタは、コンテナへのすべてのリクエストをインターセプトし、保護されたリソース・リクエストを操作して、コンテナのユーザー・セッションとOSSOのユーザー識別ヘッダー（Proxy-Remote-User）、またはOracle Access Manager SSOセッションCookie（ObSSOCookie）内のユーザー・データとの同期を試みます。
SSO同期フィルタは、Javaサーブレット仕様バージョン2.3に基づくサーブレット・フィルタの実装です。SSO同期フィルタにより、アプリケーションはSSOユーザー・セッションを追跡して各セッションと同期する必要がなくなります。アプリケーションは、コンテナのユーザー・セッションと同期するだけで済みます。
SSO同期フィルタは、コンテナへの各リクエストをインターセプトし、そのリクエストに添付されているHTTPヘッダーに基づいて操作するかどうかを決定します。フィルタは、SSOエージェントがこれらのヘッダーをWeb層で設定していることを必要とします。保護されていないアプリケーション領域にアクセスする場合、フィルタはパススルーとして機能します。保護されたリソースにアクセスした後、Web層のSSOエージェントは、Oracle Access ManagerなどのSSOシステムで認証を実行するようユーザーに指示します。認証後、Oracle Access Manager IDアサーション・プロバイダによってユーザー・アイデンティティがJAASサブジェクトとしてコンテナに確立され、ユーザー・セッションが作成されます。WebLogicでは、ユーザー・セッション・データがHTTPセッションCookieの一部（JSESSIONID）として保持されます。
アプリケーション・リソースへの後続アクセスでは、SSO同期フィルタに次の2つの情報が提供されます。
OSSOのユーザー識別ヘッダー（Proxy-Remote-User）
Oracle Access Manager SSOセッションCookie（ObSSOCookie）内のユーザー・データ
SSO同期フィルタの役割は、コンテナのユーザー・アイデンティティとSSOセッションのユーザー・アイデンティティが一致していることを確認することです。不一致がある場合、フィルタはそのコンテナのユーザー・セッションを無効にします。このため、ダウンストリーム・アプリケーションはコンテナのユーザー・セッションを追跡するだけで済み、使用しているSSO環境に関係なく一貫した方法で作用できます。
注意:
デフォルトで有効: SSO同期フィルタは、構成されたトークンからユーザー情報をフェッチし、既存セッション（存在する場合）からユーザーを取得し、CurrentSessionUserが着信SSOユーザーと一致していない場合はセッションを無効にしてリクエストされたURLにリダイレクトします。そうでない場合、リクエストは単にパススルーされます。
ドメインでOSSOまたはOracle Access Managerアサーション・プロバイダを構成していない場合、フィルタはWebLogic Serverの起動中に自動的に無効になります。
デフォルトですべてのURIに対して有効（/*）: アプリケーション・コードでの変更は不要です。
OSSOトークン/ヘッダーに対する構成: Proxy-Remote-Userが検索され、大/小文字を区別しない一致が実行されます。
Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_REMOTE_USERとREMOTE_USERが検索され、大/小文字を区別しない一致が実行されます。
グローバル・ログアウト: SSO同期フィルタは、OSSOまたはOracle Access Managerソリューションを使用するOracle Fusion Middlewareアプリケーションに対してシングル・ログアウト操作を提供します。これは、シングル・サインオンと同様に処理されます。グローバル・ログアウトが実行されると、セッションのクリーンアップが実行されていないアプリケーションに対して後続アクセスが行われたときに、SSOフィルタによってセッションが調整されます。
OSSOまたはOracle Access Managerソリューションを使用するアプリケーションは、OSSOログアウトまたはOracle Access Managerログアウトをコールする前にそのセッションを無効にする必要があります。OSSOログアウトの詳細は、「動的ディレクティブによるSSOログアウト」を参照してください。Oracle Access Managerログアウトの詳細は、「Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成」を参照してください。
アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。
様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shにEXTRA_JAVA_PROPERTIESがあるか確認します。表9-17に、各プロパティと同期動作を示します。
表9-17 SSO同期フィルタの各プロパティと同期動作
| 領域 | 優先システム・プロパティ | システム・プロパティのデフォルト値 | 同期フィルタのデフォルト動作 |
|---|---|---|---|
|
ステータス（有効または無効） |
sso.filter.enable |
構成なし |
有効 |
|
大/小文字を区別した一致 |
sso.filter.name.exact.match |
構成なし |
大/小文字を区別しない一致 |
|
構成されたトークン |
sso.filter.ssotoken |
構成なし |
|
|
URIマッピング |
適用なし |
適用なし |
/* |
一部のアプリケーションに対してフィルタを有効にすることはできません。SSO同期フィルタは、システム・フィルタです。このため、デプロイされているすべてのアプリケーションに対して有効になります（URIマッピングは/*）。
|
注意: 一部のアプリケーションに対してフィルタを有効にすることはできません。 |
次の手順に、SSO同期フィルタのプロパティと動作の変更に関するヒントを示します。
SSO同期フィルタのプロパティと動作を変更するには
フィルタの無効化: システム・プロパティsso.filter.enableをfalseに変更し（jvmに-Dとして渡す）、Oracle WebLogic Serverを再起動します。これにより、フィルタ・ステータスが切り替わります。
ユーザー識別ヘッダーと事前構成済同期フィルタ・トークンの不一致: システム・プロパティsso.filter.ssotokenを使用して、同期フィルタによって検索されるSSOトークンを上書きします。
たとえば、WebLogic Serverの起動スクリプト（-Dsso.filter.ssotoken=HEADERNAME）でWebLogic Server JVMに渡し、サーバーを再起動します。
Oracleサポート・サービスへ連絡する際には、デバッグの設定が求められることがあります。次の手順では、この設定方法について説明します。
認証プロバイダでは、デバッグ・モードで動作する場合、アプリケーション内の低レベルのアクティビティの詳細な説明を提供するメッセージが使用されます。通常、この情報はそれほど必要とされません。ただし、Oracleサポート・サービスへの連絡が必要な場合、デバッグを設定することをお薦めします。デバッグを設定すると、Oracle WebLogic Serverのデフォルト・ログの場所に認証プロバイダのメッセージが表示されます。
デバッグを設定するには
WebLogic管理コンソールにログインします。
「ドメイン」→「環境」→「サーバー」に移動し、使用するサーバーを選択します。
「デバッグ」タブをクリックします。
「このサーバーのデバッグ設定」で、「weblogic」→「security」→「atn」をクリックして開きます。
「DebugSecurityAtn」の隣にあるオプションをクリックして有効にします。
変更を保存します。
Oracle WebLogic Serverを再起動します。
Oracle WebLogic Serverのデフォルト・ログの場所で、SSOAssertionProviderを検索します。次に例を示します。
####<Apr 10, 2009 2:32:16 AM PDT> <Debug> <SecurityAtn> <sta00483> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1239355936490> <BEA-000000> <SSOAssertionProvider:Type = Proxy-Remote-User>
