| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-03 |
|
 前 |
 次 |
ここでは、Oracle Access Manager 11gを使用したシングル・サインオンの構成について説明します。内容は次のとおりです。
Oracle Access Manager 11gは、Oracleのエンタープライズ・クラス・スイートのセキュリティ製品に属しています。新規のSSOデプロイメントと既存のSSOデプロイメントでの使用を目的としたOracle Access Manager 11gは、Webシングル・サインオン、認証と認可、ポリシー管理などの広範なWeb境界セキュリティ機能を提供します。
Oracle Access Manager 11gシングル・サインオン(SSO)およびシングル・ログアウト(SLO)は、次のような様々なアプリケーション・プラットフォームをサポートします。
SOA
WebCenter
Oracle Fusion Middleware Oracle Access Manager統合ガイドの説明にあるように、Oracle Access Manager 11gは次のような様々なアプリケーションとの統合をサポートしています。
Oracle Identity Navigator
Oracle Identity Federation
Oracle Identity Manager
Oracle Adaptive Access Manager
Oracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Manager 11gは、アイデンティティ管理機能がOracle Identity Manager 11gに委ねられるという点でOracle Access Manager 10gと異なります。Oracle Access Manager 11gには、ユーザー・セルフサービスおよび自己登録、ワークフロー機能、動的グループ管理、アイデンティティ管理の委任などの機能が用意されています。
Oracle Identity Managementアプリケーションのコンソール保護
Oracle Access Manager 11gおよびその他のOracle Identity Managementアプリケーションは、WebLogicコンテナにデプロイされています。個々の管理コンソールには、Oracle Access Manager、Oracle Adaptive Access Manager、Oracle Identity Navigator、Oracle Identity Manager、Oracle WebLogic Server、Oracle Authorization Policy Managerなどがあります。
これらは、デフォルトで、WebLogic管理コンソールの事前構成済の認証プロバイダおよび事前登録済のOracle Access Manager 11gのIDMドメイン・エージェントで保護されています。OAM 11g SSOポリシーは事前シード済です。コンソールをこれ以上構成する必要はありません。
OAM 11gデプロイメントのプレビュー
新規WebLogic管理ドメインまたは既存のWebLogic管理ドメインで、Oracle Fusion Middleware構成ウィザードを使用してOracle Access Managerを構成できます。
「Oracle Access Managerで使用されるプロバイダの要件」を参照してください。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』 |
Oracle Access Manager 11gには、新規または既存のポリシー適用エージェントとの下位互換性を保持する新しいサーバー側のコンポーネントが用意されています。サーバー側で開始する動的な更新が、ポリシーや構成に対するあらゆる変更で実行されます。
OAM 10gポリシー・マネージャにかわって、OAM管理コンソール(WebLogic Administration Serverにインストール)が稼働します。
OAM 10gアクセス・サーバーにかわって、OAMサーバー(WebLogic管理下サーバーにインストール)が稼働します。
Oracle Access Manager 11gは、リソースを保護する次のような登録済エージェントの任意の組合せに対し、シングル・サインオン(SSO)、認証、その他の認可などのサービスを提供します。
11g Webゲート
10g Webゲート
JavaベースのIDMドメイン・エージェント
OSSOエージェント(10g mod_osso)
Oracle Access Manager 11gは、現在Oracle ADFのセキュリティとOPSS SSOフレームワークを使用しているどのWebアプリケーションとも統合できます。
Oracle Access Manager管理コンソールへのログインやOAM管理コマンドライン・ツールの使用は、適切な権限を持ったユーザーにのみ許可されています。企業によっては、OAM管理を担当するユーザーとWebLogic管理を担当するユーザーに別の管理者グループが必要になることがあります。詳細は、Oracle Access Managerシステム管理ガイドの新しいOAM管理者ロールの定義に関する項を参照してください。
OAM 11gの概要
Oracle Access Manager 11gの基本機能の概要は、次のとおりです。
プロビジョニング/リモート登録: 新しいリモート登録ツールにより、ネットワーク内外の管理者はエージェントとポリシーを登録できます。OAM 11gのプライマリ・ユーザー・アイデンティティ・ストアにユーザー名とパスワードを設定する必要があります。
認証: Oracle Access Manager 11gアプリケーション・ドメインは、リソースとセキュリティ・ポリシー(リソースごとに1つのポリシー)を集約します。Oracle Access Manager 11gの認証ポリシーには、固有のスキームがあります。サポートされる認証モジュールには、LDAP、X.509、Kerberosなどがあります。認証ユーザーは、集中管理された資格証明コレクタによってプライマリ・ユーザー・アイデンティティ・プロバイダにマッピングされます。
認可: アプリケーション・ドメインで定義して、データベースで永続化したセキュリティ・ポリシーに基づいて、Oracle Access Manager 11gで認可が実行されます。認可ポリシーはリソースと制約の評価を定義します。
レスポンス: 管理者は、認証レスポンスと認可レスポンスを使用してセッション属性を設定できます。セッションの属性以外に、ユーザー関連のデータおよびリクエスト関連のデータもレスポンスで取得できます。設定したレスポンスは、その立証に効果的なエージェントにHTTPヘッダーまたはCookieとして送信されます。Cookieの値およびヘッダーの変数に対し、レスポンスは別のレスポンスで事前に設定されたセッション属性を取得できます。たとえば、レスポンスによって認証時に設定されたセッション属性を、認可の際にヘッダー値として取得できます。
セッション管理: Oracle Access Manager 11gセッション管理サービスでは、Oracle Coherenceのテクノロジに基づく高パフォーマンス分散キャッシュ・システムを介してアクティブ・ユーザー・セッションを追跡します。各Oracle Access Managerの実行時インスタンスは、この分散キャッシュ・システムにあるノードとなります。これらのノード間のセキュアな通信は、対称鍵を使用すると容易に実行できます。Oracle Access Managerの実行時インスタンスは、ローカルのキャッシュにあるユーザー・セッション・データを分散キャッシュに移動して、他のノードから選択できるようにします。また、Oracle Access Managerの実行時インスタンスごとにレプリケーション・ファクタを構成して、セッション・データをどのように分散するかを指定することもできます。管理者は、セッションのライフサイクルの構成、固有のアクティブ・セッションの検索と削除、任意の時点でユーザーが同時に実行できるセッション数の制限などが可能です。バンド外のセッションを終了すると、ユーザーがセッションを終了した後でシステムへの認可されないアクセスを防止します。
キー: Oracle Access Manager 11gのランタイムは、アプリケーションとしてWebLogic管理対象サーバーまたはクラスタにデプロイされます。新しいOracle Access Manager 11g WebGatesは、エージェントの信頼モデルごとに機密情報の共有をサポートします。11g Webゲートでは、エージェントとホストに固有のCookieを使用して優れたセキュリティを実現できます。Oracle Access Manager 11g Webゲートは、すべて同レベルで信頼されます。Webゲートにはそれぞれに固有のCookieが設定されるので、あるWebゲートのCookieを使用しても、他のWebゲートで保護されたアプリケーションにユーザーにかわってアクセスすることはできません。これにより、Cookieリプレイ・タイプの攻撃から防御できます。
SSOおよびSLO: Oracle Access Manager 11gサーバー・セッション・トークンは、Oracle Access ManagerとOSSOエージェント間のSSOの基礎を形成します。ログアウトは、Oracle Access Manager 11gサーバーのグローバル・ログアウトで実行します。これにより、中央のセッションは終了し、ユーザーはアクセスした各エージェントからログアウトします。
Oracle Access Manager 10g Webゲートでは、ログアウトによりObSSOCookieが削除され、グローバル・ログアウトページにリダイレクトされます。
Oracle Access Manager 11gのWebゲートおよびmod_ossoエージェントでは、ログアウトはグローバル・ログアウトページにリダイレクトされ、各エージェントはエージェント固有のCookieを削除するためにコールバックされます。
ロギングと監査: Oracle Access Manager 11gコンポーネントでは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとロギング・ガイドラインを使用します。Oracle Access Manager 11gでは、エージェントとサーバーの監視機能が用意されています。Oracle Access Manager 11gの監査機能は共通監査フレームワークに基づいています。監査レポートの生成は、Oracle Business Intelligence Publisherによりサポートされています。
アクセス・テスター: Oracle Access Manager 11gの新しいアクセス・テスターを使用すると、IT専門家や管理者は登録されたOracle Access Managerエージェントとサーバー間の相互作用をシミュレートできます。これは、セキュリティ・ポリシー定義のテストやエージェントの接続が関係する問題のトラブルシューティングで役立ちます。
テストから本番への移行: Oracle Access Manager 11gを使用して、構成やポリシーのデータを1つのOracle Access Manager 11gデプロイメントから別のデプロイメントに移動できます(小規模なテストデプロイメントから本番デプロイメントへの移動など)。テンプレートに基づく新規トポロジの作成がサポートされています。ポリシーに対する変更のコピーや移動も可能です。
OSSO 10gとの共存およびOSSO 10gのアップグレード: Oracleが提供するUpgrade Assistantは、既存のOracleAS 10g SSOサーバー構成をスキャンし、10g OSSOポリシー・プロパティ・ファイルおよびスキーマ情報を入力として受け入れ、構成済のパートナ・アプリケーションを移行先のOracle Access Manager 11g SSOに転送します。
|
関連項目:
|
Application Authenticatorアプリケーション・ドメインはOAM 11gで提供されます。これは、OAM認証プロバイダをセキュリティ・プロバイダとしてWebLogic環境にデプロイしたアプリケーションとの統合を実現するポリシー・オブジェクトによって事前シードされています。これは、Webゲートのプロビジョニングに関連付けられていません。このドメイン(または既存のアプリケーション・ドメイン)を使用するためにWebゲートまたはアクセス・ゲートをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。
OAM認証プロバイダ(およびOracle Web Services Manager用IDアサーション・プロバイダ)で使用するカスタムの10gアクセス・ゲートで、Application Authenticatorアプリケーション・ドメインが機能するようになりました。この場合、カスタムのアクセス・ゲート(Webゲートではありません)が、OAM 11gにアクセスする前のユーザーを認証するためのトークンを使用して、WebLogic Serverに直接アクセスします。
Application Authenticatorアプリケーション・ドメインは、タイプwl_authenのリソースのみを保護し、2つの認証ポリシーと1つの認可ポリシーでシードされます。次のwl_authenリソースもこのドメインにシードされます。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion(LDAPNoPasswordValidationSchemeによって保護)
|
注意: このドメインで許可されているのは、タイプwl_authenのリソースのみです。他のリソース・タイプは追加できません。wl_authenリソースのポリシーとレスポンスは追加可能です。ただし、このドメインの変更が不要であることが理想です。 |
図15-1は、OAM 11g管理コンソールにシードされたApplication Authenticatorアプリケーション・ドメインの詳細を示しています。このページは、/Authen/UsernameAssertionリソースを保護する、事前シード済の認証ポリシーUser ID Assertionを示しています。このポリシーで保護しているリソースのほかに、ポリシーの認証スキームも表示されています。
図15-2は、User ID Assertion認証ポリシーに事前シードされたレスポンスを示しています。レスポンスの詳細は、Oracle Access Managerシステム管理ガイドを参照してください。
図15-3は、事前シード済の認証ポリシーApplication SSO、このポリシーで保護されたリソースおよび認証スキームを示しています。
図15-4は、アプリケーション・ドメインに事前シードされた認証ポリシーApplication SSOのレスポンスを示しています。
図15-5は、アプリケーション・ドメインに事前シードされた認可ポリシーApplication SSOとリソースを示しています。
認可の制約: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOの制約がありません。ただし、Oracle Access Managerシステム管理ガイドの説明に従って制約を追加することはできます。
認可のレスポンス: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOの制約がありません。ただし、Oracle Access Managerシステム管理ガイドの説明に従ってレスポンスを追加することはできます。
この項では、WebLogicコンテナにデプロイしたアプリケーションまたはそこにデプロイする予定のアプリケーションがある場合に、認証プロバイダでOAM 11gを実装する方法を説明します。
この項の内容は次のとおりです。これらは、アプリケーションをWebLogicコンテナにデプロイする場合のOAM 11g SSOの実装で役に立ちます。ここで取り上げているOAMソリューションの実装は、OAM 11gに固有なもの以外は、OAM 11gとOAM 10gのどちらでも同じです。
次の概要では、認証プロバイダを使用してOracle Access Manager 11g SSOソリューションに必要なコンポーネントとファイルをインストールする際に完了する必要があるタスクについて説明します。Oracle Access Manager 11gとOracle Access Manager 10gとでは、これらのタスクの多くはほとんど同じですが、いくつかの相違点があります。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Access Manager 11gのインストールと初期構成の詳細に関する項 |
タスクの概要: 認証プロバイダおよびOAM 11gで使用するコンポーネントのインストール
Oracle Access ManagerのOracle Internet Directoryをインストールおよび設定します。
|
関連項目:
|
Oracle WebLogic Server 10.3.1以降をインストールおよび設定します。
|
関連項目: このリストの手順3および『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』 |
オプション: Fusion Middleware製品(Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど)をインストールします。
|
注意: Fusion Middlewareアプリケーションがインストールされていない場合は、以降の手順に従って、必要なJARファイルおよびWARファイルを入手する必要があります。 |
必要に応じて、Oracle Access Manager Webゲート用にOHS 11gをインストールします。
IDアサーション・プロバイダ: Oracle HTTP Server 11gのWebサーバーが、Oracle WebLogic Serverのフロントエンドにリバース・プロキシとして構成されている必要があります。
認証プロバイダまたはOracle Web Services Manager: カスタム・アクセス・ゲートでは、Webサーバーは必要ありません。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。
認証プロバイダ・ファイル: 次のように必要なJARファイルとWARファイルを確認します。
次のFusion Middlewareパスで、必要なJARファイルの場所を確認します。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
次のパスで、コンソール拡張WARファイルを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov ider.war
WARファイルを、WebLogic Serverホームの次のパスにコピーします。
WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
Oracle Access Manager 11g:
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明されているように、Oracle Access Managerをインストールして、初期構成を実行します。
Webゲートに1つのプライマリOAMサーバーと1つのセカンダリOAMサーバーを組み込みます。設定できるセカンダリ・サーバーは1つのみです。
Webゲート(シングル・サインオン用のIDアサーション・プロバイダで使用): 1つ以上のWebゲートが存在する既存のWeb層では、プロビジョニングのみが必要です。新規Web層では、新しいWebゲートをインストールする必要があります。
どちらの場合にも、「Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」を参照してください。
認証プロバイダ(またはOracle Web Services Manager)用のアクセス・ゲート:
「Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」(または、認証プロバイダの構成時に既存のOAMエージェントの登録を参照)に説明されているように、10gアクセス・ゲートをプロビジョニングできます。
oamAuthnProvider.jarで使用できるカスタム10gアクセス・ゲートをデプロイします。
プロビジョニングとは、OAM 11gの認証と認可のサービスを使用するために、エージェントを登録してアプリケーション・ドメインを作成するプロセスです。新しい11gインスタンスまたは10gインスタンスをインストールする場合でも、レガシーの10g Webゲートがインストール済の場合でも、OAM 11gでWebゲートをプロビジョニングする必要があります。
用語としてのWebゲートは、複数のWebゲートを表します(Oracle Web Services Managerの認証プロバイダおよびIDアサーション・プロバイダで使用するカスタムの10gアクセス・ゲートも指します)。特に明記されていなければ、この項の内容は両方に同様に当てはまります。
複数のエージェントがある場合、それぞれを別々にプロビジョニングできるほか、複数のエージェントに単一のOAMエージェント登録を使用することもできます。
|
注意: Application Authenticatorアプリケーション・ドメインは事前シード済で、OAM 11gで提供されます。このアプリケーション・ドメイン(または別の既存のアプリケーション・ドメイン)を使用するためにOAMエージェントをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。 |
この項の内容は次のとおりです。
表15-1は、OAM 11gで使用するWebゲートのプロビジョニングに使用できるメソッドとツールの概要を示しています。リモート登録ツールを使用すると、テンプレートを使用して一部またはすべてのWebゲート・パラメータを指定できます。
表15-1 OAM 11g用のメソッドのプロビジョニング
| メソッド | 説明 |
|---|---|
|
Oracle Access Manager管理コンソール |
Oracle Access ManagerでOAMの管理者が手動で情報を入力し、直接パラメータを設定できるようにします。この方法は、認証プロバイダを使用している場合、またはOracle Web Services ManagerポリシーでWebサービスを保護している場合に必要です。 |
|
リモート登録 |
アプリケーションの管理者は、シングル・サインオン用のIDアサーション・プロバイダを実装する際に、コマンドラインを使用してWebゲートを登録できます。また、これによって新しいWeb層または既存のWeb層のセキュリティ・ポリシーを持つ新規アプリケーション・ドメインが作成されます。 必須パラメータは、テンプレートで指定する、環境に適した値を使用してプロビジョニングします。必須ではないパラメータについては、デフォルト値を使用します。登録が終了すると、OAM管理コンソールで値を変更できるようになります。 |
リモート登録の際には、表15-2に記載された詳細を指定する必要があります。
|
関連項目: Webゲート・パラメータすべてのリストは、Oracle Access Managerシステム管理ガイドを参照してください。 |
表15-2 OAMエージェントに必須の登録の詳細
| OAMエージェントの要素 | 説明 |
|---|---|
|
<serverAddress> |
ホストとポートを含む、Oracle Access Manager管理コンソールの実行中のインスタンスを指します。 |
|
<webDomain> OSSOリクエスト専用 |
エージェント・ベースのURLが内部的に保存されているWebサーバー・ドメインを定義します。 |
|
<agentName> |
OAM(管理)サーバーでのエージェントの一意な識別子を定義します。 同じサーバー・インスタンス上のエージェントごとにこのタグは一意にして、同一エージェントの再登録を回避する必要があります。 同一のサーバー・インスタンス上で1つのエージェントを再登録することはできません。 |
|
<hostIdentifier> |
この識別子は、Webサーバーのホストを表しています。このフィールドは、OAMエージェント名の値を指定すると自動的に入力されます。同じ名前のエージェント名またはホスト識別子がすでに存在する場合には、登録時にエラーが発生します。 |
|
<protectedResourcesList> |
一部の認証スキームでOAMエージェントを保護するリソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。 |
|
<publicResourcesList> |
公開する(OAMエージェントで保護しない)リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。 |
Webゲートやアクセス・ゲートのプロビジョニングには、前述と同じ手順を実行します。認証プロバイダで使用する新規インスタンスのプロビジョニングや、プロバイダを構成する際に既存の登録の参照などができます。
この例では、OAMRequest_short.xmlテンプレートを使用してOAM 10g Webゲートをプロビジョニングします。登録されたエージェントは、my-wl-agent1と名付けられ、/.../*を保護し、パブリック・リソースの/public/index.htmlを宣言します。なお、実際に指定する値は各環境によって異なります。
|
注意: OAM 11g Webゲートのプロビジョニングでは、OAM11gRequest_short.xmlテンプレートを使用します。 |
|
関連項目: Oracle Access Managerシステム管理ガイド |
ツールの入手: Webゲートをホストするコンピュータ上でリモート登録ツールを入手し、使用する環境に合せてスクリプトを設定します。例:
次のパスでRREG.tar.gzファイルを見つけます。
WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz
RREG.tar.gzファイルを任意の適切な場所に展開します。例: rreg/bin/oamreg。
oamregスクリプトで、使用状況がクライアント側であるかサーバー側であるかに応じて次の環境変数を設定し、さらにOracle Access Managerシステム管理ガイドの表6-7の情報を設定します。
登録リクエストの作成:
*Request_short.xmlファイルを探し、新しい場所にコピーして名前を付けます。例:
WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
コピー元ファイル: OAMRequest_short.xml(またはOAM 11gRequest.xml)
コピー先ファイル: my-wl-agent1.xml
my-wl-agent1.xmlを編集して、環境の詳細を指定し、自動ポリシーの作成をfalseに設定します。例:
<OAMRegRequest>
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>my-wl</hostIdentifier>
<agentName>my-wl-agent1</agentName>
<primaryCookieDomain>.us.example.com</primaryCookieDomain>
<autoCreatePolicy>false</autoCreatePolicy>
<logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
</OAMRegRequest>
|
関連項目: Oracle Access Managerシステム管理ガイドの登録リクエストの作成に関する項を参照してください。 |
エージェントをプロビジョニングします。例:
リモート登録スクリプトを見つけます。
chmod +x oamreg.shWindowsの場合: rreg\bin\oamreg.bat
スクリプトが存在するディレクトリから、inbandモードを使用してこのスクリプトを実行します。例:
$ ./bin/oamreg.sh inband input/my-wl-agent1.xml
Welcome to OAM Remote Registration Tool! Parameters passed to the registration tool are: Mode: inband Filename: ...
プロンプトが表示されたら、環境に応じた値を使用して次の情報を入力します。
Enter your agent username: userame Username: userame Enter agent password: ******** Do you want to enter a Webgate password?(y/n) n iv.Do you want to import an URIs file?(y/n) n
最後のメッセージを参照して、正常な登録が行われたことを確認します。
Inband registration process completed successfully! Output artifacts are created in the output folder"
コンソールの確認: OAM管理コンソールにログインして、新規登録を確認します。
OAM 11gコンソールの「システム構成」タブでナビゲーション・ペインに移動して「エージェント」ノードを開き、次のようにプロビジョニングしたエージェントを見つけます。
エージェント名をダブルクリックして登録のページを表示し、詳細を確認します。これは後で使用します。例:
エージェント名: Webゲートのインストール時に、WebゲートIDとして入力します。カスタム10gアクセス・ゲートをデプロイする場合は、WebLogic管理コンソールでOAM認証プロバイダを構成する際に、これをアクセス・ゲート名として入力します。
アクセス・クライアント・パスワード: Webゲートのインストールの際に、Webゲートのパスワードとして入力します。パスワードを入力しなかった場合、このフィールドは空白のままでかまいません。
アクセス・サーバー・ホスト名: このWebゲートの登録先とするプライマリOAM 11gサーバーのDNSホスト名を入力します。
OAMプロキシ・ポート: OAM管理コンソールの「システム構成」タブでナビゲーション・ペインに移動し、「サーバー・インスタンス」をダブルクリックしてOAMプロキシが稼働しているポートを見つけます。
プロビジョニングの際に作成されたObaccessclient.xmlファイルは、この段階では無視します。
それぞれの環境に応じて次の手順を実行します。
エージェントをインストール済の環境: 実装に応じて、次の適切な項に移動します。
エージェントをインストールしていない環境:
11g WebGateの場合: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
10g Webゲート: Oracle Access Manager システム管理ガイドを参照してください。
この項では、シングル・サインオン用のOracle Access Manager 11g IDアサーションの構成に必要な固有の手順について説明します。
前提条件
Oracle Access Manager 11gでの認証プロバイダのインストール
Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
アプリケーションでシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを構成するには、次のタスクの概要で説明されている手順を実行します。
タスクの概要: OAM 11gでのSSO用IDアサーション・プロバイダのデプロイ
前提条件のすべてのタスクが実行されていることの確認
次の項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。
|
注意: このタスクはOAM 11g WebゲートとOAM 10g Webゲートの両方で同じです。 |
この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager IDアサーション・プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をCLIENT-CERTに指定する必要があります。
WebLogic Serverのhost:portを介して直接アプリケーションにアクセスし、コンテナで認証されるようにする場合は、ここにカンマで区切った複数の値を指定できます。たとえば、<auth-method>CLIENT-CERT,FORM</auth-method>とします。
auth-methodには、BASIC、FORMまたはCLIENT-CERTの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
IDアサーション・プロバイダのweb.xmlで認証を指定するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
my_app/WEB-INF/web.xml
login-configでauth-methodを検索し、CLIENT-CERTと入力します。
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
「Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認」に進みます。
Oracle HTTP Serverには、mod_weblogicプラグイン・モジュール(11gではmod_wl_ohs.so)が含まれており、すでに有効になっています。次の手順を実行してこれを確認するか、またはこの手順を省略できます。
Oracle HTTP Server 11gでは、mod_weblogic構成はデフォルトでmod_wl_ohs.confに存在し、このファイルのパスはhttpd.confに含まれています。mod_weblogic構成が存在しない場合は、httpd.confを編集する必要があります。
Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicを構成するには
httpd.confを見つけます。たとえば、次の場所にあります。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
ファイル内に次の文があり、デプロイメントに適した値が指定されていることを確認します(必要に応じてコメントを追加または削除します)。
<IfModule mod_weblogic.c> WebLogicHost myHost.myDomain.com WebLogicPort myWlsPortNumber </IfModule> <Location http://request-uri-pattern> SetHandler weblogic-handler </Location>
ファイルを保存します。
Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。
|
注意: この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。 |
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。これは、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。これは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。
接続フィルタを構成してmod_weblogicとOHS 11gが実行されているホストからのリクエストのみを許可するには、ここで説明する手順を実行します。
|
注意: この章では、Apache用WebLogic Serverプラグインの汎用名(mod_weblogic)を使用します。Oracle HTTP Server 11gでは、このプラグインの名前はmod_wl_ohsですが、実際のバイナリ名はmod_wl_ohs.soになります。後述する例は、実装可能な正確な構文を示しています。 |
WebLogic Serverでは、デフォルト接続フィルタweblogic.security.net.ConnectionFilterImplが提供されます。このフィルタは、すべての着信接続を受け入れ、サーバーによる現在の接続フィルタの取得を許可する静的ファクトリ・メソッドも提供します。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力します。
また、weblogic.security.netパッケージにクラスを実装することにより、カスタム接続フィルタを使用することもできます。デフォルト接続フィルタと同様、カスタム接続フィルタはWebLogic Server管理コンソールで構成します。
接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。
targetAddress localAddress localPort action protocols
表15-3は、接続フィルタの各パラメータを説明しています。
表15-3 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
target |
フィルタ対象の1つ以上のシステムを指定します。 |
|
localAddress |
WebLogic Serverインスタンスのホスト・アドレスを定義します(アスタリスク(*)を指定すると、すべてのローカルIPアドレスが返されます)。 |
|
localPort |
WebLogic Serverインスタンスのリスニング・ポートを定義します(アスタリスク(*)を指定すると、サーバー上のすべての使用可能なポートが返されます)。 |
|
action |
実行するアクションを指定します。この値は、allowまたはdenyである必要があります。 |
|
protocols |
フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。 |
「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項 |
11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」の下の「ドメイン」をクリックします。
「セキュリティ」タブ→「フィルタ」タブをクリックします。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
「WebLogicドメインでのプロバイダの構成」に進みます。
ここでの情報は、OAM 11gおよびOAM 10gに同じように当てはまります。この項の内容は次のとおりです。
この項では、WebLogicセキュリティ・レルムの認証プロバイダを初めて使用するユーザーのために、いくつかのタイプの認証プロバイダのみを説明します。
WebLogicセキュリティ・レルムごとに、少なくとも1つの認証プロバイダを構成する必要があります。WebLogicセキュリティ・フレームワークは、マルチパート認証用に複数の認証プロバイダ(および複数のLoginModule)をサポートするように設計されています。このため、1つのセキュリティ・レルムで複数の認証プロバイダと複数のタイプの認証プロバイダを使用できます。制御フラグ属性により、認証プロセスにおいて各認証プロバイダのLoginModuleがどのように使用されるかが決定されます。
Oracle WebLogic Serverは、次のものを含め、複数のタイプの認証プロバイダとIDアサーション・プロバイダを提供します。
デフォルトのWebLogic認証プロバイダ(デフォルトの認証プロバイダ)では、ユーザーとグループを1箇所で、つまり、WebLogic Serverの組込みLDAPサーバーで管理できます。この認証プロバイダは、Oracle WebLogic Serverでの管理ユーザー・ログインに使用されます。
IDアサーションは、トークンベース認証を使用します。Oracle Access Manager IDアサーション・プロバイダはその一例です。これは、インストール済Webゲート(10gまたは11g)の適切なアクションを使用するように構成する必要があります。
LDAP認証プロバイダは、ユーザーおよびグループ情報を外部LDAPサーバーに格納します。このプロバイダは主に、一般的なディレクトリ・スキーマが反映されるように、対応するLDAPサーバーがデフォルトで構成されている点が異なります。
Oracle WebLogic Server 10.3.1以降では、OracleInternetDirectoryAuthenticatorを使用できます。
複数の認証プロバイダを構成する場合、各プロバイダに対してJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの使用方法を制御します。たとえば、次のJAAS制御フラグ設定を選択できます。
REQUIRED: 認証プロバイダが常に呼び出され、ユーザーはその認証テストを常にパスする必要があります。認証の成否に関係なく、プロバイダ・リストの最後まで認証が続行されます。
SUFFICIENT: ユーザーは、認証プロバイダの認証テストをパスする必要はありません。認証に成功した場合、後続の認証プロバイダは実行されません。認証に失敗した場合、プロバイダ・リストの最後まで認証が続行されます。
OPTIONAL: ユーザーは、認証プロバイダの認証テストをパスしても失敗してもかまいません。ただし、セキュリティ・レルムに構成されているすべての認証プロバイダでJAAS制御フラグがOPTIONALに設定されている場合は、ユーザーは構成されているプロバイダのいずれかの認証テストをパスする必要があります。
既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。場合によっては、認証シーケンスで各認証プロバイダが適切に機能するように、制御フラグの設定とプロバイダの順序を変更する必要があります。
|
関連項目: すべての認証プロバイダのリストと、ユーザーおよびグループ属性をLDAPスキーマと一致させるためのOracle Internet Directoryプロバイダの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項を参照してください。 |
この項では、WLSTを初めて使用するユーザーのために、WLSTについて説明します。
Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して、WebLogicドメインにプロバイダを追加できます。
WLSTはJythonベースのコマンドライン・スクリプト環境で、WebLogic Serverドメインの管理と監視のために使用できます。通常、このツールはオンラインまたはオフラインで使用できます。このツールは、ファイルで提供されるバッチ(ユーザーの入力を介在せずに、スクリプトが一連のWLSTコマンドを呼び出すスクリプト・モード)において、コマンドラインで対話的に実行することができます。また、Javaコードに組み込むことも可能です。
WebLogicドメインに認証プロバイダを追加する場合、WLSTをオンラインで使用して認証プロバイダと対話し、ユーザー、グループおよびロールを追加、削除または変更できます。
WLSTをオフラインで使用してドメイン・テンプレートを作成する場合、WLSTによって認証プロバイダのデータ・ストアとその他のドメイン文書がパッケージ化されます。ドメイン・テンプレートからドメインを作成すると、新しいドメインは、ドメイン・テンプレートの認証プロバイダのデータ・ストアとまったく同じコピーになります。ただし、WLSTをオフラインで使用して認証プロバイダのデータ・ストア内のデータを変更することはできません。
|
注意: WLSTをオフラインで使用して、認証プロバイダのデータ・ストア内のデータを変更することはできません。 |
|
関連項目:
|
Oracle Application Development Framework (Oracle ADF)セキュリティを使用し、Oracle Access Manager Single Sign On (SSO)と統合し、ユーザー認証にOracle Platform Security Services (OPSS) SSOを使用するWebアプリケーションをOracle WebLogic Server上で実行できます。ただし、Webアプリケーションを実行する前に、アプリケーションのターゲットのOracle WebLogic Server上で、Oracle Access Managerセキュリティ・プロバイダ用にドメインレベルのjps-config.xmlファイルを構成する必要があります。
ドメインレベルのjps-config.xmlファイルは次のパスに存在します。デプロイ済のアプリケーションのjps-config.xmlファイルと混同しないでください。
domain_home/config/fmwconfig/jps-config.xml
Webアプリケーションのデプロイ前またはデプロイ後に、Oracle Access Manager固有のWLSTスクリプトを使用して、ドメインレベルのjps-config.xmlファイルを構成できます。このOracle JRF WLSTスクリプトの名前は次のとおりです。
Linux: wlst.sh
Windows: wlst.cmd
JDevを使用して実行している場合、Oracle JRF WLSTスクリプトは次のパスにあります。
$JDEV_HOME/oracle_common/common/bin/
JRF WebLogicをスタンドアロンでインストールしている場合のパスは次のとおりです。
$Middleware_home/oracle_common/wlst
|
注意: Oracle JRF WLSTスクリプトが必要です。Oracle Java Required Files (JRF)用のWLSTを実行している場合は、$JDEV_HOME/wlserver_10.3/common/binにあるWLSTスクリプトを使用しないでください。 |
コマンド構文
addOAMSSOProvider(loginuri, logouturi, autologinuri)
表15-4では、addOAMSSOProviderコマンドラインにおける各引数の期待値を定義しています。
表15-4 addOAMSSOProviderコマンドライン引数
| 引数 | 定義 |
|---|---|
|
loginuri |
ログイン・ページのURIを指定します。 |
|
autologinuri |
自動ログイン・ページのURIを指定します。 |
|
logouturi |
ログアウト・ページのURIを指定します。 |
|
関連項目:
|
前提条件
Oracle ADFセキュリティが有効なFusion Webアプリケーション用のドメインレベルのjps-config.xmlを変更するには:
Oracle WebLogic ServerおよびOracle ADFセキュリティを使用しているWebアプリケーションをホストするコンピュータ上で、Oracle JRF WLSTスクリプトを見つけます。例:
cd $ORACLE_HOME/oracle_common/common/bin
Oracle WebLogic Serverをホストするコンピュータに接続します。
connect login_id password hostname:port
たとえば、Oracle WebLogic管理サーバーのホストは、ポート7001を使用するlocalhostであることが考えられます。ただし、これは使用する環境によって異なる可能性があります。
ADFセキュリティが有効なアプリケーション用の値を使用して、次のコマンドライン引数を入力します。
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
Oracle WebLogic Serverを停止して起動します。
この章で説明されているように次のタスクを実行します。
この項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンを実行するために、WebLogicセキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。
OAM IDアサーション・プロバイダ: 必須(OAM 11gで使用するWebゲートのリリースに応じた選択済アクティブタイプも指定(表16-1「Oracle Access Manager認証プロバイダ共通パラメータ」))
次の手順では、WebLogic管理コンソールを使用します。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。ステップ1を省略してください。 |
シングル・サインオン用のOracle Access ManagerプロバイダをWebLogicドメインに設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。
oamAuthnProvider<version number>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle Fusion Middlewareアプリケーションをインストール済の場合:
次のパスでoamauthenticationprovider.warを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi der.war
oamauthenticationprovider.warを次の場所にコピーします。
BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication provider.war
WebLogic管理コンソールにログインします。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブをクリックし、「制御フラグ」をREQUIREDに設定します。
「共通」タブをクリックし、インストール済のWebゲートに選択した「アクティブなタイプ」を指定します(表16-1)。
保存します。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。
デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。
保存します。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
保存します。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)
OID認証プロバイダ: (SUFFICIENT)
デフォルトの認証プロバイダ: (SUFFICIENT)
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次のようにします。
成功: 「Oracle Access Manager IDアサーション・プロバイダのログイン・ページの確認」を参照してください。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
前述のとおり、10g Webゲートに付属のログイン・フォームは、OAM 10gアクセス・サーバーでのみ使用します。OAM 11gの場合、10g Webゲートでも11g Webゲートでもログイン・ページは提供されません。
|
注意: OAM 11g Serverでは、ログイン・ページが表示されます。設定は必要ありません。 |
次の手順を実行します。
次の手順では、Oracle Access Manager IDアサーションの設定をテストする方法について説明します。
また、Oracle Access Managerシステム管理ガイドの説明に従って、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
シングル・サインオン用のOracle Access Manager IDアサーションを検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:
http://ohs_server:port/<protected url>
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「トラブルシューティングのヒント」を参照してください。
認証プロバイダ機能を使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、Oracle Access Manager認証スキームが必要です。これは、Oracle Access Manager 11gで提供されている事前シード済アプリケーション・ドメインにあります。これは、次のリソース(resource type wl_authen)を保護します。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
ポリシーにはレスポンスと制約を追加できます。ただし、それ以外の構成は必要ありません。
事前シード済アプリケーション・ドメインの詳細は、「OAM 10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー」を参照してください。
前提条件
Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
|
注意: 認証プロバイダで使用するカスタムの10gアクセス・ゲートをプロビジョニングすることも、認証プロバイダのプロバイダの構成時に既存のOAMエージェント登録を参照することもできます。 |
Oracle Access Manager認証プロバイダを構成するためのタスクについては、次の概要で説明します。
タスクの概要: OAM用の認証プロバイダ機能の構成には次の手順が含まれます。
前提条件のすべてのタスクが実行されていることの確認
この項では、WebLogicドメインに適切な認証プロバイダを追加および構成するための手順について説明します。
Oracle Access Manager認証プロバイダは、WebLogicドメインのデフォルト認証プロバイダに従って構成する必要があります。
次の手順では、WebLogic管理コンソールを使用してこのタスクを実行する方法について説明します。これらは、Oracle WebLogic Scripting Tool (WLST)を使用して追加することもできます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なファイルはすでにインストールされているので、ステップ1は省略できます。 |
WebLogicドメインにOracle Access Manager認証プロバイダを構成するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic管理コンソールに移動します。
Oracle Fusion Middlewareアプリケーションをインストール済の場合:
次のパスでoamauthenticationprovider.warを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi der.war
oamauthenticationprovider.warを次の場所にコピーします。
BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication provider.war
Oracle WebLogic管理コンソールに移動します。
必要に応じて、「ロックして編集」をクリックします。
OAM認証プロバイダ:
「セキュリティ・レルム」をクリックし、構成するレルムを選択します。
「プロバイダ」→「認証」を選択し、「新規」をクリックして、「新しい認証プロバイダの作成」ページを表示します。
名前を入力して、タイプを選択します。
名前: OAMAuthN
タイプ: OAMAuthenticator
OK
作成した認証プロバイダの名前をクリックして、「プロバイダ構成」ページを表示します。
「プロバイダ構成」ページで、次のように必要な値を設定します。
アクセス・ゲート名: プロバイダによって使用されるアクセス・ゲートの名前。これは、OAM管理コンソールのOAMエージェント登録の名前と完全に一致している必要があります。
|
注意: OAM 11gでは1つ以上の10g OAMエージェントを登録できます。正しいエージェント登録名を選択してください。 |
アクセス・ゲートのパスワード: エージェント登録に対してパスワードが定義されている場合は、それと同じパスワード(OAM管理コンソールを参照)。
プライマリ・アクセス・サーバー: OAM管理コンソールでこのアクセス・ゲートに関連付けられているプライマリ・アクセス・サーバーのhost:port。
詳細構成: 次に、いくつかの詳細構成の値を示します。
トランスポート・セキュリティ: アクセス・サーバーとアクセス・ゲート間の通信モード(オープン、簡易、証明書)。
トランスポート・セキュリティが簡易または証明書である場合、次のパラメータと値を含めてください。
トラスト・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSトラスト・ストアの絶対パス。
キー・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSキー・ストアの絶対パス。
キー・ストアのパスフレーズ: キー・ストアにアクセスするためのパスワード。
簡易モード・パスフレーズ: アクセス・ゲートとOAM Serverで共有する簡易通信モード用パスワード。
セカンダリOAMサーバー: OAM管理コンソールでこのアクセス・ゲートに関連付けられているセカンダリOAMサーバーのhost:port。
プール内の最大OAMサーバー接続数: アクセス・ゲートがOAMサーバーに対してオープンする最大接続数。デフォルト値は10です。
|
注意: WebLogic管理コンソールで指定するプール内の最大OAMサーバー接続数(またはプール内の最小OAMサーバー接続数)の設定は、OAM管理コンソールで指定する「最大接続数」や「最小接続数」とは異なります。 |
プール内の最小アクセス・サーバー接続数: 認証プロバイダからアクセス・サーバーへの認証リクエストの送信に使用する最小接続数。デフォルト値は5です。
パラメータ「制御フラグ」がOPTIONALに初期設定されていることを確認します。
|
注意: 認証プロバイダが機能し、正しく構成されていることを確認するまで、パラメータ「制御フラグ」をREQUIREDに設定しないでください。 |
チェンジ・センターで、変更のアクティブ化をクリックします。
DefaultAuthenticator: 「プロバイダ」タブでDefaultAuthenticatorを選択します。これにより、その制御フラグがSUFFICIENTに変更されます。
並べ替え: 「プロバイダ」タブで、DefaultAuthenticatorが先頭になるように(DefaultAuthenticatorの後にOAMAuthenticator)プロバイダを並べ替えます。
|
注意: Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。 |
Oracle Access Manager認証プロバイダのREQUIREDまたは唯一の認証プロバイダである場合: 次の手順を実行して、Oracle WebLogic Serverを起動するためのユーザー権限を設定します。
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。
|
注意: その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。 |
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
Adminロールの「構成の表示」を選択します。
グループを追加して「保存」をクリックします。
WebLogic Serverを再起動します。
サーバーを起動すると、認証プロバイダ・パラメータ「制御フラグ」が適切な値(REQUIRED、OPTIONAL、またはSUFFICIENT)にリセットされます。
この項では、Oracle Access Manager認証プロバイダのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager認証プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をBASICに指定する必要があります。
auth-methodには、BASICまたはFORMの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
|
注意: Oracle Access Manager認証プロバイダの場合、web.xml内のlogin-configにauth-method BASICを指定することをお薦めします。 |
認証プロバイダのアプリケーション認証方式を構成するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
WEB-INF/web.xml
login-configでauth-methodを検索し、BASICと入力します。例:
<security-constraint> <web-resource-collection> <web-resource-name>protected</web-resource-name> <url-pattern>/servlet</url-pattern> </web-resource-collection> <auth-constraint> <role-name>auth-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <description>Authenticated Users</description> <role-name>auth-users</role-name> </security-role>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
この項では、認証ユーザーをLDAP内のグループにマップする方法について説明します。このためには、weblogic.xmlファイルを編集する必要があります。たとえば、ロール名auth-usersをLDAP内のmanagersというグループにマップできます。
Oracle Access Manager認証プロバイダ用に認証ユーザーをLDAP内のグループにマップするには
アプリケーションのweblogic.xmlファイルに移動します。
ファイル内の任意の場所に、環境に応じて次の情報を追加します。
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<security-role-assignment>
<principal-name>managers</principal-name>
<role-name>auth-users</role-name>
</security-role-assignment>
</weblogic-web-app>
ファイルを保存します。
WebLogic Serverを再起動します。
「Oracle Access Manager 11g用の集中管理ログアウトの構成」に説明されているように集中管理ログアウトを構成し、ここに戻ってOracle Access Manager認証プロバイダの実装のテストを実行します。
認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。
次の手順では、認証プロバイダの設定をテストする方法について説明します。また、『Oracle Access Managerシステム管理ガイド』の説明に従って、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
Oracle Access Manager認証プロバイダの実装を検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:
http://yourdomain.com:port
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「トラブルシューティングのヒント」を参照してください。
この項では、Oracle Web Services ManagerでWebサービスを保護している場合に、トークンの検証を有効にするようにOracle Access Manager IDアサーション・プロバイダを設定する方法について説明します。
前述のとおり、Oracle Access Manager IDアサーション・プロバイダは2つのモードで機能します。デフォルト・モードの操作では、Webゲートが境界で設定したヘッダーがアサートされます。これで、ほとんどのSSOの処理を扱うことができます。もう1つのモードでは、oamAuthnProvider.jarにあるカスタム・アクセス・ゲートを使用します。この場合、ヘッダーが存在しないと、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager 11gでの認証プロバイダのインストール」を参照してください。
|
注意: Oracle Web Services ManagerのIDアサーション・プロバイダには、認証プロバイダが提供する10gカスタム・アクセス・ゲートが必要です。 |
OAM 10gでは、ポリシー・ドメインおよびこの構成に対応するポリシーの手動での作成が必要になることがあります。一方、OAM 11gでは、次のリソース(resource type wl_authen)を保護するポリシーを設定した事前シード済アプリケーション・ドメインが提供されます。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
タイプwl_authenのリソースのポリシー、レスポンスおよび制約のみを追加できます。ただし理論上はこのアプリケーション・ドメインは構成を追加することなく使用することができます。詳細は、「OAM 10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー」を参照してください。
Oracle Access Manager IDアサーション・プロバイダがヘッダーとトークンの両方の検証モードで構成されている場合、ヘッダー検証モードが優先します。ヘッダーが存在しない場合、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
前提条件
Oracle Access Manager 11gでの認証プロバイダのインストール
Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
タスクの概要: Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ
この項では、Oracle Web Services Managerポリシーを構成してWebサービスを保護する方法について概説します。
Oracle Web Services ManagerでIDアサーション・プロバイダを使用するには、Webサービスにoracle/wss_oam_token_service_policyを設定し、対応するクライアントにoracle/wss_oam_token_client_policyを設定する必要があります。
oracle/wss_oam_token_service_policyについて
このOracle Web Services Managerポリシーには、ポリシー・アサーションoracle/wss_oam_token_service_templateが含まれています。このテンプレートは、WSセキュリティ・ヘッダーのバイナリ・セキュリティ・トークンの資格証明を使用して、Oracle Access Managerアイデンティティ・ストアに対してユーザーを認証します。
Oracle Access Manager IDアサーション・プロバイダは、ObSSOCookieトークンを使用して、oracle/wss_oam_token_service_policyポリシーによって保護されているWebサービスにアクセスしようとしているユーザーのアイデンティティをアサートします。このポリシーによって保護されているWebサービスは、SOAPヘッダーのObSSOCookieトークンで提示される必要があります。つまり、WebサービスはObSSOCookieトークンを使用し、トークンの生成方法には関与しません。具体的には、WebLogic Serverセキュリティ・サービスがトークン・タイプを検出し、Oracle Access Manager IDアサーション・プロバイダを呼び出します。Oracle Access Manager IDアサーション・プロバイダは、Oracle Access Managerアクセス・サーバーに対してObSSOCookieトークンを検証し、ユーザー名を取得します。ユーザー名がプリンシパルとして認証済サブジェクトに移入されます。
Webサービス・クライアント(Webアプリケーションなど)は、ObSSOCookieトークンを取得してWebサービスに送信する必要があります。通常、これはアクセス・ゲートを使用して行われます。アクセス・ゲートは、(Oracle Access Managerで構成された認証スキームに応じて)Webサービス・クライアントのユーザーに資格証明を要求し、ユーザーを認証します。認証が成功すると、WebゲートによってObSSOCookieがユーザーのブラウザに送信されます。
Webサービス・クライアントは、ObSSOCookieトークンをSOAPリクエストとしてWebサービスに送信します。
|
注意: wss_oam_token_service_templateの設定は、クライアント・バージョンのアサーションwss_oam_token_client_templateと同じです。サービス・テンプレートのアイデンティティ・ストア構成は、クライアント・バージョンのアサーションと同じです。 |
oracle/wss_oam_token_client_policyについて
このOracle Web Services Managerポリシーには、ポリシー・アサーションoracle/wss_oam_token_client_templateが含まれています。このテンプレートは、Oracle Access Manager資格証明をバイナリ・セキュリティ・トークンの一部としてWSセキュリティ・ヘッダーに挿入します。
oracle/wss_oam_token_client_policyは、oracle/wss_oam_token_service_policyサービス・エンドポイント・ポリシーに対応するクライアント・ポリシーです。このポリシーは、任意のSOAPベースのエンドポイントで実施できます。
次のタスクの概要に、実行する必要のある手順の概要を示します。
タスクの概要: Oracle Web Services Managerのポリシーの設定
Oracle Web Services Managerを使用して、Webサービスにoracle/wss_oam_token_service_policyポリシーを設定します。
Oracle Web Services Managerを使用して、Webサービスに対応するクライアントにoracle/wss_oam_token_client_policyポリシーを設定します。
|
関連項目:
|
Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダを使用するには、WebLogicドメインでいくつかの認証プロバイダを構成し、並べ替える必要があります。
この手順は、OAM 11gでのOracle Access Manager IDアサーション・プロバイダの場合とほとんど同じです。この場合の相違点は、Oracle Web Services Managerはカスタム・アクセス・ゲートを必要とし、追加のプロバイダ固有の値が必要になることです。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: mnop:8888。
アクセス・ゲート名: アプリケーションを保護するアクセス・ゲート登録の名前。例: AG1。
アクセス・ゲートのパスワード: OAM管理コンソールで指定したアクセス・ゲート・パスワード。
これらは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して追加できます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダ・ファイルはすでにインストールされています。ステップ1を省略してください。 |
WebLogicドメインでプロバイダを設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
次のOracle Technology NetworkのWebサイトにログインします。
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic Server管理コンソールにログインします。
OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブで、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。
「共通」タブをクリックして、10gカスタム・アクセス・ゲートの選択済アクティブ・タイプとしてObSSOCookieを指定し、「保存」をクリックします。
「プロバイダ固有」タブをクリックし、次のパラメータを構成します。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。
アクセス・ゲート名: アプリケーションを保護するOAMエージェントの登録名。例: AG1。
アクセス・ゲートのパスワード: プロビジョニングの際に指定したアクセス・ゲート・パスワードがあれば、そのパスワード。
保存します。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
「OK」をクリックします。
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。
|
注意: デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。 |
「保存」をクリックします。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
「保存」をクリックします。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)
OID認証プロバイダ: (SUFFICIENT)
デフォルトの認証プロバイダ: (SUFFICIENT)
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次のようにします。
成功: 「Oracle Access Manager 11g用の集中管理ログアウトの構成」に進み、ここに戻って「Oracle Web Services Manager用IDアサーション・プロバイダのテスト」を実行します。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「Oracle Access Manager 11gでの認証プロバイダのインストール」の説明にあるように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
Oracle Web Services Managerを使用してOracle Access Manager IDアサーション・プロバイダの使用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスが認められた場合は、実装が機能しています。失敗した場合は、「トラブルシューティングのヒント」を参照してください。
この項では、Oracle Access Manager 11g用の集中管理ログアウトについて説明します。
OAM 11gでは、集中管理ログアウトとはアクティブなユーザー・セッションを終了するプロセスを意味します。ガイドラインの内容は次のとおりです。
SSO環境で使用するアプリケーションは、自身のログアウト・ページを表示しないようにする必要があります。
アプリケーションは、OAM Webゲート管理者が指定したログアウトURLを指す値でログアウト・リンクを構成できるようにする必要があります。
|
注意: アプリケーションでADF認証サーブレットを使用することを強くお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。 |
詳細は、次の項目を参照してください。
OAM 11gエージェントの登録ページのいくつかの要素によって、OAM 11g Webゲートの中央管理されたログアウトが有効になります。エージェントの登録後、その情報がObAccessClient.xmlファイルに移入されます。
エージェントの登録の際に指定する必要のある11g Webゲートのログアウトオプションには、次のものがあります。
ログアウトURL: ログアウト・ハンドラをトリガします。これにより、Cookie(10g Webゲート用ObSSOCookie、11g Webゲート用OAMAuthnCookie)が削除されるので、Oracle Access Managerで保護されたリソースにこのユーザーが次回アクセスする際には再認証が必要になります。
ログアウト・コールバックURL: oam_logout_successへのURLです。コールバックの際にCookieを消去します。これには、host:portのないURI形式を指定できます(推奨)。これにより、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。
ログアウト・リダイレクトURL: このパラメータには、エージェントの登録が完了すると自動的に情報が移入されます。デフォルトでは、ポートをデフォルトの14200としたOAMサーバーのホスト名に基づきます。
ログアウト・ターゲットURL: この値は、ログアウトの際にOPSSアプリケーションがWebゲートに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。
詳細は、Oracle Access Managerシステム管理ガイドのOAM 11gでの11g Webゲートの集中管理ログアウトの構成に関する項を参照してください。
OAMエージェント(この場合は10g Webゲート)向けに構成されたlogout.htmlファイルをアプリケーションで呼び出すと、ログアウトが始まります。アプリケーションは、logout.htmlへの問合せ文字列としてend_urlも渡します。end_urlパラメータの値は、URIまたはURLのいずれかです。
タスクの概要: 10g Webゲート向けの中央管理ログアウトの構成。
デフォルトのログアウト・ページ(logout.html)を作成して、それをWebゲートのインストール・ディレクトリに置きます。例: WebGate_install_dir/oamsso/logout.html。
logout.htmlで、logOutUrlsパラメータが各リソースWebゲートに構成されていること、および<callBackUri>が「logOutUrls」の2番目の値であることを確認します。
ステップ1にあるlogout.htmlで、ユーザーをOAM 11gサーバー上のこの中央管理ログアウトのURI(/oam/server/logout)にリダイレクトする設定になっていることを確認します。
オプション: ログアウトしたユーザーのリダイレクト先を示すend_urlパラメータをアプリケーションで渡すことができます。
10g Webゲートを構成したOHS Webサーバー構成ファイルhttpd.confを確認し、次の行が存在する場合には削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
詳細は、Oracle Access Managerシステム管理ガイドのOAM 11gでの10g Webゲートの集中管理ログアウトの構成に関する項を参照してください。
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ログアウトの詳細は、例17-2「動的ディレクティブによるSSOログアウト」を参照してください。Oracle Access Managerログアウトの詳細は、「Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成」を参照してください。
アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。
様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shにEXTRA_JAVA_PROPERTIESがあるか確認します。表15-5に、各プロパティと同期動作を示します。
表15-5 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サポート・サービスにお問合せの際は、「WebLogic管理コンソールでのデバッグの設定」の説明に従ってデバッグを設定するように求められる場合があります。
詳細は、Oracle Access Managerシステム管理ガイドのトラブルシューティングに関する項を参照してください。
