| Oracle Fusion Middlewareセキュリティ・ガイド 11gリリース1（11.1.1） B56235-01 |
|
 戻る |
 次へ |
この章では、Oracle Fusion Middlewareに対して推奨される一連のシングル・サインオン・ソリューションについて説明します。また、Oracle Fusion Middleware環境で認証とシングル・サインオンを構成する際の一般的なガイドラインとユースケースについても説明します。この章の内容は次のとおりです。
Oracle Platform Security Servicesは、Oracle WebLogic Serverの内部セキュリティ・フレームワークを構成します。WebLogicドメインは、認証プロバイダと呼ばれる個別のソフトウェア・コンポーネントを使用してセキュリティ・データの格納とトランスポート、およびセキュリティ・データへのアクセスを提供します。認証プロバイダでは、各種システムを使用してセキュリティ・データを格納できます。WebLogic Serverによってインストールされる認証プロバイダは、組込みLDAPサーバーを使用します。
Oracle Fusion Middleware 11gは、アプリケーションによる境界認証の確立および実施のために使用できる、次の2つの新しいシングル・サインオンをサポートしています。
Oracle Service Oriented Architecture（SOA）やOracle WebCenterなどのセキュリティ対応コンポーネントでは、どちらのソリューションも選択できます（Oracle Access Manager 10gまたはOracleAS Single Sign-On 10g）。複数の製品が混在するスタックを使用している場合は、ニーズに応じたソリューションを注意深く選択する必要があります。適切なSSOソリューションの選択は、十分な検討を必要とし、それぞれの要件に応じて異なります。この項では、ニーズにあわせて最適なソリューションを選択するための一般的な情報とガイドラインについて説明します。
|
関連項目: 『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の使用をお薦めします。
Oracle Access Managerは、ユーザーおよびグループ・リポジトリとして多様なLDAPベンダーをサポートし、Oracle Virtual Directoryとの連携も可能です。
Oracle Access Managerは、Oracle以外のアプリケーション・サーバー・ベンダーおよび多数のOSプラットフォーム上のWeb層コンポーネントとの統合をサポートし、柔軟性の高いソリューションを提供します。
Oracle Fusion Middlewareを初めて使用する場合やエンタープライズ・レベルのSSOソリューションを検討している場合、すでにOracle Access Managerが環境にデプロイされている場合でも、Oracle Access Managerの使用をお薦めします。
OSSO 10gの既存の顧客: Oracle Single Sign-Onは、10g Oracle Application Serverスイートに同梱されています。OSSOは、Oracle Internet DirectoryおよびOracle HTTP Server 11gとともに使用できるエンタープライズ・レベルのシングル・サインオン・ソリューションです。
既存のOracleデプロイメントにOSSOがエンタープライズ・ソリューションとしてすでにデプロイされている場合、Oracle Fusion Middlewareは、既存のOSSOソリューションを引き続きサポートします。
|
関連項目: Oracle Technology Networkの『Oracle Application Server Single Sign-On管理者ガイド』（http://www.oracle.com/technology/documentation/oim1014.html） |
11g Portal、Forms、ReportsおよびDiscoverer: 10gでは、これらのコンポーネントのSSOソリューションとしてOracle Single Sign-Onが使用されていましたが、これは11gでも同様です。これらのコンポーネントでは、10g OSSOのほかに、10g Oracle Delegated Administration Servicesを使用する必要があります。また、Oracle Internet Directory 10gまたは11gも必須です。
|
関連項目: この章の次の項、および他の11gリリース1（11.1.1）のマニュアル
|
Oracle e-Business Suite 11および12: これらのコンポーネントは、10g OSSOとOracle Internet Directoryをサポートします。このタイプのe-Business設定がデプロイメントに含まれている場合は、OSSOとOracle Internet Directoryが最適な選択です。
Oracle Access ManagerとOSSOの統合: Oracle Access Managerは、推奨されるエンタープライズ・ワイドなソリューションです。OracleAS Single Sign-Onが必要なアプリケーション（Oracle Portalなど）がデプロイされている場合、OracleAS Single Sign-On（OSSO）からOracle Access Managerに認証を委任できます。Oracle Access Managerの認証機能を統合する場合、Oracle Access ManagerまたはOSSOを認証エンジンとして機能させることができます。このような統合では、Oracle Access ManagerとOSSOの統合を必要とするアプリケーションに対してOracle Internet Directoryも必要です。
|
関連項目: 『Oracle Access Manager統合ガイド』のOracle Application Serverとの統合に関する項 |
MicrosoftクライアントのWindowsネイティブ認証: Oracle WebLogic Serverは、Simple and Protected Negotiate（SPNEGO）認証メカニズムを使用するように構成できるため、Windowsネイティブ認証をサポートします。
|
関連項目: 『Oracle Fusion Middleware Securing Oracle WebLogic Server』のMicrosoftクライアントでのシングル・サインオンの構成に関する項 |
Oracle Access Managerは、アイデンティティ管理とセキュリティ用のOracleエンタープライズ・クラス・スイート製品です。Oracle Access Managerは、シングル・サインオン・ソリューションを含め、アイデンティティ管理とセキュリティの各種機能を備えています。
Oracle Access Manager認証プロバイダは、Oracle WebLogic Serverと連携する新しいコンポーネントです。アプリケーションでは、次のOracle Access Manager認証プロバイダ機能のいずれかまたはその両方を使用できます。これらの各機能により、WebLogicユーザーに対して特定のOracle Access Manager機能が有効になります。
この機能は、Oracle Access Manager認証サービスを使用します。また、すでに認証されているOracle Access ManagerユーザーをObSSOCookieを介して検証し、WebLogic認証済セッションを作成します。また、Webゲートとポータル間のシングル・サインオンも提供します。
|
注意: Oracle Web Services Managerでは、シングル・サインオン用のIDアサーション・プロバイダが使用されます。 |
この機能は、Oracle Access Manager認証サービスを使用して、WebLogic Serverにデプロイされているアプリケーションにアクセスするユーザーを認証します。ユーザーは、ユーザー名やパスワードなどの資格証明に基づいて認証されます。
この項の説明は、ユーザーがOracle WebLogic ServerとOracle Access Managerに精通していることを前提としています。Oracle Access Managerの構成および管理の概要については、『Oracle Access Manager IDおよび共通管理ガイド』および『Oracle Access Manager System Administration Guide』を参照してください。
この項の後半は、次のとおりです。
「Oracle Access Manager認証プロバイダを使用するアプリケーションのシナリオ」では、アプリケーションの現行設定に応じて、Oracle Access Manager認証プロバイダの各種機能を使用する方法について説明します。
「Oracle Access Managerの認証プロバイダの使用」では、認証およびシングル・サインオンという、2つのプロバイダ機能について説明します。
「シングル・サインオン用のOracle Access Manager IDアサーションの構成」では、シングル・サインオン用にプロバイダを設定するための実行手順について説明します。
「Oracle Access Manager認証プロバイダの構成」では、認証プロバイダを設定するための実行手順について説明します。
「Oracle Web Services Manager用のIDアサーションの構成」では、このシナリオを設定するための実行手順について説明します。
「プロバイダ・デプロイメントのトラブルシューティング・ヒント」では、Oracle Access Manager認証プロバイダの実装に関する問題の検出方法および修正方法について説明します。
この項では、アプリケーションの現行設定に応じて、Oracle Access Managerとコンパニオン認証プロバイダを使用する方法について説明します。
アプリケーションでのOracle Application ServerからOracle WebLogic Serverへの移行
アプリケーションでのWebLogic SSPI用のOracle Access Managerセキュリティ・プロバイダの使用
アプリケーションでOracle Access Manager認証プロバイダを初めて使用する場合、使用する機能に応じて、次の項を参照してください。
シングル・サインオン用のIDアサーション・プロバイダ: 「シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダの使用について」を参照してください。
|
注意: IDアサーション・プロバイダは、Oracle Web Services ManagerでWebサービスを保護する際にも使用します。 |
認証プロバイダ: 「Oracle Access Manager認証プロバイダの使用について」を参照してください。
アプリケーションが古いOracle Application Server（OC4J）にデプロイされている場合、アプリケーションでOracle WebLogic ServerとともにOracle Access Managerのいずれかの認証プロバイダ機能を使用するには、次の手順に従ってください。
すべてのOC4J固有の設定をアプリケーション構成から削除します。
シングル・サインオン用のIDアサーション・プロバイダ: 「シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダの使用について」を参照してください。
|
注意: IDアサーション・プロバイダは、Oracle Web Services ManagerでWebサービスを保護する際にも使用します。 |
認証プロバイダ: 「Oracle Access Manager認証プロバイダの使用について」を参照してください。
|
関連項目: Java EEアプリケーションをOracle Containers for Java EE（OC4J）10gリリース3（10.1.3）からOracle WebLogic Serverにアップグレードする方法の詳細は、『Oracle Fusion Middleware Java EEアップグレード・ガイド』を参照してください。 |
10g（10.1.4.2.0）以前のOracle Access ManagerのWebLogic SSPI用セキュリティ・プロバイダは、WebLogicプラットフォームにデプロイしたJ2EEアプリケーションの認証、認可およびシングル・サインオンを提供していました。WebLogic SSPI用セキュリティ・プロバイダでは、Oracle Access Managerを使用して、ビジネス・アプリケーションへのユーザー・アクセスも管理できます。
|
注意: WebLogic SSPI用セキュリティ・プロバイダは、リリース10g（10.1.4.2.0）の『Oracle Access Manager統合ガイド』ではセキュリティ・プロバイダとも呼ばれています。 |
10g（10.1.4.2.0）以前のOracle Access ManagerのWebLogic SSPI用セキュリティ・プロバイダは、Oracle WebLogic Portalリソースへのアクセスを認証し、Oracle Access ManagerとOracle WebLogic Portal Webアプリケーション間のシングル・サインオンをサポートします。さらに、ユーザーおよびグループの管理機能も提供します。
アプリケーションで認証およびSSOのみを目的として10g（10.1.4.2.0）以前のOracle Access Manager WebLogic SSPI用セキュリティ・プロバイダを使用している場合は、最新の認証プロバイダをインストールし、かわりにそれを使用できます。ただし、最新のOracle Access Manager認証プロバイダによって提供される機能以外を使用している場合は、引き続きOracle Access Manager WebLogic SSPI用セキュリティ・プロバイダを使用してください。
10g（10.1.4.3）のOracle Access Manager認証プロバイダは、10g（10.1.4.2.0）のWebLogic SSPI用セキュリティ・プロバイダよりも簡単にインストールおよび構成できます。10g（10.1.4.2.0）のWebLogic用セキュリティ・プロバイダとは異なり、10g（10.1.4.3）の認証プロバイダは、Oracle WebLogic Serverがサポートするすべてのプラットフォームで機能します。ただし、10g（10.1.4.3）の認証プロバイダは、認証とシングル・サインオン（SSO）の2つのサービスのみを提供します。
アプリケーションでは、認証またはシングル・サインオン（またはその両方）用にOracle Access Managerの認証プロバイダを使用できます。この項では、これらの機能で必要とされる共通コンポーネントとその動作について説明します。
どの機能を使用するかに関係なく（認証またはシングル・サインオン用IDアサーション）、いくつかのコンポーネントとファイルが必要です。次のリストは、必須コンポーネントおよびファイルの概要を簡潔に示しています。
Oracle Access Managerアクセス・サーバーとOracle WebLogic Serverにより、1つのエンタープライズ・ディレクトリ・サーバー（Oracle Internet DirectoryまたはSun Oneディレクトリ・サーバー）が使用されます。
この章で後述するように、Oracle Access Manager認証プロバイダを使用するよう構成されたOracle WebLogic Server 10.3.1が必要です。
オプション: Fusion Middleware製品（Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど）には、Oracle Access Manager認証プロバイダとOAMCfgToolのJARファイルが含まれています。
Oracle Access Manager認証プロバイダのJARファイルは、Oracle Fusion Middleware製品（Oracle Identity Management、Oracle SOA SuiteまたはOracle WebCenter）のインストール時に提供されます。
|
注意: Oracle Fusion MiddlewareアプリケーションがデプロイされていないスタンドアロンのOracle WebLogic Serverを使用している場合は、この章で後述する手順に従ってJARファイルを取得してください。 |
oamAuthnProvider.jar: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダ・ファイルとOracle WebLogic Server 10.3.1用認証プロバイダ・ファイルが両方とも含まれています。ユーザーまたはアプリケーションからのWebおよび非Web（非HTTP）リソースのリクエストを処理するために、カスタムOracle Access Managerアクセス・ゲートも提供されます。
oamcfgtool.jar: Oracle Access Managerのフォームベース認証スキーム、ポリシー・ドメイン、アクセス・ポリシー、およびシングル・サインオン用のIDアサーション・プロバイダのWebゲート・プロファイルを自動的に作成する、プラットフォーム非依存のOAMCfgToolとスクリプトを提供します。OAMCfgToolでは、JRE 1.5または1.6が必要です。
Oracle Access Manager IDアサーション・プロバイダで必要となる10g（10.1.4.3）Webゲートのリバース・プロキシとして、OHS 11gを構成する必要があります。
Oracle Access Manager 10g（10.1.4.3）のコンポーネントは、次のとおりです。
アイデンティティ・サーバー
Webパス
ポリシー・マネージャ
アクセス・サーバー
Webゲート（シングル・サインオン用アイデンティティ・アサーションでのみ使用）
Webゲートは、WebリソースのHTTPリクエストをインターセプトし、それらのリクエストを認証および認可のためにアクセス・サーバーに転送するWebサーバー・プラグイン・アクセス・クライアントです。
アクセス・ゲート（認証プロバイダとともに使用、またはOracle Web Services ManagerによってWebサービスが保護されている場合に使用）
oamAuthnProvider.jarには、カスタム・アクセス・ゲートが含まれています。このコンポーネントでは、Webサーバーは必要ありません。
この項では、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダの使用について説明します。
Oracle Access Managerの認証プロバイダをシングル・サインオン用のIDアサーション・プロバイダとして構成できます。この場合、プロバイダによって保護されるのはWebリソースのみです。
このシングル・サインオン用のIDアサーション・プロバイダは、Web層のWebゲートによって実行される境界認証とObSSOCookieを使用して、保護されているWebLogicリソースにアクセスしようとするユーザーのアイデンティティをアサートします。
すべてのリクエストは、リバース・プロキシWebサーバーにルーティングされます。リクエストは、Webゲートによってインターセプトされます。Oracle Access Manager内に構成されている認証スキームに基づいて、ユーザーに対して資格証明の提示が要求されます。推奨されるスキームは、フォーム（フォームベース・ログイン）です。
認証に成功した場合、WebゲートによってObSSOCookieが作成されます。Webサーバーのmod_weblogicモジュールはそのリクエストをOracle WebLogic Serverに転送し、Oracle WebLogic Serverがシングル・サインオン（リクエストとCookieを使用）用のOracle Access Manager IDアサーション・プロバイダを呼び出して検証を求めます。
|
注意: Oracle Access Manager内に構成されている認証スキームに基づいて、ユーザーに対して資格証明の提示が要求されます。後述するように、このスキームはOAMCfgToolを使用して設定できます。この章の説明では、Apache用WebLogic Serverプラグインの汎用名（mod_weblogic）を使用します。Oracle HTTP Server 11gでは、このプラグインの名前はmod_wl_ohsですが、実際のバイナリ名はmod_wl_ohs.soになります。後述する例は、実装可能な正確な構文を示しています。 |
WebLogicセキュリティ・サービスがシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを呼び出すと、IDアサーション・プロバイダは着信リクエストからObSSOCookieを受け取り、サブジェクトにWLSUserImplプリンシパルを移入します。また、ユーザーのグループに対応しているWLSGroupImplプリンシパルがある場合はそれらが追加されます。Oracle Access ManagerによってCookieが検証されます。
図10-1は、Oracle Fusion Middlewareとともにシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを構成した場合のコンポーネントの配置と情報フローを示しています。図の後に詳細を示します。
図10-1 Webリソースのみを対象としたOracle Access Manager Single Sign-Onソリューション
次のプロセス概要では、Web専用アプリケーションとともにシングル・サインオン用のIDアサーション・プロバイダを使用する場合にコンポーネント間で発生する処理を説明します。この実装は、ほとんどすべてのSSOユースケースに対応します。例外は、Oracle Web Services ManagerによってWebサービスが保護されている場合です。この場合、信頼できるWebゲートがありません。かわりに、IDアサーション・プロバイダが提供するアクセス・ゲートにアクセスし、アクセス・ゲートがアクセス・サーバーと対話します。それ以外の処理は基本的には同じです。
|
注意: シングル・サインオン用のIDアサーション・プロバイダは、その実装において信頼できるWebゲートを使用しているか、またはoamAuthnProvider.jarが提供するカスタム・アクセス・ゲートを使用しているかどうかに関係なく、すべて同様の方法で処理されます。 |
プロセス概要: Web専用アプリケーションを使用するOracle Access ManagerのIDアサーション・プロバイダ
ユーザーが、Oracle WebLogic Serverにデプロイされている、Oracle Access Managerによって保護されたWebアプリケーションにアクセスしようとします。
リバース・プロキシWebサーバーのWebゲートがリクエストをインターセプトし、リクエストされたリソースが保護されているかどうかをOracle Access Managerアクセス・サーバーに問い合せます。
リクエストされたリソースが保護されている場合、Webゲートは、そのリソースに対して構成されているOracle Access Manager認証スキームのタイプ（フォーム・ログインを推奨）に基づいてユーザーの資格証明を要求します。ユーザーは、ユーザー名やパスワードなどの資格証明を入力します。
Webゲートは、認証リクエストをアクセス・サーバーに転送します。
アクセス・サーバーは、ユーザー資格証明をユーザー・ディレクトリの格納情報と照合した後、レスポンスをWebゲートに返します。次のように処理が選択されます。
正常な認証: 手順6に進みます。
認証失敗: ログイン・フォームが表示され、ユーザーは資格証明の再入力を求められます。エラーは報告されません。
アクセス・サーバーはセッション・トークンを作成し、Webゲートに送信します。Webゲートは、アクセス・サーバーからの返信に応じてObSSOCookieと値を設定します。Webサーバーはこのリクエストをプロキシに転送し、プロキシはmod_weblogicプラグインを使用してリクエストをOracle WebLogic Serverに転送します。
mod_weblogicは、その構成設定に従ってリクエストを転送します。
WebLogic Serverセキュリティ・サービスは、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを呼び出します。このIDアサーション・プロバイダは、タイプObSSOCookieのトークンを受け入れるように構成されています。IDアサーション・プロバイダは、ObSSOCookieを使用してCallbackHandlerを初期化します。さらに、ダウンストリームLoginModule用として、NameCallbackにユーザー名を設定します。
Oracle WebLogicセキュリティ・サービスがユーザーを認可し、リクエストしたリソースへのアクセスを許可します。
レスポンスがリバース・プロキシWebサーバーに返されます。
レスポンスがブラウザに返されます。
|
関連項目: 次の各項を参照して、実装の詳細を設定してください。 |
この項では、Oracle Access Manager認証プロバイダの使用について説明します。
Oracle Access Managerは、Webおよび非Webリソースへのアクセスを保護し、認証プロバイダを使用するように構成できます。
|
注意: 認証プロバイダでは、シングル・サインオン機能は提供されません。 |
ユーザーが保護されたリソースへのアクセスを試みると、Oracle WebLogic Serverによって、アプリケーションのweb.xmlファイルで指定されている認証方式に基づいたユーザー資格証明が要求されます。次に、Oracle WebLogic Serverが認証プロバイダを呼び出し、認証プロバイダは資格証明をOracle Access Managerアクセス・サーバーに転送します。この資格証明は、エンタープライズ・ディレクトリ・サーバーによって検証されます。
|
注意: 認証プロバイダは、Oracle Access Manager認証スキームに従うのではなく、アプリケーション構成ファイルweb.xmlに指定されている認証方式に基づいてユーザーに資格証明を要求します。 |
図10-2は、Webおよび非Webリソースに対してOracle Access Manager認証を行う場合のコンポーネントの配置と情報フローを示しています。詳細は、図の後に説明します。標準的なOracle Access Managerアイデンティティ・システム（アイデンティティ・サーバーとWebパス）、ポリシー・マネージャ、およびWebゲートの各コンポーネントは存在しますが、この図には示されていません。認証プロバイダは、カスタム・アクセス・ゲートを介してアクセス・サーバーと通信するからです。
プロセス概要: Webおよび非Webリソース用のOracle Access Manager認証プロバイダ
ユーザーが、Oracle WebLogic Serverにデプロイされている（アプリケーションのweb.xmlファイルにある認証方式で保護されている）J2EEアプリケーションにアクセスしようとします。
Oracle WebLogic Serverがリクエストをインターセプトします。
Oracle WebLogicセキュリティ・サービスが、Oracle Access Manager認証プロバイダのLoginModuleを呼び出します。LoginModuleはNAPライブラリを使用してアクセス・サーバーと通信し、ユーザー資格証明を検証します。
ユーザー・アイデンティティが正常に認証されると、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認証プロバイダのデプロイ時に使用するコンポーネントとファイルのインストール方法の追加情報を示します。
特に明記されていないかぎり、次の各項では、Oracle Access Manager IDアサーション・プロバイダとOracle Access Manager認証プロバイダの要件を両方とも説明します。
この項では、Oracle Access Managerを初めて使用するユーザーのために、インストールと設定の概要を簡潔に説明します。
アイデンティティ・システム: アイデンティティ・システムは、1つ以上のアイデンティティ・サーバーと1つのWebパスで構成されます。1つ以上のアイデンティティ・サーバーと1つのWebパスをインストールした後、アイデンティティ・システムを設定する必要があります。アイデンティティ・システムの設定中には、マスター管理者（最上位の管理者）を指定します。マスター管理者は、アイデンティティ・システムおよびアクセス・システムの他のマスター管理者と委任管理者を指定できます。
ポリシー・マネージャ: アイデンティティ・システムを設定した後、ポリシー・マネージャをインストールして設定できます。ポリシー・マネージャの設定中に、ポリシー・マネージャを保護するデフォルト・ポリシー（/access）が作成および有効化されることを確認してください。
アクセス・サーバー: Oracle Access Manager認証プロバイダでは、Webゲートまたはアクセス・ゲート用のアクセス・サーバーが2つ必要になります（1つのプライマリ・サーバーと1つのセカンダリ・サーバー）。現時点では、セカンダリ・アクセス・サーバーは1つしかサポートされません。アクセス・サーバーのインストールには、次の手順が含まれます。
アクセス・システム・コンソールで、プライマリ・サーバーのアクセス・サーバー構成プロファイルを追加します。「アクセス管理サービス」が「オン」（ポリシー・マネージャAPIのサポート・モードとも呼ばれる）になっていることを確認します。
「アクセス管理サービス」を「オン」にして、セカンダリ・アクセス・サーバー構成プロファイルを追加します。
プライマリ・アクセス・サーバーのインスタンスをインストールします。
セカンダリ・アクセス・サーバーのインスタンスをインストールします。
Webゲート/アクセス・ゲート: Webゲートまたはアクセス・ゲートのどちらが必要であるかは、使用するOracle Access Manager認証プロバイダによって決まります。次に例を示します。
シングル・サインオン用のIDアサーション・プロバイダ: 境界認証を定義するために、アプリケーションごとに個別のWebゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。
認証プロバイダまたはOracle Web Services Manager: アプリケーションごとに個別のアクセス・ゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。
|
注意: Oracle Access Managerを簡易モードまたは証明書モードでインストールする場合は、「Oracle Access Manager証明書のJavaキーストア形式への変換」で説明されているタスクも実行する必要があります。 |
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またはSun One LDAPディレクトリ・サーバーを構成します。ディレクトリ・サーバーがデプロイメント用に調整されていることを確認してください。
|
関連項目: 次のリリース11g（11.1.1.1.0）のマニュアル
|
Oracle WebLogic Server 10.3.1をインストールおよび設定します。
|
関連項目: 手順3および『Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server』 |
オプション: Fusion Middleware製品（Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど）をインストールし、必要なJARファイルが次のFusion Middlewareパスに含まれていることを確認します。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
|
注意: Fusion MiddlewareアプリケーションがデプロイされていないスタンドアロンのOracle WebLogic Serverを使用している場合は、この章で後述する手順に従ってJARファイルを取得および格納してください。 |
必要に応じて、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 Access Manager証明書のJavaキーストア形式への変換」で説明されているタスクを実行します。
リソース・タイプの作成: Oracle Access Manager認証プロバイダを使用する場合、またはOracle Web Services ManagerポリシーによってWebサービスが保護されている場合は、「Oracle Access Managerでのリソース・タイプの作成」を実行します。
シングル・サインオン用のIDアサーション・プロバイダ: 「シングル・サインオン用のOracle Access Manager IDアサーションの構成」で説明されているタスクを実行します。
認証プロバイダ: 「Oracle Access Manager認証プロバイダの構成」で説明されているタスクを実行します。
Oracle Web Services Manager: 「Oracle Web Services Manager用のIDアサーションの構成」で説明されているタスクを実行します。
すべてのJavaコンポーネントとアプリケーションでJKSをキーストア形式として使用することをお薦めします。この項では、Oracle Access Manager X.509証明書をJavaキーストア（JKS）形式に変換する手順について説明します。これらの手順に従って実行すると、Java NAPクライアントがOracle Access Managerアクセス・サーバーと簡易モードまたは証明書モードで通信する際に使用できるJKSストアが生成されます。
簡易モードまたは証明書モードで通信する場合、アクセス・サーバーでは、鍵、サーバー証明書およびCA連鎖ファイルが使用されます。
aaa_key.pem: ルートCAへのリクエストの送信中に証明書生成用のユーティリティによって生成されるランダムな鍵情報。これは秘密鍵です。Webゲートへの証明書リクエストによって、証明書リクエスト・ファイルaaa_req.pemが生成されます。このWebゲート証明書リクエストを、アクセス・サーバーによって信頼されているルートCAに送信する必要があります。ルートCAがWebゲート証明書を返します。このWebゲート証明書は、Webゲートのインストール中またはインストール後にインストールできます。
aaa_cert.pem: ルートCAによって署名された、アクセス・サーバーの実際の証明書。
aaa_chain.pem: ルートCAの公開証明書。これは、簡易モードまたは証明書モードで通信しているピアがSSLハンドシェイクを実行し、それぞれの証明書を交換して検証する際に使用されます。簡易モードでは、aaa_chain.pemはAccessServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pemにあるOpenSSL証明書です。
ここで、aaaはファイルに付けた名前です（証明書および連鎖ファイルにのみ適用可能）。
テキスト編集機能を使用して既存の証明書を編集し、CERTIFICATEブロック内のデータを除くすべてのデータを削除できます。次に、編集した証明書をJKS形式に変換し、それをキーストアにインポートします。Java KeyToolでは、すでに証明書を持っている既存の秘密鍵はインポートできません。OpenSSLユーティリティを使用して、PEM形式ファイルをDER形式ファイルに変換する必要があります。
Oracle Access Manager証明書をJKS形式に変換してインポートするには:
Java 1.6または最新バージョンをインストールおよび構成します。
元のファイルを保持するために、編集前に次のファイルをコピーしておきます。
aaa_chain.pem
aaa_cert.pem
cacert.pem（簡易モード用に構成する場合のみ）
TextPadを使用してaaa_chain.pemを編集し、CERTIFICATEブロック内のデータを除くすべてのデータを削除し、元のファイルを保持するためにこのファイルを新しい場所に保存します。
-----BEGIN CERTIFICATE----- ... CERTIFICATE ... -----END CERTIFICATE-----
編集したaaa_chain.pemに対して次のコマンドを実行します。
JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore
rootcerts
ここで、別名（短縮名）root_caを鍵に割り当てます。入力ファイルaaa_chain.pemは、手順3で手動で編集したファイルです。キーストア名はrootcertsです。
新規に作成したキーストアに格納されている鍵にアクセスするには、パスワードを入力する必要があります。
|
注意: セキュリティを確保するため、パスワード入力を求めるプロンプトが表示されるようにkeytoolを設定しておくことをお薦めします。このプロンプトは、コマンドラインで"--storepass"フラグが省略されている場合に自動的に表示されます。 |
プロンプトが表示されたら、キーストアのパスワードを入力します。次に例を示します。
Enter keystore password: <keystore_password> Re-enter new keystore password: <keystore_password>
このツールを信頼できる場合は、Yesと入力します。
Trust this certificate? [no]: yes
次のコマンドを実行した後でパスワードを入力し、証明書がJKS形式としてインポートされたことを確認します。
JDK_HOME\bin\keytool" -list -v -keystore "rootcerts" Enter keystore password: <keystore_password>
次のようなレスポンスを確認します。
Keystore type: JKS Keystore provider: SUN Your keystore contains n entries Alias name: root_ca Creation date: April 19, 2009 Entry type: trustedCertEntry Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, O="Oblix, Inc.", L=Cupertino, ST= California , C=US Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, O="Oblix, Inc.", L=Cupertino, ST= California ,C=US Serial number: x Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57 GMT+05:30 2010 Certificate fingerprints MD5: CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95 Signature algorithm name: MD5withRSA Version: 1 *******************************************
他のPEMファイル（連鎖でない場合はaaa_chain.pemを除く）について、手順3〜7を繰り返します。
アクセス・サーバーのインストール・ディレクトリ・パスでOpenSSLユーティリティを使用して、aaa_key.pemファイルをDER形式に変換します。次に例を示します。
AccessServer_install_dir\access\oblix\tools\openssl>openssl pkcs8 -topk8
-nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER
ここで、入力ファイルはaaa_key.pem、出力ファイルはaaa_key.derです。このほかに、次のオプションがあります。
表10-1 PEMからDER形式ファイルを作成するためのオプション
| オプション | 説明 |
|---|---|
|
-topk8 |
従来の形式の秘密鍵を読み取り、PKCS#8形式の鍵を書き込みます。これは、入力時にPKCS#8形式の秘密鍵を要求し、従来の形式の秘密鍵を書き込むデフォルトの操作を逆転します。 |
|
-nocrypt |
暗号化されていないPrivateKeyInfo構造を出力します。 |
|
-inform |
入力形式を指定します。入力時にPKCS#8形式の鍵が要求される場合、PKCS#8鍵のDERまたはPEMエンコードされたバージョンが要求されます。あるいは、従来の形式である秘密鍵のDERまたはPEMが使用されます。 |
|
-outform |
出力形式を指定します。出力時にPKCS#8形式の鍵が要求される場合、PKCS#8鍵のDERまたはPEMエンコードされたバージョンが要求されます。あるいは、従来の形式である秘密鍵のDERまたはPEMが使用されます。 |
簡易または証明書モード: Oracle Access Managerアクセス・サーバーが簡易モードまたは証明書モードで構成されている場合は、PEMファイル（この例ではaaa_cert.pem）で、アクセス・サーバーのパスフレーズを入力します。
Passphrase for the certificate
次のコマンドを実行して、aaa_cert.pemファイルをDER形式に変換します。
AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in
aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
ImportKeyユーティリティを使用して、DER形式ファイルをJavaキーストアにインポートします。次に例を示します。
Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der
aaa_cert.der
ウィンドウで結果を確認します。結果は、次の例のようになります。
Using keystore-file : jkscerts
One certificate, no chain
Key and certificate stored
Alias:importkey Password:your_password
次の手順を実行します。
シングル・サインオン用のIDアサーション・プロバイダ: 「シングル・サインオン用のOracle Access Manager IDアサーションの構成」に進みます。
認証プロバイダまたはOracle Web Services Manager: 「Oracle Access Managerでのリソース・タイプの作成」で説明されている手順を実行します。
この項では、ポリシー・ドメインによって保護されるリソース・タイプを識別するために、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でリソース・タイプを定義するには
アクセス・システム・コンソールに移動して、ログインします。
「アクセス・システム・パッケージ」タブを選択して、「共通情報の構成」、「リソース・タイプ定義」をクリックし、「すべてのリソース・タイプをリスト」ページを表示します。
「すべてのリソース・タイプをリスト」ページで、「追加」をクリックし、「新規リソース・タイプの定義」ページを表示します。
次の詳細を指定して、リソース・タイプを定義します。
名前: wl_authen
表示名: wl_authen
リソースの一致: 大/小文字を区別しない
リソース操作: LOGIN
定義したリソース・タイプを保存します。
次の手順を実行します。
認証プロバイダ: 「Oracle Access Manager認証プロバイダの構成」
Oracle Web Services Manager: 「Oracle Web Services Manager用のIDアサーションの構成」
この項では、シングル・サインオン用のOracle Access Manager IDアサーションの構成に固有の手順について説明します。
前提条件
認証プロバイダまたはOracle Web Services Managerに関して特に明記されていないかぎり、次のタスクを含め、「Oracle Access Managerプロバイダの必須コンポーネントのインストールおよび設定」で説明されているすべてのタスクを実行する必要があります。
Oracle Access Manager証明書のJavaキーストア形式への変換は、Oracle Access Managerが簡易または証明書トランスポート・セキュリティ・モードで構成されている場合に必要です。
アプリケーションでシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを構成するには、次のタスク概要で説明されている手順を実行します。
タスク概要: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダのデプロイおよび構成
次の項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。
この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Deploying Applications to 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で使用されることに注意してください。
Oracle Access Manager IDアサーション・プロバイダの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）が含まれており、すでに有効になっています。次の手順を実行してこれを確認するか、またはこの手順を省略できます。
Webサーバーのhttpd.confファイルにmod_weblogic構成が存在しない場合は、HTTPサーバーからOracle WebLogic Serverへリクエストをプロキシできません。
Oracle Access Manager IDアサーション・プロバイダ用の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サーバーが実行されているホストのみからリクエストを受け入れることができます。
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。このフィルタを使用すると、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非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
表10-12は、接続フィルタの各パラメータを説明しています。
表10-2 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
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 Securing Oracle WebLogic Server』のWebLogicドメインのセキュリティの構成に関する項 |
11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには
Oracle WebLogic管理コンソールにログインします。
「ドメイン」ノードを開きます。
「ドメイン」の「一般」タブで、「ドメイン全体のセキュリティ設定の表示」リンクをクリックします。
「セキュリティ・フィルタ」タブを選択します。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム属性フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHにも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「適用」をクリックします。
Oracle WebLogic Serverを再起動します。
アプリケーションを設定したら、Oracle Access Managerを使用して保護する必要があります。このタスクの自動化を支援する、OAMCfgToolというコマンドライン・ツールが用意されています。このツールは、Fusion Middlewareアプリケーションの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の実行中にエラーが発生した場合は、コマンドラインでエラーが報告されます。
表10-3は、OAMCfgToolの必須パラメータとオプション・パラメータ、およびCREATEモードの各値を示しています。パラメータは、一度に複数個指定できます。「既知の問題: JARファイルとOAMCfgTool」も参照してください。
表10-3 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 Access Manager System Administration Guide』を参照してください。 |
|
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モードで使用することにより、シングル・サインオン構成のポリシー・ドメインが正しいことを確認できます。この場合、一連のリクエストは保護されたリソースに自動的に送信されます。
表10-4は、OAMCfgToolの必須パラメータとオプション・パラメータ、およびVALIDATEモードの各値を示しています。
表10-4 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を使用する場合の処理について説明します。
プロセス概要: OAMCfgToolによる認証スキーム、ポリシー・ドメインおよびWebゲート・プロファイルの作成
app_domainパラメータは、ポリシー・マネージャのポリシー・ドメインを作成することでアプリケーション認証を可能にします。
web_domainパラメータは、リクエストの送信元であるWebゲート・ホストを送信先のアプリケーションに接続したり、ポリシーを既存Webゲートにリンクするためのホスト識別子を作成します。このホスト識別子を使用するアクセス・ポリシーが存在しない場合、新しいポリシーが設定されます。
|
注意: 新規Web層において、CREATEモードで新しいWebゲート・プロファイルを作成する場合、web_domainパラメータを省略する必要があります。この場合は、表10-3の説明に従ってください。
|
protected_urisパラメータは、ホスト識別子（または手順2で作成した新しいWebゲート/アクセス・ゲート・プロファイル）を使用して、HTTPリソースを保護するためのアプリケーション固有のURLを定義します。
public_urisパラメータは、app_domain nameにあるhttpリソースの特定のURIを（GETおよびPOST操作で）非保護にするためのPublic_URI_Policyを作成します。
LDAPパラメータは、Oracle Access Managerが使用するディレクトリ・サーバーを指定します。ここで指定した検索ベースで、すべてのLDAP問合せが実行されます。詳細は、表10-3を参照してください。
log fileおよびlog levelパラメータは、OAMCfgToolの出力ファイルとログ・レベルを指定します。
output_ldif_fileパラメータは、LDIFファイルの名前を定義します。ここで作成したLDIFファイルは、ユーザーの指定に応じて後でディレクトリ・サーバーにロードできます。このファイルを使用しない場合、構成変更はディレクトリ・サーバーに書き込まれます。
この項では、Oracle Access Managerで表示した場合のOAMCfgToolの実行結果について説明します。
ポリシー・ドメイン
「ポリシー・ドメイン」の「一般」タブ
図10-3は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「一般」タブを示しています。説明は、自動的に表示されます。
|
注意: 説明について、Java APIは稼働プラットフォームの現在のユーザーとコンピュータ・ホスト名user@hostnameを取得します。 |
「ポリシー・ドメイン」の「リソース」タブ
図10-4は、OAMCfgToolで作成しサンプル・ポリシー・ドメインの「リソース」タブを示しています。デフォルトは、httpリソース・タイプです。ホスト識別子とURL接頭辞は、入力したOAMCfgToolパラメータとその値から導出されます。説明は、自動的に表示されます。
「ポリシー・ドメイン」の「認可ルール」タブ
図10-5は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「認可ルール」タブを示しています。図の後にサブ・タブの詳細を示します。OAMCfgToolを使用すると、ポリシー・ドメインに対して認可ルールが自動的に構成されます。
「ポリシー・ドメイン」の「デフォルト・ルール」タブ
図10-6は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「デフォルト・ルール」タブを示しています。すべての値は、ポリシー・ドメインに対して自動的に構成されます。図の後にサブ・タブの詳細を示します。
「ポリシー・ドメイン」の「ポリシー」タブ
図10-7は、OAMCfgToolで指定したパラメータと値を使用して作成された、サンプル・ポリシー・ドメインの「ポリシー」タブにある「一般」サブ・タブを示しています。ホスト識別子は、app_domain値に基づきます。図の後に他のサブ・タブの詳細を示します。
「ポリシー・ドメイン」の「委任アクセス管理」タブ
図10-8は、OAMCfgToolを使用して作成されたサンプル・ポリシー・ドメインの「委任アクセス管理」タブを示しています。マスターWebリソース管理の委任権限を設定するパラメータは、このツールでは指定されません。
|
関連項目: 『Oracle Access Manager System Administration Guide』のポリシー・ドメインでのリソース保護に関する項 |
ホスト識別子
OAMCfgToolで作成したホスト識別子は、アクセス・システム・コンソールの「アクセス・システム構成」タブで確認できます。
図10-9は、OAMCfgToolを使用して作成されたサンプル・ホスト識別子を示しています。ここで説明されているように、必須パラメータはOAMCfgToolのapp_domainパラメータに入力した値から導出されます。説明は、OAMCfgToolが表示します。
アクセス・ゲート・プロファイル
図10-10は、web_domainパラメータを省略した場合にOAMCfgToolによって作成されるサンプル・アクセス・ゲート・プロファイルを示しています。このプロファイルは、アクセス・システム・コンソールにあります。ここで説明されているように、必須のプロファイル・パラメータはOAMCfgToolを使用して入力された値から導出されます。他のプロファイル・パラメータでは、デフォルト値が使用されます。説明は、OAMCfgToolが表示します。
この項では、OAMCfgToolの実行時にモデルとして使用できる手順について説明します。
この例では、新しいWebゲート・プロファイルを必要とする新規Web層を想定しています。このため、web_domain=パラメータは省略されます。新しいプロファイルが作成され、app_domain値から名前が付けられます（_AGが付加される）。
次の手順は、このツールの使用方法の一例にすぎません。その値は、使用する環境によって異なります。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、OAMCfgToolはすでにインストールされています。この場合、手順1を省略します。 |
OAMCfgToolを使用してフォーム認証スキーム、ポリシー・ドメインおよびアクセス・ポリシーを作成するには
Fusion Middlewareアプリケーションがない場合: OAMCfgToolを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/ias/htdocs/idm_11g.html
Oracle Access Manager 10g（10.1.4.3）WebGate for Oracle HTTP Server 11gのOAMCfgTool ZIPファイルを見つけます。
oamcfgtool<version>.zip
|
注意: Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするOAMCfgToolのダウンロード元は、変更される可能性があります。その場合、リリース・ノートを参照して最新情報を確認してください。 |
oamcfgtool.jarを抽出し、Webゲートをホスティングしているコンピュータにコピーします。
保護するアプリケーションをホスティングしているコンピュータにログインし、OAMCfgToolが含まれているファイル・システム・ディレクトリに移動します。
|
注意:
|
Webゲート・プロファイル、認証スキームおよびポリシー・ドメインを作成します。表10-3の説明に従って、環境に適した値を使用して次のコマンドを実行します。次に例を示します。
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を実行して、作成されたポリシー・ドメインを検証します（表10-4を参照）。次に例を示します。
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 Access Manager System Administration Guide』のアクセス・ゲートおよびWebゲートの構成に関する項 |
アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。
マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。次に例を示します。
http://hostname:port/access/oblix
hostnameはWebパスのWebサーバーをホストするコンピュータで、portはWebパスのWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
「アクセス・システム構成」→「アクセス・ゲート構成」をクリックします。
「すべて」ボタンをクリックしてすべてのプロファイルを検索し（または、リストから検索属性と条件を選択し）、「実行」をクリックします。
Webゲートの名前をクリックして、その詳細を表示します。
「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、『Oracle Access Manager System Administration Guide』の説明に従って値を変更します。
保護するアプリケーションごとに、手順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 Securing 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 Access Manager IDアサーション・プロバイダによるシングル・サインオンを実行するために、WebLogicセキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。
次の手順では、WebLogic管理コンソールを使用します。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。手順1を省略してください。 |
シングル・サインオン用のOracle Access ManagerプロバイダをWebLogicドメインに設定するには
Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/ias/htdocs/idm_11g.html
Oracle Access Manager 10g（10.1.4.3）WebGate for Oracle HTTP Server 11gのoamAuthnProvider ZIPファイルを見つけます。
oamAuthnProvider<version number>.zip
|
注意: Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするoamAuthnProvider ZIPのダウンロード元は、変更される可能性があります。その場合、リリース・ノートを参照して最新情報を確認してください。 |
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
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を再起動します。
次の手順を実行します。
成功: 「Oracle Access Manager IDアサーション・プロバイダのログイン・フォームの設定」に進みます。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「必須コンポーネントおよびファイル」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
この項では、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダで提供されるログイン・フォームの概要を示し、このフォームをデプロイするための手順について説明します。
図10-11のフォームは、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" <LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
次の手順を参考にして、環境に適したログイン・フォームを設定してください。
Oracle Access Manager IDアサーションのログイン・フォームを設定するには
アプリケーションをホスティングしているコンピュータの次のOracle HTTP Server11g Webゲート・パスに、ログイン・フォームが存在することを確認します。
WebGate_install_dir/access/oamsso/login.html
ブラウザから、次のURLにアクセスします。
http://WebGatehost:port/oamsso/login.html
ログイン・プロセスで認証ユーザーを、元のリクエストしたアプリケーションURLにリダイレクトできるようにするために、ポリシー・マネージャのリソースを保護するように/accessポリシーが作成および有効化されていることを確認します。
次の手順では、Oracle Access Manager IDアサーションの設定をテストする方法について説明します。
もう1つの方法として、『Oracle Access Manager System Administration Guide』で説明されているように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストできます。
シングル・サインオン用のOracle Access Manager IDアサーションを検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。次に例を示します。
http://ohs_server:port/<protected url>
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「プロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
Oracle Access Manager認証プロバイダを構成するには、この項の各タスクを実行する必要があります。
前提条件
IDアサーション固有の手順として特に明記されていないかぎり、「Oracle Access Managerプロバイダの必須コンポーネントのインストールおよび設定」で説明されているすべてのタスクを完了する必要があります。
コンポーネントとファイルのインストールでは、アクセス・システム・コンソールでアクセス・ゲート・プロファイルを手動で作成したり、ポリシー・マネージャの設定中にデフォルトを受け入れます。
Oracle Access Manager証明書のJavaキーストア形式への変換は、Oracle Access Managerが簡易または証明書トランスポート・セキュリティ・モードで構成されている場合に必要です。
Oracle Access Manager認証プロバイダを構成するためのその他のタスクについては、次のタスク概要で説明します。
|
注意: この項のタスクを実行するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。Oracle Access Manager以外に、このタスクを自動化できるツールはありません。 |
タスク概要: Oracle Access Manager認証プロバイダの構成
前提条件のすべてのタスクが実行されていることの確認
この項では、ポリシー・ドメインにおける認証スキームの作成方法について説明します。ポリシー・ドメインは、後で認証プロバイダに対して定義します。Oracle Access Manager認証スキームは、ポリシー・ドメインの前に作成しておく必要があります。
|
注意: このタスクは、Oracle Access Managerのアクセス・システム・コンソールで実行する必要があります。このタスクでは、OAMCfgToolを使用できません。 |
認証プロバイダを使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、ポリシー・ドメインではOracle Access Manager認証スキームが必要です。
この項の内容は次のとおりです。
Oracle Access Managerの各ポリシー・ドメインには、1つの認証スキームと複数の認証アクションを含む認証ルールが、少なくとも1つ存在する必要があります。Oracle Access Manager認証プロバイダは、資格証明の認証とユーザー名に基づいたロール・フェッチという、2つの操作を実行します。
Oracle Access Manager認証スキームの作成中に、このスキームに一意の名前とオプションの説明を入力します。スキーム・レベルは、このスキームの相対セキュリティ・レベルに対応する番号になります。このレベルが高いほど、よりセキュアであるとみなされます。
Oracle Access Manager認証プロバイダは、資格証明の認証とユーザー名に基づいたロール・フェッチという、2つの操作を実行します。認証プロバイダでは、スキームのチャレンジ・メソッドが「なし」に指定されるため、チャレンジ・パラメータは不要です。ただし、各スキームには1つ以上のステップが含まれており、それぞれのステップには、認証プロセスの一部を実行するプラグインを1つ以上含めることができます。シングルステップ・スキームまたはマルチステップ（連鎖）スキームには、認証フローが必要です。
認証スキームの詳細は、『Oracle Access Manager System Administration Guide』の「ユーザー認証の構成」を参照してください。
次の手順を実行して、アクセス・システム・コンソールで認証スキームを作成できます。
Oracle Access Manager認証プロバイダの認証スキームを作成するには
アクセス・システム・コンソールで、「アクセス・システム構成」→「認証管理」→「追加」をクリックします。
次のように、認証プロバイダが使用するポリシー・ドメインの認証スキームを作成します。
「一般」タブ: 認証プロバイダで使用する次の情報を入力および保存します。
名前: ユーザー名解決。
説明: 認証プロバイダの認証スキーム。
レベル: 1。
チャレンジ・メソッド: なし。
チャレンジ・パラメータ:
SSL必須: いいえ。
チャレンジ・リダイレクト: （空白）。
有効: （空白）。
「プラグイン」タブ: 既存のOracle Access Manager認証スキームからのcredential_mappingプラグインを使用します。
表10-5 認証スキームのプラグイン
| プラグイン名 | プラグインのパラメータ |
|---|---|
|
credential_mapping |
obMappingBase="o=company,c=us",obMappingFilter="(&(&(ob jectclass=inetOrgPerson)(uid=%userid%))(|(!(obuseraccou ntcontrol=*))(obuseraccountcontrol=ACTIVATED)))" |
obMappingBase: LDAPディレクトリ・サーバーにおけるユーザー検索のベースDN。
obMappingFilter: 特定のユーザーIDを持つユーザーを検索するために使用されるLDAPフィルタ。ディレクトリ・ログイン属性は、アイデンティティ・システムでセマンティック・ログイン・タイプを使用して定義されます。
|
注意: フィルタでは、空白を使用できません。ポリシー・マネージャでは、credential_mappingフィルタ文字列は検証されません。誤ってエラーを含んだフィルタを入力した場合でも、保存中にエラーは発生しません。ただし、フィルタは失敗し、プラグインを実行するたびに「認証に失敗しました」が返されます。 |
少なくとも1つのプラグインを作成した後、デフォルト・ステップとデフォルト認証フローが自動的に作成されます。
認証スキームの有効化: 「一般」タブ→「変更」をクリックします。「有効化」の隣にある「はい」をクリックしてから、「保存」をクリックします。
アクセス・サーバーを再起動します。
認証プロバイダの認証スキームを作成した後、そのスキームを使用するには、Oracle Access Managerでポリシー・ドメインを作成する必要があります。
Oracle Access Managerのポリシー・ドメインには、各種の情報が含まれています。図10-12に示されているように、個別のタブにそれぞれの詳細を入力できます。
図10-12 Oracle Access Managerポリシー・マネージャの「ポリシー・ドメインの作成」ページ
詳細は、次の各項を参照してください。
この項では、ポリシー・マネージャの各タブについて説明します。これらのタブを使用してポリシー・ドメインとアクセス・ポリシーの詳細を入力できます。ポリシー・ドメインのすべてのタブを使用しない場合もありますが、次のような一般情報が提供されます。
「一般」タブ: このポリシー・ドメインの名前を指定する簡潔な英数字の文字列を入力します。「名前」フィールドでは、空白を使用できます。説明はオプションです。すべての詳細を保存し、ドメインを使用する準備が整うまで、このポリシー・ドメインを有効にしないでください。
「リソース」タブ: このポリシー・ドメインによって保護されるリソースを追加します。URL接頭辞を使用して、ポリシー・ドメインのコンテンツを定義します。説明はオプションです。
「認可ルール」タブ: 認可ルールを指定します。認可ルールは、一般情報、「アクセスの許可」と「アクセスの拒否」の各条件、および後で認可条件式で使用されるルールのアクション（存在する場合）で構成されます。定義するそれぞれの認可ルールに対し、1つの認証スキームを指定する必要があります。
「デフォルト・ルール」タブ: リソースが特定のポリシーによって保護されている場合を除き、ポリシー・ドメインによって保護されるリソースに適用するデフォルト・ルールを作成します。このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加します。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームと複数の認証アクションを指定します。
認可条件式: これには、認可ルールとそれらを組み合せる演算子が含まれています。
監査ルール: マスター監査ルールが定義されていない場合は、アクセス・システム管理者に連絡するよう指示されます。
「ポリシー」タブ: ルールが定義されていない場合、ポリシー・ドメインのデフォルト・ルールが有効です。作成した各ポリシーに対して、特定の認証ルール、認可条件式および監査ルールを割り当てることができます。詳細に記載されたURLパターンを使用して、ポリシーを作成できます。ポリシーを設定する前に、保護するURLに対して必要なアクセス制御レベルを決定してください。
「委任管理者」タブ: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。
|
関連項目: 「認証プロバイダのポリシー・ドメインとアクセス・ポリシーの作成」、および『Oracle Access Manager System Administration Guide』の次の各項
|
認証プロバイダの実装では、ポリシー・ドメインにいくつかのデフォルト値と一意の値を指定する必要があります。ポリシー・ドメインを作成、表示または変更するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。
次の手順では、認証プロバイダに対して次のようなポリシー・ドメインを作成します。
（ポリシー・マネージャで設定された）デフォルトのBasic認証スキームを内部的に使用して、ユーザーを認証し、/Authen/Basicという接頭辞の付いたURLリソースを保護します。
以前に定義されたタイプwl_authenのリソースを保護します。「Oracle Access Managerでのリソース・タイプの作成」も参照してください。
以前に作成したOracle Access Manager認証スキームを使用して、ユーザーの資格証明をリクエストします。「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 Access Manager System Administration Guide』のポリシー・ドメイン管理の委任に関する項 |
この項では、WebLogicドメインに適切な認証プロバイダを追加および構成するための手順について説明します。
Oracle Access Manager認証プロバイダは、WebLogicドメインのデフォルト認証プロバイダに従って構成する必要があります。
次の手順では、WebLogic管理コンソールを使用してこのタスクを実行する方法について説明します。これらは、Oracle WebLogic Scripting Tool（WLST）を使用して追加することもできます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、手順1は省略できます。 |
WebLogicドメインにOracle Access Manager認証プロバイダを構成するには
Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/ias/htdocs/idm_11g.html
Oracle Access Manager 10g（10.1.4.3）WebGate for Oracle HTTP Server 11gのoamAuthnProvider ZIPファイルを見つけます。次に例を示します。
oamAuthnProvider<version>.zip
|
注意: Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするoamAuthnProvider ZIPのダウンロード元は、変更される可能性があります。その場合、リリース・ノートを参照して最新情報を確認してください。 |
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
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 Deploying Applications to 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を再起動します。
認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。
次の手順では、認証プロバイダの設定をテストする方法について説明します。もう1つの方法として、『Oracle Access Manager System Administration Guide』で説明されているように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストできます。
Oracle Access Manager認証プロバイダの実装を検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。次に例を示します。
http://yourdomain.com:port
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「プロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
この項では、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では、アクセス・ゲートが必要です。 |
前提条件
コンポーネントとファイルのインストールでは、カスタム・アクセス・ゲート用にアクセス・システム・コンソールでアクセス・ゲート・プロファイルを手動で作成したり、ポリシー・マネージャの設定中にデフォルトを受け入れます。
Oracle Access Manager証明書のJavaキーストア形式への変換は、Oracle Access Managerが簡易または証明書トランスポート・セキュリティ・モードで構成されている場合に必要です。
タスク概要: 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でのリソース・タイプの作成」で定義した、タイプ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 Access Manager System Administration Guide』の第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 Access Manager System Administration Guide』のポリシー・ドメイン管理の委任に関する項 |
ポリシー・ドメインの検証: 「ポリシー・ドメイン」をクリックし、作成した新しいポリシー・ドメインをクリックした後、「ページとして表示」をクリックしてすべての詳細をまとめて表示します。
この項では、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アプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。手順1を省略してください。 |
WebLogicドメインでプロバイダを設定するには
Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/ias/htdocs/idm_11g.html
Oracle Access Manager 10g（10.1.4.3）WebGate for Oracle HTTP Server 11gのoamAuthnProvider ZIPファイルを見つけます。
oamAuthnProvider<version number>.zip
|
注意: Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするoamAuthnProvider ZIPのダウンロード元は、変更される可能性があります。その場合、リリース・ノートを参照して最新情報を確認してください。 |
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
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を再起動します。
次の手順を実行します。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「必須コンポーネントおよびファイル」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
Oracle Web Services Managerを使用している場合にOracle Access Manager IDアサーション・プロバイダの使用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスに成功した場合、実装は機能しています。失敗した場合は、「プロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
Oracle Access Managerでは、様々な方法でグローバル・ログアウトまたはSLO（シングル・ログアウト）が処理されます。この項では、Oracle Access Managerによってサポートされているオプションと、これらを統合するための異なるパスについて説明します。
Oracle Access Manager SSOユーザー・セッションの追跡は、ドメインのCookie、つまりObSSOCookieを使用して実行されます。Webゲートは、ObSSOCookieを検索します。Oracle Access Managerのグローバル・ログアウトまたはSLOは、単にObSSOCookieをクリアすることを意味します。ObSSOCookieがない場合、Webゲートは再認証ワークフローを実施します。
ObSSOCookieをクリアする方法の詳細は、次の各項を参照してください。
これは、Webゲートによって管理されるSLOの形式です。このモードでは、Webゲートは、文字列「logout.」が含まれているURLへのリクエストをすべてログアウトします。例外は、logout.gifまたはlogout.jpgなどのイメージ・ファイルです。これは、アプリケーションをOAM SLOと統合するための最も簡単な方法です。
ただし、logout.jspまたはlogout.htmlをアプリケーション・リソースの一部として含める必要があります。このURLを非保護にするために、特別なポリシーを使用する必要はありません。Cookieを削除するために、ページ内にロジックを組み込む必要はありません。
ゼロ構成SLOを実装するには
logout.jspまたはlogout.htmlをアプリケーション・リソースの一部として含めます。
オプション: ログアウト・ページをアプリケーションのホーム・ページに簡単にリダイレクトできます。
これも、Webゲートによって管理されるSLOの別の形式です。一連のログアウトURLを指定して、Webゲート/アクセス・ゲート・プロファイルでそれらをLogoutURLパラメータとして設定できます。
注意: WebゲートによるこれらのURLの比較には、問合せパラメータは含まれていません。Cookieを明示的にクリアするために、ログアウト・ページ内にロジックを組み込む必要はありません。たとえば、次の1行目には有効なURLが示され、2行目には、ログアウトURLに一致しないエントリの例が示されています。
/myapp/myapp.action/signout /myapp/myapp.action/do?logout=true
|
注意: ログアウトURLパラメータを指定すると、ゼロ構成SLO（「logout」文字列の一致）機能は失われます。つまり、ゼロ構成SLOを使用したり、ログアウトURLを指定することは可能ですが、これらの両方を行うことはできません。 |
アプリケーションでWebゲートによって管理されるSLOを使用しない場合は、アプリケーション固有の方法でSLOを処理できます。このモードでは、アプリケーションでログアウト・ページのリソースが定義されます。ページ・ロジックには、ObSSOCookieのクリアが組み込まれます。
すべてのWebゲートには、logout.htmlテンプレートが付属しています。アプリケーションでは、このテンプレートを参照として使用できます。このモードでは、Oracle Access Managerポリシーを使用してログアウト・リソースへのアクセスを非保護にすることも重要です。また、アプリケーションでは、ページをブランド化したり、ホーム・ページへのリダイレクトをログアウト・ロジックの一部として処理することができます。
アプリケーション管理SLOを実装するには
アプリケーションがWebゲートのlogout.htmlテンプレートを参照していることを確認します。
アプリケーションに対するOracle Access Managerポリシーによって、ログアウト・リソースへのアクセスが保護されていないことを確認します。
オプション: アプリケーションでは、ページを分岐したり、アプリケーションのホーム・ページへのリダイレクトをログアウト・ロジックの一部として処理することができます。
この項では、Oracle Access Manager認証プロバイダに関係する共通およびプロバイダ固有のパラメータを列挙します。これらのパラメータは、Oracle WebLogic管理コンソールで指定します。詳細は、次の各項を参照してください。
表10-6 Oracle Access Manager認証プロバイダの共通パラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
名前 |
プロバイダの名前。読取り専用。 |
|
説明 |
プロバイダの説明。読取り専用。 |
|
バージョン |
プロバイダのバージョン。読取り専用。 |
|
制御フラグ |
プロバイダJAAS制御フラグ。REQUIRED、REQUISITE、OPTIONALまたはSUFFICIENTの1つを設定します。複数の認証プロバイダを構成する場合、このフラグを使用してログイン・シーケンスでのそれらの使用方法を制御します。「JAAS制御フラグ」を参照してください。 |
|
アクティブなタイプ |
このパラメータは、Oracle Access Manager IDアサーション・プロバイダにのみ関連しています。このパラメータは、IDアサーション・プロバイダによって処理されるトークン・タイプを決定します。ObSSOCookieに設定します。 |
|
Base64でのデコーディングが必要 |
Falseは読取り専用（デフォルト）。 |
新しいセキュリティ・プロバイダを作成すると、WebLogic Server管理コンソールによって、JAAS制御フラグがOPTIONALに設定されます。すぐに使用できるセキュリティ・プロバイダのデフォルト値はREQUIREDです。制御フラグの詳細は、オンライン・ヘルプを参照してください。
表10-7は、Oracle Access Manager IDアサーション・プロバイダのプロバイダ固有のパラメータを示しています。
表10-7 シングル・サインオン用のIDアサーション・プロバイダのプロバイダ固有のパラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
トランスポート・セキュリティ |
アクセス・ゲートとアクセス・サーバーの間の通信モード。 |
|
プール内の最小アクセス・サーバー接続数 |
許可される最小接続数。デフォルト値は5です。 |
|
アクセス・ゲートのパスワード |
プロバイダによって使用されるアクセス・ゲートのパスワード。 |
|
キー・ストアのパスフレーズ |
キー・ストアにアクセスするためのパスワード。 |
|
アクセス・ゲート名 |
プロバイダによって使用されるアクセス・ゲートの名前。必須です。 |
|
プライマリ・アクセス・サーバー |
プライマリ・アクセス・サーバーの名前。host:portの形式に準拠していること。必須です。「Oracle Access Managerプロバイダの必須コンポーネントのインストールおよび設定」を参照してください。 |
|
プール内の最大アクセス・サーバー接続数 |
許可される最大接続数。デフォルト値は10です。1に設定します。 |
|
簡易モードのパスフレーズ |
簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。 |
|
トラスト・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。 |
|
SSOヘッダー名 |
OAM_REMOTE_USER |
|
セカンダリ・アクセス・サーバー |
セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。「Oracle Access Managerプロバイダの必須コンポーネントのインストールおよび設定」を参照してください。 |
|
キー・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。 |
表10-8は、Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータを示しています。
表10-8 Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
トランスポート・セキュリティ |
アクセス・ゲートとアクセス・サーバーの間の通信モード。 |
|
プール内の最大アクセス・サーバー接続数 |
許可される最大接続数。デフォルト値は10です。1に設定します。 |
|
簡易モードのパスフレーズ |
簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。 |
|
プール内の最小アクセス・サーバー接続数 |
許可される最小接続数。デフォルト値は5です。 |
|
トラスト・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。 |
|
取得したユーザー名をプリンシパルとして使用する |
Oracle Access Managerから取得したユーザー名をサブジェクトのプリンシパルとして使用するかどうかを指定します。 |
|
アクセス・ゲートのパスワード |
プロバイダによって使用されるアクセス・ゲートのパスワード。 |
|
キー・ストアのパスフレーズ |
キー・ストアにアクセスするためのパスワード。 |
|
アクセス・ゲート名 |
プロバイダによって使用されるアクセス・ゲートの名前。必須です。 |
|
セカンダリ・アクセス・サーバー |
セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。「Oracle Access Managerプロバイダの必須コンポーネントのインストールおよび設定」を参照してください。 |
|
キー・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。 |
|
プライマリ・アクセス・サーバー |
プライマリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。必須です。「Oracle Access Managerプロバイダの必須コンポーネントのインストールおよび設定」を参照してください。 |
表10-9に、このリリースに関する既知の問題を示します。ツール、パラメータおよび値の詳細は、「OAMCfgToolの使用について」を参照してください。
表10-9 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を省略します。
解決策:
Fusion Middlewareアプリケーションがない場合: OAMCfgToolを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/ias/htdocs/idm_11g.html
Oracle Access Manager 10g（10.1.4.3）WebGate for Oracle HTTP Server 11gのOAMCfgTool ZIPファイルを見つけます。
oamcfgtool<version>.zip
|
注意: Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするOAMCfgTool 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 Access Manager System Administration Guide』のアクセス・ゲートおよびWebゲートの構成に関する項 |
前述の手順を繰り返して、WebGateBを構成します。
アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。
マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。次に例を示します。
http://hostname:port/access/oblix
hostnameはWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
「アクセス・システム構成」→「アクセス・ゲート構成」をクリックします。
「すべて」ボタンをクリックしてすべてのプロファイルを検索し（または、リストから検索属性と条件を選択し）、「実行」をクリックします。
Webゲートの名前をクリックして、その詳細を表示します。
「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、『Oracle Access Manager System Administration Guide』の説明に従って値を変更します。
ロード・バランサのホスト識別子に、両方の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 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アサーション・プロバイダの実装時に想定される動作について説明します。この項の内容は次のとおりです。
図10-13は、OSSO IDアサーション・プロバイダを含む、Oracle WebLogicセキュリティ・フレームワーク内のコンポーネントの配置を示しています。詳細は、図の後に説明します。
図10-13 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では、このプラグインが次の名前になります。
|
図10-14は、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アサーション・プロバイダを構成してください。
表10-10は、Oracle HTTP Serverによって設定されるヘッダー（mod_ossoおよびmod_weblogic）のリストを示しています。アプリケーション・ロジックで、ユーザー情報の識別にJAASサブジェクトを使用するアプリケーションは、OSSO IDアサーション・プロバイダを使用するよう構成されている必要があります。OSSO IDアサーション・プロバイダは、表内の太字で示されているOracleAS SSOトークン・タイプ（Proxy-Remote-User）を使用します。OSSO IDアサーション・プロバイダはProxy-Remote-Userヘッダーを検索し、ユーザーのアイデンティティをアサートします。その後、OID認証プロバイダがJAASサブジェクトを移入します。
表10-10 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 Getting Started With Installation for 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を登録する必要があります。表10-11は、このために使用するパラメータと値の概要を示しています。登録ツールを実行すると、osso.confファイル内のmod_osso登録レコードが更新されます。このツールを実行するたびに、このファイルが生成されます。
表10-11 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は、このようなディレクティブの組込み方法を示しています。対応する静的アプリケーションと同様、これらの動的サンプル・アプリケーションではユーザー情報が生成されます。
例10-1 動的ディレクティブによる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） |
例10-2 動的ディレクティブによる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サーバーが実行されているホストのみからリクエストを受け入れることができます。
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。このフィルタを使用すると、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。ネットワーク接続フィルタは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。
接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。
targetAddress localAddress localPort action protocols
|
関連項目: 『Oracle Fusion Middleware Securing Oracle WebLogic Server』のWebLogicドメインのセキュリティの構成に関する項 |
表10-12は、接続フィルタの各パラメータを説明しています。
表10-12 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
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を指定します。
カスタム接続フィルタを構成するには、「接続フィルタ」属性に、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、WebLogic ServerのCLASSPATHにも指定する必要があります。
接続フィルタ・ルールの構文を入力します。
「適用」をクリックします。
Oracle WebLogic Serverを再起動します。
この項では、OSSO IDアサーション・プロバイダ用のアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Deploying Applications to 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にアクセスできるかどうかを確認します。
この項では、次のトラブルシューティング項目について説明します。
エラー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用のグローバル・ログアウトの構成」を参照してください。
アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。
様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shでEXTRA_JAVA_PROPERTIESを確認します。表10-13に、各プロパティと同期動作を示します。
表10-13 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>
