Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.1.2) E48099-02 |
|
前 |
次 |
この章では、Fusion WebアプリケーションでADFセキュリティを有効化して、Oracle ADFリソースのリソース権限を定義し、それらのリソースに関連するWebページをユーザーが表示できるかどうかを制限する方法を説明します。
この章には次の項が含まれます:
ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。ADFセキュリティはOracle Platform Security Services (OPSS)アーキテクチャの上に構築されます。このアーキテクチャはそれ自体がOracle WebLogic Serverと密接に統合されています。それ以外にも、ユーザー・ログインおよびリソースの保護を処理できるセキュリティ対応モデルはありますが、ADFバインド・タスク・フロー、ADFバインディングを使用するトップレベルのWebページ(バインド・タスク・フローに含まれないページ)、および最も低いレベルの粒度でADFエンティティ・オブジェクトとその属性によって定義されたデータ列に対して宣言型で許可ベースの保護を実現するのに、ADFセキュリティは非常に適しています。このドキュメントでは、ADFセキュリティ・フレームワークが保護するこれらの個々のリソースを、ADFセキュリティ対応リソースと呼びます。
41.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権限クラスで定義される操作)が識別されます。たとえば、ADFタスク・フローのSummitサンプル・アプリケーションでは、customer-task-flow
のタスク・フローにより含まれるWebページを保護し、ログイン済ユーザー(認証済ユーザー)にのみアクセス権を付与します。実行時、ADFセキュリティ・フレームワークではタスク・フローのセキュリティ・ポリシーに対して認可チェックを実行して、ユーザーに表示操作を完了する権限があるかどうかを識別します。この場合、ユーザーがチェックアウト・プロセスを完了しようとする場合は、セキュリティ・ポリシーでは表示の権限をユーザーに付与する必要があります。
ユーザーとADFリソースに対してセキュリティ・ポリシーを定義するタスクを簡略化するために、ADFセキュリティではADFバインド・タスク・フローとそこに含まれるWebページに対して1つのセキュリティ・ポリシーを定義できる包含階層を定義します。つまり、バインド・タスク・フロー・レベルでセキュリティ・ポリシーを定義すると、フローのエントリ・ポイントが保護されます。次に、そのフロー内のすべてのページが、定義されたポリシーによって保護されます。また、個々のユーザーにアクセス権を付与するかわりに、ユーザーをアプリケーション・ロールにグループ化し、そのロールにview権限を付与します。
特に、Fusion Webアプリケーションで次のADFセキュリティ対応リソースのためのセキュリティ・ポリシーを定義して、ユーザーがWebページにアクセスできるようにします。
ADFバインド・タスク・フローはタスク・フローのエントリ・ポイントを保護します。エントリ・ポイントが、そのフローに含まれるページへのユーザーのアクセスを制御します。
たとえば、新規顧客に登録プロセスを説明する一連のWebページがあるとすると、バインド・タスク・フローによって、そのプロセスのページ・ナビゲーションが制御されます。バインド・タスク・フローの詳細は、20.1.2項「バインド・タスク・フローについて」を参照してください。
バインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、認可チェックは行われません。バインドなしタスク・フローの構成ページを保護する必要がある場合は、ページに関連するページ定義ファイルの権限を定義します。
Webページに関連するADFページ定義ファイル
たとえば、ページに売上数上位の製品の要約が表示されることがありますが、これには、そのページに関連付けられたADFページ定義ファイルのADFバインディングによって調整されたデータが使用されます。ページ定義とADFバインディングの詳細は、17.7項「ページ定義ファイルでの作業」を参照してください。
ADFエンティティ・オブジェクトとエンティティ・オブジェクトの属性(データ行を参照し、ユーザー・インタフェースに表示するコレクションの定義に使用されます)
たとえば、WebページにADF Facesの表コンポーネントが表示されることがあります。これには、ADFバインディングがエンティティ・オブジェクトの属性にデータ・ソースとしてマップする列が表示されます。エンティティ・オブジェクトの場合、ADFセキュリティを有効化してもエンティティ・オブジェクト行は自動的に保護されません。エンティティ・オブジェクトまたはその属性を明示的に保護するセキュリティ・ポリシーを定義しないかぎり、ユーザーが引続きデータにアクセスできます。エンティティ・オブジェクトの詳細は、4.1項「エンティティ・オブジェクトについて」を参照してください。
JDeveloperツールではセキュリティの反復開発がサポートされるため、ADFリソースに作成するセキュリティ・ポリシーの作成、テストおよび編集が容易になります。JDeveloperでのテスト・ユーザーの作成に進み、統合WebLogic Serverでアプリケーションを実行して、保護されたリソースにエンド・ユーザーがどのようにアクセスするかをシミュレートできます。この章では、ユーザー・アイデンティティとログイン資格証明のリポジトリ(アイデンティティ・ストアと呼ばれる)を構成する方法を説明します。
注意: この章で説明するアイデンティティ・ストアはすべて、統合WebLogic Serverでの実行を目的として作成するテスト・ユーザー・アイデンティティに関係しています。41.9項「セキュア・アプリケーションのデプロイの準備」で説明するように、Oracle WebLogic Serverにデプロイするとき、通常はこのようなユーザーをステージング環境に移行することはありません。 |
ADFセキュリティを有効化したが、テスト・ユーザーにアクセス権を付与するセキュリティ・ポリシーをまだ定義していないという状況を避けるため、ADFセキュリティの構成ウィザードでは、一時的なview権限を既存のすべてのADFリソースに付与できます(view権限が各ADFリソースのセキュリティ・ポリシーに追加されます)。ウィザードのこのオプションでは、自動付与を行わずに、各リソースの作成時にADFリソースのセキュリティ・ポリシーを定義する選択肢と、view権限を自動付与してから、セキュリティ・ポリシーを定義してその権限を1つずつ置き換える選択肢があります。セキュリティの反復開発の選択肢については、41.2項「ADFセキュリティ・プロセスの概要」で説明します。
ヒント: ADFセキュリティを有効化し、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義する前に、ADF認可チェックの規則を理解する必要があります。この規則を理解すると、計画しているセキュリティの実装に役立ちます。これらの規則の詳細は、41.1.2項「ADFセキュリティのユースケースと例」を参照してください。 |
Fusion Webアプリケーション・リソースを保護するADFセキュリティ・モデルは、Java EEセキュリティ・モデルで使用されているセキュリティ制約のURLマッピングに基づくものではありません。実際の処理でも、セキュリティ制約はJavaServer Faces (JSF) Webアプリケーションの保護には適していません。ページ・ナビゲーションが特定のページURLでサポートされないためです。たとえば、ユーザーがタスク・フローの次のページにナビゲートしても、そのフロー内ではURLは変化しません。新しいページが表示されるときに、URLベースのセキュリティ制約をトリガーする手段がありません。
かわりに、ADFセキュリティはJava Authentication and Authorization Service (JAAS)セキュリティ・モデルを実装しています。JAASは既存のJavaセキュリティ・モデル上に構築され、すべてのJAAS実装(JAASサービスのOracle Platform Security Services (OPSS)実装も含む)と統合されるため、JAASモデルはポリシー・ベースです。URLセキュリティ制約を利用するアプリケーションがセキュリティ非対応となるのは、セキュリティを管理するためにJava EEコンテナに依存するためです。これに対して、Fusion Webアプリケーションは、ユーザー定義ポリシーに基づいてリソースへのアクセスを認可するために、ADFセキュリティ・フレームワークへの明示的なコールを必要とします。つまり、ADFセキュリティを有効化して、ADFリソースのアクセス・ポリシーを定義したときに、アプリケーションがセキュリティ対応になります。
ADFセキュリティによりJAAS認可モデルの実装が簡略化されます。この実装では、ADFリソースに対するセキュリティ・ポリシーを宣言して公開し、それらのリソースに対する認可チェックを実行時に行うことで、セキュリティ対応アプリケーションの作成に必要な作業を最小限に抑えます。
JDeveloperのポリシー・ストアはファイルベースで、ADFリソースのセキュリティ・ポリシーを定義する権限と呼ばれるエントリのリストを含みます。権限エントリには、保護対象のリソースに操作(たとえば、ADFバインド・タスク・フローに関連付けられたWebページへのアクセス)を実行するためにユーザーに付与されるすべての権限が含まれます。権限はポリシー・ストアでアプリケーション・ロール・プリンシパルに対して付与されます。
ADFセキュリティによってJAASモデルが拡張されます。ADFセキュリティ・フレームワーク権限クラスで指定されるアクションを使用して権限を定義できるようになります。このようなクラスはADFリソースに固有であり、リソースでサポートされる操作にアクションをマッピングします。Fusion Webアプリケーションのポリシー・ストアに含まれる権限では、次の項目が指定されます。
リソースの権限クラスによって定義されるアクションと、アプリケーションのADFリソース・インスタンスを関連付ける、1つ以上の権限(現在、バインド・タスク・フローとページ定義リソースでサポートされるのは表示アクションのみです)
権限の付与先として、アプリケーションによって定義されるアプリケーション・ロール(同じアクセス権を付与するメンバー・ユーザーまたはエンタープライズ・ロール(オプション)を移入します)
エンティティ・オブジェクトの場合、権限クラスでは読取り、削除および更新アクションが定義されます。
ADF権限クラスとサポートされるアクションの詳細は、付録C「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ユーザー・リポジトリを使用するように構成できます。
表41-1に、ADFセキュリティの有効化により、アプリケーションや様々なADFセキュリティ対応リソースが受ける影響を示します。ADFセキュリティを最も効果的に使用する方法の詳細は、41.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。
表41-1 ADFセキュリティ対応リソースのサマリー
ADFリソース | ADFによるセキュリティの施行方法 | アクセス権の付与方法 |
---|---|---|
すべてのユーザー・インタフェース・プロジェクトのバインド・タスク・フロー |
デフォルトで保護されます。ユーザーがバインド・タスク・フローを開始するために権限が必要です。 |
タスク・フローの権限を定義します。 バインド・タスク・フローのWebページに関連付けられている個々のページ定義ファイルの権限は、定義しないでください。 |
すべてのユーザー・インタフェース・プロジェクトのページ定義ファイル |
デフォルトで保護されます。ページ定義に関連付けられたページをユーザーが表示するために権限が必要です。 |
Webページがバインド・タスク・フローに含まれる場合は、このタスク・フローに対する権限を定義します。 Webページがバインド・タスク・フローに含まれない場合、またはWebページがバインドなしタスク・フローに含まれる場合は、ページ定義のみの権限を定義します。 バインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、権限を定義できないことに注意してください。 |
データ・モデル・プロジェクトのエンティティ・オブジェクト |
デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。 |
データ・コレクション全体レベルでアクセスを制御する必要がある場合のみ、データを保護するためにエンティティ・オブジェクトの権限を定義します。保護対象のエンティティ・オブジェクトを参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 エンティティレベルのセキュリティは注意して使用してください。または、エンティティ属性レベルでのセキュリティの定義を検討します。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。 |
データ・モデル・プロジェクトのエンティティ・オブジェクトの属性 |
デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。 |
データ・コレクションの列レベルでアクセスを制御する必要がある場合は、データを保護するためにエンティティ・オブジェクト属性の権限を定義します。保護対象のエンティティ属性を参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。 |
ADFセキュリティの処理を開始する前に、その他のOracle ADF機能を理解しておくと役に立ちます。次に、関連する他の機能へのリンクを示します。
Oracle Platform Security Servicesのセキュリティ機能の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。
Fusion WebアプリケーションのADFリソースを保護するときはJDeveloperを使用します。ADFセキュリティでは、アプリケーションのバインド・タスク・フロー、およびバインドなしタスク・フローに含まれるすべてのWebページが保護されます。この保護を有効にするには、「ADFセキュリティの構成」ウィザードを実行し、その後、ADFセキュリティ・ポリシーを定義して各リソースのユーザー・アクセス権を定義します。
アプリケーションのユーザー・インタフェースを作成するときは、「ADFセキュリティの構成」ウィザードをいつでも実行できます。選択肢は次のとおりです。
UIプロジェクトのWebページの作成と、関連するADFリソースのセキュリティ・ポリシーの定義を繰り返しながら行います。
UIプロジェクトのすべてのWebページの作成を完了してから、関連する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サーバーに移行されます。ドメインレベルのストアを使用すると、作成したテスト・ユーザーとしてログオンしてセキュリティ実装をテストできます。
セキュリティに関するすべての設計時ツールは、図41-1に示すように、メイン・メニューの「アプリケーション」→「保護」メニューの下にあります。
設計フェーズ
ADFセキュリティを有効化し、JDeveloperで実行するアプリケーションに対するポリシー・ストアを設定するには:
「ADFセキュリティの構成」ウィザードを実行することにより、動的認証を許可し、認可を実施するためにADFセキュリティを有効化します。
ウィザードの実行時に動的認証のみを有効にすることを選択した場合は、残りの設計フェーズのステップはスキップします。このウィザードを使用して、Oracle WebLogic Serverでセキュリティ・フレームワークとOPSSを統合するファイルを構成します。
ADFセキュリティ対応リソースを作成します。構成Webページ(またはリージョン)を含むバインド・タスク・フロー、またはADFバインディングを使用して設計される最上位Webページ(またはリージョン)などです。
注意: 「ADFセキュリティの構成」ウィザードを実行すると、ADFセキュリティ対応リソースに関連付けられるすべてのWebページが保護されます。つまり、アプリケーションを実行してセキュリティをテストする前に、Webページをアクセス可能にするためにセキュリティ・ポリシーを定義する必要があります。
ADFセキュリティ対応リソースと、作成した1つ以上のアプリケーション・ロールを関連付けます。
作成するアプリケーション・ロールはアプリケーションに固有であり、これを使用すると、同じレベルのアクセス権を一連のユーザー(またはメンバー・ユーザー)に付与することができます。テスト・フェーズではユーザーをいくつか作成し、作成したアプリケーション・ロールのメンバーとして追加します。
ADFセキュリティ対応リソースおよび関連する各アプリケーション・ロールにview権限を付与します。
こうすることでアプリケーション・ロールのメンバー・ユーザーにアクセス権が与えられます。権限がないとユーザーはADFセキュリティ対応リソースにアクセスできません。テスト・フェーズでは、いくつかのユーザーを作成してアプリケーション・ロールに追加します。
テスト・フェーズ
統合WebLogic Serverを使用してアイデンティティ・ストアをプロビジョニングし、セキュリティをテストするには:
ユーザーをいくつか作成します。また、必要に応じてエンタープライズ・ロールを作成します。
定義したユーザーIDとパスワードを使用してアプリケーションにログインします。エンタープライズ・ロールは、ユーザーをグループ化して、そのグループにアプリケーション・ロールを関連付けるための論理ロールです。エンタープライズ・ロールはテストのためには必要ありません。詳細は、41.4.3項「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。
作成したユーザーおよびエンタープライズ・ロール(オプション)を1つ以上のアプリケーション・ロールに関連付けます。
メンバー・ユーザー複数のアプリケーション・ロールのアクセス権を付与する必要がある場合は、1メンバー・ユーザーを複数のアプリケーション・ロールに含めることができます。
デフォルトのログイン・ページをカスタム・ログイン・ページで置き換えます(オプション)。
「ADFセキュリティの構成」ウィザードで生成されるデフォルトのログイン・ページは、ADF Facesコンポーネントを利用できません。これは、ADFセキュリティ・ポリシーのテスト用としてのみ便宜的に提供されています。カスタム・ログイン・ページは、ADF Facesコンポーネントを使用するように設計できます。
JDeveloperでアプリケーションを実行し、任意のADFセキュリティ対応リソースにアクセスします。
最初にADFセキュリティ対応リソースにアクセスしようとするとき、セキュリティ・フレームワークによってログインを求められます。
ログインし、予定どおりにページとそのリソースにアクセスできることを確認します。
ログインすると、セキュリティ・フレームワークによって、リソースにアクセスするためのユーザーの権限がチェックされます。たとえば、予期していない401未認可ユーザーのエラーを受け取った場合は、41.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 Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。
ADFセキュリティをOPSSに統合するための構成プロセスを単純にするため、JDeveloperでは「ADFセキュリティの構成」ウィザードが用意されています。このウィザードは、ADFセキュリティを使用してFusion Webアプリケーションを保護する最初の一歩となります。このウィザードはアプリケーションレベルのツールなので、実行すると、アプリケーションに含まれるすべてのユーザー・インタフェース・プロジェクトでADFセキュリティが有効になります。
注意: ADFセキュリティの構成ウィザードにより、アプリケーションのすべてのユーザー・インタフェース・プロジェクトに対してADFセキュリティが有効になります。このウィザードを実行した後で、バインド・タスク・フローに含まれる任意のWebページや、ADFページ定義に関連付けられたすべてのWebページを表示するための権限をユーザーに許可する必要があります。したがって、ウィザードを実行した後では、セキュリティ・ポリシーを定義してユーザーにview権限を付与するまで、アプリケーションは基本的にロックダウンされます。このプロセスの概要は、41.2項「ADFセキュリティ・プロセスの概要」を参照してください。 |
「ADFセキュリティの構成」ウィザードでは、認証と認可を個別に有効化することを選択できます。選択肢は次のとおりです。
ユーザー認証のみを有効化します。
ADFセキュリティでは認証にJava EEコンテナ管理のセキュリティを利用しますが、認証のみを有効化すると、ユーザーのログインとログアウトにはADF認証サーブレットを使用し、Webページの保護にはコンテナ管理のセキュリティ制約を定義することになります。
ユーザー認証を有効化し、認可も有効化します。
認可を有効化することは、ADFリソースに対してセキュリティ・ポリシーを作成することで、Fusion Webアプリケーションに対するアクセスの制御を意図することを意味します。
ADFセキュリティ・フレームワークではこれら2つの方法がサポートされるため、Java EEセキュリティを実装した上で、ADF認証サーブレットを使用したログインとログアウトに対応することができます。ADF認証サーブレットを有効化する利点は、ユーザーがアプリケーションに最初にアクセスするとき、サーブレットが自動的にユーザーにログインを求めることです。ADF認証サーブレットでも、認証が正常に終了すると、定義された開始ページにユーザーがリダイレクトされます。また、ユーザーがアプリケーションからログアウトする際にページ・リダイレクトを管理することもできます。ADFセキュリティで提供されるこのようなリダイレクト機能は、コンテナ管理セキュリティだけを使用する場合にはありません。
41.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コンポーネントを使用するカスタム・ログイン・ページでデフォルトのログイン・ページを置き換える方法の詳細は、41.7項「ログイン・ページの作成」を参照してください。 |
始める前に:
ADFセキュリティの構成ウィザードの知識があると役立ちます。詳細は、41.3項「ADFセキュリティの有効化」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
アプリケーションに対してADFセキュリティを有効化するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。
「ADFセキュリティ」ページではデフォルトで「ADF認証および認可」オプションが選択されています。「次へ」をクリックします。
デフォルト・オプションが選択された状態でウィザードを実行すると、アプリケーションはADFセキュリティ対応リソースの認可を施行します。ADFリソースの認可の施行とは、アプリケーションのWebページにアクセスできるようにするために、それらのリソースに対するセキュリティ・ポリシーを定義することを意味します。定義を行うまでは、ADFバインド・タスク・フローに依存するすべてのページとADFページ定義は保護された状態になります。
ADFセキュリティを構成するためのウィザードの他の2つのオプションは、ADFセキュリティを有効化する場合は使用しないでください。これらのオプションを使用すると、一時的にADFセキュリティを無効化して、41.10項「ADFセキュリティの無効化」で説明するようにセキュリティ保護なしでアプリケーションを実行できます。
具体的には図41-2に示すように、ウィザードの最初のページには3つのオプションがあり、デフォルトのオプションとして「ADF認証および認可」が有効になっています。
「ADF認証および認可」(デフォルト)では、ADF認証サーブレットが有効化され、ユーザーがログインおよびログアウトする際に構成済のWebページにリダイレクトできます。このオプションを使用すると、ADF認可を有効化して、ADFリソースについて定義したセキュリティ・ポリシーに対する認可チェックを施行することもできます。このオプションを選択した場合は、アプリケーション・ロールを定義し、明示的な権限をそのロールに割り当てて、ADFセキュリティ対応リソースへのアクセスを管理します。
「ADF認証」を選択すると、アプリケーションのページが最初にアクセスされたときに、ADF認証サーブレットがユーザーのログインを要求します。また、Java EEアプリケーション・ルート「/」をJava EEセキュリティ制約(ユーザー認証をトリガーする)にマップすることで、ページ・リダイレクトがサポートされます。ウィザードによりADF認可が無効になるため、ADFリソースに対するセキュリティ・ポリシーが存在するかどうかに関係なく、認可チェックは実行されません。一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。
「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効化され、ADF Securityはポリシー権限を確認できなくなりますが、既存のポリシー・ストアは変更されません。この場合、標準的なJava EEセキュリティを使用して、ユーザーに対して、ログインし、認証を受け、URLセキュリティ制約に対してアクセス権をテストすることことを求めることができます。ウィザードをこのオプションで実行すると、ADFリソースに対するきめ細かいセキュリティが無効になることに注意してください。
注意: 現在のリリースでは、「アイデンティティ・ガバナンス・フレームワーク(IGF)の有効化」チェック・ボックスはデフォルトでは無効になっています。このオプションを選択しても、追加機能は提供されません。この機能は今後のリリースで有効になる予定です。IGFの詳細は、Identity Governance Frameworkを使用したアプリケーションの開発を参照してください。 |
「認証タイプ」ページで、ユーザーがログイン情報を送信したときにアプリケーションで使用する認証タイプを選択します。「次へ」をクリックします。
ADF認証サーブレットがBasic認証で作動せず、ログアウトしたユーザーがリソースにアクセスできるという問題が明らかになっています。Basic認証のかわりにフォームベース認証を使用してください。この問題の詳細は、41.7.7項「ADFサーブレットのログアウトとブラウザのキャッシュに関する必知事項」を参照してください。
「フォームベース認証」を選択した場合は、「デフォルト・ページの生成」を選択して、ウィザードでデフォルトのログイン・ページおよびエラー・ページを生成できます。デフォルトでは、図41-3に示すように、ウィザードによって、ユーザー・インタフェース・プロジェクトのトップ・レベルに、ログイン・ページとエラー・ページが生成されます。場所を変更する場合は、ユーザー・インタフェース・プロジェクトを基準としたフルパスを指定します。
「自動ポリシー付与」ページでは、デフォルトで選択されている「自動付与なし」オプションをそのままにしておきます。「次へ」をクリックします。
「自動付与なし」を選択すると、アプリケーション固有の明示的な権限を定義する必要があります。test-all
アプリケーション・ロールを使用すると、ADF認可により施行される制限アクセスなしで、アプリケーション・リソースを実行してテストできるので便利です。ただし、このようにすると、アプリケーションの一部のリソースが保護されない状態になるリスクが高まります。
または、ウィザードを使用してtest-all
アプリケーション・ロールに権限を付与できます。test-all
ロールへの権限付与を有効化すると、アプリケーションのアクセス・ポリシーを調整する用意ができるまで、ADFリソースに対する明示的な権限の定義を延期することができます。自動付与の有効化を決めた場合は、test-all
ロールの権限をアプリケーションの明示的な権限で置き換えるまで、アプリケーション開発をあまり進めずに、アプリケーションの内容が確定してしまわないようにしてください。明示的な権限により、ユーザーがこれらのリソースにアクセスするために必要な権限(たとえばページのview
)が確立されます。test-all
ロールの詳細は、41.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
と表示されます。
他のリダイレクト・オプションの指定の詳細は、41.7.5項「認証後にユーザーをリダイレクトする方法」を参照してください。
サマリー・ページで選択内容を確認し、「終了」をクリックします。
「ADFセキュリティ」ページでデフォルトの「ADF認証および認可」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、次のようになります。
ADF認証が有効化されます。ユーザーにログインを求め、ページ・リダイレクトを行います。
ADF認可チェックが有効化され、認可ユーザーのみがADFリソースにアクセスできます。
ウィザードによりセキュリティ関連の構成ファイルがすべて更新され、デフォルトでADFリソースがセキュリティ保護されます。表41-2に、ADFセキュリティの設定ウィザードにより更新されるファイルを示します。
表41-2 ADF認証および認可で更新されるファイル
ファイル | ファイルの場所 | ウィザードの構成 |
---|---|---|
|
ユーザー・インタフェース・プロジェクトに相対する JDeveloperでは、ユーザー・インタフェース・プロジェクト内の「Webコンテンツ」→WEB-INFノードの下 |
|
|
Webアプリケーション・ワークスペースに相対する JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→ADF META-INFノードの下 |
|
|
Webアプリケーション・ワークスペースに相対する JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノードの下 |
|
|
Webアプリケーション・ワークスペースに相対する JDeveloperでは、ユーザー・インタフェース・プロジェクト内の「Webコンテンツ」→WEB-INFノードの下 |
|
|
.Webアプリケーション・ワークスペースに相対する JDeveloperでは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノードの下 |
|
認証はWebコンテナに委任されるため、ウィザードはweb.xml
ファイルのみを更新し、ADF認証サーブレットが動的に認証をトリガーできるようにします。例41-1に示すように、ADF認証サーブレットのサーブレット・マッピングが定義され、2つのJava EEセキュリティ制約allPages
およびadfAuthentication
がweb.xml
ファイルに追加されます。
例41-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認証サーブレットにリダイレクトしたりする必要はありません。
注意: ログインを明示的にトリガーするログイン・リンクまたはログイン・ボタンを用意する場合は、 |
アプリケーションのすべてのユーザーがログインできる必要があるため、adfAuthentication
リソースに定義されるセキュリティ制約を使用すると、すべてのユーザーがこのWebリソースにアクセスできるようになります。このように、制約に関連付けられるセキュリティ・ロールはすべてのユーザーを含む必要があります。このタスクを簡略化するため、Java EE valid-users
ロールが定義されています。weblogic.xml
ファイルでは、このロールが、Oracle WebLogic Serverによって定義された暗黙のusers
グループにマッピングされます。このマッピングにより、すべてのユーザーがこのロールを持つことが保証されます。41.3.7項「valid-usersロールに関する必知事項」で説明するように、Oracle WebLogic Serverは、正しく認証されたすべてのユーザーをusers
グループのメンバーとして構成するためです。
注意:
|
認可を有効化するため、ウィザードはadf-config.xml
ファイルを更新し、例41-2
に示すように<JaasSecurityContext>
要素のauthorizationEnforce
パラメータをtrueに設定します。
例41-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セキュリティ・コンテキストのアクセス方法の詳細は、41.11.3項「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。
ウィザードで生成されるログイン・ページおよびエラー・ページは単純なHTMLページです。ユーザー・インタフェース・プロジェクトの最上位フォルダに追加されます。生成されるログイン・ページでは、ユーザーのログイン・リクエストを標準のj_security_check
アクションによって送信するHTMLフォームが定義されます。このアクションとフォームベース認証(ウィザードで提供されるコンテナ認証のデフォルト・オプション)を使用すると、Webコンテナでユーザーに対して様々なWebアプリケーション・リソースを認証できるようになります。
ウィザードはweb.xml
ファイルを更新し、例41-3に示すように、フォームベース認証を指定してページの場所を指定します。
例41-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アプリケーションにはパブリック・ページの概念もあり、明示的な認証と暗黙的な認証に対応します。つまり、ユーザーは保護されたコンテンツに移動する前にログイン・リンクをクリックすることによってアプリケーションにログインできるということです。ログイン・リンクの作成および使用の詳細は、41.7項「ログイン・ページの作成」を参照してください。
最初に「ADFセキュリティの構成」ウィザードを実行して認証と認可を有効にすると、アプリケーション・レベルでADFリソースが保護されます。さらに、ユーザー・インタフェース・プロジェクトについて特定のプロジェクトレベル設定(認証のタイプや認証のようこそページなど)を選択します。ウィザードによって、選択するプロジェクトのweb.xml
ファイルにWebアプリケーション設定が追加されます。アプリケーションに複数のユーザー・インタフェース・プロジェクトとweb.xml
ファイルが含まれる場合は、ウィザードに戻り、選択する別のユーザー・インタフェース・プロジェクトのweb.xml
ファイルでこれらの設定を構成します。
Java EEコンテナ管理の認証を使用するログイン用のADFアプリケーションとログアウト用のADF認証は、特別な要件なしでOracle Single Sign-On (Oracle SSO)と統合されます。ADF認証サーブレットは、ログアウトの詳細を処理し、セッションを無効にします。ただし、アプリケーションがServlet 3.0によって提供されるログインおよびログアウトのメソッドを使用している場合、Oracle SSOはサポートされません。さらに、Servlet 3.0のログインおよびログアウトは、Java EE 6以降を完全にサポートするアプリケーション・サーバーのみと互換性があります。
ADFセキュリティ対応リソースに依存するページが最初にアクセスされたとき、サブジェクトが定義されていないと、anonymous
ユーザー・プリンシパルとanonymous-role
ロール・プリンシパルを含むサブジェクトを構成するようにOPSSがJpsFilter
によって構成されます。このロール・プリンシパルを使用すると、認証されていないユーザーが、どのADFセキュリティ対応リソース(ADFバインド・タスク・フローまたはページ定義など)にも関連付けられていないパブリックWebページにアクセスできます。
ADFセキュリティ対応リソースに関連付けられているページの場合は、無名ユーザーがページにアクセスできるようにするには、view
権限をanonymous-role
に明示的に付与する必要があります。無名ユーザーへの権限付与の詳細は、41.5.1項「ADFリソースを公開する方法」を参照してください。
ADFセキュリティの構成ウィザードを使用して、アプリケーションのすべてのADFセキュリティ対応リソースのview権限を付与するために、組込みtest-all
アプリケーション・ロールへの自動付与を有効にすることができます。権限(自動view権限またはユーザー定義の明示的な権限)が付与されないと、ADFセキュリティの認可チェックの施行により、アプリケーションの実行とリソースへのアクセスを行えなくなります。test-all
アプリケーション・ロール機能を有効にしてウィザードを実行し、その後、自動view権限を明示的な権限で段階的に置き換えることができます。test-all
アプリケーション・ロールの権限が設定された状態ではアプリケーションをデプロイしないでください。この機能のためにすべてのADFリソースが公開されるためです。ウィザードで組込みtest-all
アプリケーション・ロールの有効化を選択する場合は、アプリケーションをデプロイする前に41.9.1項「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」を参照してください。
valid-users
ロールは、ADFセキュリティによって定義されたJava EEセキュリティ・ロールです。このロールにより、web.xml
ファイルで定義されたadfAuthentication
サーブレットWebリソースにすべてのユーザーがアクセスできることが保証されます。ADFセキュリティの構成ウィザードはweblogic.xml
ファイルを更新し、例41-4に示すように、このADFセキュリティ・ロールをusers
プリンシパルにマッピングします。Oracle WebLogic Serverは、正常に認証されたすべてのユーザーをusers
グループのメンバーとして構成するため、このマッピングによりすべてのユーザーがこのロールを持ちます。
例41-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権限は関係ありません。
アプリケーション・ロールを作成して、アプリケーションのポリシー要件を表し、同じview権限を持つユーザーのグループを定義します。アプリケーション・ポリシー・ストアに作成するアプリケーション・ロールは、お使いのアプリケーション固有のものです。たとえば、ワークフローのコンテキストでは、Application Customer Role
やApplication Employee Role
などのアプリケーション・ロールが、Summit ADFサンプル・アプリケーションのSummitADF_TaskFlows
で定義されていることがあります。
実行時には、ユーザーがメンバーとして定義されているアプリケーション・ロールにより、ユーザーにアクセス権が付与されます。このように、セキュリティ・ポリシーを定義する前に、権限の付与先にするアプリケーション・ロールをポリシー・ストアに含める必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Role
など)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-role
またはanonymous-role
)のいずれかでもかまいません。JDeveloperで提供される組込みアプリケーション・ロールを使用すると、41.5.1項「ADFリソースを公開する方法」で説明するようにADFリソースを公開できます。
アプリケーション・ロールを作成した後は、次の手順を実行します。
権限をアプリケーション・ロールに付与します。41.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
テスト・ユーザーを各アプリケーション・ロールに関連付けます。41.6項「テスト・ユーザーの作成」を参照してください。
ベスト・プラクティス: ADFセキュリティ・フレームワークは、アプリケーション・ロールまたは個々のユーザーに付与された権限に基づいて、ロールベースのアクセス制御メカニズムを施行します。セキュリティのテストのみを行う必要があり、ユーザー・グループを作成する必要がなくても、アプリケーション・ロール(少なくとも1ユーザー・メンバーを含む)を作成しなければなりません。後でADFリソースのセキュリティ・ポリシーを定義するとき、アプリケーション・ポリシー・ストアの概要エディタを使用して、権限に対してアプリケーション・ロールを選択できます。 |
JDeveloperでは、アプリケーション・ロールをjazn-data.xml
ファイルのポリシー・ストアに格納できます。これは、「アプリケーション・リソース」パネルのDescriptors/META-INFノードに表示されます。
注意: アプリケーション・ロールを作成するときは、新しいアプリケーション・ロールをアイデンティティ・ストアではなくポリシー・ストアに追加してください。アイデンティティ・ストアに追加するロールによって、エンタープライズ・セキュリティ・ロールが定義されます。また、このロールは、アイデンティティ・ストア内のユーザーをグループ化するときに役立ちます。エンタープライズ・ロールの詳細は、41.4.3項「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。 |
jazn-data.xml
ファイルのポリシー・ストアにアプリケーション・ロールを作成するには、jazn-data.xml
ファイルの概要エディタの「アプリケーション・ロール」ページを使用します。このエディタを使用すると、アイデンティティ・ストアのメンバーと、作成するアプリケーション・ロールの関係を表示できます。
始める前に:
アプリケーション・ロールについて理解しておくと役立ちます。詳細は、41.4項「アプリケーション・ロールの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
アプリケーション・ロールを作成するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。
jazn-data.xml
概要エディタの「アプリケーション・ロール」ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。
JDeveloperによってjazn-data.xml
ファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。
「ロール」リストで「新規」アイコンをクリックします。
「名前」フィールドにロール名を入力します。他のいずれかのフィールドをクリックすると、アプリケーション・ロールがポリシー・ストアに追加されます。
テスト・ユーザーをアイデンティティ・ストアにすでに設定している場合は、41.6.3項「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」に従ってユーザーとロールをマッピングできます。
アプリケーション・ロールをポリシー・ストアに追加すると、アプリケーション・ワークスペースを基準とするsrc/META-INF
ディレクトリにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。アプリケーション・ロールは、例41-5に示すように<policy-store>
内の<app-role>
要素に定義されます。ポリシー・ストアの<application>
要素にアプリケーションが指定されるため、作成するすべてのアプリケーション・ロールは、実行時にそのアプリケーションに対してのみ有効になります。他のWebアプリケーションは、独自のアプリケーション・ロールのセットを含むポリシー・ストアを定義できます。
例41-5 ポリシー・ストアでのアプリケーション・ロール定義
<policy-store> <applications> <application> <name>SummitADFTaskFlows</name> <app-roles> <app-role> <name>Application Employee Role</name> <display-name>Application Employee Role</display-name> <class>oracle.security.jps.service.policystore. ApplicationRole</class> </app-role> ... </app-roles> <jazn-policy> ... </jazn-policy> </application> </applictions> </policy-store>
エンタープライズ・ロールは、ドメインのアイデンティティ・ストア(アプリケーションのアイデンティティ・ストアではなく)で管理されるロールです。ドメインにデプロイされているすべてのアプリケーションが使用できるため、エンタープライズ・ロールは外部ロールとも呼ばれます。
アプリケーション・ロールはFusion Webアプリケーションで使用されるロールです。これはアプリケーション固有であり、アプリケーション・ポリシーで定義するものなので、Java EEコンテナで認識できるとはかぎりません。アプリケーション・ロールは、アプリケーションに定義されたユーザーとロールのみを含むという意味でスコープ指定されています。アプリケーション・ロールはエンタープライズ・ロールにマッピングする必要があります。
jazn-data.xml
ファイルの概要エディタを使用して、アイデンティティ・ストアに追加するユーザーをグループ分けするためのエンタープライズ・ロールを作成します。この仕組みを使用すると、41.6.3項「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」で説明するように、定義したアプリケーション・ロールにすべてのユーザー・グループを割り当てて、ADFセキュリティ・ポリシーで定義されたアクセス権を付与することができます。
ただし、統合WebLogic Serverでは、JDeveloper内でアプリケーションを実行するためにエンタープライズ・ロールを作成する必要はありません。アプリケーションをテストするためには、少数のテスト・ユーザーを作成して、アプリケーションに直接割り当てるだけで十分な場合があります。アプリケーションをJDeveloperで実行すると、ユーザーと定義済エンタープライズ・ロールが、デフォルトのセキュリティ・プロバイダ(統合WebLogic Serverの埋込みLDAP)に作成されます。
通常、ステージングのためにアプリケーションをデプロイするときは、ポリシー・ストアのみをターゲット・サーバーに移行します。41.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、アイデンティティ・ストア(テスト・ユーザーとエンタープライズ・ロールを含む)が移行されないように、JDeveloperデプロイメント・オプションを構成できます。
セキュア・アプリケーションをデプロイすると、Oracle Fusion Middlewareはアプリケーションのポリシー・ストアをドメインレベル・ポリシー・ストアのポリシーとマージします。このタスクを完了するために、Oracle WebLogic Serverの管理者は、最終的にポリシー・ストアのアプリケーション・ロールを既存のドメインレベル・エンタープライズ・ロールにマッピングします。ドメイン・レベルでのこのようにアプリケーション・ロールをマッピングすると、定義したADFセキュリティ・ポリシーに従ってエンタープライズ・ユーザーがアプリケーション・リソースにアクセスできるようになります。また、管理者がドメインレベルでアプリケーション・ロール・マッピングを行うことにより、本番環境のアイデンティティ・ストアの知識がなくても、アプリケーションのADFセキュリティ・ポリシーを開発できるようになります。
認可で利用されるポリシー・ストアは、実行時にアクセスされ、指定したオブジェクトに対する事前定義済のアクション(view
など)を実行するための権限を含みます。当初、「ADFセキュリティの構成」ウィンドウを実行した後では、ポリシー・ストアでは権限が定義されていません。また、デフォルトのウィザード・オプション「ADF認証および認可」では認可チェックが有効になるため、ADFセキュリティ対応リソースに依存するアプリケーションのWebページにユーザーはアクセスできません。ユーザーのアクセスを許可するリソースに明示的な権限を定義するには、JDeveloperを使用する必要があります。
ベスト・プラクティス: デフォルト・オプション「ADF認証および認可」を選択してADFセキュリティの構成ウィザードを実行すると、アプリケーションのWebページがロックダウンされます。このとき、Fusion Webアプリケーションに最大限の保護を実現できます。指定するページのみのアクセスをユーザーに許可するように、明示的な権限を定義するためです。このようなガイドラインの詳細は、41.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。 |
セキュリティ・ポリシーを定義するには、アプリケーションのポリシー・ストアに、権限を付与するアプリケーション・ロールが含まれる必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Role
など)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-role
またはanonymous-role
)のいずれかでもかまいません。アプリケーション・ロールは、同じロールの各メンバーが同じアクセス権を持つようにユーザーを分類する目的で使用できます。このため、セキュリティ・ポリシーにより、アプリケーション・ロールには、(個別のユーザーでなく)権限のプリンシパルの名前が付けられます。アプリケーション・ロールの定義の詳細は、41.4項「アプリケーション・ロールの作成」を参照してください。
ユーザー・インタフェース・プロジェクトの場合、セキュリティ・ポリシーに対応する概要エディタを使用して、ADFタスク・フローとADFページ定義などのADFリソースをセキュリティ保護します。jazn-data.xml
ファイルのエディタを開きます。これには、jazn-data.xml
ファイル(「アプリケーション・リソース」パネル)をダブルクリックするか、メイン・メニューの「アプリケーション」メニューから「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルを開くと、テスト・ユーザー、エンタープライズ・ロールおよびアプリケーション・ロールを作成するために別のエディタ・ページが概要エディタに表示されることに注意してください。
データ・モデル・プロジェクトの場合、エンティティ・オブジェクトまたはその属性のセキュリティを保護するのに、セキュリティ・ポリシーの概要エディタは使用しません。かわりに、これらのオブジェクトにメタデータを直接設定して、データバインドUIコンポーネントがデータを表示するかどうかを管理します。行レベル・セキュリティの権限付与の詳細は、41.5.11項「データのポリシーを定義する方法」を参照してください。
個別のアクセス権限にかかわらず、一部のWebページをすべてのユーザーが表示できるようにするのは、一般的な要件です。たとえば、ホームページは、サイトにアクセスするすべてのユーザーに対して表示する必要がありますが、企業サイトは認証によって身元が確認されたユーザーのみに表示する必要があります。
どちらの場合も、ページを表示する権限がユーザーの特定の権限によって定義されているわけではないので、ページはパブリックであると考えられます。両者の違いは、ユーザーが匿名であるか、それとも既知のアイデンティティであるかです。
ADFセキュリティ・モデルでは、アクセス権限をanonymous-role
プリンシパルに付与することで、セキュリティの欠如とコンテンツの公開アクセスを区別します。匿名ロールは、既知のユーザーと無名ユーザーの両方を含みます。したがって、anonymous-role
に付与される権限を使用すると、認証されていないユーザー(たとえばゲスト・ユーザー)によるリソースへのアクセスを許可できます。認証済ユーザーのみにアクセスを許可するには、authenticated-role
プリンシパルにポリシーを定義する必要があります。
始める前に:
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、41.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
バインド・タスク・フローを作成します。20.2項「タスク・フローの作成」を参照してください。
ADFページ定義ファイルを含むWebページを作成します。17.7項「ページ定義ファイルでの作業」を参照してください。
ADFセキュリティの構成ウィザードを実行します。41.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。41.4項「アプリケーション・ロールの作成」を参照してください。
ADFセキュリティ対応リソースに対する公開アクセス権を付与するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから次のいずれかのリソースを選択します。
「タスク・フロー」(バインド・タスク・フローを公開する場合)。アプリケーションによって、タスク・フローそのものに定義した権限の下でWebページが表示されます。つまり、バインド・タスク・フローのすべての構成Webページが公開されます。
「Webページ」(個別のWebページを公開する場合)。通常、これらのページはバインドなしタスク・フローに定義された、アプリケーションのトップレベル・ページ(ホームページなど)です。
「リソース」列で、アクセス権を付与するADFリソースを選択します。
選択するリソースは、リソース名の横の最初の列にロック・アイコンが表示されている必要があります。ロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図41-4ではADFリソースcustomer-registration-task-flow
(バインド・タスク・フロー)は権限が定義されていないため、ロック・アイコンが表示されています。
ヒント: 概要エディタの先頭列のヘッダーにあるキー切替えアイコンをクリックして、すでに権限が定義されたリソースの非表示と表示を切り替え、権限のないリソースのみを表示します。キー・アイコンは、リソースに権限が定義されており、十分なアクセス権を持つユーザーがアクセスできることを示します。 |
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、次の組込みアプリケーション・ロールから1つを選択します。
anonymous-roleは、サイトにアクセスするすべてのユーザーがリソースにアクセスできることを意味します。このロールへの権限付与が必要となるのは、ユーザーがログインしなくても、ADFセキュリティ対応リソースに関連するWebページにアクセスできるようにする場合です。たとえば、顧客の登録を管理するタスク・フローについてanonymous-role
に権限を付与します。
authenticated-roleは、認証されたユーザー(サイトにアクセスしてログインしたユーザー)のみがリソースにアクセスできることを意味します。たとえば、従業員登録のタスク・フローについてauthenticated-role
に権限を付与します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。
デフォルトでは、図41-5のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。
セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルが更新されます。
概要エディタは、ファイルの<policy-store>
セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロール(この場合は匿名ロール)です。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。
例41-6に示すjazn-data.xml
ファイルのセキュリティ・ポリシーでは顧客登録タスク・フローが公開されます。anonymous-role
に対する権限には、バインド・タスク・フローcustomer-registration-task-flow
の1つのview権限が含まれます。この権限により、すべてのユーザーが顧客登録タスク・フローを開始して顧客登録プロセスを完了できます。匿名ロールに権限を追加することもでき、匿名ロール権限の<permissions>
セクションに表示されます。
例41-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>
anonymous-role
およびauthenticated-role
という名前は、Oracle Platform Security Services (OPSS)によって定義される特別なロールです。
「ADFセキュリティの構成」ウィザードを実行すると、匿名ロールのサポートを有効にするJpsFilter
定義がweb.xml
ファイルに構成されます。匿名ロールを有効にすると、無名ユーザー(ログインしていないユーザー)によるサイトのブラウズがADFセキュリティによってサポートされます。反対に、認証ロールは宣言されず、デフォルトで常に識別されます。ADFセキュリティでは両方のロールがサポートされます。
エンド・ユーザーがADFセキュリティ対応リソースに最初にアクセスするとき、システムによってサブジェクトが作成され、匿名ロール・プリンシパルがそのサブジェクトに移入されます。アクセス対象のADFセキュリティ対応リソースのview権限が匿名ロールに付与されているかぎり、ユーザーのアクセスが許可されます。匿名ロールがADFリソースの権限受領者でない場合、ユーザーはログインするように求められます。ログインすると認証ロールがサブジェクトに追加されます。また、ウィザードによってJpsFilter
定義がweb.xml
ファイルに追加されます。remove.anonymous.role
はfalse
に設定され、ユーザーがログインした後でも匿名ロール・プリンシパルが使用可能になります。認証ロール・プリンシパルを使用すると、認証ロールに対して明示的に権限が付与されたリソースにユーザーがアクセスできます。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFバインド・タスク・フローのアクセス・ポリシーを定義します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はバインド・タスク・フロー定義名)を定義します。
ベスト・プラクティス: バインド・タスク・フローの個々のWebページに対しては権限を作成しないでください。ユーザーがバインド・タスク・フローにアクセスする場合、すべてのページのセキュリティはタスク・フローに付与する権限により管理されます。また、含まれている(ページ定義が関連付けられている) Webページにはデフォルトでアクセスできないため、ADFセキュリティではユーザーによるタスク・フローのページへの直接アクセスが禁止されます。これにより、タスク・フローの明確なセキュリティ・モデルがサポートされ、すべてのユーザーに単一エントリ・ポイントを強制します。セキュリティ・ポリシーの実装方法の詳細は、41.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。 |
表41-3で説明するように、概要エディタで「タスク・フロー」ヘッダーの切替えボタンをクリックすると、タスク・フローをソートできます。
表41-3 バインド・タスク・フローのリソース権限切替えボタン
ボタン | 切替えアクション | 説明 |
---|---|---|
|
権限のないバインド・タスク・フローの表示または非表示 |
権限が定義されていないバインド・タスク・フローを表します。タスク・フローがコールするWebページにはすべてのユーザーがアクセスできません。 |
|
権限付きのバインド・タスク・フローの表示または非表示 |
1つ以上の権限が定義されたバインド・タスク・フローを表します。タスク・フローがコールするWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。 |
概要エディタに表示される、利用できるアクションのリストは、タスク・フロー権限クラス(oracle.adf.controller.security.TaskFlowPermission
)によって定義されます。権限クラスは、これらのアクションを、タスク・フローがサポートする操作にマップします。表41-4に、JDeveloperによって表示される、ADFバインド・タスク・フローに対するアクションを示します。
Fusion Webアプリケーションで現在サポートされているのはview
アクションのみです。customize
、grant
またはpersonalize
アクションを選択しないでください。これらはタスク・フロー・セキュリティで将来使用するために用意されています。
表41-4 ADFバインド・タスク・フローのセキュリティ保護されたアクション
許可できるアクション | ユーザー・インタフェースへの影響 |
---|---|
|
Fusion Webアプリケーションのバインド・タスク・フローの読取りと実行を行うユーザーを制御します。 これは、タスク・フローがサポートする唯一の動作です。 |
|
今後の使用のために確保されています。このアクションは実行時にチェックされません。 |
|
今後の使用のために確保されています。このアクションは実行時にチェックされません。 |
|
今後の使用のために確保されています。このアクションは実行時にチェックされません。 |
タスク・フロー・セキュリティ・ポリシーの権限を定義するには、jazn-data.xml
ファイルの概要エディタの「リソース権限」ページを使用します。
始める前に:
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、41.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
バインド・タスク・フローを作成します。20.2項「タスク・フローの作成」を参照してください。
ベスト・プラクティス: 同じアプリケーションの別のUIプロジェクトのバインド・タスク・フローを作成している場合、一意のタスク・フロー定義名を割り当てることをお薦めします。これが必要になるのは、権限のタスク・フロー定義名が |
ADFセキュリティの構成ウィザードを実行します。41.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。41.4項「アプリケーション・ロールの作成」を参照してください。
ADFバインド・タスク・フローで権限を定義するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択します。
概要エディタに、アプリケーションで定義されるすべてのタスク・フローが表示されます。タスク・フローは、ユーザー・インタフェース・プロジェクトの「Webコンテンツ/ページ・フロー」ノードに表示されるタスク・フロー定義ファイル(.xml
)で定義されます。
「リソース」列で、アクセス権を付与するタスク・フローを選択します。
最初にバインド・タスク・フローに権限付与を行うとき、最初の列のタスク・フロー名の横に「権限のないリソースを表示します。」アイコン(ロックを表すアイコン)が表示されます。概要エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。
ヒント: 「リソース」列のヘッダーの「権限付きリソースを表示します。」アイコン(キーを表すアイコン)をクリックすると、すでに権限が定義されているすべてのタスク・フローが非表示になります。こうすることで、図41-6のように権限のないタスク・フローのみが表示されます。さらに、タスク・フロー名の一部を検索フィールドに入力すると、文字が一致する名前のタスク・フローのみを表示できます。 |
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。41.5.3項「実行時に行われる処理: 組込みロールの使用方法」
で説明したように、組込みOPSSアプリケーション・ロール、anonymous-role
およびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、41.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタの「リソース権限」ページの「アクション」列では、viewアクションが選択されたままにしておきます。
デフォルトでは、図41-7のように概要エディタにviewアクションが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。customize、grantまたはpersonalizeアクションを選択しないでください。これらは将来の使用のために用意されているものです。実行時にADFセキュリティでチェックされることはありません。
TaskFlowPermission
クラスによってタスク・フロー(タスク・フローの操作にマッピングされる特定のアクション)が定義されます。表41-4を参照してください。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のタスク・フロー定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。41.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFページ定義のアクセス・ポリシーを定義します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はページ定義名)を定義します。
ベスト・プラクティス: 個々のWebページの権限を作成するのは、そのページがバインド・タスク・フローの構成ページでない場合のみです。ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。セキュリティ・ポリシーの実装方法の詳細は、41.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。 |
表41-5で説明するように、概要エディタで「リソース」ヘッダーの切替えボタンをクリックするとWebページ定義リソースをソートできます。
表41-5 Webページ定義のリソース権限切替えボタン
ボタン | 切替えアクション | 説明 |
---|---|---|
|
権限のないトップレベル・ページの表示または非表示 |
バインドなしタスク・フローに含まれるWebページに対して定義された権限がないページ定義を表します。このWebページにはどのユーザーもアクセスできません。 |
|
権限付きのトップレベル・ページの表示または非表示 |
バインドなしタスク・フローに含まれるWebページに対して定義された1つ以上の権限があるページ定義を表します。このWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。 |
|
バインド・タスク・フローに含まれるページの表示または非表示 |
バインド・タスク・フローにも含まれるWebページに関連付けられたページ定義を表します。このようなWebページ定義には権限を付与しないでください。かわりに、バインド・タスク・フローのセキュリティ・ポリシーを定義します。 |
|
保護できないページ(ページ定義なし)の表示または非表示 |
バインドなしタスク・フローに含まれる、ページ定義が定義されていないWebページを表します。(バインド・タスク・フローに含まれる同様のページは、バインド・タスク・フローの権限によって保護されます。)Webページは、ADFセキュリティ対応リソースにより保護されていないため、すべてのユーザーによりアクセス可能です。41.5.9項「ADFバインドなしのページのポリシー定義に関する必知事項」で説明するように、必要に応じて、空のページ定義ファイルを追加することでページを保護できます。 |
概要エディタに表示される、利用できるアクションのリストは、リージョン権限クラス(oracle.adf.share.security.authorization.RegionPermission
)によって定義されます。権限クラスは、これらのアクションを、WebページのADFページ定義がサポートする操作にマップします。表41-6に、JDeveloperによって表示される、ADFページ定義に対するアクションを示します。
Fusion Webアプリケーションで現在サポートされているのはview
アクションのみです。
表41-6 ADFページ定義のセキュアなアクション
許可できるアクション | ユーザー・インタフェースへの影響 |
---|---|
|
ページを表示できるユーザーを制御します。 これは、ページ定義がサポートする唯一の動作です。 |
ページ定義セキュリティ・ポリシーの権限を定義するには、jazn-data.xml
ファイルの概要エディタの「リソース権限」ページを使用します。
始める前に:
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、41.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
ADFページ定義ファイルを含むトップレベルWebページを作成します。17.7項「ページ定義ファイルでの作業」を参照してください。
ベスト・プラクティス: 同じアプリケーションの別のUIプロジェクトのトップレベルWebページを作成している場合、一意のページ・ファイル名を割り当てることをお薦めします。これが必要になるのは、権限のページ定義が |
ADFセキュリティの構成ウィザードを実行します。41.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。41.4項「アプリケーション・ロールの作成」を参照してください。
ADFページ定義に権限を定義するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択します。
概要エディタの「リソース権限」ページには、ADFページ定義が関連付けられているページも含め、すべてのWebページが表示されます。ADFデータバインディングを使用するあらゆるWebページや、空のページ定義を作成しておいたあらゆるWebページも含まれます。ページ定義は、ユーザー・インタフェース・プロジェクトの「アプリケーション・ソース」ノードに表示されるPageDef.xml
ファイルで定義されます。
「リソース」列で、アクセス権を付与するページ定義を選択します。
最初にページ定義に権限付与を行うとき、最初の列のページ定義名の横に「権限のないリソースを表示します。」アイコン(ロック・アイコン)が表示されます。エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図41-8のページ定義account_updateUserInfo
には権限が付与されていないためロック・アイコンが表示されます。図41-8の他のページ定義には「バインド・タスク・フローに含まれるページ」アイコンが表示されます。これらはトップレベル・ページではなく、含まれているバインド・タスク・フローによって保護されるためです。
「バインド・タスク・フローに含まれるページ」アイコンが表示されている個々のWebページ定義には権限を作成しないでください。関連付けられたWebページのセキュリティ・ポリシーは、バインド・タスク・フローによって保護されます。たとえば、図41-8のaccount_addressDetails.jsff
リージョンに関連付けられているページ定義は、それが含まれているバインド・タスク・フローによって保護されます。
ヒント: ページ定義名の一部を検索フィールドに入力すると、文字が一致する名前のページ定義のみを表示できます。たとえば、 |
ヒント: 権限付きリソースのアイコン(キー・アイコン)をクリックすると、すでに権限があるすべてのページ定義を非表示にできます。「リソース」列のヘッダーの「バインド・タスク・フローに含まれるページを表示」切替えボタンがオフになっており、バインド・タスク・フローに含まれるページ定義がすべて非表示になっていることを確認します(デフォルトでは、これらのページが非表示になるように設定されています)。この場合、図41-9に示すように、権限がないトップレベル・ページ(および保護できないページ)が表示されます。 |
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。41.5.3項「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、41.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタの「リソース権限」ページの「アクション」列では、Viewアクションが選択されたままにしておきます。
デフォルトでは、図41-10のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。
RegionPermission
クラスによってページ定義(ページの操作にマッピングされる特定のアクション)が定義されます。表41-6を参照してください。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のページ定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。41.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
アプリケーションによって定義されたADFメソッドは、コマンド・コンポーネントとしてユーザー・インタフェース内にドロップできます。デフォルトでは、メソッドのコマンド・コンポーネントが表示されたページにアクセス可能なユーザーには、このメソッドを実行する権限も与えられます。メソッド操作に対するアクセスを制限する追加のセキュリティを作成するには、リソース権限を作成し、ユーザー・インタフェース・レベルで権限をテストする必要があります。ADFセキュリティでは、ADFメソッドに対する認可チェックは行われません。アプリケーションでの認可チェックを独自に有効化する必要があります。ADFメソッドに対してユーザーに付与したリソース権限に基づき、ユーザー・インタフェースでコマンド・コンポーネントが有効化または無効化されます。
コマンド・コンポーネントとしてページに表示されるメソッドへのユーザー・アクセスを制御するには、次の手順を実行します。
カスタム・リソース・タイプおよびリソースに対してリソース権限を作成します。
ユーザー・インタフェースで権限付与を施行します。
リソース・タイプを作成するとマッチャ・クラスoracle.security.jps.ResourcePermission
に設定されます。これにより、アプリケーションのADFセキュリティで保護されていない部分に対して権限を付与できるようになります。たとえば、顧客への商品の出荷をユーザーが取り消すためのボタンをページに表示できます。ただし、特定のアプリケーション・ロールのメンバーのみが出荷を取り消すことができます。このルールを適用するには、実行時に宣言的にチェック可能なリソース権限をユーザー・インタフェースに作成し、ボタンを有効または無効にします。
保護対象のユーザー・インタフェース・コンポーネントに権限を作成するには、セキュリティ・ポリシーの概要エディタを使用します。
作業を始める前に、次のようにします。
ADFセキュリティによるADFメソッドの処理方法について理解しておくと役立ちます。詳細は、41.5.6項「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
30.2項「メソッドを実行するためのコマンド・コンポーネントの作成」の説明に従い、保護対象のメソッドを実行するコマンド・コンポーネントを作成します。
ADFセキュリティの構成ウィザードを実行します。41.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。41.4項「アプリケーション・ロールの作成」を参照してください。
カスタム・リソース・タイプに対するリソース権限を付与するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストの横の「新規リソース・タイプ」ボタンをクリックします。
「リソース・タイプの作成」ダイアログで、リソース・タイプの名前、JDeveloperでリソース権限を付与する際に表示される表示名、および説明を入力します。
保護が必要なユーザー・インタフェース・リソースに適したリソース・タイプと表示名を入力します。たとえば、商品の出荷を取り消すためのメソッド・ボタンを保護する場合は、リソース・タイプにCancelShipment
、表示名にCancel Shipment
などと入力します。
「アクション」リストの横の「アクションの追加」ボタンをクリックして、保護するアクションの名前を入力します。「OK」をクリックします。
アクション名には、カスタム・リソース・タイプに関連付ける任意の名前を指定できます。たとえば、メソッドを起動するボタンを保護する場合は、アクション名にinvoke
などと入力します。個別のアプリケーション・ロールに対してリソース権限のインスタンスを付与できるようにする必要がある場合は、複数のアクションをリストに追加できます。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで「リソース」列で、「リソースの追加」アイコンをクリックします。
カスタム・リソース・タイプへの権限付与を最初に行うときには、定義済のリソースはありません。ポリシーに対してカスタム・リソースを作成する必要があります。このリソースは実行時にユーザー・インタフェースでユーザー権限をチェックする際に使用されます。
「リソースの作成」ダイアログで、リソースの名前、JDeveloperでリソース権限を付与する際に表示される表示名を入力し、「OK」をクリックします。
保護対象のユーザー・インタフェース・リソースを表すリソース名と表示名を入力します。たとえば、商品の出荷を取り消すためのメソッド・ボタンを保護する場合は、リソース名にCancelShipmentButton
、表示名にCancel Shipment Button
などと入力します。
「ロールに付与済」列で「権限受領者の追加」アイコンをクリックし、「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。41.5.3項「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、41.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタの「リソース権限」ページの「アクション」列で必要なアクションを選択します。
デフォルトでは、選択されていないカスタム・リソース・タイプのすべてのアクションが概要エディタに表示されます。使用可能なアクションはリソース・タイプによって定義されます。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のADFメソッド・リソースに、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。41.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
事前に定義されているカスタム・リソース・タイプに対してユーザーのアクセス権をチェックするEL式を定義するには、UIコンポーネントの表示プロパティで開いた「式ビルダー」ダイアログを使用します。アプリケーションを実行すると、EL式によるリソース権限評価の結果に基づき、コンポーネントが有効化または無効化されます。
たとえば、例41-7に示すように、af:button#cb1
ボタンのdisabled
属性に対してuserGrantedPermission
式を定義できます。この場合、ユーザーが権限を持っているかどうかが式によってテストされ、その結果ボタンが有効化されるか、ユーザーが権限を所有していない場合はボタンが無効化されます。この式はボタンのrendered
属性に対して定義されているのではないため、ページには常にこのボタンが表示されます。
例41-7 リソース権限のチェック式
<af:button actionListener="#{bindings.myMethodName.execute}" text="myMethodName" disabled="#{!securityContext.userGrantedPermission ['resourceName=CancelShipmentButton,resourceType=CancelShipment, action=invoke']} id="cb1"/>
作業を始める前に、次のようにします。
ADFメソッド認可チェックの制限について理解しておくと役立ちます。詳細は、41.5.6項「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
式を使用してリソース権限をチェックするには:
「アプリケーション」ウィンドウで、ADFメソッドにバインドされたコマンド・コンポーネントを含むページをダブルクリックします。
ページのビジュアル・エディタで、ADFメソッドの実行に使用されるコマンド・コンポーネントを選択します。
「プロパティ」ウィンドウで、「無効」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedPermissionを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。
権限文字列は、resourceName=
aResourceName
;resourceType=
aResourceType
;action=
actionName
のようにセミコロンで連結した文字列として入力します。たとえば、ページ内でメソッドの起動に使用されるコマンド・ボタンを有効または無効にするには、例41-7に示したような式を入力します。
例41-7では、ユーザーに定義されているアプリケーション・ロールに対して、CancelShipment
というリソース・タイプの権限がリソース・ポリシー権限で起動されるかどうかは式によって決定されます。実行時に式をテストする際に、リソース・ポリシーがアプリケーション・ポリシー・ストアに存在している必要があります。
「OK」をクリックします。
セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルが更新されます。
概要エディタは、ファイルの<policy-store>
セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロールです。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。
例41-8は、従業員登録のタスク・フローとそのタスク・フローにアクセスするために使用するトップレベルWebページに対して、認証されていないユーザーにアクセス権を付与するjazn-data.xml
ファイルのセキュリティ・ポリシーを示しています。anonymous-role
アプリケーション・ロールに対する権限には、バインド・タスク・フローemp-reg-task-flow
のview権限と、indexPageDef
ページ定義を含むWebページのview権限が含まれます。この権限によって、認証されていないユーザーは従業員登録タスク・フローに入り、ようこそページを表示できるようになります。
Webページに関しては、ようこそページ(index.jsf
)に対して作成されたindexPageDef
ページ定義に権限が定義されていることに注意してください。また、これはバインド・タスク・フローによってまだ保護されていないトップレベルWebページであることにも注意してください。
例41-8 アプリケーションレベル・ポリシー・ストアの権限
<policy-store> ... <jazn-policy> <grant> <grantee> <principals> <principal> <name>anonymous-role</name> <class>oracle.security.jps.internal.core.principals. JpsAnonymousRoleImpl</class> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/flows/emp-reg-task-flow-definition.xml# #emp-reg-task-flow-definition</name> <actions>view</actions> </permission> <permission> <class>oracle.adf.share.security.authorization.RegionPermission</class> <name>oracle.summit.view.pageDefs.indexPageDef</name> <actions>view</actions> </permission> ... </permissions> </grant> ... </jazn-policy> </policy-store>
ADFリソースに作成する権限は、標準のJAAS権限です。アプリケーションでADFセキュリティを有効化すると、Oracle WebLogic Server上で実行されているOracle Platform Security Service (OPSS)は、この権限を使用して認可を実行します。認可モードでは、ADFセキュリティは、JAAS権限で実装され、ページへのアクセス権のセキュリティ・チェックを実行する、きめ細かい認可を使用します。ADFセキュリティ施行ロジックは、JAASサブジェクトによって表現されるユーザーが、リソースにアクセスする正しい権限を持っているかどうかを確認します。
サブジェクトには、ユーザーのプリンシパル(ログオン前は無名、ログオン後はユーザー名を含むユーザー・プリンシパル)とロール・プリンシパルのリスト(authenticated-role
、ポリシー・ストアやアイデンティティ・ストアから取得されるいくつかのロールなど)が含まれます。プリンシパルは、ポリシー・ストアに定義されているアプリケーション・ロールのすべてのユーザーのメンバーシップを表すために作成されます。また、各アプリケーション・ロールには複数の権限を関連付けておくことができます。これらは、jazn-data.xml
ファイルの概要エディタで作成されるADFセキュリティ・ポリシーです。
注意: ADFセキュリティ・ポリシーはアプリケーションごとにスコープ指定されます。このスコープで2つのアプリケーションは、意図しない結果を生じることなく、同じ権限ターゲットを参照します。ポリシー・ストア情報のアプリケーション・スコープを設定するためにアプリケーション・リソースを指定する必要はありません。 |
統合WebLogic Serverを使用してアプリケーションを実行する前に、テスト・ユーザーを含むアイデンティティ・ストアをプロビジョニングし、構成するアプリケーション・ロールにそれらのユーザーを追加する必要があります。41.6項「テスト・ユーザーの作成」で説明するように、アプリケーション・ロールでは、ユーザーまたはユーザー・グループ(エンタープライズ・ロール)に固有のメンバーを定義できます。
その後、実行時に、現在のユーザーがアクセスしようとしているページのview権限を持っているかどうかが、ページのコンテキストによって決まります。
ページがバインド・タスク・フローのアクティビティである場合は、タスク・フロー・コントローラによって権限が決まります。
ページが、ページ定義ファイルが関連付けられたトップレベル・ページである場合は、ADFモデルによって権限が決まります。
次に、Oracle Platform Security Servicesにより、ページにアクセスするために必要な権限を持つロールがサブジェクトに含まれるかどうかが確認されます。ユーザーが認可されると、タスク・フローが開始します。
バインド・タスク・フローとトップレベル・ページ(バインドなしタスク・フローで定義)の場合、ユーザーが認可されないと、ADFコントローラによって例外がスローされ、タスク・フロー構成で指定された例外ハンドラに制御が渡されます。他のエラー・ページの指定の詳細は、41.7.5項「認証後にユーザーをリダイレクトする方法」を参照してください。
「ADFセキュリティの構成」ウィザードのデフォルト・オプション「ADF認証および認可」では、認可チェックが有効になり、Webページが保護されます(WebページがADFセキュリティ対応リソースに関連付けられている場合)。したがって、ウィザードを実行した後で、次の両方の条件が存在するとWebページは保護されません。
ページにデータバインドADF Facesコンポーネントが表示されず、ページにADFページ定義が存在していない場合。
ページがデータバインドADFタスク・フローの構成ページでない場合。(ユーザーがバインド・タスク・フローのプロセスとしてアクセスするすべてのページは、タスク・フローの権限でチェックされます。)
「データ・コントロール」パネルを使用してWebページを設計し、データバインドされたADF Facesコンポーネントを作成するときには常に、JDeveloperによってADFページ定義ファイルが生成されます。ただし、WebページがADFバインディングを使用しない場合でも空のページ定義ファイルを作成できます。これには、ユーザー・インタフェース・プロジェクトのWebページを右クリックして、「ページ定義に移動」を選択します。このページ定義ファイルは空にしておくことができます。このページは、データバインドADF FacesコンポーネントをサポートするためにADFバインディングと連携する必要がないためです。
WebページとADFページ定義ファイル(空かどうかに関係なく)をいったん関連付けると、関連付けられたWebページにユーザーがアクセスするときに認可チェックが施行されます。他のADFページ定義と同様にページのセキュリティ・ポリシーを定義できます。空のADFページ定義に対する権限付与の詳細は、41.5.5項「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。
作業を始める前に、次のようにします。
個々のページの定義ファイルのセキュリティについて理解しておくと役立ちます。詳細は、41.5.5項「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。
JDeveloperがページ定義ファイルを生成する通常の方法について理解しておくことも役立ちます。詳細は、17.7項「ページ定義ファイルでの作業」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
セキュリティ・ポリシーを定義するために空のページ定義を作成するには:
「アプリケーション」ウィンドウで、保護するWebページを探し、ノードを右クリックして「ページ定義に移動」を選択します。
確認ダイアログで「はい」をクリックすると、ページの新しいページ定義が作成されます。
ページ定義はpageDefs
パッケージに追加されます。
一度に複数のリソースに適用する権限を定義する場合は、java.util.regex.Pattern
クラスによって定義されるパターンを作成して、実行時に評価される正規表現を生成します。たとえば、権限を一連のリソースに対応させるには、権限の名前に対して.*
(任意の文字0個以上を表す)という表現を入力できます。ADFセキュリティでは、他のセキュリティ・オブジェクト(プリンシパル名など)については正規表現を使用できません。
この機能を使用すると、例41-9に示すように、同じ権限を持つバインド・タスク・フローをグループ化してWEB-INF
の専用のサブフォルダに含め、そのフォルダ全体に権限を定義できます。この場合、ピリオド(任意の文字を表す)の後にアスタリスク修飾子(0回以上を表す)を付けた正規表現を使用します。
例41-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.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権限を付与すると同時に、正規表現で除外セットを定義して特定のページ定義を除くことができます。例41-10は、custom
で始まるページ定義名を除いたすべてのページに関してanonymous-role
にview権限を付与する方法を示しています。
例41-10 正規表現とメタ文字を使用したポリシー権限の定義
<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>
表41-7は、ポリシー定義で使用できる正規表現の基本的なメタ文字の一部を示しています。
データ・モデル・オブジェクトのADFエンティティ・オブジェクトはセキュリティ対応です。つまり、開発者が付与することのできるリソース固有の権限が事前定義されています。さらに、エンティティ・オブジェクトの個々の属性だけを保護することもできます。
セキュリティ保護の対象とするエンティティ・オブジェクトでは、UIコンポーネントがADFバインディングによってセキュアなエンティティ・オブジェクトのアクセス先データにバインドされている場合に、そのUIコンポーネントをレンダリングしているWebページに表示されるデータの、ユーザーによる更新が制限されます。さらに、エンティティ・オブジェクトをセキュリティ保護する際、そのエンティティ・オブジェクトに依存するデータ・モデル・プロジェクト内のビュー・オブジェクトも事実上保護します。そのため、セキュリティ保護するエンティティ・オブジェクトは、このビュー・オブジェクトにバインドされたUIコンポーネントに適用される、さらに広範なアクセス・ポリシーを定義します。
ADFエンティティ・オブジェクトを使用して行データを保護するには:
保護するエンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について、特定のアクションの権限マップを定義します。
ポリシー・ストアに追加したアプリケーション・ロールに権限を付与します。
データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクトによって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。
概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission
)によって定義されます。権限クラスは、エンティティ・オブジェクトでサポートされる操作をアクションにマップします。表41-8は、エンティティ・オブジェクトの、セキュア化できる操作を示しています。
表41-8 ADFエンティティ・オブジェクトのセキュア化可能な操作
セキュアな操作 | 想定されるマップされたアクション | 対応する実装 |
---|---|---|
|
|
|
|
|
バインドされたコレクションの属性を更新します。 |
|
|
バインドされたコレクションの1つの行を削除します。 |
エンティティ・オブジェクトがアクセスするすべての行レベル・データを保護するには、エンティティ・オブジェクト用の概要エディタを使用します。
作業を始める前に、次のようにします。
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、41.5.11項「データのポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
エンティティ・オブジェクトに対する操作をセキュア化する手順:
「アプリケーション」ウィンドウで、保護するエンティティ・オブジェクトをダブルクリックします。
概要エディタで、「一般」ナビゲーション・タブをクリックします。
「一般」ページで「セキュリティ」セクションを開き、エンティティ・オブジェクトについて保護する操作を選択します。
「セキュリティ」セクションに、EntityPermission
クラスで定義されている、保護できる操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表41-8に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。
たとえば、read権限を有効化するには、図41-11に示すように選択します。権限が、エンティティ・オブジェクトのXML定義に表示されます。
データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクト属性によって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。
概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission
)によって定義されます。権限クラスは、エンティティ・オブジェクト属性でサポートされる操作をアクションにマップします。表41-9は、エンティティ・オブジェクト属性の、保護可能な操作を示しています。
表41-9 ADFエンティティ・オブジェクト属性のセキュア化可能な操作
セキュアな操作 | 想定されるマップされたアクション | 対応する実装 |
---|---|---|
|
|
バインドされたコレクションの特定の属性を更新します。 |
エンティティ・オブジェクトがアクセスするデータの個々の列を保護するには、エンティティ・オブジェクト用の概要エディタの「属性」ページを使用します。
作業を始める前に、次のようにします。
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、41.5.11項「データのポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
エンティティ・オブジェクト属性に対する操作をセキュア化する手順:
「アプリケーション」ウィンドウで、保護する属性を定義するエンティティ・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
属性ページで保護する属性を選択し、「セキュリティ」タブをクリックして、update操作を選択します。
「セキュリティ」タブに、EntityAttributePermission
クラスで定義されるセキュア化可能な操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表41-9に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。
たとえば、update権限を有効化するには、図41-12に示すように選択します。権限マップが、エンティティ・オブジェクトのXML定義に表示されます。
権限ターゲットが構成されても、エンティティ・オブジェクトの権限ターゲットに対してポリシー権限が明示的に定義されるまで、エンティティ・オブジェクトあるいはその属性から導出されるデータは、セキュリティ保護されないままです。
既存のエンティティ・オブジェクトまたはエンティティ属性の権限ターゲットに対するアクセス・ポリシーを定義するには、セキュリティ・ポリシーの概要エディタを使用します。
作業を始める前に、次のようにします。
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、41.5.11項「データのポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
ADFセキュリティの構成ウィザードを実行します。41.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。41.4項「アプリケーション・ロールの作成」を参照してください。
41.5.11.1項「ADFエンティティ・オブジェクトに対する権限マップの定義」の説明に従って、エンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について権限ターゲットを定義します。
エンティティ・オブジェクトまたはエンティティ属性のアクセス・ポリシーを定義するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「ADFエンティティ・オブジェクト」または「ADFエンティティ・オブジェクト属性」を選択します。
概要エディタのリソース権限ページに、これまでに権限ターゲットを定義したすべてのエンティティ・オブジェクト(またはエンティティ属性)が表示されます。
「リソース」列で、アクセス権を付与するADFエンティティ・オブジェクトまたはエンティティ属性を選択します。
初めてADFエンティティ・オブジェクトまたはエンティティ属性に権限付与を行うとき、図41-13に示すように、先頭列のメソッド名の隣には「権限のないリソース」アイコン(ロック・アイコン)が表示されています。エディタに表示されるロック・アイコンは、リソースにセキュリティ・ポリシーが定義されていないためにロックされている(権限を定義するまでユーザーがアクセスできない)ことを示します。
「ロールに付与済」列で「権限受領者の追加」アイコンをクリックし、「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。41.5.3項「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、41.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列で、特定のアプリケーション・ロールに付与するアクションを選択します。
エンティティ・オブジェクトに対し、概要エディタではデフォルトでreadアクションが選択されています。表41-8に示すように、対応する権限ターゲットをすでに構成している場合は、updateアクションおよびdeleteアクションを選択できます。
エンティティ・オブジェクト属性に関しては、表41-9に示す権限ターゲットに対し、概要エディタではデフォルトでupdateアクションが選択されています。エンティティ・オブジェクト属性に対してサポートされる他のアクションはありません。
図41-14は、エンティティ・オブジェクトのアプリケーション・ロールApplication Employee Roleに付与されるdelete、read、update権限を示しています。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のADFエンティティ・オブジェクトまたはエンティティ属性に、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。41.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
リソース権限を作成することで、セキュア化できる個々のOracle ADFアーティファクトに対するエンド・ユーザーのアクセス権を定義します。しかし、管理とメンテナンスを容易にするため、リソース権限を資格付与として定義することもできます。こうすると、セキュア化可能な複数のアプリケーション・アーティファクトが1つの名前付きセキュリティ・グループとして集約され、これを1つの文によってアプリケーション・ロールに付与できます。たとえば、ADFビジネス・コンポーネント・エンティティ・オブジェクトによってアプリケーション内で公開されるデータへのアクセスを認可しようとする場合、複数のエンティティ・オブジェクトに対して同一のセキュリティ・ポリシーが必要になる可能性があります。各エンティティ・オブジェクトに対してアクセス権限を個別に付与するのではなく、これらの権限を1つの資格としてグループ化し、一括して付与できます。
セキュリティ・ポリシーの概要エディタの「資格付与」ページで、資格付与を作成します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、選択したリソース・インスタンスとアクションとのペアで構成される1つの資格(XML定義では<permission-set>
として識別されます)を定義します。この資格は付与可能なエンティティであり、アプリケーション・ロールに付与できます。
セキュリティ・ポリシーの概要エディタには、リソース・タイプのリストが表示されます。選択したリソース・タイプにより、アプリケーション・ワークスペースのプロジェクト内で定義されたリソース・インスタンスがフィルタ処理されます。また、選択したリソース・タイプにより、概要エディタに表示される使用可能なアクションのリストが決定されます。たとえば、リソース・タイプタスク・フロー権限を選択した場合、概要エディタには、選択したユーザー・インタフェース・プロジェクト内のすべてのタスク・フローが表示されます。また、viewアクションも表示され、これを使用可能なADFバインド・タスク・フロー・リソースに関連付けることができます。
表41-10は、JDeveloperで表示されるリソース・タイプのリストと、各タイプに対して関連付けられるリソースおよびサポートされるアクションを示します。
表41-10 セキュア化できるOracle ADFアーティファクトのリソース・タイプ
リソース・タイプ | サポートされるリソースおよびアクション |
---|---|
|
選択したユーザー・インタフェース・プロジェクト内のADFバインド・タスク・フローに対してviewアクションを定義します。 |
|
選択したユーザー・インタフェース・プロジェクト内のADFページ定義ファイルに基づくリージョンおよびWebページに対してviewアクションを定義します。 |
|
選択したデータ・モデル・オブジェクト内のエンティティ・オブジェクトに対してread、updateおよびdeleteアクションを定義します。 |
|
選択したデータ・モデル・オブジェクト内の特定のエンティティ・オブジェクトのエンティティ・オブジェクト属性に対してupdateアクションを定義します。 |
セキュア化できるOracle ADFアーティファクトに対して資格付与を定義するには、セキュリティ・ポリシーの概要エディタの「資格付与」ページを使用します。
始める前に:
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、41.5.12項「リソース権限を資格付与として集約する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
アプリケーション・ロールを作成します。41.4項「アプリケーション・ロールの作成」を参照してください。
Oracle ADFアーティファクトに対して資格付与を定義するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「資格付与」を選択します。
セキュリティ・ポリシー概要エディタの「資格付与」ページで、「資格」セクションの「資格の追加」アイコンをクリックします。
概要エディタに、アプリケーションで定義されるすべてのリソースが表示されます。
「資格付与」ページで、「リソース」タブをクリックして「メンバー・リソースの追加」アイコンをクリックし、メンバー・リソースを資格に追加します。
「リソースの選択」ダイアログで、「リソース・タイプ」ドロップダウン・リストからリソースを選択して、「ソース・プロジェクト」セクションで必要なプロジェクトを選択します。
ダイアログに、アプリケーション・ワークスペース内のすべてのプロジェクトが表示されます。
「使用可能なリソース」セクションで、リソースを選択して「追加」アイコンをクリックします。
ダイアログに、選択したプロジェクトによって定義されたすべてのリソースが表示されます。
「アクション」リストで、選択したリソースに対する目的のアクションを選択します。
図41-15に示す概要エディタでは、タスク・フローに対してViewアクションが選択され、資格に追加されています。
必要なその他のリソースをリストに追加します。
「資格付与」ページで、「付与」タブをクリックして、「ロール付与の追加」アイコンをクリックし、アプリケーション・ロールに資格を付与します。
「アプリケーション・ロールの選択」ダイアログで、1つ以上のカスタム・アプリケーション・ロールを選択します。
ダイアログに、jazn-data.xml
ファイル内のすべてのアプリケーション・ロールが表示されます。事前定義されたアプリケーション・ロール(Oracle Fusionアプリケーションの用語では職務ロールとも呼びます)に権限を追加しないでください。JDeveloperで自分で作成したカスタム・アプリケーション・ロール、またはこの目的でITセキュリティ・マネージャによって作成されたカスタム・アプリケーション・ロールのみを選択してください。
「OK」をクリックします。
これらの手順を繰り返して他のリソースを追加し、同一カスタム・アプリケーション・ロールの同一資格に対して、これらのリソースの権限を作成します。
JDeveloperのセキュリティ・ポリシー・エディタを使用して資格を作成すると、JDeveloperはjazn-data.xml
ファイル内で、アプリケーション・ポリシー・ストアのソースを修正します。ファイルのポリシー・ストア・セクションには、<resource-type>
定義(選択したリソース・タイプに対してサポートされるアクションを識別)、<resource>
定義(アプリケーションから選択してリソース・タイプにマッピングしたリソース・インスタンスを識別)、<permission-set>
定義(1つの資格として付与されるリソースおよびアクションを定義)、および<grant>
定義が含まれ、1つ以上の資格(XML内で権限セットとして定義)が目的のアプリケーション・ロール(権限受領者)に付与されます。
例41-11に示すように、Oracle Fusionアプリケーションにおける資格ベースのセキュリティ・ポリシーは、<jazn-policies>
要素内で定義され、単一のアプリケーション・ロールに付与される1つ以上の資格によって構成されます。
例41-11 jazn-data.xmlファイル内の資格ベース・ポリシー定義
<?xml version="1.0" ?> <jazn-data> <policy-store> <applications> <application> <name>MyApp</name> <app-roles> <app-role> <name>AppRole</name> <display-name>AppRole display name</display-name> <description>AppRole description</description> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> <class>oracle.security.jps.service.policystore.ApplicationRole</class> </app-role> </app-roles> <role-categories> <role-category> <name>MyAppRoleCategory</name> <display-name>MyAppRoleCategory display name</display-name> <description>MyAppRoleCategory description</description> </role-category> </role-categories> <!-- resource-specific OPSS permission class definition --> <resource-types> <resource-type> <name>APredefinedResourceType</name> <display-name>APredefinedResourceType display name</display-name> <description>APredefinedResourceType description</description> <provider-name>APredefinedResourceType provider</provider-name> <matcher-class>oracle.security.jps.ResourcePermission</matcher-class> <actions-delimiter>,</actions-delimiter> <actions>write,read</actions> </resource-type> </resource-types> <resources> <resource> <name>MyResource</name> <display-name>MyResource display name</display-name> <description>MyResource description</description> <type-name-ref>APredefinedResourceType</type-name-ref> </resource> </resources> <!-- entitlement definition --> <permission-sets> <permission-set> <name>MyEntitlement</name> <display-name>MyEntitlement display name</display-name> <description>MyEntitlement description</description> <member-resources> <member-resource> <type-name-ref>APredefinedResourceType</type-name-ref> <resource-name>MyResource</resource-name> <actions>write</actions> </member-resource> </member-resources> </permission-set> </permission-sets> <!-- Oracle function security policies --> <jazn-policy> <!-- function security policy is a grantee and permission set --> <grant> <!-- application role is the recipient of the privileges --> <grantee> <principals> <principal> <class> oracle.security.jps.service.policystore.ApplicationRole </class> <name>AppRole</name> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> </principal> </principals> </grantee> <!-- entitlement granted to an application role --> <permission-set-refs> <permission-set-ref> <name>MyEntitlement</name> </permission-set-ref> </permission-set-refs> </grant> </jazn-policy> </application> </applications> </policy-store> </jazn-data>
JDeveloperで提供されるエディタを使用して、アイデンティティ・ストアとポリシー・ストアの両方を作成できます。アプリケーション固有のjazn-data.xml
ファイルに両方のリポジトリを作成します。ファイルのアイデンティティ・ストア・セクション用のエディタでは、有効なユーザーIDと割り当てられたパスワードのリストを入力できます。同じエディタを使用して、アプリケーション・ロールを作成し、アプリケーション・ロールのメンバーとしてテスト・ユーザーまたはエンタープライズ・ロールを割り当てることができます。定義されると、この情報はjazn-data.xml
ファイルのポリシー・ストア・セクションに表示されます。
アプリケーションのアイデンティティ・ストアに一時的なユーザーのセットを生成して、本番環境での実際のユーザーの体験をシミュレートします。統合WebLogic Serverでアプリケーションを実行すると、任意のテスト・ユーザーとしてログインでき、アプリケーションのセキュアADFリソースを表示するアクセス権を与えられます。
アイデンティティ・ストアを使用すると、エンタープライズ・ロールにユーザーをグループ分けすることができます。通常は、JDeveloperのデプロイメント・オプションを構成して、アイデンティティ・ストアをステージング環境に移行しないようにするため、jazn-data.xml
ファイルに作成するエンタープライズ・ロールは便宜上のものです。エンタープライズ・ロールの使用方法の詳細は、41.4.3項「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。
注意: アイデンティティ・ストアのスタンドアロン・サーバーへのデプロイを選択する場合、Oracle WebLogic Serverに対してすでに構成されているローカル・アイデンティティ・ストアにユーザーとエンタープライズ・ロールを作成しないでください。たとえば、ユーザー |
ユーザーがリソースを表示できるようにするには、そうしたロールのメンバーであるユーザーではなく、アプリケーション・ロールに対して権限を付与します。したがって、アイデンティティ・ストアにテスト・ユーザーを生成した後で、各ユーザーまたはエンタープライズ・ロール・グループをアプリケーション・ロールに関連付ける必要があります。この関連付けにより、ADFセキュリティ・ポリシーによって定義されたアクセス権がユーザーに付与されます。アクセス権のユーザーへの付与の詳細は、41.6.3項「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」を参照してください。
始める前に:
アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、41.6項「テスト・ユーザーの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
テスト・ユーザーおよびグループを作成するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「ユーザー」を選択します。
セキュリティ・ポリシーの概要エディタの「ユーザー」ページで、「レルム」ドロップダウン・リストからアプリケーションのレルムを選択して、次の手順を実行します。
JDeveloperでは、レルムjazn.com
がデフォルトで使用されます。
「ユーザー」リストで「新規ユーザー」アイコンをクリックします。
「名前」フィールドにユーザー名を入力します。
Oracle WebLogic Serverに対してすでに構成されているユーザー名を選択しないでください(たとえば、webcenter
は入力しないでください)。Oracle WebLogic Serverによりインストールされているユーザー名のリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・グループ」の章を参照してください。
「パスワード」フィールドにユーザーのパスワードを入力します。他の任意のフィールドをクリックすると、パスワードがアイデンティティ・ストアに追加されます。
パスワードは8文字以上で指定し、特殊文字(!、%、^、&、$など)を少なくとも1つ含める必要があります。
必要に応じて、概要エディタで、「エンタープライズ・ロール」ナビゲーション・タブをクリックし、アプリケーションのレルムを「レルム」ドロップダウン・リストから選択して、次の手順を実行します。
ユーザーをグループ分けしてアプリケーション・ロールに追加する場合のみ、エンタープライズ・ロールを作成します。統合WebLogic Serverを使用してアプリケーションを実行するためのテスト・ユーザーを作成する目的であれば、エンタープライズ・ロール・グループを作成する必要はありません。
「エンタープライズ・ロール」リストで「新規ロール」アイコンをクリックします。
「名前」フィールドにエンタープライズ・ロール名を入力します。他のいずれかのフィールドをクリックすると、ロールがアイデンティティ・ストアに追加されます。
エンタープライズ・ロール・グループを作成する場合、Oracle WebLogic Serverに対してすでに構成されているロール名を選択しないでください(たとえば、Administrators
は入力しないでください)。Oracle WebLogic Serverによりインストールされているデフォルト・グループ名のリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・グループ」の章を参照してください。
ユーザー・アイデンティティとエンタープライズ・ロール・グループを含むアイデンティティ・ストアをプロビジョニングすると、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。
ダイアログによって、アイデンティティ・ストアに対応するファイルの<jazn-realm>
セクションにユーザー情報が書き込まれます。各ユーザー・アイデンティティには、ユーザー名とユーザー・ログイン・パスワードが含まれます。各エンタープライズ・ロールには1つ以上のメンバー・ユーザーが含まれます。
例41-12に、2つのユーザーと2つのエンタープライズ・ロールを含むjazn-data.xml
ファイルのアイデンティティ・ストアを示します。ユーザーcmagee
はEnterprise Employee Group
エンタープライズ・ロールのメンバーで、ユーザー214
はEnterprise Customer Group
エンタープライズ・ロールのメンバーです。
例41-12 アプリケーションレベル・アイデンティティ・ストアのユーザーとエンタープライズ・ロール
<jazn-data> <jazn-realm default="jazn.com"> <realm> <name>jazn.com</name> <users> <user> <name>cmagee</name> <display-name>Colin Magee</display-name> <description>Sales Rep</description> <credentials>{903}5AUHlE+qvDxxAhxIMoXJ/WLhMF0ynue7</credentials> </user> <user> <name>214</name> <display-name>Ojibway Retail</display-name> <description>Customer</description> <credentials>{903}rijN2KQCBSeBQ/JNZlv8GwwUiGWk5IQa</credentials> </user> ... </users> <roles> <role> <name>Enterprise Employee Group</name> <members> <member> <type>user</type> <name>cmagee</name> </member> </members> </role> <role> <name>Enterprise Customer Group</name> <members> <member> <type>user</type> <name>214</name> </member> ... </members> </role> ... </roles> </realm> ... </jazn-realm> </jazn-data>
ADFセキュリティ・フレームワークは、アプリケーション・ロールに付与された権限を使用するロールベースのアクセス制御メカニズムを施行するため、アプリケーション固有の一連のロールをポリシー・ストアに定義します。たとえば、ワークフローのコンテキストでは、顧客、製品担当、監督者、管理者などのロールを想定できます。
アプリケーション・ロールを作成したら、アイデンティティ・ストアに作成したユーザーに1つ以上のロールを関連付けることができます。アプリケーション・ロールのメンバーであるユーザーには、実行時にアプリケーション・ロールのアクセス権が付与されます。複数のリソース権限を特定のユーザーに付与する場合は、1ユーザーを複数のアプリケーション・ロールに割り当てることができます。
たとえば、認証された1ユーザーがスーパーバイザ・ロールと従業員ロールに所属し、別の1ユーザーは従業員ロールのみに所属する場合があります。顧客レコードのブラウズと編集を許可するバインド・タスク・フローのセキュリティ・ポリシーでは、スーパーバイザ・ロールにview権限が与えられますが、従業員ロールにはブラウズ・ページのview権限に制限されます。このように、アプリケーション・ロールへの権限付与により複数レベルのアクセスに対応します。認証されたユーザーが、ターゲットADFリソースのview権限を持つアプリケーション・ロールのメンバーでない場合は、ユーザーが認証されていないというメッセージがセキュリティ・フレームワークによって返されます。
始める前に:
アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、41.6項「テスト・ユーザーの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
ADFセキュリティの構成ウィザードを実行します。41.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。41.4項「アプリケーション・ロールの作成」を参照してください。
ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義します。41.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
テスト・ユーザーを作成し、必要に応じてエンタープライズ・ロール・グループを作成します。41.6.1項「JDeveloperでテスト・ユーザーを作成する方法」を参照してください。
ユーザーをアプリケーション・ロールに関連付けるには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。
セキュリティ・ポリシーの概要エディタの「アプリケーション・ロール」ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。
JDeveloperによってjazn-data.xml
ファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。
「ロール」リストで既存のアプリケーション・ロールを選択し、必要に応じて次のタスクを実行します。
「マッピング」セクションで、「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「ユーザーの追加」を選択します。次に、「ユーザーの選択」ダイアログで、前に作成したユーザーをリストから選択して「OK」をクリックします。
アイデンティティ・ストアにエンタープライズ・ロールを定義している場合、必要であれば、「マッピング」セクションで「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「エンタープライズ・ロールの追加」を選択します。次に、「エンタープライズ・ロールの選択」ダイアログで、前に作成したエンタープライズ・ロールをリストから選択して「OK」をクリックします。
ユーザーにアプリケーション・ロールを関連付けると、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。
ダイアログによって、ファイルの<policy-store>
セクションにユーザー情報が書き込まれます。各アプリケーション・ロールには1つ以上のメンバー・ユーザーまたはエンタープライズ・ロールが含まれます。
例41-13は、Application Employee Role
アプリケーション・ロールを持つjazn-data.xml
ファイル内のポリシー・ストアを示しています。ここには、Enterprise Employee Group
とEnterprise Manager Group
という2つのメンバーが含まれています。
例41-13 アプリケーションレベル・ポリシー・ストアでのユーザーとアプリケーション・ロールの関連付け
<policy-store> <applications> <application> <name>SummitADF</name> <app-roles> <app-role> <name>Application Employee Role</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <display-name>Application Employee Role</display-name> <members> <member> <class>oracle.security.jps.internal.core.principals. JpsXmlEnterpriseRoleImpl</class> <name>Enterprise Employee Group</name> </member> <member> <class>oracle.security.jps.internal.core.principals. JpsXmlEnterpriseRoleImpl</class> <name>Enterprise Manager Group</name> </member> ... </members> </app-role> ... </app-roles> <jazn-policy> ... </jazn-policy> </application> </applictions> </policy-store>
ADFセキュリティでは、暗黙的認証および明示的認証を使用できます。
暗黙的な認証のシナリオでは、未認証のユーザーがアクセスしようとするWebページが、anonymous-role
に権限付与されていないADFセキュリティ対応リソースに関連付けられている場合、認証が動的にトリガーされます。ユーザーが正常にログインすると、認証されたユーザーが、リクエストしたページのADFセキュリティ対応リソースに対するviewアクセス権を付与されているかどうかを検証するために別のチェックが実行されます。
明示的な認証のシナリオでは、ログイン・リンクが表示された公開ページがアプリケーションに用意され、このリンクをクリックすると、そのユーザーのログインにおいて認証チャレンジがトリガー実行されます。ログイン・リンクには、認証が成功した後に表示するいくつかの他のターゲット・ページ(認証済ユーザーがアクセス権を持っている場合)を指定できます。
41.3.5項「ADF認証に関する必知事項」で説明しているように、暗黙的な認証および明示的な認証シナリオは、ADFセキュリティの構成ウィザードの実行時にデフォルトで処理されます。ただし、デフォルトで生成されるログイン・ページ(または独自に提供したページ)をADF Facesコンポーネントを使用するようにカスタマイズした場合は、コンテナ管理のデプロイメント記述子(web.xml
ファイル)を構成する必要があります。
ユーザー認証を明示的に処理するには:
ログイン・リンク・コンポーネントを作成し、アプリケーションのパブリック・ホームページに追加します。
Servlet 3.0固有のAPIを使用して、ユーザーによるログインの試行を処理するマネージドBeanを作成します。
ADF Facesコンポーネントを使用して、JSFログイン・ページを作成します。
ログイン・ページのリソースがアクセス可能であることを確認します。
暗黙的な認証と明示的な認証の詳細は、41.8.4項「実行時に行われる処理: ADFセキュリティによる認証の処理」を参照してください。
アプリケーションのどのページにも追加できる標準的なログイン・リンク・コンポーネントを作成して、ユーザーの認証または以降のログオフができます。このコンポーネントは、ユーザーの認証状態を追跡し、適切なログインまたはログアウトのURLおよびアイコンを戻します。このログイン・リンク・コンポーネントは、ユーザーの認証後、ユーザーを特定のページにリダイレクトします。したがって、このログイン・リンク・コンポーネントを使用すると、一貫性のある単一のオブジェクトを得られます。
認証されていないユーザーに対しては、ログイン・リンク・コンポーネントは図41-16のように表示されます。
その後、ユーザーがログイン・リンクをクリックして、適切な資格証明を持つユーザーとしてログインすると、コンポーネントは図41-17のようになります。
始める前に:
ADF認証について理解しておくと役立ちます。詳細は、41.7項「ログイン・ページの作成」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
public_html
ディレクトリにコピーします。
注意: アプリケーションでスキンを使用する場合は、使用されるイメージは適切なスキン・イメージを参照している必要があります。スキンの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」の章を参照してください。 |
ログイン・リンク・コンポーネントを作成してページに追加するには:
「アプリケーション」ウィンドウで、コンポーネントを表示するWebページをダブルクリックします。
「コンポーネント」ウィンドウの「ADF Faces」ページで、「共通コンポーネント」パネルからリンクをドラッグして、このページにドロップします。
「構造」ウィンドウで「af:link」を右クリックし、「プロパティに移動」を選択します。
「プロパティ」ウィンドウで、「リンク」コンポーネントのラベルを指定して、「テキスト」フィールドに条件式言語(EL)式を入力します。
たとえば、次のようなEL式を入力して、リンク・テキストを条件付きでレンダリングできます。
#{securityContext.authenticated ? "Click to log out" : "Click to log in"}
現在のユーザーが認証されると、securityContext
Beanのauthenticated
プロパティがtrueに評価され、ログアウト・オプションがレンダリングされます。それ以外の場合はログイン・オプションのリンクがレンダリングされます。
「プロパティ」ウィンドウで、「リンク」コンポーネントのURLを指定して、「宛先」フィールドにEL式を入力します。
たとえば、次のEL式はユーザーが認証済かどうかに応じて、ユーザーを転送するURLを条件付きでレンダリングします。
#{securityContext.authenticated ? "/adfAuthentication?logout=true&end_url=/faces/welcome" : "/adfAuthentication?success_url=/faces/welcome"}
ユーザーがリンクをクリックすると、URLパラメータend_url
およびsuccess_url
がターゲット・ページの宛先をADF認証サーブレットに転送します。Webページ名のかわりにビュー・アクティビティ名がURLパラメータで渡されます。これにより、ログイン後のページ・ナビゲーションで制御フロー・ルールが施行されます。現在のユーザーが認証されると、securityContext
Beanのauthenticated
プロパティがtrueに評価され、ようこそページに転送されます。ユーザーが認証されない場合、ログイン・ページに転送する必要はありません。ADF認証サーブレットでトリガーされるログインは、コンテナ管理セキュリティ構成によって処理されるためです。ログアウトは、セッションを無効にするADF認証サーブレットによって処理されることに注意してください。
「リンク」コンポーネントのリンク・コンポーネント・イメージを指定するには、「プロパティ」ウィンドウで、「アイコン」フィールドにEL式を入力します。
たとえば、次のEL式は条件に応じて、ユーザーが認証されない場合にリンク・コンポーネント・イメージをロックのGIFとしてレンダリングします。それ以外の場合は、キーのGIFでイメージをレンダリングします。
#{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}
図41-18に、ログイン・リンク・コンポーネントをグローバル・メニュー・ファセットに追加するとどのように表示されるかを示します。
ADFセキュリティの構成ウィザードを実行して生成されるデフォルトのログイン・フォームは、JDeveloperでアプリケーションをテストする際に利用できるように提供されます。デフォルトのフォームでは、アプリケーションのユーザー・インタフェースに合せて、ADF Facesコンポーネントを使用してページをカスタマイズすることはできません。図41-19に示すように、カスタマイズ可能なコンポーネントを組み込めるADF Facesベースのログイン・ページによって、デフォルトのフォームを置き換えることができます。
ただし、ADF Facesコンポーネントを含むログイン・ページの設計が要件でない場合は、単純なJSPまたはHTMLのログイン・ページを使用することもできます。ADFセキュリティの構成ウィザードの実行時に単純なログイン・ページを生成する方法の詳細は、41.3.1項「ADFセキュリティを有効化する方法」を参照してください。
ADF Facesページとしてログイン・ページを作成する前に、ログインの試行を処理するマネージドBeanを作成する必要があります。このログインBeanの例では、Servlet 3.0固有のAPIを使用し、プログラムによって認証が処理されます。ログインBeanは、doLogin()
メソッドによって、ログイン・リンクから開始されたログイン・アクションを処理します。ログインが成功すると、このメソッドはADF認証サーブレットを起動してランディング・ページにリダイレクトします。このBeanをadfc-config.xml
ファイルに追加し、request
スコープで登録します。
注意: この項で説明するこのバッキングBeanの例では、Oracle Single Sign-On (OSS)による認証は行われません。このバッキングBeanは、Servlet 3.0によって提供されるログインおよびログアウト・メソッドを使用して認証を処理しています。Servlet 3.0は、Java EE 6以降をサポートするアプリケーション・サーバー上のプログラムによるログインを汎用的にサポートしています。 |
作業を始める前に、次のようにします。
ログイン・ページの知識があると役立ちます。詳細は、41.7.2項「明示的な認証用のログイン・ページを作成する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
ログインのためのバッキングBeanを作成して登録する手順:
「アプリケーション」ウィンドウで、バッキングBeanを作成するプロジェクトを右クリックし、「新規」、「ギャラリから」の順にクリックします。
「新規ギャラリ」で「一般」を開き、「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; }
次のクラスをインポートします。
javax.faces.application.FacesMessage javax.faces.context.ExternalContext javax.faces.context.FacesContext javax.servlet.ServletException javax.servlet.http.HttpServletRequest javax.servlet.http.HttpSession
doLogin()
メソッドをこのJavaクラスに追加して、ユーザーのログイン試行を処理します。
1 public String doLogin() { 2 FacesContext ctx = FacesContext.getCurrentInstance(); 3 if (_username == null || _password == null) { 4 showError("Invalid credentials", 5 "An incorrect username or password was specified.", null); 6 } else { 7 ExternalContext ectx = ctx.getExternalContext(); 8 HttpServletRequest request = (HttpServletRequest) 9 ctx.getExternalContext().getRequest(); 10 try { 11 request.login(_username, _password); // Servlet 3.0 login 12 _username = null; 13 _password = null; 14 String loginUrl = ectx.getRequestContextPath() + 15 "/adfAuthentication?success_url=/faces/welcome"; 16 redirect(loginUrl); 17 } catch (ServletException fle) { 18 showError("ServletException", "Login failed. 19 Please verify the username and password and try again.", null); 20 } 21 } 22 return null; 23 }
doLogin()
メソッドは、次のタスクを実行します。
行2および行6-9は、ExternalContext
からのHTTPリクエストをカプセル化するオブジェクトを取得します。
行3-5は、資格証明が指定されていない場合のエラーを処理します。showError()
メソッドは、ログイン・プロセスに関する多様な問題を処理するために実装するメソッドです。
行11-13は、Servlet 3.0 API login()
メソッドを使用して、リクエストを発行するユーザーのログインを試行します。このプログラムによるログイン例は、Servlet APIに依存しており、Oracle Single Sign-On (Oracle SSO)はサポートされていません。
行14-15は、ADF認証サーブレットを使用したログインの成功後にリダイレクトを実行するために、ユーザーを転送する先のURLを指定します。
行16はメソッドredirect()
をコールします。このメソッドは、行14で指定されたURLにユーザーを転送するためにこの項で後から実装します。
行17-20はServletException
を処理します。これは、ログインにかかわる多様な問題によってスローされます。たとえば、資格証明が正しくない場合、ロックされたアカウントにログインを試行した場合、または期限切れパスワードを使用した場合に例外が生成されます。showError()
メソッドは、ログイン・プロセスに関する多様な問題を処理するために実装するメソッドです。
行22はnullを返して、ADFコントローラが制御フロー・ケースを試行しないようにします。
メソッドredirect()
およびshowError()
のスタブを作成します。
アクションを含むredirect()
メソッドを追加します。
1 private void redirect(String forwardUrl) { 2 FacesContext ctx = FacesContext.getCurrentInstance(); 3 ExternalContext ectx = ctx.getExternalContext(); 4 try { 5 ectx.redirect(forwardUrl); 6 } catch (IOException ie) { 7 showError("IOException", "An error occurred during redirecting. 8 Please consult logs for more information.", ie); 9 } 10 }
redirect()
メソッドは、次のタスクを実行します。
行2はADF Faces ctx
を取得します。これはレスポンスを特定のURIに転送します。
行3-5はctx
を使用して現在のHTTPレスポンスをURLにリダイレクトします。
行6 - 8はIOException
を処理します。これがスローされるのは、リクエストを読み取ることができないとき、またはレスポンスを書き込むことができないときです。
showError()
メソッドを実装します。
private void showError(String errType, String message, Exception e){ FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, errType, message); FacesContext.getCurrentInstance().addMessage("d2:it35", msg); if (e != null) { e.printStackTrace(); } }
このshowError()
メソッドは、サマリー・エラー・メッセージをFacesContext
に追加し、例外のフル・スタック・トレースをコンソールに出力します。
必要に応じて、タスク・フローのメソッド・コール・アクティビティからプログラムによるログアウトをトリガーする場合は、logoff()
メソッドのスタブを作成し、次のように実装します。
public String logoff() { FacesContext ctx = FacesContext.getCurrentInstance(); ExternalContext ectx = ctx.getExternalContext(); HttpServletRequest httpRequest = (HttpServletRequest) ectx.getRequest(); try { httpRequest.logout(); // Servlet 3.0 logout HttpSession session = httpRequest.getSession(false); if (session != null) { session.invalidate(); } String logoutUrl = ectx.getRequestContextPath() + "/faces" + ctx.getViewRoot().getViewId(); redirect(logoutUrl); } catch (ServletException e) { showError("ServletException", "An error occurred during logout. Please consult logs for more information.", e); } return null; }
このlogoff()
メソッドは、Servlet 3.0 APIのlogout()
メソッドを使用してログオフ・アクションを処理します。これは、ログアウト・リンクおよびADF認証サーブレットのかわりとして、現在のHTTPレスポンスをURLにリダイレクトします。プログラムを使用しないログアウトの処理の詳細は、41.7.4.2項「ログイン・リンクおよびログアウト・リンクの追加」を参照してください。
Javaファイルを保存します。
「アプリケーション」ウィンドウで、WEB-INFを開き、adfc-config.xmlをダブルクリックします。
エディタ・ウィンドウで、「概要」タブをクリックします。
概要エディタで、「マネージドBean」ナビゲーション・タブをクリックします。
マネージドBeanページの「マネージドBean」セクションで、「追加」アイコンをクリックして、Bean名と完全修飾クラス名を入力し、スコープrequestを選択します。
たとえば、クラス名は図41-20のoracle.summit.bean.LoginBean
のようになります。
すべてを保存します。
ADF Facesレイアウト・コンポーネントおよびADF Facesユーザー・インタフェース・コンポーネントを利用する単純なログイン・ページには、2つの入力フィールドと1つのボタンが含まれます。これらのUIコンポーネントのプロパティを、ログイン・ページのマネージドBeanに定義したログイン・ハンドラ・メソッドにバインドする必要があります。
この手順で作成できるページでは暗黙的な認証はサポートされないことに注意してください。暗黙的な認証を実装する場合には、コンテナ管理の認証をサポートする、デフォルトのウィザードにより生成されたログイン・フォームをカスタマイズできます。Java EEコンテナでは、ユーザーにより送信されたj_username
およびj_password
入力を処理するためにj_security_check
メカニズムに依存するフォームを使用します。ここで説明する明示的な認証シナリオでは、Java EEコンテナ管理の認証は使用しません。
作業を始める前に、次のようにします。
明示的認証について理解しておくと役立ちます。詳細は、41.7.2項「明示的な認証用のログイン・ページを作成する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
明示的な認証用のADF Facesベースのログイン・ページを作成するには:
「アプリケーション」ウィンドウで、ログイン・ページを作成するプロジェクトを右クリックし、「新規」、「新規ギャラリ」の順にクリックします。
「新規ギャラリ」で「Web層」を開き、「JSF」、「ページ」の順に選択し、「OK」をクリックします。
「JSFページの作成」ダイアログで、「JSP XML」を選択します。
「ファイル名」フィールドで、ログイン・ページの名前を指定します。たとえば、LoginPage.jspx
を入力します。
他のオプションは選択しません。また、マネージドBeanでUIコンポーネントを公開するオプションは選択しないでください。ログイン・ページのために作成したマネージドBeanにコンポーネントを手動でバインドします。
「OK」をクリックします。
ページを保存します。
「コンポーネント」ウィンドウの「ADF Faces」ページで、「レイアウト」パネルから「パネル・ボックス」をドラッグし、「構造」ウィンドウの「af:form」ノードの下にドロップします。
「プロパティ」ウィンドウで、「テキスト」、「水平」、「幅」、「高さ」フィールドに値を入力します。
たとえば、基本的なログイン・ページを作成するには、次のように入力します。
「テキスト」にLogin Information
を設定します。
「アイコン」に/images/key_ena.png
を設定します。
「幅」および「高さ」に300
および200
ピクセルを設定します。
「コンポーネント」ウィンドウから「パネル・フォーム・レイアウト」をドラッグして、「構造」ウィンドウの「af:panelBox」ノードの下にドロップします(図41-21)。
「共通コンポーネント」ウィンドウから、ユーザー名フィールド用に「入力テキスト」を「パネル・フォーム・レイアウト」ノードにドラッグし、パスワード・フィールド用にもう1つの「入力テキスト」をドラッグします。
入力フィールドの「プロパティ」ウィンドウで、「ラベル」フィールドにUsername
とPassword
を入力し、「動作」セクションを開き、両方のフィールドの「必須」ドロップダウン・リストから「true」を選択します。
「プロパティ」ウィンドウで、パスワード・フィールド用に、「外観」セクションを開き、「機密」ドロップダウン・リストから「true」を選択します。
2つの入力フィールドの値を処理するために、各フィールドで次の手順を実行します。
「構造」ウィンドウで、入力フィールドの1つを選択し(たとえば「af:inputText - Username」ノードを選択)、「プロパティ」ウィンドウで「値」フィールドの横にある「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、Beanのハンドラ・メソッドに対応する式の値を選択します。
たとえば、構造ウィンドウでusername入力フィールドを選択した場合は、図41-22のように「式ビルダー」ダイアログでusernameを選択します。
「OK」をクリックします。
「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにフィールドがバインドされます。たとえば、username入力フィールドの場合、式は#{loginPageBean.username}
のようになります(図41-23)。
「コンポーネント」ウィンドウで、「レイアウト」パネルから「パネル枠線レイアウト」をドラッグして、af:panelBoxノードのfooterノードの内側にドロップします(図41-24)。
JSP/HTMLビジュアル・エディタで、ラベルが「端」、「上」および「下」のパネル枠線レイアウト・ファセットを削除します。「開始」ファセットのみを残します。
「構造」ウィンドウで、「パネル枠線レイアウト」ファセットを開いて、「開始」ノードを選択し、「コンポーネント」ウィンドウから「ボタン」をドラッグ・アンド・ドロップします。
「プロパティ」ウィンドウで、ボタン・コンポーネントの「テキスト」フィールドにLogin
を入力します。
ログイン・ボタンのアクションを処理するには、次の手順を実行します。
「構造」ウィンドウで「開始」ノードにある「af:button」を選択し、「プロパティ」ウィンドウで「アクション」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、ログイン・メソッドに対応する式の値を選択します。
たとえば、ログインBeanにdoLogin()
という名前のメソッドを作成した場合は、「式ビルダー」ダイアログでdoLoginを選択します。
「OK」をクリックします。
「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにボタンがバインドされます。たとえば、ログイン・ボタンの場合、式は#{loginPageBean.doLogin}
のようになります(図41-25)。
ページを保存します。
アプリケーションはADFセキュリティによって保護されるため、デフォルトでは、バインド・タスク・フローに定義されたすべてのWebページ、およびADFページ定義によって定義されたすべてのWebページにはアクセスできません。すべてのユーザーがログオンできるようにする必要があるため、ログイン・ページは公開する必要があります。このため、ログイン・ページにはデータバインド・コンポーネントを追加しないでください。ログイン・ページでデータバインド・コンポーネントが使用されないかぎり、このページにはデフォルトでアクセスできます。
コンテナがページ(この場合は認証ページ)へのアクセスを許可する前に、定義済の認証ポイントに常にリダイレクトすることを保証するには、これ以上の手順は必要ありません。
ADFセキュリティの構成ウィザードを実行して、「ADF認証」オプションを選択したとき(ADF認可を有効にしない)、アプリケーションがカスタム・ログイン・ページまたはカスタム・エラー・ページを使用していると、場合によってはADFセキュリティでweb.xml
ファイルに追加されたデフォルトのJava EEセキュリティ制約を編集する必要があります。例41-14に示すように、allPages
セキュリティ制約に定義されるデフォルトのURLパターン(/*
)は、Java EEアプリケーション・ルート以下すべてに対応します。つまり、ログイン・ページに使用される各リソース・ファイル(イメージ、スタイル・シート、JavaScriptライブラリなど)もこれに含まれます。
例41-14 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
)によってすべてのリソース・ファイルが除外されます。
Webアプリケーションは通常は保護されているため、認証されていないユーザーのための開始地点すなわちホームページが必要になります。このようなパブリックなようこそページを作成するには、アプリケーション内の他のページへのリンクを含み、アプリケーションの開始地点として機能するADF Facesページを作成します。ただし、認証されていないユーザーに対してはパブリック・ページへのリンクしかレンダリングできません。反対に、セキュア・ページへのリンクをレンダリングするのは、ユーザーがログインし、ターゲット・ページを表示する適切な権限を持っている場合のみです。
ベスト・プラクティス: ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して、新しいブラウザ・ウィンドウまたはタブを開いたとき、アプリケーションの |
標準のADF Facesページを作成すると、ページはデフォルトでパブリックになり、認証されていないユーザーがアクセスできます。ただし、ようこそページをADFリソースに関連付けた場合(「データ・コントロール」パネルを使用してデータバインドADF Facesコンポーネントをようこそページにドラッグ・アンド・ドロップするなど)、ADFセキュリティによってデフォルトでページが保護されます。セキュリティ・ポリシーの概要エディタを使用して、提供されているanonymous-role
にADFリソースのview権限を付与すると、任意のADFリソースを公開できます。anonymous-role
の詳細は、41.5.2項「ADFリソースの公開時の処理」を参照してください。
ログイン・リンクやログアウト・リンクをパブリックのようこそページに追加して、ログインやアプリケーション使用中のログアウトをユーザーが明示的に行えるようにします。Java EEコンテナ管理セキュリティでは、保護されているリソースにアクセスする際に認証の概念がサポートされますが、ログアウトした後も保護されたアプリケーションにとどまる標準の方法はありません。ただし、一般的なWebアプリケーションの場合、ページがパブリックであれば、ユーザーは同じページにとどまります。あるいは、ページが保護されている場合はようこそページが再び表示されます。各ページにログイン・リンクとログアウト・リンクを追加すると、ユーザーがアプリケーション内の任意の場所でログイン・セッションを終了できます(ようこそページに戻る)。また、ようこそページにこれらのリンクがあると、ユーザーがアプリケーションを開始するときに明示的に認証されます。
たとえば、3つのコンポーネント(出力テキスト領域、イメージ、リンク)を含むADF Facesパネル・グループを作成できます。適切なログイン・リンクまたはログアウト・リンクをレンダリングするために、ユーザーの認証ステータスを評価するEL式を使用できます。特に、securityContext.authenticated
を使用すると、例41-15に示すようにADFセキュリティ・コンテキストにアクセスできます。この式はtrue
またはfalse
として評価され、この例では、結果によって、表示するログイン・イメージまたはログアウト・イメージとリンクが決まります。例41-15に示すように、ADF認証サーブレットのsuccess_url
およびend_url
パラメータは、ターゲット・ページwelcome.jspx
と関連付けられたビュー・アクティビティwelcome
として渡されます。URLパラメータに対するWebページ名ではなく、ビュー・アクティビティ名を渡すことで、Fusion Webアプリケーションではページ・ナビゲーションの処理にタスク・フローの制御フロー・ルールが使用されるようになります。
例41-15 ログイン/ログアウト・リンクをレンダリングする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:link text="#{securityContext.authenticated ? "Logout" : "Login"}" destination="#{securityContext.authenticated ? "/adfAuthentication?logout=true&end_url=/faces/welcome" : "/adfAuthentication?success_url=/faces/welcome"}" 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>
ページ内にリンクを直接レンダリングするかわりに、41.7.1項「明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法」で説明するように、ログイン・リンクとログアウト・リンクを含むログイン・リンク・コンポーネントを作成して、ページ・テンプレートに追加できます。
セキュリティ保護されたページに無名ユーザーがアクセスできないように、ようこそページ上のセキュリティ保護されたページをポイントするナビゲーション・コンポーネントを、次の2つの基準に基づいてビューから非表示にする必要があります。
ユーザーが既知のユーザー・アイデンティティで認証されているか
指定されたユーザー・アイデンティティがターゲットの表示権限を持っているか
これらの条件の一方が満たされない場合、パブリック・ページ上でセキュリティ保護されたリソースをポイントするすべてのナビゲーション・コンポーネントは、そのrendered
属性をfalse
に設定して、無名ユーザーに対して非表示にする必要があります。ようこそページでこのような規則を施行するには、41.11.1「ADFセキュリティでの式言語(EL)の使用」を参照してください。
暗黙的な認証を実装することを選択した場合は、ユーザーが保護されたWebページにアクセスしてログインした後、ADF認証サーブレットは、ログイン・リクエストが発行された最初のページにユーザーをリダイレクトします。ADFセキュリティ認証が有効な場合、ADF認証サーブレットは、URLに対するADF認証のsuccess_url
パラメータとして元のページを自動的に渡します。通常、これは必要な動作です。ただし、ページ内に明示的なログイン・リンクを表示する場合は、一般的にターゲットの宛先は保護されたページになります。認証後、保護されたページへのリダイレクトがADF認証サーブレットによって確実に行われるように、例41-16に示すように、Webページのビュー・アクティビティ名をサーブレットのsuccess_url
パラメータとして渡します。
例41-16 success_urlを含むWebページの明示的なログイン・リンク
<af:link text="Login" destination="/adfAuthentication?success_url=/faces/viewactivityname"/>
ベスト・プラクティス: Fusion WebアプリケーションがADF認証リダイレクトをADFコントローラのナビゲーション・イベントとして処理するようにするには、リダイレクト・ターゲットをビュー・アクティビティ名で指定します。かわりにWebページ名を指定した場合、ユーザーのログイン後、ADFコントローラ・ハンドラがターゲット・ページに関連付けられた制御フロー・ルールを特定できなくなる可能性があります。リダイレクト・ターゲットとしてビュー・アクティビティを指定しない場合、特に |
さらに、元のページにリダイレクトできないケースを処理するために、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つのブラウズ・ページを含むバインドなしタスク・フローを定義した場合、例41-17に示すようにアプリケーションのエラー・ページ(adfc-config.xml
ファイルに指定されたauthorizationErrorPage.jspx
)が表示されます。
例41-17 タスク・フローを使用するアプリケーションのエラー・ページ・リダイレクト
<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コントローラ例外ハンドラのビュー・アクティビティとしてエラー・ページを指定する方法の詳細は、24.5項「タスク・フローでの例外の処理」を参照してください。
ユーザーが認証されず、認可の失敗が発生した場合は、フレームワークがADF認証サーブレットにリダイレクトし、ADF認証サーブレットがログインを求めるJava EE制約をトリガーします。この場合、コンテナ管理セキュリティは、web.xml
ファイルの<login-config>
要素に指定されているログイン・ページとエラー・ページを利用します。
タスク・フローを使用せずにFusion Webアプリケーションを作成する場合、例41-18に示すようにADFバインディング・フィルタのための<init-param>
設定をweb.xml
に指定できます。アプリケーションにタスク・フローがないこのケースでは、ページ認可チェックがADFバインディング・フィルタによって処理され、unauthorizedErrorPage
パラメータがADFバインディング・リクエスト・ハンドラに渡されます。
注意:
|
例41-18 タスク・フローを使用しないアプリケーションのエラー・ページ・リダイレクト
<filter> <filter-name>adfBindings</filter-name> <filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class> <init-param> <param-name>unauthorizedErrorPage</param-name> <param-value>faces/authorizationErrorPage.jspx</param-value> </init-param> </filter>
ユーザーが保護対象のリソースにアクセスできるように(直接URLアクセスまたはADFセキュリティの保護対象リソースへの移動により)暗黙的な認証を実装することを選択すると、ADFセキュリティ認証サーブレットがJava EEコンテナを開始し、web.xml
ファイルで構成されているログイン・フォームを表示します。暗黙的な認証では、ADF Facesコンポーネントを使用するようにデフォルトのウィザードにより生成されたログイン・フォームをカスタマイズしている場合は、ADF Facesサーブレットを参照するようにサーブレット・マッピングに対するURLパターンを変更する必要があります。
「ADFセキュリティの構成」ウィザードの「認証タイプ」ページでこのように設定できます。あるいは、web.xml
ファイルで直接行うことができます。すでに「ADFセキュリティの構成」ウィザードを実行している場合は、次の手順に従って、説明したようにweb.xml
ファイルが更新されていることを確認できます。
明示的な認証を実装することを選択し、ユーザーが保護対象のリソースにアクセスするためにログインできるようにパブリック・ページを作成した場合は、作成するログイン・フォームはADFセキュリティによりトリガーされません。明示的な認証シナリオでは、web.xml
ファイルを構成する必要はありません。
注意: アプリケーションで明示的な認証がプログラム的に実装されており、41.7.2.2項「明示的な認証用のADF Facesベースのログイン・ページの作成」で説明しているとおりにログイン・ページを作成した場合に |
作業を始める前に、次のようにします。
ログイン・ページの知識があると役立ちます。詳細は、41.7.2項「明示的な認証用のログイン・ページを作成する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
暗黙的な認証用のADF Facesログイン・ページを参照するには:
「アプリケーション」ウィンドウで、WEB-INFを開き、web.xmlをダブルクリックします。
web.xml
ファイルの概要エディタで、「セキュリティ」ナビゲーション・タブをクリックします。
「セキュリティ」ページで「ログイン認証」セクションを開き、ADF Facesサーブレットへの参照を含むようにログイン・ページを設定します。こうすることで、ログイン・ページがADF Facesライフサイクル/faces/ADFlogin.jspx
ページの一部になります。
ファイル・ブラウザを使用してページを追加すると、web.xml
ファイルに入力されるパスに/faces
が指定されません。ADF Facesサーブレットのサーブレット・マッピング・パスを参照するようにパスのエントリを変更します。たとえば、マッピングで指定されるURLパターンが/faces/*
の場合、パスを/faces/
yourpage
.jspx
とする必要があります(図41-26)。
アプリケーションのweb.xml
ファイルの指定に基づいてBasic認証が有効な場合、ブラウザは認証資格証明をキャッシュします。これは、ADF認証サーブレットによるログアウト・リダイレクトの実行後に、Basic認証によってユーザーを再認証する場合の既知の問題です。このシナリオでは、ログアウト・セッションを完了し、ユーザーがリソースにアクセスできないようにするために、ブラウザを閉じて新しいブラウザ・セッションを再起動する必要があります。ADFアプリケーションがログアウトを完了し、ログアウト後はユーザーがリソースにアクセスできないようにするには、Basic認証のかわりにフォームベース認証を使用します。41.3.1項「ADFセキュリティを有効化する方法」で説明するように、ADFセキュリティの構成ウィザードを実行してフォームベース認証を選択できます。
アプリケーションのweb.xml
ファイルの指定に基づいてBasic認証が有効な場合、ブラウザは認証資格証明をキャッシュします。これは、ADF認証サーブレットによるログアウト・リダイレクトの実行後に、Basic認証によってユーザーを再認証する場合の既知の問題です。このシナリオでは、ログアウト・セッションを完了し、ユーザーがリソースにアクセスできないようにするために、ブラウザを閉じて新しいブラウザ・セッションを再起動する必要があります。ADFアプリケーションがログアウトを完了し、ログアウト後はユーザーがリソースにアクセスできないようにするには、Basic認証のかわりにフォームベース認証を使用します。41.3.1項「ADFセキュリティを有効化する方法」で説明するように、ADFセキュリティの構成ウィザードを実行してフォームベース認証を選択できます。
ADFセキュリティを有効化してカスタム・エラー・ページを表示する場合、ページ表示のリクエストに応じてアプリケーションがHTTPエラーを生成すると、エラー・ページが表示されます。ただし、特定のバージョンのInternet Explorerでは、ブラウザに、カスタム・エラー・ページか、Internet Explorerに組み込まれているエラー・メッセージのどちらかが表示されます。Internet Explorerにエラー・メッセージのみが表示される場合は、「インターネット オプション」ダイアログの「詳細設定」で、エラー・メッセージ番号を表示するオプションを無効にできます。Internet Explorer 10では、このオプションはデフォルトで有効になっています。「ADFセキュリティの構成」ウィザードで有効化したカスタム・エラー・メッセージを表示するには、「HTTPエラーメッセージを簡易表示する」を無効にする必要があります。
Internet Explorer 10でカスタム・エラー・メッセージを表示するには:
Internet Explorerのツールバーで、「ツール」ボタンをクリックします。
「インターネット オプション」ダイアログで、「詳細設定」タブをクリックします。
「詳細設定」タブで、スクロールして「HTTPエラーメッセージを簡易表示する」を探します。
このオプションをクリックして無効化し、「OK」をクリックします。
統合WebLogic Serverにより、アプリケーションを直接JDeveloper内部で実行して、アプリケーションで定義するアプリケーション・ポリシー、ユーザーおよび資格証明などのセキュリティ・オブジェクトを移行するかどうかを決定できます。デフォルトでは、アプリケーションを実行するたびにすべてのセキュリティ・オブジェクトが統合WebLogic Serverに移行されます。
JDeveloperはデフォルトで、アプリケーションを実行するたびにアプリケーション・リポジトリから統合WebLogic Serverにセキュリティ・オブジェクトをデプロイするよう構成されています。この動作は、「アプリケーション・プロパティ」ダイアログでのセキュリティ・デプロイメント・オプションの選択により、次のように変更できます。
ドメインレベル・ポリシーをアプリケーションのjazn-data.xml
ファイル内のポリシーにより上書きするかどうかを決定します。
システム資格証明をアプリケーションのcwallet.sso
ファイルにより上書きするかどうかを決定します。
cwallet.sso
ファイル(JDeveloperの「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」→META-INFノード)には、安全に保持されるオブジェクトとして資格証明が格納されます。この資格証明はアイデンティティと照合するために認証プロバイダに渡されます。このファイルは暗号化されているため、JDeveloper内では参照も編集もできません。設計時に各種コンポーネントでcwallet.sso
ファイルを使用し、そのファイル内に必要な資格証明を作成します。
jazn-data.xml
ファイルのアイデンティティ・ストアの一部をドメインレベル・アイデンティティ・ストアに移行するかどうかを決定します。
デプロイ設定を変更しない場合、アプリケーションを実行するたびに、JDeveloperはドメイン・レベルのセキュリティ・ポリシーおよびシステム資格証明を上書きします。また、テスト目的で作成した新しいユーザー・アイデンティティを移行し、統合WebLogic Serverがそのアイデンティティ・ストアで使用する埋込みLDAPサーバー内の既存のユーザー・パスワードを更新します。しかし、統合WebLogic Server内の既存のセキュリティ・オブジェクトを更新せずにアプリケーションを実行する場合には、このオプションを選択できます。
始める前に:
統合WebLogic Serverについて理解しておくと役立ちます。詳細は、41.8項「JDeveloperでのセキュリティのテスト」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
セキュリティ・デプロイメントを構成し、JDeveloperでアプリケーションを実行するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「セキュリティ・デプロイメントの構成」を選択します。
「アプリケーション・プロパティ」ダイアログの「デプロイメント」ページの「セキュリティ・デプロイメント・オプション」セクションで、統合WebLogic Serverにデプロイするセキュリティ・オブジェクトを選択します。
デフォルトでは、アプリケーションを実行するたびに、JDeveloperによって、ドメイン・レベルのアプリケーション・ポリシーとシステム資格証明がアプリケーションのアプリケーション・ポリシーとシステム資格証明で上書きされます。これらリポジトリのいずれかを上書きしない場合は、「アプリケーション・ポリシー」または「資格証明」を選択解除します。選択解除した場合、JDeveloperでは新しいポリシーまたは資格証明のみがドメインレベル・ストアにマージされます。
デフォルトでは、アプリケーションを実行するたびに、テスト目的で作成する新規ユーザーのアイデンティティがJDeveloperによって移行され、統合WebLogic Serverでアイデンティティ・ストア用に使用される埋込みLDAPサーバーにある既存のユーザー・パスワードが更新されます。「ユーザーとグループ」を選択解除して、アプリケーションのアイデンティティ・ストアの移行を無効にできます。
「OK」をクリックします。
「アプリケーション」ウィンドウで、保護されたWebページが含まれるユーザー・インタフェース・プロジェクトを右クリックし、「実行」を選択します。
ユーザー・インタフェース・プロジェクトで「実行」を選択すると、JDeveloperでは、プロジェクトについて構成済のデフォルト実行ターゲットを使用してアプリケーションが実行されます。たとえば、実行ターゲットとしてタスク・フロー・アクティビティを構成して、アプリケーションを起動できます。デフォルトの実行ターゲットを構成するには、20.5項「タスク・フローのテスト」を参照してください。
アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。
統合WebLogic Serverを使用してアプリケーションを実行するとき、JDeveloperは、「アプリケーション・プロパティ」ダイアログに指定したセキュリティ・デプロイメント構成設定に基づいて、セキュリティ・ポリシーと資格証明をドメイン・レベルに移行します。デプロイメント・プロセスで、JDeveloperは、例41-19に示すように、「アプリケーション・プロパティ」の設定に基づいてデプロイメント・アーカイブ・ファイルに追加するweblogic-application.xml
ファイルを更新します。これらの設定はアプリケーション・ソース・ディレクトリのweblogic-application.xml
ファイルには追加されないため、表示されないことに注意してください。
例41-19 アーカイブ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(デフォルトで開発モードで実行するように設定されている)にどちらも再デプロイすることができます。
注意: いずれ本番環境にデプロイする際には、 |
また、例41-20に示すように、JDeveloperはweblogic-application.xml
ファイルをOPSSライフサイクル・リスナーでも更新します。アプリケーションが実行する前に移行プロセスを開始するために、ライフサイクル・リスナーはポリシーと資格証明について移行設定を確認し、ドメイン・レベルでセキュリティ・オブジェクトを上書きします。
例41-20 アーカイブ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
と同等の暗黙のグループです。
アイデンティティ・ストアの移行は、weblogic-application.xml
ファイルのアプリケーション・ライフサイクル・リスナー設定では制御されません。かわりに、統合WebLogic Serverで実行するとき、またはJDeveloperからデプロイするときは、Oracle WebLogic Mbeanによってアイデンティティの移行が処理されます。ユーザーがすでに存在している場合、Mbeanはユーザー定義全体を移行しません。ユーザーのパスワードだけを更新します。
「ADFセキュリティの構成」ウィザードを実行すると、jazn-data.xml
ファイルのポリシー・ストアにtest-all
アプリケーション・ロールを追加するオプションを有効にできます。このオプションを有効にするときは、アプリケーションのアプリケーション・ロールへの権限付与のスコープも指定します。
JDeveloperでtest-all
アプリケーション・ロールにview権限を付与し、ウィザードの実行時にユーザー・インタフェース・プロジェクトに表示されるADFタスク・フローとWebページすべてにこのポリシーを適用するには、「既存のオブジェクトのみに付与」を選択します。
JDeveloperでtest-all
アプリケーション・ロールにview権限を付与し、開発者がユーザー・インタフェース・プロジェクトで作成した既存のADFタスク・フローとWebページ、および今後ユーザー・インタフェース・プロジェクトで作成するすべてのADFタスク・フローとWebページにこのポリシーを適用するには、「すべてのオブジェクトに付与」を選択します。「すべてのオブジェクトに付与」オプションを選択してウィザードを初めて実行した後は、ウィザードによりオプション「新規オブジェクトに付与」が表示されます。
ウィザードの実行後、jazn-data.xml
ファイルにtest-all
ロールが表示され、セキュリティ・ポリシーの概要エディタにこのロールが表示されます。test-all
ロールにテスト・ユーザーを移入する必要はありません。ウィザードによって、組込みアプリケーション・ロールanonymous-role
がtest-all
ロールに割り当てられるためです。この場合、すべてのユーザーは自動的にanonymous-role
プリンシパルを保持し、アプリケーションへのアクセスを許可されます。
注意: 41.9.1項「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」で説明するように、アプリケーションをデプロイする前に、 |
いつでもウィザードを再実行して、自動付与を無効にすることができます。いったん無効になると、新たに作成するADFタスク・フローとWebページはtest-all
ロールを利用しないため、41.5項「ADFセキュリティ・ポリシーの定義」で説明するように明示的な付与を定義する必要があります。
統合WebLogic Serverを使用してJDeveloperでアプリケーションをテストするとき、アイデンティティ・ストアが、Oracle Internet Directoryに格納されている情報と一緒に埋込みLDAPサーバーに移行されます。
図41-27に、ユーザーがあらかじめログインせずに、ADFバインド・タスク・フローまたはADFバインディングを含むWebページ(mypage.jspx
など)にアクセスを試行するときの認証プロセスを示します。ユーザーがパブリック・ページのログイン・リンクをクリックしてログインを開始するのではないため、認証は暗黙的に開始されます。セキュリティ保護されたページの場合、無名ユーザーに対して権限付与は行われません。
図41-27の暗黙的な認証プロセスでは、リソースがanonymous-role
に対する権限を持たず、ユーザーがまだ認証されていず、認証メソッドがフォームベース認証であると想定しています。この場合、処理は次のようになります。
バインド・タスクフローまたはWebページ(ADFバインディングを含む)がリクエストされると、ADFバインディング・サーブレット・フィルタがADF認証サーブレットにリクエストをリダイレクトし(図のステップ1)、ログインをトリガーした論理操作を格納します。
ADF認証サーブレットにはJava EEセキュリティ制約が設定されているため、Java EEコンテナによって構成済のログイン・メカニズムが起動されます(図のステップ2)。コンテナのログイン構成に基づいて、ユーザーは次のように認証を求められます。
フォームベース認証の場合は、適切なログイン・フォームが表示されます(図のステップ2a)。
ユーザーは、表示されるログイン・フォームに自分の資格証明を入力します(図のステップ2b)。
ユーザーは、コンテナのj_security_check()
メソッドにフォームをポストします(図のステップ2c)。
Java EEコンテナは、構成済のプラガブル認証モジュールを使用してユーザーを認証します(図のステップ2d)。
認証が成功すると、コンテナは認証チャレンジを開始したサーブレット(この場合はADF認証サーブレット)にユーザーをリダイレクトします(図のステップ3)。
ADF認証サーブレットに戻ると、最初にリクエストされたリソースにリダイレクトされます(図のステップ4)。
リソースが表示されるかどうかは、ユーザーのアクセス権と、ADFセキュリティのための認可が施行されているかどうかに依存します。41.8.5項「実行時に行われる処理: ADFセキュリティによる認可の処理」を参照してください。
図41-28は、パブリック・ページの「ログイン」リンクから開始するプロセスで、ユーザーが認証される場合の明示的認証処理を示しています。
明示的認証のシナリオでは、(anonymous
ユーザー・プリンシパルとanonymous-role
プリンシパルのみを持つ)認証されていないユーザーが、パブリック・ページの「ログイン」リンクをクリックします(図のステップ1)。「ログイン」リンクは、web.xml
ファイルのJava EEセキュリティ制約を介してセキュリティ保護されているADF認証サーブレットへのダイレクト・リクエストです。
このシナリオでは、現在のページがパラメータとしてADF認証サーブレットに渡されます。暗黙的認証のケースと同じく、セキュリティ制約によってユーザーがログイン・ページにリダイレクトされます(図のステップ2)。暗黙的認証ケースのステップa - ステップdで説明したようにコンテナがユーザーを認証すると、リクエストがADF認証サーブレットに戻されます(図のステップ3)。その後、サーブレットによってユーザーがパブリック・ページに戻されますが、その時点では新しいユーザーおよびロール・プリンシパルが配置されています。
ADF認可が有効になってるとき、ADFバインド・タスク・フローとタスク・フロー外部のWebページ(ADFページ定義がある)はデフォルトで保護されます。ユーザーがこれらのWebページにアクセスしようとすると、ADFセキュリティが、ポリシー・ストアでそのユーザーがアクセス権を付与されているかどうか、確認して判定します。ユーザーがまだ認証されていず、anonymous-role
に対してページが許可されていない場合、ログイン・ページまたはフォームが表示されます。認証されたユーザーでも権限がない場合は、セキュリティ・エラーが表示されます。ポリシー・ストアに適切な権限を構成していない場合、ページは保護された状態に維持され、したがって認証されたユーザーも利用できません。
図41-29は、認可プロセスを示しています。
このユーザーは、ポリシー・ストアに定義されたアプリケーション・ロール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
のポリシー・ストアで定義されています。
統合WebLogic Serverを使用したJDeveloperでのテストの後は、アプリケーションをスタンドアロン・サーバーにデプロイすることができます。最初は、ターゲットのサーバーはステージング環境です。本番環境にデプロイする前に、このサーバーのアイデンティティ・ストアを使用して開発のテストを続行できます。つまり、通常は作成したテスト・ユーザーを統合WebLogic Serverで実行するために移行しません。資格証明(cwallet.sso
ファイル内)とセキュリティ・ポリシー(jazn-data.xml
ファイル内)をスタンドアロンOracle WebLogic Serverに移行するために実行するステップは、ターゲット・サーバーで構成されているモードと、デプロイにJDeveloperまたはJDeveloper外部ツールのどちらを使用するかによって異なります。
ターゲット・サーバーが開発モードで構成されているときは、JDeveloperから直接デプロイできます。この場合、JDeveloperが、デプロイメント・プロセスの一環としてポリシー・ストア、システム資格証明およびアイデンティティ・ストア(ユーザーおよびグループ)の移行を自動的に処理します。アプリケーション・セキュリティ・デプロイメント・プロパティでは、デプロイメント・プロセスがドメインレベルのポリシー・ストアとシステム資格証明を上書きできるようにデフォルトで構成されています。さらに、アイデンティティ・ストア・デプロイメント・プロパティは、テスト・ユーザーを含むアイデンティティ・ストアを移行するようにデフォルトで構成されています。41.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、このデフォルトのデプロイメント動作を「アプリケーション・プロパティ」ダイアログで変更できます。
注意: 開発モードで実行するOracle WebLogic Serverへのシステム資格証明の移行が実行されるのは、ターゲット・サーバーが資格証明の上書きを許可するように構成されている場合だけです。システム資格証明の上書きをサポートするためにOracle WebLogic Serverを構成する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。 |
ターゲット・サーバーが本番モードで構成されているとき、通常は、JDeveloper外部でOracle Enterprise Managerなどのツールを使用して移行タスクを処理します。JDeveloper外部のツールを使用してポリシー・ストアを本番環境のドメインレベルに移行する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。本番モードで実行するOracle WebLogic Serverでは、どのような状況でもシステム資格証明の上書きはサポートされないことに注意してください。
「ADFセキュリティの構成」ウィザードで自動付与機能を有効にした場合は、アプリケーションをデプロイする前にtest-all
アプリケーション・ロールを削除することをお薦めします。test-all
ロールによってすべてのADFリソースが公開されるため、このロールが存在していると、アプリケーションのリソースが保護されない状態になるリスクが高まります。したがって、アプリケーションレベルのポリシー・ストアを移行する前にこのロールを削除する必要があります。
さらに、アプリケーションのOracle WebLogic Serverへのデプロイを準備するとき、jazn-data.xml
ファイルに作成したテスト・アイデンティティを削除することもお薦めします。こうしておくと、セキュリティ・ポリシーをテストするために作成したユーザーが、ドメインレベルのアイデンティティ・ストアに移行されません。
ベスト・プラクティス: アプリケーションをスタンドアロン環境にデプロイする場合は、すでにOracle WebLogic Serverに対して構成しているローカル・アイデンティティ・ストアのユーザーおよびエンタープライズ・ロールを移行してはいけません。たとえば、ユーザー |
セキュリティ・ポリシーの概要エディタには、ADFセキュリティの組込みtest-all
ロールに対するview権限を持つすべてのリソースを表示する機能があります。概要エディタのこの機能を使用して、test-all
ロールの権限を削除し、アプリケーションで定義するロールの権限で置き換えることができます。
または、jazn-data.xml
ファイルの概要エディタを使用してtest-all
ロールを削除できます。エディタの「アプリケーション・ロール」ページでtest-all
ロールを選択して、「アプリケーション・ロールの削除」ボタンをクリックします。ただし、この方法でtest-all
ロールを削除しても、削除するロールのかわりの権限を作成する必要があります。概要エディタではこれらのタスク両方を一緒に行うことができるため、次の手順で使用方法を説明します。
始める前に:
Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、41.9項「セキュア・アプリケーションのデプロイの準備」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
test-allアプリケーション・ロールを削除し、カスタム・アプリケーション・ロールで置き換えるには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択し、「test-allのみが付与されたタスク・フローを示します」チェック・ボックスを選択して、この組込みロールに対する権限を含むタスク・フローのリストを表示します。
test-all
ロールに対する権限が存在しない場合、概要エディタの「リソース」リストには何も表示されません。test-all
ロールが定義されるのは、ADFセキュリティの構成ウィザードで有効にした場合のみです。有効になっている場合、test-all
の権限を含むそれらのタスク・フローが図41-30のように表示されます。
「リソース」列でリストの最初のタスク・フローを選択します。
「付与先」列でtest-allを選択し、「権限受領者の削除」アイコンをクリックします。
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。その後、「アプリケーション・ロールの選択」ダイアログを使用して必要なロールを追加します。
これらのステップを繰り返し、残りのすべてのタスク・フローでtest-all
ロールを削除して、独自のアプリケーション・ロールで置き換えます。
概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択し、手順を繰り返して、すべてのWebページとそのADFページ定義についてtest-all
ロールを削除します。
「test-allのみが付与されたタスク・フローを示します」/「test-allのみが付与されたWebページを示します」チェックボックスが選択された状態で、概要エディタにtest-all
権限付きのリソースが表示されていないことを確認します。
デプロイ先のスタンドアロンOracle WebLogic Serverでは、構成済の独自のアイデンティティ・ストアが用意されます。JDeveloperで作成したテスト・ユーザーとエンタープライズ・ロール・グループをドメイン・レベルに移行しないようにするには、jazn-data.xml
ファイルからテスト・ユーザー・レルムを削除する必要があります。
または、JDeveloperからデプロイする場合は、ユーザーとグループの移行を無効にすることができます。これには、41.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」オプションを選択解除します。
始める前に:
Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、41.9項「セキュア・アプリケーションのデプロイの準備」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
アイデンティティ・ストアからテスト・ユーザーとエンタープライズ・ロール・グループを削除するには:
メイン・メニューで「アプリケーション」メニューを選択し、「保護」→「ユーザー」を選択します。
jazn-data.xml
ファイルのエディタ・ウィンドウで「ソース」タブをクリックします。
jazn-data.xml
ファイルのソースで<jazn-realm>要素の横の「-」アイコンをクリックすると、図41-31のように要素全体が折りたたまれます。
この要素が選択された状態で[Delete]を押し、ファイルを保存します。
リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルは、ADFセキュリティによって保護されません。アプリケーションのWebページをセキュリティ保護する場合、これらのファイルをセキュリティ保護することは必須ではありませんが、アプリケーションを十分にセキュリティ強化するために、リソース・ファイルを保護したほうが好ましい場合もあります。JavaScriptファイルはブラウザにダウンロードされるため、このときに読取り可能となることに注意してください。
リソース・ファイルを提供するため、ADF Facesフレームワークではorg.apache.myfaces.trinidad.webapp.ResourceServlet
を使用し、これによってリソース・ローダーに処理が委譲されます。Fusion Webアプリケーションのweb.xml
ファイルには、リソース・サーブレットとURLパターンを対応付けるサーブレット・マッピングが含まれます。JDeveloperは、デフォルトで/adf/*
(MyFaces Trinidad Coreの場合)および/afr/*
(ADF Facesの場合)パターンを使用します。
リソース・サーブレットはADFセキュリティによって保護されないため、リソース・サーブレット用のJava EEアクセス・パスを、セキュリティ制約を使用して保護できます。リソース・ファイルに対する独自のセキュリティをweb.xml
ファイル内に実装するには、/adflib/*
、/adf/*
および/afr/*
パスに対するセキュリティ制約を定義して、これらに特定のセキュリティ・ロールを割り当てます。このセキュリティ制約により、すべてのユーザーは、Fusion Webアプリケーションの最初のページにアクセスする前に認証を受けることになります。
例41-21は、セキュリティ・ロールresource_role
と、このロールにマッピングされたURLパターンによる制約を示します。セキュリティ・ロールを定義した後は、ターゲット・サーバーの管理者によってこのロールをOracle WebLogic Serverエンタープライズ・ロール(ユーザー・グループ)にマッピングしてもらうか、または同名のエンタープライズ・ロールを作成してもらう(この場合はマッピングは不要)必要があります。
例41-21 リソース・ファイルに対するweb.xmlファイル内のURL制約
<security-role> <description>Java EE role to map to an enterprise role. All users who will be allowed to run Fusion web app must be members of that role.
</description> <role-name>resource_role</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>resources</web-resource-name> <url-pattern>/adflib/*</url-pattern> <url-pattern>/adf/*</url-pattern> <url-pattern>/afr/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>resource_role</role-name> </auth-constraint> </security-constraint>
アプリケーション・ポリシー・ストアに対する認可チェックを一時的に実行せずにアプリケーションを実行する必要がある場合、JDeveloperではADFセキュリティを無効にできます。こうすると、既存のセキュリティ・ポリシーで提供される保護なしで、アプリケーションを実行し、すべてのリソースにアクセスできます。
アプリケーションのレベルでADFセキュリティを無効にするには、ウィザードを実行して次のオプションの1つを選択します。
「ADF認証」を選択すると、ADF認可が無効になりますが、ADF認証サーブレットは有効なままです。たとえば、一時的に無効化されたセキュリティ・ポリシーに対して認可チェックを施行してアプリケーションをJDeveloperで実行する必要があるとします。このオプションでは、Java EEアプリケーション・ルート「/」を、ユーザー認証をトリガーするallPages
Java EEセキュリティ制約にマップすることで、ユーザーがアプリケーションのページに最初にアクセスしたときにログインを要求します。認可チェックが施行されないため、ADFリソースはセキュリティ対応になりません。したがって、一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。
「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効になり、ADFリソースの認可チェックも無効になります。この場合、ユーザー認証とADFリソースのセキュリティがない状態でアプリケーションを実行できます。
どちらのオプションもADFセキュリティを再有効化する目的でいつでも選択できます。このウィザードでは特に、アプリケーション開発者がADFリソースに対して定義したセキュリティ・ポリシーを含む、アプリケーションのポリシー・ストアは変更されません。このため、いつでもウィザードに戻り、「ADF認証および認可」オプションを選択し、アプリケーションの既存のポリシー・ストアやアイデンティティ・ストアに対してADFセキュリティを再有効化できます。
始める前に:
ADFセキュリティの無効化について理解しておくと役立ちます。詳細は、41.10項「ADFセキュリティの無効化」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
ADF認可チェックを無効にするには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。
「ADFセキュリティ」ページで「ADF認証」オプションまたはADFセキュリティ構成の無効化オプションを選択します。「次へ」をクリックします。
これらのオプションのいずれかを設定してウィザードを実行すると、ユーザー・インタフェース・プロジェクトのADFリソースはセキュリティ対応でなくなります。
「終了」をクリックします。
「ADFセキュリティ構成の削除」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、web.xml
ファイルとadf-config.xml
ファイルからADF固有のメタデータ(表41-2)が削除されます。
同様に、「ADF認証」オプションを選択してウィザードを実行し、認可チェックのみを無効にすると、次の更新が実行されます。
web.xml
ファイルでADF固有のメタデータは変更されず、allPages
セキュリティ制約が追加されます。
allPages
セキュリティ制約が存在する場合、ユーザーはアプリケーションに最初にアクセスしたときに認証を行うことになります。
例41-22に示すようにadf-config.xml
ファイルの<JaasSecurityContext>
要素のauthorizationEnforce
パラメータがfalse
に設定されます。
例41-22 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
ファイルを表示する場合、ウィザードによって適用されたファイル内の変更を確認するにはワークスペースを保存する必要があります。
ADFセキュリティの有効化プロセスを完了した後、ユーザー・インタフェースにおいてADFセキュリティと連動するようにアプリケーションをカスタマイズすることができます。たとえば、式言語(EL)を使用し、一連のUIコンポーネントのためだけに定義したカスタム権限の評価に基づいて、UIコンポーネントをWebページにレンダリングできます。さらに、マネージドBean内にメソッドを定義して、アプリケーションの情報(ユーザー名やロール・メンバーシップなど)を公開できます。
式言語(EL)を使用するとUIのポリシーを直接評価できますが、Javaを使用するとマネージドBean内でポリシーを評価できます。ADFセキュリティでは、セキュリティ・コンテキストでADFリソースにアクセスするように、EL式で使用できる便利なメソッドがいくつか実装されています。たとえば、EL式の便利なメソッドを使用して、ユーザーが特定のタスク・フローにアクセスできるかどうかを判定することができます。優れたセキュリティは、ユーザーがアクセス権を持たないリソースや機能をアプリケーションが非表示にすることを求めます。この理由から、ユーザーが特定のタスク・フローへのアクセスを許可されない場合、そのユーザーの権限を評価して、そのタスク・フローを開始するナビゲーション・コンポーネントをレンダリングするかどうかを判別します。
注意: ポリシーを評価できるのは、現在のリクエストのみです。この理由から、リクエスト・スコープ外でポリシーを評価すると、予期しない結果が発生することがあるため、ポリシー評価がどこで行われるかを理解することが重要です。 |
UIコンポーネント内でELを使用すると、コンポーネントの属性値を動的に定義できるようになるため、実行時にUIコンポーネントを変更できます。リソースを保護する場合、対象となるUIコンポーネント属性はrendered
属性です。これを使用して、ユーザーの権限に基づいてコンポーネントの表示と非表示を切り替えることができます。デフォルトでは、rendered
属性はtrue
に設定されています。権限に応じてこの値を動的に変更することで、UIコンポーネントの表示と非表示を設定できます。たとえば、ユーザーが適切な権限を持っている場合は、UIコンポーネントが表示されるようにrendered
属性をtrue
に設定する必要があります。権限を持たない場合は、属性をfalse
に設定して、UIコンポーネントを非表示にする必要があります。
ELを使用してポリシーを評価するには、securityContext
ELネームスペースでADFセキュリティのメソッドを使用する必要があります。これらのメソッドを使用して、特定のユーザーまたはADFリソースに関してADFセキュリティ・コンテキストの情報にアクセスできます。
表41-11に、ユーザーが関連する権限を持つかどうかを判別するために必要なEL式を示します。ユーザーが適切な権限を持っている場合、EL式はtrue
に評価されます。そうでない場合はfalse
を返します。
表41-11 ADFリソースに対するview権限を判定するEL式
式 | 式のアクション |
---|---|
#{securityContext.taskflowViewable['
例: #{securityContext.taskflowViewable ['/WEB-INF/audit-expense-report.xml#audit-expense-report']} |
|
#{securityContext.regionViewable[' |
|
注意: ページ権限の場合、マネージドBean内部の遅延バインディングELを使用することにより、ページ定義の値を動的に指定できます。41.3.7項「valid-usersロールに関する必知事項」を参照してください。 |
表41-12には、ADFセキュリティ・コンテキストから、ADFリソースに関連しない一般的な情報を取得するためのEL式を示します。たとえば、ユーザーの名前をユーザー・インタフェースに表示する場合は、現在のユーザー名にアクセスできます。また、現在のユーザーが特定のロールのメンバーかどうか、特定の権限を付与されているかどうかもチェックできます。アプリケーションはこの結果を使用してメニューの非表示と表示を動的に切り替えることができます。
表41-12 ADFセキュリティ・コンテキストでのユーザー情報を判定するEL式
式 | 式のアクション |
---|---|
#{securityContext.userName} |
認証されたユーザーのユーザー名を戻します。 |
#{data.adfContext.tenantName} |
認証されたユーザーのテナント名を戻します。テナント名はユーザーが自ら認識している別名で、ログインに使用できます。 |
#{data.adfContext.tenantId} |
認証されたユーザーのテナントIDを戻します。 |
#{securityContext.authenticated} |
ユーザーがログインしている場合は |
#{securityContext.userInRole[' |
|
|
|
#{securityContext.userGrantedPermission['permission']}
|
表41-11に示された便利なメソッド |
#{securityContext.userGrantedResource['resource']}
|
この式を使用すると、タスク・フローに含まれないリソース(「ADF Faces」パネルやメニュー項目など)の表示プロパティの権限をテストできます。最初に、保護するUIコンポーネントのカスタム・リソース・タイプを作成します。詳細は、41.11.2項「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。 |
作業を始める前に、次のようにします。
ELの用法について理解しておくと役立ちます。詳細は、41.11.1項「ADFセキュリティでの式言語(EL)の使用」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
ナビゲーション・コンポーネントのレンダリングを、ターゲット・タスク・フローまたはページ定義に対してユーザーに付与された権限に関連付ける手順:
「アプリケーション」ウィンドウで、条件付きでレンダリングするナビゲーション・コンポーネントを含むページをダブルクリックします。
ページのビジュアル・エディタで、セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
「プロパティ」ウィンドウで、「レンダリング済」フィールドの横に表示されている「プロパティ・メニュー」ドロップダウン・メニューから、「式ビルダー」を選択します(図41-32)。
「式ビルダー」で「ADFバインディング」の「securityContext」ノードを開いて適切なEL値を選択します。次に、「式」フィールドに、アクセスしようとしているADFリソースの修飾名を入力します。
たとえば、図41-33に示すようにアプリケーションで表示するタスク・フローへのアクセスを制限するには、次のような式を作成します。
#{securityContext.taskflowViewable ['/WEB-INF/audit-expense-report.xml#audit-expense-report']}
この例では、式によって、ターゲット・タスク・フローaudit-expense-report
を表示するためのユーザーのアクセス権が判別されます。ユーザーにアクセス権がある場合、式はtrue
として評価され、rendered
属性は値true
を受け取ります。
ヒント: 「式ビルダー」ダイアログの「説明」を開くと、選択したセキュリティELメソッドに関する追加情報を参照できます。 |
「OK」をクリックします。
アプリケーションを実行すると、ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。
「式ビルダー」を使用してrendered
属性の式を定義すると、開いている.jspx
ファイルのコンポーネント定義がJDeveloperによって更新されます。例41-23に示すように、コンポーネントのrendered
属性に、true
またはfalse
に評価される式が追加されます。この例ではコンポーネントはナビゲーション・リンクであり、リンク・テキストCheckout
は別の式で定義されます。このナビゲーション・リンクを含むページによってこのコンポーネントがレンダリングされるのは、チェックアウト・タスク・フローにアクセスするための十分なアクセス権がユーザーにある場合のみです。
セキュリティ権限を評価できるスコープは、リクエストに設定されています。リクエストよりも上位レベルまでスコープ設定されたマネージドBean (マネージドBeanが基礎となっているグローバル・メニューなど)からターゲット・ページにアクセスするための権限を評価する場合は、遅延EL評価(遅延バインディング)を実装する必要があります。Beanの管理プロパティとしてターゲット・ページを渡すことで、マネージドBeanが必要なバインディング情報を取得できるようになった後でEL式が評価されるようになります。ELは、ページが実行されるとすぐに評価されるため、マネージドBeanを基礎としたUIコンポーネントのプロパティ内に直接EL式を配置すると、有効範囲外エラーが発生します。
例41-24に、ユーザーが特定のターゲット・ページを表示できるかどうかに基づいてtrue
またはfalse
を返すマネージドBeanのプロパティ(authorized
)を示します。この場合、_targetPageDef
変数は、ターゲット・ページの名前が含まれる管理プロパティです。UI内で、EL式はauthorized
プロパティを参照します。
例41-24 マネージド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; } }
表41-12に示したADFセキュリティのELネームスペースでのセキュリティ式によって、ページにUIコンポーネントを表示する前にユーザー権限、認証およびロール・メンバーシップ・ステータスを確認できます。タスク・フロー・セキュリティやWebページ・セキュリティの一部ではないアプリケーションの機能部分を保護するために、UIコンポーネントをきめ細かく保護する必要がある場合は、EL値userGrantedResource
と、カスタム・リソース・タイプ用に定義したリソース権限を使用します。たとえば、ユーザーがメニュー項目用に作成したリソース権限によって、アプリケーションはCancel Shipment(出荷取消し)のメニュー項目を有効化または無効化して、顧客注文更新の実行者を制限します。
カスタム・リソース・タイプのリソース権限は、ResourcePermission
クラスに依存しています。このクラスはOracle Platform Security Services (OPSS)によって提供され、アプリケーションとともにパッケージ化されています。
セキュリティ・ポリシーの概要エディタを使用して、カスタム・リソース・タイプのセキュリティ・ポリシーを作成します。またWebページでは、セキュリティ式を使用して、リソース権限によって投影されるUIコンポーネントへのユーザーのアクセス権限を評価します。
ベスト・プラクティス: カスタム・リソース・タイプと |
カスタム・リソース・タイプのリソース・ポリシーを許可するには:
保護するUIコンポーネントのカスタム・リソース・タイプを作成します。
カスタム・リソースに対してリソース権限を作成します。
UIコンポーネントのレンダリングを、ロールに付与されるリソース権限に関連付けます。
「リソース・タイプの作成」ダイアログを使用して、保護するUIコンポーネントのリソース・タイプを作成します。JDeveloperが、リソース・タイプの定義とOPSS権限クラスoracle.security.jps.ResourcePermission
を一致させます。このクラスを使用して、タスク・フロー・セキュリティまたはWebページ・セキュリティによって保護されないアプリケーションの機能部分に権限を付与できるカスタム・アクションを指定できます。たとえば、メニューのUIコンポーネントを使用してユーザーがアクセスするアプリケーションの機密部分を保護するために、リソース・タイプを作成することがあります。
「リソース・タイプの作成」ダイアログでは、保護するリソースのタイプ(たとえば、MenuProtection
という名前はメニューのUIコンポーネントを識別する)、セキュリティ・ポリシー・ストアに表示される表示名(例: Menu Protection
)、リソース権限でのリソース・タイプの使用方法の説明(例: Resource permission to grant menu item permissions
)を識別できます。このダイアログでは、権限を付与するために使用する1つ以上のカスタム・アクション名を入力することもできます。たとえば、保護されたメニュー項目へのアクセス権を付与するセキュリティ・ポリシーで使用するために、process
というアクション名を入力できます。
作業を始める前に、次のようにします。
ADF権限クラスについて理解しておくと役立ちます。詳細は、41.11.2項「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
カスタム・リソース・タイプを作成する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「新規リソース・タイプ」をクリックします。
「リソース・タイプの作成」ダイアログで、名前と、UIコンポーネントを説明する表示名を入力します。
たとえば、メニュー項目を保護するには、名前にはMenuProtection
、表示名にはMenu Protection
と入力します。
「アクション」リストで「追加」をクリックし、権限を付与するアクションの名前を入力して、「OK」をクリックします。
たとえば、メニュー項目を保護する場合、process
と入力することで、メニュー選択を処理する権限が付与されることを示します。特定のアクションの権限を個々のユーザーまたはロールに付与する場合は、複数のアクション名を入力できます。図41-34のように概要エディタにカスタム権限が表示されます。
jazn-data.xml
ファイルの概要エディタを使用して、カスタム・リソースのADFセキュリティ・ポリシーを作成します。完成したソースは、例41-25に示すように、ポリシー・ストアで定義される権限と類似した内容となります。
例41-25 カスタム・リソース権限の定義
<grant> <grantee> <principals> <principal> <name>AccountManagersadmin</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.security.jps.ResourcePermission</class> <name>resourceType=MenuProtection,resourceName=CancelShipment</name> <actions>process</actions> </permission> </permissions> </grant>
ターゲット名<permission>
は、カスタム・リソース・タイプと、リソースを割り当てた名前を識別します。たとえば、ユーザーがアカウント内のメニュー選択から出荷を取り消すことができるリソース名は、CancelShipment
という名前になります。
アクションは、カスタム・リソース・タイプによって定義されています。たとえば、メニュー保護では、リソース・タイプによって、メニュー選択を処理する権限を付与するための単一アクションprocess
が定義されます。
作業を始める前に、次のようにします。
ResourcePermission
クラスについて理解しておくと役立ちます。詳細は、41.11.2項「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
カスタム・リソース・タイプに対してリソース権限を作成する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで、「リソース・タイプ」ドロップダウン・リストからカスタム・リソースを選択します。
「リソース」列で、「リソースの追加」アイコンをクリックします。
「リソースの作成」ダイアログで、セキュリティ・ポリシーが特に保護するリソースの名前、表示名、説明を入力して、「OK」をクリックします。
概要エディタの「リソース権限」ページにおいて、「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アクション」列で、カスタム・リソース・タイプに対して定義したアクションを選択します。
図41-35のように、概要エディタにリソース権限が表示されます。
UIコンポーネントの表示プロパティに対する「式ビルダー」ダイアログを使用して、コンポーネントのレンダリングを制御するEL式を定義します。たとえば、認可ユーザーが出荷を取り消すことができるアプリケーションでメニュー項目を保護するために、アプリケーションは、af:commandMenuItem
によって定義されたメニュー項目のdisabledプロパティに対して、userGrantedResource
式を指定します。例41-26に示すように、ユーザーにリソース・タイプに対する権限が付与されているか、その結果メニュー項目が表示されるかどうかが式によってテストされ、ユーザーにリソースに対する権限が付与されていない場合は、メニュー項目が無効化されます。
例41-26 ユーザーのリソース権限を評価するための式
#{!securityContext.userGrantedResource ['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}
図41-36は、「式ビルダー」ダイアログに式がどのように表示されるかを示します。
作業を始める前に、次のようにします。
ResourcePermission
クラスについて理解しておくと役立ちます。詳細は、41.11.2項「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、41.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
カスタム・リソース・タイプを作成します。詳細は、41.11.2.1項「カスタム・リソース・タイプの作成」を参照してください。
41.11.2.2項「カスタム・リソース・タイプに対するリソース権限の作成」の説明に従って、カスタム権限を使用してADFセキュリティ・ポリシーを作成します。
UIコンポーネントのレンダリングとユーザーに付与されるリソース権限を関連付ける手順:
「アプリケーション」ウィンドウで、条件付きでレンダリングするUIコンポーネントを含むページをダブルクリックします。
ページのビジュアル・エディタで、セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
「プロパティ」ウィンドウで、「レンダリング済」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedResourceを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。
権限文字列は、resourceName=
theResourceInstanceName
;resourceType=
customResourceTypeName
;action=
actionName
のようにセミコロンで連結した文字列として入力します。たとえば、認可ユーザーが出荷を取り消すことができるアプリケーションでメニュー項目を保護するために、例41-27と同じような式を入力できます。ここで、userGrantedResource
のリソース・タイプは、カスタム・リソース権限で使用されるリソース・タイプを識別します。
例41-27 ユーザーのリソース権限を評価するためのEL式
#{!securityContext.userGrantedResource ['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}
例41-27では、アプリケーション・ポリシー・ストアに追加したMenuProtection
という名前のカスタム・リソース・タイプに基づいて、権限が式によって評価されます。
「OK」をクリックします。
Fusion Webアプリケーション内にセキュリティを実装することは、定義上、ADFセキュリティ・フレームワークのセキュリティ・インフラストラクチャを実装することです。このため、フレームワークのセキュリティ・コンテキストを使用して、アプリケーションのポリシーやセキュリティ全体を定義するときに必要となる情報にアクセスできます。
ADFセキュリティの施行は、アプリケーションと無関係にコンテナ・レベルでオン/オフを切り替えることができるため、認可チェックを行う前に、ADFセキュリティが有効化されているかどうかを判断する必要があります。このためには、例41-28に示すように、ADFセキュリティ・コンテキストのisAuthorizationEnabled()
メソッドをコールします。
Fusion Webアプリケーション内のユーザー・プリンシパルがnull
になることはない(つまり、認証されていないユーザーの場合はanonymous
で、認証されたユーザーの場合は実際のユーザー名になる)ため、ユーザー・プリンシパルがnull
かどうかを確認するだけで、そのユーザーがログオンしているかどうかを判断することはできません。このため、anonymous
ユーザー・プリンシパルがユーザーが認証されていないことを表すことを考慮に入れるメソッドを使用する必要があります。このためには、例41-29に示すように、ADFセキュリティ・コンテキストのisAuthenticated()
メソッドをコールします。
Fusion Webアプリケーションでは、セキュアでありながらすべてのユーザーに使用可能なパブリック・ページの概念をサポートしています。さらに、Webページ上のコンポーネント(ポートレットなど)では、現在のユーザー・アイデンティティの情報を必要とします。このため、Fusion Webアプリケーションのユーザー名は決してnull
になることはありません。認証されていないユーザーがページにアクセスすると、ユーザー名anonymous
がページ・コンポーネントに渡されます。Fusion Webアプリケーションがユーザーのテナント名を登録しているときは、テナント名も取得できます。テナント名はユーザーが自ら認識している別名で、ログインに使用できます。
現在のユーザー名を判別するには、例41-30に示すように、ADFセキュリティ・コンテキストのgetUserName()
メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymous
を返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。
例41-30 ADFセキュリティ・コンテキストのgetUserName()メソッドの使用
// ============ Current User's Name/PrincipalName ============= public String getCurrentUser() { _currentUser = ADFContext.getCurrent().getSecurityContext().getUserName(); return _currentUser; }
Facesベースのアプリケーションでユーザー名を判別するための従来のメソッド(FacesContext.getCurrentInstance().getExternalContext().getRemoteUser()
)では、認証されていないユーザーに対してnull
が戻されるため、そのメソッドを使用する場合は、パブリック・ユーザーのケースを処理する追加のロジックを使用する必要があります。
現在のユーザーのテナント名を判別するには、例41-31に示すように、ADFコンテキストのgetTenantName()
メソッドを評価します。
例41-31 ADFコンテキストのgetTenantName()メソッドの使用
// ============ Current User's Tenant Name ============= public String getTenantName() { _tenantName = ADFContext.getCurrent().getTenantName(); return _tenantName; }
現在のユーザーのテナントIDを判別するには、例41-32に示すように、ADFコンテキストのgetTenantId()
メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymous
を返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。
Fusion WebアプリケーションはJavaServer Facesベースのアプリケーションなので、例41-33に示すように、Faces外部コンテキストのisUserInRole(roleName)
メソッドを使用すると、ユーザーに特定のロールが割り当てられているかどうかを判別できます。ADFセキュリティはJAASポリシーに基づくため、ロール・メンバーシップに基づくADFセキュリティ対応リソースに関連付けられたページを保護するためにJava EEセキュリティ・ロールを使用する必要はありません。ただし、ADFセキュリティ対応リソースに関連付けられていないページについては、メソッドを使用してロールをチェックできます。
この例では、便利なメソッド(checkIsUserInRole
)が定義されています。マネージドBean内でこのメソッドを使用すると、名前付きロールのメンバーシップを属性として公開し、その後EL内で使用できます。
Java内からセキュリティ・ポリシーを評価するには、ADFセキュリティ・コンテキストのhasPermission
メソッドを使用できます。このメソッドは、(リソースとアクションの組合せにより定義された)権限オブジェクトを取り、ユーザーに対応する権限があればtrue
を返します。
例41-34では、ページ名と必要なアクションを渡し、ユーザーの権限に基づいてtrue
またはfalse
を返すことのできる、便利な関数が定義されています。この便利な関数がページ権限を確認するため、RegionPermission
クラスを使用して、hasPermission
メソッドに渡される権限オブジェクトを定義しています。
例41-34 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ナビゲーション・アクションの結果を動的に変更できます。例41-35では、1つのコマンド・ボタンがユーザーの権限に応じて異なるターゲット・ページを指していることがわかります。コマンド・ボタンのバッキングBeanは、最も高いレベルで保護されているページ(管理者ページ)から最も低いレベルで保護されているページ(パブリックのようこそページ)までview権限を確認することにより、適切なアクションを適用して、ユーザーに対して権限レベルに応じたページを表示します。適切なアクションを戻すバッキングBeanは、例41-34に定義されている便利なメソッドを使用しています。
例41-35 認可チェックに基づくページ・ナビゲーション結果の変更
//Command Button Definition <af:button text="Goto Your Group Home page" binding="#{backing_content.commandButton1}" id="commandButton1" action="#{backing_content.getSecureNavigationAction}"/> //Backing Bean Code public String getSecureNavigationAction() { String ActionName; if (TestPermission("ManagerPage", "view")) ActionName = "goToManagerPage"; else if (TestPermission("EmployeePage", "view")) ActionName = "goToEmployeePage"; else ActionName = "goToWelcomePage"; return (ActionName); }
次に示すベスト・プラクティスは、ADFセキュリティ・フレームワークによるセキュリティ施行のための規則をまとめたものです。これらのベスト・プラクティスを理解することで、アプリケーションを保護して、意図したWebページにユーザーのアクセスを許可することができます。
アプリケーションを構築するときは最初からADFセキュリティを有効にしてください。
セキュリティを有効化すると、アプリケーションが実質的にロックダウンされます。また、作成する固有のADFセキュリティ対応リソースに対して明示的な権限付与を行う必要が生じます。アプリケーションを構築する際に、これらのリソースについて認識して、権限付与を行うことにより、反復しながらセキュリティをテストできます。こうして、必要な結果を実現するようにアプリケーションを構成できます。
バインド・タスク・フローの権限を定義してください。
バインド・タスク・フローを実行するプロセスでユーザーがアクセスするページは、ページごとの個別の権限チェックは行われず、タスク・フローの権限において実行されます。つまり、タスク・フローに追加するページには、ページ定義レベルでの独自のセキュリティは定義されていません。ユーザーがフローをリクエストする場合、アクセス・レベルに応じて、タスク・フローのすべてのページの表示を許可されるか、まったく許可されないかのどちらかになります。
バインド・タスク・フローの個々のページには権限を定義しないでください。
タスク・フローはユーザーによるページへの直接アクセスを妨げないことを理解することが重要です。公開されているディレクトリにあるすべてのWebページは、URLを使用してブラウザからアクセスできます。バインド・タスク・フローによって参照されるページに直接アクセスできないようにするため、関連するページ定義ファイルについて存在するすべての権限を削除します。バインド・タスク・フローのコンテキスト内でページに追加のセキュリティが必要な場合は、それらのページをサブタスク・フローに含めて、このネストされたタスク・フローに対する権限の定義を追加します。
エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすため、タスク・フローを使用してください。
タスク・フローを使用すると、エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすことができます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローのURL起動プロパティをurl-invoke-disallowed
に設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。URL起動プロパティの詳細は、21.6.4項「URLを使用したバインド・タスク・フローのコール方法」を参照してください。
未認可のユーザーに対する代替タスク・フローを指定してください。
エンド・ユーザーが、必要な権限を持たないリージョンでバインド・タスク・フローを起動しようとすると、リクエストしたタスク・フローではなく、空白にレンダリングされたリージョンが表示されます。リージョンが空白のままだと、リクエストしたタスク・フローが表示されない理由についてのフィードバックが提供されないため、エンド・ユーザーが当惑する可能性があります。このシナリオの発生時には、認可が必要でない代替タスク・フローを構成することを検討してください。代替タスク・フローの構成の詳細は、23.12項「未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理」を参照してください。
バインド・タスク・フロー外部の個々のページには権限を定義してください。
ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。ページ定義ファイルとそれがセキュリティ保護するWebページの間には1対1の関係があります。
ADFバインディングを使用しないページを保護する場合は、そのページに対して空のページ定義バインディング・ファイルを作成できます。
ユーザーのアクセス権に基づいてUIコンポーネントをレンダリングするにはカスタム権限を定義してください。
カスタムADF権限クラスを使用すると、ADFセキュリティを拡張して、権限で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。
UIコンポーネントによって表示される行レベル・データに対するユーザーのアクセス権を管理するには、エンティティ・オブジェクト属性権限を定義してください。
エンティティ・オブジェクトおよびエンティティ・オブジェクト属性は両方とも権限クラスを定義します。これを使用して、エンティティ・オブジェクトがデータ・ソースに対して開始する読取り、更新および削除操作の権限を定義できます。これらのデータ・モデル・プロジェクト・コンポーネントの場合、ADFセキュリティ認可を選択するために、アプリケーション・ロールに明示的に権限を付与する必要があります。ただし、エンティティ・オブジェクトの認可を有効にすると、そのエンティティ・オブジェクトによって定義されたすべてのデータ行は権限付与によって保護されます。このレベルの粒度では、表コンポーネントがWebページにレンダリングされるとき、ユーザーのアクセス権に応じて、すべてのデータが表示されるかデータがまったく表示されないかのどちらかになります。コレクション全体を保護するかわりに、データの個々の列を保護することができます。このレベルの粒度は、エンティティ・オブジェクトの個々の属性に設定する権限によってサポートされます。エンティティ・オブジェクトが保護されるとき、ユーザーが見ることができるのは表コンポーネントに表示されるデータの一部のみです。
view権限しかないユーザーに行レベルの作成/挿入操作を公開しないようにするには、タスク・フローまたはページレベルの権限付与を使用してください。
特定のユーザーだけが表の新しい行を更新できるページのアクセスを制御する適切な方法としては、タスク・フローまたはページレベルの権限付与を使用します。ただし、代替手段として、特定の操作に対応する表ボタンを保護することができます。これには、EL式を指定して、ボタンを表示するためのユーザーのアクセス権をテストします。カスタム権限が定義され、userGrantedPermission
式がボタンのRendered
プロパティに設定されているとき、十分な権限を持つユーザーのみにボタンが表示されます。これが役立つのは、ユーザー・インタフェースに表示されるページに制限がなく、行レベルデータのview権限のみがエンティティ・オブジェクトに定義されている場合です。この場合、ユーザーが表示すると、エンティティ・オブジェクトに関連付けられた編集可能な表の「Delete」ボタンは無効な状態で表示されます。ただし、入力表の場合は、ユーザーにupdate権限がなくても、ユーザー・インタフェースによってCreateInsert
操作のボタンが無効になることはありません。
JDeveloperを、ユーザー・アイデンティティのプロビジョニング・ツールとして使用しないでください。
JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、常にシステム管理者が担当します。アプリケーションをデプロイする前に、作成したすべてのユーザーおよびグループをjazn-data.xml
ファイルから削除する必要があります。
ユーザーがファイル名を使用してWebページにアクセスできないようにしてください。
Fusion Webアプリケーションをデプロイするときは、ADFコントローラの構成ファイルに定義されたビュー・アクティビティからユーザーがWebページにアクセスできるように常に許可する必要があります。ユーザーがJSPXファイルの物理名(ファイル名AllDepartments.jspx
など)を使用して直接アクセスすることは許可しないでください。
ビュー・アクティビティの名前がAllDepartments
とすると、このページをコールするには次の2つの方法があります。
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セキュリティ権限を適用します。