21 Access Managerでのシングル・サインオンの理解
ここでは、次のトピックについて説明します。
ノート:
特に明記しないかぎり、この章の情報は、すべてのエージェント・タイプとAccess Manager資格証明コレクタに共通です。
「Access Managerの集中ログアウトの概要」を参照してください。
21.1 Access Managerシングル・サインオンのコンポーネント
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エージェントの登録および管理」を参照)。 関連項目: 「リソースの保護およびSSOの有効化ポリシーの管理」。 |
|
ポリシー強制エージェント |
OAMエージェント(Webゲートまたはアクセス・クライアント)
関連項目: 「エージェントおよび登録の概要」。 |
|
資格証明コレクタおよび通信チャネル |
関連項目: 表22-4 |
|
SSOエンジン |
セッションのライフサイクルを管理し、有効なセッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。 関連項目: 「Access Managerセッションの維持」および「OAM Webゲートが関与するセッションの集中ログアウトの構成」 |
|
レガシー・システムをサポートするプロキシ |
|
|
アクセス・ポリシー |
登録済エージェントは、Access Manager認証、認可およびトークン発行ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。 ノート: 明示的にアクセスを許可するポリシーでリソースが保護されない場合、Access Managerのデフォルトの動作ではアクセスが拒否されます。 |
|
ポリシー・ストア |
本番環境ではデータベースです(それ以外の場合は、oam-config.xml)。 関連項目: 「データ・ソースの管理」 |
|
暗号化キーおよびキー・ストレージ |
登録されたOAM Webゲートごとに1つのキーが生成および使用されます。 関連項目: 表-1。 |
|
Cookie |
関連項目: 「SSO Cookieの理解」。 |
シングル・サインオンは、表21-2に示すように実装できます。この表には、追加情報の参照先が含まれています。
表21-2 SSOの実装の概要
| SSOのタイプ | 説明 |
|---|---|
|
単一のネットワーク・ドメインのSSO |
単一のネットワーク・ドメイン(たとえば、example.com)内のリソースに対して、Access Managerのシングル・サインオンを設定できます。これには、単一のネットワーク・ドメイン内にある複数のWebLogic管理ドメインに属するリソースの保護が含まれます。 単一のネットワーク・ドメインのSSOについては、このドキュメントで説明します。 |
|
複数のネットワーク・ドメインのSSO |
Access Manager 12cは、ネットワーク間ドメインでの設定不要なシングル・サインオンをサポートします。 関連項目: 「複数のネットワーク・ドメインのSSO」。 |
|
アプリケーションのSSO |
アプリケーションのシングル・サインオンを使用すると、Access Managerによって認証されたユーザーは、アプリケーションにアクセスする際に再認証は必要ありません。 |
|
複数のWebLogicサーバー・ドメインSSO |
WebLogic Serverインスタンスの基本管理単位をドメインと呼びます。様々なシステム管理者の責任、アプリケーションの境界、またはWebLogicサーバーの地理的な場所に基づいて、複数のWebLogic管理ドメインを定義することができます。ただし、クラスタ内のすべての管理対象サーバーが同じWebLogic Serverドメインに存在する必要があります。 |
|
リバース・プロキシのSSO |
このSSO実装タイプは、わずかな構成の変更でサポートされます。 関連項目: 「リバース・プロキシのSSO」 |
|
混在リリース・エージェントを使用したSSO |
Access Managerは、登録された12c OAMエージェント(Webゲートおよびプログラム・アクセス・クライアント)をシームレスにサポートします。 |
21.1.1 複数のネットワーク・ドメインのSSO
Access Managerでは、これは標準機能です。OAM Webゲートが排他的に使用される場合、システム内のすべてのCookieはホスト・ベースです。ただし、すべてのドメインを管理する必要があります。一部のドメインが外部のエンティティ(Access Managerのデプロイメントの一部ではないもの)により制御される場合、Identity Federationを使用することをお薦めします。
Access Managerは、ネットワーク間ドメインでの設定不要シングル・サインオンをサポートします。Access Managerのシングル・サインオフ時には、次の処理が実行されます。
-
OAMサーバーが設定するSSO Cookieは、ネットワーク・ドメイン全体で機能するホストCookieです。Webゲートは、そのスタンドアロン・エージェントCookieをクリアした後、セッションをクリアするためにOAMサーバーにリダイレクトします。
関連項目:
21.1.2 アプリケーションのSSOとAccess Manager
ユーザーの資格証明を送信する次の2つの方法があります。
-
Cookieの使用: ユーザーの識別にアプリケーションで抽出する必要があるブラウザのCookieに特定の値が設定されます。
-
ヘッダー変数の使用: エージェントのリクエストで設定され、アプリケーションで参照できるHTTPヘッダー。
ノート:
どちらの形式でも、管理者はポリシー内の適切なレスポンスを入力する必要があります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。
ヘッダー・レスポンス値は、OAMエージェントによってリクエストに挿入され、Access Manager 12cに登録されているエージェントによって保護されているWebサーバーにのみ適用できます。ポリシーに、Access Managerによって保護されていないWebサーバーでホストされているリダイレクトURLが含まれる場合、ヘッダー・レスポンスは適用されません。
たとえば、ユーザーを認証する場合、ポータル索引ページにリダイレクトすることがあります。
http://example.com/authnsuccess.htm
認証に失敗すると、認証アクションによってユーザーがエラー・ページまたは自己登録スクリプトにリダイレクトされる場合があります。
http://example.com/authnfail.htm
21.1.3 複数のWebLogicサーバー・ドメインSSO
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つ以上のシステム・リソースに同じ名前を付けることはできません。
21.2 Access Managerポリシー・モデル
Access Managerは、Oracle Access Managerのポリシー・モデルを抽出して単一のAccess Managerポリシー・モデルを構成します。
図21-1に、Access Manager 12cポリシー・モデルの主な要素(共有ポリシー・コンポーネント、個別のアプリケーション・ドメイン、外部依存関係など)を示します。
共有ポリシー・コンポーネント
共有ポリシー・コンポーネントはグローバルであり、1つ以上のアプリケーション・ドメインで使用できます。図21-2に、Access Managerポリシーの共有コンポーネントを示します。
表21-3に、Access Managerポリシーのグローバルな共有コンポーネントの説明を示します。
表21-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のデフォルトの動作として、アクセスが拒否されます。表21-4に、アクセスを許可するように構成できるポリシー・コンポーネントの説明と、詳細の参照先を示します。
表21-4 Access Managerのポリシー・コンポーネント
| コンポーネント | 説明 |
|---|---|
|
アプリケーション・ドメイン |
各アプリケーション・ドメインは、各リソースと、それらのリソースにアクセス可能なユーザーを示すために関連付けられたポリシーを格納する論理コンテナを提供します。アプリケーション・ドメインは、エージェントの登録時に自動的に作成されるようにすることも、コンソールを使用して手動で作成することもできます。 |
|
リソース定義 |
定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。 関連項目: 「ポリシー・リソース定義の追加および管理」。 |
|
認証ポリシー |
1つの認証ポリシーでのみ、アプリケーション・ドメインで定義された各リソースを保護できます。各認証ポリシーには、1つの認証スキームが必要です。 1つの認証ポリシーにより、多くのリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。 関連項目: 「特定のリソースに対する認証ポリシーの定義」 |
|
認可ポリシー |
1つの認可ポリシーでのみ、アプリケーション・ドメインに割り当てられる各リソースを保護できます。ポリシーには、それぞれ1つ以上の条件およびルールを含めることができます。認可ポリシーには、成功レスポンスも含めることができます。 1つの認可ポリシーで複数のリソースを保護できます。ただし、1つの認可ポリシーでのみ、各リソースを保護できます。 関連項目: 「特定のリソースの認可ポリシーの定義」。 |
|
トークン発行ポリシー |
生成されるアプリケーション・ドメインでは、「トークン発行ポリシー」のコンテナのみがデフォルトで提供されます。条件やルールは自動的に生成されません。これらは手動で追加する必要があります。 関連項目: 「トークン発行ポリシーのページ」。 |
|
ポリシー・レスポンス |
すべてのポリシー・タイプに使用できます。認証および認可の成功レスポンスをそれぞれのポリシー内で定義して、ポリシー評価後に適用できます。 関連項目: 「SSOのポリシー・レスポンスの概要」。 |
|
ルール |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシーには、保護対象のリソースへのアクセスを許可または拒否するかどうかを定義したルールが含まれています。 ルールは、次で説明されている認可条件を参照します。 関連項目: 「認可ポリシー・ルールおよび条件の概要」。 |
|
Condition |
認可ポリシーとトークン発行ポリシーのみで利用可能です。 各認可ポリシー・ルールは、ルールの適用対象、時間の条件が存在するかどうか、および評価結果の適用方法を定義する条件を参照します。 条件は、ルールの外部で宣言され、ルール内から参照されます。 関連項目: 「認可ポリシー・ルールおよび条件の概要」。 |
21.3 アプリケーション・ドメインおよびポリシーの詳細分析
各アプリケーション・ドメイン内では、アクセスを制御する特定のポリシーによって、特定のリソースが保護対象として識別されます。認証ポリシーおよび認可ポリシーには、成功と評価された場合に適用されるレスポンスが含まれます。このレスポンスは、管理者が構成します。認可ポリシーには、評価の実行方法を定義する条件とルールおよび成功と評価された場合に適用されるレスポンスが含まれます。これらの条件とルールおよびレスポンスは、管理者が構成します。
アプリケーション・ドメインのサイズと数は、管理者が決定します。それを決定するために、必要に応じて、個々のアプリケーション・リソースまたは他の論理グループを使用できます。アプリケーション・ドメインは、エージェント登録時に自動的に作成されます。また、管理者はアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを追加すると、同じエージェントを使用して複数のアプリケーション・ドメインを保護できます。
図21-3に、アプリケーション・ドメイン内のポリシーの詳細およびアプリケーション・ドメインでの共有要素の使用方法を示します。
詳細は、以下のトピックを参照してください。
21.3.1 ポリシーのリソース定義
リソースという用語は、OAMサーバーに格納されていて、多くのユーザーがアクセスできるドキュメント、エンティティまたは一部のコンテンツを表します。
クライアントは、特定のプロトコル(HTTPやHTTPSなど)を使用してOAMサーバーと通信し、既存のリソース・タイプに該当するリソースをリクエストします。各HTTPリソース・タイプをホスト識別子に関連付ける必要があります。ただし、HTTP以外のリソース・タイプは、(ホスト識別子ではなく)特定の名前に関連付けられます。
Access Managerでは、各リソースを特定のポリシーと関連付けるために、アプリケーション・ドメインのリソース・コンテナ内でリソースとして定義する必要があります。
ノート:
アプリケーション・ドメイン内のポリシーに関連付けできるリソースは、リソース・コンテナで定義されているリソースのみです。
詳細は、「ポリシー・リソース定義の追加および管理」を参照してください。
ノート:
ページの内容の一部を保護するには、Oracle Entitlements Serverの使用をお薦めします。
21.3.2 認証ポリシーについて
管理者は、認証ポリシーを作成して、アプリケーション・ドメイン内の特定のリソースに適用できます。
各認証ポリシーで指定する内容は次のとおりです。
-
このポリシーが適用される特定のリソースを指定します。このリソースは、このポリシーの「リソース」タブで、アプリケーション・ドメインのリソース・コンテナに定義する必要があります。
-
ユーザーの認証に使用するチャレンジ・メソッドを提供する認証スキームを指定します。
-
このポリシーの評価結果に基づいてユーザーをリダイレクトする成功URL (および失敗URL)を指定します。
-
エージェントが実行する認証後アクションを指定するオプション・レスポンスを定義します。
ポリシー・レスポンスには、情報をセッションに挿入して後で抽出する機能があります。これにより、特定の順序でURLにリダイレクトすることでアプリケーションへの(アプリケーション間の)データの経路を提供していたOracle Access Manager 12cよりも堅牢性と柔軟性が強化されます。
ポリシー・レスポンスはオプションです。これらは、管理者が構成する必要があり、アプリケーション・ドメイン内で定義されている特定のリソースに適用する必要があります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。
認証ポリシーの評価結果
Access Managerはユーザーを認証するために、このポリシーの認証スキームによって定義されているチャレンジ・メソッドに基づいて、認証資格証明のリクエストをユーザーのブラウザに示します。
ポリシーの評価後に、結果が返され、ユーザーはその結果に基づいてリダイレクトされます。
-
成功(アクセスを許可)の場合、リクエストしたURLにリダイレクトされます。
-
失敗(アクセスを拒否)の場合、汎用エラー・ページにリダイレクトされます。
ノート:
ポリシーの評価結果は、ポリシーごとにオーバーライドされます。
21.3.3 認可ポリシーについて
認可は、ユーザーにリクエストしたリソースのアクセス権があるかどうかを決定するプロセスです。
たとえば、ユーザーは、データを表示したり、ポリシーで保護されているアプリケーション・プログラムを実行したりできます。
管理者は、認可ポリシーを作成して、サブジェクトまたはアイデンティティが特定のリソースにアクセスできる条件を指定できます。リクエストしたリソースは、アプリケーション・ドメインに属している必要があり、特定の認可ポリシー内に含まれている必要があります。
各認可ポリシーで指定する内容は次のとおりです。
-
このポリシーが適用される特定のリソースを指定します。このリソースは、このポリシーの「リソース」タブで、アプリケーション・ドメインのリソース・コンテナに定義する必要があります。
-
このポリシーの評価結果に基づいてユーザーをリダイレクトする成功URL (および失敗URL)を指定します。
-
このポリシーおよびリソースに定義されている条件に基づいて、特定の許可ルールまたは拒否ルールを指定します。条件タイプの概要は、表21-5を参照してください。
-
認可後にエージェントが実行するアクションを特定する、オプションのレスポンスを定義します(「SSOのポリシー・レスポンスの概要」を参照してください)。
関連項目:
21.4 ポリシーの条件およびルール
条件は、認可ポリシー内およびトークン発行ポリシー内でのみ指定できます。ルールは、ポリシーの全体的な結果を決定する許可指定または拒否指定を定義します。
特に明記しないかぎり、ポリシーの条件およびルールに関する情報は、認可ポリシーおよびトークン発行ポリシーに同様に適用されます。
条件
条件は、定義されている条件に基づいてアクセスの許可または拒否を指定するルールと連携させて使用します。表21-5に、使用可能な条件タイプを示します。
表21-5 条件タイプ
| タイプ | 詳細は、以下を参照 |
|---|---|
|
アイデンティティ |
|
|
IP4範囲 |
|
|
一時的 |
|
|
属性 |
|
|
True |
実質的には"すべて許可"。これを、認証された任意の使用を認める必要がある場合のデフォルト・オプションとして使用することをお薦めします。この場合、認可時に特定の条件が満たされる必要はありません。 これは、Access Managerの前のリリースの「暗黙的な制約の使用」フラグにかわるものです。「暗黙的な制約の使用」フラグも同様に、制約が特に定義されていない場合に、ポリシーの評価を、結果を許可として完了させます。 |
認可ポリシーおよびトークン発行ポリシーはそれぞれ、1つ以上の条件オブジェクトを含めることができます。ポリシーの条件タイプ1つにつき複数のインスタンスが存在可能です(以前のポリシー・モデルではクラス1つにつき1つのインスタンスのみ存在可能でした)。
条件は、Access Manager 12cの以前の認可制約に似ています。ただし、制約では許可または拒否を指定できますが、条件では指定できません。
ルール
ルールはポリシー・モデルの新しい構造です。各ルールは、ポリシーの全体的な結果を決定する許可指定または拒否指定を定義します。ルールは、さらに、各条件の評価結果を組み合せる方法を定義します。条件はルールで参照され、ルールの外部で宣言されます。
ルール内で、評価結果を次のように組み合せることができます。
-
簡易モード: すべての条件が満たされる場合またはいずれか1つの条件が満たされる場合のどちらかの場合に評価としてtrueを返すことができるコンバイナの値に基づいて組み合された条件名のリストを受け入れます。(以前は、ALLは制約を許可し、ANYは制約を拒否していました。)
-
式モード: ユーザーは、条件名と特殊文字(カンマ「,」、縦線「|」、アンパサンド「&」および感嘆符「!」)を使用して条件を組み合せたブール式を指定できます。
ノート:
許可ルールまたは拒否ルールのどちらにも属さない条件が複数存在するポリシーは、有効なポリシーとして処理されます。
条件およびルールの詳細は、「リソースの保護およびSSOの有効化ポリシーの管理」を参照してください。
21.5 SSO Cookieの理解
SSO Cookieは、ユーザー・ログイン中に設定またはクリアされます。
次の各項で、SSO Cookieの詳細を説明します。
21.5.1 ユーザー・ログイン時のシングル・サインオンCookie
ユーザー・ログイン中に、シングル・サインオンを設定またはクリアできます。
表21-6に、Cookieの詳細をまとめます。
表21-6 SSO Cookie
| ユーザー・ログインで設定されるSSO Cookie | 設定元 | 説明 |
|---|---|---|
|
OAM_ID Cookie |
OAMサーバーの埋込み資格証明コレクタ |
ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。 関連項目: 「OAM_ID Cookie」。 |
|
OAMAuthnCookie |
OAM Webゲート |
アクセスする各OAM Webゲートによって設定されます。OAM WebゲートおよびOAMサーバーで認識されるキーで保護されます。有効なOAMAuthnCookieがセッションに必要です。 ノート: 異なるOAM Webゲートで保護されるアプリケーションにユーザーがアクセスする場合、複数のOAMAuthnCookieを使用します。 「OAM WebゲートのOAMAuthnCookie」を参照してください。 |
|
OAM_REQ |
OAMサーバーの埋込み資格証明コレクタ |
認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定またはクリアされる一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。 ノート: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。 「OAM_REQ Cookie」を参照してください。 |
|
OAMRequestContext |
OAM Webgate |
OAM Webゲートによって設定またはクリアされ、OAM WebゲートおよびOAMサーバーで認識されるキーで保護されます。 Internet Explorerブラウザの場合: --RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextは一時的なCookieになります。 --RequestContextCookieExpTimeが設定されている場合、OAMRequestContext Cookieは、 IE以外のすべてのブラウザでは、RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextはデフォルトの5分間か、 関連項目: 「OAMRequestContext」 |
|
DCCCtxCookie |
外部資格証明コレクタ |
外部資格証明コレクタ(DCC)の場合は、埋込み資格証明コレクタ(ECC)で作成されるOAM_REQと同様になります。 「DCCCtxCookie」を参照してください |
認証および認可ポリシーの構成の詳細は、「リソースの保護およびSSOの有効化ポリシーの管理」を参照してください。
21.5.2 シングル・サインオン・サーバーおよびエージェントCookie
次の各項では、SSOサーバーおよびエージェントのCookieについて説明します。
21.5.2.1 OAM_ID Cookie
OAM_ID Cookieは、OAMサーバーが適用範囲になります。OAM_IDは、ユーザーが資格証明のチャレンジを受けたときにOAMサーバーによって生成され、サーバーへのリダイレクトごとにそのサーバーに送信されます。OAM_IDは、OAMサーバーのみが認識するキーで保護されます。
ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラがCookieの有無を確認します。
-
Cookieが存在しない場合、ユーザー認証が開始されます。認証に成功した後、ユーザー・コンテキストおよびトークンがSSOエンジンによって設定されます。Cookieは、グローバル・ユーザーID (GUID)、作成時間およびアイドル・タイムアウトの詳細で設定されます。Cookieの情報はSSOサーバー・キーで暗号化され、SSOエンジンでのみ復号化できます。
-
Cookieが存在する場合、Cookieが復号化され、サインインのフローが認証されたユーザーで終了します。
21.5.2.2 OAM WebゲートのOAMAuthnCookie
認証の成功後にOAMサーバーから受け取った認証トークンを使用して各OAM Webゲートで設定された1つのOAMAuthnCookie_<host:port>_<random number>があります。有効なOAMAuthnCookieがセッションに必要です。
SSL接続: 管理者は、SSLを構成してエージェントおよびサーバーの簡易または証明書モードを指定し、SSL接続でのみObSSOCookieの送信を可能にしてCookieが安全でないWebサーバーに送信されることを防止します。詳細は、「OAMサーバーとWebゲート間の通信について」を参照してください。
Cookieの有効期間: OAM WebゲートおよびOAMAuthnCookieでは、有効なトークン(またはCookie)時間を制御するtokenValidityPeriodパラメータで有効期間が管理されます。
このキーは、OAM WebゲートおよびSSOエンジンで識別され、OAMAuthnCookieの暗号化に使用されます。SSOエンジン・キー(SSOエンジンでのみ識別)は、OAM_ID OAMサーバーCookieの暗号化に使用されます。
21.5.2.3 OAM_REQ Cookie
認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定またはクリアされる一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。
資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。
高可用性構成では、インフラストラクチャ・セキュリティ・カスタムWLSTコマンドを使用してリクエスト・キャッシュ・タイプをBASICからCOOKIEに変更する必要があります。
ノート:
Oracle共通ホームからWLSTスクリプトを起動する必要があります。『Oracle Fusion Middlewareの管理のコマンドライン・インタフェースの起動方法に関する項を参照してください。
21.5.2.4 OAMRequestContext
OAMRequestContextは、12cリソースのWebゲートによって設定またはクリアされ、12c WebゲートとOAMサーバーそれぞれで認識されるキーで保護されます。
資格証明が収集され、認証が実行される一方で、このCookieは、保護されたリソースへのユーザーの元のリクエストの状態を格納するように構成されます。
-
Internet Explorerブラウザの場合:
-
RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextは一時的なCookieになります。
-
RequestContextCookieExpTimeが設定されている場合、OAMRequestContext Cookieは、
Expiresディレクティブを使用して設定されている時間で有効期限が切れます。これには、クライアント・ホストとWebサーバー・ホスト間の時間同期が必要です。
-
-
IE以外のすべてのブラウザでは、RequestContextCookieExpTimeが設定されていない場合、OAMRequestContextはデフォルトの5分間か、
Max-Ageディレクティブを使用して設定されている時間で有効期限が切れます。
関連項目:
表15-2のRequestContextCookieExpTime
21.5.2.5 DCCCtxCookie
DCCCtxCookieは、外部資格証明コレクタ(DCC)にのみ作用します。DCCCtxCookieは、認証時に必要な各種のコンテキスト情報を保存するために、DCCで使用されます。
これに含まれる情報は、認証が完了した時点で元のリクエストを再作成するため、サーバー・アフィニティを保持するため、および反復複数ステップの認証を実行するために必要です。
デフォルトでは、DCCCtxCookieは、認証スキームに基づいて資格証明を収集するために、DCCが最初にリダイレクトされたときに設定されます(フォームによる認証スキームでは、ブラウザが最初にログイン・フォームにリダイレクトされたとき)。
DCCの場合、認証後にOAMサーバーが、認証レスポンスでDCCに向けてDCCセッション・トークンを発行します。その後で、DCCはこのトークンを使用してホストベースのDCC Cookieを設定し、次の処理を実行します。
-
認証時にDCC Cookieが提示された場合: DCCは、DCCキーを使用してトークンを復号し、部分的なトークンの検証をローカルに実行します(整合性チェック、トークンの有効期間チェック)。この検証をパスすると、DCCはOAMサーバーに対するOAPチャネルで、タイムアウトについての完全なトークンの検証を実行します。
-
DCC Cookieが存在しない場合: これは、最初の認証であることを示すため、資格証明コレクションが開始し、資格証明のサニティ・チェックと構文チェックを実行してから、その資格証明を検証するためにOAMサーバーに送信します。
21.5.2.6 DCCCtxCookie_COUNT
DCCCtxCookie_COUNT Cookieは、DCCCtxCookieの分割後に生成されるCookieの数を保持します。DCCCtxCookie_COUNT Cookieによって数が決まる一方、構成パラメータMaxSplittedCookieSizeによって各DCCCtxCookie Cookieのサイズが決まります。デフォルトでは、サイズは4KBに設定されます。
この機能により、Webゲートでは大規模なDCCCtxCookie Cookieを処理できるようになります。DCCCtxCookieのサイズが4 KBを超える場合、ブラウザによってはサポートされず、ユーザー認証が失敗することがあります。DCCCtxCookie Cookieを各サイズが4 KB以下の複数のCookieに分割するには、Webゲートの構成パラメータMaxSplittedCookieSizeに適切な値を設定します。DCCCtxCookie Cookieの分割後に生成されるCookieの数は、DCCCtxCookie_COUNT Cookieによって追跡されます。
たとえば、リクエストされたURLが長すぎる場合、DCCCtxCookie Cookieのサイズは6 KBになります。デフォルト設定では、DCCCtxCookieは次のように2つのCookieに分割されます。
DCCCtxCookie_HOST:PORT_1 (サイズ: 4 KB)
DCCCtxCookie_HOST:PORT_2 (サイズ: 2 KB)
長いURLの処理中に'不正なリクエスト'エラーが発生する可能性があります。このエラーを回避するには、httpd.confファイルを編集し、LimitRequestFieldSizeパラメータを追加します。LimitRequestFieldSizeのデフォルト値は8 KBです。
21.5.3 OAM CookieでのSameSite=None属性のサポート
OAMは、WebGateおよびOAMサーバーによって設定されたすべてのCookieにSameSite=None属性を追加します。
OAM CookieでのSameSite=None属性のサポート
OAMは、WebGateおよびOAMサーバーによって設定されたすべてのCookieにSameSite=None属性を追加します。
ノート:
- また、この機能を使用するには、最新のWebGateパッチをダウンロードしてアップグレードする必要もあります。詳細は、https://support.oracle.comにあるノート
Support for SameSite Attribute in Webgate (Doc ID 2687940.1)を参照してください。 - また、https://support.oracle.comにあるノート
Oracle Access Manager (OAM): Impact Of SameSite Attribute Semantics (Doc ID 2634852.1)も参照してください。
OAMサーバーのオプション構成
- SSL/TLSがロード・バランサ(LBR)で終了し、OAMサーバーがSSL/TLSモードで実行されていない場合、setDomainEnv.shで次のシステム・プロパティを設定します:
-Doam.samesite.flag.value=None;secureまたは、LBRまたはWeb層からOAMサーバーへSSL/TLSコンテキストを伝播できます。詳細は、https://support.oracle.comにある
ドキュメントID 1569732.1を参照してください。 - OAMサーバーが
SameSite=Noneを含めるのを無効にするには、setDomainEnv.shで次のシステム・プロパティを設定します:-Doam.samesite.flag.enable=false - 非SSL/TLS HTTP接続に
SameSite=Noneを設定するには、setDomainEnv.shで次のシステム・プロパティを設定します:-Doam.samesite.flag.enableNoneWithoutSecure=true
- すべての管理サーバーおよび管理対象サーバーを停止します。
$OAM_DOMAIN_HOME/bin/setDomainEnv.shを編集し、次のようにプロパティを追加します:EXTRA_JAVA_PROPERTIES="-Doam.samesite.flag.enable=false ${EXTRA_JAVA_PROPERTIES}" export EXTRA_JAVA_PROPERTIES- 管理サーバーおよび管理対象サーバーを開始します。
WebGateのオプション構成
- SSL/TLSがLBRで終了し、OAM Webgate WebServerがSSL/TLSモードで実行されていない場合、WebGateでリクエストがSSL/TLSとして処理されるように、「ユーザー定義パラメータ」構成でProxySSLHeaderVarを設定します。詳細は、ユーザー定義のWebGateパラメータに関する項を参照してください。
- OAM WebGateが
SameSite=Noneを含めるのを無効にするには、コンソールの「ユーザー定義パラメータ」構成でSameSite=disabledを設定します。これはエージェントごとの構成です。 - 非SSL HTTP接続に
SameSite=Noneを設定するには、コンソールの「ユーザー定義パラメータ」構成でEnableSameSiteNoneWithoutSecure=trueを設定します。これはエージェントごとの構成です。
ノート:
SSL/TLSコンポーネントと非SSL/TLSコンポーネントの混在を使用するデプロイメント: 非SSL/TLSアクセスの場合、OAMサーバーおよびWebgateはCookieにSameSite=Noneを設定しません。一部のブラウザ(Google Chromeなど)では、非セキュア(非SSL/TLSアクセス) CookieのSameSite=None設定が許可されないため、不一致が検出された場合にCookieが設定されないことがあります。
そのため、このようなSSL/TLSと非SSL/TLSが混在したデプロイメントはSSL/TLSのみのデプロイメントに移行して、全体的なセキュリティを強化することをお薦めします。