| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド 11g リリース1 (11.1.1) B62265-02 |
|
前 |
次 |
ログインは、ユーザーの認証および目的のアプリケーションへのアクセスを取得するアクションです。シングル・サインオン(SSO)はOracle Access Managerによって有効化されるので、追加または別のログインで同じユーザー・セッションの実行中に他のアプリケーションにアクセスする必要がなくなります。
この章では、ポリシーおよびそれらに必要なコンポーネントを開発する前の基盤を構築するOracle Access Manager 11gシングル・サインオンの概要を示します。この章の内容は次のとおりです。
|
注意: 特に指定のないかぎり、この章の情報は、OAMエージェントおよびOSSOエージェントで同じです。シングル・ログアウトの詳細は、第15章「OAM 11gの集中管理ログアウトの構成」を参照してください。 |
少なくとも2つの登録されたエージェントを含む完全に機能するOracle Access Manager 11gシステムが必要です。
この項では、この章のタスクのナレッジ・ベースの要件を示します。
エージェント登録フォームの詳細は、第9章「コンソールを使用したパートナ(エージェントおよびアプリケーション)の登録」を参照してください。
Oracle Access Manager 11gは、Oracle Access ManagerおよびOSSO 10gのポリシー・モデルを簡易性、柔軟性および今後の成長経路を提供する単一のモデルに抽出します。
表11-1は、OAM 11gポリシー・モデルと他のモデルを比較しています。
表11-1 OAM 11gポリシー・モデルとOAM 10gの比較
| ポリシーの要素 | OAM 11gポリシー・モデル | OAM 10gポリシー・モデル |
|---|---|---|
|
ポリシー・オーサリング |
Oracle Access Managerコンソール |
OAMポリシー・マネージャ |
|
ポリシー・ストア |
データベース |
LDAPディレクトリ・サーバー |
|
ドメイン |
アプリケーション・ドメイン |
ポリシー・ドメイン |
|
リソース |
|
|
|
ホスト識別子 |
|
|
|
ポリシー |
|
|
|
レスポンス |
|
|
|
認証スキーム |
認証スキームはグローバルに定義され、認証ポリシー内で参照できます。 信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。 注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表12-3「認証スキームの定義」を参照してください。 |
認証スキームをポリシーの外部で定義し、認証ポリシー内で参照できます。 |
|
Cookie |
||
|
問合せ文字列ベースのHTTPリソース定義 |
アクセス・ポリシーでサポートされています。 |
ポリシー・モデルは、アクセス・ポリシー内の問合せ文字列ベースのHTTPリソース定義をサポートします。 ベース・リソースURLの場合と同様に、実行時にOAMプロキシは、URLエンコーディングの後に問合せ文字列をポリシー・レイヤーに渡します。HTTP GETリクエストの一部である問合せ文字列のみが渡されます。問合せ文字列のパターンはHTTP POSTデータに適用されません。 関連項目: 表13-1「リソース定義の要素」 |
この項では、Oracle Access Manager 11gポリシー・モデルおよびそのグローバル共有コンポーネントを説明します。
Oracle Access Manager 11gポリシー・モデルは、OAMアプリケーション・ドメインのコンテキスト内で認証および認可サービスをサポートします。ポリシー・モデルは、全体のシステム構成の一部である外部ユーザー・アイデンティティ・ストアおよび認証モジュールに基づいています。
|
注意: 以前のリリースのOracle Access Managerでは、OAMポリシー・ドメインのコンテキスト内で認証および認可サービスを提供していました。OracleAS SSO 10gは認証のみ提供します。 |
図11-1は、Oracle Access Manager 11gのポリシー・モデル内の様々な要素を示しています。
図11-1 Oracle Access Manager 11gポリシー・モデルおよび共有コンポーネント
アプリケーション・ドメインおよびポリシー
Oracle Access Manager 11gポリシー・モデルの最上位レベルの構造は、OAMアプリケーション・ドメインです。各アプリケーション・ドメインは、リソースおよびアクセス可能なユーザーを指示する関連付けられた認証および認可ポリシーの論理コンテナを提供します。
アプリケーション・ドメインのサイズおよび数は、管理者が個々のアプリケーション・リソースまたは必要に応じてその他の論理グループに基づいて決定できます。アプリケーション・ドメインは、エージェント登録時に自動的に作成されます。また、管理者はアプリケーション・ドメインを手動で作成し、リソースおよびポリシーを追加することにより、同じエージェントを使用して複数のアプリケーション・ドメインを保護できます。詳細は、次の項目を参照してください。
共有ポリシー・コンポーネント
1つ以上のアプリケーション・ドメインで使用できるグローバル・ポリシー・コンポーネント。次の各項目で詳細情報を提供します。
リソース・タイプは、保護されるリソースの種類を示します。
単一のリソース・タイプを使用して、各リソースを定義します。ただし、リソース・タイプを使用して任意の数のリソースを定義できます。
保護するリソースをアプリケーション・ドメインに追加する前に、*their*リソース・タイプを定義する必要があります。管理者は通常デフォルトのリソース・タイプHTTPを使用しますが、HTTP以外のタイプを定義できます。
リソース・タイプおよび管理の詳細は、「リソース・タイプの管理」を参照してください。
ホストに複数の名前を指定できます。OAMでリソースのURLを識別できるように、OAMはリソースのホスト・コンピュータを参照する様々な方法を認識する必要があります。
表11-2は、従業員がアクセスできるWebサーバーの異なるホスト名を示しています。これらの名前すべてを使用して単一のホスト識別子を作成すると、ユーザーのアクセス方法に関係なくアプリケーションを適切に保護する1つのポリシー・セットを定義できます。
表11-2 ホスト識別子の例
| ホスト識別子 | 説明 |
|---|---|
|
hrportal.intranet.company.com |
従業員が覚えやすい名前。これはロード・バランシングされたプロキシで、このリクエストによってHRアプリケーションをホストするいくつかのサーバーのいずれかを実際に利用できます。 |
|
hr-sf-02.intranet.company.com |
直接アクセスできるアプリケーションをホストする単一のマシン。 |
|
hrportal.company.com |
以前の従業員の福利厚生や企業年金情報などの確認に主に使用するため、同じアプリケーションで企業ファイアウォールの外部にもアクセスできます。また、これはロード・バランシングされたリバース・プロキシです。 |
OAMを使用すると、すべての使用可能なバリエーションが一緒に格納されます。管理者は、ホストの正規の名前およびユーザーがホストを表現できる他のすべての名前を入力します。リストのアドレスに送信されるリクエストは、公式のホスト名にマップされます。
ホスト識別子はエージェントの登録中に自動的に作成され、新しいアプリケーション・ドメインのリソース定義とデフォルトの認証および認可ポリシーをシードするために使用されます。また、管理者は1つ以上のアプリケーション・ドメインで使用されるホスト識別子の定義を作成できます。
アプリケーション・ドメインの認証および認可ポリシーは、ホスト識別子に基づいてリソースを保護します。ホスト識別子を使用して実行時にリソースまたはアプリケーションを識別し、設計時にアプリケーション・リソースのポリシーを作成できます。
詳細は、「ホスト識別子について」を参照してください。
|
関連項目: エージェントおよびアプリケーションの登録の詳細は、次の章を参照してください。 |
認証は、ユーザーを証明するプロセスです。Oracle Access Managerを使用したユーザーのアイデンティティの認証は、事前定義セットのプロセスを実行したユーザーのデジタル・アイデンティティの確認を示します。
1つの認証スキームにのみ、各認証ポリシーを割り当てることができます。ただし、1つの認証スキームを複数の認証ポリシーに割り当てることができます。
1つの認証ポリシーにより、多くのリソースを保護できます。ただし、1つの認証ポリシーでのみ、各リソースを保護できます。
次の項を参照してください。
OAMを使用すると、認証スキームという単一の認証プロセスでリソースまたはリソースのグループを保護できます。認証スキームは、事前定義済の認証モジュールに基づいています。
認証スキーム: ユーザーの認証に必要なチャレンジ・メカニズム、信頼レベルおよび基礎となる認証モジュールを定義する名前の付いたコンポーネント。このスキームに関する一般的な情報も含まれています。認証スキームはグローバルに定義されるため、少人数のセキュリティ管理者が一貫性のあるセキュアな方法で定義できます。Oracle Access Manager 11gには、いくつかの認証スキームがデフォルトで提供されています。
認証モジュール: 認証スキームの実行可能な最小の単位。いくつかの事前定義モジュールが用意されています。各モジュールには、標準プラグインが含まれます。認証モジュールは、準拠する正確な手順および資格証明にユーザーを要求する方法を決定します。これらのモジュールの詳細は、「認証モジュールの管理」を参照してください。
詳細は、「認証スキームの管理」を参照してください。
マルチレベル認証: Oracle Access Manager 11gを使用すると、管理者は異なる認証レベルを別の認証スキームに割り当てて、任意のアプリケーションを保護するスキームを選択できます。機密性の高いアプリケーションにユーザー証明書、機密性の低いアプリケーションにユーザー名およびパスワードが必要になる場合があります。たとえば、レベル2として定義されたBasic Over LDAP認証スキームがあるリソースへのアクセス権を付与されているユーザーは、それ以下のレベルのスキームがある他のリソースにアクセスできます。これに対して、ユーザーがより厳格な認証チャレンジ(レベル5のクライアント証明書と呼ばれるスキームなど)のあるリソースにアクセスしようとする場合には、再認証を受けることが必要です。
Windows固有の認証: 統合されたWindows固有の認証がOSSOおよびWebgateで保護されたアプリケーションでサポートされます(『Oracle Fusion Middleware Oracle Access Manager統合ガイド』を参照してください)。
他の認証タイプ: 次のようなOracle Fusion Middlewareアプリケーションに必要な認証機能がサポートされます。
一般的にユーザー名およびパスワードを使用して証明書を使用しない弱い認証
サード・パーティのセルフサービス・ユーザー・プロビジョニングの自動ログイン
ユーザー・コンテキスト情報のHTTPヘッダー・サポート。たとえば、ホスト識別子を使用してリソースのホスト・コンテキストを作成します。これは、異なるコンピュータで同じURLパスを使用するリソースを追加する場合に役立ちます。
2つのWebGateの異なる認証スキームを使用する場合、ユーザーは再認証なしで高い認証スキームから低い認証スキームに移行できますが、低い認証スキームから高い認証スキームには移行できません。
|
注意: シングル・サインオンの実行中、ユーザーの認証テストに成功する場合がありますが、2番目または3番目のリソースにアクセスすると認可テストに失敗する場合があります。ドメインの各リソースに一意の認可ポリシーが存在する場合があります。 |
Oracle Access Manager11gを使用した認証スキームの構成および使用の詳細は、「認証スキームの管理」を参照してください。
管理イベント以外に、認証の成功および失敗イベントが監査されます。監査には、認証スキーム、モジュールおよびポリシーの作成、変更、表示および削除が含まれます。認証するユーザーに関して収集される情報は、次のとおりです。
IPアドレス
ユーザー・ログインID
アクセス時間
ロギング(または監査)中、ユーザー情報およびユーザー機密属性は記録されません。誤用を避けるためにセキュアなデータ(ユーザー・パスワードなど)が削除されます。
認証中にいくつかのモニタリングおよび診断メトリックが収集されます。詳細は、第25章「Oracle Access Managerコンソールを使用したパフォーマンスの監視」を参照してください。
明示的にアクセスを許可するポリシーでリソースが保護されない場合、OAM 11gのデフォルトの動作でアクセスが拒否されます。一方で、明示的にアクセスを指定したルールまたはポリシーでリソースが保護されなかった場合、OAM 10gのデフォルトの動作でアクセスが許可されていました。
Oracle Access Manager 11gポリシー・モデルを使用すると、特定のリソースのアクセスを認可される認証ユーザーと認可されないユーザーを区別するアプリケーション・ドメインを定義する場合にリソースにアクセスできるユーザーを制御できます。
ブラウザへのURLの入力、アプリケーションの実行、他の外部ビジネス・ロジックの呼出しなど、ユーザーがアプリケーション・ドメインで保護されるリソースにアクセス可能ないくつかの方法があります。ユーザーがアプリケーション・ドメインで保護されるリソースへのアクセスをリクエストすると、認証および認可のドメインのポリシーに応じてリクエストが評価されます。
アプリケーション・ドメインは、柔軟な方法でリソースおよびポリシーを論理的にグループ化します。各アプリケーション・ドメインを作成して、全体のアプリケーションのデプロイメント、特定の層のデプロイメントまたは単一のホストに関連するポリシー要素を含めることができます。アプリケーション・ドメインは、相互に階層の関係がありません。
アプリケーション・ドメイン内で、各リソースを制御するポリシーとともに特定のリソースが識別されます。認証および認可ポリシーには、成功した評価に適用される管理者が構成するレスポンスが含まれます。認可ポリシーには、評価の実行方法を定義する管理者が構成する制約が含まれます。
各アプリケーション・ドメインには、一意の名前を使用する必要があります(簡単な説明はオプションです)。管理者がリソースおよびポリシーを定義できるリソース・コンテナおよびポリシー・コンテナで各ドメインがシードされます。
リソースは、サーバーに格納されて多くのユーザーがアクセスできるドキュメント、エンティティまたは内容の一部を表します。クライアントは、特定のプロトコル(HTTPやHTTPSなど)を使用してサーバーと通信し、既存のリソース・タイプで定義されているリソースをリクエストします。
|
注意: ページの内容の一部を保護するには、Oracle Entitlements Serverの使用をお薦めします。 |
Oracle Access Managerを使用する場合、リソース定義がアプリケーション・ドメイン内に作成されます。各リソースがURLパスとして定義されます。各HTTPリソース・タイプをホスト識別子に関連付ける必要があります。ただし、HTTP以外のリソース・タイプ(HTTP以外のリソース)は、ホスト識別子ではなく特定の名前と関連付けられます。
|
注意: アプリケーション・ドメイン内で定義されたリソースのみ、アプリケーション・ドメインに定義されたポリシーに関連付けることができます。 |
詳細は、「ポリシーで使用するリソース定義の追加および管理」を参照してください。
認証は、ユーザーを証明するプロセスです。ユーザーを認証するため、Oracle Access Managerは、ユーザーのブラウザに認証資格証明のリクエストをチャレンジ形式で示します。チャレンジは、チャレンジ・メソッドと呼ばれます。
管理者は、アプリケーション・ドメイン内に1つ以上の認証ポリシーを作成して、特定のリソースをそのドメイン内に適用できます。
|
注意: エージェント・タイプに関係なく、認証がOAM 11g認証ポリシーによって行われます。 |
認証ポリシーの評価
認証ポリシーでは、指定されたリソースのアクセスを提供する必要があるユーザーの認証に使用される認証方式を指定します。ポリシーは、リソース・アクセスを保護する方法を定義します。
ポリシーが評価された後、次の2つの標準アクションが実行されます。
結果が戻されます。
リクエストしたURL(成功した場合の許可)または一般エラー・ページのURL(失敗した場合の拒否)のいずれかの結果に基づく内容がユーザーに示されます。
結果は、ポリシーごとに上書きできます。
SSOのポリシー・レスポンス
管理者が定義するポリシー・レスポンスは、前述の内容以外に実行されるオプションのアクションを宣言します。ポリシー・レスポンスには、情報をセッションに挿入して後で抽出する機能があります。これにより、特定の順序でURLにリダイレクトすることでアプリケーションのデータの経路を提供していたOAM 10gよりも堅牢で柔軟性が高くなります。詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。
|
注意: 管理者がポリシー・レスポンスを構成し、同じアプリケーション・ドメイン内で定義される特定のリソースに適用する必要があります。 |
詳細は、「アプリケーション・ドメインおよびポリシーの詳細分析」を参照してください。
認可は、ユーザーにリクエストしたリソースのアクセス権があるかどうかを決定するプロセスです。
管理者は、1つ以上の認可ポリシーを作成して、リソースにアクセスできるサブジェクトまたはアイデンティティの条件を指定できます。ユーザーは、データの表示やポリシーで保護されたアプリケーション・プログラムを実行できます。リクエストしたリソースがアプリケーション・ドメインに属し、リクエストしたリソースを特定の認可ポリシーでそのドメイン内で扱う必要があります。
|
注意: OracleAS SSO 10gでは認可を実行しません。OSSOエージェントはOAM 11g認可ポリシーを使用しません。 |
SSOの認可レスポンス
管理者が定義するポリシー・レスポンスは、前述の内容以外に実行されるオプションのアクションを宣言します。ポリシー・レスポンスには、情報をセッションに挿入して後で抽出する機能があります。これにより、特定の順序でURLにリダイレクトすることでアプリケーションのデータの経路を提供していたOAM 10gよりも堅牢で柔軟性が高くなります。
詳細は、「SSOのポリシー・レスポンスの概要」を参照してください。
認可制約
認可制約は、リソースのリクエストのコンテキストに基づいて特定のリソースのアクセスを付与または拒否するルールです。認可制約により、リクエストに対する認可の成功または失敗が決定されます。
管理者は、認可ポリシーに割り当てられるリソースに適用される制約を定義する必要があります。詳細は、「認可制約の概要」を参照してください。
認可ポリシーの評価
認可ポリシーの評価は、成功(許可)または失敗(拒否)の2つの結果のいずれかになります。ポリシー評価のデータが不十分な場合、常に結果が失敗になります。たとえば、アクセスを許可する前にユーザーがグループのメンバーであることを制約で確認しますが、グループがLDAPに実際に存在しない場合は失敗の結果になります。
詳細は、「特定のリソースの認可ポリシーの定義」を参照してください。
OAM 11g SSOの概要を説明するため、次のタスクの概要にOAM 11gを使用したシングル・サインオンの構成方法および特定のタスクに関連する追加情報の場所をまとめます。
タスクの概要: OAM 11gを使用したシングル・サインオンの構成
次の項を確認してください。
アプリケーションのドキュメントを使用して、各パートナ・アプリケーションのシングル・サインオン・ログアウトURLを構成します。
保護するアプリケーションをホストしている各WebサーバーのOAMポリシー施行エージェントをインストールします。
|
注意: OAM 11gでエージェントを登録すると、基本ポリシーでシードされるデフォルトのホスト識別子およびアプリケーション・ドメインが自動的に作成されます。 |
「リソース・タイプの管理」の手順に従って、使用できる目的のリソース・タイプを確認します(またはリソース・タイプを作成します)。
次の項の手順に従って、適切な認証モジュールおよびスキームを使用していることを確認します。
「ホスト識別子の管理」の手順に従って、エージェントに基づく名前が付けられたホスト識別子の定義が自動的に作成された(またはホスト識別子の定義を作成した)ことを確認します。
第13章「リソースを保護してSSOを有効化するポリシーの管理」の手順に従って、リソース定義を追加し、アプリケーション・ドメインのOAM 11gポリシーを構成します。
|
関連項目: 必要に応じて次のトピックを参照してください。 |
「SSOエンジン」を構成します(「SSOトークンとIPの検証の管理」を参照してください)。
「グローバル・サインオンおよび集中管理ログアウトの検証」の手順に従って、構成を検証します。
この項では、Oracle Access Manager 11gを使用するシングル・サインオンの簡単な概要を説明します。内容は次のとおりです。
この項では、シングル・サインオンのOracle Access Manager 11gポリシーを実装および施行する主要コンポーネントを説明します。
表11-3に、主要なシングル・サインオン・コンポーネントをまとめます。
表11-3 OAM 11g SSOおよびOSSO 10gコンポーネントの概要
| コンポーネントの説明 | OAM 11g | OSSO 10g |
|---|---|---|
|
サーバー 注意: 管理外ユーザーは、SSOログイン・ページを戻すパートナ・アプリケーションのURLを入力して、シングル・サインオン・サーバーに最初にアクセスします。関連項目: 「OAM 11g SSO処理の概要」 |
注意: 管理ユーザーは、https://host:port/oamconsoleのURLを入力して、コンソールのホームページにアクセスできます。関連項目: 「Oracle Access Managerコンソールのログインおよびサインアウト」 |
関連項目: 『Oracle Application Server Single Sign-On管理者ガイド』 |
|
プロキシ レガシー・システムのサポートを提供します。 |
|
|
|
ポリシー施行エージェント 依存するパーティとともに存在し、認証および認可タスクをOAMサーバーに委任します。 |
|
|
|
Oracle Identity Managementインフラストラクチャ |
エンタープライズ・アイデンティティのセキュアな集中管理を有効化します。 |
エンタープライズ・アイデンティティのセキュアな集中管理を有効化します。 |
|
ポリシー・ストア |
データベース |
mod_ossoおよびパートナ・アプリケーション |
|
パートナ・アプリケーション 注意: 外部アプリケーションは認証が委任されません。かわりに、アプリケーション・ユーザー名とパスワードを求めるHTMLログイン・フォームが表示されます。たとえば、Yahoo!Mailは、HTMLログイン・フォームを使用する外部アプリケーションです。 |
認証および認可をOAMに委任して登録されたエージェントからヘッダーを受け入れるアプリケーション。 |
認証をmod_ossoおよびOracleAS Single Sign-Onサーバーに委任するアプリケーション。 注意: OAM 11gでmod_ossoを登録した後、mod_ossoは認証をOAMに委任します。 mod_ossoモジュールを使用すると、ユーザーのログイン後に認証されたユーザー情報をパートナ・アプリケーションで受け入れることができます。登録されたOSSOエージェントからヘッダーを受け入れて、再認証を回避します。 パートナ・アプリケーションは、認証されたユーザーがアプリケーションの使用を認可されているかを判別します。 |
|
SSOエンジン ユーザー・セッションのライフ・サイクルを管理し、有効なユーザー・セッションのすべての依存するパーティのグローバル・ログアウトを容易にして、複数のプロトコルの一貫したサービスを提供します。 |
OAMエージェントを使用する場合
|
|
|
パートナ・キー |
|
|
|
サーバー・キー |
|
|
|
キーの格納 |
|
|
|
Cookie 関連項目: 「シングル・サインオンCookieについて」 |
ホストベースの認証Cookie
|
|
|
ポリシー |
OAMエージェントは、OAM 11g認証および認可ポリシーを使用して、保護されたアプリケーション(定義されたリソース)のアクセスを取得するユーザーを決定します。 |
mod_ossoは、OAM 11g認証ポリシーのみを使用して、定義されたリソースのアクセスを取得するユーザーを決定します。 mod_ossoは、認証のみを提供します。 |
|
クライアントIP |
|
|
表11-4は、ユーザー・ログインの実行中に設定または消去できるCookieを示しています。
表11-4 SSO Cookie
| ユーザー・ログインで設定されるSSO Cookie | 設定元 | 説明 |
|---|---|---|
|
OAM_ID Cookie |
OAM 11gサーバー |
OAMサーバーでのみ認識されるキーで保護されます。 ユーザーが保護されたアプリケーションにアクセスすると、リクエストがSSOエンジンに達して、コントローラが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は、OAM 11gと古いエージェント間の下位互換性および相互運用性を有効化します。 |
|
OAM_REQ |
OAM 11gサーバー |
認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookie。OAMサーバーでのみ認識されるキーで保護されます。 注意: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。 |
|
OAMRequestContext |
11g Webgate |
11g Webgateによって設定または消去される一時的なCookie。11g WebgateおよびOAMサーバーで認識されるキーで保護されます。 注意: 資格証明が収集され、認証が実行される一方で、このCookieは高可用性オプションとして構成され、保護されたリソースへのユーザーの元のリクエストの状態を格納します。 |
|
OHS-host-port |
Oracle HTTP Server |
Oracle HTTP Server(OHS)でOSSOエージェント(mod_osso)にアクセスする場合のみ設定されます。mod_ossoエージェントおよびOAMサーバーで認識されるキーで保護されます。「mod_osso Cookie」を参照してください。 注意: このCookieは、OAM 11gと古いエージェント間の下位互換性および相互運用性を有効化します。 |
|
GITO Cookie |
OAM 11gサーバー |
OSSO 10gおよびOAM 11gの間の下位互換性および相互運用性を提供します。このCookieはOAMサーバーによって作成され、OAMサーバーまたはmod_ossoエージェントによってアクセスまたは変更されます。 |
認証および認可ポリシーの構成の詳細は、第13章「リソースを保護してSSOを有効化するポリシーの管理」を参照してください。
認証の成功後に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の暗号化に使用されます。
次に説明するObSSOCookieと似ています。
Oracle 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コマンドの使用に関する項を参照してください。 |
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)がOAM 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管理者ガイド』を参照してください。
この項では、様々なシングル・サインオンの実装タイプの次の内容を説明します。
Oracle Access Managerにより、管理者は、ユーザーの資格証明が一度確認されてからユーザーが実行する各アプリケーションに提供される信頼網を構築できます。これらの資格証明を使用すると、固有のメカニズムによるユーザーの再認証をアプリケーションで実行する必要がありません。
アプリケーションのシングル・サインオンにより、Oracle Access Managerで認証されたユーザーは再認証を実行することなくアプリケーションにアクセスできます。
Cookieの使用: ユーザーの識別にアプリケーションで抽出する必要があるブラウザのCookieに特定の値が設定されます。
ヘッダー・レスポンス値は、OAMエージェントによってリクエストに挿入され、OAM 11gに登録されたエージェントで保護されるWebサーバーにのみ適用できます。OAMで保護されないWebサーバーでホストされているリダイレクトURLがポリシーに含まれる場合、ヘッダー・レスポンスは適用されません。
たとえば、ユーザーを認証する場合、ポータル索引ページにリダイレクトすることがあります。
http://mycompany.com/authnsuccess.htm
認証に失敗すると、認証アクションによってユーザーがエラー・ページまたは自己登録スクリプトにリダイレクトされる場合があります。
http://mycompany.com/authnfail.htm
この項では、OAM 11gを使用したシングル・サインオン処理を説明します。
Oracle Access Managerは、Oracle Identity Federation以前の独自の複数のネットワーク・ドメインSSO機能を提供します。これがOAM 10gデプロイメントで実装される場合、OAM 11gにOAM 10gエージェントを登録してこのサポートを継続できます。
混在リリース・エージェントを使用したSSO
Oracle Access Manager 11gにエージェントを登録した後、OAMサーバーは、OAM 10g、11gエージェントおよび10g OSSOエージェント(mod_osso)の任意の組合せのシームレスなサポートを提供します。
リバース・プロキシSSO
シングル・サインオン構成のリバース・プロキシを使用する場合、IPvalidationパラメータをfalseに設定するか、Webgate登録でプロキシIPアドレスをIPValidationExceptionsリストに追加してください。その他の場合は、リバース・プロキシによってクライアントのIPアドレスは隠されます。
認証に成功した後、リバース・プロキシが10g Webgate ObSSOCookieをOracle WebLogicに渡さない場合があります。この問題を回避するため、Oracle WebLogicでリバース・プロキシを使用するときは、Basic Over LDAPではなくフォーム・ベース認証を使用してください。11g Webgateでは、セキュリティを考慮してユーザー定義パラメータ(filterOAMAuthnCookie(デフォルトはtrue))を使用して、OAMAuthnCookieをダウンストリーム・アプリケーションに渡すことを防止できます。Cookieを渡す場合は、パラメータをfalseに設定します。
複数のWebLogicサーバー・ドメインSSO
OAM 11gは、複数の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 Managerコンソールを使用して管理およびモニタリング・タスクを実行すると、ドメインを切り替えることができますが、実行時に異なる管理サーバーに接続します。
複数のドメインを作成した場合、各ドメインは固有のデータベース・スキーマを参照する必要があります。ドメイン間で構成されたリソースまたはサブシステムを共有できません。たとえば、1つのドメインにJDBCデータ・ソースを作成する場合、別のドメインの管理対象サーバーまたはクラスタで使用できません。かわりに、2番目のドメインに類似するデータ・ソースを作成する必要があります。さらに、2つ以上のシステム・リソースに同じ名前を使用できません。
OAM 10gとは異なり、OAM 11gは、即時利用可能なネットワーク間ドメインのシングル・サインオンをサポートします。OAM 11gのシングル・サインオフの実行中、次の処理が実行されます。
11g OAMサーバーによって設定されるSSO Cookieは、ネットワーク・ドメイン間で動作するホストCookieです。Webgateは、スタンドアロン・エージェントCookieを消去し、セッションを消去するためにOAM 11gサーバーにリダイレクトします。
スタンドアロン・エージェントCookieを使用しないOAM 10g Webgateの場合、リダイレクトを必要としないサーバー側でのみログアウトが発生します。
スタンドアロン・エージェントCookieをサポートする11g WebgateおよびOSSOエージェントの場合、エージェント・ログアウト・コールバックURLがパラレルにコールされます。セッションでアクセスするエージェントおよび複数のドメインのエージェントは、ブラウザでサポートされる同時接続の数に応じてすべてパラレルにコールされます。
|
注意: 標準ベースのマルチプロトコルのネットワーク間ドメインのシングル・サインオンには、Oracle Identity Federationをお薦めします。 |
この項の内容は次のとおりです。
シングル・サインオンのログインおよびログアウト処理は、ユーザーが有効かどうかおよびユーザーの状態が有効または無効かを決定します(ユーザーまたはユーザー・セッションが最初に期限切れになる場合)。セッション管理サポートでは、ユーザー・セッション・コンテキストおよびユーザー・トークンを検索、保持および消去します。
次の各項目で詳細情報を提供します。
ユーザーが保護されたリソースに最初にアクセスする場合、リソースの認証スキームおよびレベルに基づいて資格証明が求められます(通常はユーザーIDおよびパスワードが必要です)。
誤ったユーザーIDまたはパスワードが入力されると、認証に失敗します。この場合、ユーザーは認証されずに、資格証明の別のプロンプトが表示されます。
認証に成功すると、認可ポリシーの確認が実行され、このユーザーに特定のリソースのアクセスが認可されていることを確認します。認可に成功すると、情報がアプリケーションに渡されます。セッションが期限切れになるか、高い認証レベルでリソースをリクエストするまで、ユーザーはサインインを再度求められません。
プロビジョニングは、Oracle Access Managerのセッションを作成しません。新しいユーザーがセルフサービス・プロビジョニング・アプリケーションを使用してアカウントを作成すると、アプリケーションにアクセスする場合にユーザーIDおよびパスワードを再度求められます。
保護されたアプリケーションがユーザーの資格証明をリクエストするOracle Access Manager 11gに向けられます。たとえば、Oracle Identity ManagerがOAM 11gで保護されている場合、ユーザー・リクエストが資格証明を入力するリクエストが実行されるOracle Access Managerにリダイレクトされます。
Oracle Platform Security Services(OPSS)は、Oracle WebLogic Serverの内部セキュリティ・フレームワークで構成されます。Oracle WebLogic Serverでは、Oracle Application Development Framework(Oracle ADF)セキュリティを使用し、Oracle Access Manager 11g SSOと統合して、ユーザー認証にOPSS SSOを使用するWebアプリケーションを実行できます。
詳細は、付録C「Oracle ADFアプリケーションとOracle Access Manager 11g SSOの統合」を参照してください。
Oracle Access Managerは、アイデンティティの確認に顧客が指定した認証方式で各ユーザーを認証し、ユーザー・アイデンティティ・ストアに格納された情報を利用します。Oracle Access Manager認証では、いくつかの認証方式および様々な認証レベルをサポートします。機密性の程度が異なるリソースは、より厳しい認証方式に対応する高いレベルの認証を要求することで保護できます。
ユーザーが保護されたアプリケーションにアクセスしようとすると、SSO Cookieの有無を確認するOAMがリクエストを受け取ります。
ユーザーを認証してユーザー・コンテキストおよびトークンを設定した後、OAMはSSO Cookieを設定して、SSOエンジンでのみ復号化できるSSOサーバー・キーでCookieを暗号化します。
認証の成功および失敗に応じて指定されるアクション(OAM 11gのレスポンス)によっては、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を通じてユーザー情報が他のアプリケーションに渡されたりする場合があります。
認可ポリシーおよび確認結果に基づいて、リクエストした内容へのユーザーのアクセスが許可または拒否されます。ユーザーのアクセスが拒否されると、Webgate登録で管理者が指定した別のURLにリダイレクトされます。
図11-2は、ポリシーの評価、ユーザーのアイデンティティの検証、保護されたリソースへのユーザーの認可および保護されたリソースの使用に含まれるプロセスを示しています。この例は、OAMエージェントのフロー(Webgate/アクセス・クライアント10gまたはWebgate 11g)を示しています。11g Webgateでは、少しのバリエーションがあります。
プロセスの概要: OAMエージェントを使用したSSOログイン処理
Webgateは、ポリシーを評価するためにリクエストをOAMに送信します。
OAM
SSO Cookieの有無を確認します。
ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。
OAMサーバーは、決定をログに記録して戻します。
Webgateは、次のように応答します。
保護されていないリソース: リソースがユーザーに提供されます。
保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。
認証ポリシーに基づくログイン・フォームが提供されます。
認証処理が開始されます。
ユーザーは資格証明を送信します。
OAMは資格証明を確認します。
OAMはセッションを開始し、次のホストベースCookieを作成します。
パートナごとに1つ: 認証に成功した後にOAMサーバーから受け取った認証トークンを使用して11g Webgateで設定されるOAMAuthnCookie(10g Webgateで設定されるObSSOCookie)。
注意: 有効なCookieがセッションに必要です。
OAMサーバーに1つ: OAM_ID
OAMは成功または失敗をログに記録します。
資格証明コレクタがWebgateにリダイレクトされ、認可処理が開始されます。
Webgateは、ポリシーの検索、ポリシーとユーザーのアイデンティティの比較および認可のユーザー・レベルの決定をOAMに求めます。
OAMはポリシーの決定をログに記録し、セッションCookieを確認します。
OAMサーバーは認可ポリシーを評価し、結果をキャッシュします。
OAMサーバーは、決定をログに記録して戻します。
Webgateは、次のように応答します。
認可ポリシーでアクセスを許可すると、目的の内容またはアプリケーションがユーザーに提供されます。
認可ポリシーでアクセスを拒否すると、管理者が決定した別のURLにユーザーがリダイレクトされます。
登録されたOSSOエージェント(mod_osso)を使用したSSOログイン処理は、Webgateを使用したログイン処理と似ています。ただし、mod_ossoは、OAM 11g認証ポリシーを使用した認証のみを提供します。
|
注意: mod_ossoは、固有の認可またはOAM 11gポリシーを使用した認可をサポートしません。 |
図11-3は、mod_ossoおよびOAM 11gを使用したログイン処理を示しています。
プロセスの概要: OSSOエージェントを使用したSSOログイン処理
mod_ossoは、ポリシーを評価するためにリクエストをOAMに送信します。
OAM
SSO Cookieの有無を確認します。
ポリシーを確認して、リソースが保護されているかどうかおよび保護されている場合はその方法を判別します。
OAMサーバーは、決定をログに記録して戻します。
mod_ossoは、次のように応答します。
保護されていないリソース: リソースがユーザーに提供されます。
保護されているリソース
リクエストが資格証明コレクタにリダイレクトされます。
認証ポリシーに基づくログイン・フォームが提供されます。
認証処理が開始されます。
ユーザーは資格証明を送信します。
OAMは資格証明を確認します。
OAMはセッションを開始し、認証トークンをアプリケーションに渡して、次のCookieを作成します。
パートナごとに1つ: OHS_host_port
OAMサーバーに1つ: OAM_ID
グローバル非アクティビティ・タイムアウト: ドメインレベルCookieのGITO
OAMは成功または失敗をログに記録します。
資格証明コレクタは、ユーザーの認可にアプリケーションCABで使用できる単純なヘッダー値を送信するmod_ossoにリダイレクトされます。
認証に成功すると、リソースが提供され、OHS-host-port Cookieが設定されます。
OAM 11gサーバーは、エージェントのタイプまたはリリースに関係なく類似したSSOランタイム処理を提供します。
