| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
この章では、Access Managerシングル・サインオンを構成する要素の概要を示します。これにより、管理者にポリシーの開発を始めるための基礎が提供されます。
この章には次のトピックが含まれます:
|
注意: 特に明記しないかぎり、この章の情報は、すべてのエージェント・タイプとAccess Manager資格証明コレクタに共通です。シングル・ログアウトの詳細は、第22章「11g Webゲートが関与するセッションの集中ログアウトの構成」を参照してください。 |
ログインは、ユーザーが認証し、保護されたアプリケーションへのアクセス権を取得するためのアクションです。シングル・サインオン(SSO)は、ユーザーが一度の認証で複数の保護されたリソース(Webページやアプリケーション)にアクセスできるようにするプロセスです。SSOはAccess Managerによって実現されます。SSOを使用すると、同一セッションで他のアプリケーションにアクセスする際に、再びログインしたり、別のログインを使用したりする必要がなくなります。
Access Managerは、いくつかのSSOアーキテクチャ(パートナ・ネットワークのアイデンティティ・フェデレーション、サービス指向アーキテクチャなど)をひとつにまとめ、共通のSSOエンジンを介して、複数のプロトコルにわたって一貫したサービスにSSOを提供します。Oracle Identity Managementインフラストラクチャでは、ユーザー・アイデンティティをポリシー内で参照されるアイデンティティ・ストアに格納します。
|
注意: コンテキスト・データは、ユーザー操作の様々なステージで、Access Managerに対して提示する情報またはAccess Managerによって収集される情報です。そのようなステージには、認証、認可、エンタープライズSSO、フェデレーション、適応認証、トークン検証、セッション作成などがあります。情報自体は、ユーザーのデバイス・フィンガープリント、IPアドレス、ウイルス対策およびファイアウォール防御、アサーションなどを構成できます。Access Managerと統合したときにコンテキスト・データ・プロバイダおよびアサーション・プロバイダの役割を果たすコンポーネントには、エンタープライズ・シングル・サインオン、Identity Federation、Oracle Adaptive Access Managerなどがあります。 |
表18-1に、Access Managerのポリシーをサポートまたは施行するコンポーネントの概要を示します。また、これらのコンポーネントの詳細が説明されている場所を必要に応じて示しています。
|
注意: 明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Managerのデフォルトの動作ではアクセスが拒否されます。認証タスクをAccess Managerに委任するには、エージェントが依存する相手とともに存在し、Access Managerに登録されている必要があります。エージェントを登録すると、エージェントとAccess Manager SSOとの間で必要な信頼メカニズムが設定されます。 |
表18-1 サマリー: SSOのコンポーネント
| コンポーネント | 説明 |
|---|---|
|
アプリケーション |
アプリケーションは、認証と認可をAccess Managerに委任して、登録済エージェントからのヘッダーを受け入れます。 注: 外部アプリケーションは認証が委任されません。かわりに、アプリケーション・ユーザー名とパスワードを求めるHTMLログイン・フォームが表示されます。たとえば、 Yahoo! Mailは、HTMLのログイン・フォームを使用する外部アプリケーションです。 |
|
管理者以外のユーザーは、最初に保護されたリソースのURLを入力して、アクセスを取得します。このURLは、SSOログイン・ページを返します。 関連項目: 「Access Manager資格証明コレクションおよびログインの概要」。 管理ユーザーは、URL (https://host:port/oamconsole)を入力してコンソールにアクセスすると、ポリシーを作成できます。ただし、エージェントの登録時にデフォルトのポリシーが自動的に生成されます(第16章を参照)。 |
|
ポリシー強制エージェント |
関連項目: 第15章「エージェントおよび登録の概要」。 |
|
資格証明コレクタおよび通信チャネル |
関連項目: 表19-5「DCCとECCの比較」 |
|
SSOエンジン |
セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。 関連項目: 第17章「Access Managerセッションの維持」および第22章「11g Webゲートが関与するセッションの集中ログアウトの構成」 |
|
レガシー・システムをサポートするプロキシ |
|
|
アクセス・ポリシー |
登録済エージェントは、Access Manager認証、認可およびトークン発行ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。 注: 明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Managerのデフォルトの動作ではアクセスが拒否されます。 |
|
ポリシー・ストア |
本番環境ではデータベースです(それ以外の場合は、oam-config.xml)。 関連項目: 第5章 |
|
暗号化キーおよびキー・ストレージ |
登録されたmod_ossoまたは11g Webgateごとに1つのキーが生成および使用されます。ただし、すべての10g Webgateで単一のキーが生成されます。 |
|
Cookie |
関連項目: 「SSO Cookieの理解」。 |
|
注意: Oracle Access Managementコンソールと、WebLogicコンテナにデプロイされたその他のOracle Identity Managementコンソールのシングル・サインオンは、事前登録済のIAMSuiteAgentとコンパニオン・ポリシーを使用して有効化されます。これらのコンソールの保護に、それ以上の構成は必要ありません。 |
シングル・サインオンは、表18-2に示すように実装できます。この表には、追加情報の参照先が含まれています。
表18-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に登録することによって、このサポートを継続できます。 |
管理者は、Access Managerを使用して、ユーザーの資格証明が1回検証された後にユーザーが実行する各アプリケーションに提供される信頼網を構築できます。これらの資格証明を使用すると、固有のメカニズムによるユーザーの再認証をアプリケーションで実行する必要がありません。
アプリケーションのシングル・サインオンを使用すると、Access Managerによって認証されたユーザーは、アプリケーションにアクセスする際に再認証は必要ありません。
Cookieの使用: ユーザーの識別にアプリケーションで抽出する必要があるブラウザのCookieに特定の値が設定されます。
ヘッダー・レスポンス値は、OAMエージェントによってリクエストに挿入され、Access Manager 11gに登録されているエージェントによって保護されている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コンソールを使用して管理タスクおよびモニタリング・タスクを実行する際、ドメインを切り替えることができますが、その際接続する管理サーバーが切り替わります。
複数のドメインを作成した場合、各ドメインは固有のデータベース・スキーマを参照する必要があります。ドメイン間で構成されたリソースまたはサブシステムを共有できません。たとえば、1つのドメインにJDBCデータ・ソースを作成する場合、別のドメインの管理対象サーバーまたはクラスタで使用できません。かわりに、2番目のドメインに類似するデータ・ソースを作成する必要があります。さらに、2つ以上のシステム・リソースに同じ名前を使用できません。
これは、サポート対象の構成ですが、次の注意事項が付随します。
注意事項
シングル・サインオン構成でリバース・プロキシを使用するときには、次のいずれかのタスクを必ず実行してください。そうしていないと、リバース・プロキシはクライアントのIPアドレスを隠します。
IPvalidationパラメータにfalseを設定します
または、そのプロキシのIPアドレスをWebゲート登録のIPValidationExceptionsリストに追加します
認証に成功した後、リバース・プロキシが10g Webgate ObSSOCookieをOracle WebLogicに渡さない場合があります。この問題を回避するには:
Oracle WebLogicでリバース・プロキシを使用するときに、Basic Over LDAPではなくフォーム・ベース認証を使用します。
11g Webgateの場合は、セキュリティを考慮してユーザー定義パラメータ(filterOAMAuthnCookie、デフォルトはtrue)を使用して、OAMAuthnCookieをダウンストリーム・アプリケーションに渡すことを防止できます。このCookieを渡す必要がある場合は、filterOAMAuthnCookieパラメータにfalseを設定します。
Access Managerは、Oracle Access ManagerとOSSOのポリシー・モデルを抽出して単一のAccess Managerポリシー・モデルを構成します。図18-1に、Access Manager 11gポリシー・モデルの主な要素(共有ポリシー・コンポーネント、個別のアプリケーション・ドメイン、外部依存関係など)を示します。
共有ポリシー・コンポーネント
共有ポリシー・コンポーネントはグローバルであり、1つ以上のアプリケーション・ドメインで使用できます。図18-2に、Access Managerポリシーの共有コンポーネントを示します。
表18-3に、Access Managerポリシーのグローバルな共有コンポーネントの説明を示します。
表18-3 Access Managerのグローバルな共有ポリシー・コンポーネント
| コンポーネント | 説明 |
|---|---|
|
リソース・タイプ |
保護するリソースのタイプと関連の動作を定義します。デフォルトのリソース・タイプはHTTPです。ただし、管理者はアプリケーション・ドメイン内の特定のリソースに適用可能なHTTP以外のリソース・タイプを定義できます。 特定のリソース・タイプには、任意の数のリソースが属することが可能です。ただし、1つのポリシーに追加する各リソースは、1つのタイプとして定義されている必要があります。
関連項目: |
|
ホスト識別子 |
ホストに複数の名前を指定できます。OAMでリソースのURLを識別できるように、OAMはリソースのホスト・コンピュータを参照する様々な方法を認識する必要があります。 Access Managerでは、使用可能なホストのバリエーションはすべてまとめて格納されます。管理者は、ホストの正規の名前およびユーザーがホストを表現できる他のすべての名前を入力します。リストのアドレスに送信されるリクエストは、公式のホスト名にマップされます。 アプリケーション・ドメインの認証および認可ポリシーは、ホスト識別子に基づいてリソースを保護します。ホスト識別子を使用して実行時にリソースまたはアプリケーションを識別し、設計時にアプリケーション・リソースのポリシーを作成できます。 ホスト識別子は、エージェントの登録中に自動的に生成でき、新しいアプリケーション・ドメインでリソース定義およびデフォルトの認証ポリシーと認可ポリシーをシードするために使用されます。 また、管理者は1つ以上のアプリケーション・ドメインで使用されるホスト識別子の定義を作成できます。 仮想Webホスティング: 単一のサーバーでユニークなサブディレクトリに解決する複数のドメイン名とIPアドレスのサポートを有効にします。同じホストが、複数のNICカード(IPベース)または同じIPに解決する複数の名前(たとえば、abc.comとdef.com)に基づいて、サービスを受ける複数のサイトを持つことができます。 関連項目: 「ホスト識別子について」 |
|
認証スキーム |
ユーザーの認証に必要なチャレンジ・メカニズム、信頼レベルおよび基礎となる認証モジュールまたはプラグインを定義する名前付きコンポーネント。Access Managerには、複数のデフォルト認証スキームが用意されています。また、管理者は独自のスキームを定義することもできます。 Access Managerを使用してユーザーのアイデンティティを認証することは、事前定義された一連のプロセスを実行してユーザーのデジタル・アイデンティティを確認することを示します。1つの認証スキームは、複数の認証ポリシーに割り当てることができます。ただし、1つの認証ポリシーには、1つの認証スキームのみ割り当てることができます。 注: 認証スキームは、グローバルに定義されるため、少人数の管理者が一貫性のあるセキュアな方法で定義できます。 関連項目: 「認証スキームの管理」 |
|
認証モジュールおよびプラグイン |
認証スキームの最小実行単位です。認証モジュールは、準拠する正確な手順および資格証明にユーザーを要求する方法を決定します。 認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。 認証処理では、1つの認証モジュールを使用して、バックエンド認証スキームに対する情報の要件および転送を制御するルールを定義します。プラグインにより収集され、コンテキストに保存された情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データを使用して、ユーザーのログイン・ページのCookieやヘッダーを設定することもできます。 複数のプラグインと事前定義済モジュールが用意されています。プラグインは、必要に応じて複数ステップの認証を構成および編成できるため、プラグインの使用をお薦めします。 関連項目: |
Access Managerのポリシー・コンポーネント
リソースが明示的にアクセスを許可するポリシーで保護されていない場合、Access Managerのデフォルトの動作として、アクセスが拒否されます。表18-4に、アクセスを許可するように構成できるポリシー・コンポーネントの説明と、詳細の参照先を示します。
表18-4 Access Managerのポリシー・コンポーネント
| コンポーネント | 説明 |
|---|---|
|
アプリケーション・ドメイン |
各アプリケーション・ドメインは、各リソースと、それらのリソースにアクセス可能なユーザーを示すために関連付けられたポリシーを格納する論理コンテナを提供します。アプリケーション・ドメインは、エージェントの登録時に自動的に作成されるようにすることも、コンソールを使用して手動で作成することもできます。 |
|
リソース定義 |
定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。 関連項目: 「ポリシー・リソース定義の追加および管理」 |
|
認証ポリシー |
1つの認証ポリシーでのみ、アプリケーション・ドメインで定義された各リソースを保護できます。各認証ポリシーには、1つの認証スキームが必要です。 1つの認証ポリシーにより、多くのリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。 関連項目: 「特定のリソースに対する認証ポリシーの定義」 |
|
認可ポリシー |
1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。ポリシーには、それぞれ1つ以上の条件およびルールを含めることができます。認可ポリシーには、成功レスポンスも含めることができます。 1つの認可ポリシーで複数のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。 関連項目: 「特定のリソースに対する認可ポリシーの定義」。 |
|
トークン発行ポリシー |
生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。条件やルールは自動的に生成されません。これらは手動で追加する必要があります。 関連項目: 「トークン発行ポリシー・ページについて」。 |
|
ポリシー・レスポンス |
すべてのポリシー・タイプに使用できます。認証および認可の成功レスポンスをそれぞれのポリシー内で定義して、ポリシー評価後に適用できます。 関連項目: 「SSOのポリシー・レスポンスの概要」。 |
|
ルール |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシーには、保護対象のリソースへのアクセスを許可または拒否するかどうかを定義したルールが含まれています。 ルールは、次で説明されている認可条件を参照します。 関連項目:「認可ポリシー・ルールおよび条件の概要」。 |
|
条件 |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシー・ルールは、ルールの適用対象、時間の条件が存在するかどうか、および評価結果の適用方法を定義する条件を参照します。 条件は、ルールの外部で宣言され、ルール内から参照されます。 関連項目:「認可ポリシー・ルールおよび条件の概要」。 |
Access Managerを使用すると、アプリケーション・ドメイン内で定義されているポリシーに基づいて、誰がリソースにアクセスできるかを制御できます。ユーザーは、ブラウザにURLを入力する、アプリケーションを実行する、他のなんらかの外部ビジネス・ロジックをコールするといった方法によって、保護されているリソースにアクセスを試みます。ユーザーが保護されているリソースへのアクセスをリクエストすると、特定のリソースへのアクセスを認可されている認証ユーザーと認可されていない認証ユーザーを選別するポリシーに従って、リクエストが評価されます。
アプリケーション・ドメインは、相互に階層の関係がありません。各アプリケーション・ドメインを作成して、全体のアプリケーションのデプロイメント、特定の層のデプロイメントまたは単一のホストに関連するポリシー要素を含めることができます。
各アプリケーション・ドメイン内では、アクセスを制御する特定のポリシーによって、特定のリソースが保護対象として識別されます。認証ポリシーおよび認可ポリシーには、成功と評価された場合に適用されるレスポンスが含まれます。このレスポンスは、管理者が構成します。認可ポリシーには、評価の実行方法を定義する条件とルールおよび成功と評価された場合に適用されるレスポンスが含まれます。これらの条件とルールおよびレスポンスは、管理者が構成します。
アプリケーション・ドメインのサイズと数は、管理者が決定します。それを決定するために、必要に応じて、個々のアプリケーション・リソースまたは他の論理グループを使用できます。アプリケーション・ドメインは、エージェント登録時に自動的に作成されます。また、管理者はアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを追加すると、同じエージェントを使用して複数のアプリケーション・ドメインを保護できます。
図18-3に、アプリケーション・ドメイン内のポリシーの詳細およびアプリケーション・ドメインでの共有要素の使用方法を示します。
詳細な情報は、次のトピックを参照してください:
リソースという用語は、OAMサーバーに格納されていて、多くのユーザーがアクセスできるドキュメント、エンティティまたは一部のコンテンツを表します。
クライアントは、特定のプロトコル(HTTPやHTTPSなど)を使用してOAMサーバーと通信し、既存のリソース・タイプに該当するリソースをリクエストします。各HTTPリソース・タイプをホスト識別子に関連付ける必要があります。ただし、HTTP以外のリソース・タイプは、(ホスト識別子ではなく)特定の名前に関連付けられます。
Access Managerでは、各リソースを特定のポリシーと関連付けるために、アプリケーション・ドメインのリソース・コンテナ内でリソースとして定義する必要があります。
|
注意: アプリケーション・ドメイン内のポリシーに関連付けできるリソースは、リソース・コンテナで定義されているリソースのみです。 |
詳細は、「ポリシー・リソース定義の追加および管理」を参照してください。
|
注意: ページの内容の一部を保護するには、Oracle Entitlements Serverの使用をお薦めします。 |
管理者は、認証ポリシーを作成して、アプリケーション・ドメイン内の特定のリソースに適用できます。各認証ポリシーで指定する内容は次のとおりです。
このポリシーが適用される特定のリソースを指定します。このリソースは、このポリシーの「リソース」タブで、アプリケーション・ドメインのリソース・コンテナに定義する必要があります。
ユーザーの認証に使用するチャレンジ・メソッドを提供する認証スキームを指定します。
このポリシーの評価結果に基づいてユーザーをリダイレクトする成功URL (および失敗URL)を指定します。
エージェントが実行する認証後アクションを指定するオプション・レスポンスを定義します。
ポリシー・レスポンスには、情報をセッションに挿入して後で抽出する機能があります。これにより、Oracle Access Manager 10gよりも堅牢性と柔軟性が強化されます。Oracle Access Manager 10gでは、特定の順序でURLにリダイレクトすることでアプリケーションへの(アプリケーション間の)データの経路を提供していました。
ポリシー・レスポンスはオプションです。これらは、管理者が構成する必要があり、アプリケーション・ドメイン内で定義されている特定のリソースに適用する必要があります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。
認証ポリシーの評価結果
Access Managerはユーザーを認証するために、このポリシーの認証スキームによって定義されているチャレンジ・メソッドに基づいて、認証資格証明のリクエストをユーザーのブラウザに示します。
ポリシーの評価後に、結果が返され、ユーザーはその結果に基づいてリダイレクトされます。
成功(アクセスを許可)の場合、リクエストしたURLにリダイレクトされます。
失敗(アクセスを拒否)の場合、汎用エラー・ページにリダイレクトされます。
|
注意: ポリシーの評価結果は、ポリシーごとにオーバーライドされます。 |
認可は、ユーザーにリクエストしたリソースのアクセス権があるかどうかを決定するプロセスです。たとえば、ユーザーは、データを表示したり、ポリシーで保護されているアプリケーション・プログラムを実行したりできます。
管理者は、認可ポリシーを作成して、サブジェクトまたはアイデンティティが特定のリソースにアクセスできる条件を指定できます。リクエストしたリソースは、アプリケーション・ドメインに属している必要があり、特定の認可ポリシー内に含まれている必要があります。
|
注意: OracleAS SSO 10gは認可しません。OSSOエージェントは、Access Manager 11g認可ポリシーを使用しません。 |
各認可ポリシーで指定する内容は次のとおりです。
このポリシーが適用される特定のリソースを指定します。このリソースは、このポリシーの「リソース」タブで、アプリケーション・ドメインのリソース・コンテナに定義する必要があります。
このポリシーの評価結果に基づいてユーザーをリダイレクトする成功URL (および失敗URL)を指定します。
このポリシーおよびリソースに定義されている条件に基づいて、特定の許可ルールまたは拒否ルールを指定します。条件タイプの概要は、表18-5を参照してください。
認可後にエージェントが実行するアクションを特定する、オプションのレスポンスを定義します。「SSOのポリシー・レスポンスの概要」を参照してください。
トークン発行ポリシーは、クライアントのアイデンティティに基づいてリソース(リライイング・パーティ・パートナ)のトークンを発行する際に従うルールを定義します。クライアントは、リクエスタ・パートナまたはエンド・ユーザーのどちらかです。
特に明記しないかぎり、アプリケーション・ドメインおよび認可ポリシーに関する情報は、トークン発行ポリシーにも同様に適用されます。
|
注意: ポリシーが自動生成される際は、トークン発行ポリシーは作成されません。トークン発行ポリシー用のコンテナのみが自動生成されます。 |
トークン発行ポリシーに固有の情報は、次を参照してください。
特に明記しないかぎり、ポリシーの条件およびルールに関する情報は、次のポリシーに同様に適用されます。
認可ポリシー
トークン発行ポリシー
条件
条件は、認可ポリシー内およびトークン発行ポリシー内でのみ指定できます。条件は、定義されている条件に基づいてアクセスの許可または拒否を指定するルールと連携させて使用します。表18-5に、使用可能な条件タイプを示します。
表18-5 条件タイプ
| タイプ | 詳細の参照先 |
|---|---|
|
アイデンティティ |
|
|
IP4範囲 |
|
|
一時的 |
|
|
属性 |
|
|
True |
実質的には「すべて許可」。これを、認証された任意の使用を認める必要がある場合のデフォルト・オプションとして使用することをお薦めします。この場合、認可時に特定の条件が満たされる必要はありません。 これは、Access Managerの前のリリースの「暗黙的な制約の使用」フラグにかわるものです。「暗黙的な制約の使用」フラグも同様に、制約が特に定義されていない場合に、ポリシーの評価を、結果を許可として完了させます。 |
認可ポリシーおよびトークン発行ポリシーはそれぞれ、1つ以上の条件オブジェクトを含めることができます。ポリシーの条件タイプ1つにつき複数のインスタンスが存在可能です(以前のポリシー・モデルではクラス1つにつき1つのインスタンスのみ存在可能でした)。
条件は、Access Manager 11gの以前の認可制約に似ています。ただし、制約では許可または拒否を指定できますが、条件では指定できません。
ルール
ルールはポリシー・モデルの新しい構造です。各ルールは、ポリシーの全体的な結果を決定する許可指定または拒否指定を定義します。ルールは、さらに、各条件の評価結果を組み合せる方法を定義します。条件はルールで参照され、ルールの外部で宣言されます。
ルール内で、評価結果を次のように組み合せることができます。
簡易モード: すべての条件が満たされる場合またはいずれか1つの条件が満たされる場合のどちらかの場合に評価としてtrueを返すことができるコンバイナの値に基づいて組み合された条件名のリストを受け入れます。(以前は、ALLは制約を許可し、ANYは制約を拒否していました。)
式モード: ユーザーは、条件名と特殊文字(カンマ「,」、縦線「|」、アンパサンド「&」および感嘆符「!」)を使用して条件を組み合せたブール式を指定できます。
|
注意: 許可ルールまたは拒否ルールのどちらにも属さない条件が複数存在するポリシーは、有効なポリシーとして処理されます。 |
条件およびルールの詳細は、第20章を参照してください。
この項では次のトピックを記載しています:
Access Managerは、認証プロセス時の資格証明コレクションに、2つのメカニズムを提供します。
デフォルトの埋込み資格証明コレクタ(ECC)は、Access Managerサーバーとともにインストールされるため、追加のインストールや設定手順なしで使用できます(ただし、グローバル・パスワード・ポリシーを除きます。「グローバル・パスワード・ポリシーの管理」を参照してください)。
ユーザーをポリシー強制点から資格証明コレクタにリダイレクトするメカニズムは、HTTP上のフロント・チャネル・プロトコル専用です。このプロトコルは、現時点では、リクエストのコンテキストと、問合せ文字列に対する認証レスポンスを提供します。
11.1.2以降のWebゲートは、オプションの外部資格証明コレクタ(DCC)に切り替えるための1つのスイッチが用意されています。DCCを使用すると、本番環境に強固なセキュリティを提供するネットワーク分離が可能になりますが、いくつかの形式の認証が必要になります。
特に明記しないかぎり、このドキュメントの説明は、ECCの使用を前提にしています。
シングル・サインオンのログイン処理は、ユーザーが有効なユーザーかどうかと、セッション状態がアクティブまたは非アクティブ(初回のユーザーまたはユーザー・セッションの期限が切れている場合)かを決定します。セッション管理サポートでは、セッション・コンテキストおよびユーザー・トークンを検索、保持および消去します。
セルフサービス・プロビジョニング・アプリケーションを使用したログイン
プロビジョニングは、Access Managerのセッションを作成しません。新しいユーザーがセルフサービス・プロビジョニング・アプリケーションを使用してアカウントを作成すると、ユーザーはアプリケーションにアクセスするときにユーザーIDとパスワードを再度求められます。
保護されているアプリケーションはAccess Manager 11gに転送され、Access Manager 11gがユーザーの資格証明をリクエストします。たとえば、Oracle Identity ManagerがAccess Managerで保護されている場合、ユーザー・リクエストは、資格証明の入力をリクエストするAccess Managerにリダイレクトされます。
成功の結果と失敗の結果は、「Access Managerで保護されたリソースへのログイン処理」で説明するとおりです。
Access Managerで保護されたリソースへのログイン処理
ユーザーが保護されたリソースに初めてアクセスすると、リソースの認証スキームと認証レベルに基づいて資格証明が求められます。通常は、ユーザーIDとパスワードが必要になります。
失敗: ユーザーIDまたはパスワードの入力に間違いがあると、認証は失敗します。ユーザーは認証されずに、資格証明を求める別のプロンプトが表示されます。
Oracle Access Manager 11.1.1では、OAMサーバー内のECCのみが使用可能でした。Access Manager 11.1.2は、デフォルトでECCをサポートします。ただし、Access Managerでは、外部資格証明コレクタ(DCC)として使用するように、11g Webゲートを構成することもできます。DCCを有効化したWebゲートは、リソースWebゲートと分離(または組合せ)できます。
ECCとDCCは、どちらもフォームのログイン、エラー、ログインの再試行を含む認証フローを提供します。これらは、SecurIDとサーバーのアフィニティの他、パスワード・ポリシーの実施や、資格証明が一度に提供されない、動的、マルチステップ、反復および変数の認証(マルチステップ認証)を提供します。カスタマイズ可能な認証フローには、認証プラグインを含めることができます。この認証プラグインは、そのプラグインとOAMプロキシ、資格証明コレクタ間のコントラクトを持つもの、そのプラグインとログイン・アプリケーション間のコントラクトを持つもの、資格証明コレクタとログイン・アプリケーション間のコントラクトを持つものがあります。
どちらの(または両方の)資格証明コレクタを使用するかを決定するときには、次の事項について検討します。
共存: ECCとDCCの共存を許可すると、ECCまたはDCCに対応した構成の認証スキームとポリシーを使用できるようになります。これにより、ECC(たとえば、Oracle Access Managementコンソール)に依存するリソースにフォールバック・メカニズムを使用できるようになります。
ECCを無効にする: ECCを無効にすると、ECCメカニズム(たとえば、Oracle Access Managementコンソール)に依存するリソースへのアクセスを、完全に禁止することになります。
表18-6に、詳細へのリンクを示します。
表18-6 Access Managerで保護されたリソースへのログイン処理
| ログイン処理の項目 | 次を参照してください。 |
|---|---|
|
OAMエージェントとECCの使用 |
「OAMエージェントとECCを使用するSSOログイン処理について」 |
|
OAMエージェントとDCCの使用 |
「OAMエージェントとDCCを使用するログイン処理について」 |
|
OSSOエージェントとECCの使用 |
「OSSOエージェント(mod_osso)とECCを使用するSSOログイン処理について」 |
|
その他のエージェントまたは混在するエージェント・タイプの使用 |
混在しているエージェント・タイプがサポートされています。各エージェント・タイプの処理は同じです。その他のエージェントタイプについては、次を参照してください。 |
|
Oracle ADFセキュリティを使用したアプリケーションのログインおよび自動ログイン |
Oracle Platform Security Services (OPSS)は、Oracle WebLogic Serverの内部セキュリティ・フレームワークで構成されます。Oracle WebLogic Serverでは、Oracle Application Development Framework (Oracle ADF)セキュリティを使用し、Access Manager 11g SSOと統合して、ユーザー認証にOPSS SSOを使用するWebアプリケーションを実行できます。 詳細については、付録A「Oracle ADFアプリケーションとAccess Manager SSOの統合」を参照してください。 |
この項は、OAMエージェント(リソースを保護するリソースWebゲート)にデフォルトの埋込み資格証明コレクタを使用していることを前提にしています。
Access Managerは、顧客が指定した認証方式で各ユーザーを認証してアイデンティティを決定し、ユーザー・アイデンティティ・ストアに格納されている情報を利用します。Access Managerの認証では、いくつかの認証方法と複数の認証レベルをサポートしています。より厳密な認証方式に対応する高いレベルの認証を要求すると、様々な機密度のリソースを保護できます。
ユーザーが保護されているアプリケーションにアクセスしようとすると、Access Managerがリクエストを受け取り、SSO Cookieの有無を確認します。
ユーザーを認証してユーザー・コンテキストおよびトークンを設定した後、Access ManagerはSSO Cookieを設定して、SSOサーバー・キーでCookieを暗号化します(このキーは、SSOエンジンでのみ復号化できます)。
認証の成功および失敗に対して指定されているアクション(Access Manager 11gのレスポンス)に応じて、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を介してユーザー情報が他のアプリケーションに渡されたりします。
認可ポリシーおよび確認結果に基づいて、リクエストした内容へのユーザーのアクセスが許可または拒否されます。ユーザーは、アクセスが拒否されると、別のURL (Webgate登録で管理者が指定)にリダイレクトされます。
図18-4は、ポリシーの評価、ユーザーのアイデンティティの検証、保護されたリソースへのユーザーの認可および保護されたリソースの使用に含まれるプロセスを示しています。この例は、OAMエージェント・フローを示しています。11g Webgate/アクセス・クライアントの場合は、多少異なります。
プロセスの概要: 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン処理
Webgateは、ポリシー評価のリクエストをAccess Managerに送信します。
Access Managerは次を実行します。
SSO Cookieの有無を確認します。
ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。
Access Managerサーバーは、決定をログに記録して返します。
Webgateは、次のように応答します。
保護されていないリソース: リソースがユーザーに提供されます。
保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。
認証ポリシーに基づくログイン・フォームが提供されます。
認証処理が開始されます。
ユーザーは資格証明を送信します。
Access Managerは、資格証明を検証します。
Access Managerはセッションを開始し、次のホストベースCookieを作成します。
エージェントごとに1つ: 認証に成功した後にOAMサーバーから受け取った認証トークンを使用して11g Webgateによって設定されるOAMAuthnCookie (10g Webgateによって設定されるObSSOCookie)。
注: 有効なCookieがセッションに必要です。
OAMサーバーに1つ: OAM_ID
Access Managerは、成功または失敗をログに記録します。
資格証明コレクタがWebgateにリダイレクトされ、認可処理が開始されます。
Webゲートは、ポリシーの検索、ユーザーのアイデンティティとの比較およびユーザーの認可レベルの決定をAccess Managerに求めます。
Access Managerは、ポリシー決定をログに記録し、セッションCookieを確認します。
OAMサーバーは認可ポリシーを評価し、結果をキャッシュします。
OAMサーバーは、決定をログに記録して戻します。
Webgateは、次のように応答します。
認可ポリシーでアクセスを許可すると、目的の内容またはアプリケーションがユーザーに提供されます。
認可ポリシーによってアクセスが拒否された場合、ユーザーは、管理者が決定した別のURLにリダイレクトされます。
外部資格証明コレクタとは、デプロイメント内で追加の資格証明コレクション機能を使用するように構成された、Webゲートのことです。DCC Webゲートでもアプリケーションを保護するかどうかによって、2つのデプロイメント・タイプが存在します。
表18-7に、DCCがサポートされるデプロイメントを示します。
表18-7 DCCデプロイメントのサポート
| デプロイメント・タイプ | 説明 |
|---|---|
|
独立したDCCとリソースWebゲート |
アプリケーションを保護するWebゲートが、一元化されたDCCとは別に独立的に管理されている分散デプロイメントです。この内容は、次のようになります。
ユーザーエージェントとDCCとの間のHTTPSを有効にします(ただし、一部またはすべてのリソースWebゲートとのHTTPSは有効にしません)。 資格証明コレクションがDCC Webゲートに外部化されて一元化されている場合、ユーザーエージェントと他のWebゲートとの接続では、ユーザー資格証明、および他のWebゲートによって保護されているリソースへのアクセスを取得するために使用できるセッション・トークンが伝送されることはありません。これにより、これらのリンクでSSLを使用しないために公開される情報が大幅に減少し、デプロイメントによっては許容可能なトレードオフになります。
関連項目: 図18-5 |
|
DCCとリソースWebゲート一体化 |
構成と処理のオーバーヘッドが最小になる、合理化されたデプロイメントです。 DCC Webゲートは、アプリケーション・リソースを保護するリソースWebゲート(ポリシー強制点)とDCCの両方として機能します。この場合、フロントチャネル・リダイレクションやフロントチャネル処理はありません。
関連項目: 図18-6 |
独立したDCCとリソースWebgate: 図18-5に、DCCを分離したデプロイメントの例を示します。
このトポロジ(図18-5)は、最大のセキュリティ機密性を備えたシナリオに適した選択肢を示しています。集中資格証明コレクションおよび外部資格証明コレクションの両方が使用されています。アプリケーションを保護するリソースWebゲートは、資格証明コレクションを実行するDCC Webゲートから分離されています。
ユーザーは、公衆回線網から、Access Managerによって保護されているリソースにアクセスします。アプリケーションを保護しているWebゲートは、DMZ内にデプロイされます。DCC WebゲートもDMZ内にデプロイされます。保護されているアプリケーションおよびOAMサーバーのインスタンスは、プライベート・ネットワーク内に配置され、公衆回線網から直接アクセスすることはできません。
DMZ内でDCCを使用すると、サーバー自体への接続に認証済のネットワーク接続のみが許可されます。DCCは、11g Webゲートに利用できるすべてのバックチャネル通信の特性を継承します(Oracle Accessプロトコルを使用するネットワーク接続)。OAPは、次の機能を提供します。
クライアントとサーバーの間のSSL (オプションでサード・パーティによる署名済証明書を使用)
クライアントIDおよびパスワードを使用するアプリケーション・レベルの相互認証
アプリケーション・レベルで多重化された全二重通信をリクエスト
組込みの接続ロード・バランシング/フェイルオーバー機能
DCCは、エージェントから認証リクエストを受信すると、DCC Cookieの存在をチェックします。Cookieが存在しない場合、資格証明コレクションが開始され、チェックが行われて、ユーザーが入力した資格証明が検証のために渡されます。
|
注意: 暗号化は、11gリソースWebゲートからDCCの方向でのみ行われます。10gリソースWebゲートと11g DCCの間の通信はクリアテキストで行われ、チャネルは暗号化されません。 |
プロセスの概要: 一体化したDCCとリソースWebゲートによる認証
ユーザーが、認証プロセスを開始するリソースへのアクセスをリクエストします。
DCCは、フロント・チャネルを通じてログイン・ページにリダイレクトします。
ログイン・ページがユーザーに返されます。
ユーザーは、資格証明を入力します。この資格証明はアクションURLにポストされます(認証スキームのユーザー定義パラメータについては、表19-23を参照)。
認証には、バック・チャネル(OAP)とOAMプロキシが使用されます。
認証プラグインがアクティブ化されます。
プラグインは、追加の資格証明を収集するためのURLへのリダイレクトをリクエストします。
プラグインのリクエストは、DCCに返されます。
DCCは、そのURLをリダイレクトして、指定された資格証明を要求します。
ブラウザは、リダイレクトに従います。
資格証明は、アクションURLにポストされます。
登録されたOSSOエージェント(mod_osso)を使用したSSOログイン処理は、Webgateを使用したログイン処理と似ています。ただし、mod_ossoは、Access Manager 11gの認証ポリシーを使用した認証のみを提供します。
|
注意: mod_ossoは、固有の認可またはAccess Manager 11gのポリシーを使用した認可をサポートしません。 |
図18-7は、mod_ossoおよびAccess Manager 11gを使用したログイン処理を示しています。
プロセスの概要: OSSOエージェントとECCを使用したSSOログイン処理
mod_ossoは、ポリシー評価のリクエストをAccess Managerに転送します。
Access Managerは次を実行します。
SSO Cookieの有無を確認します。
ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。
OAMサーバーは、決定をログに記録して戻します。
mod_ossoは、次のように応答します。
保護されていないリソース: リソースがユーザーに提供されます。
保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。
認証ポリシーに基づくログイン・フォームが提供されます。
認証処理が開始されます。
ユーザーは資格証明を送信します。
ECCは資格証明を検証します。
Access Managerはセッションを開始し、認証トークンをアプリケーションに渡して、次のCookieを作成します。
パートナごとに1つ: OHS_host_port
OAMサーバーに1つ: OAM_ID
グローバルな非アクティブ・タイムアウト: ドメインレベルのCookie GITOです。「mod_osso Cookie」を参照してください。
Access Managerは、成功または失敗をログに記録します。
資格証明コレクタは、ユーザーの認可にアプリケーションが使用できる単純なヘッダー値を送信するmod_ossoにリダイレクトされます。
認証に成功すると、リソースが提供され、OHS-host-port Cookieが設定されます。
この項では、Access Manager 11gを使用するシングル・サインオンの概要を簡単に説明します。次のトピックが含まれます:
表18-8は、ユーザー・ログインの実行中に設定または消去できるCookieを示しています。
表18-8 SSO Cookie
| ユーザー・ログインで設定されるSSO Cookie | 設定元 | 説明 |
|---|---|---|
|
OAM_ID Cookie |
OAMサーバーの埋込み資格証明コレクタ |
ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。 関連項目: 「OAM_ID Cookie」。 |
|
OAMAuthnCookie |
11g Webgate |
アクセスする各11g Webgateによって設定されます。11g WebgateおよびOAMサーバーで認識されるキーで保護されます。有効なOAMAuthnCookieがセッションに必要です。 注: 異なる11g Webgateで保護されるアプリケーションにユーザーがアクセスする場合、複数のOAMAuthnCookieを使用します。 「11g OAM WebgateのOAMAuthnCookie」を参照してください。 |
|
ObSSOCookie |
10g Webgate |
10g Webgateにアクセスする場合のみ、10g WebgateのドメインベースCookieが設定されます。OAMサーバーでのみ認識されるキーで保護されます。すべてのWebgateに対して1つのグローバル共有秘密鍵です。 注: このCookieによって、Access Manager 11gと以前のエージェントの間の下位互換性および相互運用性が実現します。 「10g WebgateのObSSOCookie」を参照してください。 |
|
OAM_REQ |
OAMサーバーの埋込み資格証明コレクタ |
認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。 注: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。 「OAM_REQ Cookie」を参照してください。 |
|
OAMRequestContext |
11g Webgate |
11g Webgateによって設定または設定解除され、11g WebgateおよびOAMサーバーで認識されるキーで保護されます。 Internet Explorerブラウザの場合: --RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextは一時的なCookieになります。 --RequestContextCookieExpTimeが設定されている場合、OAMRequestContext Cookieは、 IE以外のすべてのブラウザでは、RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextはデフォルトの5分間か、 関連項目: 「OAMRequestContext」 |
|
DCCCtxCookie |
外部資格証明コレクタ |
外部資格証明コレクタ(DCC)の場合は、埋込み資格証明コレクタ(ECC)で作成されるOAM_REQと同様になります。 「DCCCtxCookie」を参照してください。 |
|
OHS-host-port |
Oracle HTTP Server |
Oracle HTTP Server (OHS)でOSSOエージェント(mod_osso)にアクセスする場合のみ設定されます。mod_ossoエージェントおよびOAMサーバーで認識されるキーで保護されます。 注: このCookieによって、Access Manager 11gと以前のエージェントの間の下位互換性および相互運用性が実現します。 「mod_osso Cookie」を参照してください。 |
|
GITO Cookie |
OAMサーバー |
OSSO 10gおよびAccess Manager 11gの間の下位互換性および相互運用性を実現します。このCookieはOAMサーバーによって作成され、OAMサーバーまたはmod_ossoエージェントによってアクセスまたは変更されます。 「mod_osso Cookie」を参照してください。 |
|
OpenSSO cookie |
OpenSSOプロキシ |
「OpenSSO Cookie (iPlanetDirectoryPro)」を参照してください。 |
認証および認可ポリシーの構成の詳細は、第20章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。
このCookieは、OAMサーバーが適用範囲になります。OAM_IDは、ユーザーが資格証明のチャレンジを受けたときにOAMサーバーによって生成され、サーバーへのリダイレクトごとにそのサーバーに送信されます。
OAM_IDは、OAMサーバーのみが認識するキーで保護されます。
ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。
Cookieが存在しない場合、ユーザー認証が開始されます。認証に成功した後、ユーザー・コンテキストおよびトークンがSSOエンジンによって設定されます。Cookieは、グローバル・ユーザーID (GUID)、作成時間およびアイドル・タイムアウトの詳細で設定されます。Cookieの情報はSSOサーバー・キーで暗号化され、SSOエンジンでのみ復号化できます。
Cookieが存在する場合、Cookieが復号化され、サインインのフローが認証されたユーザーで終了します。
認証の成功後にOAMサーバーから受け取った認証トークンを使用して各11g Webgateで設定された1つのOAMAuthnCookie_<host:port>_<random number>があります。有効なOAMAuthnCookieがセッションに必要です。
SSL接続: 管理者は、SSLを構成してエージェントおよびサーバーの簡易または証明書モードを指定し、SSL接続でのみObSSOCookieの送信を可能にしてCookieが安全でないWebサーバーに送信されることを防止します。詳細は、「OAMサーバーおよびWebgate間の通信について」を参照してください。
Cookieの有効期間: 11g WebgateおよびOAMAuthnCookieでは、有効なトークン(またはCookie)時間を制御する「tokenValidityPeriod」パラメータで有効期間が管理されます。
このキーは、11g WebgateおよびSSOエンジンで識別され、OAMAuthnCookieの暗号化に使用されます。SSOエンジン・キー(SSOエンジンでのみ識別)は、OAM_ID OAMサーバーCookieの暗号化に使用されます。
10g WebgateのObSSOCookieと同様です。
Access Manager 11gは、10g Webgateで保護されているリソースにアクセスする各ユーザーまたは各アプリケーションに対して、キーベースCookieであるObSSOCookieを設定します。エージェントの登録中にキーが設定され、エージェントおよびSSOエンジンで識別されます(両方で共有されます)。このキーは、OAMサーバー(またはSSOエンジン)キーとは異なります。
ObSSOcookieを削除すると10g Webgateからユーザーがログアウトするので、アクセス・システムで保護されるリソースを次にリクエストするときにユーザーの再認証が必要になります。
Webgateでは、認証が成功すると、ユーザーのブラウザにObSSOCookieを送信します。このCookieは、同等またはそれ以下のレベルの認証を必要とする他の保護されたリソースの認証メカニズムとして使用できます。ユーザーがブラウザまたは別のリソースへのアクセスをリクエストすると、リクエストがOAMサーバーに送信されます。ユーザーがログインし、ObSSOCookieが設定されます。OAMサーバーは、ObSSOCookieを含むURLを使用したセッション・トークンを生成します。ユーザーに認可資格証明を求めるかわりに後続の認可でCookieが使用される場合、シングル・サインオンが有効です。
Cookieが生成されると、Cookieの一部が暗号化されたセッション・トークンとして使用されます。シングル・サインオンCookieは、ユーザー名およびパスワードなどのユーザー資格証明を含みません。
SSL接続: 管理者は、SSLを構成してエージェントおよびサーバーの簡易または証明書モードを指定し、SSL接続でのみObSSOCookieの送信を可能にしてCookieが安全でないWebサーバーに送信されることを防止します。詳細は、「OAMサーバーおよびWebgate間の通信について」を参照してください。
Cookieの有効期間: 管理者は、OAMエージェント登録の目的のCookieセッション時間を指定できます。詳細は、「コンソールを使用したOAMエージェントの登録」を参照してください。
認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。
資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。
高可用性構成では、インフラストラクチャ・セキュリティ・カスタムWLSTコマンドを使用してリクエスト・キャッシュ・タイプをBASICからCOOKIEに変更する必要があります。
|
注意: Oracle共通ホームからWLSTスクリプトを起動する必要があります。『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。 |
このCookieは、11g Webgateによって設定または設定解除され、11g WebgateおよびOAMサーバーで認識されるキーで保護されます。
資格証明が収集され、認証が実行される一方で、このCookieは、保護されたリソースへのユーザーの元のリクエストの状態を格納するように構成されます。
Internet Explorerブラウザの場合:
RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextは一時的なCookieになります。
RequestContextCookieExpTimeが設定されている場合、OAMRequestContext Cookieは、Expiresディレクティブを使用して設定されている時間で有効期限が切れます。これには、クライアント・ホストとWebサーバー・ホスト間の時間同期が必要です。
IE以外のすべてのブラウザでは、RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextはデフォルトの5分間か、Max-Ageディレクティブを使用して設定されている時間で有効期限が切れます。
これは、外部資格証明コレクタ(DCC)にのみ作用します。
DCCCtxCookieは、認証時に必要な各種のコンテキスト情報を保存するために、DCCで使用されます。これに含まれる情報は、認証が完了した時点で元のリクエストを再作成するため、サーバー・アフィニティを保持するため、および反復複数ステップの認証を実行するために必要です。
デフォルトでは、DCCCtxCookieは、認証スキームに基づいて資格証明を収集するために、DCCが最初にリダイレクトされたときに設定されます(フォームによる認証スキームでは、ブラウザが最初にログイン・フォームにリダイレクトされたとき)。
DCCの場合、認証後にOAMサーバーが、認証レスポンスでDCCに向けてDCCセッション・トークンを発行します。その後で、DCCはこのトークンを使用してホストベースのDCC Cookieを設定し、次の処理を実行します。
認証時にDCC Cookieが提示された場合: DCCは、DCCキーを使用してトークンを復号し、部分的なトークンの検証をローカルに実行します(整合性チェック、トークンの有効期間チェック)。この検証をパスすると、DCCはOAMサーバーに対するOAPチャネルで、タイムアウトについての完全なトークンの検証を実行します。
DCC Cookieが存在しない場合: これは、最初の認証であることを示すため、資格証明コレクションが開始し、資格証明のサニティ・チェックと構文チェックを実行してから、その資格証明を検証するためにOAMサーバーに送信します。
mod_ossoモジュールは、OracleASアプリケーションの認証を提供するOracle HTTP Serverモジュールです。ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onで保護されるアプリケーションを有効化してユーザー名およびパスワードのかわりにHTTPヘッダーを受け入れるOracle HTTP Serverにこのモジュールが存在します。これらのヘッダーの値がmod_osso Cookieに格納されます。
アプリケーション・サーバーに格納されるmod_ossoは、シングル・サインオン・サーバーの唯一のアプリケーションとして認証プロセスを簡易化します。このため、mod_ossoは、OracleASアプリケーションに透過的な認証を実現します。これらのアプリケーションの管理者は、アプリケーションをSDKに統合する負担がなくなります。mod_ossoは、ユーザーを認証した後、アプリケーションがユーザーを認可するために使用できる単純なヘッダー値を送信します。
GITO Cookie
複数のタイプのエージェント(mod_ossoおよびWebgate)がAccess Manager 11gとともに動作している場合にタイムアウトをサポートするために、特殊な状況で必要になります。サーバー側のセッション・マネージャは、セッションの検証中に有効期間およびタイムアウトのCookieの妥当性を確認できます。エンティティのセッションのログアウトでログアウトがすべてのエンティティに伝播していることを確認するには、OSSOエージェント(mod_osso)のグローバル・ログアウトが必要です。
ユーザーがOSSO 10gで認証される場合、OSSOサーバーはGITO Cookieを設定します。パートナCookie (OHS Cookie)が設定されると、OHSはサーバーのリクエストをルーティングしません。かわりに、OHSはアクセスごとにGITO Cookieを復号化し、最後のアクティビティのタイムスタンプを更新します。リクエストの処理中に、現在の時間がGITOタイムアウト(最終アクティビティ時間 + GITOタイムアウト)を超えたことをパートナが検出すると、リクエストが強制認証モードでOSSO 10gに送信されます。リクエストが強制認証モードでOSSOサーバーに達すると、サーバーはSSO_ID Cookieを無視して、新しいリクエストとして資格証明のユーザーを要求します。認証に成功した後、SSO_IDおよびGITO Cookieが更新されます。
Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスに従ってeditGITOValues WLSTコマンドを使用すると有効になります。
OssoSecureCookiesディレクティブ
OssoSecureCookiesディレクティブを追加して、すべてのCookieにSecureフラグを設定します。これにより、HTTPSで保護された接続のCookieのみの送信がブラウザに通知されます。mod_osso構成(mod_osso.conf)のこのディレクティブの例は、次のとおりです。
<IfModule mod_osso.c> OssoIpCheck off OssoIdleTimeout off OssoSecureCookies on OssoConfigFile osso/osso.conf <Location /j2ee/webapp> require valid-user AuthType Basic </Location> </IfModule>
詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。
OpenSSOプロキシがセッション検証をトリガーした後、エージェントがこのCookieを検出します。OpenSSO cookieのデフォルト名は次のとおりです。
iPlanetDirectoryPro
OpenSSOエージェントは、認証されてログインした後、ユーザーがOpenSSO Cookieを持っているかどうかを検証します。持っていない場合、OpenSSOエージェントがユーザー認証リクエストを開始します。SSOユーザー・ログインおよび認証フロー中に、OpenSSO Cookieが作成され、ユーザーのブラウザに設定されます。このCookieにはOpenSSOセッション識別子が含まれます。
エンド・ユーザー・セッション検証では、OpenSSOエージェントが保護されているアプリケーションへのリクエストを捕捉し、OpenSSO Cookieを検出します。
ユーザー・シングル・ログアウト時に、OpenSSOプロキシはユーザー・ログアウト・リクエストを受信して、ユーザーをOAMログアウトURLに転送します。OpenSSOプロキシは、OpenSSO Cookieを復号化して、OpenSSOセッション識別子をフェッチし、そこからOAMセッションIDをフェッチします。OpenSSOプロキシは、ログアウト・リクエストをOAMセッションIDとともに、OpenSSOログアウト・イベントを介して、コントローラに送信します。
SSOユーザー・ログインおよび認証フロー
エンド・ユーザー・セッションの検証フロー
ユーザー・シングル・ログアウト・フロー
次の概要では、Access Manager 11gを使用するシングル・サインオンを構成するために管理者が実行する必要があるタスクについて説明します。タスクごとに、詳細情報へのリンクを提供しています。
この章のすべてのトピックを確認し、Access Manager 11gのSSOポリシー・モデルを理解します。
固有のアプリケーションのドキュメントを使用して、保護しようとするアプリケーションごとにシングル・サインオン・ログアウトURLを構成します。
どちらかの方法を使用して保護するアプリケーションをホストしている各Webサーバーに、エージェントをインストールし、登録します。関連項目:
リソース・タイプ、ホスト識別子、認証スキームおよびモジュールの管理に進みます。
既存のアプリケーション・ドメインを検索して(または新しいアプリケーション・ドメインを作成して)、次の説明に従って、リソースおよびポリシーを追加します。
