47 Fusion WebアプリケーションでのADFセキュリティの有効化

この章では、Fusion WebアプリケーションでADFセキュリティを有効化して、Oracle ADFリソースのリソース権限を定義し、それらのリソースに関連するWebページをユーザーが表示できるかどうかを制限する方法を説明します。

この章の内容は次のとおりです。

• ADFセキュリティについて

• ADFセキュリティ・プロセスの概要

• ADFセキュリティの有効化

• アプリケーション・ロールの作成

• ADFセキュリティ・ポリシーの定義

• テスト・ユーザーの作成

• ログイン・ページの作成

• JDeveloperにおけるセキュリティのテスト

• セキュア・アプリケーションのデプロイの準備

• ADFセキュリティの無効化

• 高度なトピックとベスト・プラクティス

ADFセキュリティについて

セキュリティは、エンタープライズ・アプリケーションの重要な部分です。ADFアプリケーションでのセキュリティの実装により、アプリケーションにアクセスできるユーザーや、それらのユーザーがログイン後に行える操作が決定されます。Fusion Webアプリケーションの様々なレイヤーでセキュリティを視覚的に有効化できます。

ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。ADFセキュリティはOracle Platform Security Services (OPSS)アーキテクチャの上に構築されます。このアーキテクチャはそれ自体がOracle WebLogic Serverと密接に統合されています。それ以外にも、ユーザー・ログインおよびリソースの保護を処理できるセキュリティ対応モデルはありますが、ADFバインド・タスク・フロー、ADFバインディングを使用するトップレベルのWebページ(バインド・タスク・フローに含まれないページ)、および最も低いレベルの粒度でADFエンティティ・オブジェクトとその属性によって定義されたデータ列に対して宣言型で許可ベースの保護を実現するのに、ADFセキュリティは非常に適しています。このドキュメントでは、ADFセキュリティ・フレームワークが保護するこれらの個々のリソースを、ADFセキュリティ対応リソースと呼びます。

「ADFセキュリティの有効化」の説明に従い、ADFセキュリティの構成ウィザードを実行して、Fusion WebアプリケーションのADFセキュリティを有効にします。このウィザードにより、Fusion Webアプリケーション全体のADFセキュリティを構成するため、ADFセキュリティ対応リソースに関連するWebページはデフォルトで保護されます。つまり、ADFセキュリティを有効化すると、アプリケーションがロックダウンされるので、そのページはデフォルトでセキュアであるとみなされます。

ADFセキュリティを有効にしたら、ユーザーにアクセス権を付与する必要があります。これによってユーザーは、Fusion WebアプリケーションのWebページを表示できるようになります。ユーザーに付与するアクセス権は、ページのADFセキュリティ対応リソース用に指定するセキュリティ・ポリシーとして知られています。タスク・フローの入力やWebページの表示を行うユーザー権限を制御するのは、最終的にはADFリソースにおけるセキュリティ・ポリシーになります。

ADF SecurityはJava Authentication and Authorization Service (JAAS)に基づいているので、セキュリティ・ポリシーによりプリンシパル(ユーザーまたはアプリケーション・ロール)、ADFリソースおよび権限(リソースのADF権限クラスで定義される操作)が識別されます。たとえば、ADFタスク・フローのSummitサンプル・アプリケーションでは、customer-task-flowのタスク・フローにより含まれるWebページを保護し、ログイン済ユーザー(認証済ユーザー)にのみアクセス権を付与します。実行時、ADFセキュリティ・フレームワークではタスク・フローのセキュリティ・ポリシーに対して認可チェックを実行して、ユーザーに表示操作を完了する権限があるかどうかを識別します。この場合、ユーザーがチェックアウト・プロセスを完了しようとする場合は、セキュリティ・ポリシーでは表示の権限をユーザーに付与する必要があります。

ユーザーとADFリソースに対してセキュリティ・ポリシーを定義するタスクを簡略化するために、ADFセキュリティではADFバインド・タスク・フローとそこに含まれるWebページに対して1つのセキュリティ・ポリシーを定義できる包含階層を定義します。つまり、バインド・タスク・フロー・レベルでセキュリティ・ポリシーを定義すると、フローのエントリ・ポイントが保護されます。次に、そのフロー内のすべてのページが、定義されたポリシーによって保護されます。また、個々のユーザーにアクセス権を付与するかわりに、ユーザーをアプリケーション・ロールにグループ化し、そのロールにview権限を付与します。

特に、Fusion Webアプリケーションで次のADFセキュリティ対応リソースのためのセキュリティ・ポリシーを定義して、ユーザーがWebページにアクセスできるようにします。

• ADFバインド・タスク・フローはタスク・フローのエントリ・ポイントを保護します。エントリ・ポイントが、そのフローに含まれるページへのユーザーのアクセスを制御します。

  たとえば、新規顧客に登録プロセスを説明する一連のWebページがあるとすると、バインド・タスク・フローによって、そのプロセスのページ・ナビゲーションが制御されます。バインド・タスク・フローの詳細は、「バインド・タスク・フローについて」を参照してください。

  ADFバインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、認可チェックは行われません。バインドなしタスク・フローの構成ページを保護する必要がある場合は、ページに関連するページ定義ファイルの権限を定義します。

• Webページに関連付けられているADFページ定義ファイルは、バインド・タスク・フローに含まれません

  たとえば、Webページに売上数上位の製品の要約が表示されることがありますが、これには、そのページに関連付けられたADFページ定義ファイルのADFバインディングによって調整されたデータが使用されます。ページ定義とADFバインディングの詳細は、「ページ定義ファイルの処理」を参照してください。

• ADFエンティティ・オブジェクトとエンティティ・オブジェクトの属性(データ行を参照し、ユーザー・インタフェースに表示するコレクションの定義に使用されます)

  たとえば、WebページにADF Facesの表コンポーネントが表示されることがあります。これには、ADFバインディングがエンティティ・オブジェクトの属性にデータ・ソースとしてマップする列が表示されます。エンティティ・オブジェクトの場合、ADFセキュリティを有効化してもエンティティ・オブジェクト行は自動的に保護されません。エンティティ・オブジェクトまたはその属性を明示的に保護するセキュリティ・ポリシーを定義しないかぎり、ユーザーが引続きデータにアクセスできます。エンティティ・オブジェクトの詳細は、「エンティティ・オブジェクトについて」を参照してください。

JDeveloperツールではセキュリティの反復開発がサポートされるため、ADFリソースに作成するセキュリティ・ポリシーの作成、テストおよび編集が容易になります。JDeveloperでのテスト・ユーザーの作成に進み、統合WebLogic Serverでアプリケーションを実行して、保護されたリソースにエンド・ユーザーがどのようにアクセスするかをシミュレートできます。この章では、ユーザー・アイデンティティとログイン資格証明のリポジトリ(アイデンティティ・ストアと呼ばれる)を構成する方法を説明します。

ノート:

この章で説明するアイデンティティ・ストアはすべて、統合WebLogic Serverでの実行を目的として作成するテスト・ユーザー・アイデンティティに関係しています。「セキュア・アプリケーションのデプロイの準備」で説明するように、Oracle WebLogic Serverにデプロイするとき、通常はこのようなユーザーをステージング環境に移行することはありません。

ADFセキュリティを有効化したが、テスト・ユーザーにアクセス権を付与するセキュリティ・ポリシーをまだ定義していないという状況を避けるため、「ADFセキュリティの構成」ウィザードでは、一時的なview権限を既存のすべてのADFリソースに付与できます(view権限が各ADFリソースのセキュリティ・ポリシーに追加されます)。ウィザードのこのオプションでは、自動付与を行わずに、各リソースの作成時にADFリソースのセキュリティ・ポリシーを定義する選択肢と、view権限を自動付与してから、セキュリティ・ポリシーを定義してその権限を1つずつ置き換える選択肢があります。セキュリティの反復開発の選択肢については、「ADFセキュリティ・プロセスの概要」で説明します。

ヒント:

ADFセキュリティを有効化し、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義する前に、ADF認可チェックの規則を理解する必要があります。この規則を理解すると、計画しているセキュリティの実装に役立ちます。これらの規則の詳細は、「ADFセキュリティのユースケースと例」を参照してください。

ADFセキュリティとJavaセキュリティの統合

Fusion Webアプリケーション・リソースを保護するADFセキュリティ・モデルは、Java EEセキュリティ・モデルで使用されているセキュリティ制約のURLマッピングに基づくものではありません。実際の処理でも、セキュリティ制約はJavaServer Faces (JSF) Webアプリケーションの保護には適していません。ページ・ナビゲーションが特定のページURLでサポートされないためです。たとえば、ユーザーがタスク・フローの次のページにナビゲートしても、そのフロー内ではURLは変化しません。新しいページが表示されるときに、URLベースのセキュリティ制約をトリガーする手段がありません。

かわりに、ADFセキュリティはJava Authentication and Authorization Service (JAAS)セキュリティ・モデルを実装しています。JAASは既存のJavaセキュリティ・モデル上に構築され、すべてのJAAS実装(JAASサービスのOracle Platform Security Services (OPSS)実装も含む)と統合されるため、JAASモデルはポリシー・ベースです。URLセキュリティ制約を利用するアプリケーションがセキュリティ非対応となるのは、セキュリティを管理するためにJava EEコンテナに依存するためです。これに対して、Fusion Webアプリケーションは、ユーザー定義ポリシーに基づいてリソースへのアクセスを認可するために、ADFセキュリティ・フレームワークへの明示的なコールを必要とします。つまり、ADFセキュリティを有効化して、ADFリソースのアクセス・ポリシーを定義したときに、アプリケーションがセキュリティ対応になります。

ADFセキュリティによりJAAS認可モデルの実装が簡略化されます。この実装では、ADFリソースに対するセキュリティ・ポリシーを宣言して公開し、それらのリソースに対する認可チェックを実行時に行うことで、セキュリティ対応アプリケーションの作成に必要な作業を最小限に抑えます。

JDeveloperのポリシー・ストアはファイルベースで、ADFリソースのセキュリティ・ポリシーを定義する権限と呼ばれるエントリのリストを含みます。権限エントリには、保護対象のリソースに操作(たとえば、ADFバインド・タスク・フローに関連付けられたWebページへのアクセス)を実行するためにユーザーに付与されるすべての権限が含まれます。権限はポリシー・ストアでアプリケーション・ロール・プリンシパルに対して付与されます。

ADFセキュリティによってJAASモデルが拡張されます。ADFセキュリティ・フレームワーク権限クラスで指定されるアクションを使用して権限を定義できるようになります。このようなクラスはADFリソースに固有であり、リソースでサポートされる操作にアクションをマッピングします。Fusion Webアプリケーションのポリシー・ストアに含まれる権限では、次の項目が指定されます。

• リソースの権限クラスによって定義されるアクションと、アプリケーションのADFリソース・インスタンスを関連付ける、1つ以上の権限(現在、バインド・タスク・フローとページ定義リソースでサポートされるのはviewアクションのみです)

• 権限の付与先として、アプリケーションによって定義されるアプリケーション・ロール(同じアクセス権を付与するメンバー・ユーザーまたはエンタープライズ・ロール(オプション)を移入します)

エンティティ・オブジェクトの場合、権限クラスはエンティティ・オブジェクトのread、removeCurrentRowおよびupdate操作に対応するread、deleteおよびupdateアクションを定義します。

ADF権限クラスとサポートされるアクションの詳細は、「ADFセキュリティ権限の付与」を参照してください。

ADFセキュリティのユースケースと例

ADFセキュリティを使用すると、Webアプリケーションを現実のビジネス・セキュリティ要件に適応させやすくなります。アプリケーション・リソースへのパスを保護するのではなく、JAASによってADFリソースに対する表示操作を保護するためです。JAASベースのADFセキュリティでは次の機能が提供されます。

• ADFリソース(バインド・タスク・フローなど)の宣言セキュリティのサポート

  Java EEセキュリティはURLベースまたはページベースであるため、カスタム・コードなしではナビゲーションを制御できません。ADFセキュリティでは、ユーザーがタスク・フローを開始できるかどうかを制御できます。つまり、タスク・フローに対する1つのセキュリティ・ポリシーによって、複数のWebページへのアクセスを制御できます。また、宣言セキュリティではアクセス・パスではなくADFリソースを保護できるため、アプリケーションの別の場所でADFリソースを再利用するときも、保護された状態が維持されます。

• 権限の継承を可能にするアプリケーション・ロールを使用した権限割当ての簡略化

  Java EEセキュリティ制約で使用されるJava EEセキュリティ・ロールが平面的であるのに対し、JAAS権限を付与するアプリケーション・ロールはネストすることができ、Oracle WebLogic Serverドメインが定義するエンタープライズ・ロールにマップすることもできます。

• セキュリティ・コンテキストで、ADFリソースにアクセスするためにEL式で使用するユーティリティ・メソッド

  ADFセキュリティのEL式ユーティリティ・メソッドを使用すると、ユーザーが既知の操作を実行できるかどうかを判定することができます。たとえば、ユーザーが特定のタスク・フローを表示できるかどうかを判定することができます。

また、JDeveloperを使用すると、統合WebLogic Serverでセキュリティをテストするためのテスト・ユーザーとパスワードをすぐに作成できます。Oracle WebLogic Serverにデプロイする準備ができたら、アプリケーション固有の認可ポリシーをサーバーに移行できます。管理者はアプリケーションがLDAPユーザー・リポジトリを使用するように構成できます。

表47-1に、ADFセキュリティの有効化がアプリケーションや様々なADFセキュリティ対応リソースに及ぼす影響をまとめています。ADFセキュリティを最も効果的に使用する方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

表47-1 ADFセキュリティ対応リソースのサマリー

ADFリソース	ADFによるセキュリティの施行方法	アクセス権の付与方法
すべてのユーザー・インタフェース・プロジェクトのバインド・タスク・フロー	デフォルトで保護されます。ユーザーがバインド・タスク・フローを開始するために権限が必要です。	タスク・フローの権限を定義します。 バインド・タスク・フローのWebページに関連付けられている個々のページ定義ファイルの権限は、定義しないでください。
すべてのユーザー・インタフェース・プロジェクトのページ定義ファイル	デフォルトで保護されます。ページ定義に関連付けられたページをユーザーが表示するために権限が必要です。	Webページがバインド・タスク・フローに含まれる場合は、このタスク・フローに対する権限を定義します。 Webページがバインド・タスク・フローに含まれない場合、またはWebページがバインドなしタスク・フローに含まれる場合は、ページ定義のみの権限を定義します。 バインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、権限を定義できないことに注意してください。
データ・モデル・プロジェクトのエンティティ・オブジェクト	デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。	データ・コレクション全体レベルでアクセスを制御する必要がある場合のみ、データを保護するためにエンティティ・オブジェクトの権限を定義します。保護対象のエンティティ・オブジェクトを参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 エンティティレベルのセキュリティは注意して使用してください。または、エンティティ属性レベルでのセキュリティの定義を検討します。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。
データ・モデル・プロジェクトのエンティティ・オブジェクトの属性	デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。	データ・コレクションの列レベルでアクセスを制御する必要がある場合は、データを保護するためにエンティティ・オブジェクト属性の権限を定義します。保護対象のエンティティ属性を参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。

ADFセキュリティの追加機能

ADFセキュリティの処理を開始する前に、その他のOracle ADF機能を理解しておくと役に立ちます。次に、関連する他の機能へのリンクを示します。

• Oracle Platform Security Servicesのセキュリティ機能の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「Oracle Platform Security Servicesの概要」を参照してください。

ADFセキュリティ・プロセスの概要

Oracle ADF Securityフレームワークは、いくつかのすぐに使用できる機能を提供して、開発者がより簡単にセキュアなADFアプリケーションをコーディングできるようにしています。ADFセキュリティ設定は、アプリケーション全体のjazn-data.xmlデータ・ファイルに格納されます。

Fusion WebアプリケーションのADFリソースを保護するときはJDeveloperを使用します。ADFセキュリティでは、アプリケーションのバインド・タスク・フロー、およびバインドなしタスク・フローに含まれるすべてのWebページが保護されます。この保護を有効にするには、「ADFセキュリティの構成」ウィザードを実行し、その後、ADFセキュリティ・ポリシーを定義して各リソースのユーザー・アクセス権を定義します。

アプリケーションのユーザー・インタフェースを作成するときは、「ADFセキュリティの構成」ウィザードをいつでも実行できます。選択肢は次のとおりです。

• UIプロジェクトのWebページの作成と、関連するADFリソースのセキュリティ・ポリシーの定義を繰り返しながら行います。

• UIプロジェクトのすべてのWebページの作成を完了してから、関連するADFリソースのセキュリティ・ポリシーを定義します。

ノート:

Fusion Webアプリケーションの保護に進む前に、「ADFセキュリティのユースケースと例」で説明されているADFセキュリティ・モデルについてよく理解する必要があります。

設計とテストの反復プロセスは、様々な設計時ツールでサポートされています。

新しいバインド・タスク・フローまたはADFページ定義ファイルをユーザー・インタフェース・プロジェクトで作成するたびに、新しいADFリソースがjazn-data.xmlファイルの概要エディタに表示されます。このエディタは、セキュリティ・ポリシーの概要エディタとも呼ばれます。概要エディタを使用し、アプリケーション全体に関してWebページに関連付けられたADFリソースのセキュリティ・ポリシーを定義します。また、概要エディタを使用してADFリソースをソートすると、セキュリティ・ポリシーがまだ定義されていないADFリソースを簡単に見つけることができます。

ADFアイデンティティ・ストアの少数のテスト・ユーザーをプロビジョニングするには、別のエディタを使用します。JDeveloperに作成するアイデンティティ・ストアを使用して、ユーザー資格証明(ユーザーIDとパスワード)を定義できます。エディタには、作成するユーザーと、ユーザーを割り当てるアプリケーション・ロールの関係も表示され、ADFセキュリティ・ポリシーで定義されるアクセス権を付与することができます。

JDeveloperは設計時に、ポリシー・ストアとアイデンティティ・ストアのすべての変更内容をアプリケーション全体で1つのファイルに保存します。開発環境では、これはjazn-data.xmlファイルです。エディタを使用してjazn-data.xmlファイルを構成すると、統合WebLogic Serverでアプリケーションを実行でき、ポリシー・ストアの内容がドメインレベルのストア(system-jazn-data.xmlファイル)に追加されます。また、テスト・ユーザーは、統合WebLogic Serverがアイデンティティ・ストアとして使用する埋込みLDAPサーバーに移行されます。ドメインレベルのストアを使用すると、作成したテスト・ユーザーとしてログオンしてセキュリティ実装をテストできます。

セキュリティに関するすべての設計時ツールは、図47-1に示すように、メイン・メニューの「アプリケーション」→「保護」メニューを使用してアクセスします。

図47-1 ADFセキュリティの設計時ツールの利用

「図47-1 ADFセキュリティの設計時ツールの利用」の説明

設計フェーズ

ADFセキュリティを有効化し、JDeveloperで実行するアプリケーションに対するポリシー・ストアを設定するには:

1. 「ADFセキュリティの構成」ウィザードを実行することにより、動的認証を許可し、認可を実施するためにADFセキュリティを有効化します。

   ウィザードの実行時に動的認証のみを有効にすることを選択した場合は、残りの設計フェーズのステップはスキップします。このウィザードを使用して、Oracle WebLogic Serverでセキュリティ・フレームワークとOPSSを統合するファイルを構成します。

2. ADFセキュリティ対応リソースを作成します。構成Webページ(またはリージョン)を含むバインド・タスク・フロー、またはADFバインディングを使用して設計される最上位Webページ(またはリージョン)などです。

   ノート: 「ADFセキュリティの構成」ウィザードを実行すると、ADFセキュリティ対応リソースに関連付けられるすべてのWebページが保護されます。つまり、アプリケーションを実行してセキュリティをテストする前に、Webページをアクセス可能にするためにセキュリティ・ポリシーを定義する必要があります。

3. ADFセキュリティ対応リソースと、作成した1つ以上のアプリケーション・ロールを関連付けます。

   作成するアプリケーション・ロールはアプリケーションに固有であり、これを使用すると、同じレベルのアクセス権を一連のユーザー(またはメンバー・ユーザー)に付与することができます。テスト・フェーズではユーザーをいくつか作成し、作成したアプリケーション・ロールのメンバーとして追加します。

4. ADFセキュリティ対応リソースおよび関連する各アプリケーション・ロールにview権限を付与します。

   こうすることでアプリケーション・ロールのメンバー・ユーザーにアクセス権が与えられます。権限がないとユーザーはADFセキュリティ対応リソースにアクセスできません。テスト・フェーズでは、いくつかのユーザーを作成してアプリケーション・ロールに追加します。

テスト・フェーズ

統合WebLogic Serverを使用してアイデンティティ・ストアをプロビジョニングし、セキュリティをテストするには:

1. ユーザーをいくつか作成します。また、必要に応じてエンタープライズ・ロールを作成します。

   定義したユーザーIDとパスワードを使用してアプリケーションにログインします。エンタープライズ・ロールは、ユーザーをグループ化して、そのグループにアプリケーション・ロールを関連付けるための論理ロールです。エンタープライズ・ロールはテストのためには必要ありません。詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。

2. 作成したユーザーおよびエンタープライズ・ロール(オプション)を1つ以上のアプリケーション・ロールに関連付けます。

   メンバー・ユーザー複数のアプリケーション・ロールのアクセス権を付与する必要がある場合は、1メンバー・ユーザーを複数のアプリケーション・ロールに含めることができます。

3. デフォルトのログイン・ページをカスタム・ログイン・ページで置き換えます(オプション)。

   「ADFセキュリティの構成」ウィザードで生成されるデフォルトのログイン・ページは、ADF Facesコンポーネントを利用できません。これは、ADFセキュリティ・ポリシーのテスト用としてのみ便宜的に提供されています。カスタム・ログイン・ページは、ADF Facesコンポーネントを使用するように設計できます。

4. JDeveloperでアプリケーションを実行し、任意のADFセキュリティ対応リソースにアクセスします。

   最初にADFセキュリティ対応リソースにアクセスしようとするとき、セキュリティ・フレームワークによってログインを求められます。

5. ログインし、予定どおりにページとそのリソースにアクセスできることを確認します。

   ログインすると、セキュリティ・フレームワークによって、リソースにアクセスするためのユーザーの権限がチェックされます。たとえば、予期していない401未認可ユーザーのエラーを受け取った場合は、「ADFセキュリティの操作のベスト・プラクティス」に従って権限を作成したことを確認します。

ステージングの準備

ステージング環境または本番環境でOracle WebLogic Serverにデプロイするためにセキュア・アプリケーションを準備するには:

1. すべてのADFセキュリティ対応リソースについてtest-allロールのすべての権限を削除し、定義した権限で置き換えます。

   ADFリソースはデフォルトで保護されるため、アプリケーションをテストする開発者にview権限が付与されるのは、セキュリティ・ポリシーが定義された後です。「ADFセキュリティの構成」ウィザードでは、test-allロールに対して、すべてのADFリソースへのアクセスを可能にする権限を生成するオプションがあります。企業のセキュリティを危険にさらさないために、test-allロールに対するすべての一時権限は、自ら定義した明示的な権限でいずれ置き換える必要があります。

2. 作成したすべてのユーザー・アイデンティティを削除します。

   JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、システム管理者が担当します。

3. ポリシー・ストアに表示されるアプリケーション・ロールが、最終的に管理者がドメインレベルのグループにマッピングするロールであることを確認します。

4. ADF Facesリソース・ファイルを保護するセキュリティ制約を定義するかどうかを決定します。

   リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルはADFセキュリティによって保護されませんが、アプリケーションにアクセスしようとするすべてのユーザーを認証する必要がある場合は、それらのファイルのJava EEアクセス・パスを保護できます。

5. 完成したポリシー・ストアと資格証明ストアをターゲット・サーバーに移行します。

   アプリケーションがOracle WebLogic環境のサーバーにデプロイされると、アプリケーションのポリシーと資格証明は自動的にドメイン・ポリシー・ストアに移行されます。これらのストアの自動的な移行は、ターゲット・サーバーの構成によって制御されます。JDeveloper外部でデプロイメントを実行するためにOracle Enterprise Managerを使用する場合、移行構成設定はこのツールで指定できます。jazn-data.xmlセキュリティ・ポリシーおよびcwallet.sso資格証明の移行の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。

ADFセキュリティの有効化

ADFセキュリティの構成ウィザードでは、認証と認可を個別に有効化できます。

ADFセキュリティをOPSSに統合するための構成プロセスを単純にするため、JDeveloperでは「ADFセキュリティの構成」ウィザードが用意されています。このウィザードは、ADFセキュリティを使用してFusion Webアプリケーションを保護する開始ポイントとなります。このウィザードはアプリケーションレベルのツールなので、実行すると、アプリケーションに含まれるすべてのユーザー・インタフェース・プロジェクトでADFセキュリティが有効になります。

ノート:

「ADFセキュリティの構成」ウィザードにより、アプリケーションのすべてのユーザー・インタフェース・プロジェクトに対してADFセキュリティが有効になります。このウィザードを実行した後で、バインド・タスク・フローに含まれる任意のWebページや、ADFページ定義に関連付けられたすべてのWebページを表示するための権限をユーザーに許可する必要があります。したがって、ウィザードを実行した後では、セキュリティ・ポリシーを定義してユーザーにview権限を付与するまで、アプリケーションは基本的にロックダウンされます。このプロセスの概要は、「ADFセキュリティ・プロセスの概要」を参照してください。

ADFセキュリティを有効化する方法

「ADFセキュリティの構成」ウィザードでは、認証と認可を個別に有効化することを選択できます。選択肢は次のとおりです。

• ユーザー認証のみを有効化します。

  ADFセキュリティでは認証にJava EEコンテナ管理のセキュリティを利用しますが、認証のみを有効化すると、ユーザーのログインとログアウトにはADF認証サーブレットを使用し、Webページの保護にはコンテナ管理のセキュリティ制約を定義することになります。

• ユーザー認証を有効化し、認可も有効化します。

  認可を有効化することは、ADFリソースに対してセキュリティ・ポリシーを作成することで、Fusion Webアプリケーションに対するアクセスの制御を意図することを意味します。

ADFセキュリティ・フレームワークではこれら2つの方法がサポートされるため、Java EEセキュリティを実装した上で、ADF認証サーブレットを使用したログインとログアウトに対応することができます。ADF認証サーブレットを有効化する利点は、ユーザーがアプリケーションに最初にアクセスするとき、サーブレットが自動的にユーザーにログインを求めることです。ADF認証サーブレットでも、認証が正常に終了すると、定義された開始ページにユーザーがリダイレクトされ、リクエストURLでターゲット・ページを渡す必要はありません。また、ユーザーがアプリケーションからログアウトする際にページ・リダイレクトを管理することもできます。ADFセキュリティで提供されるこのようなリダイレクト機能は、コンテナ管理セキュリティだけを使用する場合にはありません。

「実行時に行われる処理: ADFセキュリティによる認証の処理」で説明されているように、ADFセキュリティでは認証は実行されませんが、Java EEコンテナを利用して構成済のログイン・メカニズムが起動されます。

ベスト・プラクティス:

Java EEセキュリティ制約では、タスク・フローと連動してタスク・フローの現在のページを保護することはできません。このため、ADFタスク・フローを含むようにアプリケーションが設計されている場合、コンテナ管理セキュリティは効果的なソリューションではありません。ADFタスク・フローを使用する場合は、「ADFセキュリティの構成」ウィザードで「ADF認証および認可」オプションを選択します。このオプションを選択すると、セキュリティ・ポリシーを定義してアプリケーションのタスク・フローを保護できます。

ADFセキュリティはWebコンテナに認証を委任するため、「ADFセキュリティの構成」ウィザードを実行すると、ウィザードによってWebコンテナで使用する認証方式の構成を求められます。認証で最も一般的に使用されるタイプは、HTTP Basic認証とフォームベース認証です。Basic認証では、ユーザーがユーザー名とパスワードを入力できるようにブラウザのログイン・ダイアログが使用されます。Basic認証の場合、ユーザーからの資格証明がブラウザによりキャッシュされるため、ログアウトできないことに注意してください。Basic認証は、カスタム・ログイン・ページを作成しないでアプリケーションをテストする場合に便利です。フォーム認証では、アプリケーションの開発者がカスタムのログインUIを指定することができます。フォームベース認証を選択すると、ウィザードを使用して単純なログイン・ページを生成することもできます。デフォルトのログイン・ページは、統合WebLogic Serverでアプリケーションをテストするときに役立ちます。

ノート:

生成されるログイン・ページは単純なJSPファイルまたはHTMLファイルであるため、ADF Facesコンポーネントを使用して変更することはできません。ADF Facesコンポーネントを使用するカスタム・ログイン・ページでデフォルトのログイン・ページを置き換える方法の詳細は、「ログイン・ページの作成」を参照してください。

始める前に:

「ADFセキュリティの構成」ウィザードの知識があると役立ちます。詳細は、「ADFセキュリティの有効化」を参照してください。

アプリケーションに対してADFセキュリティを有効化するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。
2. 「ADFセキュリティ」ページではデフォルトで「ADF認証および認可」オプションが選択されています。「次へ」をクリックします。

   デフォルト・オプションが選択された状態でウィザードを実行すると、アプリケーションはADFセキュリティ対応リソースの認可を施行します。ADFリソースの認可の施行とは、アプリケーションのWebページにアクセスできるようにするために、それらのリソースに対するセキュリティ・ポリシーを定義することを意味します。定義を行うまでは、ADFバインド・タスク・フローに依存するすべてのページとADFページ定義は保護された状態になります。

   ADFセキュリティを構成するためのウィザードの他の2つのオプションは、ADFセキュリティを有効化する場合は使用しないでください。これらのオプションを使用すると、一時的にADFセキュリティを無効化して、「ADFセキュリティの無効化」で説明するようにセキュリティ保護なしでアプリケーションを実行できます。

   具体的には図47-2に示すように、ウィザードの最初のページには3つのオプションがあり、デフォルトのオプションとして「ADF認証および認可」が有効になっています。

   • 「ADF認証および認可」(デフォルト)では、ADF認証サーブレットが有効化され、ユーザーがログインおよびログアウトする際に構成済のWebページにリダイレクトできます。このオプションを使用すると、ADF認可を有効化して、ADFリソースについて定義したセキュリティ・ポリシーに対する認可チェックを施行することもできます。このオプションを選択した場合は、アプリケーション・ロールを定義し、明示的な権限をそのロールに割り当てて、ADFセキュリティ対応リソースへのアクセスを管理します。

   • 「ADF認証」を選択すると、アプリケーションのページが最初にアクセスされたときに、ADF認証サーブレットがユーザーのログインを要求します。また、Java EEアプリケーション・ルート「/」をJava EEセキュリティ制約(ユーザー認証をトリガーする)にマップすることで、ページ・リダイレクトがサポートされます。ウィザードによりADF認可が無効になるため、ADFリソースに対するセキュリティ・ポリシーが存在するかどうかに関係なく、認可チェックは実行されません。一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。

   • 「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効化され、ADF Securityはポリシー権限を確認できなくなりますが、既存のポリシー・ストアは変更されません。この場合、標準的なJava EEセキュリティを使用して、ユーザーに対して、ログインし、認証を受け、URLセキュリティ制約に対してアクセス権をテストすることことを求めることができます。ウィザードをこのオプションで実行すると、ADFリソースに対するきめ細かいセキュリティが無効になることに注意してください。

   図47-2 セキュリティ対応リソースを有効化するための「ADFセキュリティの構成」ウィザードの使用

   
   「図47-2 セキュリティ対応リソースを有効化するためのADFセキュリティの構成ウィザードの使用」の説明
3. 「認証タイプ」ページで、ユーザーがログイン情報を送信したときにアプリケーションで使用する認証タイプを選択します。「次へ」をクリックします。

   ADF認証サーブレットがBasic認証で作動せず、ログアウトしたユーザーがリソースにアクセスできるという問題が明らかになっています。Basic認証のかわりにフォームベース認証を使用してください。この問題の詳細は、「Fusion Webアプリケーション・ログアウトおよびブラウザ・キャッシュに関する必知事項」を参照してください。

   「フォームベース認証」を選択した場合は、「デフォルト・ページの生成」を選択して、ウィザードでデフォルトのログイン・ページおよびエラー・ページを生成できます。デフォルトでは、図47-3に示すように、ウィザードによって、ユーザー・インタフェース・プロジェクトのトップ・レベルに、ログイン・ページとエラー・ページが生成されます。場所を変更する場合は、ユーザー・インタフェース・プロジェクトを基準としたフルパスを指定します。

   図47-3 単純なログイン・ページを生成するための「ADFセキュリティの構成」ウィザードの使用

   
   「図47-3 単純なログイン・ページを生成するためのADFセキュリティの構成ウィザードの使用」の説明
4. 「自動ポリシー付与」ページでは、デフォルトで選択されている「自動付与なし」オプションをそのままにしておきます。「次へ」をクリックします。

   「自動付与なし」を選択すると、アプリケーション固有の明示的な権限を定義する必要があります。test-allアプリケーション・ロールを使用すると、ADF認可により施行される制限アクセスなしで、アプリケーション・リソースを実行してテストできるので便利です。ただし、このようにすると、アプリケーションの一部のリソースが保護されない状態になるリスクが高まります。

   または、ウィザードを使用してtest-allアプリケーション・ロールに権限を付与できます。test-allロールへの権限付与を有効化すると、アプリケーションのアクセス・ポリシーを調整する用意ができるまで、ADFリソースに対する明示的な権限の定義を延期することができます。自動付与の有効化を決めた場合は、test-allロールの権限をアプリケーションの明示的な権限で置き換えるまで、アプリケーション開発をあまり進めずに、アプリケーションの内容が確定してしまわないようにしてください。明示的な権限により、ユーザーがこれらのリソースにアクセスするために必要な権限(たとえばページのview)が確立されます。test-allロールの詳細は、「組込みtest-allアプリケーション・ロールを使用する方法」を参照してください。

5. 「認証されたようこそページ」で、ログイン後にユーザーを特定のWebページに移動させる場合またはセッション・タイムアウトによりセッションが失われた後にデフォルトの宛先ページを定義する場合に「認証の成功時にリダイレクト」を選択します。「次へ」をクリックします。

   「認証の成功時にリダイレクト」オプションを未選択のままにし、アプリケーションでAuthenticationService APIを使用して明示的にログイン・リダイレクトを処理しない場合、ユーザーはデフォルトでログインを開始したページに戻されます。ただし、ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して新しいブラウザ・ウィンドウまたはタブを開くと、ようこそページの定義がアプリケーションのweb.xmlファイルにない場合は、403エラーまたは404エラーを受け取ります。このオプションを使用して、ようこそページを指定すると、その定義がアプリケーションのweb.xmlファイルに追加されます。

   指定するWebページにADF Facesコンポーネントが含まれる場合、/faces/のコンテキストでページを定義する必要があることに注意してください。たとえば、adffaces_welcome.jspxのパスは、「ようこそページ」フィールドに、/faces/adffaces_welcome.jspxと表示されます。

   他のリダイレクト・オプションの指定の詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。

6. サマリー・ページで選択内容を確認し、「終了」をクリックします。

ADFセキュリティを有効にしたときの処理

「ADFセキュリティ」ページでデフォルトの「ADF認証および認可」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、次のようになります。

• ADF認証が有効化されます。ユーザーにログインを求め、ページ・リダイレクトを行います。

• ADF認可チェックが有効化され、認可ユーザーのみがADFリソースにアクセスできます。

ウィザードによりセキュリティ関連の構成ファイルがすべて更新され、デフォルトでADFリソースがセキュリティ保護されます。表47-2に、ADFセキュリティの設定ウィザードにより更新されるファイルを示します。

表47-2 ADF認証および認可で更新されるファイル

ファイル	ファイルの場所	ウィザードの構成
web.xml	ユーザー・インタフェース・プロジェクトに相対する/public_html/WEB-INFディレクトリ JDeveloperでは、ユーザー・インタフェース・プロジェクト内の「Webコンテンツ」→WEB-INFノードの下	Oracle JpsFilterフィルタを定義して、OPSSポリシー・プロバイダを設定します。フィルタで定義される設定により、サーブレットが特殊な権限を持つことが示されます。JpsFilterをweb.xmlファイルの最初のフィルタ定義にすることが重要です。 Oracle adfAuthenticationサーブレット定義を追加します。これは、ユーザーがADFリソースに最初にアクセスするときにログインを求めます。ADFセキュリティ自体は認証を実行しませんが、Java EEコンテナ管理のセキュリティをこの目的で利用します。 ウィザードで「ADF認証および認可」オプションを選択すると、web.xmlによって、ユーザー認証を動的にトリガーするセキュリティ制約にadfAuthenticationサーブレットがマッピングされます。 ウィザードで「ADF認証」オプションを選択すると、web.xmlによって、ユーザー認証を動的にトリガーするallPagesセキュリティ制約に、Java EEアプリケーション・ルート「/」がマッピングされます。 ユーザー・ログインを処理するためのログイン構成の認証方式を設定します。 ウィザードで「認証の成功時にリダイレクト」オプションを選択すると、web.xmlによってsuccess_urlサーブレット初期化属性(init-param要素)が定義され、これにより、ログインが成功した場合に使用するリダイレクト宛先がホワイトリスト登録され、1. AuthenticationService APIを使用してログイン・リダイレクトを処理しないアプリケーションのための1つの固定されたフォールバックと、2.　セッション・タイムアウトによりセッションが失われた場合のデフォルトの宛先ページが指定されます。 valid-usersロールなど、動的認証を有効化するセキュリティ制約をトリガーするために使用される必須セキュリティ・ロールを定義します。
adf-config.xml	Webアプリケーション・ワークスペースに相対する/.adf/META-INFディレクトリ JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→ADF META-INFノードの下	JAASセキュリティ・コンテキストを定義します。 認可チェックのためにADFセキュリティ・ポリシーを使用できるようにします(<JaasSecurityContext>要素のauthorizationEnforceパラメータがtrueに設定されます)。 Java SEアプリケーションでログイン・ダイアログのトリガーを有効にします(<JaasSecurityContext>要素のauthenticationRequireパラメータをtrueに設定します)。このパラメータは、Fusion Webアプリケーションでは使用されません。Fusion Webアプリケーションでは、認証を有効にする際にweb.xmlファイルの設定が使用されます。
jps-config.xml	Webアプリケーション・ワークスペースに相対する/src/META-INFディレクトリ JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノードの下	OPSSセキュリティ・サービスは、特にJDeveloperの設計時に有効にします。 Oracle ADFモデル・テスターを使用してデータ・モデル・プロジェクトをテストする場合、またはセキュリティ検証のユニット・テストを実行する場合は、ワークスペース固有のこのファイルが存在している必要があります。このファイルは、デプロイ済のFusion Webアプリケーションでは使用されません。たとえば、統合WebLogic Serverにデプロイする場合は、DefaultDomain/config/fmwconfig/jps-config.xmlファイルによってOPSSセキュリティ・サービスが有効化されます。
weblogic.xml	Webアプリケーション・ワークスペースに相対する/public_html/WEB-INFディレクトリ JDeveloperでは、ユーザー・インタフェース・プロジェクト内の「Webコンテンツ」→WEB-INFノードの下	valid-usersセキュリティ・ロールをusersという暗黙のグループにマッピングします。Oracle WebLogic Serverにより、すべての認証済ユーザーがusersグループのメンバーとして構成されます。
jazn-data.xml	Webアプリケーション・ワークスペースに相対する/src/META-INFディレクトリ JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノードの下	統合WebLogic Serverで使用するために構成するXMLアイデンティティ・ストアのデフォルトのjazn.comレルム名を設定します。 このファイルは、ADFセキュリティ対応のアプリケーションのユーザー・アイデンティティ、ユーザー・グループおよびセキュリティ・ポリシーを格納するために使用します。このファイルはデプロイ時に使用され、Oracle ADFモデル・テスターの実行時にセキュリティのサポートを有効にします。ただし、統合WebLogic Serverなどにアプリケーションをデプロイする場合、DefaultDomain/config/fmwconfig/system-jazn-data.xmlファイルで構成されているポリシー・ストアにセキュリティ・ポリシーが移行されます。

認証はWebコンテナに委任されるため、ウィザードはweb.xmlファイルのみを更新し、ADF認証サーブレットが動的に認証をトリガーできるようにします。次の例に示すように、ADF認証サーブレットのサーブレット・マッピングが定義され、2つのJava EEセキュリティ制約allPagesおよびadfAuthenticationがweb.xmlファイルに追加されます。

<servlet>
   <servlet-name>adfAuthentication</servlet-name>
   <servlet-class>
        oracle.adf.share.security.authentication.AuthenticationServlet
   </servlet-class>
   <init-param>
      <param-name>success_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>end_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>disable_url_param</param-name>
      <param-value>true</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
...
<servlet-mapping>
   <servlet-name>adfAuthentication</servlet-name>
   <url-pattern>/adfAuthentication</url-pattern>
</servlet-mapping>
...
<security-constraint>
   <web-resource-collection>
        <web-resource-name>allPages</web-resource-name>
        <url-pattern>/</url-pattern>
   </web-resource-collection>
   <auth-constraint>
        <role-name>valid-users</role-name>
   </auth-constraint>
</security-constraint>
<security-constraint>
   <web-resource-collection>
        <web-resource-name>adfAuthentication</web-resource-name>
        <url-pattern>/adfAuthentication</url-pattern>
   </web-resource-collection>
   <auth-constraint>
        <role-name>valid-users</role-name>
   </auth-constraint>
</security-constraint>

例で示されているinit-param要素によって定義されるサーブレット初期化属性は、ログインおよびログアウトが成功した場合のリダイレクトを制御します(それぞれsuccess_urlおよびend_url)。これらのinit-param要素により、ログイン時およびログアウト時のリダイレクト・ターゲットがアプリケーションによって指定されない場合のデフォルトまたはフォールバック宛先が指定されます。この場合、未検証のリダイレクトの発生を防ぐ固定宛先ホワイトリストがADF認証サーブレットに定義されます。サーブレット初期化属性disable_url_paramを必要に応じてweb.xmlのサーブレットのinit-paramリストに追加して、success_urlおよびend_urlがブラウザURLで渡されないようにすることで、ブラウザURL上のこれらのパラメータを利用する悪意のあるリダイレクト攻撃をある程度防止できます。このリダイレクト保護は、特にアプリケーションがAuthenticationService APIを使用してログインおよびログアウト・リダイレクトをサポートする場合に適切に機能し、リダイレクトURLパラメータはユーザーが変更できないセッション属性として格納されます。

サーブレットのinit-param要素disable_url_paramによる保護は、選択する必要があり、デフォルトでは無効になっています。リダイレクト・パラメータをブラウザURLリクエストで渡すレガシー・アプローチを使用する既存のアプリケーションでは、disable_url_param属性を有効にしないでください。新しいアプリケーションでは、例に示すように選択(disable_url_paramをtrueに設定)して、success_urlおよびend_urlがブラウザURLで使用されないようにすることをお薦めします。

allPages制約は「/」URLにマッピングされるため、Java EEアプリケーション・ルートを保護します。このマッピングにより、ADFセキュリティがアクセスされる前でも、Oracle WebLogic Serverコンテナがユーザー認証を動的にトリガーできるようになります。ユーザーがアプリケーションに最初にアクセスするときに、コンテナがユーザーにユーザー名とパスワードを求めるように強制します。その後、ユーザーがADFセキュリティで保護されたページにアクセスするときは、ユーザーを認証したりADF認証サーブレットにリダイレクトしたりする必要はありません。

ノート:

ログインを明示的にトリガーするログイン・リンクまたはログイン・ボタンを用意する場合は、allPages制約をweb.xmlファイルから削除できます。ログアウトを実行するリンクまたはボタンも用意します。ログインとログアウトを実行するカスタム・コンポーネントの作成方法の詳細は、「ログイン・ページの作成」を参照してください。動的認証を許可するために制約を保持する場合は、Java EEアプリケーション・ルートの下位項目すべてがこの制約の対象になるため、「カスタム・ログイン・ページのリソースを明示的な認証時にアクセス可能にする方法」で説明するように、サポートするリソースが実行時にログイン・ページに表示されないことがあります。

アプリケーションのすべてのユーザーがログインできる必要があるため、adfAuthenticationリソースに定義されるセキュリティ制約を使用すると、すべてのユーザーがこのWebリソースにアクセスできるようになります。このように、制約に関連付けられるセキュリティ・ロールはすべてのユーザーを含む必要があります。このタスクを簡略化するため、Java EE valid-usersロールが定義されています。weblogic.xmlファイルでは、このロールが、Oracle WebLogic Serverによって定義された暗黙のusersグループにマッピングされます。「valid-usersロールに関する必知事項」で説明するように、Oracle WebLogic Serverは、正しく認証されたすべてのユーザーをusersグループのメンバーとして構成するため、このマッピングにより、すべてのユーザーがこのロールを持つことが保証されます。

ノート:

adfAuthenticationリソース制約は、ADF認証サーブレットに対して1つの標準URLパターンの定義を提供します。このADF認証サーブレットのURLパターンを参照する明示的なログイン・リンクまたはログアウト・リンクをWebページに表示できます。この明示的なログイン・シナリオは、「ADFセキュリティの構成」ウィザードで単純なログイン・フォームを生成し、ADF認証を利用してユーザーにログインを求めるかわりに使用できます。明示的なログイン・シナリオの処理の詳細は、「ログイン・ページの作成」を参照してください。

認可を有効化するため、ウィザードはadf-config.xmlファイルを更新し、次の例に示すように<JaasSecurityContext>要素のauthorizationEnforceパラメータをtrueに設定します。

<JaasSecurityContext 
  initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"
  jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
                             authorizationEnforce="true"
                             authenticationRequire="true"/>

認可が有効化されると、ユーザーがコンテナによって認証された後で、ADFセキュリティ・コンテキストがHttpServletRequestからユーザー・プリンシパルを取得します。ユーザーはユーザー名とパスワードを送信し、そのデータがユーザー情報が格納されているアイデンティティ・ストアのデータと比較されます。一致するデータが見つかると、要求の発信元(ユーザー)が認証されます。その後、ユーザー・プリンシパルはADFセキュリティ・コンテキストに格納され、認可権を判別するために他のセキュリティ関連情報(ユーザーが所属するグループなど)を取得する際にアクセスできます。ADFセキュリティ・コンテキストのアクセス方法の詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。

デフォルトのフォームベース・ログイン・ページ生成時の処理

ウィザードで生成されるログイン・ページおよびエラー・ページは単純なHTMLページです。ユーザー・インタフェース・プロジェクトの最上位フォルダに追加されます。生成されるログイン・ページでは、ユーザーのログイン・リクエストを標準のj_security_checkアクションによって送信するHTMLフォームが定義されます。このアクションとフォームベース認証(ウィザードで提供されるコンテナ認証のデフォルト・オプション)を使用すると、Webコンテナでユーザーに対して様々なWebアプリケーション・リソースを認証できるようになります。

ウィザードはweb.xmlファイルを更新し、次の例に示すように、フォームベース認証を指定してページの場所を指定します。

<login-config>
   <auth-method>FORM</auth-method>
   <form-login-config>
       <form-login-page>/login.html</form-login-page>
       <form-error-page>/error.html</form-error-page>
   </form-login-config>
</login-config>

認証されていないユーザーが保護対象のリソースにアクセスしようとすると、ウィザードで生成されたログイン・ページがサーバー側からのリダイレクトによってアプリケーションに表示されます。ログイン・ページへのリダイレクトは、ADFセキュリティ対応のリソースを含むページにユーザーが移動した場合にのみ発生するため、これは暗黙的な認証と呼ばれます。

Webアプリケーションにはパブリック・ページの概念もあり、明示的な認証と暗黙的な認証に対応します。つまり、ユーザーは保護されたコンテンツに移動する前にログイン・リンクをクリックすることによってアプリケーションにログインできるということです。ログイン・リンクの作成および使用の詳細は、「ログイン・ページの作成」を参照してください。

「ADFセキュリティの構成」ウィザードに関する必知事項

最初に「ADFセキュリティの構成」ウィザードを実行して認証と認可を有効にすると、アプリケーション・レベルでADFリソースが保護されます。さらに、ユーザー・インタフェース・プロジェクトについて特定のプロジェクトレベル設定(認証のタイプや認証のようこそページなど)を選択します。ウィザードによって、選択するプロジェクトのweb.xmlファイルにWebアプリケーション設定が追加されます。アプリケーションに複数のユーザー・インタフェース・プロジェクトとweb.xmlファイルが含まれる場合は、ウィザードに戻り、選択する別のユーザー・インタフェース・プロジェクトのweb.xmlファイルでこれらの設定を構成します。

ADF認証に関する必知事項

Java EEコンテナ管理の認証を使用するログイン用のFusion Webアプリケーションとログアウト用のADF認証は、特別な要件なしでOracle Single Sign-On (Oracle SSO)と統合されます。ADF認証サーブレットは、ログアウトの詳細を処理し、ユーザー・セッションを無効にします。ただし、アプリケーションがServlet 3.0によって提供されるログインおよびログアウトのメソッドを使用している場合、Oracle SSOはサポートされません。さらに、Servlet 3.0のログインおよびログアウトは、Java EE 6以降を完全にサポートするアプリケーション・サーバーのみと互換性があります。

ADFセキュリティ対応リソースに依存するページが最初にアクセスされたときにユーザーがまだログインしていない場合は、アプリケーション・サーバーによってセッションが作成され、ADFセキュリティの構成ウィザードの実行時にweb.xmlに構成されたJpsFilterによってanonymousユーザー・プリンシパルとanonymous-roleロール・プリンシパルを含むサブジェクトが作成されます。このロール・プリンシパルを使用すると、無名ユーザー・セッションでは、認証されていないユーザーがどのADFセキュリティ対応リソース(ADFバインド・タスク・フローまたはページ定義など)にも関連付けられていないパブリックWebページにアクセスできます。ログイン時に、WebLogic Serverは既存の無名ユーザー・セッションを無効にせず、セキュリティ上の理由により、認証されたユーザー・セッションの新しいセッションIDのみを作成します。

WebLogic Serverによって強制される認証済ユーザー・セッション動作により、ユーザーは無名ユーザー・セッション・データを新しいIDを持つ認証済ユーザー・セッションにクローニングすることで、前にアクセスしたパブリック・ページを引き続き表示できます。この動作は、WebLogic Server上でのHTTPセッションの作成方法とは異なりますが、無名ユーザー・セッション・データを認証ユーザー・セッションに渡すときにセキュリティ・リスクが伴いません。

ノート:

Fusion Webアプリケーションでは、セッションBeanが初期化されるのはセッションの確立時のみです。セッションがanonymousとして作成された場合、WebLogic Serverによって新しいセッションが作成される場合でも、セッションBeanはユーザーのログイン時に再初期化されません。これは、パブリック・ページからセキュリティ保護されたページに移動する場合です。ただし、ユーザーがセキュリティ保護されたページでアプリケーションに入る場合は、ユーザー・ログイン時にセッションBeanが初期化されます。

そのため、Fusion Webアプリケーションでは、現在のユーザー・データを認証済セッションから取得するためにセッション・スコープのマネージドBeanを使用しないでください。アプリケーションで現在のユーザーを取得する正しい方法は、ADFセキュリティ・コンテキストから取得することです。ADFセキュリティ・コンテキストを扱うAPIの詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。

ADFセキュリティ対応リソースに関連付けられているページの場合は、無名ユーザーがページにアクセスできるようにするには、view権限をanonymous-roleに明示的に付与する必要があります。無名ユーザーへの権限付与の詳細は、「ADFリソースを公開する方法」を参照してください。

組込みtest-allロールに関する必知事項

「ADFセキュリティの構成」ウィザードを使用して、アプリケーションのすべてのADFセキュリティ対応リソースのview権限を付与するために、組込みtest-allアプリケーション・ロールへの自動付与を有効にすることができます。権限(自動view権限またはユーザー定義の明示的な権限)が付与されないと、ADFセキュリティの認可チェックの施行により、アプリケーションの実行とリソースへのアクセスを行えなくなります。test-allアプリケーション・ロール機能を有効にしてウィザードを実行し、その後、自動view権限を明示的な権限で段階的に置き換えることができます。test-allアプリケーション・ロールの権限が設定された状態ではアプリケーションをデプロイしないでください。この機能のためにすべてのADFリソースが公開されるためです。ウィザードで組込みtest-allアプリケーション・ロールの有効化を選択する場合は、アプリケーションをデプロイする前に「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」を参照してください。

valid-usersロールに関する必知事項

valid-usersロールは、ADFセキュリティによって定義されたJava EEセキュリティ・ロールです。このロールにより、web.xmlファイルで定義されたadfAuthenticationサーブレットWebリソースにすべてのユーザーがアクセスできることが保証されます。ADFセキュリティの構成ウィザードはweblogic.xmlファイルを更新し、次の例に示すように、このADFセキュリティ・ロールをusersプリンシパルにマッピングします。Oracle WebLogic Serverは、正常に認証されたすべてのユーザーをusersグループのメンバーとして構成するため、このマッピングによりすべてのユーザーがこのロールを持ちます。

<security-role-assignment>
   <role-name>valid-users</role-name>
   <principal-name>users</principal-name>
</security-role-assignment>

usersプリンシパルは、実行時に、OPSSによって、正常に認証されたサブジェクトに自動的に追加されます。セキュリティの観点から、valid-usersロールがADF認証をサポートするのは、セキュリティ制約だけを使用してWebリソースへのアクセスを制御する必要がある場合のみです。このマッピングの最終的な結果はJava EEセキュリティに全面的に依存します。JAAS権限は関係ありません。

アプリケーション・ロールの作成

ADFオブジェクトに対する権限を付与するには、エンタープライズ・グループにマップされるアプリケーション・ロールを作成する必要があります。ロールを定義するには、次の2つの方法があります。これらは、アプリケーション・ロールまたはエンタープライズ・ロールとして定義できます。アプリケーション・ロールはアプリケーションにローカルで、アプリケーションで定義されたユーザーおよびロールのみ含むことができます。エンタープライズ・ロールは、ドメインにデプロイされているすべてのアプリケーションが使用できます。

アプリケーション・ロールを作成して、アプリケーションのポリシー要件を表し、同じview権限を持つユーザーのグループを定義します。アプリケーション・ポリシー・ストアに作成するアプリケーション・ロールは、お使いのアプリケーション固有のものです。たとえば、ワークフローのコンテキストでは、Application Customer RoleやApplication Employee Roleなどのアプリケーション・ロールが、Summit ADFサンプル・アプリケーションのSummitADF_TaskFlowsワークスペースで定義されていることがあります。

実行時には、ユーザーがメンバーとして定義されているアプリケーション・ロールにより、ユーザーにアクセス権が付与されます。このように、セキュリティ・ポリシーを定義する前に、権限の付与先にするアプリケーション・ロールをポリシー・ストアに含める必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Roleなど)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-roleまたはanonymous-role)のいずれかでもかまいません。JDeveloperで提供される組込みアプリケーション・ロールを使用すると、「ADFリソースを公開する方法」で説明するようにADFリソースを公開できます。

アプリケーション・ロールを作成した後は、次の手順を実行します。

• 「ADFセキュリティ・ポリシーの定義」の説明に従って、権限をアプリケーション・ロールに付与します。

• 「テスト・ユーザーの作成」の説明に従って、テスト・ユーザーを各アプリケーション・ロールに関連付けます。

ベスト・プラクティス:

ADFセキュリティ・フレームワークは、アプリケーション・ロールまたは個々のユーザーに付与された権限に基づいて、ロールベースのアクセス制御メカニズムを施行します。セキュリティのテストのみを行う必要があり、ユーザー・グループを作成する必要がなくても、アプリケーション・ロール(少なくとも1ユーザー・メンバーを含む)を作成しなければなりません。後でADFリソースのセキュリティ・ポリシーを定義するとき、アプリケーション・ポリシー・ストアの概要エディタを使用して、権限に対してアプリケーション・ロールを選択できます。

アプリケーション・ロールを作成する方法

JDeveloperでは、アプリケーション・ロールをjazn-data.xmlファイルのポリシー・ストアに格納できます。これは、「アプリケーション・リソース」パネルのDescriptors/META-INFノードに表示されます。

ノート:

アプリケーション・ロールを作成するときは、新しいアプリケーション・ロールをアイデンティティ・ストアではなくポリシー・ストアに追加してください。アイデンティティ・ストアに追加するロールによって、エンタープライズ・セキュリティ・ロールが定義されます。また、このロールは、アイデンティティ・ストア内のユーザーをグループ化するときに役立ちます。エンタープライズ・ロールの詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。

jazn-data.xmlファイルのポリシー・ストアにアプリケーション・ロールを作成するには、jazn-data.xmlファイルの概要エディタの「アプリケーション・ロール」ページを使用します。このエディタを使用すると、アイデンティティ・ストアのメンバーと、作成するアプリケーション・ロールの関係を表示できます。

始める前に:

アプリケーション・ロールについて理解しておくと役立ちます。詳細は、「アプリケーション・ロールの作成」を参照してください。

アプリケーション・ロールを作成するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。
2. jazn-data.xml概要エディタの「アプリケーション・ロール」ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。

   JDeveloperによってjazn-data.xmlファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。

3. 「ロール」リストで「新規」アイコンをクリックします。
4. 「名前」フィールドにロール名を入力します。他のいずれかのフィールドをクリックすると、アプリケーション・ロールがポリシー・ストアに追加されます。
5. テスト・ユーザーをアイデンティティ・ストアにすでに設定している場合は、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」の説明に従ってユーザーとロールをマッピングできます。

アプリケーション・ロール作成時の処理

アプリケーション・ロールをポリシー・ストアに追加すると、アプリケーション・ワークスペースを基準とするsrc/META-INFディレクトリにあるjazn-data.xmlファイルがJDeveloperによって更新されます。アプリケーション・ロールは、次の例に示すように<policy-store>内の<app-role>要素に定義されます。ポリシー・ストアの<application>要素にアプリケーションが指定されるため、作成するすべてのアプリケーション・ロールは、実行時にそのアプリケーションに対してのみ有効になります。他のWebアプリケーションは、独自のアプリケーション・ロールのセットを含むポリシー・ストアを定義できます。

<policy-store>
     <applications>
         <application>
            <name>SummitADFTaskFlows</name>
            <app-roles>
               <app-role>
                  <name>Application Employee Role</name>
                  <display-name>Application Employee Role</display-name>
                  <class>oracle.security.jps.service.policystore.
                                                        ApplicationRole</class>
               </app-role>
               ...
            </app-roles>
            <jazn-policy>
              ...
            </jazn-policy>
         </application>
    </applictions>
</policy-store>

エンタープライズ・ロールとアプリケーション・ロールに関する必知事項

エンタープライズ・ロールは、ドメインのアイデンティティ・ストア(アプリケーションのアイデンティティ・ストアではなく)で管理されるロールです。ドメインにデプロイされているすべてのアプリケーションが使用できるため、エンタープライズ・ロールは外部ロールとも呼ばれます。

アプリケーション・ロールはFusion Webアプリケーションで使用されるロールです。これはアプリケーション固有であり、アプリケーション・ポリシーで定義するものなので、Java EEコンテナで認識できるとはかぎりません。アプリケーション・ロールは、アプリケーションに定義されたユーザーとロールのみを含むという意味でスコープ指定されています。アプリケーション・ロールはエンタープライズ・ロールにマッピングする必要があります。

jazn-data.xmlファイルの概要エディタを使用して、アイデンティティ・ストアに追加するユーザーをグループ分けするためのエンタープライズ・ロールを作成します。この仕組みを使用すると、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」で説明するように、定義したアプリケーション・ロールにすべてのユーザー・グループを割り当てて、ADFセキュリティ・ポリシーで定義されたアクセス権を付与できます。

ただし、統合WebLogic Serverでは、JDeveloper内でアプリケーションを実行するためにエンタープライズ・ロールを作成する必要はありません。アプリケーションをテストするためには、少数のテスト・ユーザーを作成して、アプリケーションに直接割り当てるだけで十分な場合があります。アプリケーションをJDeveloperで実行すると、ユーザーと定義済エンタープライズ・ロールが、デフォルトのセキュリティ・プロバイダ(統合WebLogic Serverの埋込みLDAP)に作成されます。

通常、ステージングのためにアプリケーションをデプロイするときは、ポリシー・ストアのみをターゲット・サーバーに移行します。「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、アイデンティティ・ストア(テスト・ユーザーとエンタープライズ・ロールを含む)が移行されないように、JDeveloperデプロイメント・オプションを構成できます。

セキュア・アプリケーションをデプロイすると、Oracle Fusion Middlewareはアプリケーションのポリシー・ストアをドメインレベル・ポリシー・ストアのポリシーとマージします。このタスクを完了するために、Oracle WebLogic Serverの管理者は、最終的にポリシー・ストアのアプリケーション・ロールを既存のドメインレベル・エンタープライズ・ロールにマッピングします。ドメイン・レベルでのこのようにアプリケーション・ロールをマッピングすると、定義したADFセキュリティ・ポリシーに従ってエンタープライズ・ユーザーがアプリケーション・リソースにアクセスできるようになります。また、管理者がドメインレベルでアプリケーション・ロール・マッピングを行うことにより、本番環境のアイデンティティ・ストアの知識がなくても、アプリケーションのADFセキュリティ・ポリシーを開発できるようになります。

ADFセキュリティ・ポリシーの定義

ADFセキュリティ実装は、認証および認可という2つの主要概念から構成されます。認証は、アイデンティティ・ストアに基づいてユーザーのアイデンティティを確認し、認可は、ユーザーがポリシー・ストアでアクセス権を付与されたリソースへのアクセス権のみ持つことを確認します。

認可で利用されるポリシー・ストアは、実行時にアクセスされ、指定したオブジェクトに対する事前定義済のアクション(viewなど)を実行するための権限を含みます。当初、「ADFセキュリティの構成」ウィンドウを実行した後では、ポリシー・ストアでは権限が定義されていません。また、デフォルトのウィザード・オプション「ADF認証および認可」では認可チェックが有効になるため、ADFセキュリティ対応リソースに依存するアプリケーションのWebページにユーザーはアクセスできません。ユーザーのアクセスを許可するリソースに明示的な権限を定義するには、JDeveloperを使用する必要があります。

ベスト・プラクティス:

デフォルト・オプション「ADF認証および認可」を選択して「ADFセキュリティの構成」ウィザードを実行すると、アプリケーションのWebページがロックダウンされます。指定するページのみのアクセスをユーザーに許可するように明示的な権限を定義するため、このときにFusion Webアプリケーションに最大限の保護を実現できます。このようなガイドラインの詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

セキュリティ・ポリシーを定義するには、アプリケーションのポリシー・ストアに、権限を付与するアプリケーション・ロールが含まれる必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Roleなど)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-roleまたはanonymous-role)のいずれかでもかまいません。アプリケーション・ロールは、同じロールの各メンバーが同じアクセス権を持つようにユーザーを分類する目的で使用できます。このため、セキュリティ・ポリシーにより、アプリケーション・ロールには、(個別のユーザーでなく)権限のプリンシパルの名前が付けられます。アプリケーション・ロールの定義の詳細は、「アプリケーション・ロールの作成」を参照してください。

ユーザー・インタフェース・プロジェクトの場合、セキュリティ・ポリシーに対応する概要エディタを使用して、ADFタスク・フローとADFページ定義などのADFリソースをセキュリティ保護します。jazn-data.xmlファイルのエディタを開きます。これには、jazn-data.xmlファイル(「アプリケーション・リソース」パネル)をダブルクリックするか、メイン・メニューの「アプリケーション」メニューから「保護」→「リソース権限」を選択します。

jazn-data.xmlファイルを開くと、テスト・ユーザー、エンタープライズ・ロールおよびアプリケーション・ロールを作成するために別のエディタ・ページが概要エディタに表示されることに注意してください。

データ・モデル・プロジェクトの場合、エンティティ・オブジェクトまたはその属性のセキュリティを保護するのに、セキュリティ・ポリシーの概要エディタは使用しません。かわりに、これらのオブジェクトにメタデータを直接設定して、データバインドUIコンポーネントがデータを表示するかどうかを管理します。行レベル・セキュリティの権限付与の詳細は、「データのポリシーを定義する方法」を参照してください。

ADFリソースを公開する方法

個別のアクセス権限にかかわらず、一部のWebページをすべてのユーザーが表示できるようにするのは、一般的な要件です。たとえば、ホームページは、サイトにアクセスするすべてのユーザーに対して表示する必要がありますが、企業サイトは認証によって身元が確認されたユーザーのみに表示する必要があります。

どちらの場合も、ページを表示する権限がユーザーの特定の権限によって定義されているわけではないので、ページはパブリックであると考えられます。両者の違いは、ユーザーが匿名であるか、それとも既知のアイデンティティであるかです。

ADFセキュリティ・モデルでは、アクセス権限をanonymous-roleプリンシパルに付与することで、セキュリティの欠如とコンテンツの公開アクセスを区別します。匿名ロールは、既知のユーザーと無名ユーザーの両方を含みます。したがって、anonymous-roleに付与される権限を使用すると、認証されていないユーザー(たとえばゲスト・ユーザー)によるリソースへのアクセスを許可できます。認証済ユーザーのみにアクセスを許可するには、authenticated-roleプリンシパルにポリシーを定義する必要があります。

ノート:

アプリケーション内の他のページへのリンクを含むパブリック・ホームページの作成方法の詳細は、「パブリックなようこそページの作成方法」を参照してください。

始める前に:

ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、「ADFセキュリティ・ポリシーの定義」を参照してください。

次のタスクを完了する必要があります。

1. 「タスク・フローの作成」の説明に従って、バインド・タスク・フローを作成します。

2. 「ページ定義ファイルの処理」の説明に従って、ADFページ定義ファイルを含むWebページを作成します。

3. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

4. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

ADFセキュリティ対応リソースに対する公開アクセス権を付与するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから次のいずれかのリソースを選択します。

   • 「タスク・フロー」(バインド・タスク・フローを公開する場合)。アプリケーションによって、タスク・フローそのものに定義した権限の下でWebページが表示されます。つまり、バインド・タスク・フローのすべての構成Webページが公開されます。

   • 「Webページ」(個別のWebページを公開する場合)。通常、これらのページはバインドなしタスク・フローに定義された、アプリケーションのトップレベル・ページ(ホームページなど)です。

3. 「リソース」列で、アクセス権を付与するADFリソースを選択します。

   選択するリソースは、リソース名の横の最初の列にロック・アイコンが表示されている必要があります。ロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図47-4ではADFリソースcustomer-registration-task-flow (バインド・タスク・フロー)は権限が定義されていないため、ロック・アイコンが表示されています。

   ヒント:

   概要エディタの先頭列のヘッダーにあるキー切替えアイコンをクリックして、すでに権限が定義されたリソースの非表示と表示を切り替え、権限のないリソースのみを表示します。キー・アイコンは、リソースに権限が定義されており、十分なアクセス権を持つユーザーがアクセスできることを示します。

   図47-4 概要エディタでのADFセキュリティ対応リソースの選択

   
   「図47-4 概要エディタでのADFセキュリティ対応リソースの選択」の説明
4. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
5. 「アプリケーション・ロールの選択」ダイアログで、次の組込みアプリケーション・ロールから1つを選択します。

   • anonymous-roleは、サイトにアクセスするすべてのユーザーがリソースにアクセスできることを意味します。このロールへの権限付与が必要となるのは、ユーザーがログインしなくても、ADFセキュリティ対応リソースに関連するWebページにアクセスできるようにする場合です。たとえば、顧客の登録を管理するタスク・フローについてanonymous-roleに権限を付与します。

   • authenticated-roleは、認証されたユーザー(サイトにアクセスしてログインしたユーザー)のみがリソースにアクセスできることを意味します。たとえば、従業員登録のタスク・フローについてauthenticated-roleに権限を付与します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
7. 概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。

   デフォルトでは、図47-5のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。

   図47-5 概要エディタでのanonymous-roleへの権限付与

   
   「図47-5 概要エディタでのanonymous-roleへの権限付与」の説明

ADFリソースの公開時の処理

セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルが更新されます。

概要エディタは、ファイルの<policy-store>セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロール(この場合は匿名ロール)です。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。

次の例は、顧客登録タスク・フローを公開するjazn-data.xmlファイルのセキュリティ・ポリシーを示しています。anonymous-roleに対する権限には、バインド・タスク・フローcustomer-registration-task-flowの1つのview権限が含まれます。この権限により、すべてのユーザーが顧客登録タスク・フローを開始して顧客登録プロセスを完了できます。匿名ロールに権限を追加することもでき、匿名ロール権限の<permissions>セクションに表示されます。

<policy-store>
   ...
   <jazn-policy>
      <grant>
         <grantee>
            <principals>
                <principal>
                   <class>oracle.security.jps.internal.core.
                                         principals.JpsAnonymousRoleImpl</class>
                   <name>anonymous-role</name>
                </principal>
            </principals>
         </grantee>
         <permissions>
            <permission>
                  <class>oracle.adf.controller.security.TaskFlowPermission</class>
                  <name>/WEB-INF/customer-registration-task-flow.xml#
                                           customer-registration-task-flow</name>
                  <actions>view</actions>
            </permission>
            ...
         </permissions>
      ...
      </grant>
      ...
   </jazn-policy>
</policy-store>

実行時に行われる処理: 組込みロールの使用方法

anonymous-roleおよびauthenticated-roleという名前は、Oracle Platform Security Services (OPSS)によって定義される特別なロールです。

「ADFセキュリティの構成」ウィザードを実行すると、匿名ロールのサポートを有効にするJpsFilter定義がweb.xmlファイルに構成されます。匿名ロールを有効にすると、無名ユーザー(ログインしていないユーザー)によるサイトのブラウズがADFセキュリティによってサポートされます。反対に、認証ロールは宣言されず、デフォルトで常に識別されます。ADFセキュリティでは両方のロールがサポートされます。

エンド・ユーザーがADFセキュリティ対応リソースに最初にアクセスするとき、システムによってサブジェクトが作成され、匿名ロール・プリンシパルがそのサブジェクトに移入されます。アクセス対象のADFセキュリティ対応リソースのview権限が匿名ロールに付与されているかぎり、ユーザーのアクセスが許可されます。匿名ロールがADFリソースの権限受領者でない場合、ユーザーはログインするように求められます。ログインすると認証ロールがサブジェクトに追加されます。また、ウィザードによってJpsFilter定義がweb.xmlファイルに追加されます。remove.anonymous.roleはfalseに設定され、ユーザーがログインした後でも匿名ロール・プリンシパルが使用可能になります。認証ロール・プリンシパルを使用すると、認証ロールに対して明示的に権限が付与されたリソースにユーザーがアクセスできます。

ADFバインド・タスク・フローのポリシーを定義する方法

セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFバインド・タスク・フローのアクセス・ポリシーを定義します。作成する権限は、jazn-data.xmlファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はバインド・タスク・フロー定義名)を定義します。

ベスト・プラクティス:

バインド・タスク・フローの個々のWebページに対しては権限を作成しないでください。ユーザーがバインド・タスク・フローにアクセスする場合、すべてのページのセキュリティはタスク・フローに付与する権限により管理されます。また、含まれている(ページ定義が関連付けられている) Webページにはデフォルトでアクセスできないため、ADFセキュリティではユーザーによるタスク・フローのページへの直接アクセスが禁止されます。これにより、タスク・フローの明確なセキュリティ・モデルがサポートされ、すべてのユーザーに単一エントリ・ポイントを強制します。セキュリティ・ポリシーの実装方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

表47-3で説明するように、概要エディタで「タスク・フロー」ヘッダーの切替えボタンをクリックすると、タスク・フローをソートできます。

表47-3 バインド・タスク・フローのリソース権限切替えボタン

ボタン	切替えアクション	説明
	権限のないバインド・タスク・フローの表示または非表示	権限が定義されていないバインド・タスク・フローを表します。タスク・フローがコールするWebページにはすべてのユーザーがアクセスできません。
	権限付きのバインド・タスク・フローの表示または非表示	1つ以上の権限が定義されたバインド・タスク・フローを表します。タスク・フローがコールするWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。

概要エディタに表示される、利用できるアクションのリストは、タスク・フロー権限クラス(oracle.adf.controller.security.TaskFlowPermission)によって定義されます。権限クラスは、これらのアクションを、タスク・フローがサポートする操作にマップします。表47-4に、JDeveloperによって表示される、ADFバインド・タスク・フローに対するアクションを示します。

Fusion Webアプリケーションで現在サポートされているのはviewアクションのみです。customize、grantまたはpersonalizeアクションを選択しないでください。これらはタスク・フロー・セキュリティで将来使用するために用意されています。

表47-4 ADFバインド・タスク・フローのセキュリティ保護されたアクション

許可できるアクション	ユーザー・インタフェースへの影響
view	Fusion Webアプリケーションのバインド・タスク・フローの読取りと実行を行うユーザーを制御します。 これは、タスク・フローがサポートする唯一の動作です。
customize	将来の使用のために予約されています。このアクションは実行時にチェックされません。
grant	将来の使用のために予約されています。このアクションは実行時にチェックされません。
personalize	将来の使用のために予約されています。このアクションは実行時にチェックされません。

タスク・フロー・セキュリティ・ポリシーの権限を定義するには、jazn-data.xmlファイルの概要エディタの「リソース権限」ページを使用します。

始める前に:

ADFセキュリティ・ポリシーについて理解しておくと役立ちます。「ADFセキュリティ・ポリシーの定義」を参照してください。

次のタスクを完了する必要があります。

1. 「タスク・フローの作成」の説明に従って、バインド・タスク・フローを作成します。

   ベスト・プラクティス:

   同じアプリケーションの別のUIプロジェクトのバインド・タスク・フローを作成している場合、一意のタスク・フロー定義名を割り当てることをお薦めします。これが必要になるのは、権限のタスク・フロー定義名がjazn-data.xmlポリシー・ストアにパスでスコープ指定されているためです(たとえば、/WEB-INF/mytaskflow-definition.xml#mytaskflow-definition)。したがって、権限のプロジェクトレベル・スコープを設定するには、一意の定義名でバインド・タスク・フローを作成するしかありません。

2. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

3. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

ADFバインド・タスク・フローで権限を定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択します。

   概要エディタに、アプリケーションで定義されるすべてのタスク・フローが表示されます。タスク・フローは、ユーザー・インタフェース・プロジェクトの「Webコンテンツ/ページ・フロー」ノードに表示されるタスク・フロー定義ファイル(.xml)で定義されます。

3. 「リソース」列で、アクセス権を付与するタスク・フローを選択します。

   最初にバインド・タスク・フローに権限付与を行うとき、最初の列のタスク・フロー名の横に「権限のないリソースを表示します。」アイコン(ロックを表すアイコン)が表示されます。概要エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。

   ヒント:

   「リソース」列のヘッダーの「権限付きリソースを表示します。」アイコン(キーを表すアイコン)をクリックすると、すでに権限が定義されているすべてのタスク・フローが非表示になります。こうすることで、図47-6のように権限のないタスク・フローのみが表示されます。さらに、タスク・フロー名の一部を検索フィールドに入力すると、文字が一致する名前のタスク・フローのみを表示できます。

   図47-6 概要エディタでの権限付きタスク・フローの非表示

   
   「図47-6 概要エディタでの権限付きタスク・フローの非表示」の説明
4. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
5. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

   「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明するように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

   アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
7. 概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。

   デフォルトでは、図47-7のように概要エディタにviewアクションが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。customize、grantまたはpersonalizeアクションを選択しないでください。これらは将来の使用のために用意されているものです。実行時にADFセキュリティでチェックされることはありません。

   TaskFlowPermissionクラスによってタスク・フロー(タスク・フローの操作にマッピングされる特定のアクション)が定義されます。表47-4を参照してください。

   図47-7 概要エディタでのバインド・タスク・フロー定義のアプリケーション・ロールへの権限付与

   
   「図47-7 概要エディタでのバインド・タスク・フロー定義のアプリケーション・ロールへの権限付与」の説明
8. このステップを必要なだけ繰り返して、追加の権限を作成します。

   同一のタスク・フロー定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

ページ定義を参照するWebページのポリシーを定義する方法

セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFページ定義のアクセス・ポリシーを定義します。作成する権限は、jazn-data.xmlファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はページ定義名)を定義します。

ベスト・プラクティス:

個々のWebページの権限を作成するのは、そのページがバインド・タスク・フローの構成ページでない場合のみです。ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。セキュリティ・ポリシーの実装方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。

表47-5で説明するように、概要エディタで「リソース」ヘッダーの切替えボタンをクリックするとWebページ定義リソースをソートできます。

表47-5 Webページ定義のリソース権限切替えボタン

ボタン	切替えアクション	説明
	権限のないトップレベル・ページの表示または非表示	バインドなしタスク・フローに含まれるWebページに対して定義された権限がないページ定義を表します。このWebページにはどのユーザーもアクセスできません。
	権限付きのトップレベル・ページの表示または非表示	バインドなしタスク・フローに含まれるWebページに対して定義された1つ以上の権限があるページ定義を表します。このWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。
	バインド・タスク・フローに含まれるページの表示または非表示	バインド・タスク・フローにも含まれるWebページに関連付けられたページ定義を表します。このようなWebページ定義には権限を付与しないでください。かわりに、バインド・タスク・フローのセキュリティ・ポリシーを定義します。
	保護できないページ(ページ定義なし)の表示または非表示	バインドなしタスク・フローに含まれる、ページ定義が定義されていないWebページを表します。(バインド・タスク・フローに含まれる同様のページは、バインド・タスク・フローの権限によって保護されます。)Webページは、ADFセキュリティ対応リソースにより保護されていないため、すべてのユーザーによりアクセス可能です。「ADFバインドなしのページのポリシー定義に関する必知事項」で説明するように、必要に応じて、空のページ定義ファイルを追加することでページを保護できます。

概要エディタに表示される、利用できるアクションのリストは、リージョン権限クラス(oracle.adf.share.security.authorization.RegionPermission)によって定義されます。権限クラスは、これらのアクションを、WebページのADFページ定義がサポートする操作にマップします。表47-6に、JDeveloperによって表示される、ADFページ定義に対するアクションを示します。

Fusion Webアプリケーションで現在サポートされているのはviewアクションのみです。

customize、grantまたはpersonalizeアクションを選択しないでください。これらは、WebCenter Portal: Frameworkアプリケーションでのページ定義セキュリティのためだけに実装されています。

表47-6 ADFページ定義のセキュアなアクション

許可できるアクション	ユーザー・インタフェースへの影響
view	ページを表示できるユーザーを制御します。 これは、ページ定義がサポートする唯一の動作です。 他のすべての操作はOracle WebCenter Portal: Frameworkをサポートしています。
customize	カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるアプリケーション)またはWebCenter Portalアプリケーションのページに含まれるWebCenter Portalカスタマイズ可能コンポーネント(カスタマイズ可能パネルまたは「詳細フレームの表示」)に対して暗黙の変更(最小化/復元、削除または移動)を実行できるユーザーを制御します。詳細は、『Oracle WebCenter Portalの開発』の「WebCenter Portalアセットの概要」を参照してください。
grant	すべてのWebCenter Portal固有のアクションを組み合せて指定した権限を付与します。他のすべてのアクションの権限付与と同じです。他のユーザーに権限を付与できるユーザーや、Oracle WebCenter PortalのComposerを使用してページのセキュリティ設定を変更できるユーザーも制御します。詳細は、『Oracle WebCenter Portalの開発』の「WebCenter Portalアセットの概要」を参照してください。
personalize	カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるアプリケーション)またはWebCenter Portalアプリケーションのページに含まれるWebCenter Portalカスタマイズ可能コンポーネント(カスタマイズ可能パネルまたは「詳細フレームの表示」)に対して暗黙の変更(最小化/復元、削除または移動)を実行できるユーザーを制御します。詳細は、『Oracle WebCenter Portalの開発』の「WebCenter Portalアセットの概要」を参照してください。

ページ定義セキュリティ・ポリシーの権限を定義するには、セキュリティ・ポリシーの概要エディタの「リソース権限」ページを使用します。

始める前に:

ADFセキュリティ・ポリシーについて理解しておくと役立ちます。「ADFセキュリティ・ポリシーの定義」を参照してください。

次のタスクを完了する必要があります。

1. 「ページ定義ファイルの処理」の説明に従って、ADFページ定義ファイルを含むトップレベルWebページを作成します。

   ベスト・プラクティス:

   同じアプリケーションの別のUIプロジェクトのトップレベルWebページを作成している場合、一意のページ・ファイル名を割り当てることをお薦めします。これが必要になるのは、権限のページ定義がjazn-data.xmlポリシー・ストアにパッケージでスコープ指定されているためです(たとえば、view.pageDefs.mytoppagePageDef)。したがって、権限のプロジェクトレベル・スコープを設定するには、一意のファイル名でトップレベル・ページを作成するしかありません。

2. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

3. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

ADFページ定義に権限を定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択します。

   概要エディタの「リソース権限」ページには、ADFページ定義が関連付けられているページも含め、すべてのWebページが表示されます。ADFバインディングを使用するあらゆるWebページや、空のページ定義を作成しておいたあらゆるWebページも含まれます。ページ定義は、ユーザー・インタフェース・プロジェクトの「アプリケーション・ソース」ノードに表示されるPageDef.xmlファイルで定義されます。

3. 「リソース」列で、アクセス権を付与するページ定義を選択します。

   最初にページ定義に権限付与を行うとき、最初の列のページ定義名の横に「権限のないリソースを表示します。」アイコン(ロック・アイコン)が表示されます。エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図47-8のページ定義account_updateUserInfoには権限が付与されていないためロック・アイコンが表示されます。図47-8の他のページ定義には「バインド・タスク・フローに含まれるページ」アイコンが表示されます。これらはトップレベル・ページではなく、含まれているバインド・タスク・フローによって保護されるためです。

   「バインド・タスク・フローに含まれるページ」アイコンが表示されている個々のWebページ定義には権限を作成しないでください。関連付けられたWebページのセキュリティ・ポリシーは、バインド・タスク・フローによって保護されます。たとえば、図47-8のaccount_addressDetails.jsffリージョンに関連付けられているページ定義は、それが含まれているバインド・タスク・フローによって保護されます。

   ヒント:

   ページ定義名の一部を検索フィールドに入力すると、文字が一致する名前のページ定義のみを表示できます。たとえば、generalという語を検索すると、図47-8に示すように名前がgeneralという語で開始するページ定義のみが表示されます。

   図47-8 概要エディタでの名前によるページ定義の検索

   
   「図47-8 概要エディタでの名前によるページ定義の検索」の説明

   ヒント:

   権限付きリソースのアイコン(キー・アイコン)をクリックすると、すでに権限があるすべてのページ定義を非表示にできます。「リソース」列のヘッダーの「バインド・タスク・フローに含まれるページを表示」切替えボタンがオフになっており、バインド・タスク・フローに含まれるページ定義がすべて非表示になっていることを確認します(デフォルトでは、これらのページが非表示になるように設定されています)。この場合、図47-9に示すように、権限がないトップレベル・ページ(および保護できないページ)が表示されます。

   図47-9 概要エディタでの権限付きWebページの非表示

   
   「図47-9 概要エディタでの権限付きWebページの非表示」の説明
4. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
5. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

   「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明するように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

   アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
7. 概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。

   デフォルトでは、図47-10のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。

   customize、grantまたはpersonalizeの各アクションは、WebCenter Portal: Frameworkアプリケーションまたはカスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できる)で使用するために実装されています。

   RegionPermissionクラスによってページ定義(ページの操作にマッピングされる特定のアクション)が定義されます。表47-6を参照してください。

   図47-10 概要エディタでのADFページ定義に関するアプリケーション・ロールへの権限付与

   
   「図47-10 概要エディタでのADFページ定義に関するアプリケーション・ロールへの権限付与」の説明
8. このステップを必要なだけ繰り返して、追加の権限を作成します。

   同一のページ定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法

アプリケーションによって定義されたADFメソッドは、コマンド・コンポーネントとしてユーザー・インタフェース内にドロップできます。デフォルトでは、メソッドのコマンド・コンポーネントが表示されたページにアクセス可能なユーザーには、このメソッドを実行する権限も与えられます。メソッド操作に対するアクセスを制限する追加のセキュリティを作成するには、リソース権限を作成し、ユーザー・インタフェース・レベルで権限をテストする必要があります。ADFセキュリティでは、ADFメソッドに対する認可チェックは行われません。アプリケーションでの認可チェックを独自に有効化する必要があります。ADFメソッドに対してユーザーに付与したリソース権限に基づき、ユーザー・インタフェースでコマンド・コンポーネントが有効化または無効化されます。

コマンド・コンポーネントとしてページに表示されるメソッドへのユーザー・アクセスを制御するには、次のステップを実行します。

1. カスタム・リソース・タイプおよびリソースに対してリソース権限を作成します。
2. ユーザー・インタフェースで権限付与を施行します。

ADFメソッドへのアクセスを制御するリソース権限の作成

リソース・タイプを作成するとマッチャ・クラスoracle.security.jps.ResourcePermissionに設定されます。これにより、アプリケーションのADFセキュリティで保護されていない部分に対して権限を付与できるようになります。たとえば、顧客への商品の出荷をユーザーが取り消すためのボタンをページに表示できます。ただし、特定のアプリケーション・ロールのメンバーのみが出荷を取り消すことができます。このルールを適用するには、実行時に宣言的にチェック可能なリソース権限をユーザー・インタフェースに作成し、ボタンを有効または無効にします。

保護対象のユーザー・インタフェース・コンポーネントに権限を作成するには、セキュリティ・ポリシーの概要エディタを使用します。

始める前に:

ADFセキュリティによるADFメソッドの処理方法について理解しておくと役立ちます。詳細は、「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

1. 「メソッドを実行するためのコマンド・コンポーネントの作成」の説明に従い、保護対象のメソッドを実行するコマンド・コンポーネントを作成します。

2. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

3. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

カスタム・リソース・タイプに対するリソース権限を付与するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストの横の「新規リソース・タイプ」ボタンをクリックします。
3. 「リソース・タイプの作成」ダイアログで、リソース・タイプの名前、JDeveloperでリソース権限を付与する際に表示される表示名、および説明を入力します。

   保護が必要なユーザー・インタフェース・リソースに適したリソース・タイプと表示名を入力します。たとえば、商品の出荷を取り消すためのメソッド・ボタンを保護する場合は、リソース・タイプにCancelShipment、表示名にCancel Shipmentなどと入力します。

4. 「アクション」リストの横の「アクションの追加」ボタンをクリックして、保護するアクションの名前を入力します。「OK」をクリックします。

   アクション名には、カスタム・リソース・タイプに関連付ける任意の名前を指定できます。たとえば、メソッドを起動するボタンを保護する場合は、アクション名にinvokeなどと入力します。個別のアプリケーション・ロールに対してリソース権限のインスタンスを付与できるようにする必要がある場合は、複数のアクションをリストに追加できます。

5. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで「リソース」列で、「リソースの追加」アイコンをクリックします。

   カスタム・リソース・タイプへの権限付与を最初に行うときには、定義済のリソースはありません。ポリシーに対してカスタム・リソースを作成する必要があります。このリソースは実行時にユーザー・インタフェースでユーザー権限をチェックする際に使用されます。

6. 「リソースの作成」ダイアログで、リソースの名前、JDeveloperでリソース権限を付与する際に表示される表示名を入力し、「OK」をクリックします。

   保護対象のユーザー・インタフェース・リソースを表すリソース名と表示名を入力します。たとえば、商品の出荷を取り消すためのメソッド・ボタンを保護する場合は、リソース名にCancelShipmentButton、表示名にCancel Shipment Buttonなどと入力します。

7. 「ロールに付与済」列で「権限受領者の追加」アイコンをクリックし、「アプリケーション・ロールの追加」を選択します。
8. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

   「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明するように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

   アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

9. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
10. 概要エディタの「リソース権限」ページの「アクション」列で必要なアクションを選択します。

    デフォルトでは、選択されていないカスタム・リソース・タイプのすべてのアクションが概要エディタに表示されます。使用可能なアクションはリソース・タイプによって定義されます。

11. このステップを必要なだけ繰り返して、追加の権限を作成します。

    同一のADFメソッド・リソースに、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

ユーザー・インタフェースによるリソース権限の施行

事前に定義されているカスタム・リソース・タイプに対してユーザーのアクセス権をチェックするEL式を定義するには、UIコンポーネントの表示プロパティで開いた「式ビルダー」ダイアログを使用します。アプリケーションを実行すると、EL式によるリソース権限評価の結果に基づき、コンポーネントが有効化または無効化されます。

たとえば、次の例に示すように、af:button#cb1ボタンのdisabled属性に対してuserGrantedPermission式を定義できます。この場合、ユーザーが権限を持っているかどうかが式によってテストされ、その結果ボタンが有効化されるか、ユーザーが権限を所有していない場合はボタンが無効化されます。この式はボタンのrendered属性に対して定義されているのではないため、ページには常にこのボタンが表示されます。

<af:button actionListener="#{bindings.myMethodName.execute}" 
     text="myMethodName"
     disabled="#{!securityContext.userGrantedPermission
       ['resourceName=CancelShipmentButton,resourceType=CancelShipment,
             action=invoke']}
     id="cb1"/>

始める前に:

ADFメソッド認可チェックの制限について理解しておくと役立ちます。詳細は、「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

• 「ADFメソッドへのアクセスを制御するリソース権限の作成」の説明に従って、カスタム・リソース・タイプに対するリソース権限を作成します。

式を使用してリソース権限をチェックするには:

1. 「アプリケーション」ウィンドウで、ADFメソッドにバインドされたコマンド・コンポーネントを含むページをダブルクリックします。
2. ページのビジュアル・エディタで、ADFメソッドの実行に使用されるコマンド・コンポーネントを選択します。
3. 「プロパティ」ウィンドウで、「無効」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
4. 「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedPermissionを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。

   権限文字列は、resourceName=aResourceName;resourceType=aResourceType;action=actionNameのようにセミコロンで連結した文字列として入力します。たとえば、ページ内でメソッドの起動に使用されるコマンド・ボタンを有効または無効にするには、前述の例に示したような式を入力します。

   例では、ユーザーに定義されているアプリケーション・ロールに対して、CancelShipmentというリソース・タイプの権限がリソース・ポリシー権限で起動されるかどうかは式によって決定されます。実行時に式をテストする際に、リソース・ポリシーがアプリケーション・ポリシー・ストアに存在している必要があります。

5. 「OK」をクリックします。

セキュリティ・ポリシーの定義時の処理

セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルが更新されます。

概要エディタは、ファイルの<policy-store>セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロールです。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。

次の例は、従業員登録のタスク・フローとそのタスク・フローにアクセスするために使用するトップレベルWebページに対して、認証されていないユーザーにアクセス権を付与するjazn-data.xmlファイルのセキュリティ・ポリシーを示しています。anonymous-roleアプリケーション・ロールに対する権限には、バインド・タスク・フローemp-reg-task-flowのview権限と、indexPageDefページ定義を含むWebページのview権限が含まれます。この権限によって、認証されていないユーザーは従業員登録タスク・フローに入り、ようこそページを表示できるようになります。

Webページに関しては、ようこそページ(index.jsf)に対して作成されたindexPageDefページ定義に権限が定義されていることに注意してください。また、これはバインド・タスク・フローによってまだ保護されていないトップレベルWebページであることにも注意してください。

<policy-store>
    ...
    <jazn-policy>
        <grant>
            <grantee>
                <principals>
                    <principal>
                         <name>anonymous-role</name>
                         <class>oracle.security.jps.internal.core.principals.
                                       JpsAnonymousRoleImpl</class>
                     </principal>
                 </principals>
             </grantee>
             <permissions>
                  <permission>
                      <class>oracle.adf.controller.security.TaskFlowPermission</class>
                      <name>/WEB-INF/flows/emp-reg-task-flow-definition.xml#
                                                  #emp-reg-task-flow-definition</name>
                      <actions>view</actions>
                  </permission>
                   <permission>
                        <class>oracle.adf.share.security.authorization.RegionPermission</class>
                        <name>oracle.summit.view.pageDefs.indexPageDef</name>
                        <actions>view</actions>
                  </permission>
                  ...
             </permissions>
        </grant>
        ...
    </jazn-policy>
</policy-store>

実行時に行われる処理: ADFセキュリティ・ポリシーの実施方法

ADFリソースに作成する権限は、標準のJAAS権限です。アプリケーションでADFセキュリティを有効化すると、Oracle WebLogic Server上で実行されているOracle Platform Security Service (OPSS)は、この権限を使用して認可を実行します。認可モードでは、ADFセキュリティは、JAAS権限で実装され、ページへのアクセス権のセキュリティ・チェックを実行する、きめ細かい認可を使用します。ADFセキュリティ施行ロジックは、JAASサブジェクトによって表現されるユーザーが、リソースにアクセスする正しい権限を持っているかどうかを確認します。

サブジェクトには、ユーザーのプリンシパル(ログオン前は無名、ログオン後はユーザー名を含むユーザー・プリンシパル)とロール・プリンシパルのリスト(authenticated-role、ポリシー・ストアやアイデンティティ・ストアから取得されるいくつかのロールなど)が含まれます。プリンシパルは、ポリシー・ストアに定義されているアプリケーション・ロールのすべてのユーザーのメンバーシップを表すために作成されます。また、各アプリケーション・ロールには複数の権限を関連付けておくことができます。これらは、jazn-data.xmlファイルの概要エディタで作成されるADFセキュリティ・ポリシーです。

ノート:

ADFセキュリティ・ポリシーはアプリケーションごとにスコープ指定されます。このスコープで2つのアプリケーションは、意図しない結果を生じることなく、同じ権限ターゲットを参照します。ポリシー・ストア情報のアプリケーション・スコープを設定するためにアプリケーション・リソースを指定する必要はありません。

統合WebLogic Serverを使用してアプリケーションを実行する前に、テスト・ユーザーを含むアイデンティティ・ストアをプロビジョニングし、構成するアプリケーション・ロールにそれらのユーザーを追加する必要があります。「テスト・ユーザーの作成」で説明するように、アプリケーション・ロールでは、ユーザーまたはユーザー・グループ(エンタープライズ・ロール)に固有のメンバーを定義できます。

その後、実行時に、現在のユーザーがアクセスしようとしているページのview権限を持っているかどうかが、ページのコンテキストによって決まります。

• ページがバインド・タスク・フローのアクティビティである場合は、タスク・フロー・コントローラによって権限が決まります。

• ページが、ページ定義ファイルが関連付けられたトップレベル・ページである場合は、ADFモデル・レイヤーによって権限が決まります。

次に、Oracle Platform Security Servicesにより、ページにアクセスするために必要な権限を持つロールがサブジェクトに含まれるかどうかが確認されます。ユーザーが認可されると、タスク・フローが開始します。

バインド・タスク・フローとトップレベル・ページ(バインドなしタスク・フローで定義)の場合、ユーザーが認可されないと、ADFコントローラによって例外がスローされ、タスク・フロー構成で指定された例外ハンドラに制御が渡されます。他のエラー・ページの指定の詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。

ADFバインドなしのページのポリシー定義に関する必知事項

「ADFセキュリティの構成」ウィザードのデフォルト・オプション「ADF認証および認可」では、認可チェックが有効になり、Webページが保護されます(WebページがADFセキュリティ対応リソースに関連付けられている場合)。したがって、ウィザードを実行した後で、次の両方の条件が存在するとWebページは保護されません。

• ページにデータバインドADF Facesコンポーネントが表示されず、ページにADFページ定義が存在していない場合。

• ページがデータバインドADFタスク・フローの構成ページでない場合。(ユーザーがバインド・タスク・フローのプロセスとしてアクセスするすべてのページは、タスク・フローの権限でチェックされます。)

「データ・コントロール」パネルを使用してWebページを設計し、データバインドされたADF Facesコンポーネントを作成するときには常に、JDeveloperによってADFページ定義ファイルが生成されます。ただし、WebページがADFバインディングを使用しない場合でも空のページ定義ファイルを作成できます。これには、ユーザー・インタフェース・プロジェクトのWebページを右クリックして、「ページ定義に移動」を選択します。このページ定義ファイルは空にしておくことができます。このページは、データバインドADF FacesコンポーネントをサポートするためにADFバインディングと連携する必要がないためです。

WebページとADFページ定義ファイル(空かどうかに関係なく)をいったん関連付けると、関連付けられたWebページにユーザーがアクセスするときに認可チェックが施行されます。他のADFページ定義と同様にページのセキュリティ・ポリシーを定義できます。空のADFページ定義に対する権限付与の詳細は、「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。

始める前に:

個々のページの定義ファイルのセキュリティについて理解しておくと役立ちます。詳細は、「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。

JDeveloperがページ定義ファイルを生成する通常の方法について理解しておくことも役立ちます。詳細は、「ページ定義ファイルでの作業」を参照してください。

セキュリティ・ポリシーを定義するために空のページ定義を作成するには:

1. 「アプリケーション」ウィンドウで、保護するWebページを探し、ノードを右クリックして「ページ定義に移動」を選択します。

2. 確認ダイアログで「はい」をクリックすると、ページの新しいページ定義が作成されます。

   ページ定義はpageDefsパッケージに追加されます。

正規表現を使用したリソース・グループのポリシーの定義方法

一度に複数のリソースに適用する権限を定義する場合は、java.util.regex.Patternクラスによって定義されるパターンを作成して、実行時に評価される正規表現を生成します。たとえば、権限を一連のリソースに対応させるには、権限の名前に対して.* (任意の文字0個以上を表す)という表現を入力できます。ADFセキュリティでは、他のセキュリティ・オブジェクト(プリンシパル名など)については正規表現を使用できません。

この機能を使用すると、次の例に示すように、同じ権限を持つバインド・タスク・フローをグループ化してWEB-INFの専用のサブフォルダに含め、そのフォルダ全体に権限を定義できます。この場合、ピリオド(任意の文字を表す)の後にアスタリスク修飾子(0回以上を表す)を付けた正規表現を使用します。

...
<grant>
   <grantee>
      <principals>
         <principal>
            <class>oracle.security.jps.service.policystore.ApplicationRole</class>
            <name>anonymous-role</name>
         </principal>
      </principals>
   </grantee>
   <permissions>
       <permission>
          <class>oracle.adf.controller.security.TaskFlowPermission</class>
          <name>/WEB-INF/.*</name>
          <actions>view</actions>
       </permission>
   </permissions>
</grant>

jazn-data.xmlファイルの概要エディタのユーザー・インタフェースでは、正規表現の使用がサポートされていないため、直接ファイルを編集する必要があります。system-jazn-data.xmlファイルのポリシー・ストアを直接編集しないでください。そのかわりに、正規表現を使用してjazn-data.xmlファイルに権限を追加します。アプリケーションを実行またはデプロイすると、これらの権限がポリシー・ストアにマージされます。

より複雑な正規表現を使用すると、ポリシーにビジネス・ルールを定義して、非常に限定的な権限のセットを作成できます。たとえば、すべてのページ定義にview権限を付与すると同時に、正規表現で除外セットを定義して特定のページ定義を除くことができます。次の例は、customで始まるページ定義名を除いたすべてのページに関してanonymous-roleにview権限を付与する方法を示しています。

<grant>
   <grantee>
      <principals>
         <principal>
            <class>oracle.security.jps.service.policystore.ApplicationRole</class>
            <name>anonymous-role</name>
         </principal>
      </principals>
   </grantee>
   <permissions>
      <permission>
         <class>oracle.adf.share.security.authorization.RegionPermission</class>
         <name>[^(custom)].*</name>
         <actions>view</actions>
      </permission>
   </permissions>
</grant>

表47-7は、ポリシー定義で使用できる正規表現の基本的なメタ文字の一部を示しています。

表47-7 メタ文字の説明

メタ文字	説明
[abc]	a、bまたはc(リストに含まれる)
[^abc]	a、bまたはc以外の文字(否定)
[a-zA-Z]	aからzまたはAからZ、包含的(範囲)
[a-d[m-p]]	aからd、またはmからp~= [a-dm-p](和集合)
[a-z&&[def]]	d、eまたはf(積集合)
[a-z&&[^bc]]	aからzのうち、bおよびcを除く、つまり[ad-z](減算)
[a-z&&[^m-p]]	aからzのうち、mからpを除く
.*	任意の個数の任意の文字(この表現ではピリオドとアスタリスクを一緒に使用することに注意)

データのポリシーを定義する方法

データ・モデル・オブジェクトのADFエンティティ・オブジェクトはセキュリティ対応です。つまり、開発者が付与することのできるリソース固有の権限が事前定義されています。さらに、エンティティ・オブジェクトの個々の属性だけを保護することもできます。

セキュリティ保護の対象とするエンティティ・オブジェクトでは、UIコンポーネントがADFバインディングによってセキュアなエンティティ・オブジェクトのアクセス先データにバインドされている場合に、そのUIコンポーネントをレンダリングしているWebページに表示されるデータの、ユーザーによる更新が制限されます。さらに、エンティティ・オブジェクトをセキュリティ保護する際、そのエンティティ・オブジェクトに依存するデータ・モデル・プロジェクト内のビュー・オブジェクトも事実上保護します。そのため、セキュリティ保護するエンティティ・オブジェクトは、このビュー・オブジェクトにバインドされたUIコンポーネントに適用される、さらに広範なアクセス・ポリシーを定義します。

ADFエンティティ・オブジェクトを使用して行データを保護するには:

1. 保護するエンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について、特定のアクションの権限マップを定義します。
2. ポリシー・ストアに追加したアプリケーション・ロールに権限を付与します。

ADFエンティティ・オブジェクトに対する権限マップの定義

データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクトによって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。

概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission)によって定義されます。権限クラスは、エンティティ・オブジェクトでサポートされる操作をアクションにマップします。表47-8は、エンティティ・オブジェクトの、セキュア化できる操作を示しています。

表47-8 ADFエンティティ・オブジェクトのセキュア化可能な操作

セキュアな操作	想定されるマップされたアクション	対応する実装
read	read	WHERE句フラグメントで制限された、数行の結果セットを表示します。
update	update	バインドされたコレクションの属性を更新します。
removeCurrentRow	delete	バインドされたコレクションの1つの行を削除します。

ノート:

read操作やupdate操作とは異なり、deleteアクションにマップされるセキュア化可能な操作は、一意識別子removeCurrentRowで定義されます。Fusion Webアプリケーションの認可チェックはアクション名ではなく操作名に依存するため、delete権限名ではなくremoveCurrentRow操作名をテストする必要があります。エンティティ権限をテストできるようにするエンティティ行APIおよびEL式の詳細は、「エンティティ・オブジェクト操作の認可チェックの実行方法」を参照してください。

エンティティ・オブジェクトがアクセスするすべての行レベル・データを保護するには、エンティティ・オブジェクト用の概要エディタを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

• 「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」の説明に従って、データ・モデル・プロジェクトにエンティティ・オブジェクトを作成します。

エンティティ・オブジェクトに対する操作をセキュア化するには:

1. 「アプリケーション」ウィンドウで、保護するエンティティ・オブジェクトをダブルクリックします。
2. 概要エディタで、「一般」ナビゲーション・タブをクリックします。
3. 「一般」ページで「セキュリティ」セクションを開き、エンティティ・オブジェクトについて保護する操作を選択します。

   「セキュリティ」セクションに、EntityPermissionクラスで定義されている、保護できる操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表47-8に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。

   たとえば、read権限を有効化するには、図47-11に示すように選択します。権限が、エンティティ・オブジェクトのXML定義に表示されます。

   図47-11 ADFエンティティ・オブジェクトのread操作に対する権限を有効化

   
   「図47-11 ADFエンティティ・オブジェクトのread操作に対する権限を有効化」の説明

ADFエンティティ・オブジェクト属性に対する権限マップの定義

データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクト属性によって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。

概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission)によって定義されます。権限クラスは、エンティティ・オブジェクト属性でサポートされる操作をアクションにマップします。表47-9は、エンティティ・オブジェクト属性の、保護可能な操作を示しています。

表47-9 ADFエンティティ・オブジェクト属性のセキュア化可能な操作

セキュアな操作	想定されるマップされたアクション	対応する実装
update	update	バインドされたコレクションの特定の属性を更新します。

エンティティ・オブジェクトがアクセスするデータの個々の列を保護するには、エンティティ・オブジェクト用の概要エディタの「属性」ページを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

• 「エンティティ・オブジェクトを使用したビジネス・ドメイン・レイヤーの作成」の説明に従って、データ・モデル・プロジェクトにエンティティ・オブジェクトを作成します。

エンティティ・オブジェクト属性に対する操作をセキュア化するには:

1. 「アプリケーション」ウィンドウで、保護する属性を定義するエンティティ・オブジェクトをダブルクリックします。
2. 概要エディタで、「属性」ナビゲーション・タブをクリックします。
3. 属性ページで保護する属性を選択し、「セキュリティ」タブをクリックして、update操作を選択します。

   「セキュリティ」タブに、EntityAttributePermissionクラスで定義されるセキュア化可能な操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表47-9に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。

   たとえば、update権限を有効化するには、図47-12に示すように選択します。権限マップが、エンティティ・オブジェクトのXML定義に表示されます。

   図47-12 ADFエンティティ・オブジェクトのupdate操作に対して権限を有効化

   
   「図47-12 ADFエンティティ・オブジェクトのupdate操作に対して権限を有効化」の説明

ADFエンティティ・オブジェクトおよびエンティティ属性に対する権限の付与

権限ターゲットが構成されても、エンティティ・オブジェクトの権限ターゲットに対してポリシー権限が明示的に定義されるまで、エンティティ・オブジェクトあるいはその属性から導出されるデータは、セキュリティ保護されないままです。

既存のエンティティ・オブジェクトまたはエンティティ属性の権限ターゲットに対するアクセス・ポリシーを定義するには、セキュリティ・ポリシーの概要エディタを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。

次のタスクを完了する必要があります。

1. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

2. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

3. 「ADFエンティティ・オブジェクトに対する権限マップの定義」の説明に従って、エンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について権限ターゲットを定義します。

エンティティ・オブジェクトまたはエンティティ属性のアクセス・ポリシーを定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「ADFエンティティ・オブジェクト」または「ADFエンティティ・オブジェクト属性」を選択します。

   概要エディタの「リソース権限」ページに、これまでに権限ターゲットを定義したすべてのエンティティ・オブジェクト(またはエンティティ属性)が表示されます。

3. 「リソース」列で、アクセス権を付与するADFエンティティ・オブジェクトまたはエンティティ属性を選択します。

   初めてADFエンティティ・オブジェクトまたはエンティティ属性に権限付与を行うとき、図47-13に示すように、先頭列のメソッド名の隣には「権限のないリソース」アイコン(ロック・アイコン)が表示されています。エディタに表示されるロック・アイコンは、リソースにセキュリティ・ポリシーが定義されていないためにロックされている(権限を定義するまでユーザーがアクセスできない)ことを示します。

   図47-13 概要エディタでの権限のないエンティティ・オブジェクト

   
   「図47-13 概要エディタでの権限のないエンティティ・オブジェクト」の説明
4. 「ロールに付与済」列で「権限受領者の追加」アイコンをクリックし、「アプリケーション・ロールの追加」を選択します。
5. 「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。

   「アプリケーション・ロールの選択」ダイアログには、jazn-data.xmlファイルのアプリケーション・ロールが表示されます。「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。

   アプリケーション固有のアプリケーション・ロールが表示されていない場合は、「アプリケーション・ロールの作成」の説明に従ってロールを作成します。

6. 「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
7. 概要エディタの「リソース権限」ページの「アクション」列で、特定のアプリケーション・ロールに付与するアクションを選択します。

   エンティティ・オブジェクトに対し、概要エディタではデフォルトでreadアクションが選択されています。表47-8に示すように、対応する権限ターゲットをすでに構成している場合は、updateアクションおよびdeleteアクションを選択できます。

   エンティティ・オブジェクト属性に関しては、表47-9に示す権限ターゲットに対し、概要エディタではデフォルトでupdateアクションが選択されています。エンティティ・オブジェクト属性に対してサポートされる他のアクションはありません。

   図47-14は、エンティティ・オブジェクトのアプリケーション・ロールApplication Employee Roleに付与されるdelete、read、update権限を示しています。

   図47-14 概要エディタでADFエンティティ・オブジェクト権限をアプリケーション・ロールに付与

   
   「図47-14 概要エディタでADFエンティティ・オブジェクト権限をアプリケーション・ロールに付与」の説明
8. このステップを必要なだけ繰り返して、追加の権限を作成します。

   同一のADFエンティティ・オブジェクトまたはエンティティ属性に、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xmlファイルのポリシー・ストア定義に含まれます。

リソース権限を資格付与として集約する方法

リソース権限を作成することで、セキュア化できる個々のOracle ADFアーティファクトに対するエンド・ユーザーのアクセス権を定義します。しかし、管理とメンテナンスを容易にするため、リソース権限を資格付与として定義することもできます。こうすると、セキュア化可能な複数のアプリケーション・アーティファクトが1つの名前付きセキュリティ・グループとして集約され、これを1つの文によってアプリケーション・ロールに付与できます。たとえば、ADFビジネス・コンポーネント・エンティティ・オブジェクトによってアプリケーション内で公開されるデータへのアクセスを認可しようとする場合、複数のエンティティ・オブジェクトに対して同一のセキュリティ・ポリシーが必要になる可能性があります。各エンティティ・オブジェクトに対してアクセス権限を個別に付与するのではなく、これらの権限を1つの資格としてグループ化し、一括して付与できます。

セキュリティ・ポリシーの概要エディタの「資格付与」ページで、資格付与を作成します。作成する権限は、jazn-data.xmlファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、選択したリソース・インスタンスとアクションとのペアで構成される1つの資格(XML定義では<permission-set>として識別されます)を定義します。この資格は付与可能なエンティティであり、アプリケーション・ロールに付与できます。

セキュリティ・ポリシーの概要エディタには、リソース・タイプのリストが表示されます。選択したリソース・タイプにより、アプリケーション・ワークスペースのプロジェクト内で定義されたリソース・インスタンスがフィルタ処理されます。また、選択したリソース・タイプにより、概要エディタに表示される使用可能なアクションのリストが決定されます。たとえば、リソース・タイプタスク・フロー権限を選択した場合、概要エディタには、選択したユーザー・インタフェース・プロジェクト内のすべてのタスク・フローが表示されます。また、viewアクションも表示され、これを使用可能なADFバインド・タスク・フロー・リソースに関連付けることができます。

表47-10は、JDeveloperで表示されるリソース・タイプのリストと、各タイプに対して関連付けられるリソースおよびサポートされるアクションを示します。

表47-10 セキュア化できるOracle ADFアーティファクトのリソース・タイプ

リソース・タイプ	サポートされるリソースおよびアクション
タスク・フロー	選択したユーザー・インタフェース・プロジェクト内のADFバインド・タスク・フローに対してviewアクションを定義します。
Webページ	選択したユーザー・インタフェース・プロジェクト内のADFページ定義ファイルに基づくリージョンおよびWebページに対してviewアクションを定義します。
ADFエンティティ・オブジェクト	選択したデータ・モデル・オブジェクト内のエンティティ・オブジェクトに対してread、updateおよびdeleteアクションを定義します。
ADFエンティティ・オブジェクト属性	選択したデータ・モデル・オブジェクト内の特定のエンティティ・オブジェクトのエンティティ・オブジェクト属性に対してupdateアクションを定義します。

セキュア化できるOracle ADFアーティファクトに対して資格付与を定義するには、セキュリティ・ポリシーの概要エディタの「資格付与」ページを使用します。

始める前に:

エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「リソース権限を資格付与として集約する方法」を参照してください。

次のタスクを完了する必要があります。

• 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

Oracle ADFアーティファクトに対して資格付与を定義するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「資格付与」を選択します。
2. セキュリティ・ポリシー概要エディタの「資格付与」ページで、「資格」セクションの「資格の追加」アイコンをクリックします。

   概要エディタに、アプリケーションで定義されるすべてのリソースが表示されます。

3. 「資格付与」ページで、「リソース」タブをクリックして「メンバー・リソースの追加」アイコンをクリックし、メンバー・リソースを資格に追加します。
4. 「リソースの選択」ダイアログで、「リソース・タイプ」ドロップダウン・リストからリソースを選択して、「ソース・プロジェクト」セクションで必要なプロジェクトを選択します。

   ダイアログに、アプリケーション・ワークスペース内のすべてのプロジェクトが表示されます。

5. 「使用可能なリソース」セクションで、リソースを選択して「追加」アイコンをクリックします。

   ダイアログに、選択したプロジェクトによって定義されたすべてのリソースが表示されます。

6. 「アクション」リストで、選択したリソースに対する目的のアクションを選択します。

   図47-15に示す概要エディタでは、タスク・フローに対してViewアクションが選択され、資格に追加されています。

   図47-15 バインド・タスク・フローを資格内のリソースとして追加

   
   「図47-15 バインド・タスク・フローを資格内のリソースとして追加」の説明
7. 必要なその他のリソースをリストに追加します。
8. 「資格付与」ページで、「付与」タブをクリックして、「ロール付与の追加」アイコンをクリックし、アプリケーション・ロールに資格を付与します。
9. 「アプリケーション・ロールの選択」ダイアログで、1つ以上のカスタム・アプリケーション・ロールを選択します。

   ダイアログに、jazn-data.xmlファイル内のすべてのアプリケーション・ロールが表示されます。事前定義されたアプリケーション・ロール(Oracle Fusionアプリケーションの用語では職務ロールとも呼びます)に権限を追加しないでください。JDeveloperで自分で作成したカスタム・アプリケーション・ロール、またはこの目的でITセキュリティ・マネージャによって作成されたカスタム・アプリケーション・ロールのみを選択してください。

10. 「OK」をクリックします。
11. これらのステップを繰り返して他のリソースを追加し、同一カスタム・アプリケーション・ロールの同一資格に対して、これらのリソースの権限を作成します。

資格作成後の処理

JDeveloperのセキュリティ・ポリシー・エディタを使用して資格を作成すると、JDeveloperはjazn-data.xmlファイル内で、アプリケーション・ポリシー・ストアのソースを修正します。ファイルのポリシー・ストア・セクションには、<resource-type>定義(選択したリソース・タイプに対してサポートされるアクションを識別)、<resource>定義(アプリケーションから選択してリソース・タイプにマッピングしたリソース・インスタンスを識別)、<permission-set>定義(1つの資格として付与されるリソースおよびアクションを定義)、および<grant>定義が含まれ、1つ以上の資格(XML内で権限セットとして定義)が目的のアプリケーション・ロール(権限受領者)に付与されます。

次の例に示すように、Oracle Fusionアプリケーションにおける資格ベースのセキュリティ・ポリシーは、<jazn-policies>要素内で定義され、単一のアプリケーション・ロールに付与される1つ以上の資格によって構成されます。

<?xml version="1.0" ?>
<jazn-data>
  <policy-store>
    <applications>
      <application>
        <name>MyApp</name>
                
      <app-roles>
        <app-role>
          <name>AppRole</name>
          <display-name>AppRole display name</display-name>
          <description>AppRole description</description>
          <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
        </app-role>
      </app-roles>
                
      <role-categories>
        <role-category>
          <name>MyAppRoleCategory</name>
          <display-name>MyAppRoleCategory display name</display-name>
          <description>MyAppRoleCategory description</description>
        </role-category>
      </role-categories>
                
      <!-- resource-specific OPSS permission class definition -->
      <resource-types>
        <resource-type>
          <name>APredefinedResourceType</name>
          <display-name>APredefinedResourceType display name</display-name>
          <description>APredefinedResourceType description</description>
          <provider-name>APredefinedResourceType provider</provider-name>
          <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
          <actions-delimiter>,</actions-delimiter>
          <actions>write,read</actions>
        </resource-type>
      </resource-types>
                
      <resources>
        <resource>
          <name>MyResource</name>
          <display-name>MyResource display name</display-name>
          <description>MyResource description</description>
          <type-name-ref>APredefinedResourceType</type-name-ref>
        </resource>
      </resources>
                
      <!-- entitlement definition -->
      <permission-sets>
        <permission-set>
          <name>MyEntitlement</name>
          <display-name>MyEntitlement display name</display-name>
          <description>MyEntitlement description</description>
          <member-resources>
            <member-resource>
              <type-name-ref>APredefinedResourceType</type-name-ref>
              <resource-name>MyResource</resource-name>
              <actions>write</actions>
            </member-resource>
          </member-resources>
        </permission-set>
      </permission-sets>
                
      <!-- Oracle function security policies -->
      <jazn-policy>
        <!-- function security policy is a grantee and permission set -->
        <grant>
          <!-- application role is the recipient of the privileges -->
          <grantee>
            <principals>
              <principal>
                <class>
                   oracle.security.jps.service.policystore.ApplicationRole
                </class>
                <name>AppRole</name>
                <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
              </principal>
            </principals>
          </grantee>

          <!-- entitlement granted to an application role -->
          <permission-set-refs>
            <permission-set-ref>
              <name>MyEntitlement</name>
            </permission-set-ref>
          </permission-set-refs>
        </grant>
      </jazn-policy>
    </application>
  </applications>
 </policy-store>
</jazn-data>

テスト・ユーザーの作成

テストの目的で、ADFセキュリティではjazn-data.xmlファイルにユーザーを作成することを開発者に許可します。

JDeveloperで提供されるエディタを使用して、アイデンティティ・ストアとポリシー・ストアの両方を作成できます。アプリケーション固有のjazn-data.xmlファイルに両方のリポジトリを作成します。ファイルのアイデンティティ・ストア・セクション用のエディタでは、有効なユーザーIDと割り当てられたパスワードのリストを入力できます。同じエディタを使用して、アプリケーション・ロールを作成し、アプリケーション・ロールのメンバーとしてテスト・ユーザーまたはエンタープライズ・ロールを割り当てることができます。定義されると、この情報はjazn-data.xmlファイルのポリシー・ストア・セクションに表示されます。

JDeveloperでテスト・ユーザーを作成する方法

アプリケーションのアイデンティティ・ストアに一時的なユーザーのセットを生成して、本番環境での実際のユーザーの体験をシミュレートします。統合WebLogic Serverでアプリケーションを実行すると、任意のテスト・ユーザーとしてログインでき、アプリケーションのセキュアADFリソースを表示するアクセス権を与えられます。

アイデンティティ・ストアを使用すると、エンタープライズ・ロールにユーザーをグループ分けすることができます。通常は、JDeveloperのデプロイメント・オプションを構成して、アイデンティティ・ストアをステージング環境に移行しないようにするため、jazn-data.xmlファイルに作成するエンタープライズ・ロールは便宜上のものです。エンタープライズ・ロールの使用方法の詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。

注意:

アイデンティティ・ストアのスタンドアロン・サーバーへのデプロイを選択する場合、Oracle WebLogic Serverに対してすでに構成されているローカル・アイデンティティ・ストアにユーザーとエンタープライズ・ロールを作成しないでください。たとえば、ユーザーweblogicとエンタープライズ・ロールAdministratorsを含むアイデンティティ・ストアをデプロイする場合は、ターゲット・サーバーのデフォルト管理構成を上書きします。Oracle WebLogic Serverによってデフォルトでインストールされるグローバル・ロールの完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・ロール」の章を参照してください。

ユーザーがリソースを表示できるようにするには、そうしたロールのメンバーであるユーザーではなく、アプリケーション・ロールに対して権限を付与します。したがって、アイデンティティ・ストアにテスト・ユーザーを生成した後で、各ユーザーまたはエンタープライズ・ロール・グループをアプリケーション・ロールに関連付ける必要があります。この関連付けにより、ADFセキュリティ・ポリシーによって定義されたアクセス権がユーザーに付与されます。アクセス権のユーザーへの付与の詳細は、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」を参照してください。

Oracle WebLogic Serverに対してすでに構成されているユーザー名を選択しないでください(たとえば、webcenterは入力しないでください)。Oracle WebLogic Serverによりインストールされているユーザー名のリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・ロール」の章を参照してください。

始める前に:

アイデンティティ・ストアについて理解しておくと役立ちます。「テスト・ユーザーの作成」を参照してください。

テスト・ユーザーおよびグループを作成するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「テスト・ユーザーとロール」を選択します。

2. セキュリティ・ポリシーの概要エディタの「テスト・ユーザーとロール」ページで、「レルム」ドロップダウン・リストからアプリケーションのレルムを選択して、次のステップを実行します。

   JDeveloperでは、レルムjazn.comがデフォルトで使用されます。

   1. 「ユーザー」リストで「新規ユーザー」アイコンをクリックします。

   2. 「名前」フィールドにユーザー名を入力します。

   3. 「パスワード」フィールドにユーザーのパスワードを入力します。他の任意のフィールドをクリックすると、パスワードがアイデンティティ・ストアに追加されます。

      パスワードは8文字以上で指定し、特殊文字(!、%、^、&、$など)を少なくとも1つ含める必要があります。

3. 必要に応じて、セキュリティ・ポリシーの概要エディタで、「エンタープライズ・ロール」ナビゲーション・タブをクリックし、アプリケーションのレルムを「レルム」ドロップダウン・リストから選択して、次のステップを実行します。

   ユーザーをグループ分けしてアプリケーション・ロールに追加する場合のみ、エンタープライズ・ロールを作成します。統合WebLogic Serverを使用してアプリケーションを実行するためのテスト・ユーザーを作成する目的であれば、エンタープライズ・ロール・グループを作成する必要はありません。

   1. 「エンタープライズ・ロール」リストで「新規ロール」アイコンをクリックします。

   2. 「名前」フィールドにエンタープライズ・ロール名を入力します。他のいずれかのフィールドをクリックすると、ロールがアイデンティティ・ストアに追加されます。

      エンタープライズ・ロール・グループを作成する場合、Oracle WebLogic Serverに対してすでに構成されているロール名を選択しないでください(たとえば、Administratorsは入力しないでください)。Oracle WebLogic Serverによってインストールされるデフォルト・グループ名の完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループ、セキュリティ・ロール」を参照してください。

テスト・ユーザー作成時の処理

ユーザー・アイデンティティとエンタープライズ・ロール・グループを含むアイデンティティ・ストアをプロビジョニングすると、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルがJDeveloperによって更新されます。

ダイアログによって、アイデンティティ・ストアに対応するファイルの<jazn-realm>セクションにユーザー情報が書き込まれます。各ユーザー・アイデンティティには、ユーザー名とユーザー・ログイン・パスワードが含まれます。各エンタープライズ・ロールには1つ以上のメンバー・ユーザーが含まれます。

次の例は、2つのユーザーと2つのエンタープライズ・ロールを含むjazn-data.xmlファイルのアイデンティティ・ストアを示しています。ユーザーcmageeはEnterprise Employee Groupエンタープライズ・ロールのメンバーで、ユーザー214はEnterprise Customer Groupエンタープライズ・ロールのメンバーです。

<jazn-data>
   <jazn-realm default="jazn.com">
      <realm>
         <name>jazn.com</name>
         <users>
            <user>
               <name>cmagee</name>
               <display-name>Colin Magee</display-name>
               <description>Sales Rep</description>
               <credentials>{903}5AUHlE+qvDxxAhxIMoXJ/WLhMF0ynue7</credentials>
            </user>
            <user>
               <name>214</name>
               <display-name>Ojibway Retail</display-name>
               <description>Customer</description>
               <credentials>{903}rijN2KQCBSeBQ/JNZlv8GwwUiGWk5IQa</credentials>
            </user>
            ...
         </users>
         <roles>
            <role>
               <name>Enterprise Employee Group</name>
               <members>
                  <member>
                     <type>user</type>
                     <name>cmagee</name>
                  </member>
               </members>
            </role>
            <role>
               <name>Enterprise Customer Group</name>
               <members>
                  <member>
                     <type>user</type>
                     <name>214</name>
                  </member>
                  ...
               </members>
            </role>
            ...
         </roles>
      </realm>
      ...
   </jazn-realm>
</jazn-data>

テスト・ユーザーとアプリケーション・ロールを関連付ける方法

ADFセキュリティ・フレームワークは、アプリケーション・ロールに付与された権限を使用するロールベースのアクセス制御メカニズムを施行するため、アプリケーション固有の一連のロールをポリシー・ストアに定義します。たとえば、ワークフローのコンテキストでは、顧客、製品担当、監督者、管理者などのロールを想定できます。

アプリケーション・ロールを作成したら、アイデンティティ・ストアに作成したユーザーに1つ以上のロールを関連付けることができます。アプリケーション・ロールのメンバーであるユーザーには、実行時にアプリケーション・ロールのアクセス権が付与されます。複数のリソース権限を特定のユーザーに付与する場合は、1ユーザーを複数のアプリケーション・ロールに割り当てることができます。

たとえば、認証された1ユーザーがスーパーバイザ・ロールと従業員ロールに所属し、別の1ユーザーは従業員ロールのみに所属する場合があります。顧客レコードのブラウズと編集を許可するバインド・タスク・フローのセキュリティ・ポリシーでは、スーパーバイザ・ロールにview権限が与えられますが、従業員ロールにはブラウズ・ページのview権限に制限されます。このように、アプリケーション・ロールへの権限付与により複数レベルのアクセスに対応します。認証されたユーザーが、ターゲットADFリソースのview権限を持つアプリケーション・ロールのメンバーでない場合は、ユーザーが認証されていないというメッセージがセキュリティ・フレームワークによって返されます。

始める前に:

アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、「テスト・ユーザーの作成」を参照してください。

次のタスクを完了する必要があります。

1. 「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。

2. 「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。

3. 「ADFセキュリティ・ポリシーの定義」の説明に従って、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義します。

4. 「JDeveloperでテスト・ユーザーを作成する方法」の説明に従って、テスト・ユーザーを作成し、必要に応じてエンタープライズ・ロール・グループを作成します。

ユーザーをアプリケーション・ロールに関連付けるには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。

2. セキュリティ・ポリシーの概要エディタの「アプリケーション・ロール」ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。

   JDeveloperによってjazn-data.xmlファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。

3. 「ロール」リストで既存のアプリケーション・ロールを選択し、必要に応じて次のタスクを実行します。

   1. 「マッピング」セクションで、「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「ユーザーの追加」を選択します。次に、「ユーザーの選択」ダイアログで、前に作成したユーザーをリストから選択して「OK」をクリックします。

   2. アイデンティティ・ストアにエンタープライズ・ロールを定義している場合、必要であれば、「マッピング」セクションで「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「エンタープライズ・ロールの追加」を選択します。次に、「エンタープライズ・ロールの選択」ダイアログで、前に作成したエンタープライズ・ロールをリストから選択して「OK」をクリックします。

アプリケーション・ロール構成時の処理

ユーザーにアプリケーション・ロールを関連付けると、Webアプリケーション・ワークスペースを基準とした/src/META-INFノードにあるjazn-data.xmlファイルがJDeveloperによって更新されます。

ダイアログによって、ファイルの<policy-store>セクションにユーザー情報が書き込まれます。各アプリケーション・ロールには1つ以上のメンバー・ユーザーまたはエンタープライズ・ロールが含まれます。

次の例は、Enterprise Employee GroupとEnterprise Manager Groupという2つのメンバーが含まれている、Application Employee Roleアプリケーション・ロールを持つjazn-data.xmlファイル内のポリシー・ストアを示しています。

<policy-store>
     <applications>
         <application>
            <name>SummitADF</name>
            <app-roles>
               <app-role>
                  <name>Application Employee Role</name>
                  <class>oracle.security.jps.service.policystore.ApplicationRole</class>
                  <display-name>Application Employee Role</display-name>
                  <members>
                     <member>
                        <class>oracle.security.jps.internal.core.principals.
                                                               JpsXmlEnterpriseRoleImpl</class>
                        <name>Enterprise Employee Group</name>
                     </member>
                     <member>
                        <class>oracle.security.jps.internal.core.principals.
                                                               JpsXmlEnterpriseRoleImpl</class>
                        <name>Enterprise Manager Group</name>
                     </member>
                     ...
                  </members>
               </app-role>
               ...
            </app-roles>
            <jazn-policy>
              ...
            </jazn-policy>
         </application>
    </applictions>
</policy-store>

ログイン・ページの作成

暗黙の認証と明示的な認証の両方がADFセキュリティでサポートされます。ログイン・リンク、ログイン・ページ、ようこそページを作成でき、その他の様々なアクションを実行できます。

ADFセキュリティでは、暗黙的認証および明示的認証を使用できます。

• 暗黙的な認証のシナリオでは、未認証のユーザーがアクセスしようとするWebページが、anonymous-roleに権限付与されていないADFセキュリティ対応リソースに関連付けられている場合、認証が動的にトリガーされます。ユーザーが正常にログインすると、認証されたユーザーが、リクエストしたページのADFセキュリティ対応リソースに対するviewアクセス権を付与されているかどうかを検証するために別のチェックが実行されます。

• 明示的な認証のシナリオでは、ログイン・リンクが表示された公開ページがアプリケーションに用意され、このリンクをクリックすると、そのユーザーのログインにおいて認証チャレンジがトリガー実行されます。ログイン・リンクには、認証が成功した後に表示するいくつかの他のターゲット・ページ(認証済ユーザーがアクセス権を持っている場合)を指定できます。

「ADF認証に関する必知事項」で説明したように、暗黙的および明示的な認証のシナリオは、ADFセキュリティの構成ウィザードを実行するとデフォルトで処理されます。ただし、デフォルトの生成済ログイン・ページをカスタマイズ(または独自のページを指定)してADF Facesコンポーネントを使用する場合は、コンテナ管理デプロイメント・ディスクリプタ(web.xmlファイル)を構成する必要があります。

ユーザー認証を明示的に処理するには:

1. ログイン・リンク・コンポーネントを作成し、アプリケーションのパブリック・ホームページに追加します。

2. Servlet 3.0固有のAPIを使用して、ユーザーによるログインの試行を処理するマネージドBeanを作成します。

3. ADF Facesコンポーネントを使用して、JSFログイン・ページを作成します。

4. ログイン・ページのリソースがアクセス可能であることを確認します。

暗黙的な認証と明示的な認証の詳細は、「実行時に行われる処理: ADFセキュリティによる認証の処理」を参照してください。

明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法

アプリケーションのどのページにも追加できる標準的なログイン・リンク・コンポーネントを作成して、ユーザーの認証または以降のログオフができます。このコンポーネントは、ユーザーの認証状態を追跡し、適切なログインまたはログアウトのURLおよびアイコンを戻します。このログイン・リンク・コンポーネントは、ユーザーの認証後、ユーザーを特定のページにリダイレクトします。したがって、このログイン・リンク・コンポーネントを使用すると、一貫性のある単一のオブジェクトを得られます。

認証されていないユーザーに対しては、ログイン・リンク・コンポーネントは図47-16のように表示されます。

図47-16 ユーザーがログインする前のコンポーネント

その後、ユーザーがログイン・リンクをクリックして、適切な資格証明を持つユーザーとしてログインすると、コンポーネントは図47-17のようになります。

図47-17 ユーザーがログインした後のコンポーネント

始める前に:

ADF認証について理解しておくと役立ちます。詳細は、「ログイン・ページの作成」を参照してください。

次のタスクを完了する必要があります。

• ログインおよびログアウトのイメージ・ファイル(GIF、JPG、PNGなどのファイル)を、プロジェクトのpublic_htmlディレクトリにコピーします。

ノート:

アプリケーションでスキンを使用する場合は、使用されるイメージは適切なスキン・イメージを参照している必要があります。スキンの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」の章を参照してください。

ログイン・リンク・コンポーネントを作成してページに追加するには:

1. 「アプリケーション」ウィンドウで、コンポーネントを表示するWebページをダブルクリックします。
2. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「共通コンポーネント」パネルからリンクをドラッグして、このページにドロップします。
3. 「構造」ウィンドウで「af:link」を右クリックし、「プロパティに移動」を選択します。
4. 「プロパティ」ウィンドウで、「リンク」コンポーネントのラベルを指定して、「テキスト」フィールドに条件式言語(EL)式を入力します。

   たとえば、次のようなEL式を入力して、リンク・テキストを条件付きでレンダリングできます。

   #{securityContext.authenticated ? "Click to log out" : 
                                     "Click to log in"}
   

   現在のユーザーが認証されると、securityContext Beanのauthenticatedプロパティがtrueに評価され、ログアウト・オプションがレンダリングされます。それ以外の場合はログイン・オプションのリンクがレンダリングされます。

5. 「プロパティ」ウィンドウで、「リンク」コンポーネントのURLを指定して、「宛先」フィールドにEL式を入力します。

   たとえば、次のEL式はユーザーが認証済かどうかに応じて、ユーザーを転送するURLを条件付きでレンダリングします。

   #{securityContext.authenticated ? \"Logout\" : \"Login\"}" id="gl2" destination="#{securityContext.authenticated ? 
                                                  \"/adfAuthentication?logout=true\" : \"/adfAuthentication?login=true\"}
   

   ユーザーがリンクをクリックすると、ADF認証サーブレットのinit-paramのsuccess_urlおよびend_url設定によって宛先が決定されます。これらの設定では、ログイン後のページ・ナビゲーションに制御フロー・ルールが適用されるように、Webページ名ではなくビュー・アクティビティ名を指定する必要があります。現在のユーザーが認証されると、securityContext Beanのauthenticatedプロパティがtrueに評価され、success_urlで定義されているページに転送されます。ユーザーが認証されない場合、ログイン・ページに転送する必要はありません。ADF認証サーブレットでトリガーされるログインは、コンテナ管理セキュリティ構成によって処理されるためです。ログアウトは、セッションを無効にするADF認証サーブレットによって処理されることに注意してください。

6. 「リンク」コンポーネントのリンク・コンポーネント・イメージを指定するには、「プロパティ」ウィンドウで、「アイコン」フィールドにEL式を入力します。

   たとえば、次のEL式は条件に応じて、ユーザーが認証されない場合にリンク・コンポーネント・イメージをロックのGIFとしてレンダリングします。それ以外の場合は、キーのGIFでイメージをレンダリングします。

   #{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}
   

   図47-18に、ログイン・リンク・コンポーネントをグローバル・メニュー・ファセットに追加するとどのように表示されるかを示します。

   図47-18 ページのログイン・リンク・コンポーネント

   
   「図47-18 ページのログイン・リンク・コンポーネント」の説明

明示的な認証用のログイン・ページを作成する方法

「ADFセキュリティの構成」ウィザードを実行して生成されるデフォルトのログイン・フォームは、JDeveloperでアプリケーションをテストする際に利用できるように提供されます。デフォルトのフォームでは、アプリケーションのユーザー・インタフェースに合せて、ADF Facesコンポーネントを使用してページをカスタマイズすることはできません。図47-19に示すように、カスタマイズ可能なコンポーネントを組み込めるADF Facesベースのログイン・ページによって、デフォルトのフォームを置き換えることができます。

図47-19 ログイン・ページ

ただし、ADF Facesコンポーネントを含むログイン・ページの設計が要件でない場合は、単純なJSPまたはHTMLのログイン・ページを使用することもできます。ADFセキュリティの構成ウィザードの実行時に単純なログイン・ページを生成する方法の詳細は、「ADFセキュリティを有効化する方法」を参照してください。

バッキングBeanのログイン・コードの作成

ADF Facesページとしてログイン・ページを作成する前に、ログインの試行を処理するマネージドBeanを作成する必要があります。このログインBeanの例では、Servlet 3.0固有のAPIを使用し、プログラムによって認証が処理されます。ログインBeanは、doLogin()メソッドによって、ログイン・リンクから開始されたログイン・アクションを処理します。ログインが成功すると、このメソッドはサーブレットAPIを起動してランディング・ページにリダイレクトします。このBeanをadfc-config.xmlファイルに追加し、requestスコープで登録します。

ノート:

この項で説明するこのバッキングBeanの例では、Oracle Single Sign-On (Oracle SSO)による認証は行われません。このバッキングBeanは、Servlet 3.0によって提供されるログインおよびログアウト・メソッドを使用して認証を処理しています。Servlet 3.0は、Java EE 6以降をサポートするアプリケーション・サーバー上のプログラムによるログインを汎用的にサポートしています。

始める前に:

ログイン・ページの知識があると役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。

次のタスクを完了する必要があります。

• 「ADFセキュリティの構成」ウィザードを実行し、ADF認証と認可を有効化します。

ログインのためのバッキングBeanを作成して登録するには:

1. 「アプリケーション」ウィンドウで、バッキングBeanを作成するプロジェクトを右クリックし、「新規」、「ギャラリから」の順にクリックします。
2. 「新規ギャラリ」で「一般」を開き、「Java」、「クラス」を選択して「OK」をクリックします。
3. 「Javaクラスの作成」ダイアログで、ログイン・ページのバッキングBeanクラス・ファイルの名前を入力し、デフォルトのオプション「スーパークラスからのコンストラクタ」と「抽象メソッドの実装」を無効にして、「OK」をクリックします。

   たとえば、LoginPageName.javaのように、ログイン・ページ名に基づいてバッキングBeanの名前を付けると便利です。

4. 「アプリケーション」ウィンドウで、「アプリケーション・ソース」を開き、新しいLoginPageName.javaバッキングBeanをダブルクリックします。
5. ソース・エディタで、LoginPageName.javaファイルの宣言セクションに次のコードを追加して2つのprivateフィールドを作成します。

   private String _username;
   private String _password;
   

6. 両方のフィールドのパブリック・アクセッサを生成または作成します。

   ソース・エディタを右クリックして、「アクセッサの生成」を選択すると、次のパブリック・アクセッサがファイルに追加されます。

   public void setUsername(String _username) {
       this._username = _username;
   }
   
   public String getUsername() {
       return _username;
   }
   
   public void setPassword(String _password) {
       this._password = _password;
   }
   
   public String getPassword() {
       return _password;
   }
   

7. 以下のクラスをインポートします。

   javax.faces.application.FacesMessage
   javax.faces.context.ExternalContext
   javax.faces.context.FacesContext
   
   javax.servlet.ServletException
   javax.servlet.http.HttpServletRequest
   javax.servlet.http.HttpSession
   

8. doLogin()メソッドをこのJavaクラスに追加して、ユーザーのログイン試行を処理します。

   1 public String doLogin() {
   2   FacesContext ctx = FacesContext.getCurrentInstance();
   
   3   if (_username == null || _password == null) {
   4      showError("Invalid credentials",
   5                  "An incorrect username or password was specified.", null);
   6   } else {
   7       ExternalContext ectx = ctx.getExternalContext();
   8       HttpServletRequest request = (HttpServletRequest)
   9                                    ctx.getExternalContext().getRequest();
   10      try { 
   11          request.login(_username, _password); // Servlet 3.0 login
   12          _username = null;
   13          _password = null;
   14          HttpSession session = request.getSession();
   15          session.setAttribute("success_url", "/faces" +
   16                                             ctx.getViewRoot().getViewId());
   17          redirect(ectx.getRequestContextPath() + "/adfAuthentication");
   18      } catch (ServletException fle) {
   19          showError("ServletException", "Login failed. 
   20             Please verify the username and password and try again.", null);
   21      }
   22  }
   23  return null;
   24 }
   

   doLogin()メソッドは、次のタスクを実行します。

   行2および行6-9は、ExternalContextからのHTTPリクエストをカプセル化するオブジェクトを取得します。

   行3-5は、資格証明が指定されていない場合のエラーを処理します。showError()メソッドは、ログイン・プロセスに関する多様な問題を処理するために実装するメソッドです。

   行11-13は、Servlet 3.0 API login()メソッドを使用して、リクエストを発行するユーザーのログインを試行します。このプログラムによるログイン例は、Servlet APIに依存しており、Oracle Single Sign-On (Oracle SSO)はサポートされていません。

   行14-16は、HTTPセッションを作成し、ADF認証サーブレット・パラメータsuccess_urlをセッションの属性として設定します。セッションにsuccess_urlを設定すると、宛先ページURLが悪意のアルリダイレクトの影響を受けるリクエスト・パラメーターとして渡されないことが保証されます。この例では、宛先ページはFacesコンテキストから取得された現在のページです。

   ノート: ADFセキュリティ・ウィザードを実行し、このウィザードを使用してログイン・フォームを作成した場合は、ログイン成功時にログイン・ページに戻るのではなく、セッションを保護されているターゲット・ページにリダイレクトする必要があります。この場合、15行目と16行目のsession.setAttributeで属性としてsuccess_urlおよび宛先ページのフル・パス(たとえば、/faces/protectedPage)を取得します。

   行17はメソッドredirect()をコールします。このメソッドは、ADF認証サーブレットが行15で設定されているHTTPセッションから取得するURLにユーザーを転送するためにこの項で後から実装します。

   行18-21はServletExceptionを処理します。これは、ログインにかかわる多様な問題によってスローされます。たとえば、資格証明が正しくない場合、ロックされたアカウントにログインを試行した場合、または期限切れパスワードを使用した場合に例外が生成されます。showError()メソッドは、ログイン・プロセスに関する多様な問題を処理するために実装するメソッドです。

   行23はnullを返して、ADFコントローラが制御フロー・ケースを試行しないようにします。

9. メソッドredirect()およびshowError()のスタブを作成します。
10. アクションを含むredirect()メソッドを追加します。

    1  private void redirect(String forwardUrl) {
    2    FacesContext ctx = FacesContext.getCurrentInstance();
    3    ExternalContext ectx = ctx.getExternalContext();
    4    try {
    5      ectx.redirect(forwardUrl);
    6    } catch (IOException ie) {
    7        showError("IOException", "An error occurred during redirecting. 
    8                        Please consult logs for more information.", ie);
    9    }
    10 }
    

    redirect()メソッドは、次のタスクを実行します。

    行2はADF Faces ctxを取得します。これはレスポンスを特定のURIに転送します。

    行3-5はctxを使用して現在のHTTPレスポンスをURLにリダイレクトします。

    行6 - 8はIOExceptionを処理します。これがスローされるのは、リクエストを読み取ることができないとき、またはレスポンスを書き込むことができないときです。

11. showError()メソッドを実装します。

    private void showError(String errType, String message, Exception e){
      FacesMessage msg =
            new FacesMessage(FacesMessage.SEVERITY_ERROR, errType, message);
      FacesContext.getCurrentInstance().addMessage("d2:it35", msg);
      if (e != null) {
          e.printStackTrace();
      }
    }
    

    このshowError()メソッドは、サマリー・エラー・メッセージをFacesContextに追加し、例外のフル・スタック・トレースをコンソールに出力します。

12. 必要に応じて、タスク・フローのメソッド・コール・アクティビティからプログラムによるログアウトをトリガーする場合は、logoff()メソッドのスタブを作成し、次のように実装します。

    public String logoff() {
      FacesContext ctx = FacesContext.getCurrentInstance();
      ExternalContext ectx = ctx.getExternalContext();
      HttpServletRequest httpRequest = (HttpServletRequest) ectx.getRequest();
      try {
          httpRequest.logout(); // Servlet 3.0 logout
          HttpSession session = httpRequest.getSession(false);
          if (session != null) {
              session.invalidate();
          }
          String logoutUrl = ectx.getRequestContextPath() + "/faces" +
                                ctx.getViewRoot().getViewId();
          redirect(logoutUrl);
      } catch (ServletException e) {
          showError("ServletException", "An error occurred during logout.
                      Please consult logs for more information.", e);
      }
      return null;
    }
    

    このlogoff()メソッドは、Servlet 3.0 APIのlogout()メソッドを使用してログオフ・アクションを処理します。

13. Javaファイルを保存します。
14. 「アプリケーション」ウィンドウで、WEB-INFを開き、adfc-config.xmlをダブルクリックします。
15. エディタ・ウィンドウで、「概要」タブをクリックします。
16. 概要エディタで、「マネージドBean」ナビゲーション・タブをクリックします。
17. 「マネージドBean」ページの「マネージドBean」セクションで、「追加」アイコンをクリックして、Bean名と完全修飾クラス名を入力し、スコープrequestを選択します。

    たとえば、クラス名は図47-20のoracle.summit.bean.LoginBeanのようになります。

    図47-20 adfc-config.xmlファイルに登録されたログインBean

    
    「図47-20 adfc-config.xmlファイルに登録されたログインBean」の説明
18. すべてを保存します。

明示的な認証用のADF Facesベースのログイン・ページの作成

ADF Facesレイアウト・コンポーネントおよびADF Facesユーザー・インタフェース・コンポーネントを利用する単純なログイン・ページには、2つの入力フィールドと1つのボタンが含まれます。これらのUIコンポーネントのプロパティを、ログイン・ページのマネージドBeanに定義したログイン・ハンドラ・メソッドにバインドする必要があります。

この手順で作成できるページでは暗黙的な認証はサポートされないことに注意してください。暗黙的な認証を実装する場合には、コンテナ管理の認証をサポートする、デフォルトのウィザードにより生成されたログイン・フォームをカスタマイズできます。Java EEコンテナでは、ユーザーにより送信されたj_usernameおよびj_password入力を処理するためにj_security_checkメカニズムに依存するフォームを使用します。ここで説明する明示的な認証シナリオでは、Java EEコンテナ管理の認証は使用しません。

始める前に:

明示的認証について理解しておくと役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。

次のタスクを完了する必要があります。

• 「バッキングBeanのログイン・コードの作成」の説明に従って、ユーザーのログイン試行を処理するマネージドBeanを作成します。

明示的な認証用のADF Facesベースのログイン・ページを作成するには:

1. 「アプリケーション」ウィンドウで、ログイン・ページを作成するプロジェクトを右クリックし、「新規」、「新規ギャラリ」の順にクリックします。

2. 「新規ギャラリ」で「Web層」を開き、「JSF」、「ページ」の順に選択し、「OK」をクリックします。

3. 「JSFページの作成」ダイアログで、「JSP XML」を選択します。

4. 「ファイル名」フィールドで、ログイン・ページの名前を指定します。たとえば、LoginPage.jspxを入力します。

   他のオプションは選択しません。また、マネージドBeanでUIコンポーネントを公開するオプションは選択しないでください。ログイン・ページのために作成したマネージドBeanにコンポーネントを手動でバインドします。

5. 「OK」をクリックします。

6. ページを保存します。

7. 「コンポーネント」ウィンドウの「ADF Faces」ページで、「レイアウト」パネルから「パネル・ボックス」をドラッグし、「構造」ウィンドウの「af:form」ノードの下にドロップします。

8. 「プロパティ」ウィンドウで、「テキスト」、「水平」、「幅」、「高さ」フィールドに値を入力します。

   たとえば、基本的なログイン・ページを作成するには、次のように入力します。

   「テキスト」にLogin Informationを設定します。

   「アイコン」に/images/key_ena.pngを設定します。

   「幅」および「高さ」に300および200ピクセルを設定します。

9. 「コンポーネント」ウィンドウから「パネル・フォーム・レイアウト」をドラッグして、「構造」ウィンドウの「af:panelBox」ノードの下にドロップします(図47-21)。

   図47-21 パネル・フォーム・レイアウトのログイン・ページ構造

   
   「図47-21 パネル・フォーム・レイアウトのログイン・ページ構造」の説明

10. 「共通コンポーネント」ウィンドウから、ユーザー名フィールド用に「入力テキスト」をドラッグして「パネル・フォーム・レイアウト」ノードにドロップし、パスワード・フィールド用にもう1つの「入力テキスト」をドラッグ・アンド・ドロップします。

11. 入力フィールドの「プロパティ」ウィンドウで、「ラベル」フィールドにUsernameとPasswordを入力し、「動作」セクションを開き、両方のフィールドの「必須」ドロップダウン・リストから「true」を選択します。

12. 「プロパティ」ウィンドウで、パスワード・フィールド用に、「外観」セクションを開き、「機密」ドロップダウン・リストから「true」を選択します。

13. 2つの入力フィールドの値を処理するために、各フィールドで次のステップを実行します。

    1. 「構造」ウィンドウで、入力フィールドの1つを選択し(たとえば「af:inputText - Username」ノードを選択)、「プロパティ」ウィンドウで「値」フィールドの横にある「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。

    2. 「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、Beanのハンドラ・メソッドに対応する式の値を選択します。

       たとえば、「構造」ウィンドウでusername入力フィールドを選択した場合は、図47-22のように「式ビルダー」ダイアログでusernameを選択します。

       図47-22 「式ビルダー」ダイアログでのusernameの選択

       
       「図47-22 「式ビルダー」ダイアログでのusernameの選択」の説明

    3. 「OK」をクリックします。

       「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにフィールドがバインドされます。たとえば、username入力フィールドの場合、式は#{loginPageBean.username}のようになります(図47-23)。

       図47-23 「プロパティ」ウィンドウでのusernameの値

       
       「図47-23 「プロパティ」ウィンドウでのusernameの値」の説明

14. 「コンポーネント」ウィンドウで、「レイアウト」パネルから「パネル枠線レイアウト」をドラッグして、af:panelBoxノードのfooterノードの内側にドロップします(図47-24)。

    図47-24 ログイン・ページ構造とパネル枠線レイアウト

    
    「図47-24 ログイン・ページ構造とパネル枠線レイアウト」の説明

15. JSP/HTMLビジュアル・エディタで、ラベルが「端」、「上」および「下」のパネル枠線レイアウト・ファセットを削除します。「開始」ファセットのみを残します。

16. 「構造」ウィンドウで、「パネル枠線レイアウト」ファセットを開いて、「開始」ノードを選択し、「コンポーネント」ウィンドウから「ボタン」をドラッグ・アンド・ドロップします。

17. 「プロパティ」ウィンドウで、ボタン・コンポーネントの「テキスト」フィールドにLoginを入力します。

18. ログイン・ボタンのアクションを処理するには、次のステップを実行します。

    1. 「構造」ウィンドウで「開始」ノードにある「af:button」を選択し、「プロパティ」ウィンドウで「アクション」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。

    2. 「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、ログイン・メソッドに対応する式の値を選択します。

       たとえば、ログインBeanにdoLogin()という名前のメソッドを作成した場合は、「式ビルダー」ダイアログでdoLoginを選択します。

    3. 「OK」をクリックします。

       「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにボタンがバインドされます。たとえば、ログイン・ボタンの場合、式は#{loginPageBean.doLogin}のようになります(図47-25)。

       図47-25 「プロパティ」ウィンドウでのログインのアクション

       
       「図47-25 「プロパティ」ウィンドウでのログインのアクション」の説明

19. ページを保存します。

ログイン・ページのパブリック化の確認

アプリケーションはADFセキュリティによって保護されるため、デフォルトでは、バインド・タスク・フローに定義されたすべてのWebページ、およびADFページ定義によって定義されたすべてのWebページにはアクセスできません。すべてのユーザーがログオンできるようにする必要があるため、ログイン・ページは公開する必要があります。このため、ログイン・ページにはデータバインド・コンポーネントを追加しないでください。ログイン・ページでデータバインド・コンポーネントが使用されないかぎり、このページにはデフォルトでアクセスできます。

コンテナがページ(この場合は認証ページ)へのアクセスを許可する前に、定義済の認証ポイントに常にリダイレクトすることを保証するには、これ以上のステップは必要ありません。

カスタム・ログイン・ページのリソースを明示的な認証時にアクセス可能にする方法

「ADFセキュリティの構成」ウィザードを実行して、「ADF認証」オプションを選択したとき(ADF認可を有効にしない)、アプリケーションがカスタム・ログイン・ページまたはカスタム・エラー・ページを使用していると、場合によってはADFセキュリティでweb.xmlファイルに追加されたデフォルトのJava EEセキュリティ制約を編集する必要があります。次の例に示すように、allPagesセキュリティ制約に定義されるデフォルトのURLパターン(/*)は、Java EEアプリケーション・ルートの下位項目すべてに対応し、ログイン・ページに使用される各リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)もこれに含まれます。

<security-constraint>
   <web-resource-collection>
      <web-resource-name>allPages</web-resource-name>
      <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
      <role-name>valid-users</role-name>
   </auth-constraint>
</security-constraint>

作成するページがリソース(イメージ、CSSファイルまたはJavaScriptライブラリなど)を使用する場合、web.xmlファイルのデフォルトのallPagesセキュリティ制約により、そのようなリソースが実行時にロードされなくなります。アプリケーションでそれらのリソースを表示するためには、リソースを独自のフォルダに保存し、そのリソース・フォルダがURLパターンに含まれないようにallPagesセキュリティ制約を編集する必要があります。

「ADFセキュリティの構成」ウィザードを実行して、「ADF認証および認可」オプション(デフォルト)を選択した場合は、このようなリソースの問題が生じないことに注意してください。特に、この場合にデフォルトで生成される制約がADF認証サーブレットに対応し、制約(/adfAuthentication)によってすべてのリソース・ファイルが除外されます。

パブリックなようこそページの作成方法

Webアプリケーションは通常は保護されているため、認証されていないユーザーのための開始地点すなわちホームページが必要になります。このようなパブリックなようこそページを作成するには、アプリケーション内の他のページへのリンクを含み、アプリケーションの開始地点として機能するADF Facesページを作成します。ただし、認証されていないユーザーに対してはパブリック・ページへのリンクしかレンダリングできません。反対に、セキュア・ページへのリンクをレンダリングするのは、ユーザーがログインし、ターゲット・ページを表示する適切な権限を持っている場合のみです。

ベスト・プラクティス:

ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して、新しいブラウザ・ウィンドウまたはタブを開いたとき、アプリケーションのweb.xmlファイルにようこそページが定義されていないと、ブラウザに403エラーまたは404エラーが表示されます。このエラーを防ぐためには、ようこそページの定義をアプリケーションのweb.xmlファイルに指定する必要があります。この定義は、「ADFセキュリティの構成」ウィザードを実行して作成できます。このウィザードの実行方法の詳細は、「ADFセキュリティを有効化する方法」を参照してください。

ようこそページのパブリック化の確認

標準のADF Facesページを作成すると、ページはデフォルトでパブリックになり、認証されていないユーザーがアクセスできます。ただし、ようこそページをADFリソースに関連付けた場合(「データ・コントロール」パネルを使用してデータバインドADF Facesコンポーネントをようこそページにドラッグ・アンド・ドロップするなど)、ADFセキュリティによってデフォルトでページが保護されます。セキュリティ・ポリシーの概要エディタを使用して、提供されているanonymous-roleにADFリソースのview権限を付与すると、任意のADFリソースを公開できます。anonymous-roleの詳細は、「ADFリソースの公開時の処理」を参照してください。

ログイン・リンクおよびログアウト・リンクの追加

ログイン・リンクやログアウト・リンクをパブリックのようこそページに追加して、ログインやアプリケーション使用中のログアウトをユーザーが明示的に行えるようにします。Java EEコンテナ管理セキュリティでは、保護されているリソースにアクセスする際に認証の概念がサポートされますが、ログアウトした後も保護されたアプリケーションにとどまる標準の方法はありません。ただし、一般的なWebアプリケーションの場合、ページがパブリックであれば、ユーザーは同じページにとどまります。あるいは、ページが保護されている場合はようこそページが再び表示されます。各ページにログイン・リンクとログアウト・リンクを追加すると、ユーザーがアプリケーション内の任意の場所でログイン・セッションを終了できます(ようこそページに戻る)。また、ようこそページにこれらのリンクがあると、ユーザーがアプリケーションを開始するときに明示的に認証されます。

たとえば、3つのコンポーネント(出力テキスト領域、イメージ、ログイン/ログアウト・リンク)を含むADF Facesパネル・グループを作成できます。適切なログイン・リンクまたはログアウト・リンクをレンダリングするために、ユーザーの認証ステータスを評価するEL式を使用できます。特に、securityContext.authenticatedを使用すると、次の例に示すようにADFセキュリティ・コンテキストにアクセスできます。この式はtrueまたはfalseとして評価され、この例では、結果によって、表示するログイン・イメージまたはログアウト・イメージとリンクが決まります。次の例に示すように、リンクはセキュリティBeanのlogonおよびlogoffメソッドをトリガーします。

<af:panelGroupLayout inlineStyle="width:100%; height:15px;" id="ptpgl3">
     <af:spacer width="7" height="10" id="pts2"/>
     <af:outputText value="Welcome #{securityContext.userName}!"
                           inlineStyle="font-weight:bold; width:100px" id="ptot2"
                           rendered="#{securityContext.authenticated}"/>
     <af:image source="#{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}"
               id="pti2" inlineStyle="width:16px; height:16px;" shortDesc="switchable icon"/>
     <af:link text="Logon" id="l1" action="#{securityBean.logon}"
                rendered="#{!securityContext.authenticated}"/>
     <af:link text="Logoff" id="l2" action="#{securityBean.logoff}"
                rendered="#{securityContext.authenticated}"/>
     <f:facet name="separator">
         <af:spacer width="5" height="10" id="pts1"/>
     </f:facet>
</af:panelGroupLayout>

logonおよびlogoffメソッドを実装するセキュリティBeanでは、ADF AuthenticationService APIを使用してアプリケーションを悪意のあるリダイレクトから保護できます。これにより、web.xmlファイルにsuccess_urlおよびend_urlパラメータをnullとしてホワイトリスト登録してADF認証サーブレットを起動する場合と同じレベルの保護が実現されますが、これはタスク・フローによるナビゲーションの処理に代わるベスト・プラクティスとみなされます。リダイレクトの詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。

ページ内にリンクを直接レンダリングするかわりに、「明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法」で説明するように、ログイン・リンクとログアウト・リンクを含むログイン・リンク・コンポーネントを作成して、ページ・テンプレートに追加できます。

セキュアなページへのリンクの非表示化

セキュリティ保護されたページに無名ユーザーがアクセスできないように、ようこそページ上のセキュリティ保護されたページをポイントするナビゲーション・コンポーネントを、次の2つの基準に基づいてビューから非表示にする必要があります。

• ユーザーが既知のユーザー・アイデンティティで認証されているか

• 指定されたユーザー・アイデンティティがターゲットの表示権限を持っているか

これらの条件の一方が満たされない場合、パブリック・ページ上でセキュリティ保護されたリソースをポイントするすべてのナビゲーション・コンポーネントは、そのrendered属性をfalseに設定して、無名ユーザーに対して非表示にする必要があります。ようこそページでこのような規則を施行するには、「ADFセキュリティでの式言語(EL)の使用」を参照してください。

認証後にユーザーをリダイレクトする方法

暗黙的な認証を実装することを選択した場合は、ユーザーが保護されたWebページにアクセスしてログインした後、ADF認証サーブレットは、ログイン・リクエストが発行された最初のページにユーザーをリダイレクトします。ADFセキュリティ認証が有効な場合、ADFは、ADF認証のsuccess_urlパラメータとして元のページをセッション・マップで自動的に渡します。通常、これは必要な動作です。

また、暗黙の認証を実装することを選択した場合、web.xmlファイル内でsuccess_urlパラメータをinit-param要素として指定することにより、Fusion Webアプリケーションを悪意のあるリダイレクトから保護できます。ただし、ADF認証サーブレットによって元のページがsuccess_urlパラメータとして自動的に渡され、web.xmlの設定よりも優先されるため、web.xmlのinit-param設定が有効になるのは、ユーザーがadfAuthentication URLをブラウザに明示的に入力する場合のみです。

一方、明示的な認証を実装し、ページに明示的なログイン・リンクを表示することを選択した場合、ADFセキュリティ・フレームワークは元のページを判別できません。この場合、ログイン・リンクは、認証後、目的のページへのリダイレクトがADF認証サーブレットによって確実に行われるように、次の例に示すように、Webページのビュー・アクティビティ名をサーブレットのsuccess_urlパラメータとして渡します。

<af:link text="Login" destination="/adfAuthentication?success_url=/faces/viewactivityname"/>

ベスト・プラクティス:

明示的な認証で、Fusion WebアプリケーションがADF認証リダイレクトをADFコントローラのナビゲーション・イベントとして処理するようにするには、リダイレクト・ターゲットをビュー・アクティビティ名で指定します。リダイレクト・ターゲットとしてビュー・アクティビティを指定しない場合、特にaf:buttonコンポーネントなどのコマンド・コンポーネントは、ログイン後に必ず元のページに戻ることになります。リダイレクト・ターゲットを表すADF認証サーブレットのパラメータsuccess_urlおよびend_urlとしてビュー・アクティビティ名を渡すことで、アプリケーションではすべての場合において、制御フロー・ルールを使用してナビゲーションが処理されるようになります。

明示的な認証では、タスク・フロー・ビュー・アクティビティ名でsuccess_urlを定義するベスト・プラクティスに従うと、ユーザーがブラウザに入力を試みるadfAuthentication URLをADF認証サーブレットが無視するようにすることで、Fusion Webアプリケーションが悪意のアルリダイレクトから保護されます。または、タスク・フロー・アクティビティが不便な場合は、アプリケーションでAuthenticationService APIを使用して、リダイレクトを安全な方法で処理するログインおよびログアウト・メソッドを実装できます。セキュリティBeanでAPIを使用する方法の詳細は、「異なるホスト・サーバーへのリダイレクトに関する必知事項」を参照してください。

ユーザーが認証されたが、Webページの表示を認可されない場合は、ADF認証サーブレットをアプリケーションのエラー・ページにリダイレクトできます。タスク・フローを使用しない設計のアプリケーションを作成した場合を除いて、Fusion Webアプリケーションのエラー処理は、ADFコントローラの例外ハンドラで制御されます。たとえば、ADFページ定義で保護された、トップレベルのようこそページと1つのブラウズ・ページを含むバインドなしタスク・フローを定義した場合、次の例に示すようにアプリケーションのエラー・ページ(adfc-config.xmlファイルに指定されたauthorizationErrorPage.jspx)が表示されます。

<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2">
  <exception-handler>authorizationErrorPage</exception-handler>
  <view id="welcomePage">
    <page>/welcomePage.jspx</page>
  </view>
  <view id="browse">
    <page>/browse.jspx</page>
  </view>
  <view id="authorizationErrorPage">
    <page>/authorizationErrorPage.jspx</page>
  </view>
  <control-flow-rule>
    <from-activity-id>welcomePage</from-activity-id>
    <control-flow-case>
      <from-outcome>goToSecuredPage</from-outcome>
      <to-activity-id>browse</to-activity-id>
    </control-flow-case>
  </control-flow-rule>
</adfc-config>

ADFコントローラ例外ハンドラのビュー・アクティビティとしてエラー・ページを指定する方法の詳細は、「タスク・フローでの例外の処理」を参照してください。

ユーザーが認証されず、認可の失敗が発生した場合は、フレームワークがADF認証サーブレットにリダイレクトし、ADF認証サーブレットがログインを求めるJava EE制約をトリガーします。この場合、コンテナ管理セキュリティは、web.xmlファイルの<login-config>要素に指定されているログイン・ページとエラー・ページを利用します。

タスク・フローを使用せずにFusion Webアプリケーションを作成する場合、次の例に示すようにADFバインディング・フィルタのための<init-param>設定をweb.xmlに指定できます。アプリケーションにタスク・フローがないこのケースでは、ページ認可チェックがADFバインディング・フィルタによって処理され、unauthorizedErrorPageパラメータがADFバインディング・リクエスト・ハンドラに渡されます。

ノート:

unauthorizedErrorPageパラメータの機能は、ADFコントローラが使用できない以前のリリースとの互換性のために用意されています。Fusion Webアプリケーションでは、ユーザーをエラー・ページにリダイレクトする必要があるときは、前述の例のようにタスク・フロー例外ハンドラを使用してエラー・ページを指定します。

<filter>
    <filter-name>adfBindings</filter-name>
    <filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class>
    <init-param>
        <param-name>unauthorizedErrorPage</param-name>
        <param-value>faces/authorizationErrorPage.jspx</param-value>
    </init-param>
</filter>

暗黙的な認証用のカスタム・ログイン・ページをトリガーする方法

ユーザーが保護対象のリソースにアクセスできるように(直接URLアクセスまたはADFセキュリティの保護対象リソースへの移動により)暗黙的な認証を実装することを選択すると、ADFセキュリティ認証サーブレットがJava EEコンテナを開始し、web.xmlファイルで構成されているログイン・フォームを表示します。暗黙的な認証では、ADF Facesコンポーネントを使用するようにデフォルトのウィザードにより生成されたログイン・フォームをカスタマイズしている場合は、ADF Facesサーブレットを参照するようにサーブレット・マッピングに対するURLパターンを変更する必要があります。

「ADFセキュリティの構成」ウィザードの「認証タイプ」ページでこのように設定できます。あるいは、web.xmlファイルで直接行うことができます。すでに「ADFセキュリティの構成」ウィザードを実行している場合は、次の手順に従って、説明したようにweb.xmlファイルが更新されていることを確認できます。

明示的な認証を実装することを選択し、ユーザーが保護対象のリソースにアクセスするためにログインできるようにパブリック・ページを作成した場合は、作成するログイン・フォームはADFセキュリティによりトリガーされません。明示的な認証シナリオでは、web.xmlファイルを構成する必要はありません。

ノート:

「明示的な認証用のADF Facesベースのログイン・ページの作成」で説明しているとおりに、アプリケーションで明示的な認証をプログラム的に実装する際にログイン・ページ・アプリケーション・パスでweb.xmlファイルを構成すると、予期しない結果が発生し、ログインが失敗することがあります。web.xmlファイルは、暗黙的な認証を実装しており、デフォルトのウィザードにより生成されたログイン・フォームのようにj_security_checkアクションに依存するフォームを作成した場合にのみ変更してください。

始める前に:

ログイン・ページの知識があると役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。

暗黙的な認証用のADF Facesログイン・ページを参照するには:

1. 「アプリケーション」ウィンドウで、WEB-INFを開き、web.xmlをダブルクリックします。
2. web.xmlファイルの概要エディタで、「セキュリティ」ナビゲーション・タブをクリックします。
3. 「セキュリティ」ページで「ログイン認証」セクションを開き、ADF Facesサーブレットへの参照を含むようにログイン・ページを設定します。こうすることで、ログイン・ページがADF Facesライフサイクル/faces/ADFlogin.jspxページの一部になります。

   ファイル・ブラウザを使用してページを追加すると、web.xmlファイルに入力されるパスに/facesが指定されません。ADF Facesサーブレットのサーブレット・マッピング・パスを参照するようにパスのエントリを変更します。たとえば、マッピングで指定されるURLパターンが/faces/*の場合、パスを/faces/yourpage.jspxとする必要があります(図47-26)。

   図47-26 ログイン構成でのFacesサーブレットに対する参照の追加

   
   「図47-26 ログイン構成でのFacesサーブレットへの参照の追加」の説明

リダイレクト宛先ページを確実に使用可能にする方法

ADF認証サーブレットはユーザーにログインを求めるときに、success_urlで定義されているリダイレクト宛先をセッション・マップに配置します。ただし、ユーザーが認証される前にセッションがタイムアウトした場合、セッション・マップはsuccess_urlの値を失い、アプリケーションは宛先ページに移動できなくなります。

ログイン・リダイレクト宛先をアプリケーションが確実に常に使用できるようにするには、success_urlパラメータをタスク・フローのナビゲーション結果ルールとして定義するか、ADFセキュリティの構成ウィザードを実行するときにweb.xmlファイルに追加される、ホワイトリスト登録された1つのページとして静的に定義します。

web.xmlファイルはデプロイメント前に定義する必要があるため、Fusion Webアプリケーションでは、接続参照値の定義を伴うリダイレクトURLのsuccess_urlパラメータを構成する別の動的なアプローチがサポートされています。これらの値は、connections.xmlファイルで直接構成することもできます。

connections.xmlファイルをADF認証サーブレットのリダイレクト宛先の永続ストアとして使用するには:

1. 次の例に示すように、web.xmlファイルで、oracle.adf.share.security.authentication.connectionsという名前のinit-paramをADF認証サーブレットの定義に追加し、adf/META-INFフォルダにあるconnections.xmlファイルに出現する接続参照名としてparam_valueを指定します。

   <servlet>
     <servlet-name>adfAuthentication</servlet-name>
       <servlet-class>
         oracle.adf.share.security.authentication.AuthenticationServlet
       </servlet-class>
       <init-param>
         <param-name>
           oracle.adf.share.security.authentication.connections
         </param-name>
         <param-value>my_connection_name</param-value>
       </init-param>
      ...
   </servlet>

2. 次の例に示すように、connections.xmlファイルで、success_urlを定義し、必要に応じてend_urlを名前付き接続参照内で定義します。

   <References xmlns="http://xmlns.oracle.com/adf/jndi">
     <Reference name="my_connection_name"
                className=
               "oracle.adf.share.security.authentication.AuthenticationConnection"
                xmlns="">
       <Factory className=
            "oracle.adf.share.security.authentication.AuthenticationConnection"/>
       <RefAddresses>
         <StringRefAddr addrType="success_url">
           <Contents>
              http://localhost:port/context_root/faces/welcomePage</Contents>
         </StringRefAddr>
         <!-- end_url for logout -->
         <StringRefAddr addrType="end_url">
           <Contents>
              http://localhost:port/context_root/faces/publicPage</Contents>
         </StringRefAddr>
       </RefAddresses>
     </Reference>
   </References>

アプリケーションを現在のリクエスト・ホスト、ポートおよびコンテキスト・ルートにリダイレクトする場合は、宛先URLでホスト名、ポート番号およびコンテキスト・ルートを省略できます。この場合、URLは/faces/pagenameとして指定され、/facesはADF Facesのコンテキストでページをロードし、ADF Facesコンポーネントを使用するように設計されたページをサポートします。

実行時にリダイレクトURLがセッション・マップ上にない場合、ADF認証サーブレットはoracle.adf.share.security.authentication.connectionsという名前のinit-paramから接続名を取得してconnections.xmlファイルから接続を参照します。名前付きの接続がない場合、またはsuccess_url (ログイン)やend_url (ログアウト)がconnections.xmlにない場合は、success_urlまたはend_urlがweb.xmlに定義されていないかどうかADF認証サーブレットによってチェックされます。

異なるホスト・サーバーへのリダイレクトに関する必知事項

ログアウト時に、Fusion Webアプリケーションの開始サーバーとは異なる任意のWebページまたはホスト・サーバーにユーザーをリダイレクトすることが必要な場合があります。このシナリオでは、宛先ページのURLがリクエスト時にアプリケーションによって配置されないようにすることで、アプリケーションを悪意のあるリダイレクトから保護する必要があり、かわりにセッション・マップを使用します。これを実現するために、次の例に示すように、サーブレットのinit-param要素disable_url_paramをtrueに設定してweb.xmlファイルのADF認証サーブレット定義に追加することで、ADFリダイレクト・パラメータがブラウザURLで渡されないようにすることをお薦めします。

<servlet>
   <servlet-name>adfAuthentication</servlet-name>
   <servlet-class>
        oracle.adf.share.security.authentication.AuthenticationServlet
   </servlet-class>
   <init-param>
      <param-name>success_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>end_url</param-name>
      <param-value>faces/welcome</param-value>
   </init-param>
   <init-param>
      <param-name>disable_url_param</param-name>
      <param-value>true</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
...

セッション・マップでリダイレクト・パラメータを渡すこと(そうしなければブラウザURLリクエストでパラメータが公開される)をADFによって強制される前に構築されたレガシー・アプリケーションでは、disable_url_paramをtrueに設定せず、かわりにターゲットの宛先をセッション・マップに配置することで、ADFインタフェースoracle.adf.share.security.AuthenticationServiceを使用してADF固有のログインおよびログアウト・メソッドを処理するセキュリティBeanを実装することを検討してください。

次の例は、AuthenticationServiceインタフェースのlogout()メソッドの使用方法を示しています。このメソッドは、渡されたURLをセッション・マップに内部的に挿入し、ユーザーによってURLに明示的に設定される可能性のあるend_urlパラメータを無視します。同様にlogin()メソッドはセッション・マップにログインURLの宛先を配置します。異なるサーバー上のWebページにリダイレクトするためにログアウトが必要な場合、メソッド実装では、目的のWebページのURLを渡し、悪意のあるリダイレクトから引き続き保護できます。

import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import oracle.adf.share.security.AuthenticationService;
import oracle.adf.share.security.authentication.AuthenticationServiceUtil;

public class SecurityBean {
    public SecurityBean() {
        super();
    }
    
    public boolean isAuthenticated() {
        ExternalContext ectx =
                          FacesContext.getCurrentInstance().getExternalContext();
        return ectx.getUserPrincipal() != null;
    }
    
    public void logon() {
        if (!isAuthenticated())
        {
            FacesContext ctx = FacesContext.getCurrentInstance();
            AuthenticationServiceUtil.getAuthenticationService().login("/faces" +
                                       ctx.getViewRoot().getViewId(), null, null);
        }    
    }
    
    public void logoff() {   
        if (isAuthenticated())
        {
            AuthenticationServiceUtil.getAuthenticationService().
                                                 logout("/faces/index", null);
        }    
    }
}

プログラムによるアプローチの代替では、null値のsuccess_urlおよびend_urlパラメータを持つ明示的なリンクでADF認証サーブレットを呼び出すことで、セッション・マップへの宛先URLの配置を処理します。この場合、ADF認証サーブレットは、web.xmlファイル(またはconnections.xmlファイル)からリダイレクト値を取得しようとし、ユーザーがURLに入力しようとする値を無視します。このアプローチでは、success_urlおよびend_urlパラメータにinit-param要素を指定することで、web.xmlにADF認証サーブレット定義を構成する必要があります。その結果、これはログインおよびログアウト・リダイレクトに単一の宛先があるホワイトリストを生成する宣言的なアプローチになります。

Fusion Webアプリケーション・ログアウトおよびブラウザ・キャッシュに関する必知事項

Fusion Webアプリケーションのweb.xmlファイルの指定に基づいてBasic認証が有効な場合、ブラウザは認証資格証明をキャッシュします。これは、ADF認証サーブレットによるログアウト・リダイレクトの実行後に、Basic認証によってユーザーを再認証する場合の既知の問題です。このシナリオでは、ログアウト・セッションを完了し、ユーザーによるリソースへのアクセスを防ぐために、ブラウザを終了し、新しいブラウザ・セッションを再開する必要があります。

ADFアプリケーションがログアウトを完了し、ユーザーがログアウト後にリソースにアクセスできないようにするには、基本認証ではなくフォームベースの認証を使用します。「ADFセキュリティを有効化する方法」で説明するように、ADFセキュリティの構成ウィザードを実行してフォームベース認証を選択できます。

Internet Explorerでのエラー・ページの表示に関する必知事項

ADFセキュリティを有効化してカスタム・エラー・ページを表示する場合、ページ表示のリクエストに応じてアプリケーションがHTTPエラーを生成すると、エラー・ページが表示されます。ただし、特定のバージョンのInternet Explorerでは、ブラウザに、カスタム・エラー・ページか、Internet Explorerに組み込まれているエラー・メッセージのどちらかが表示されます。Internet Explorerにエラー・メッセージのみが表示される場合は、「インターネット オプション」ダイアログの「詳細設定」で、エラー・メッセージ番号を表示するオプションを無効にできます。Internet Explorer 10では、このオプションはデフォルトで有効になっています。「ADFセキュリティの構成」ウィザードで有効化したカスタム・エラー・メッセージを表示するには、「HTTPエラーメッセージを簡易表示する」を無効にする必要があります。

Internet Explorer 10でカスタム・エラー・メッセージを表示するには:

1. Internet Explorerのツールバーで、「ツール」ボタンをクリックします。

2. 「インターネット オプション」ダイアログで、「詳細設定」タブをクリックします。

3. 「詳細設定」タブで、スクロールして「HTTPエラーメッセージを簡易表示する」を探します。

4. このオプションをクリックして無効化し、「OK」をクリックします。

JDeveloperでのセキュリティのテスト

ADFセキュリティをテストするために、JDeveloperで、統合WebLogic Serverを使用してアプリケーションを実行し、アプリケーションで定義されたセキュリティ・オブジェクトを移行するかどうかを決定します。

統合WebLogic Serverにより、アプリケーションを直接JDeveloper内部で実行して、アプリケーションで定義するアプリケーション・ポリシー、ユーザーおよび資格証明などのセキュリティ・オブジェクトを移行するかどうかを決定できます。デフォルトでは、アプリケーションを実行するたびにすべてのセキュリティ・オブジェクトが統合WebLogic Serverに移行されます。

セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法

JDeveloperはデフォルトで、アプリケーションを実行するたびにアプリケーション・リポジトリから統合WebLogic Serverにセキュリティ・オブジェクトをデプロイするよう構成されています。この動作は、「アプリケーション・プロパティ」ダイアログでのセキュリティ・デプロイメント・オプションの選択により、次のように変更できます。

• ドメインレベル・ポリシーをアプリケーションのjazn-data.xmlファイル内のポリシーにより上書きするかどうかを決定します。

• システム資格証明をアプリケーションのcwallet.ssoファイルにより上書きするかどうかを決定します。

  cwallet.ssoファイル(JDeveloperの「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノード)には、安全に保持されるオブジェクトとして資格証明が格納されます。この資格証明はアイデンティティと照合するために認証プロバイダに渡されます。このファイルは暗号化されているため、JDeveloper内では参照も編集もできません。設計時に各種コンポーネントでcwallet.ssoファイルを使用し、そのファイル内に必要な資格証明を作成します。

• jazn-data.xmlファイルのアイデンティティ・ストアの一部をドメインレベル・アイデンティティ・ストアに移行するかどうかを決定します。

デプロイ設定を変更しない場合、アプリケーションを実行するたびに、JDeveloperはドメイン・レベルのセキュリティ・ポリシーおよびシステム資格証明を上書きします。また、テスト目的で作成した新しいユーザー・アイデンティティを移行し、統合WebLogic Serverがそのアイデンティティ・ストアで使用する埋込みLDAPサーバー内の既存のユーザー・パスワードを更新します。しかし、統合WebLogic Server内の既存のセキュリティ・オブジェクトを更新せずにアプリケーションを実行する場合には、このオプションを選択できます。

始める前に:

統合WebLogic Serverについて理解しておくと役立ちます。詳細は、「JDeveloperにおけるセキュリティのテスト」を参照してください。

セキュリティ・デプロイメントを構成し、JDeveloperでアプリケーションを実行するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「セキュリティ・デプロイメントの構成」を選択します。
2. 「アプリケーション・プロパティ」ダイアログの「デプロイメント」ページの「セキュリティ・デプロイメント・オプション」セクションで、統合WebLogic Serverにデプロイするセキュリティ・オブジェクトを選択します。

   デフォルトでは、アプリケーションを実行するたびに、JDeveloperによって、ドメイン・レベルのアプリケーション・ポリシーとシステム資格証明がアプリケーションのアプリケーション・ポリシーとシステム資格証明で上書きされます。これらリポジトリのいずれかを上書きしない場合は、「アプリケーション・ポリシー」または「資格証明」を選択解除します。選択解除した場合、JDeveloperでは新しいポリシーまたは資格証明のみがドメインレベル・ストアにマージされます。

   デフォルトでは、アプリケーションを実行するたびに、テスト目的で作成する新規ユーザーのアイデンティティがJDeveloperによって移行され、統合WebLogic Serverでアイデンティティ・ストア用に使用される埋込みLDAPサーバーにある既存のユーザー・パスワードが更新されます。「ユーザーとグループ」を選択解除して、アプリケーションのアイデンティティ・ストアの移行を無効にできます。

3. 「OK」をクリックします。
4. 「アプリケーション」ウィンドウで、保護されたWebページが含まれるユーザー・インタフェース・プロジェクトを右クリックし、「実行」を選択します。

   ユーザー・インタフェース・プロジェクトで「実行」を選択すると、JDeveloperでは、プロジェクトについて構成済のデフォルト実行ターゲットを使用してアプリケーションが実行されます。たとえば、実行ターゲットとしてタスク・フロー・アクティビティを構成して、アプリケーションを起動できます。デフォルトの実行ターゲットを構成するには、「タスク・フローのテスト」を参照してください。

   アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの作成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。

セキュリティ・デプロイメント・オプション構成時の処理

統合WebLogic Serverを使用してアプリケーションを実行するとき、JDeveloperは、「アプリケーション・プロパティ」ダイアログに指定したセキュリティ・デプロイメント構成設定に基づいて、セキュリティ・ポリシーと資格証明をドメイン・レベルに移行します。デプロイメント・プロセスで、JDeveloperは、次の例に示すように、「アプリケーション・プロパティ」の設定に基づいてデプロイメント・アーカイブ・ファイルに追加するweblogic-application.xmlファイルを更新します。これらの設定はアプリケーション・ソース・ディレクトリのweblogic-application.xmlファイルには追加されないため、表示されないことに注意してください。

<application-param>
    <param-name>jps.credstore.migration</param-name>
    <param-value>OVERWRITE</param-value>
</application-param>
<application-param>
    <param-name>jps.policystore.migration</param-name>
    <param-value>OVERWRITE</param-value>
</application-param>

OVERWRITE値を指定すると、アプリケーションのセキュリティ・ポリシーと資格証明を変更して、開発モードで実行しているOracle WebLogic Server、または統合WebLogic Server(デフォルトで開発モードで実行するように設定されている)にどちらも再デプロイすることができます。

ノート:

いずれ本番環境にデプロイする際には、weblogic-application.xmlファイルの移行設定は無視されます。既存のポリシーと資格証明を上書きできるため、これはセキュリティの脆弱性とみなされます。本番環境へのデプロイの詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。

また、次の例に示すように、JDeveloperはweblogic-application.xmlファイルをOPSSライフサイクル・リスナーでも更新します。アプリケーションが実行する前に移行プロセスを開始するために、ライフサイクル・リスナーはポリシーと資格証明について移行設定を確認し、ドメイン・レベルでセキュリティ・オブジェクトを上書きします。

<listener>
    <listener-class>
        oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
    </listener-class>
</listener>
<listener>
    <listener-class>
        oracle.security.jps.wls.listeners.JpsAppVersionLifecycleListener
    </listener-class>
</listener>

移行プロセスで、JDeveloperはOracle Platform Security Services (OPSS)アプリケーション・ロール・メンバー・クラスを統合WebLogic Serverメンバー・クラスにマッピングし、ユーザーをWebLogic Serverアイデンティティ・ストアusersに移行し、ロールをWebLogic Serverアイデンティティ・ストア・グループに移行します。Oracle WebLogic Serverでは、usersはOPSSのauthenticated-roleと同等の暗黙のグループです。

アイデンティティ・ストアの移行は、weblogic-application.xmlファイルのアプリケーション・ライフサイクル・リスナー設定では制御されません。かわりに、統合WebLogic Serverで実行するとき、またはJDeveloperからデプロイするときは、Oracle WebLogic Mbeanによってアイデンティティの移行が処理されます。ユーザーがすでに存在している場合、Mbeanはユーザー定義全体を移行しません。ユーザーのパスワードだけを更新します。

組込みtest-allアプリケーション・ロールを使用する方法

「ADFセキュリティの構成」ウィザードを実行すると、jazn-data.xmlファイルのポリシー・ストアにtest-allアプリケーション・ロールを追加するオプションを有効にできます。このオプションを有効にするときは、アプリケーションのアプリケーション・ロールへの権限付与のスコープも指定します。

• JDeveloperでtest-allアプリケーション・ロールにview権限を付与し、ウィザードの実行時にユーザー・インタフェース・プロジェクトに表示されるADFタスク・フローとWebページすべてにこのポリシーを適用するには、「既存のオブジェクトのみに付与」を選択します。

• JDeveloperでtest-allアプリケーション・ロールにview権限を付与し、開発者がユーザー・インタフェース・プロジェクトで作成した既存のADFタスク・フローとWebページ、および今後ユーザー・インタフェース・プロジェクトで作成するすべてのADFタスク・フローとWebページにこのポリシーを適用するには、「すべてのオブジェクトに付与」を選択します。「すべてのオブジェクトに付与」オプションを選択してウィザードを初めて実行した後は、ウィザードによりオプション「新規オブジェクトに付与」が表示されます。

ウィザードの実行後、jazn-data.xmlファイルにtest-allロールが表示され、セキュリティ・ポリシーの概要エディタにこのロールが表示されます。test-allロールにテスト・ユーザーを移入する必要はありません。ウィザードによって、組込みアプリケーション・ロールanonymous-roleがtest-allロールに割り当てられるためです。この場合、すべてのユーザーは自動的にanonymous-roleプリンシパルを保持し、アプリケーションへのアクセスを許可されます。

ノート:

アプリケーションをデプロイする前に、「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」の説明に従って、ポリシー・ストアからすべてのtest-allロールを削除する必要があります。これにより、未認可のユーザーはアプリケーションのWebページにアクセスできなくなります。

いつでもウィザードを再実行して、自動付与を無効にすることができます。いったん無効になると、新たに作成するADFタスク・フローとWebページはtest-allロールを利用しないため、「ADFセキュリティ・ポリシーの定義」で説明するように明示的な付与を定義する必要があります。

実行時に行われる処理: ADFセキュリティによる認証の処理

統合WebLogic Serverを使用してJDeveloperでアプリケーションをテストするとき、アイデンティティ・ストアが、Oracle Internet Directoryに格納されている情報と一緒に埋込みLDAPサーバーに移行されます。

図47-27に、ユーザーがあらかじめログインせずに、ADFバインド・タスク・フローまたはADFバインディングを含むWebページ(mypage.jspxなど)にアクセスを試行するときの認証プロセスを示します。ユーザーがパブリック・ページのログイン・リンクをクリックしてログインを開始するのではないため、認証は暗黙的に開始されます。セキュリティ保護されたページの場合、無名ユーザーに対して権限付与は行われません。

図47-27 ADFセキュリティの暗黙的認証

「図47-27 ADFセキュリティの暗黙的認証」の説明

図47-27の暗黙的な認証プロセスでは、リソースがanonymous-roleに対する権限を持たず、ユーザーがまだ認証されていず、認証メソッドがフォームベース認証であると想定しています。この場合、処理は次のようになります。

1. バインド・タスクフローまたはWebページ(ADFバインディングを含む)がリクエストされると、ADFバインディング・サーブレット・フィルタがADF認証サーブレットにリクエストをリダイレクトし(図のステップ1)、ログインをトリガーした論理操作を格納します。

2. ADF認証サーブレットにはJava EEセキュリティ制約が設定されているため、Java EEコンテナによって構成済のログイン・メカニズムが起動されます(図のステップ2)。コンテナのログイン構成に基づいて、ユーザーは次のように認証を求められます。

   1. フォームベース認証の場合は、適切なログイン・フォームが表示されます(図のステップ2a)。

   2. ユーザーは、表示されるログイン・フォームに自分の資格証明を入力します(図のステップ2b)。

   3. ユーザーは、コンテナのj_security_check()メソッドにフォームをポストします(図のステップ2c)。

   4. Java EEコンテナは、構成済のプラガブル認証モジュールを使用してユーザーを認証します(図のステップ2d)。

3. 認証が成功すると、コンテナは認証チャレンジを開始したサーブレット(この場合はADF認証サーブレット)にユーザーをリダイレクトします(図のステップ3)。

4. ADF認証サーブレットに戻ると、最初にリクエストされたリソースにリダイレクトされます(図のステップ4)。

   「実行時に行われる処理: ADFセキュリティによる認可の処理」で説明するように、リソースが表示されるかどうかは、ユーザーのアクセス権と、ADFセキュリティのための認可が施行されているかどうかに依存します。

図47-28は、パブリック・ページの「ログイン」リンクから開始するプロセスで、ユーザーが認証される場合の明示的認証処理を示しています。

図47-28 ADFセキュリティの明示的認証

「図47-28 ADFセキュリティの明示的認証」の説明

明示的認証のシナリオでは、(anonymousユーザー・プリンシパルとanonymous-roleプリンシパルのみを持つ)認証されていないユーザーが、パブリック・ページの「ログイン」リンクをクリックします(図のステップ1)。「ログイン」リンクは、web.xmlファイルのJava EEセキュリティ制約を介してセキュリティ保護されているADF認証サーブレットへのダイレクト・リクエストです。

このシナリオでは、現在のページがパラメータとしてADF認証サーブレットに渡されます。暗黙的認証のケースと同じく、セキュリティ制約によってユーザーがログイン・ページにリダイレクトされます(図のステップ2)。暗黙的認証ケースのステップa - ステップdで説明したようにコンテナがユーザーを認証すると、リクエストがADF認証サーブレットに戻されます(図のステップ3)。その後、サーブレットによってユーザーがパブリック・ページに戻されますが、その時点では新しいユーザーおよびロール・プリンシパルが配置されています。

実行時に行われる処理: ADFセキュリティによる認可の処理

ADF認可が有効になってるとき、ADFバインド・タスク・フローとタスク・フロー外部のWebページ(ADFページ定義がある)はデフォルトで保護されます。ユーザーがこれらのWebページにアクセスしようとすると、ADFセキュリティが、ポリシー・ストアでそのユーザーがアクセス権を付与されているかどうか、確認して判定します。ユーザーがまだ認証されていず、anonymous-roleに対してページが許可されていない場合、ログイン・ページまたはフォームが表示されます。認証されたユーザーでも権限がない場合は、セキュリティ・エラーが表示されます。ポリシー・ストアに適切な権限を構成していない場合、ページは保護された状態に維持され、したがって認証されたユーザーも利用できません。

図47-29は、認可プロセスを示しています。

図47-29 ADFセキュリティの認可

「図47-29 ADFセキュリティの認可」の説明

このユーザーは、ポリシー・ストアに定義されたアプリケーション・ロールstaffのメンバーです。ユーザーがまだログインしていないため、セキュリティ・コンテキストにはサブジェクト(ユーザーを表すコンテナ・オブジェクト)がありません。そのかわりに、Oracle Platform Security Servicesにより、ADFセキュリティに対して、anonymousユーザー・プリンシパル(ユーザーの一意の定義)とanonymous-roleプリンシパルを持つサブジェクトが提供されます。

anonymous-roleプリンシパルを使用すると、通常、ユーザーはADFリソースで定義されないページのみ(public.jspページなど)にアクセスできます。これに対して、ADFタスク・フローで定義されたページまたはADFページ定義ファイルを使用するタスク・フロー外部のページはすべてデフォルトで保護され、ユーザーはアクセスできません。このセキュリティ・ポリシーの例外は、ポリシー・ストアでADFリソースに対するanonymous-roleアクセスを付与する場合です。この場合、ユーザーはADFリソースによって定義されたページにすぐにアクセスすることはできません。

(ADFページ定義などで指定されている)mypage.jspxなど、ADFリソースによって定義されたWebページにユーザーがアクセスしようとすると、ADFセキュリティ施行ロジックがそのリクエストを遮断し、また、すべてのADFリソースがデフォルトでセキュリティ保護されているため、ユーザーは自動的に認証を要求されます(anonymous-roleがADFリソースへのアクセスを付与されていないと想定)。

認証が正常に終了すると、ユーザーは特定のサブジェクトを取得します。ここでセキュリティ施行ロジックがポリシー・ストアをチェックして、mypage.jspxの表示を許可されるロールと、ユーザーがそのロールのメンバーかどうかを判別します。mypage.jspxのこの例ではview権限がスタッフ・ロールに付与されています。ユーザーはそのロールのメンバーであるため、mypage.jspxにナビゲートできます。

同様の方法で、ADFリソースにより定義されている別のページsecpage.jspにユーザーがアクセスしようとすると、ユーザーはこのページで必要なview権限を持たないため、アクセスが拒否されます。

ユーザーおよびロールは、リソース・プロバイダのアイデンティティ・ストアですでに定義されているものです。アプリケーション・ロールは、jazn-data.xmlのポリシー・ストアで定義されています。

セキュア・アプリケーションのデプロイの準備

Oracle ADFアプリケーションは、テスト後にターゲット・アプリケーション・サーバーにデプロイする必要があります。アプリケーションを統合WebLogic Serverで実行でき、スタンドアロンOracle WebLogic Serverにデプロイできます

統合WebLogic Serverを使用したJDeveloperでのテストの後は、アプリケーションをスタンドアロン・サーバーにデプロイすることができます。最初は、ターゲットのサーバーはステージング環境です。本番環境にデプロイする前に、このサーバーのアイデンティティ・ストアを使用して開発のテストを続行できます。つまり、通常は作成したテスト・ユーザーを統合WebLogic Serverで実行するために移行しません。資格証明(cwallet.ssoファイル内)とセキュリティ・ポリシー(jazn-data.xmlファイル内)をスタンドアロンOracle WebLogic Serverに移行するために実行するステップは、ターゲット・サーバーで構成されているモードと、デプロイにJDeveloperまたはJDeveloper外部ツールのどちらを使用するかによって異なります。

ノート:

JDeveloperからデプロイメント環境へのデプロイの詳細は、「Fusion Webアプリケーションのデプロイ」を参照してください。

ターゲット・サーバーが開発モードで構成されているときは、JDeveloperから直接デプロイできます。この場合、JDeveloperが、デプロイメント・プロセスの一環としてポリシー・ストア、システム資格証明およびアイデンティティ・ストア(ユーザーおよびグループ)の移行を自動的に処理します。アプリケーション・セキュリティ・デプロイメント・プロパティでは、デプロイメント・プロセスがドメインレベルのポリシー・ストアとシステム資格証明を上書きできるようにデフォルトで構成されています。さらに、アイデンティティ・ストア・デプロイメント・プロパティは、テスト・ユーザーを含むアイデンティティ・ストアを移行するようにデフォルトで構成されています。「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、このデフォルトのデプロイメント動作を「アプリケーション・プロパティ」ダイアログで変更できます。

ノート:

開発モードで実行するOracle WebLogic Serverへのシステム資格証明の移行が実行されるのは、ターゲット・サーバーが資格証明の上書きを許可するように構成されている場合だけです。システム資格証明の上書きをサポートするためにOracle WebLogic Serverを構成する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。

ターゲット・サーバーが本番モードで構成されているとき、通常は、JDeveloper外部でOracle Enterprise Managerなどのツールを使用して移行タスクを処理します。JDeveloper外部のツールを使用してポリシー・ストアを本番環境のドメインレベルに移行する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。本番モードで実行するOracle WebLogic Serverでは、どのような状況でもシステム資格証明の上書きはサポートされないことに注意してください。

「ADFセキュリティの構成」ウィザードで自動付与機能を有効にした場合は、アプリケーションをデプロイする前にtest-allアプリケーション・ロールを削除することをお薦めします。test-allロールによってすべてのADFリソースが公開されるため、このロールが存在していると、アプリケーションのリソースが保護されない状態になるリスクが高まります。したがって、アプリケーションレベルのポリシー・ストアを移行する前にこのロールを削除する必要があります。

さらに、アプリケーションのOracle WebLogic Serverへのデプロイを準備するとき、jazn-data.xmlファイルに作成したテスト・アイデンティティを削除することもお薦めします。こうしておくと、セキュリティ・ポリシーをテストするために作成したユーザーが、ドメインレベルのアイデンティティ・ストアに移行されません。

ベスト・プラクティス:

アプリケーションをスタンドアロン環境にデプロイする場合は、すでにOracle WebLogic Serverに対して構成しているローカル・アイデンティティ・ストアのユーザーおよびエンタープライズ・ロールを移行してはいけません。たとえば、ユーザーweblogicとエンタープライズ・ロールAdministratorsを含むアイデンティティ・ストアをデプロイする場合は、ターゲット・サーバーのデフォルト管理構成を上書きします。競合の可能性をすべて排除するには、「アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法」で説明するように、アイデンティティ・ストアの移行を無効にすることができます。

アプリケーション・ポリシー・ストアからtest-allロールを削除する方法

セキュリティ・ポリシーの概要エディタには、ADFセキュリティの組込みtest-allロールに対するview権限を持つすべてのリソースを表示する機能があります。概要エディタのこの機能を使用して、test-allロールの権限を削除し、アプリケーションで定義するロールの権限で置き換えることができます。

または、jazn-data.xmlファイルの概要エディタを使用してtest-allロールを削除できます。エディタの「アプリケーション・ロール」ページでtest-allロールを選択して、「アプリケーション・ロールの削除」ボタンをクリックします。ただし、この方法でtest-allロールを削除しても、削除するロールのかわりの権限を作成する必要があります。概要エディタではこれらのタスク両方を一緒に行うことができるため、次の手順で使用方法を説明します。

始める前に:

Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。

test-allアプリケーション・ロールを削除し、カスタム・アプリケーション・ロールで置き換えるには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択し、「test-allのみが付与されたタスク・フローを示します」チェック・ボックスを選択して、この組込みロールに対する権限を含むタスク・フローのリストを表示します。

   test-allロールに対する権限が存在しない場合、概要エディタの「リソース」リストには何も表示されません。test-allロールが定義されるのは、「ADFセキュリティの構成」ウィザードで有効にした場合のみです。有効になっている場合、test-allの権限を含むそれらのタスク・フローが図47-30のように表示されます。

   図47-30 概要エディタでのtest-all権限付きタスク・フローの表示

   
   「図47-30 概要エディタでのtest-all権限付きタスク・フローの表示」の説明
3. 「リソース」列でリストの最初のタスク・フローを選択します。
4. 「付与先」列でtest-allを選択し、「権限受領者の削除」アイコンをクリックします。
5. 「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。その後、「アプリケーション・ロールの選択」ダイアログを使用して必要なロールを追加します。
6. これらのステップを繰り返し、残りのすべてのタスク・フローでtest-allロールを削除して、独自のアプリケーション・ロールで置き換えます。
7. 概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択し、ステップを繰り返して、すべてのWebページとそのADFページ定義についてtest-allロールを削除します。
8. 「test-allのみが付与されたタスク・フローを示します」/「test-allのみが付与されたWebページを示します」チェックボックスが選択された状態で、概要エディタにtest-all権限付きのリソースが表示されていないことを確認します。

アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法

デプロイ先のスタンドアロンOracle WebLogic Serverでは、構成済の独自のアイデンティティ・ストアが用意されます。JDeveloperで作成したテスト・ユーザーとエンタープライズ・ロール・グループをドメイン・レベルに移行しないようにするには、jazn-data.xmlファイルからテスト・ユーザー・レルムを削除する必要があります。

または、JDeveloperからデプロイする場合は、「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」オプションを選択解除して、ユーザーとグループの移行を無効にすることができます。

始める前に:

Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。

アイデンティティ・ストアからテスト・ユーザーとエンタープライズ・ロール・グループを削除するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「ユーザー」を選択します。
2. jazn-data.xmlファイルのエディタ・ウィンドウで「ソース」タブをクリックします。
3. jazn-data.xmlファイルのソースで<jazn-realm>要素の横の「-」アイコンをクリックすると、図47-31のように要素全体が折りたたまれます。

   図47-31 XMLエディタでの<jazn-realm>要素の選択

   
   「図47-31 XMLエディタでの<jazn-realm>要素の選択」の説明
4. この要素が選択された状態で[Delete]を押し、ファイルを保存します。

URL制約を使用してリソース・ファイルをセキュリティ保護する方法

リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルは、ADFセキュリティによって保護されません。アプリケーションのWebページをセキュリティ保護する場合、これらのファイルをセキュリティ保護することは必須ではありませんが、アプリケーションを十分にセキュリティ強化するために、リソース・ファイルを保護したほうが好ましい場合もあります。JavaScriptファイルはブラウザにダウンロードされるため、このときに読取り可能となることに注意してください。

リソース・ファイルを提供するため、ADF Facesフレームワークではorg.apache.myfaces.trinidad.webapp.ResourceServletを使用し、これによってリソース・ローダーに処理が委譲されます。Fusion Webアプリケーションのweb.xmlファイルには、リソース・サーブレットとURLパターンを対応付けるサーブレット・マッピングが含まれます。JDeveloperは、デフォルトで/adf/*(MyFaces Trinidad Coreの場合)および/afr/*(ADF Facesの場合)パターンを使用します。

リソース・サーブレットはADFセキュリティによって保護されないため、リソース・サーブレット用のJava EEアクセス・パスを、セキュリティ制約を使用して保護できます。リソース・ファイルに対する独自のセキュリティをweb.xmlファイル内に実装するには、/adflib/*、/adf/*および/afr/*パスに対するセキュリティ制約を定義して、これらに特定のセキュリティ・ロールを割り当てます。このセキュリティ制約により、すべてのユーザーは、Fusion Webアプリケーションの最初のページにアクセスする前に認証を受けることになります。

次の例は、セキュリティ・ロールresource_roleと、このロールにマッピングされたURLパターンによる制約を示しています。セキュリティ・ロールを定義した後は、ターゲット・サーバーの管理者によってこのロールをOracle WebLogic Serverエンタープライズ・ロール(ユーザー・グループ)にマッピングしてもらうか、または同名のエンタープライズ・ロールを作成してもらう(この場合はマッピングは不要)必要があります。

<security-role>
    <description>Java EE role to map to an enterprise role. All users who will
      be allowed to run Fusion web app must be members of that role.     </description>
    <role-name>resource_role</role-name>
</security-role>

<security-constraint>
    <web-resource-collection>
      <web-resource-name>resources</web-resource-name>
      <url-pattern>/adflib/*</url-pattern>
      <url-pattern>/adf/*</url-pattern>
      <url-pattern>/afr/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>resource_role</role-name>
    </auth-constraint>
</security-constraint>

ADFセキュリティの無効化

ADFセキュリティは無効にできますが、作成された権限は削除されません。このオプションを使用して、前にセキュリティ保護したアプリケーションを非保護で実行できます。

アプリケーション・ポリシー・ストアに対する認可チェックを一時的に実行せずにアプリケーションを実行する必要がある場合、JDeveloperではADFセキュリティを無効にできます。こうすると、既存のセキュリティ・ポリシーで提供される保護なしで、アプリケーションを実行し、すべてのリソースにアクセスできます。

ADFセキュリティを無効化する方法

アプリケーションのレベルでADFセキュリティを無効にするには、ウィザードを実行して次のオプションの1つを選択します。

• 「ADF認証」を選択すると、ADF認可が無効になりますが、ADF認証サーブレットは有効なままです。たとえば、一時的に無効化されたセキュリティ・ポリシーに対して認可チェックを施行してアプリケーションをJDeveloperで実行する必要があるとします。このオプションでは、Java EEアプリケーション・ルート「/」を、ユーザー認証をトリガーするallPagesJava EEセキュリティ制約にマップすることで、ユーザーがアプリケーションのページに最初にアクセスしたときにログインを要求します。認可チェックが施行されないため、ADFリソースはセキュリティ対応になりません。したがって、一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。

• 「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効になり、ADFリソースの認可チェックも無効になります。この場合、ユーザー認証とADFリソースのセキュリティがない状態でアプリケーションを実行できます。

どちらのオプションもADFセキュリティを再有効化する目的でいつでも選択できます。このウィザードでは特に、アプリケーション開発者がADFリソースに対して定義したセキュリティ・ポリシーを含む、アプリケーションのポリシー・ストアは変更されません。このため、いつでもウィザードに戻り、「ADF認証および認可」オプションを選択し、アプリケーションの既存のポリシー・ストアやアイデンティティ・ストアに対してADFセキュリティを再有効化できます。

始める前に:

ADFセキュリティの無効化について理解しておくと役立ちます。詳細は、「ADFセキュリティの無効化」を参照してください。

ADF認可チェックを無効にするには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。
2. 「ADFセキュリティ」ページで「ADF認証」オプションまたはADFセキュリティ構成の無効化オプションを選択します。「次へ」をクリックします。

   これらのオプションのいずれかを設定してウィザードを実行すると、ユーザー・インタフェース・プロジェクトのADFリソースはセキュリティ対応でなくなります。

3. 「終了」をクリックします。

ADFセキュリティを無効にしたときの処理

「ADFセキュリティ構成の削除」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、web.xmlファイルとadf-config.xmlファイルからADF固有のメタデータ(表47-2)が削除されます。

同様に、「ADF認証」オプションを選択してウィザードを実行し、認可チェックのみを無効にすると、次の更新が実行されます。

• web.xmlファイルでADF固有のメタデータは変更されず、allPagesセキュリティ制約が追加されます。

  allPagesセキュリティ制約が存在する場合、ユーザーはアプリケーションに最初にアクセスしたときに認証を行うことになります。

• 次の例に示すようにadf-config.xmlファイルの<JaasSecurityContext>要素のauthorizationEnforceパラメータがfalseに設定されます。

<JaasSecurityContext 
  initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory"
  jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext"
                             authorizationEnforce="false"
                             authenticationRequire="true"/>

adf-config.xmlファイルは、ワークスペースの/.adf/META_INFフォルダにあります。JDeveloperでは、このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで「ディスクリプタ」→「ADF META-INF」ノードを開くと見つかります。JDeveloperの外部でエディタを使用してadf-config.xmlファイルを表示する場合、ウィザードによって適用されたファイル内の変更を確認するにはワークスペースを保存する必要があります。

高度なトピックとベスト・プラクティス

デフォルトのADFリージョンとタスク・フロー認可以外に、追加のセキュリティ構成があります。さらに、ADFアプリケーションを保護して、意図したWebページへのユーザーのアクセスを許可するのに役立つベスト・プラクティスがあります。

ADFセキュリティの有効化プロセスを完了した後、ユーザー・インタフェースにおいてADFセキュリティと連動するようにアプリケーションをカスタマイズすることができます。たとえば、式言語(EL)を使用し、一連のUIコンポーネントのためだけに定義したカスタム権限の評価に基づいて、UIコンポーネントをWebページにレンダリングできます。さらに、マネージドBean内にメソッドを定義して、アプリケーションの情報(ユーザー名やロール・メンバーシップなど)を公開できます。

ADFセキュリティでの式言語(EL)の使用

式言語(EL)を使用するとUIのポリシーを直接評価できますが、Javaを使用するとマネージドBean内でポリシーを評価できます。ADFセキュリティでは、セキュリティ・コンテキストでADFリソースにアクセスするように、EL式で使用できる便利なメソッドがいくつか実装されています。たとえば、EL式とADFセキュリティ・コンテキストAPIのメソッドを使用して、ユーザーが特定のタスク・フローにアクセスできるかどうかを判定できます。優れたセキュリティは、ユーザーがアクセス権を持たないリソースや機能をアプリケーションが非表示にすることを求めます。この理由から、ユーザーが特定のタスク・フローへのアクセスを許可されない場合、そのユーザーの権限を評価して、そのタスク・フローを開始するナビゲーション・コンポーネントをレンダリングするかどうかを判別します。

ノート:

ポリシーを評価できるのは、現在のリクエストのみです。この理由から、リクエスト・スコープ外でポリシーを評価すると、予期しない結果が発生することがあるため、ポリシー評価がどこで行われるかを理解することが重要です。

ELを使用したポリシーの評価方法

UIコンポーネント内でELを使用すると、コンポーネントの属性値を動的に定義できるようになるため、実行時にUIコンポーネントを変更できます。リソースを保護する場合、対象となるUIコンポーネント属性はrendered属性です。これを使用して、ユーザーの権限に基づいてコンポーネントの表示と非表示を切り替えることができます。デフォルトでは、rendered属性はtrueに設定されています。権限に応じてこの値を動的に変更することで、UIコンポーネントの表示と非表示を設定できます。たとえば、ユーザーが適切な権限を持っている場合は、UIコンポーネントが表示されるようにrendered属性をtrueに設定する必要があります。権限を持たない場合は、属性をfalseに設定して、UIコンポーネントを非表示にする必要があります。

ELを使用してポリシーを評価するには、securityContext ELネームスペースでADFセキュリティのメソッドを使用する必要があります。これらのメソッドを使用して、特定のユーザーまたはADFリソースに関してADFセキュリティ・コンテキストの情報にアクセスできます。

表47-11に、ユーザーが関連する権限を持つかどうかを判別するために必要なEL式を示します。ユーザーが適切な権限を持っている場合、EL式はtrueに評価されます。そうでない場合はfalseを返します。

表47-11 ADFリソースに対するview権限を判定するEL式

式	式のアクション
#{securityContext.taskflowViewable['MyTaskFlow']} 次に例を示します。 #{securityContext.taskflowViewable ['/WEB-INF/audit-expense-report.xml#audit-expense-report']}	MyTaskFlowは、アクセス対象のタスク・フローのWEB-INFノード修飾名です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。
#{securityContext.regionViewable['MyPagePageDef']}	MyPagePageDefは、アクセス対象のWebページに関連付けられているページ定義ファイルの修飾名です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。

ノート:

「valid-usersロールに関する必知事項」で説明したように、ページ権限の場合、マネージドBean内部の遅延バインディングELを使用することにより、ページ定義の値を動的に指定できます。

表47-12には、ADFセキュリティ・コンテキストから、ADFリソースに関連しない一般的な情報を取得するためのEL式を示します。たとえば、ユーザーの名前をユーザー・インタフェースに表示する場合は、現在のユーザー名にアクセスできます。また、現在のユーザーが特定のロールのメンバーかどうか、特定の権限を付与されているかどうかもチェックできます。アプリケーションはこの結果を使用してメニューの非表示と表示を動的に切り替えることができます。

表47-12 ADFセキュリティ・コンテキストでのユーザー情報を判定するEL式

式	式のアクション
#{securityContext.userName}	認証されたユーザーのユーザー名を戻します。
#{securityContext.authenticated}	ユーザーがログインしている場合はtrueを戻します。ユーザーがログインしていない場合はfalseを戻します。これが役立つのは、ログイン/ログアウトの動的リンクのレンダリング、またはユーザーが認証されたときの「ようこそ、username」メッセージのレンダリングです。この式を使用する例は、「ログイン・リンクおよびログアウト・リンクの追加」を参照してください。
#{securityContext.userInRole['roleList']}	roleListはロール名のカンマ区切りリストです。ユーザーが少なくとも1つのロールに含まれる場合はtrueを戻します。ユーザーがどのロールにも含まれない場合または現在認証されていない場合は、falseを戻します。
#{securityContext.userInAllRoles['roleList']}	roleListはロール名のカンマ区切りリストです。ユーザーがすべてのロールに含まれる場合はtrueを戻します。ユーザーがすべてのロールには含まれていない場合または現在認証されていない場合は、falseを戻します。
#{securityContext.userGrantedPermission['permission']}	permissionは、permissionClass=<class>;target=<artifact_name>;action=<action>のようなセミコロンで連結した要素を含む文字列です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。 表47-11に示された便利なメソッドtaskflowViewableおよびregionViewableにも同じ機能があります。
#{securityContext.userGrantedResource['resource']}	resourceは、resourceName=<name>;resourceType=<type>;action=<action>のようなセミコロンで連結した要素を含む文字列です。ユーザーがアクセス権を持つ場合はtrueを戻します。ユーザーが十分なアクセス権を持たない場合はfalseを戻します。 この式を使用すると、タスク・フローに含まれないリソース(「ADF Faces」パネルやメニュー項目など)の表示プロパティの権限をテストできます。最初に、保護するUIコンポーネントのカスタム・リソース・タイプを作成します。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

始める前に:

ELの用法について理解しておくと役立ちます。詳細は、「ADFセキュリティでの式言語(EL)の使用」を参照してください。

ナビゲーション・コンポーネントのレンダリングを、ターゲット・タスク・フローまたはページ定義に対してユーザーに付与された権限に関連付けるには:

1. 「アプリケーション」ウィンドウで、条件付きでレンダリングするナビゲーション・コンポーネントを含むページをダブルクリックします。
2. ページのビジュアル・エディタで、セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
3. 「プロパティ」ウィンドウで、「レンダリング済」フィールドの横に表示されている「プロパティ・メニュー」ドロップダウン・メニューから、「式ビルダー」を選択します(図47-32)。

   図47-32 データへのRenderedプロパティのバインディング

   
   「図47-32 データへのRenderedプロパティのバインディング」の説明
4. 「式ビルダー」で「ADFバインディング」の「securityContext」ノードを開いて適切なEL値を選択します。次に、「式」フィールドに、アクセスしようとしているADFリソースの修飾名を入力します。

   たとえば、図47-33に示すようにアプリケーションで表示するタスク・フローへのアクセスを制限するには、次のような式を作成します。

   #{securityContext.taskflowViewable
        ['/WEB-INF/audit-expense-report.xml#audit-expense-report']}
   

   この例では、式によって、ターゲット・タスク・フローaudit-expense-reportを表示するためのユーザーのアクセス権が判別されます。ユーザーにアクセス権がある場合、式はtrueとして評価され、rendered属性は値trueを受け取ります。

   図47-33 「式ビルダー」ダイアログでのELの定義

   
   「図47-33 「式ビルダー」ダイアログでのELの定義」の説明

   ヒント:

   「式ビルダー」ダイアログの「説明」を開くと、選択したセキュリティELメソッドに関する追加情報を参照できます。

5. 「OK」をクリックします。

アプリケーションを実行すると、ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。

「式ビルダー」ダイアログの使用時の処理

「式ビルダー」を使用してrendered属性の式を定義すると、開いている.jspxファイルのコンポーネント定義がJDeveloperによって更新されます。次の例に示すように、コンポーネントのrendered属性に、trueまたはfalseに評価される式が追加されます。この例ではコンポーネントはナビゲーション・リンクであり、リンク・テキストCheckoutは別の式で定義されます。このナビゲーション・リンクを含むページによってこのコンポーネントがレンダリングされるのは、チェックアウト・タスク・フローにアクセスするための十分なアクセス権がユーザーにある場合のみです。

<af:commandNavigationItem
   text="#{res['global.nav.checkout']}"
   action="globalCheckout"
   id="cni3"
   rendered="#{securityContext.taskflowViewable
                       ['/WEB-INF/checkout-task-flow.xml#checkout-task-flow']}"
/>

ELの遅延評価に関する必知事項

セキュリティ権限を評価できるスコープは、リクエストに設定されています。リクエストよりも上位レベルまでスコープ設定されたマネージドBean (マネージドBeanが基礎となっているグローバル・メニューなど)からターゲット・ページにアクセスするための権限を評価する場合は、遅延EL評価(遅延バインディング)を実装する必要があります。Beanの管理プロパティとしてターゲット・ページを渡すことで、マネージドBeanが必要なバインディング情報を取得できるようになった後でEL式が評価されるようになります。ELは、ページが実行されるとすぐに評価されるため、マネージドBeanを基礎としたUIコンポーネントのプロパティ内に直接EL式を配置すると、有効範囲外エラーが発生します。

次の例は、ユーザーが特定のターゲット・ページを表示できるかどうかに基づいてtrueまたはfalseを返すマネージドBeanのプロパティ(authorized)を示しています。この場合、_targetPageDef変数は、ターゲット・ページの名前が含まれる管理プロパティです。UI内で、EL式はauthorizedプロパティを参照します。

public boolean isAuthorized() 
{
 if (_targetPageDef != null) {
  FacesContext fctx = FacesContext.getCurrentInstance();
  ADFContext adfCtx = ADFContext.getCurrent();
  SecurityContext secCtx = adfCtx.getSecurityContext();
  boolean hasPermission = secCtx.hasPermission(new RegionPermission
     (_targetPageDef, RegionPermission.VIEW_ACTION));
     if (hasPermission) {
        return hasPermission;
     }
     else {
        fctx.addMessage(null, new FacesMessage (
        FacesMessage.SEVERITY_WARN, "Access Permission not defined! " , null));
        return false;
     }
}

OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法

表47-12に示したADFセキュリティのELネームスペースでのセキュリティ式によって、ページにUIコンポーネントを表示する前にユーザー権限、認証およびロール・メンバーシップ・ステータスを確認できます。タスク・フロー・セキュリティやWebページ・セキュリティの一部ではないアプリケーションの機能部分を保護するために、UIコンポーネントをきめ細かく保護する必要がある場合は、EL値userGrantedResourceと、カスタム・リソース・タイプ用に定義したリソース権限を使用します。たとえば、ユーザーがメニュー項目用に作成したリソース権限によって、アプリケーションはCancel Shipment(出荷取消し)のメニュー項目を有効化または無効化して、顧客注文更新の実行者を制限します。

カスタム・リソース・タイプのリソース権限は、ResourcePermissionクラスに依存しています。このクラスはOracle Platform Security Services (OPSS)によって提供され、アプリケーションとともにパッケージ化されています。

セキュリティ・ポリシーの概要エディタを使用して、カスタム・リソース・タイプのセキュリティ・ポリシーを作成します。またWebページでは、セキュリティ式を使用して、リソース権限によって投影されるUIコンポーネントへのユーザーのアクセス権限を評価します。

ベスト・プラクティス:

カスタム・リソース・タイプとResourcePermissionマッチャ・クラスを組み合せることで、ADFセキュリティを開き、権限内で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。Webページへのアクセスを管理するために、カスタム・リソース・タイプを作成する必要はありません。このレベルのアクセスは、セキュリティ・ポリシーの概要エディタで操作できる、ADFセキュリティのデフォルトのview権限によって実現されます。

カスタム・リソース・タイプのリソース・ポリシーを許可するには:

1. 保護するUIコンポーネントのカスタム・リソース・タイプを作成します。
2. カスタム・リソースに対してリソース権限を作成します。
3. UIコンポーネントのレンダリングを、ロールに付与されるリソース権限に関連付けます。

カスタム・リソース・タイプの作成

「リソース・タイプの作成」ダイアログを使用して、保護するUIコンポーネントのリソース・タイプを作成します。JDeveloperが、リソース・タイプの定義とOPSS権限クラスoracle.security.jps.ResourcePermissionを一致させます。このクラスを使用して、タスク・フロー・セキュリティまたはWebページ・セキュリティによって保護されないアプリケーションの機能部分に権限を付与できるカスタム・アクションを指定できます。たとえば、メニューのUIコンポーネントを使用してユーザーがアクセスするアプリケーションの機密部分を保護するために、リソース・タイプを作成することがあります。

「リソース・タイプの作成」ダイアログでは、保護するリソースのタイプ(たとえば、MenuProtectionという名前はメニューのUIコンポーネントを識別する)、セキュリティ・ポリシー・ストアに表示される表示名(例: Menu Protection)、リソース権限でのリソース・タイプの使用方法の説明(例: Resource permission to grant menu item permissions)を識別できます。このダイアログでは、権限を付与するために使用する1つ以上のカスタム・アクション名を入力することもできます。たとえば、保護されたメニュー項目へのアクセス権を付与するセキュリティ・ポリシーで使用するために、processというアクション名を入力できます。

始める前に:

ADF権限クラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

カスタム・リソース・タイプを作成するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「新規リソース・タイプ」をクリックします。
3. 「リソース・タイプの作成」ダイアログで、名前と、UIコンポーネントを説明する表示名を入力します。

   たとえば、メニュー項目を保護するには、名前にはMenuProtection、表示名にはMenu Protectionと入力します。

4. 「アクション」リストで「追加」をクリックし、権限を付与するアクションの名前を入力して、「OK」をクリックします。

   たとえば、メニュー項目を保護する場合、processと入力することで、メニュー選択を処理する権限が付与されることを示します。特定のアクションの権限を個々のユーザーまたはロールに付与する場合は、複数のアクション名を入力できます。図47-34のように概要エディタにカスタム権限が表示されます。

   図47-34 カスタム・リソース・タイプの作成

   
   「図47-34 カスタム・リソース・タイプの作成」の説明

カスタム・リソース・タイプに対するリソース権限の作成

jazn-data.xmlファイルの概要エディタを使用して、カスタム・リソースのADFセキュリティ・ポリシーを作成します。完成したソースは、次の例に示すように、ポリシー・ストアで定義される権限と類似した内容となります。

<grant>
  <grantee>
    <principals>
      <principal>
         <name>AccountManagersadmin</name>
         <class>oracle.security.jps.service.policystore.ApplicationRole</class>
      </principal>
     </principals>
  </grantee>
  <permissions>
     <permission>
       <class>oracle.security.jps.ResourcePermission</class>
       <name>resourceType=MenuProtection,resourceName=CancelShipment</name>
       <actions>process</actions>
     </permission>
   </permissions>
</grant>

ターゲット名<permission>は、カスタム・リソース・タイプと、リソースを割り当てた名前を識別します。たとえば、ユーザーがアカウント内のメニュー選択から出荷を取り消すことができるリソース名は、CancelShipmentという名前になります。

アクションは、カスタム・リソース・タイプによって定義されています。たとえば、メニュー保護では、リソース・タイプによって、メニュー選択を処理する権限を付与するための単一アクションprocessが定義されます。

始める前に:

ResourcePermissionクラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

次のタスクを完了する必要があります。

• 「カスタム・リソース・タイプの作成」の説明に従って、カスタム・リソース・タイプを作成します。

カスタム・リソース・タイプに対してリソース権限を作成するには:

1. メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
2. セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストからカスタム・リソースを選択します。
3. 「リソース」列で、「リソースの追加」アイコンをクリックします。
4. 「リソースの作成」ダイアログで、セキュリティ・ポリシーが特に保護するリソースの名前、表示名、説明を入力して、「OK」をクリックします。
5. 概要エディタの「リソース権限」ページにおいて、「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
6. 「アクション」列で、カスタム・リソース・タイプに対して定義したアクションを選択します。

   図47-35のように、概要エディタにリソース権限が表示されます。

   図47-35 概要エディタでのカスタム・リソースに対する権限の作成

   
   「図47-35 概要エディタでのカスタム・リソースに対する権限の作成」の説明

UIコンポーネントのレンダリングとリソース権限との関連付け

UIコンポーネントの表示プロパティに対する「式ビルダー」ダイアログを使用して、コンポーネントのレンダリングを制御するEL式を定義します。たとえば、認可ユーザーが出荷を取り消すことができるアプリケーションでメニュー項目を保護するために、アプリケーションは、af:commandMenuItemによって定義されたメニュー項目のdisabledプロパティに対して、userGrantedResource式を指定します。次の例に示すように、ユーザーにリソース・タイプに対する権限が付与されているか、その結果メニュー項目が表示されるかどうかが式によってテストされ、ユーザーにリソースに対する権限が付与されていない場合は、メニュー項目が無効化されます。

#{!securityContext.userGrantedResource
       ['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}

図47-36は、「式ビルダー」ダイアログに式がどのように表示されるかを示します。

図47-36 「式ビルダー」ダイアログでのELの定義

「図47-36 「式ビルダー」ダイアログでのELの定義」の説明

始める前に:

ResourcePermissionクラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。

次のタスクを完了する必要があります。

1. 「カスタム・リソース・タイプの作成」の説明に従って、カスタム・リソース・タイプを作成します。

2. 「カスタム・リソース・タイプに対するリソース権限の作成」の説明に従って、カスタム権限を使用してADFセキュリティ・ポリシーを作成します。

UIコンポーネントのレンダリングとユーザーに付与されるリソース権限を関連付けるには:

1. 「アプリケーション」ウィンドウで、条件付きでレンダリングするUIコンポーネントを含むページをダブルクリックします。
2. ページのビジュアル・エディタで、セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
3. 「プロパティ」ウィンドウで、「レンダリング済」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
4. 「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedResourceを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。

   権限文字列は、resourceName=theResourceInstanceName;resourceType=customResourceTypeName;action=actionNameのようにセミコロンで連結した文字列として入力します。たとえば、認可ユーザーが出荷を取り消すことができるアプリケーションでメニュー項目を保護するために、次の例と同じような式を入力でき、userGrantedResourceのリソース・タイプは、カスタム・リソース権限で使用されるリソース・タイプを識別します。

   #{!securityContext.userGrantedResource
          ['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}
   

   この例では、アプリケーション・ポリシー・ストアに追加したMenuProtectionという名前のカスタム・リソース・タイプに基づいて、権限が式によって評価されます。

5. 「OK」をクリックします。

エンティティ・オブジェクト操作の認可チェックの実行方法

Fusion Webアプリケーションで、エンティティ・オブジェクトの操作をセキュリティで保護する際にデータ・コレクションのセキュリティを有効にできます。ユーザーには、行セット全体のデータを表示、更新または削除するのに十分な権限が必要です。

oracle.jbo.ViewCriteriaRow APIでは、エンティティ行のレベルで標準操作(read、update、removeCurrentRow)の認可チェックを実行できます。次の例は、エンティティ行に対して認可チェックAPI、getSecurityHints()およびallowsOperation()を使用して、ユーザーにデータを削除する権限があるかどうかをテストする方法を示しています。

if(row.getSecurityHints().allowsOperation("removeCurrentRow").hasPermission())
        // code for the data
else
        // display error message

allowsOperation()メソッドは、保護するアクションの名前ではなく保護された操作名を入力として必要とします。エンティティ行の削除の操作名はremoveCurrentRow (deleteがアクション名)です。

Fusion WebアプリケーションのJSFページにデータ・バインドされたコンポーネントの基礎となるエンティティ・オブジェクトの認可チェックを実行する場合は、EL式を使用できます。たとえば、次のEL式は、指定された操作を実行する権限がユーザーに付与されている場合にtrueを返します。式で使用されている<operationName>は、エンティティ・オブジェクトに対して有効にしたread、updateまたはremoveCurrentRow操作である必要があります。

#{row.hints.allows.<operationName>}

認可チェック式は、行コレクションのコンテキストで評価されます。行コレクションのコンテキストの外部でエンティティ権限をチェックする場合は、表47-12に示すようにuserGrantedResourceメソッドを使用する必要があります。

ADFセキュリティ・コンテキストからの情報の取得

Fusion Webアプリケーション内にセキュリティを実装することは、定義上、ADFセキュリティ・フレームワークのセキュリティ・インフラストラクチャを実装することです。このため、フレームワークのセキュリティ・コンテキストを使用して、アプリケーションのポリシーやセキュリティ全体を定義するときに必要となる情報にアクセスできます。

セキュリティが有効かどうかの判定方法

ADFセキュリティの施行は、アプリケーションと無関係にコンテナ・レベルでオン/オフを切り替えることができるため、認可チェックを行う前に、ADFセキュリティが有効化されているかどうかを判断する必要があります。このためには、次の例に示すように、ADFセキュリティ・コンテキストのisAuthorizationEnabled()メソッドをコールします。

if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()){
  //Authorization checks are performed here.
}

ユーザーが認証済かどうかの判定方法

Fusion Webアプリケーション内のユーザー・プリンシパルがnullになることはない(つまり、認証されていないユーザーの場合はanonymousで、認証されたユーザーの場合は実際のユーザー名になる)ため、ユーザー・プリンシパルがnullかどうかを確認するだけで、そのユーザーがログオンしているかどうかを判断することはできません。このため、anonymousユーザー・プリンシパルがユーザーが認証されていないことを表すことを考慮に入れるメソッドを使用する必要があります。このためには、次の例に示すように、ADFセキュリティ・コンテキストのisAuthenticated()メソッドをコールします。

// ============ User's Authenticated Status =============
private boolean _authenticated;
public boolean isAuthenticated() {
  _authenticated = ADFContext.getCurrent().getSecurityContext().isAuthenticated();
  return _authenticated;
}

現在のユーザー名の判別方法

Fusion Webアプリケーションでは、セキュアでありながらすべてのユーザーに使用可能なパブリック・ページの概念をサポートしています。さらに、Webページ上のコンポーネント(ポートレットなど)では、現在のユーザー・アイデンティティの情報を必要とします。このため、Fusion Webアプリケーションのユーザー名は決してnullになることはありません。認証されていないユーザーがページにアクセスすると、ユーザー名anonymousがページ・コンポーネントに渡されます。

現在のユーザー名を判別するには、次の例に示すように、ADFセキュリティ・コンテキストのgetUserName()メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymousを返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。

// ============ Current User's Name/PrincipalName =============
     public String getCurrentUser() {
      _currentUser = ADFContext.getCurrent().getSecurityContext().getUserName(); 
      return _currentUser;
     }

Facesベースのアプリケーションでユーザー名を判別するための従来のメソッド(FacesContext.getCurrentInstance().getExternalContext().getRemoteUser())では、認証されていないユーザーに対してnullが戻されるため、そのメソッドを使用する場合は、パブリック・ユーザーのケースを処理する追加のロジックを使用する必要があります。

Java EEセキュリティ・ロールのメンバーシップの判別方法

Fusion WebアプリケーションはJavaServer Facesベースのアプリケーションなので、次の例に示すように、Faces外部コンテキストのisUserInRole(roleName)メソッドを使用すると、ユーザーに特定のロールが割り当てられているかどうかを判別できます。ADFセキュリティはJAASポリシーに基づくため、ロール・メンバーシップに基づくADFセキュリティ対応リソースに関連付けられたページを保護するためにJava EEセキュリティ・ロールを使用する必要はありません。ただし、ADFセキュリティ対応リソースに関連付けられていないページについては、メソッドを使用してロールをチェックできます。

この例では、便利なメソッド(checkIsUserInRole)が定義されています。マネージドBean内でこのメソッドを使用すると、名前付きロールのメンバーシップを属性として公開し、その後EL内で使用できます。

public boolean checkIsUserInRole(String roleName){
        return 
(FacesContext.getCurrentInstance().getExternalContext().isUserInRole(roleName));
}

public boolean isCustomer() {
        return (checkIsUserInRole("Application Customer Role"));
 }

Javaを使用して権限を判別する方法

Java内からセキュリティ・ポリシーを評価するには、ADFセキュリティ・コンテキストのhasPermissionメソッドを使用できます。このメソッドは、(リソースとアクションの組合せにより定義された)権限オブジェクトを取り、ユーザーに対応する権限があればtrueを返します。

次の例では、ページ名と必要なアクションを渡し、ユーザーの権限に基づいてtrueまたはfalseを返すことのできる、便利な関数が定義されています。この便利な関数がページ権限を確認するため、RegionPermissionクラスを使用して、hasPermissionメソッドに渡される権限オブジェクトを定義しています。

private boolean TestPermission (String PageName, String Action)  {
  Permission p = new RegionPermission("view.pageDefs." + PageName + "PageDef",
                                         Action);
  if (p != null) {
     return ADFContext.getCurrent().getSecurityContext().hasPermission(p);
  }
  else {
     return (true);
}

バッキングBean内からターゲット・ページのユーザー権限を判別することはできないので、今度はこの便利なメソッドを使用して、Facesナビゲーション・アクションの結果を動的に変更できます。次の例では、1つのコマンド・ボタンがユーザーの権限に応じて異なるターゲット・ページを指していることがわかります。コマンド・ボタンのバッキングBeanは、最も高いレベルで保護されているページ(管理者ページ)から最も低いレベルで保護されているページ(パブリックのようこそページ)までview権限を確認することにより、適切なアクションを適用して、ユーザーに対して権限レベルに応じたページを表示します。適切なアクションを戻すバッキングBeanは、次の例に定義されている便利なメソッドを使用しています。

//Button Definition
<af:button text="Goto Your Group Home page"
  binding="#{backing_content.commandButton1}"
  id="commandButton1"
  action="#{backing_content.getSecureNavigationAction}"/>

//Backing Bean Code
    public String getSecureNavigationAction() {
      String ActionName;
      if (TestPermission("ManagerPage", "view"))
        ActionName = "goToManagerPage";
      else if (TestPermission("EmployeePage", "view"))
        ActionName = "goToEmployeePage";
      else
        ActionName = "goToWelcomePage";
      return (ActionName);
    }

ADFセキュリティの操作のベスト・プラクティス

次に示すベスト・プラクティスは、ADFセキュリティ・フレームワークによるセキュリティ施行のための規則をまとめたものです。これらのベスト・プラクティスを理解することで、アプリケーションを保護して、意図したWebページにユーザーのアクセスを許可することができます。

アプリケーションを構築するときは最初からADFセキュリティを有効にしてください。

セキュリティを有効化すると、アプリケーションが実質的にロックダウンされます。また、作成する固有のADFセキュリティ対応リソースに対して明示的な権限付与を行う必要が生じます。アプリケーションを構築する際に、これらのリソースについて認識して、権限付与を行うことにより、反復しながらセキュリティをテストできます。こうして、必要な結果を実現するようにアプリケーションを構成できます。

バインド・タスク・フローの権限を定義してください。

バインド・タスク・フローを実行するプロセスでユーザーがアクセスするページは、ページごとの個別の権限チェックは行われず、タスク・フローの権限において実行されます。つまり、タスク・フローに追加するページには、ページ定義レベルでの独自のセキュリティは定義されていません。ユーザーがフローをリクエストする場合、アクセス・レベルに応じて、タスク・フローのすべてのページの表示を許可されるか、まったく許可されないかのどちらかになります。

バインド・タスク・フローの個々のページには権限を定義しないでください。

タスク・フローはユーザーによるページへの直接アクセスを妨げないことを理解することが重要です。公開されているディレクトリにあるすべてのWebページは、URLを使用してブラウザからアクセスできます。バインド・タスク・フローによって参照されるページに直接アクセスできないようにするため、関連するページ定義ファイルについて存在するすべての権限を削除します。バインド・タスク・フローのコンテキスト内でページに追加のセキュリティが必要な場合は、それらのページをサブタスク・フローに含めて、このネストされたタスク・フローに対する権限の定義を追加します。

エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすため、タスク・フローを使用してください。

タスク・フローを使用すると、エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすことができます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローの「URL起動」プロパティをurl-invoke-disallowedに設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。「URL起動」プロパティの詳細は、「URLを使用したバインド・タスク・フローのコール方法」を参照してください。

未認可のユーザーに対する代替タスク・フローを指定してください。

エンド・ユーザーが、必要な権限を持たないリージョンでバインド・タスク・フローを起動しようとすると、リクエストしたタスク・フローではなく、空白にレンダリングされたリージョンが表示されます。リージョンが空白のままだと、リクエストしたタスク・フローが表示されない理由についてのフィードバックが提供されないため、エンド・ユーザーが当惑する可能性があります。このシナリオの発生時には、認可が必要でない代替タスク・フローを構成することを検討してください。代替タスク・フローの構成の詳細は、「未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理」を参照してください。

バインド・タスク・フロー外部の個々のページには権限を定義してください。

ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。ページ定義ファイルとそれがセキュリティ保護するWebページの間には1対1の関係があります。

ADFバインディングを使用しないページを保護する場合は、そのページに対して空のページ定義バインディング・ファイルを作成できます。

ユーザーのアクセス権に基づいてUIコンポーネントをレンダリングするにはカスタム権限を定義してください。

カスタムADF権限クラスを使用すると、ADFセキュリティを拡張して、権限で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。

UIコンポーネントによって表示される行レベル・データに対するユーザーのアクセス権を管理するには、エンティティ・オブジェクト属性権限を定義してください。

エンティティ・オブジェクトおよびエンティティ・オブジェクト属性は両方とも権限クラスを定義します。これを使用して、エンティティ・オブジェクトがデータ・ソースに対して開始する読取り、更新および削除操作の権限を定義できます。これらのデータ・モデル・プロジェクト・コンポーネントの場合、ADFセキュリティ認可を選択するために、アプリケーション・ロールに明示的に権限を付与する必要があります。ただし、エンティティ・オブジェクトの認可を有効にすると、そのエンティティ・オブジェクトによって定義されたすべてのデータ行は権限付与によって保護されます。このレベルの粒度では、表コンポーネントがWebページにレンダリングされるとき、ユーザーのアクセス権に応じて、すべてのデータが表示されるかデータがまったく表示されないかのどちらかになります。コレクション全体を保護するかわりに、データの個々の列を保護することができます。このレベルの粒度は、エンティティ・オブジェクトの個々の属性に設定する権限によってサポートされます。エンティティ・オブジェクトが保護されるとき、ユーザーが見ることができるのは表コンポーネントに表示されるデータの一部のみです。

view権限しかないユーザーに行レベルの作成/挿入操作を公開しないようにするには、タスク・フローまたはページレベルの権限付与を使用してください。

特定のユーザーだけが表の新しい行を更新できるページのアクセスを制御する適切な方法としては、タスク・フローまたはページレベルの権限付与を使用します。ただし、代替手段として、特定の操作に対応する表ボタンを保護することができます。これには、EL式を指定して、ボタンを表示するためのユーザーのアクセス権をテストします。カスタム権限が定義され、userGrantedPermission式がボタンのRenderedプロパティに設定されているとき、十分な権限を持つユーザーのみにボタンが表示されます。これが役立つのは、ユーザー・インタフェースに表示されるページに制限がなく、行レベルデータのview権限のみがエンティティ・オブジェクトに定義されている場合です。この場合、ユーザーが表示すると、エンティティ・オブジェクトに関連付けられた編集可能な表の「Delete」ボタンは無効な状態で表示されます。ただし、入力表の場合は、ユーザーにupdate権限がなくても、ユーザー・インタフェースによってCreateInsert操作のボタンが無効になることはありません。

JDeveloperを、ユーザー・アイデンティティのプロビジョニング・ツールとして使用しないでください。

JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、常にシステム管理者が担当します。アプリケーションをデプロイする前に、作成したすべてのユーザーおよびグループをjazn-data.xmlファイルから削除する必要があります。

ユーザーがファイル名を使用してWebページにアクセスできないようにしてください。

Fusion Webアプリケーションをデプロイするときは、ADFコントローラの構成ファイルに定義されたビュー・アクティビティからユーザーがWebページにアクセスできるように常に許可する必要があります。ユーザーがJSPXファイルの物理名(ファイル名AllDepartments.jspxなど)を使用して直接アクセスすることは許可しないでください。

ビュー・アクティビティの名前がAllDepartmentsとすると、このページをコールするには次の2つの方法があります。

1. localhost:7101/myapp/faces/AllDepartments

2. localhost:7101/myapp/faces/AllDepartments.jspx

違いは、1のコールがADFコントローラ・タスク・フローのコンテキストにあることです。つまり、ページのナビゲーションが作動し、ページで参照されるすべてのマネージドBeanが適切にインスタンス化されます。2のコールでもページが表示されますが、完全に作動しないことがあります。これはセキュリティの侵害とみなされる可能性があるためです。

JSPXファイルへの直接アクセスを防ぐには、JSPXファイルを/public_html/WEB-INFディレクトリに移動して、直接ファイル・アクセスを行えないようにします。ドキュメントにアクセスするには、ユーザーはビュー・アクティビティ名をコールする必要があります。

この方法では、ADFセキュリティで保護されていないドキュメントは保護できないことに注意してください。物理ファイルそのものへのアクセスのみがロックダウンされます。

したがって、次のセキュリティ・ガイドラインが引続き適用されます。

1. adfc-config.xmlファイルに定義されたビュー・アクティビティに関連付けられたすべてのJSPXドキュメントに、ADFセキュリティ権限を適用します。

2. ユーザー・インタフェース・プロジェクトのすべてのJSPXドキュメントを/public_html/WEB-INFディレクトリに移動して、ファイルへの直接アクセスを防ぎます。

3. adfc-config.xmlのページを最小限に制限し、他のすべてのページをバインド・タスク・フローに含めます。

4. バインド・タスク・フローに直接URLアクセスでアクセスできないようにします(新しいタスク・フローのデフォルト構成設定)。

5. バインド・タスク・フローにADFセキュリティ権限を適用します。