| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
Access Managerは、いくつかのSSOアーキテクチャ(パートナ・ネットワークのアイデンティティ・フェデレーション、サービス指向アーキテクチャなど)をひとつにまとめ、共通のSSOエンジンを介して、複数のプロトコルにわたって一貫したサービスにSSOを提供します。Oracle Identity Managementインフラストラクチャでは、ユーザー・アイデンティティをポリシー内で参照されるアイデンティティ・ストアに格納します。
ノート:
コンテキスト・データは、ユーザー操作の様々なステージで、Access Managerに対して提示する情報またはAccess Managerによって収集される情報です。そのようなステージには、認証、認可、エンタープライズSSO、フェデレーション、適応認証、トークン検証、セッション作成などがあります。情報自体は、ユーザーのデバイス・フィンガープリント、IPアドレス、ウイルス対策およびファイアウォール防御、アサーションなどを構成できます。Access Managerと統合したときにコンテキスト・データ・プロバイダおよびアサータの役割を果たすコンポーネントには、エンタープライズ・シングル・サインオン、Identity Federation、Oracle Adaptive Access Managerなどがあります。
表21-1に、Access Managerのポリシーをサポートまたは強制するコンポーネントの概要を示し、必要に応じて、これらのコンポーネントの詳細情報の参照先を示します。
ノート:
明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Managerのデフォルトの動作ではアクセスが拒否されます。認証タスクをAccess Managerに委任するには、エージェントが依存する相手とともに存在し、Access Managerに登録されている必要があります。エージェントを登録すると、エージェントとAccess Manager SSOとの間で必要な信頼メカニズムが設定されます。
表21-1 サマリー: SSOのコンポーネント
| コンポーネント | 説明 |
|---|---|
アプリケーション |
アプリケーションは、認証と認可をAccess Managerに委任して、登録済エージェントからのヘッダーを受け入れます。 ノート: 外部アプリケーションは認証が委任されません。かわりに、アプリケーション・ユーザー名とパスワードを求めるHTMLログイン・フォームが表示されます。たとえば、 Yahoo! Mailは、HTMLのログイン・フォームを使用する外部アプリケーションです。 |
|
管理者以外のユーザーは、最初に保護されたリソースのURLを入力して、アクセスを取得します。このURLは、SSOログイン・ページを返します。 関連項目: 「資格証明コレクションおよびログインの理解」。 管理ユーザーは、URL (https://host:port/oamconsole)を入力してコンソールにアクセスすると、ポリシーを作成できます。ただし、エージェントの登録時にデフォルトのポリシーが自動的に生成されます(「OAM 11gエージェントの登録および管理」を参照)。 関連項目: 「リソースの保護およびSSOの有効化ポリシーの管理」。 |
ポリシー強制エージェント |
関連項目: 「エージェントおよび登録の概要」。 |
資格証明コレクタおよび通信チャネル |
関連項目: 表22-5 |
SSOエンジン |
セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。 関連項目: 「Access Managerセッションの維持」および「11g Webゲートが関与するセッションの集中ログアウトの構成」 |
レガシー・システムをサポートするプロキシ |
|
アクセス・ポリシー |
登録済エージェントは、Access Manager認証、認可およびトークン発行ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。 ノート: 明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Managerのデフォルトの動作ではアクセスが拒否されます。 |
ポリシー・ストア |
本番環境ではデータベースです(それ以外の場合は、oam-config.xml)。 関連項目: 「データ・ソースの管理」 |
暗号化キーおよびキー・ストレージ |
登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成および使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。 関連項目: 表1-2。 |
Cookie |
関連項目: 「SSO Cookieの理解」。 |
ノート:
Oracle Identity Managementコンソールと、WebLogicコンテナにデプロイされたその他のOracle Identity Managementコンソールのシングル・サインオンは、事前登録済のIAMSuiteAgentとコンパニオン・ポリシーを使用して有効にします。これらのコンソールの保護に、それ以上の構成は必要ありません。
シングル・サインオンは、表21-2に示すように実装できます。この表には、追加情報の参照先が含まれています。
表21-2 SSOの実装の概要
| SSOのタイプ | 説明 |
|---|---|
単一のネットワーク・ドメインのSSO |
単一のネットワーク・ドメイン(たとえば、example.com)内のリソースに対して、Access Managerのシングル・サインオンを設定できます。これには、単一のネットワーク・ドメイン内にある複数のWebLogic管理ドメインに属するリソースの保護が含まれます。 単一のネットワーク・ドメインのSSOについては、このドキュメントで説明します。 |
複数のネットワーク・ドメインのSSO |
Access Manager 11gは、ネットワーク間ドメインの設定不要なシングル・サインオンをサポートします。 関連項目: 「複数のネットワーク・ドメインのSSO」。 |
アプリケーションのSSO |
アプリケーションのシングル・サインオンを使用すると、Access Managerによって認証されたユーザーは、アプリケーションにアクセスする際に再認証は必要ありません。 |
複数のWebLogicサーバー・ドメインSSO |
WebLogic Serverインスタンスの基本管理単位をドメインと呼びます。様々なシステム管理者の責任、アプリケーションの境界、またはWebLogicサーバーの地理的な場所に基づいて、複数のWebLogic管理ドメインを定義することができます。ただし、クラスタ内のすべての管理対象サーバーが同じWebLogic Serverドメインに存在する必要があります。 |
リバース・プロキシのSSO |
このSSO実装タイプは、わずかな構成の変更でサポートされます。 関連項目: 「リバース・プロキシのSSO」 |
混在リリース・エージェントを使用したSSO |
Access Managerは、登録された11gおよび10g OAMエージェント(Webゲートとプログラムのアクセス・クライアント)に加え、レガシーOSSOエージェント(mod_osso 10g)およびレガシーOpenSSOエージェントをシームレスにサポートします。これらは、任意の組合せで使用できます。 |
Access Managerでは、これは標準機能です。11g WebGatesが独占的に使用される場合、システム内のすべてのcookieはホスト・ベースです。ただし、すべてのドメインを管理する必要があります。一部のドメインが外部のエンティティ(Access Managerのデプロイメントの一部ではないもの)により制御される場合、Identity Federationを使用することをお薦めします。
Access Managerは、ネットワーク間ドメインでの設定不要シングル・サインオンをサポートします。Access Managerのシングル・サインオフ時には、次の処理が実行されます。
OAMサーバーが設定するSSO Cookieは、ネットワーク・ドメイン全体で機能するホストCookieです。Webゲートは、そのスタンドアロン・エージェントCookieをクリアした後、セッションをクリアするためにOAMサーバーにリダイレクトします。
スタンドアロン・エージェントCookieを使用しない10g Webゲートの場合、サーバー側でのみログアウトが行われ、リダイレクトは必要ありません。
スタンドアロン・エージェントCookieをサポートする11g WebゲートとOSSOエージェントの場合、エージェントのログアウト・コールバックURLがパラレルに呼び出されます。セッションでアクセスするエージェントおよび複数のドメインのエージェントは、ブラウザでサポートされる同時接続の数に応じてすべてパラレルにコールされます。
ノート:
Access Managerは、Identity Federation 11.1.1よりも前に、独自の複数のネットワーク・ドメインSSO機能を提供しています。これがOracle Access Manager 10gデプロイメントに実装されている場合、10gエージェントをAccess Manager 11gに登録することによって、このサポートを継続できます。
関連項目:
, 11.1.1
ユーザーの資格証明を送信する次の2つの方法があります。
Cookieの使用: ユーザーの識別にアプリケーションで抽出する必要があるブラウザのCookieに特定の値が設定されます。
ヘッダー変数の使用: エージェントのリクエストで設定され、アプリケーションで参照できるHTTPヘッダー。
ノート:
どちらの形式でも、管理者はポリシー内の適切なレスポンスを入力する必要があります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。
ヘッダー・レスポンス値は、OAMエージェントによってリクエストに挿入され、Access Manager 12cに登録されているエージェントによって保護されているWebサーバーにのみ適用できます。ポリシーに、Access Managerによって保護されていないWebサーバーでホストされているリダイレクトURLが含まれる場合、ヘッダー・レスポンスは適用されません。
たとえば、ユーザーを認証する場合、ポータル索引ページにリダイレクトすることがあります。
http://example.com/authnsuccess.htm
認証に失敗すると、認証アクションによってユーザーがエラー・ページまたは自己登録スクリプトにリダイレクトされる場合があります。
http://example.com/authnfail.htm
Access Managerは、複数のWebLogic管理ドメインでSSOをサポートします。様々なシステム管理者の責任、アプリケーションの境界、またはWebLogicサーバーの地理的な場所に基づいて、複数のWebLogic管理ドメインを定義することができます。
一方で、1つのドメインを使用して、すべてのWebLogic Server管理アクティビティを集中管理できます。
ノート:
クラスタ内のすべての管理対象サーバーは、同じドメインに存在しなければなりません。クラスタを複数のドメインに分割することはできません。ドメイン内のすべての管理対象サーバーで、同じバージョンのOracle WebLogic Serverソフトウェアを実行する必要があります。管理サーバーは、ドメイン内の管理対象サーバーと同じバージョンか、それ以降のサービス・パックを実行できます。
WebLogic管理ドメインには、次の2つの基本タイプがあります。
管理対象サーバーを含むドメイン: アプリケーションをホストする複数の管理対象サーバーを含むドメインおよび管理操作を実行する管理サーバーで、単純な本番環境を構成できます。この構成では、アプリケーションおよびリソースは個々の管理対象サーバーにデプロイされ、同様に、アプリケーションにアクセスするクライアントは個々の管理対象サーバーに接続します。
向上したアプリケーションのパフォーマンス、スループットまたは可用性を必要とする本番環境では、クラスタとして2つ以上の管理対象サーバーを構成する場合があります。クラスタリングにより、複数の管理対象サーバーをホスト・アプリケーションおよびリソースの1つの単位として操作できます。スタンドアロン管理対象サーバーおよびクラスタ化された管理対象サーバーの違いの詳細は、管理対象サーバーおよびクラスタ管理対象サーバーを参照してください。
スタンドアロンWebLogic Serverドメイン: 開発環境またはテスト環境には、本番ドメインのサーバーから個別に単一のアプリケーションおよびサーバーをデプロイできます。この場合、管理サーバーとして動作し開発中のアプリケーションもホストする単一のサーバー・インスタンスを構成する単純なドメインをデプロイできます。WebLogic Serverでインストールできるexamplesドメインは、スタンドアロンWebLogic Serverドメインの例です。
クラスタ内のすべての管理対象サーバーは、同じドメインに存在しなければなりません。クラスタを複数のドメインに分割することはできません。ドメイン内のすべての管理対象サーバーで、同じバージョンのOracle WebLogic Serverソフトウェアを実行する必要があります。管理サーバーは、ドメイン内の管理対象サーバーと同じバージョンか、それ以降のサービス・パックを実行できます。
各ドメインの構成は個別の構成ファイル(config.xml)に保存され、このファイルは他のファイル(ログ、セキュリティ・ファイルなど)とともに管理サーバーに保存されます。管理サーバーを使用して構成タスクを実行する場合、ユーザーが加えた変更は、その管理サーバーで管理されているドメインにのみ適用されます。別のドメインを管理するには、そのドメインの管理サーバーを使用します。この理由から、1つのドメインのサーバー・インスタンス、アプリケーションおよびリソースは、別のドメインのサーバー、アプリケーションおよびリソースからは独立して扱う必要があります。構成タスクやデプロイメント・タスクを複数のドメインで同時に実行することはできません。
各ドメインには、管理アクティビティを実行するための固有の管理サーバーが必要です。Oracle Access Managementコンソールを使用して管理タスクおよびモニタリング・タスクを実行する際、ドメインを切り替えることができますが、その際に接続する管理サーバーが切り替わります。
複数のドメインを作成した場合、各ドメインは、そのドメイン専用のデータベース・スキーマを参照する必要があります。構成したリソースまたはサブシステムをドメイン間で共有することはできません。たとえば、あるドメインでJDBCデータ・ソースを作成した場合、別のドメインの管理対象サーバーまたはクラスタでその接続プールを使用することはできません。かわりに、2番目のドメインで同様のデータ・ソースを作成する必要があります。また、2つ以上のシステム・リソースに同じ名前を付けることはできません。
リバース・プロキシのSSOは、サポート対象の構成です。
この構成に付随する注意事項を次に示します。
注意事項
シングル・サインオン構成でリバース・プロキシを使用するときには、次のいずれかのタスクを必ず実行してください。そうしていないと、リバース・プロキシはクライアントのIPアドレスを隠します。
IPvalidationパラメータにfalseを設定します
または、そのプロキシのIPアドレスをWebゲート登録のIPValidationExceptionsリストに追加します
認証に成功した後、リバース・プロキシが10g Webgate ObSSOCookieをOracle WebLogicに渡さない場合があります。この問題を回避するには:
Oracle WebLogicでリバース・プロキシを使用するときに、Basic Over LDAPではなくフォーム・ベース認証を使用します。
11g Webgateの場合は、セキュリティを考慮してユーザー定義パラメータ(filterOAMAuthnCookie、デフォルトはtrue)を使用して、OAMAuthnCookieをダウンストリーム・アプリケーションに渡すことを防止できます。このCookieを渡す必要がある場合は、filterOAMAuthnCookieパラメータにfalseを設定します。
