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

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

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

30.1項「ADFセキュリティの概要」
30.2項「ADFセキュリティ・プロセスの概要」
30.3項「ADFセキュリティの有効化」
30.4項「アプリケーション・ロールの作成」
30.5項「ADFセキュリティ・ポリシーの定義」
30.6項「テスト・ユーザーの作成」
30.7項「ログイン・ページの作成」
30.8項「JDeveloperでのセキュリティのテスト」
30.9項「セキュア・アプリケーションのデプロイの準備」
30.10項「ADFセキュリティの無効化」
30.11項「高度なトピックとベスト・プラクティス」

30.1 ADFセキュリティの概要

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

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

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

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

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

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

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

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

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

たとえば、ページに売上数上位の製品の要約が表示されることがありますが、これには、そのページに関連付けられたADFページ定義ファイルのADFバインディングによって調整されたデータが使用されます。ページ定義とADFバインディングの詳細は、12.6項「ページ定義ファイルでの作業」を参照してください。
ADFエンティティ・オブジェクトとエンティティ・オブジェクトの属性(データ行を参照し、ユーザー・インタフェースに表示するコレクションの定義に使用されます)

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

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

注意:

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

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

ヒント:

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

30.1.1 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リソースのアクセス・ポリシーを定義したときに、アプリケーションがセキュリティ対応になります。

注意:

OPSSとADFセキュリティは両方ともJava Authentication and Authorization Services (JAAS)と呼ばれるJavaセキュリティ・モデル上に構築されます。JAASでは、アプリケーションのリソースを保護するためにカスタム権限を使用できます。Oracle Platform Security Servicesのセキュリティ機能の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。

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

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

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

リソースの権限クラスによって定義されるアクションと、アプリケーションのADFリソース・インスタンスを関連付ける、1つ以上の権限(現在、バインド・タスク・フローとページ定義リソースでサポートされるのは表示アクションのみです)
権限の付与先として、アプリケーションによって定義されるアプリケーション・ロール(同じアクセス権を付与するメンバー・ユーザーまたはエンタープライズ・ロール(オプション)を移入します)

エンティティ・オブジェクトの場合、権限クラスでは読取り、削除および更新アクションが定義されます。

ADF権限クラスとサポートされるアクションの詳細は、付録C「Oracle ADFでの権限付与」を参照してください。

30.1.2 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ユーザー・リポジトリを使用するように構成できます。

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

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

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

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

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

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

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

注意:

Fusion Webアプリケーションの保護に進む前に、ADFセキュリティ・モデルについてよく理解する必要があります。30.1.2項「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サーバーに移行されます。ドメインレベルのストアを使用すると、作成したテスト・ユーザーとしてログオンしてセキュリティ実装をテストできます。

セキュリティのためのすべての設計時ツールは、図30-1に示すようにJDeveloperのメイン・メニューの「アプリケーション」→「保護」メニューの下にあります。

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

設計フェーズ

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

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

ウィザードの実行時に動的認証のみを有効にすることを選択した場合は、残りの設計フェーズのステップはスキップします。このウィザードを使用して、Oracle WebLogic Serverでセキュリティ・フレームワークとOPSSを統合するファイルを構成します。
ADFセキュリティ対応リソースを作成します。構成Webページ(またはリージョン)を含むバインド・タスク・フロー、またはADFバインディングを使用して設計される最上位Webページ(またはリージョン)などです。

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

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

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

テスト・フェーズ

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

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

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

メンバー・ユーザー複数のアプリケーション・ロールのアクセス権を付与する必要がある場合は、1メンバー・ユーザーを複数のアプリケーション・ロールに含めることができます。
デフォルトのログイン・ページをカスタム・ログイン・ページで置き換えます(オプション)。

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

最初にADFセキュリティ対応リソースにアクセスしようとするとき、セキュリティ・フレームワークによってログインを求められます。
ログインし、予定どおりにページとそのリソースにアクセスできることを確認します。

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

ステージングの準備

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

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

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

JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、システム管理者が担当します。
ポリシー・ストアに表示されるアプリケーション・ロールが、最終的に管理者がドメインレベルのグループにマッピングするロールであることを確認します。
ADF Facesリソース・ファイルを保護するセキュリティ制約を定義するかどうかを決定します。

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

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

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

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

注意:

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

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

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

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

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

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

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

30.8.4項「実行時に行われる処理: 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コンポーネントを使用するカスタム・ログイン・ページでデフォルトのログイン・ページを置き換える方法の詳細は、30.7項「ログイン・ページの作成」を参照してください。

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

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

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

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

具体的には図30-2に示すように、ウィザードの最初のページには3つのオプションがあり、デフォルトのオプションとして「ADF認証および認可」が有効になっています。
- 「ADF認証および認可」(デフォルト)では、ADF認証サーブレットが有効化され、ユーザーがログインおよびログアウトする際に構成済のWebページにリダイレクトできます。このオプションを使用すると、ADF認可を有効化して、ADFリソースについて定義したセキュリティ・ポリシーに対する認可チェックを施行することもできます。このオプションを選択した場合は、アプリケーション・ロールを定義し、明示的な権限をそのロールに割り当てて、ADFセキュリティ対応リソースへのアクセスを管理します。
- 「ADF認証」を選択すると、アプリケーションのページが最初にアクセスされたときに、ADF認証サーブレットがユーザーのログインを要求します。また、Java EEアプリケーション・ルート「/」をJava EEセキュリティ制約(ユーザー認証をトリガーする)にマップすることで、ページ・リダイレクトがサポートされます。ウィザードによりADF認可が無効になるため、ADFリソースに対するセキュリティ・ポリシーが存在するかどうかに関係なく、認可チェックは実行されません。一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。
- 「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効化され、ADFセキュリティはポリシー権限を確認できなくなりますが、既存のポリシー・ストアは変更されません。この場合、標準的なJava EEセキュリティを使用して、ユーザーに対して、ログインし、認証を受け、URLセキュリティ制約に対してアクセス権をテストすることことを求めることができます。ウィザードをこのオプションで実行すると、ADFリソースに対するきめ細かいセキュリティが無効になることに注意してください。
図30-2 セキュリティ対応リソースを有効化するためのADFセキュリティの構成ウィザードの使用
「認証タイプ」ページで、ユーザーがログイン情報を送信したときにアプリケーションで使用する認証タイプを選択します。「次へ」をクリックします。

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

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

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

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

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

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

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

他のリダイレクト・オプションの指定の詳細は、30.7.5項「認証後にユーザーをリダイレクトする方法」を参照してください。
サマリー・ページで選択内容を確認し、「終了」をクリックします。

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

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

ADF認証が有効化されます。ユーザーにログインを求め、ページ・リダイレクトを行います。
ADF認可チェックが有効化され、認可ユーザーのみがADFリソースにアクセスできます。

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

表30-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認証および認可」オプションを選択すると、ユーザー認証を動的にトリガーするセキュリティ制約に`adfAuthentication`サーブレットがマッピングされます。ウィザードで「ADF認証」オプションを選択すると、ユーザー認証を動的にトリガーする`allPages`セキュリティ制約に、Java EEアプリケーション・ルート「/」がマッピングされます。ユーザー・ログインを処理するためのログイン構成の認証方式を設定します。 `valid-users`ロールなど、動的認証を有効化するセキュリティ制約をトリガーするために使用される必須セキュリティ・ロールを定義します。
`adf-config.xml`	Webアプリケーション・ワークスペースに相対する`/.adf/META-INF` ディレクトリ JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→ADF META-INFノードの下	JAASセキュリティ・コンテキストを定義します。認可チェックのためにADFセキュリティ・ポリシーを使用できるようにします(`<JaasSecurityContext>`要素の`authorizationEnforce`パラメータが`true`に設定されます)。 ADF Swingアプリケーションなどの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認証サーブレットによる認証を有効化します。例30-1に示すように、ADF認証サーブレットのサーブレット・マッピングが定義され、2つのJava EEセキュリティ制約allPagesとadfAuthenticationがweb.xmlファイルに追加されます。

例30-1 web.xmlファイルのADF認証ディスクリプタ

<servlet>
   <servlet-name>adfAuthentication</servlet-name>
   <servlet-class>
        oracle.adf.share.security.authentication.AuthenticationServlet
   </servlet-class>
   <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>

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

注意:

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

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

注意:

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

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

例30-2 adf-config.xmlファイルでのAuthorizationEnforceフラグの有効化

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

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

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

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

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

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

30.3.4 ADFセキュリティの構成ウィザードについて

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

30.3.5 ADF認証について

Java EEコンテナ管理のセキュリティではログインとログアウト用の標準メソッドが定義されていますが、ADF認証を使用する利点は、アプリケーションがOracle Single Sign-On (Oracle SSO)を使用する場合に同じログアウトを使用できることです。

ADFセキュリティ対応リソースに依存するページが最初にアクセスされたとき、サブジェクトが定義されていないと、anonymousユーザー・プリンシパルとanonymous-roleロール・プリンシパルを含むサブジェクトを構成するようにOPSSがJPSFilterによって構成されます。このロール・プリンシパルを使用すると、認証されていないユーザーが、どのADFセキュリティ対応リソース(ADFバインド・タスク・フローまたはページ定義など)にも関連付けられていないパブリックWebページにアクセスできます。

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

30.3.6 組込みtest-allロールについて

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

30.3.7 valid-usersロールについて

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

例30-4 weblogic.xmlファイルでのvalid-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権限は関係ありません。

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

アプリケーション・ロールを作成して、アプリケーションのポリシー要件を表し、同じview権限を持つユーザーのグループを定義します。アプリケーション・ポリシー・ストアに作成するアプリケーション・ロールは、お使いのアプリケーション固有のものです。たとえば、ワーク・フローのコンテキストでは、fod-customer、fod-productSpecialist、fod-supervisorおよびfod-adminなどのアプリケーション・ロールがあります。fodはこれらのロールがFusion Order Demoアプリケーション固有であることを示します。

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

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

権限をアプリケーション・ロールに付与します。30.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
テスト・ユーザーを各アプリケーション・ロールに関連付けます。30.6項「テスト・ユーザーの作成」を参照してください。

ベスト・プラクティス:

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

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

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

注意:

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

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

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

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

JDeveloperによってjazn-data.xmlファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。
「ロール」リストで「新規」アイコンをクリックします。
「名前」フィールドにロール名を入力します。他のいずれかのフィールドをクリックすると、アプリケーション・ロールがポリシー・ストアに追加されます。
テスト・ユーザーをアイデンティティ・ストアにすでに設定している場合は、30.6.3項「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」に従ってユーザーとロールをマッピングできます。

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

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

例30-5 ポリシー・ストアでのアプリケーション・ロール定義

<policy-store>
     <applications>
         <application>
            <name>StoreFrontModule</name>
            <app-roles>
               <app-role>
                  <name>fod-users</name>
                  <display-name>FOD Users</display-name>
                  <class>oracle.security.jps.service.policystore.
                                                        ApplicationRole</class>
               </app-role>
               ...
            </app-roles>
            <jazn-policy>
              ...
            </jazn-policy>
         </application>
    </applictions>
</policy-store>

30.4.3 エンタープライズ・ロールとアプリケーション・ロールについて

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

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

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

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

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

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

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

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

ベスト・プラクティス:

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

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

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

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

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

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

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

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

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

注意:

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

作業を始める前に、次のようにします。

バインド・タスク・フローを作成します。14.2項「タスク・フローの作成」を参照してください。
ADFページ定義ファイルを含むWebページを作成します。12.6項「ページ定義ファイルでの作業」を参照してください。
ADFセキュリティの構成ウィザードを実行します。30.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。30.4項「アプリケーション・ロールの作成」を参照してください。

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

「アプリケーション」メニューから「保護」→「リソース権限」を選択します。
jazn-data.xmlファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから次のいずれかのリソースを選択します。
- 「タスク・フロー」(バインド・タスク・フローを公開する場合)。アプリケーションによって、タスク・フローそのものに定義した権限の下でWebページが表示されます。つまり、バインド・タスク・フローのすべての構成Webページが公開されます。
- 「Webページ」(個別のWebページを公開する場合)。通常、これらのページは無制限タスク・フローに定義された、アプリケーションのトップレベル・ページ(ホームページなど)です。
「リソース」列で、アクセス権を付与するADFリソースを選択します。

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

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

図30-4 概要エディタでのADFセキュリティ対応リソースの選択
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、次の組込みアプリケーション・ロールから1つを選択します。
- anonymous-roleは、サイトにアクセスするすべてのユーザーがリソースにアクセスできることを意味します。このロールへの権限付与が必要となるのは、ユーザーがログインしなくても、ADFセキュリティ対応リソースに関連するWebページにアクセスできるようにする場合です。たとえば、顧客の登録を管理するタスク・フローについてanonymous-roleに権限を付与します。
- authenticated-roleは、認証されたユーザー(サイトにアクセスしてログインしたユーザー)のみがリソースにアクセスできることを意味します。たとえば、従業員登録のタスク・フローについてauthenticated-roleに権限を付与します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列では、Viewアクションが選択されたままにしておきます。

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

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

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

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

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

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

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

例30-6 アプリケーションレベルのポリシー・ストアでのanonymous-roleに対する権限

<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>

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

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に設定され、ユーザーがログインした後でも匿名ロール・プリンシパルが使用可能になります。認証ロール・プリンシパルを使用すると、認証ロールに対して明示的に権限が付与されたリソースにユーザーがアクセスできます。

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

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

ベスト・プラクティス:

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

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

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

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

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

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

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

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

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

作業を始める前に、次のようにします。

バインド・タスク・フローを作成します。14.2項「タスク・フローの作成」を参照してください。

ベスト・プラクティス:

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

ADFセキュリティの構成ウィザードを実行します。30.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。30.4項「アプリケーション・ロールの作成」を参照してください。

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

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

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

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

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

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

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

アプリケーション固有のアプリケーション・ロールが表示されていない場合は、30.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列では、viewアクションが選択されたままにしておきます。

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

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

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

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

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

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

ベスト・プラクティス:

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

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

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

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

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

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

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

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

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

作業を始める前に、次のようにします。

ADFページ定義ファイルを含むトップレベルWebページを作成します。12.6項「ページ定義ファイルでの作業」を参照してください。

ベスト・プラクティス:

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

ADFセキュリティの構成ウィザードを実行します。30.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。30.4項「アプリケーション・ロールの作成」を参照してください。

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

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

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

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

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

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

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

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

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

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

アプリケーション固有のアプリケーション・ロールが表示されていない場合は、30.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列では、viewアクションが選択されたままにしておきます。

デフォルトでは、図30-10のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。customize、grantまたはpersonalizeの各アクションは、Oracle WebCenter Portal: Frameworkアプリケーションまたはカスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できる)で使用するために実装されています。

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

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

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

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

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

例30-7に示すjazn-data.xmlファイルのセキュリティ・ポリシーでは、チェックアウト・タスク・フローが保護され、ユーザーがアカウント情報を更新できるトップレベルWebページが保護されます。fod-usersアプリケーション・ロールに対する権限には、バインド・タスク・フローcheckout-task-flowのview権限と、account_updateUserInfoPageDefページ定義を含むWebページのview権限が含まれます。この権限を使用すると、fod-usersアプリケーション・ロールのメンバーとして認証されたユーザーだけが、チェックアウト・タスク・フローを開始したり、ユーザー情報更新ページを表示したりすることができます。

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

例30-7 アプリケーションレベル・ポリシー・ストアの権限

<policy-store>
    ...
    <jazn-policy>
        <grant>
            <grantee>
                <principals>
                    <principal>
                        <class>oracle.security.jps.service.policystore.ApplicationRole</class>
                         <name>fod-users</name>
                     </principal>
                 </principals>
             </grantee>
             <permissions>
                  <permission>
                      <class>oracle.adf.controller.security.TaskFlowPermission</class>
                      <name>/WEB-INF/checkout-task-flow.xml#checkout-task-flow</name>
                      <actions>view</actions>
                  </permission>
                   <permission>
                        <class>oracle.security.jps.service.policystore.ApplicationRole</class>
                        <name>oracle.fodemo.storefront.pageDefs.acct_updateUserInfoPageDef</name>
                        <actions>view</actions>
                  </permission>
                  ...
             </permissions>
        </grant>
        ...
    </jazn-policy>
</policy-store>

30.5.7 実行時に行われる処理: 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を使用してアプリケーションを実行する前に、テスト・ユーザーを含むアイデンティティ・ストアをプロビジョニングし、構成するアプリケーション・ロールにそれらのユーザーを追加する必要があります。30.6項「テスト・ユーザーの作成」で説明するように、アプリケーション・ロールでは、ユーザーまたはユーザー・グループ(エンタープライズ・ロール)に固有のメンバーを定義できます。

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

ページがバインド・タスク・フローのアクティビティである場合は、タスク・フロー・コントローラによって権限が決まります。
ページが、ページ定義ファイルが関連付けられたトップレベル・ページである場合は、ADFモデルによって権限が決まります。

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

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

30.5.8 ADFバインドなしのページのポリシー定義について

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

ページにデータバインドADF Facesコンポーネントが表示されず、ページにADFページ定義が存在していない場合。
ページがデータバインドADFタスク・フローの構成ページでない場合。(ユーザーがバインド・タスク・フローのプロセスとしてアクセスするすべてのページは、タスク・フローの権限でチェックされます。)

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

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

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

アプリケーション・ナビゲータで、保護するWebページを探し、右クリックして「ページ定義に移動」を選択します。
確認ダイアログで「はい」をクリックすると、ページの新しいページ定義が作成されます。

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

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

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

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

例30-8 アプリケーションレベル・ポリシー・ストアに定義されたフォルダ全体のタスク・フロー権限

...
<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権限を付与すると同時に、正規表現で除外セットを定義して特定のページ定義を除くことができます。例30-9は、customで始まるページ定義名を除いたすべてのページに関してanonymous-roleにview権限を付与する方法を示しています。

例30-9 正規表現とメタ文字を使用したポリシー権限の定義

<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>

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

表30-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を除く
.*	任意の個数の任意の文字(この表現ではピリオドとアスタリスクを一緒に使用することに注意)

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

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

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

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

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

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

エンティティ・オブジェクトまたはその個々の属性の操作を保護できます。

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

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

表30-8 ADFビジネス・コンポーネントのセキュア化できる操作

ADFコンポーネント	セキュアな操作	想定されるマップされたアクション	対応する実装
ADFビジネス・コンポーネント・エンティティ・オブジェクト	`read`	`Read`	`WHERE`句フラグメントで制限された、数行の結果セットを表示します。
	`update`	`Update`	バインドされたコレクションの属性を更新します。
	`removeCurrentRow`	`Delete`	バインドされたコレクションの1つの行を削除します。
エンティティ・オブジェクトのADFビジネス・コンポーネント属性	`update`	`Update`	バインドされたコレクションの特定の属性を更新します。

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

作業を始める前に、次のようにします。

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

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

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

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

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

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

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

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

アプリケーション・ナビゲータに表示されるデータ・モデル・プロジェクトで、セキュア化する属性を定義しているエンティティ・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
属性ページで該当する属性を選択し、「セキュリティ」セクションを開き、エンティティ・オブジェクト属性について保護する操作を選択します。

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

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

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

30.5.10.2 ADFエンティティ・オブジェクトの権限の付与

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

既存のエンティティ・オブジェクトの権限ターゲットのアクセス・ポリシーを定義するには、「認可の編集」ダイアログを使用します。

作業を始める前に、次のようにします。

ADFセキュリティの構成ウィザードを実行します。30.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。30.4項「アプリケーション・ロールの作成」を参照してください。
30.5.10.1項「ADFエンティティ・オブジェクトに対する権限マップの定義」の説明に従って、エンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について権限ターゲットを定義します。

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

アプリケーション・ナビゲータに表示されるデータ・モデル・プロジェクトで、エンティティ・オブジェクトを選択します。
選択したエンティティ・オブジェクトまたはエンティティ・オブジェクト属性の構造ウィンドウで、右クリックして、「認可の編集」を選択します。

「認可の編集」ダイアログに、エンティティ・オブジェクト(または属性)に実行できるアクション(表30-8)が表示されます。このダイアログには、jazn-data.xmlポリシー・ストアのアプリケーション・ロールも表示されます。組込みアプリケーション・ロールのanonymous-roleおよびauthenticated-roleが、アプリケーション開発者が作成したアプリケーション・ロールと一緒に表示されます。
ダイアログで、個別のアプリケーション・ロールに対して許可するアクションを選択します。

たとえば、fod-usersアプリケーション・ロールに「更新」および「削除」権限を付与するには、図30-13に示すように、それらのアクションを選択します。

アプリケーション・ロールに付与された権限がjazn-data.xmlファイルに表示されます。

図30-13 エンティティ・オブジェクトのアクセス・ポリシーの定義

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

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

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

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

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

注意:

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

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

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

「アプリケーション」メニューから「保護」→「ユーザー」を選択します。
jazn-data.xmlファイルの概要エディタのユーザー・ページで、「レルム」ドロップダウン・メニューからアプリケーションのレルムを選択し、次の手順を実行します。

JDeveloperによってデフォルト・レルムjazn.comが自動的に作成されます。
1. 「ユーザー」リストで「新規ユーザー」アイコンをクリックします。
2. 「名前」フィールドにユーザー名を入力します。
  
  Oracle WebLogic Serverに対してすでに構成されているユーザー名を選択しないでください(たとえば、webcenterは入力しないでください)。Oracle WebLogic Serverによりインストールされているユーザー名のリストは、『Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
3. 「パスワード」フィールドにユーザーのパスワードを入力します。他の任意のフィールドをクリックすると、パスワードがアイデンティティ・ストアに追加されます。
  
  パスワードは8文字以上で指定し、特殊文字(!、%、^、&、$など)を少なくとも1つ含める必要があります。
必要であれば、jazn-data.xmlファイルの概要エディタで、「エンタープライズ・ロール」ナビゲーション・タブをクリックし、アプリケーションのレルムを「レルム」ドロップダウン・メニューから選択して次の手順を実行します。

ユーザーをグループ分けしてアプリケーション・ロールに追加する場合のみ、エンタープライズ・ロールを作成します。統合WebLogic Serverを使用してアプリケーションを実行するためのテスト・ユーザーを作成する目的であれば、エンタープライズ・ロール・グループを作成する必要はありません。
1. 「エンタープライズ・ロール」リストで「新規ロール」アイコンをクリックします。
2. 「名前」フィールドにエンタープライズ・ロール名を入力します。他のいずれかのフィールドをクリックすると、ロールがアイデンティティ・ストアに追加されます。
  
  エンタープライズ・ロール・グループを作成する場合、Oracle WebLogic Serverに対してすでに構成されているロール名を選択しないでください(たとえば、Administratorsは入力しないでください)。Oracle WebLogic Serverによりインストールされている全デフォルト・グループ名のリストは、『Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

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

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

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

例30-10に、2つのユーザーと2つのエンタープライズ・ロールを含むjazn-data.xmlファイルのアイデンティティ・ストアを示します。ユーザーahunoldとskingは両方ともfod-usersエンタープライズ・ロールのメンバーで、skingのみがfod-adminエンタープライズ・ロールのメンバーです。

例30-10 アプリケーションレベル・アイデンティティ・ストアのユーザーとエンタープライズ・ロール

<jazn-data>
   <jazn-realm default="jazn.com">
      <realm>
         <name>jazn.com</name>
         <users>
            <user>
               <name>sking</name>
               <guid>09FC5C61F68111DCAF1DB790A6B3BAC5</guid>
               <credentials>{903}A0VQ5ozADte7EKIJzcTi6xMZ7YDpRXY5</credentials>
            </user>
            <user>
               <name>ahunold</name>
               <guid>09FEA650F68111DCAF1DB790A6B3BAC5</guid>
               <credentials>{903}/SQSrKZYCLW068VJpHaodILd48mJI47w</credentials>
            </user>
            ...
         </users>
         <roles>
            <role>
               <name>fod-users</name>
               <guid>0A084340F68111DCAF1DB790A6B3BAC5</guid>
               <members>
                  <member>
                     <type>user</type>
                     <name>sking</name>
                  </member>
                  <member>
                     <type>user</type>
                     <name>ahunold</name>
                  </member>
                  ...
               </members>
            </role>
            <role>
               <name>fod-admin</name>
               <guid>0A0CFE30F68111DCAF1DB790A6B3BAC5</guid>
               <members>
                  <member>
                     <type>user</type>
                     <name>sking</name>
                  </member>
                  ...
               </members>
            </role>
            ...
         </roles>
      </realm>
      ...
   </jazn-realm>
</jazn-data>

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

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

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

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

作業を始める前に、次のようにします。

ADFセキュリティの構成ウィザードを実行します。30.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。30.4項「アプリケーション・ロールの作成」を参照してください。
ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義します。30.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
テスト・ユーザーを作成し、必要に応じてエンタープライズ・ロール・グループを作成します。30.6.1項「JDeveloperでテスト・ユーザーを作成する方法」を参照してください。

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

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

JDeveloperによってjazn-data.xmlファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。
「ロール」リストで既存のアプリケーション・ロールを選択し、必要に応じて次のタスクを実行します。
1. 「マッピング」セクションで、「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「ユーザーの追加」を選択します。次に、「ユーザーの選択」ダイアログで、前に作成したユーザーをリストから選択して「OK」をクリックします。
2. アイデンティティ・ストアにエンタープライズ・ロールを定義している場合、必要であれば、「マッピング」セクションで「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「エンタープライズ・ロールの追加」を選択します。次に、「エンタープライズ・ロールの選択」ダイアログで、前に作成したエンタープライズ・ロールをリストから選択して「OK」をクリックします。

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

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

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

例30-11に、jazn-data.xmlファイルのポリシー・ストアを示します。ここには、2つのメンバーskingとahunoldを含むfod-usersアプリケーション・ロールがあります。

例30-11 アプリケーションレベル・ポリシー・ストアでのユーザーとアプリケーション・ロールの関連付け

<policy-store>
     <applications>
         <application>
            <name>StoreFrontModule</name>
            <app-roles>
               <app-role>
                  <name>fod-users</name>
                  <display-name>FOD Users</display-name>
                  <class>oracle.security.jps.service.policystore.ApplicationRole</class>
                  <members>
                     <member>
                        <class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class>
                        <name>sking</name>
                     </member>
                     <member>
                        <class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class>
                        <name>ahunold</name>
                     </member>
                     ...
                  </members>
               </app-role>
               ...
            </app-roles>
            <jazn-policy>
              ...
            </jazn-policy>
         </application>
    </applictions>
</policy-store>

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

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

暗黙的な認証のシナリオでは、未認証のユーザーがアクセスしようとするWebページが、anonymous-roleに権限付与されていないADFセキュリティ対応リソースに関連付けられている場合、認証が動的にトリガーされます。ユーザーが正常にログインすると、認証されたユーザーが、リクエストしたページのADFセキュリティ対応リソースに対するviewアクセス権を付与されているかどうかを検証するために別のチェックが実行されます。
明示的な認証のシナリオでは、ログイン・リンクが表示された公開ページがアプリケーションに用意され、このリンクをクリックすると、そのユーザーのログインにおいて認証チャレンジがトリガー実行されます。ログイン・リンクには、認証が成功した後に表示するいくつかの他のターゲット・ページ(認証済ユーザーがアクセス権を持っている場合)を指定できます。

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

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

注意:

次の明示的な認証の処理方法では、Fusion WebアプリケーションをOracle WebLogic Serverにデプロイすることを前提としています。記載されているJSFベースのログイン・ページに対するユーザー・インタフェースはプログラム的な認証に依存しており、Oracle WebLogic Serverおよびそれによりサポートされるログイン・プロセスに固有のAPIを使用します。この方法ではフォームベース認証のかわりに、カスタム・ログイン・ページとの互換性が最も高いプログラム的な認証を使用します。

ログイン・リンク・コンポーネントを作成し、アプリケーションのパブリック・ホームページに追加します。
Oracle WebLogic Server固有のAPIを使用して、ユーザーによるログインの試行を処理するマネージドBeanを作成します。
ADF Facesコンポーネントを使用して、JSFログイン・ページを作成します。
ログイン・ページのリソースがアクセス可能であることを確認します。

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

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

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

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

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

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

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

作業を始める前に、次のようにします。

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

注意:

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

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

アプリケーション・ナビゲータで、コンポーネントを表示するWebページをダブルクリックします。
コンポーネント・パレットのADF Facesページで「実行イメージ・リンク」を選択してページまでドラッグします。
構造ウィンドウでaf:goImageLinkを右クリックし、「プロパティに移動」を選択します。
プロパティ・インスペクタで、条件式言語(EL)式で指定されるリンク・テキストをレンダリングするように、実行イメージ・リンク・コンポーネントのTextプロパティを設定します。

たとえば、次のようなEL式を入力できます。
```
#{securityContext.authenticated ? &quot;Click to log out&quot; : 
                                  &quot;Click to log in&quot;}
```
現在のユーザーが認証されると、securityContext Beanのauthenticatedプロパティがtrueに評価され、ログアウト・オプションがレンダリングされます。それ以外の場合はログイン・オプションのリンクがレンダリングされます。
プロパティ・インスペクタで、条件EL式で指定されるURLにユーザーを転送するように、実行イメージ・リンク・コンポーネントのDestinationプロパティを設定します。

たとえば、次のようなEL式を入力できます。
```
#{securityContext.authenticated ? &quot;/adfAuthentication?logout=true&amp;
                                    end_url=/faces/welcome&quot; :
                &quot;/adfAuthentication?success_url=/faces/welcome&quot;}
```
ユーザーがリンクをクリックすると、URLパラメータend_urlおよびsuccess_urlがターゲット・ページの宛先をADF認証サーブレットに転送します。Webページ名のかわりにビュー・アクティビティ名がURLパラメータで渡されます。これにより、ログイン後のページ・ナビゲーションで制御フロー・ルールが施行されます。現在のユーザーが認証されると、securityContext Beanのauthenticatedプロパティがtrueに評価され、ようこそページに転送されます。ユーザーが認証されない場合、ログイン・ページに転送する必要はありません。ADF認証サーブレットでトリガーされるログインは、コンテナ管理セキュリティ構成によって処理されるためです。ログアウトは、セッションを無効にするADF認証サーブレットによって処理されることに注意してください。ログアウトはADFセキュリティによって処理されますが、プロセスを完了するためにブラウザ・キャッシュを消去する必要があります。Basic認証とブラウザ・キャッシュに関連する既知の問題の詳細は、30.7.7項「ADFサーブレットのログアウトとブラウザのキャッシュについて」を参照してください。
実行イメージ・リンク・コンポーネントのリンク・コンポーネントを指定するには、プロパティ・インスペクタで「アイコン」フィールドにEL式を入力します。

たとえば、次のEL式は条件に応じて、ユーザーが認証されない場合にリンク・コンポーネント・イメージをロックのGIFとしてレンダリングします。それ以外の場合は、キーのGIFでイメージをレンダリングします。
```
#{securityContext.authenticated ? "/images/lock.gif" : "/images/key.gif"}
```
図30-16に、ログイン・リンク・コンポーネントをグローバル・メニュー・ファセットに追加するとどのように表示されるかを示します。

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

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

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

図30-17 ログイン・ページ

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

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

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

このバッキングBeanの例で使用されるOracle WebLogic Server APIは、ログイン・ページを表示する際に、ユーザーの現在のページ(ホームページなど)から認証を実行し、アプリケーションが現在のページから移動しないようにするために使用することもできます。

注意:

この手順で作成するバッキングBeanは、Oracle WebLogic Server固有のAPIとOracle WebLogic Serverでサポートされるログイン・プロセスに依存することに注意してください。Oracle WebLogic ServerにFusion Webアプリケーションをデプロイする場合のみ、この手順を使用します。

作業を始める前に、次のようにします。

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

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

バッキングBeanを作成するユーザー・インタフェース・プロジェクトで、次のライブラリをプロジェクトにインポートします。
- WebLogic 10.3 Remote-Client
ライブラリをインポートするには、「アプリケーション」ウィンドウでユーザー・インタフェース・プロジェクトのノードをダブルクリックします。「プロジェクト・プロパティ」ダイアログで、「ライブラリとクラスパス」をクリックしてから「ライブラリの追加」を選択します。「ライブラリの追加」ダイアログで「拡張」ノードを開き、WebLogic 10.3 Remote-Clientライブラリまでスクロールして追加します。ユーザー・インタフェース・プロジェクトがこのライブラリを使用することで、、バッキングBeanコード・サンプルの次のimport文をコンパイルして解決できます。
```
import weblogic.security.URLCallbackHandler;
import weblogic.servlet.security.ServletAuthentication;
```
ライブラリの作成方法とプロジェクトへの追加方法の詳細は、JDeveloperオンライン・ヘルプを参照してください。

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

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

たとえば、LoginPageName.javaのように、ログイン・ページ名に基づいてバッキングBeanの名前を付けると便利です。
アプリケーション・ナビゲータで「アプリケーション・ソース」ノードを開き、新しいLoginPageName.javaバッキングBeanをダブルクリックします。
ソース・エディタで、LoginPageName.javaファイルの宣言セクションに次のコードを追加して2つのprivateフィールドを作成します。
```
private String _username;
private String _password;
```
両方のフィールドのパブリック・アクセッサを生成または作成します。

ソース・エディタを右クリックして、「アクセッサの生成」を選択すると、次のパブリック・アクセッサがファイルに追加されます。
```
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;
}
```
doLogin()メソッドをこのJavaクラスに追加して、ユーザーのログイン試行を処理します。
```
1 public String doLogin() {
2   String un = _username;
3   byte[] pw = _password.getBytes();
4   FacesContext ctx = FacesContext.getCurrentInstance();
5   HttpServletRequest request =
6                  (HttpServletRequest)ctx.getExternalContext().getRequest();
7   try {
8       CallbackHandler handler = new URLCallbackHandler(un, pw);
9       Subject mySubj = 
10                 weblogic.security.services.Authentication.login(handler);
11      weblogic.servlet.security.ServletAuthentication.runAs(mySubj, request);
12      ServletAuthentication.generateNewSessionID(request);
13      String loginURL = "faces/mylandingpage.jspx";
14      sendForward(loginURL);
15   } catch (FailedLoginException fle) {
16      FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR,
17                                        "Incorrect Username or Password",
18                                        "An incorrect Username or Password" +
19                                        " was specified");
20      ctx.addMessage(null, msg);
21      setPassword(null);
22   } catch (LoginException le) {
23      reportUnexpectedLoginError("LoginException", le);
24   }
25   return null;
26 }
```
doLogin()メソッドは、次のタスクを実行します。

行4 - 6は、FacesContextからのHTTPリクエストをカプセル化するオブジェクトを取得します。

行8はCallbackHandlerを作成します。これは、セキュリティ操作のための情報を取得するオブジェクトです。URLCallbackHandlerにより、セキュリティ操作が、コンストラクタに渡されたユーザー名とパスワードを取得できるようになります。他のCallbackHandler実装は別のソースからユーザー名とパスワードを取得できます。

行9 - 10はSubjectを作成します。これは、CallbackHandlerによって提供される情報から資格証明をカプセル化するオブジェクトです。

行11は、Subjectによってカプセル化された資格証明を使用して、リクエストを発行するユーザーのログインを実行しようとします。

行12は、ユーザーが正常に認証された後で、セッションのセッションIDを確実に変更するようにします。これは、セキュリティの脆弱性を招くセッション固定攻撃に対してアプリケーションをオープンにしないために必要です。

行13はログイン成功後のユーザーの転送先URLを作成します。このログインBeanの例では、認証は全面的にOracle WebLogic Serverによって処理されます。この例はプラットフォーム固有であるため、ADF認証サーブレットを起動してログイン後にリダイレクトする必要はありません。ADFセキュリティ認証サーブレットは、プラットフォーム独自のJava EEコンテナ管理ログインを実装して暗黙的な認証を実装する場合に便利です。

行14はメソッドsendForward()をコールします。このメソッドは、行13で指定されたURLにユーザーを転送するためにこの項で後から実装します。

行15 - 21はFailedLoginExceptionを処理します。これは、入力された資格証明が正しくないときにスローされる例外です。新しいメッセージをFacesContextに追加して例外を処理します。

行22 - 23はLoginExceptionを処理します。これは、ログインにかかわる多様な問題によってスローされます。たとえば、資格証明が正しくない場合、ロックされたアカウントにログインを試行した場合、または期限切れパスワードを使用した場合に例外が生成されます。FailedLoginExceptionはLoginExceptionのサブクラスですが、FailedLoginExceptionは行17で捕捉されるため、不正確な資格証明以外のログインの問題がある場合のみ、これらの行が実行されます。reportUnexpectedLoginError()は、ログイン・プロセスの様々な問題を処理するために実装するメソッドです。

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

次のクラスをインポートします。

javax.faces.application.FacesMessage
javax.faces.context.FacesContext
javax.security.auth.Subject
javax.security.auth.callback.CallbackHandler
javax.security.auth.login.FailedLoginException
javax.security.auth.login.LoginException
javax.servlet.http.HttpServletRequest
weblogic.security.URLCallbackHandler
weblogic.servlet.security.ServletAuthentication

メソッドsendForward()およびreportUnexpectedLoginError()のスタブを作成します。
アクションを含むsendForward()メソッドを追加します。
```
1  private void sendForward(String forwardUrl) {
2    FacesContext ctx = FacesContext.getCurrentInstance();
3    try {
4      ctx.getExternalContext().redirect(forwardUrl);
5    } catch (IOException ie) {
6      reportUnexpectedLoginError("IOException", ie);
7    }
8     ctx.responseComplete();
9  }
```
sendForward()メソッドは、次のタスクを実行します。

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

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

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

行8はHTTPレスポンスを完了とマークして、ブラウザがレンダリングを終了できるようにします。

次のクラスをインポートします。

javax.servlet.RequestDispatcher
javax.servlet.ServletException
java.io.IOException

reportUnexpectedLoginError()メソッドを実装します。

private void reportUnexpectedLoginError(String errType, Exception e){
  FacesMessage msg =
    new FacesMessage(FacesMessage.SEVERITY_ERROR, "Unexpected error 
                                                          during login",
                     "Unexpected error during login (" + errType + "),
                        please consult logs for detail");
  FacesContext.getCurrentInstance().addMessage(null, msg);
  FacesContext.getCurrentInstance().renderResponse();
}

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

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

たとえば、クラス名は図30-18のoracle.foddemo.security.Loginのようになります。

図30-18 adfc-config.xmlファイルに登録されたログインBean
すべてを保存します。

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

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

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

作業を始める前に、次のようにします。

ユーザーのログイン試行を処理するマネージドBeanを作成します。30.7.2.1項「バッキングBeanのログイン・コードの作成」を参照してください。

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

アプリケーション・ナビゲータの、ユーザー・インタフェース・プロジェクトの下の部分で、アプリケーションを右クリックして「新規」を選択します。
「新規ギャラリ」で「Web層」を展開し、「JSF」、「JSFページ」の順に選択し、「OK」をクリックします。
「JSFページの作成」ダイアログで、「XMLドキュメントの作成(*.jspx)」を選択します。
「ファイル名」フィールドで、ログイン・ページの名前を指定します。たとえば、LoginPage.jspxを入力します。

他のオプションは選択しません。また、マネージドBeanでUIコンポーネントを公開するオプションは選択しないでください。ログイン・ページのために作成したマネージドBeanにコンポーネントを手動でバインドします。
「OK」をクリックします。
ページを保存します。
コンポーネント・パレットのADF Facesページで、「レイアウト」パネルから「パネル・ボックス」コンポーネントを選択し、構造ウィンドウのaf:formの下にドラッグします。
「プロパティ・インスペクタ」で、「テキスト」、「水平方向」、「幅」および「高さ」プロパティを設定します。

たとえば、Fusion Order DemoアプリケーションのMaster Price Listモジュールに表示されるログイン・ページを再作成するには、次のように入力します。

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

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

「幅」および「高さ」に300および200ピクセルを設定します。
コンポーネント・パレットの「パネル・フォーム・レイアウト」コンポーネントを、図30-19のように構造ウィンドウのaf:panelBoxタグの下にドラッグします。

図30-19 パネル・フォーム・レイアウトのログイン・ページ構造
コンポーネント・パレットのADF Facesページで、「入力テキスト」コンポーネントをユーザー名フィールドの「パネル・フォーム・レイアウト」コンポーネントにドラッグし、もう1つの「入力テキスト」コンポーネントをパスワード・フィールドにドラッグします。
「プロパティ・インスペクタ」で、入力フィールドの「ラベル」プロパティにUsernameとPasswordを設定し、両方のフィールドの「動作 - 必須」プロパティにtrueを設定します。
「プロパティ・インスペクタ」で、パスワード・フィールドの「外観 - 機密」プロパティにtrueを設定します。
2つの入力フィールドの値を処理するために、各フィールドで次の手順を実行します。
1. 構造ウィンドウで、入力フィールドの1つを選択し(たとえば、af:inputText - Usernameタグを選択し)、「プロパティ・インスペクタ」で「値プロパティの右側にある「プロパティ・メニュー」アイコンをクリックして、「式ビルダー」を選択します。
2. 「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、Beanのハンドラ・メソッドに対応する式の値を選択します。
  
  たとえば、構造ウィンドウでusername入力フィールドを選択した場合は、図30-20のように「式ビルダー」ダイアログでusernameを選択します。
  
  図30-20 「式ビルダー」ダイアログでのusernameの選択
3. 「OK」をクリックします。
  
  「プロパティ・インスペクタ」に表示される式により、ログイン・ページのために作成したマネージドBeanにフィールドがバインドされます。たとえば、username入力フィールドの場合、式は#{loginPageBean.username}のようになります(図30-21)。
  
  図30-21 「プロパティ・インスペクタ」でのusernameの値
コンポーネント・パレットの「パネル枠線レイアウト」コンポーネントを、図30-22のようにaf:panelBoxタグのfooterフォルダの内側にドラッグします。

図30-22 ログイン・ページ構造とパネル枠線レイアウト
JSP/HTMLビジュアル・エディタで、ラベルが「端」、「上」および「下」のパネル枠線レイアウト・ファセットを削除します。「開始」ファセットのみを残します。
構造ウィンドウで、「パネル枠線レイアウト」ファセットのフォルダを開き、startフォルダを選択してから、コンポーネント・パレットで「ボタン」コンポーネントを選択します。
「プロパティ・インスペクタ」で、ボタン・コンポーネントの「テキスト」プロパティをLoginに設定します。
ログイン・ボタンのアクションを処理するには、次の手順を実行します。
1. 構造ウィンドウでstartフォルダにあるログインのaf:commandButtonタグを選択したら、「プロパティ・インスペクタ」で「アクション」プロパティの右側の「プロパティ・メニュー」アイコンをクリックして、「式ビルダー」を選択します。
2. 「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、ログイン・メソッドに対応する式の値を選択します。
  
  たとえば、ログインBeanにdoLogin()という名前のメソッドを作成した場合は、「式ビルダー」ダイアログでdoLoginを選択します。
3. 「OK」をクリックします。
  
  「プロパティ・インスペクタ」に表示される式により、ログイン・ページのために作成したマネージドBeanにボタンがバインドされます。たとえば、ログイン・ボタンの場合、式は#{loginPageBean.doLogin}のようになります(図30-23)。
  
  図30-23 「プロパティ・インスペクタ」でのログインのアクション
ページを保存します。

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

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

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

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

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

例30-12 ADF認証専用のJava EEセキュリティ制約

<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)によってすべてのリソース・ファイルが除外されます。

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

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

ベスト・プラクティス:

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

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

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

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

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

たとえば、3つのコンポーネント(出力テキスト領域、イメージ、実行リンク)を含むADF Facesパネル・グループを作成できます。適切なログイン・リンクまたはログアウト・リンクをレンダリングするために、ユーザーの認証ステータスを評価するEL式を使用できます。特に、securityContext.authenticatedを使用すると、例30-13に示すようにADFセキュリティ・コンテキストにアクセスできます。この式はtrueまたはfalseとして評価され、この例では、結果によって、表示するログイン・イメージまたはログアウト・イメージとリンクが決まります。例30-13に示すように、ADF認証サーブレットのsuccess_urlおよびend_urlパラメータは、ターゲット・ページwelcome.jspxと関連付けられたビュー・アクティビティwelcomeとして渡されます。URLパラメータに対するWebページ名ではなく、ビュー・アクティビティ名を渡すことで、Fusion Webアプリケーションではページ・ナビゲーションの処理にタスク・フローの制御フロー・ルールが使用されるようになります。

例30-13 ログイン/ログアウト・リンクをレンダリングするADF FacesコンポーネントとEL式

<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:goLink text="#{securityContext.authenticated ? &quot;Logout&quot; : &quot;Login&quot;}"
                destination="#{securityContext.authenticated ? 
                       &quot;/adfAuthentication?logout=true&amp;end_url=/faces/welcome&quot; : 
                            &quot;/adfAuthentication?success_url=/faces/welcome&quot;}"
                inlineStyle="color:Blue; font-size:14px; font-weight:bold;"/>
      <f:facet name="separator">
         <af:spacer width="5" height="10" id="pts1"/>
      </f:facet>
</af:panelGroupLayout>

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

30.7.4.3 保護されたページへのリンクの非表示化

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

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

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

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

暗黙的な認証を実装することを選択した場合は、ユーザーが保護されたWebページにアクセスしてログインした後、ADF認証サーブレットは、ログイン・リクエストが発行された最初のページにユーザーをリダイレクトします。ADFセキュリティ認証が有効な場合、ADF認証サーブレットは、URLに対するADF認証のsuccess_urlパラメータとして元のページを自動的に渡します。通常、これは必要な動作です。ただし、ページ内に明示的なログイン・リンクを表示する場合は、一般的にターゲットの宛先は保護されたページになります。認証後、保護されたページへのリダイレクトがADF認証サーブレットによって確実に行われるように、例30-14に示すように、Webページのビュー・アクティビティ名をサーブレットのsuccess_urlパラメータとして渡します。

例30-14 success_urlを含むWebページの明示的なログイン・リンク

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

さらに、元のページにリダイレクトできないケースを処理するために、web.xmlファイル内でsuccess_urlパラメータを<init-param>として指定できます。こうすると、保護されたWebページにユーザーがアクセスし、ログインのためにリダイレクトされるとき、フレームワークによって、元のページがURLのsuccess_urlパラメータとして自動的に渡され、web.xmlの設定よりも優先されます。したがって、web.xmlの<init-param>設定が有効になるのは、ユーザーがadfAuthentication URLをブラウザに明示的に入力する場合のみです。

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

例30-15 タスク・フローを使用するアプリケーションのエラー・ページ・リダイレクト

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

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

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

注意:

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

例30-16 タスク・フローを使用しないアプリケーションのエラー・ページ・リダイレクト

<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>

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

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

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

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

注意:

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

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

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

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

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

30.7.7 ADFサーブレットのログアウトとブラウザのキャッシュについて

アプリケーションのweb.xmlファイルの指定に基づいてBasic認証が有効な場合、ブラウザは認証資格証明をキャッシュします。これはBasic認証の既知の問題です。ADF認証サーブレットがログアウトを完了できず、ユーザーがログアウト後もリソースにアクセスできます。このシナリオでは、ログアウト・セッションを完了するために、ブラウザを閉じて新しいブラウザ・セッションを再起動する必要があります。ADF認証サーブレットがログアウトを完了し、ログアウト後はユーザーがリソースにアクセスできないようにするには、Basic認証のかわりにフォームベース認証を使用します。30.3.1項「ADFセキュリティを有効化する方法」で説明するように、ADFセキュリティの構成ウィザードを実行してフォームベース認証を選択できます。

30.7.8 IBM WebSphere Application Serverについて

アプリケーションをIBM WebSphereアプリケーション・サーバーにデプロイし、同じマシンを使用してWebSphere管理コンソールにログインすると、アプリケーションにログインしたユーザーの名前ではなく管理コンソールにログインしたユーザーの名前がアプリケーションによって表示されます。通常は、認証されたユーザーをテストする式(#{securityContext.authenticated ? securityContext.userName : ""}など)によって、アプリケーションにログインしたユーザーの名前が表示される必要があります。ただし、Mozilla Firefoxでアプリケーションが実行されているときは、管理ユーザーの名前がIBM WebSphereアプリケーション・サーバーに表示されます。セッションIDが同一マシンのすべてのブラウザで共有されるためです。この動作は、Oracle WebLogic Serverで実行するときや、アプリケーションをMicrosoft Internet Explorerで実行するときには発生しません。

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

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

30.8.1 セキュアなアプリケーションを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内の既存のセキュリティ・オブジェクトを更新せずにアプリケーションを実行する場合には、このオプションを選択できます。

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

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

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

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

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

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

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

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

例30-17 アーカイブ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ファイルの移行設定は無視されます。既存のポリシーと資格証明を上書きできるため、これはセキュリティの脆弱性とみなされます。本番環境へのデプロイの詳細は、30.9項「セキュア・アプリケーションのデプロイの準備」を参照してください。

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

例30-18 アーカイブweblogic-application.xmlファイルのセキュリティ移行リスナー

<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と同等の暗黙のグループです。

例30-19 system-jazn-data.xmlファイル内のアプリケーション・ロール・フラグメント

<app-roles>
   <app-role>
      <name>fod-users</name>
      <guid>FFFF394F696E786F4134485764511002</guid>
      <display-name/>
      <description/>
      <class>oracle.security.jps.service.policystore.ApplicationRole</class>
      <members>
         <member>
            <name>fod-users</name>
            <class>weblogic.security.principal.WLSGroupImpl</class>
         </member>
      </members>
   </app-role>
</app-roles>

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

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

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

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

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

注意:

30.9.1項「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」で説明するように、アプリケーションをデプロイする前に、test-allロールのすべてのオカレンスをポリシー・ストアから削除する必要があります。こうすることで、未認可のユーザーがアプリケーションのWebページにアクセスすることを防ぎます。

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

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

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

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

図30-25 ADFセキュリティの暗黙的認証

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

バインド・タスクフローまたはWebページ(ADFバインディングを含む)がリクエストされると、ADFバインディング・サーブレット・フィルタがADF認証サーブレットにリクエストをリダイレクトし(図のステップ1)、ログインをトリガーした論理操作を格納します。
ADF認証サーブレットにはJava EEセキュリティ制約が設定されているため、Java EEコンテナによって構成済のログイン・メカニズムが起動されます(図のステップ2)。コンテナのログイン構成に基づいて、ユーザーは次のように認証を求められます。
1. フォームベース認証の場合は、適切なログイン・フォームが表示されます(図のステップ2a)。
2. ユーザーは、表示されるログイン・フォームに自分の資格証明を入力します(図のステップ2b)。
3. ユーザーは、コンテナのj_security_check()メソッドにフォームをポストします(図のステップ2c)。
4. Java EEコンテナは、構成済のプラガブル認証モジュールを使用してユーザーを認証します(図のステップ2d)。
認証が成功すると、コンテナは認証チャレンジを開始したサーブレット(この場合はADF認証サーブレット)にユーザーをリダイレクトします(図のステップ3)。
ADF認証サーブレットに戻ると、最初にリクエストされたリソースにリダイレクトされます(図のステップ4)。

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

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

図30-26 ADFセキュリティの明示的認証

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

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

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

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

図30-27は、認可プロセスを示しています。

図30-27 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のポリシー・ストアで定義されています。

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

統合WebLogic Serverを使用したJDeveloperでのテストの後は、アプリケーションをスタンドアロン・サーバーにデプロイすることができます。最初は、ターゲットのサーバーはステージング環境です。本番環境にデプロイする前に、このサーバーのアイデンティティ・ストアを使用して開発のテストを続行できます。つまり、通常は作成したテスト・ユーザーを統合WebLogic Serverで実行するために移行しません。セキュリティ・ポリシーとシステム資格証明を(cwallet.ssoファイルから)スタンドアロンOracle WebLogic Serverに移行するために実行するステップは、ターゲット・サーバーで構成されているモードと、デプロイにJDeveloperまたはJDeveloper外部ツールのどちらを使用するかによって異なります。

注意:

JDeveloperからデプロイメント環境へのデプロイの詳細は、第36章「Fusion Webアプリケーションのデプロイ」を参照してください。

ターゲット・サーバーが開発モードで構成されているときは、JDeveloperから直接デプロイできます。この場合、JDeveloperが、デプロイメント・プロセスの一環としてポリシー・ストア、システム資格証明およびアイデンティティ・ストア(ユーザーおよびグループ)の移行を自動的に処理します。アプリケーション・セキュリティ・デプロイメント・プロパティでは、デプロイメント・プロセスがドメインレベルのポリシー・ストアとシステム資格証明を上書きできるようにデフォルトで構成されています。さらに、アイデンティティ・ストア・デプロイメント・プロパティは、テスト・ユーザーを含むアイデンティティ・ストアを移行するようにデフォルトで構成されています。30.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、このデフォルトのデプロイメント動作を「アプリケーション・プロパティ」ダイアログで変更できます。

注意:

開発モードで実行するOracle WebLogic Serverへのシステム資格証明の移行が実行されるのは、ターゲット・サーバーが資格証明の上書きを許可するように構成されている場合だけです。システム資格証明の上書きをサポートするOracle WebLogic Serverの構成の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

ターゲット・サーバーが本番モードで構成されているとき、通常は、JDeveloper外部でOracle Enterprise Managerなどのツールを使用して移行タスクを処理します。JDeveloper外部のツールを使用してポリシー・ストアを本番環境のドメインレベルに移行する方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。本番モードで実行するOracle WebLogic Serverでは、どのような状況でもシステム資格証明の上書きはサポートされないことに注意してください。

ADFセキュリティの構成ウィザードで自動付与機能を有効にした場合は、アプリケーションをデプロイする前にtest-allアプリケーション・ロールを削除することをお薦めします。test-allロールによってすべてのADFリソースが公開されるため、このロールが存在していると、アプリケーションのリソースが保護されない状態になるリスクが高まります。したがって、アプリケーションレベルのポリシー・ストアを移行する前にこのロールを削除する必要があります。

さらに、アプリケーションのOracle WebLogic Serverへのデプロイを準備するとき、jazn-data.xmlファイルに作成したテスト・アイデンティティを削除することもお薦めします。こうしておくと、セキュリティ・ポリシーをテストするために作成したユーザーが、ドメインレベルのアイデンティティ・ストアに移行されません。

ベスト・プラクティス:

アプリケーションをスタンドアロン環境にデプロイする場合は、すでにOracle WebLogic Serverに対して構成しているローカル・アイデンティティ・ストアのユーザーおよびエンタープライズ・ロールを移行してはいけません。たとえば、ユーザーweblogicとエンタープライズ・ロールAdministratorsを含むアイデンティティ・ストアをデプロイする場合は、ターゲット・サーバーのデフォルト管理構成を上書きします。競合の可能性をすべて排除するには、30.9.2項「アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法」で説明するように、アイデンティティ・ストアの移行を無効にすることができます。

30.9.1 アプリケーション・ポリシー・ストアからtest-allロールを削除する方法

jazn-data.xmlファイルの概要エディタには、ADFセキュリティの組込みtest-allロールに対するview権限を持つすべてのリソースを表示する機能があります。概要エディタのこの機能を使用して、test-allロールの権限を削除し、アプリケーションで定義するロールの権限で置き換えることができます。

または、jazn-data.xmlファイルの概要エディタを使用してtest-allロールを削除できます。エディタのアプリケーション・ロール・ページでtest-allロールを選択して、「アプリケーション・ロールの削除」ボタンをクリックします。ただし、この方法でtest-allロールを削除しても、削除するロールのかわりの権限を作成する必要があります。概要エディタではこれらのタスク両方を一緒に行うことができるため、次の手順で使用方法を説明します。

test-allアプリケーション・ロールを削除し、カスタム・アプリケーション・ロールで置き換えるには:

「アプリケーション」メニューから「保護」→「リソース権限」を選択します。
jazn-data.xmlファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択し、「test-allのみが付与されたタスク・フローを示します」チェックボックスを選択して、この組込みロールに対する権限を含むタスク・フローのリストを表示します。

test-allロールに対する権限が存在しない場合、概要エディタの「リソース」リストには何も表示されません。test-allロールが定義されるのは、ADFセキュリティの構成ウィザードで有効にした場合のみです。有効になっている場合、test-allの権限を含むそれらのタスク・フローが図30-28のように表示されます。

図30-28 概要エディタでのtest-all権限付きタスク・フローの表示
「リソース」列でリストの最初のタスク・フローを選択します。
「付与先」列でtest-allを選択し、「権限受領者の削除」アイコンをクリックします。
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。その後、「アプリケーション・ロールの選択」ダイアログを使用して必要なロールを追加します。
これらのステップを繰り返し、残りのすべてのタスク・フローでtest-allロールを削除して、独自のアプリケーション・ロールで置き換えます。
概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択し、ステップを繰り返して、すべてのWebページとそのADFページ定義についてtest-allロールを削除します。
「test-allのみが付与されたタスク・フローを示します」/「test-allのみが付与されたWebページを示します」チェックボックスが選択された状態で、概要エディタにtest-all権限付きのリソースが表示されていないことを確認します。

30.9.2 アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法

デプロイ先のスタンドアロンOracle WebLogic Serverでは、構成済の独自のアイデンティティ・ストアが用意されます。JDeveloperで作成したテスト・ユーザーとエンタープライズ・ロール・グループをドメイン・レベルに移行しないようにするには、jazn-data.xmlファイルからテスト・ユーザー・レルムを削除する必要があります。

または、JDeveloperからデプロイする場合は、ユーザーとグループの移行を無効にすることができます。これには、30.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」オプションを選択解除します。

アイデンティティ・ストアからテスト・ユーザーとエンタープライズ・ロール・グループを削除するには:

「アプリケーション」メニューから「保護」→「ユーザー」を選択します。
jazn-data.xmlファイルのエディタ・ウィンドウで「ソース」タブをクリックします。
jazn-data.xmlファイルのソースで<jazn-realm>要素の左側の「-」アイコンをクリックすると、図30-29のように要素全体が折りたたまれます。

図30-29 XMLエディタでの<jazn-realm>要素の選択
この要素が選択された状態で[Delete]を押し、ファイルを保存します。

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

アプリケーション・ポリシー・ストアに対する認可チェックを一時的に実行せずにアプリケーションを実行する必要がある場合、JDeveloperではADFセキュリティを無効にできます。こうすると、既存のセキュリティ・ポリシーで提供される保護なしで、アプリケーションを実行し、すべてのリソースにアクセスできます。

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

アプリケーションのレベルでADFセキュリティを無効にするには、ウィザードを実行して次のオプションの1つを選択します。

「ADF認証」を選択すると、ADF認可が無効になりますが、ADF認証サーブレットは有効なままです。たとえば、一時的に無効化されたセキュリティ・ポリシーに対して認可チェックを施行してアプリケーションをJDeveloperで実行する必要があるとします。このオプションでは、Java EEアプリケーション・ルート「/」を、ユーザー認証をトリガーするallPagesJava EEセキュリティ制約にマップすることで、ユーザーがアプリケーションのページに最初にアクセスしたときにログインを要求します。認可チェックが施行されないため、ADFリソースはセキュリティ対応になりません。したがって、一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。
「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効になり、ADFリソースの認可チェックも無効になります。この場合、ユーザー認証とADFリソースのセキュリティがない状態でアプリケーションを実行できます。

どちらのオプションもADFセキュリティを再有効化する目的でいつでも選択できます。このウィザードでは特に、アプリケーション開発者がADFリソースに対して定義したセキュリティ・ポリシーを含む、アプリケーションのポリシー・ストアは変更されません。このため、いつでもウィザードに戻り、「ADF認証および認可」オプションを選択し、アプリケーションの既存のポリシー・ストアやアイデンティティ・ストアに対してADFセキュリティを再有効化できます。

Oracle ADF認可チェックを無効にするには:

「アプリケーション」メニューから「保護」→「ADFセキュリティの構成」を選択します。
ADFセキュリティ・ページで「ADF認証」オプションまたは「ADFセキュリティ構成の無効化」オプションを選択します。「次へ」をクリックします。

これらのオプションのいずれかを設定してウィザードを実行すると、ユーザー・インタフェース・プロジェクトのADFリソースはセキュリティ対応でなくなります。
「終了」をクリックします。

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

「ADFセキュリティ構成の削除」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、web.xmlファイルとadf-config.xmlファイルからADF固有のメタデータ(表30-2)が削除されます。

同様に、「ADF認証」オプションを選択してウィザードを実行し、認可チェックのみを無効にすると、次の更新が実行されます。

web.xmlファイルでADF固有のメタデータは変更されず、allPagesセキュリティ制約が追加されます。

allPagesセキュリティ制約が存在する場合、ユーザーはアプリケーションに最初にアクセスしたときに認証を行うことになります。
例30-20に示すようにadf-config.xmlファイルの<JaasSecurityContext>要素のauthorizationEnforceパラメータがfalseに設定されます。

例30-20 adf-config.xmlファイルでのAuthorizationEnforceフラグの無効化

<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ファイルを表示する場合、ウィザードによって適用されたファイル内の変更を確認するにはワークスペースを保存する必要があります。

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

ADFセキュリティの有効化プロセスを完了した後、ユーザー・インタフェースにおいてADFセキュリティと連動するようにアプリケーションをカスタマイズすることができます。たとえば、式言語(EL)を使用し、一連のUIコンポーネントのためだけに定義したカスタム権限の評価に基づいて、UIコンポーネントをWebページにレンダリングできます。さらに、マネージドBean内にメソッドを定義して、アプリケーションの情報(ユーザー名やロール・メンバーシップなど)を公開できます。

30.11.1 ADFセキュリティでの式言語(EL)の使用

式言語(EL)を使用するとUIのポリシーを直接評価できますが、Javaを使用するとマネージドBean内でポリシーを評価できます。ADFセキュリティでは、セキュリティ・コンテキストでADFリソースにアクセスするように、EL式で使用できる便利なメソッドがいくつか実装されています。たとえば、EL式の便利なメソッドを使用して、ユーザーが特定のタスク・フローにアクセスできるかどうかを判定することができます。優れたセキュリティは、ユーザーがアクセス権を持たないリソースや機能をアプリケーションが非表示にすることを求めます。この理由から、ユーザーが特定のタスク・フローへのアクセスを許可されない場合、そのユーザーの権限を評価して、そのタスク・フローを開始するナビゲーション・コンポーネントをレンダリングするかどうかを判別します。

注意:

ポリシーを評価できるのは、現在のリクエストのみです。この理由から、リクエスト・スコープ外でポリシーを評価すると、予期しない結果が発生することがあるため、ポリシー評価がどこで行われるかを理解することが重要です。

30.11.1.1 ELを使用したポリシーの評価方法

UI要素内でELを使用するとプロパティを動的に定義できるようになり、実行時にUIコンポーネントを変更できます。リソースを保護する場合、該当するUIプロパティはRenderedプロパティです。これを使用して、ユーザーの権限に基づいてコンポーネントの表示と非表示を切り替えることができます。デフォルトでは、Renderedプロパティはtrueに設定されています。権限に応じてこの値を動的に変更することで、UIコンポーネントの表示と非表示を設定できます。たとえば、ユーザーが適切な権限を持っている場合は、Renderedプロパティをtrueに設定して、UIコンポーネントを表示する必要があります。権限を持たない場合は、プロパティをfalseに設定して、UIコンポーネントを非表示にする必要があります。

ELを使用してポリシーを評価するには、securityContext ELネームスペースでADFセキュリティのメソッドを使用する必要があります。これらのメソッドを使用して、特定のユーザーまたはADFリソースに関してADFセキュリティ・コンテキストの情報にアクセスできます。

表30-9に、ユーザーが関連する権限を持つかどうかを判別するために必要なEL式を示します。ユーザーが適切な権限を持っている場合、EL式はtrueに評価されます。そうでない場合はfalseを返します。

表30-9 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`を戻します。

#{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を戻します。

注意:

ページ権限の場合、マネージドBean内部の遅延バインディングELを使用することにより、ページ定義の値を動的に指定できます。30.3.7項「valid-usersロールについて」を参照してください。

表30-10には、ADFセキュリティ・コンテキストから、ADFリソースに関連しない一般的な情報を取得するためのEL式を示します。たとえば、ユーザーの名前をユーザー・インタフェースに表示する場合は、現在のユーザー名にアクセスできます。また、現在のユーザーが特定のロールのメンバーかどうか、特定の権限を付与されているかどうかもチェックできます。アプリケーションはこの結果を使用してメニューの非表示と表示を動的に切り替えることができます。

表30-10 ADFセキュリティ・コンテキストでのユーザー情報を判定するEL式

式	式のアクション
#{securityContext.userName}	認証されたユーザーのユーザー名を戻します。
#{data.adfContext.tenantName}	認証されたユーザーのテナント名を戻します。テナント名はユーザーが自ら認識している別名で、ログインに使用できます。
#{data.adfContext.tenantId}	認証されたユーザーのテナントIDを戻します。
#{securityContext.authenticated}	ユーザーがログインしている場合は`true`を戻します。ユーザーがログインしていない場合は`false`を戻します。これが役立つのは、ログイン/ログアウトの動的リンクのレンダリング、またはユーザーが認証されたときの「ようこそ、username」メッセージのレンダリングです。この式を使用する例は、30.7.4.2項「ログイン・リンクおよびログアウト・リンクの追加」を参照してください。
#{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`を戻します。表30-9に示された便利なメソッド`taskflowViewable`および`regionViewable`にも同じ機能があります。
#{securityContext.userGrantedResource['resource']}	`resource`は、`resourceName=<name>;resourceType=<type>;action=<action>`のようなセミコロンで連結した要素を含む文字列です。ユーザーがアクセス権を持つ場合は`true`を戻します。ユーザーが十分なアクセス権を持たない場合は`false`を戻します。この式を使用すると、タスク・フローに含まれないリソース(ADF Facesパネルなど)の`rendered`プロパティの権限をテストできます。この方法は、アプリケーションにパッケージ化する必要があるカスタム権限クラスを作成するかわりに使用できます。たとえば、そのリソースに付与されている権限に基づいて、ページでのパネルの表示と非表示を切り替える場合、式は次のようになります。 #{securityContext.userGrantedResource ['resourceName=myPanel1; resourceType=myLayoutPanel; action=myAction']} ポリシー・ストアでは、リソースに対する権限の`<permission>`定義は次のようになります。 <permission> <class>oracle.security.jps. ResourcePermission</class> <name>resourceType=myLayoutPanel, resourceName=myPanel1</name> <actions>myAction</actions> </permission>

ナビゲーション・コンポーネントのレンダリングを、ターゲット・タスク・フローまたはページ定義に対してユーザーに付与された権限に関連付けるには:

アプリケーション・ナビゲータで、ページをダブルクリックします。
セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
プロパティ・インスペクタで、図30-30に示すように、Renderedプロパティの右側に表示されているドロップダウン・メニューから「式ビルダー」を選択します。

図30-30 データへのRenderedプロパティのバインディング
「式ビルダー」で「ADFバインディング」のsecurityContextノードを開いて適切なEL値を選択します。次に、「式」フィールドに、アクセスしようとしているADFリソースの修飾名を入力します。

たとえば、図30-31に示すようにアプリケーションで表示するタスク・フローへのアクセスを制限するには、次のような式を作成します。
```
#{securityContext.taskflowViewable
     ['/WEB-INF/audit-expense-report.xml#audit-expense-report']}
```
この例では、式によって、ターゲット・タスク・フローaudit-expense-reportを表示するためのユーザーのアクセス権が判別されます。ユーザーにアクセス権がある場合、式はtrueに評価され、renderedプロパティが値trueを受け取ります。

図30-31 「式ビルダー」ダイアログでのELの定義
「OK」をクリックします。

アプリケーションを実行すると、ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。

30.11.1.2 「式ビルダー」ダイアログの使用時の処理

「式ビルダー」を使用して「プロパティ・インスペクタ」のRenderedプロパティの式を定義すると、開いている.jspxファイルのコンポーネント定義がJDeveloperによって更新されます。例30-21に示すように、コンポーネントのrenderedプロパティに、trueまたはfalseに評価される式が追加されます。この例ではコンポーネントはナビゲーション・リンクであり、リンク・テキストCheckoutは別の式で定義されます。このナビゲーション・リンクを含むページによってこのコンポーネントがレンダリングされるのは、チェックアウト・タスク・フローにアクセスするための十分なアクセス権がユーザーにある場合のみです。

例30-21 .jspxファイルのソースでのEL式

<af:commandNavigationItem
   text="#{res['global.nav.checkout']}"
   action="globalCheckout"
   id="cni3"
   rendered="#{securityContext.taskflowViewable
                       ['/WEB-INF/checkout-task-flow.xml#checkout-task-flow']}"
/>

30.11.1.3 ELの遅延評価について

セキュリティ権限を評価できるスコープは、リクエストに設定されています。リクエストよりも上位レベルまでスコープ設定されたマネージドBean (マネージドBeanが基礎となっているグローバル・メニューなど)からターゲット・ページにアクセスするための権限を評価する場合は、遅延EL評価(遅延バインディング)を実装する必要があります。Beanの管理プロパティとしてターゲット・ページを渡すことで、マネージドBeanが必要なバインディング情報を取得できるようになった後でEL式が評価されるようになります。ELは、ページが実行されるとすぐに評価されるため、マネージドBeanを基礎としたUIコンポーネントのプロパティ内に直接EL式を配置すると、有効範囲外エラーが発生します。

例30-22に、ユーザーが特定のターゲット・ページを表示できるかどうかに基づいてtrueまたはfalseを返すマネージドBeanのプロパティ(authorized)を示します。この場合、_targetPageDef変数は、ターゲット・ページの名前が含まれる管理プロパティです。UI内で、EL式はauthorizedプロパティを参照します。

例30-22 マネージドBean内の遅延EL評価

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;
     }
}

30.11.2 カスタムJAAS権限とELを使用したポリシーの評価方法

ADFセキュリティELネームスペースのuserGrantedPermission (表30-9)を使用して、ページにUI要素をレンダリングするかどうかを判別できます。作成する式で、認証されたユーザーのカスタム権限を評価できます。カスタム権限は、「JAAS権限の作成」ダイアログを使用して作成するJAAS権限クラスです。このダイアログで作成できるクラスは、oracle.adf.share.security.authorization.ADFPermissionクラスを拡張して、権限がADFセキュリティによって使用できるようにします。

Fusion Webアプリケーションのカスタム権限により、セキュリティ・ポリシーを定義する際の柔軟性が向上します。たとえば、カスタム権限には、保護対象のUI要素に対応する名前を付けることができます。いったん権限を作成したら、jazn-data.xmlファイルの概要エディタを使用し、jazn-data.xmlポリシー・ストアによって定義されたアプリケーション・ロールに権限を付与することでADFリソースのセキュリティ・ポリシーを作成します。

ベスト・プラクティス:

カスタムADF権限クラスを使用すると、ADFセキュリティを拡張して、権限で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。Webページへのアクセスを管理するためにカスタム権限を作成する必要がないことに注意してください。このレベルのアクセスは、jazn-data.xmlファイルの概要エディタで操作できる、ADFセキュリティのデフォルトのview権限によって実現されます。

カスタムJAAS権限クラスを作成するには:

アプリケーション・ナビゲータで、カスタムJAAS権限クラスを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で「すべてのアイテム」と「JAAS権限」を順に選択し、「OK」をクリックします。
「JAAS権限の作成」ダイアログで、権限の名前と完全修飾パッケージ名を入力します。

権限名としては一般的な名前を選択できます。
「アクション」リストに、アクション権限のための名前を入力します。

アクション名は、権限の目的を特定できるように具体的な名前を付けることができます。同一コンポーネントに様々な目的で権限を適用する場合は、リストに複数のアクションを追加できます。たとえば、マネージャと従業員の両方がページ・メニューを見られるように許可しますが、マネージャは特定のメニュー項目の選択も行えるようにします。
「ターゲット」リストでは「属性」の選択をそのままにしておきます。

カスタムJAAS権限のアクションを使用してポリシー・ストアにポリシーを作成してから、実際のターゲット名を指定します。

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

JDeveloperによって、指定したパッケージにクラスが追加されます。たとえば、Fusion Order Demoアプリケーションのoracle.fodemo.storefront.store.viewパッケージでは、次のようなカスタム権限クラスAccountPermission.javaが定義されます。

package oracle.fodemo.storefront.store.view;

import oracle.adf.share.security.authorization.ADFPermission;
import oracle.adf.share.security.authorization.PermissionActionDescriptor;
import oracle.adf.share.security.authorization.PermissionTargetDescriptor;

public class AccountPermission extends ADFPermission {
  private static final PermissionActionDescriptor[] actions =
   {new PermissionActionDescriptor("view", "view")};
  private static final PermissionTargetDescriptor[] targets =
   {new PermissionTargetDescriptor("attributeValue", "Attribute")};

  public AccountPermission(String name, String actions) {
    super(name, actions);
  }

  public static PermissionActionDescriptor[] getPermissionActionDescriptors() {
    return actions;
  }

  public static PermissionTargetDescriptor[] getPermissionTargetDescriptors() {
    return targets;
  }
}

カスタム権限を使用してADFセキュリティ・ポリシーを作成するには:

メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
jazn-data.xmlファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストからカスタム・リソースを選択します。

概要エディタにすべてのカスタム・リソースが表示されます。最初はカスタム・リソースに関連付けられているリソース・タイプはありませんが、図30-32のようにエディタによってハイライト表示されます。

図30-32 概要エディタでのカスタム・リソースの表示
「リソース・タイプ」フィールドの横の「新規リソース・タイプ」アイコンをクリックします。
「リソース・タイプの作成」ダイアログで名前とアクションを入力し、「OK」をクリックします。
概要エディタのリソース権限ページにおいて、「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、アプリケーション・ロールを選択して「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列で必要なアクションを選択します。

図30-33のように概要エディタにカスタム権限が表示されます。

図30-33 概要エディタでのカスタム権限の作成

UIコンポーネントのレンダリングとユーザーに付与されるカスタム権限を関連付けるには:

アプリケーション・ナビゲータで、ページをダブルクリックします。
セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
「プロパティ・インスペクタ」で、Renderedプロパティの右側に表示されているドロップダウン・メニューから「式ビルダー」を選択します。
「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedPermission値を選択します。次に、「式」フィールドに権限を定義する連結文字列を入力します。

権限文字列は、permissionClass=qualifiedClassName;target=artifactName;action=actionNameのようにセミコロンで連結した文字列として入力します。たとえば、テキスト・フィールドによってページに表示される口座番号を保護するには、次のような式を入力します。このとき、userGrantedPermissionの権限はカスタムJAAS権限と同じ名前です。
```
#{securityContext.userGrantedPermission
       ['permissionClass=oracle.fodemo.storefront.store.view.AccountPermission;
         target=AccountPermission;action=view']}
```
この例では、アプリケーション・ポリシー・ストアに追加したAccountPermissionという名前のカスタムJAAS権限定義に基づいて式が権限を評価します。

図30-34に示すように、Fusion Order Demoアプリケーションでは、ページmyOrders.jpxが、af:outputText#ot18テキスト・フィールドのValueプロパティに対してuserGrantedPermission式を定義します。この場合、式がユーザーに権限があるかどうかをテストして、口座番号(bindings.AccountNumber.inputValue)を表示します。または、権限がない場合は口座番号のかわりにXXXXXXXXXXXXを表示します。この式はテキスト・フィールドのRenderedプロパティに対して定義されているのではないため、ページには常にこのフィールドが表示されます。
```
#{securityContext.userGrantedPermission
       ['permissionClass=oracle.fodemo.storefront.store.view.AccountPermission;
         target=AccountPermission;action=view']
     ? bindings.AccountNumber.inputValue : 'XXXXXXXXXXXX'}
```
図30-34 「式ビルダー」ダイアログでのELの定義
「OK」をクリックします。

30.11.3 ADFセキュリティ・コンテキストからの情報の取得

Fusion Webアプリケーション内にセキュリティを実装することは、定義上、ADFセキュリティ・フレームワークのセキュリティ・インフラストラクチャを実装することです。このため、フレームワークのセキュリティ・コンテキストを使用して、アプリケーションのポリシーやセキュリティ全体を定義するときに必要となる情報にアクセスできます。

30.11.3.1 セキュリティが有効かどうかの判定方法

ADFセキュリティの施行は、アプリケーションと無関係にコンテナ・レベルでオン/オフを切り替えることができるため、認可チェックを行う前に、ADFセキュリティが有効化されているかどうかを判断する必要があります。このためには、例30-23に示すように、ADFセキュリティ・コンテキストのisAuthorizationEnabled()メソッドをコールします。

例30-23 ADFセキュリティ・コンテキストのisAuthorizationEnabled()メソッドの使用

if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()){
  //Authorization checks are performed here.
}

30.11.3.2 ユーザーが認証済かどうかの判定方法

Fusion Webアプリケーション内のユーザー・プリンシパルがnullになることはない(つまり、認証されていないユーザーの場合はanonymousで、認証されたユーザーの場合は実際のユーザー名になる)ため、ユーザー・プリンシパルがnullかどうかを確認するだけで、そのユーザーがログオンしているかどうかを判断することはできません。このため、anonymousユーザー・プリンシパルがユーザーが認証されていないことを表すことを考慮に入れるメソッドを使用する必要があります。このためには、例30-24に示すように、ADFセキュリティ・コンテキストのisAuthenticated()メソッドをコールします。

例30-24 ADFセキュリティ・コンテキストのisAuthenticated()メソッドの使用

// ============ User's Authenticated Status =============
private boolean _authenticated;
public boolean isAuthenticated() {
_authenticated = ADFContext.getCurrent().getSecurityContext().isAuthenticated();
    return _authenticated;
}

30.11.3.3 現在のユーザー名、テナント名またはテナントIDを判別する方法

Fusion Webアプリケーションでは、セキュアでありながらすべてのユーザーに使用可能なパブリック・ページの概念をサポートしています。さらに、Webページ上のコンポーネント(ポートレットなど)では、現在のユーザー・アイデンティティの情報を必要とします。このため、Fusion Webアプリケーションのユーザー名は決してnullになることはありません。認証されていないユーザーがページにアクセスすると、ユーザー名anonymousがページ・コンポーネントに渡されます。Fusion Webアプリケーションがユーザーのテナント名を登録しているときは、テナント名も取得できます。テナント名はユーザーが自ら認識している別名で、ログインに使用できます。

現在のユーザー名を判別するには、例30-25に示すように、ADFセキュリティ・コンテキストのgetUserName()メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymousを返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。

例30-25 ADFセキュリティ・コンテキストのgetUserName()メソッドの使用

// ============ Current User's Name/PrincipalName =============
public String getCurrentUser() {
   _currentUser = ADFContext.getCurrent().getSecurityContext().getUserName();
   return _currentUser;
}

Facesベースのアプリケーションでユーザー名を判別するための従来のメソッド(FacesContext.getCurrentInstance().getExternalContext().getRemoteUser())では、認証されていないユーザーに対してnullが戻されるため、そのメソッドを使用する場合は、パブリック・ユーザーのケースを処理する追加のロジックを使用する必要があります。

現在のユーザーのテナント名を判別するには、例30-26に示すように、ADFセキュリティ・コンテキストのgetTenantName()メソッドを評価します。

例30-26 ADFセキュリティ・コンテキストのgetTenantName()メソッドの使用

// ============ Current User's Tenant Name =============
public String getTenantName() {
  _tenantName = ADFContext.getCurrent().getTenantName();
  return _tenantName;
}

現在のユーザーのテナントIDを判別するには、例30-27に示すように、ADFセキュリティ・コンテキストのgetTenantId()メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymousを返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。

例30-27 ADFセキュリティ・コンテキストのgetTenantId()メソッドの使用

// ============ Current User's Tenant ID =============
public String getTenantId() {
    _tenantId = ADFContext.getCurrent().getTenantId();
    return _tenantId;
}

30.11.3.4 Java EEセキュリティ・ロールのメンバーシップの判別方法

Fusion WebアプリケーションはJavaServer Facesベースのアプリケーションなので、例30-28に示すように、Faces外部コンテキストのisUserInRole(roleName)メソッドを使用すると、ユーザーに特定のロールが割り当てられているかどうかを判別できます。ADFセキュリティはJAASポリシーに基づくため、ロール・メンバーシップに基づくADFセキュリティ対応リソースに関連付けられたページを保護するためにJava EEセキュリティ・ロールを使用する必要はありません。ただし、ADFセキュリティ対応リソースに関連付けられていないページについては、メソッドを使用してロールをチェックできます。

この例では、便利なメソッド(checkIsUserInRole)が定義されています。マネージドBean内でこのメソッドを使用すると、名前付きロールのメンバーシップを属性として公開し、その後EL内で使用できます。

例30-28 FacesコンテキストのUserInRole(roleName)メソッドの使用

public boolean checkIsUserInRole(String roleName){
        return 
(FacesContext.getCurrentInstance().getExternalContext().isUserInRole(roleName));
}

public boolean isCustomer() {
        return (checkIsUserInRole("fod-users"));
}

30.11.3.5 Javaを使用して権限を判別する方法

Java内からセキュリティ・ポリシーを評価するには、ADFセキュリティ・コンテキストのhasPermissionメソッドを使用できます。このメソッドは、(リソースとアクションの組合せにより定義された)権限オブジェクトを取り、ユーザーに対応する権限があればtrueを返します。

例30-29では、ページ名と必要なアクションを渡し、ユーザーの権限に基づいてtrueまたはfalseを返すことのできる、便利な関数が定義されています。この便利な関数がページ権限を確認するため、RegionPermissionクラスを使用して、hasPermissionメソッドに渡される権限オブジェクトを定義しています。

例30-29 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ナビゲーション・アクションの結果を動的に変更できます。例30-30では、1つのコマンド・ボタンがユーザーの権限に応じて異なるターゲット・ページを指していることがわかります。コマンド・ボタンのバッキングBeanは、最も高いレベルで保護されているページ(管理者ページ)から最も低いレベルで保護されているページ(パブリックのようこそページ)までview権限を確認することにより、適切なアクションを適用して、ユーザーに対して権限レベルに応じたページを表示します。適切なアクションを戻すバッキングBeanは、例30-29に定義されている便利なメソッドを使用しています。

例30-30 認可チェックに基づくページ・ナビゲーション結果の変更

//CommandButton Definition
<af:commandButton 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);
    }

30.11.4 ADFセキュリティの操作のベスト・プラクティス

次に示すベスト・プラクティスは、ADFセキュリティ・フレームワークによるセキュリティ施行のための規則をまとめたものです。これらのベスト・プラクティスを理解することで、アプリケーションを保護して、意図したWebページにユーザーのアクセスを許可することができます。

アプリケーションを構築するときは最初からADFセキュリティを有効にしてください。

セキュリティを有効化すると、アプリケーションが実質的にロックダウンされます。また、作成する固有のADFセキュリティ対応リソースに対して明示的な権限付与を行う必要が生じます。アプリケーションを構築する際に、これらのリソースについて認識して、権限付与を行うことにより、反復しながらセキュリティをテストできます。こうして、必要な結果を実現するようにアプリケーションを構成できます。

バインド・タスク・フローの権限を定義してください。

バインド・タスク・フローを実行するプロセスでユーザーがアクセスするページは、ページごとの個別の権限チェックは行われず、タスク・フローの権限において実行されます。つまり、タスク・フローに追加するページには、ページ定義レベルでの独自のセキュリティは定義されていません。ユーザーがフローをリクエストする場合、アクセス・レベルに応じて、タスク・フローのすべてのページの表示を許可されるか、まったく許可されないかのどちらかになります。

バインド・タスク・フローの個々のページには権限を定義しないでください。

タスク・フローはユーザーによるページへの直接アクセスを妨げないことを理解することが重要です。公開されているディレクトリにあるすべてのWebページは、URLを使用してブラウザからアクセスできます。バインド・タスク・フローによって参照されるページに直接アクセスできないようにするため、関連するページ定義ファイルについて存在するすべての権限を削除します。バインド・タスク・フローのコンテキスト内でページに追加のセキュリティが必要な場合は、それらのページをサブタスク・フローに含めて、このネストされたタスク・フローに対する権限の定義を追加します。

エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすため、タスク・フローを使用してください。

タスク・フローを使用すると、エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすことができます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つの無制限タスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローのURL起動プロパティをurl-invoke-disallowedに設定することで、アプリケーションのアクセス・ポイントは1つのみ(無制限タスク・フローのページ)となります。URL起動プロパティの詳細は、15.6.4項「URLを使用したバインド・タスク・フローのコール方法」を参照してください。

バインド・タスク・フロー外部の個々のページには権限を定義してください。

ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、または無制限タスク・フロー内でアクセスされる場合のみです。ページ定義ファイルとそれがセキュリティ保護するWebページの間には1対1の関係があります。

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つの方法があります。

localhost:7101/myapp/faces/AllDepartments
localhost:7101/myapp/faces/AllDepartments.jspx

違いは、1のコールがADFコントローラ・タスク・フローのコンテキストにあることです。つまり、ページのナビゲーションが作動し、ページで参照されるすべてのマネージドBeanが適切にインスタンス化されます。2のコールでもページが表示されますが、完全に作動しないことがあります。これはセキュリティの侵害とみなされる可能性があるためです。

JSPXファイルへの直接アクセスを防ぐには、JSPXファイルを/public_html/WEB-INFディレクトリに移動して、直接ファイル・アクセスを行えないようにします。ドキュメントにアクセスするには、ユーザーはビュー・アクティビティ名をコールする必要があります。

この方法では、ADFセキュリティで保護されていないドキュメントは保護できないことに注意してください。物理ファイルそのものへのアクセスのみがロックダウンされます。

したがって、次のセキュリティ・ガイドラインが引続き適用されます。

adfc-config.xmlファイルに定義されたビュー・アクティビティに関連付けられたすべてのJSPXドキュメントに、ADFセキュリティ権限を適用します。
ユーザー・インタフェース・プロジェクトのすべてのJSPXドキュメントを/public_html/WEB-INFディレクトリに移動して、ファイルへの直接アクセスを防ぎます。
adfc-config.xmlのページを最小限に制限し、他のすべてのページをバインド・タスク・フローに含めます。
バインド・タスク・フローに直接URLアクセスでアクセスできないようにします(新しいタスク・フローのデフォルト構成設定)。
バインド・タスク・フローにADFセキュリティ権限を適用します。