Oracle® Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発 12c (12.2.1.3.0) E90376-03 |
|
![]() 前 |
![]() 次 |
この章の内容は次のとおりです。
セキュリティは、エンタープライズ・アプリケーションの重要な部分です。ADFアプリケーションでのセキュリティの実装により、アプリケーションにアクセスできるユーザーや、それらのユーザーがログイン後に行える操作が決定されます。Fusion Webアプリケーションの様々なレイヤーでセキュリティを視覚的に有効化できます。
ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。ADFセキュリティはOracle Platform Security Services (OPSS)アーキテクチャの上に構築されます。このアーキテクチャはそれ自体がOracle WebLogic Serverと密接に統合されています。それ以外にも、ユーザー・ログインおよびリソースの保護を処理できるセキュリティ対応モデルはありますが、ADFバインド・タスク・フロー、ADFバインディングを使用するトップレベルのWebページ(バインド・タスク・フローに含まれないページ)、および最も低いレベルの粒度でADFエンティティ・オブジェクトとその属性によって定義されたデータ列に対して宣言型で許可ベースの保護を実現するのに、ADFセキュリティは非常に適しています。このドキュメントでは、ADFセキュリティ・フレームワークが保護するこれらの個々のリソースを、ADFセキュリティ対応リソースと呼びます。
「ADFセキュリティの有効化」の説明に従い、ADFセキュリティの構成ウィザードを実行して、Fusion WebアプリケーションのADFセキュリティを有効にします。このウィザードにより、Fusion Webアプリケーション全体のADFセキュリティを構成するため、ADFセキュリティ対応リソースに関連するWebページはデフォルトで保護されます。つまり、ADFセキュリティを有効化すると、アプリケーションがロックダウンされるので、そのページはデフォルトでセキュアであるとみなされます。
ADFセキュリティを有効にしたら、ユーザーにアクセス権を付与する必要があります。これによってユーザーは、Fusion WebアプリケーションのWebページを表示できるようになります。ユーザーに付与するアクセス権は、ページのADFセキュリティ対応リソース用に指定するセキュリティ・ポリシーとして知られています。タスク・フローの入力やWebページの表示を行うユーザー権限を制御するのは、最終的にはADFリソースにおけるセキュリティ・ポリシーになります。
ADF SecurityはJava Authentication and Authorization Service (JAAS)に基づいているので、セキュリティ・ポリシーによりプリンシパル(ユーザーまたはアプリケーション・ロール)、ADFリソースおよび権限(リソースのADF権限クラスで定義される操作)が識別されます。たとえば、ADFタスク・フローのSummitサンプル・アプリケーションでは、customer-task-flow
のタスク・フローにより含まれるWebページを保護し、ログイン済ユーザー(認証済ユーザー)にのみアクセス権を付与します。実行時、ADFセキュリティ・フレームワークではタスク・フローのセキュリティ・ポリシーに対して認可チェックを実行して、ユーザーに表示操作を完了する権限があるかどうかを識別します。この場合、ユーザーがチェックアウト・プロセスを完了しようとする場合は、セキュリティ・ポリシーでは表示の権限をユーザーに付与する必要があります。
ユーザーとADFリソースに対してセキュリティ・ポリシーを定義するタスクを簡略化するために、ADFセキュリティではADFバインド・タスク・フローとそこに含まれるWebページに対して1つのセキュリティ・ポリシーを定義できる包含階層を定義します。つまり、バインド・タスク・フロー・レベルでセキュリティ・ポリシーを定義すると、フローのエントリ・ポイントが保護されます。次に、そのフロー内のすべてのページが、定義されたポリシーによって保護されます。また、個々のユーザーにアクセス権を付与するかわりに、ユーザーをアプリケーション・ロールにグループ化し、そのロールにview権限を付与します。
特に、Fusion Webアプリケーションで次のADFセキュリティ対応リソースのためのセキュリティ・ポリシーを定義して、ユーザーがWebページにアクセスできるようにします。
ADFバインド・タスク・フローはタスク・フローのエントリ・ポイントを保護します。エントリ・ポイントが、そのフローに含まれるページへのユーザーのアクセスを制御します。
たとえば、新規顧客に登録プロセスを説明する一連のWebページがあるとすると、バインド・タスク・フローによって、そのプロセスのページ・ナビゲーションが制御されます。バインド・タスク・フローの詳細は、「バインド・タスク・フローについて」を参照してください。
ADFバインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、認可チェックは行われません。バインドなしタスク・フローの構成ページを保護する必要がある場合は、ページに関連するページ定義ファイルの権限を定義します。
Webページに関連付けられているADFページ定義ファイルは、バインド・タスク・フローに含まれません
たとえば、Webページに売上数上位の製品の要約が表示されることがありますが、これには、そのページに関連付けられたADFページ定義ファイルのADFバインディングによって調整されたデータが使用されます。ページ定義とADFバインディングの詳細は、「ページ定義ファイルの処理」を参照してください。
ADFエンティティ・オブジェクトとエンティティ・オブジェクトの属性(データ行を参照し、ユーザー・インタフェースに表示するコレクションの定義に使用されます)
たとえば、WebページにADF Facesの表コンポーネントが表示されることがあります。これには、ADFバインディングがエンティティ・オブジェクトの属性にデータ・ソースとしてマップする列が表示されます。エンティティ・オブジェクトの場合、ADFセキュリティを有効化してもエンティティ・オブジェクト行は自動的に保護されません。エンティティ・オブジェクトまたはその属性を明示的に保護するセキュリティ・ポリシーを定義しないかぎり、ユーザーが引続きデータにアクセスできます。エンティティ・オブジェクトの詳細は、「エンティティ・オブジェクトについて」を参照してください。
JDeveloperツールではセキュリティの反復開発がサポートされるため、ADFリソースに作成するセキュリティ・ポリシーの作成、テストおよび編集が容易になります。JDeveloperでのテスト・ユーザーの作成に進み、統合WebLogic Serverでアプリケーションを実行して、保護されたリソースにエンド・ユーザーがどのようにアクセスするかをシミュレートできます。この章では、ユーザー・アイデンティティとログイン資格証明のリポジトリ(アイデンティティ・ストアと呼ばれる)を構成する方法を説明します。
注意:
この章で説明するアイデンティティ・ストアはすべて、統合WebLogic Serverでの実行を目的として作成するテスト・ユーザー・アイデンティティに関係しています。「セキュア・アプリケーションのデプロイの準備」で説明するように、Oracle WebLogic Serverにデプロイするとき、通常はこのようなユーザーをステージング環境に移行することはありません。
ADFセキュリティを有効化したが、テスト・ユーザーにアクセス権を付与するセキュリティ・ポリシーをまだ定義していないという状況を避けるため、「ADFセキュリティの構成」ウィザードでは、一時的なview権限を既存のすべてのADFリソースに付与できます(view権限が各ADFリソースのセキュリティ・ポリシーに追加されます)。ウィザードのこのオプションでは、自動付与を行わずに、各リソースの作成時にADFリソースのセキュリティ・ポリシーを定義する選択肢と、view権限を自動付与してから、セキュリティ・ポリシーを定義してその権限を1つずつ置き換える選択肢があります。セキュリティの反復開発の選択肢については、「ADFセキュリティ・プロセスの概要」で説明します。
ヒント:
ADFセキュリティを有効化し、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義する前に、ADF認可チェックの規則を理解する必要があります。この規則を理解すると、計画しているセキュリティの実装に役立ちます。これらの規則の詳細は、「ADFセキュリティのユースケースと例」を参照してください。
Fusion Webアプリケーション・リソースを保護するADFセキュリティ・モデルは、Java EEセキュリティ・モデルで使用されているセキュリティ制約のURLマッピングに基づくものではありません。実際の処理でも、セキュリティ制約はJavaServer Faces (JSF) Webアプリケーションの保護には適していません。ページ・ナビゲーションが特定のページURLでサポートされないためです。たとえば、ユーザーがタスク・フローの次のページにナビゲートしても、そのフロー内ではURLは変化しません。新しいページが表示されるときに、URLベースのセキュリティ制約をトリガーする手段がありません。
かわりに、ADFセキュリティはJava Authentication and Authorization Service (JAAS)セキュリティ・モデルを実装しています。JAASは既存のJavaセキュリティ・モデル上に構築され、すべてのJAAS実装(JAASサービスのOracle Platform Security Services (OPSS)実装も含む)と統合されるため、JAASモデルはポリシー・ベースです。URLセキュリティ制約を利用するアプリケーションがセキュリティ非対応となるのは、セキュリティを管理するためにJava EEコンテナに依存するためです。これに対して、Fusion Webアプリケーションは、ユーザー定義ポリシーに基づいてリソースへのアクセスを認可するために、ADFセキュリティ・フレームワークへの明示的なコールを必要とします。つまり、ADFセキュリティを有効化して、ADFリソースのアクセス・ポリシーを定義したときに、アプリケーションがセキュリティ対応になります。
ADFセキュリティによりJAAS認可モデルの実装が簡略化されます。この実装では、ADFリソースに対するセキュリティ・ポリシーを宣言して公開し、それらのリソースに対する認可チェックを実行時に行うことで、セキュリティ対応アプリケーションの作成に必要な作業を最小限に抑えます。
JDeveloperのポリシー・ストアはファイルベースで、ADFリソースのセキュリティ・ポリシーを定義する権限と呼ばれるエントリのリストを含みます。権限エントリには、保護対象のリソースに操作(たとえば、ADFバインド・タスク・フローに関連付けられたWebページへのアクセス)を実行するためにユーザーに付与されるすべての権限が含まれます。権限はポリシー・ストアでアプリケーション・ロール・プリンシパルに対して付与されます。
ADFセキュリティによってJAASモデルが拡張されます。ADFセキュリティ・フレームワーク権限クラスで指定されるアクションを使用して権限を定義できるようになります。このようなクラスはADFリソースに固有であり、リソースでサポートされる操作にアクションをマッピングします。Fusion Webアプリケーションのポリシー・ストアに含まれる権限では、次の項目が指定されます。
リソースの権限クラスによって定義されるアクションと、アプリケーションのADFリソース・インスタンスを関連付ける、1つ以上の権限(現在、バインド・タスク・フローとページ定義リソースでサポートされるのはview
アクションのみです)
権限の付与先として、アプリケーションによって定義されるアプリケーション・ロール(同じアクセス権を付与するメンバー・ユーザーまたはエンタープライズ・ロール(オプション)を移入します)
エンティティ・オブジェクトの場合、権限クラスはエンティティ・オブジェクトのread
、removeCurrentRow
およびupdate
操作に対応するread
、delete
およびupdate
アクションを定義します。
ADF権限クラスとサポートされるアクションの詳細は、「ADFセキュリティ権限の付与」を参照してください。
ADFセキュリティを使用すると、Webアプリケーションを現実のビジネス・セキュリティ要件に適応させやすくなります。アプリケーション・リソースへのパスを保護するのではなく、JAASによってADFリソースに対する表示操作を保護するためです。JAASベースのADFセキュリティでは次の機能が提供されます。
ADFリソース(バインド・タスク・フローなど)の宣言セキュリティのサポート
Java EEセキュリティはURLベースまたはページベースであるため、カスタム・コードなしではナビゲーションを制御できません。ADFセキュリティでは、ユーザーがタスク・フローを開始できるかどうかを制御できます。つまり、タスク・フローに対する1つのセキュリティ・ポリシーによって、複数のWebページへのアクセスを制御できます。また、宣言セキュリティではアクセス・パスではなくADFリソースを保護できるため、アプリケーションの別の場所でADFリソースを再利用するときも、保護された状態が維持されます。
権限の継承を可能にするアプリケーション・ロールを使用した権限割当ての簡略化
Java EEセキュリティ制約で使用されるJava EEセキュリティ・ロールが平面的であるのに対し、JAAS権限を付与するアプリケーション・ロールはネストすることができ、Oracle WebLogic Serverドメインが定義するエンタープライズ・ロールにマップすることもできます。
セキュリティ・コンテキストで、ADFリソースにアクセスするためにEL式で使用するユーティリティ・メソッド
ADFセキュリティのEL式ユーティリティ・メソッドを使用すると、ユーザーが既知の操作を実行できるかどうかを判定することができます。たとえば、ユーザーが特定のタスク・フローを表示できるかどうかを判定することができます。
また、JDeveloperを使用すると、統合WebLogic Serverでセキュリティをテストするためのテスト・ユーザーとパスワードをすぐに作成できます。Oracle WebLogic Serverにデプロイする準備ができたら、アプリケーション固有の認可ポリシーをサーバーに移行できます。管理者はアプリケーションがLDAPユーザー・リポジトリを使用するように構成できます。
表47-1に、ADFセキュリティの有効化がアプリケーションや様々なADFセキュリティ対応リソースに及ぼす影響をまとめています。ADFセキュリティを最も効果的に使用する方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。
表47-1 ADFセキュリティ対応リソースのサマリー
ADFリソース | ADFによるセキュリティの施行方法 | アクセス権の付与方法 |
---|---|---|
すべてのユーザー・インタフェース・プロジェクトのバインド・タスク・フロー |
デフォルトで保護されます。ユーザーがバインド・タスク・フローを開始するために権限が必要です。 |
タスク・フローの権限を定義します。 バインド・タスク・フローのWebページに関連付けられている個々のページ定義ファイルの権限は、定義しないでください。 |
すべてのユーザー・インタフェース・プロジェクトのページ定義ファイル |
デフォルトで保護されます。ページ定義に関連付けられたページをユーザーが表示するために権限が必要です。 |
Webページがバインド・タスク・フローに含まれる場合は、このタスク・フローに対する権限を定義します。 Webページがバインド・タスク・フローに含まれない場合、またはWebページがバインドなしタスク・フローに含まれる場合は、ページ定義のみの権限を定義します。 バインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、権限を定義できないことに注意してください。 |
データ・モデル・プロジェクトのエンティティ・オブジェクト |
デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。 |
データ・コレクション全体レベルでアクセスを制御する必要がある場合のみ、データを保護するためにエンティティ・オブジェクトの権限を定義します。保護対象のエンティティ・オブジェクトを参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 エンティティレベルのセキュリティは注意して使用してください。または、エンティティ属性レベルでのセキュリティの定義を検討します。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。 |
データ・モデル・プロジェクトのエンティティ・オブジェクトの属性 |
デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。 |
データ・コレクションの列レベルでアクセスを制御する必要がある場合は、データを保護するためにエンティティ・オブジェクト属性の権限を定義します。保護対象のエンティティ属性を参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。 |
Oracle ADF Securityフレームワークは、いくつかのすぐに使用できる機能を提供して、開発者がより簡単にセキュアなADFアプリケーションをコーディングできるようにしています。ADFセキュリティ設定は、アプリケーション全体のjazn-data.xmlデータ・ファイルに格納されます。
Fusion WebアプリケーションのADFリソースを保護するときはJDeveloperを使用します。ADFセキュリティでは、アプリケーションのバインド・タスク・フロー、およびバインドなしタスク・フローに含まれるすべてのWebページが保護されます。この保護を有効にするには、「ADFセキュリティの構成」ウィザードを実行し、その後、ADFセキュリティ・ポリシーを定義して各リソースのユーザー・アクセス権を定義します。
アプリケーションのユーザー・インタフェースを作成するときは、「ADFセキュリティの構成」ウィザードをいつでも実行できます。選択肢は次のとおりです。
UIプロジェクトのWebページの作成と、関連するADFリソースのセキュリティ・ポリシーの定義を繰り返しながら行います。
UIプロジェクトのすべてのWebページの作成を完了してから、関連するADFリソースのセキュリティ・ポリシーを定義します。
注意:
Fusion Webアプリケーションの保護に進む前に、「ADFセキュリティのユースケースと例」で説明されているADFセキュリティ・モデルについてよく理解する必要があります。
設計とテストの反復プロセスは、様々な設計時ツールでサポートされています。
新しいバインド・タスク・フローまたはADFページ定義ファイルをユーザー・インタフェース・プロジェクトで作成するたびに、新しいADFリソースがjazn-data.xml
ファイルの概要エディタに表示されます。このエディタは、セキュリティ・ポリシーの概要エディタとも呼ばれます。概要エディタを使用し、アプリケーション全体に関してWebページに関連付けられたADFリソースのセキュリティ・ポリシーを定義します。また、概要エディタを使用してADFリソースをソートすると、セキュリティ・ポリシーがまだ定義されていないADFリソースを簡単に見つけることができます。
ADFアイデンティティ・ストアの少数のテスト・ユーザーをプロビジョニングするには、別のエディタを使用します。JDeveloperに作成するアイデンティティ・ストアを使用して、ユーザー資格証明(ユーザーIDとパスワード)を定義できます。エディタには、作成するユーザーと、ユーザーを割り当てるアプリケーション・ロールの関係も表示され、ADFセキュリティ・ポリシーで定義されるアクセス権を付与することができます。
JDeveloperは設計時に、ポリシー・ストアとアイデンティティ・ストアのすべての変更内容をアプリケーション全体で1つのファイルに保存します。開発環境では、これはjazn-data.xml
ファイルです。エディタを使用してjazn-data.xml
ファイルを構成すると、統合WebLogic Serverでアプリケーションを実行でき、ポリシー・ストアの内容がドメインレベルのストア(system-jazn-data.xml
ファイル)に追加されます。また、テスト・ユーザーは、統合WebLogic Serverがアイデンティティ・ストアとして使用する埋込みLDAPサーバーに移行されます。ドメインレベルのストアを使用すると、作成したテスト・ユーザーとしてログオンしてセキュリティ実装をテストできます。
セキュリティに関するすべての設計時ツールは、図47-1に示すように、メイン・メニューの「アプリケーション」→「保護」メニューを使用してアクセスします。
設計フェーズ
ADFセキュリティを有効化し、JDeveloperで実行するアプリケーションに対するポリシー・ストアを設定するには:
「ADFセキュリティの構成」ウィザードを実行することにより、動的認証を許可し、認可を実施するためにADFセキュリティを有効化します。
ウィザードの実行時に動的認証のみを有効にすることを選択した場合は、残りの設計フェーズのステップはスキップします。このウィザードを使用して、Oracle WebLogic Serverでセキュリティ・フレームワークとOPSSを統合するファイルを構成します。
ADFセキュリティ対応リソースを作成します。構成Webページ(またはリージョン)を含むバインド・タスク・フロー、またはADFバインディングを使用して設計される最上位Webページ(またはリージョン)などです。
注意: 「ADFセキュリティの構成」ウィザードを実行すると、ADFセキュリティ対応リソースに関連付けられるすべてのWebページが保護されます。つまり、アプリケーションを実行してセキュリティをテストする前に、Webページをアクセス可能にするためにセキュリティ・ポリシーを定義する必要があります。
ADFセキュリティ対応リソースと、作成した1つ以上のアプリケーション・ロールを関連付けます。
作成するアプリケーション・ロールはアプリケーションに固有であり、これを使用すると、同じレベルのアクセス権を一連のユーザー(またはメンバー・ユーザー)に付与することができます。テスト・フェーズではユーザーをいくつか作成し、作成したアプリケーション・ロールのメンバーとして追加します。
ADFセキュリティ対応リソースおよび関連する各アプリケーション・ロールにview権限を付与します。
こうすることでアプリケーション・ロールのメンバー・ユーザーにアクセス権が与えられます。権限がないとユーザーはADFセキュリティ対応リソースにアクセスできません。テスト・フェーズでは、いくつかのユーザーを作成してアプリケーション・ロールに追加します。
テスト・フェーズ
統合WebLogic Serverを使用してアイデンティティ・ストアをプロビジョニングし、セキュリティをテストするには:
ユーザーをいくつか作成します。また、必要に応じてエンタープライズ・ロールを作成します。
定義したユーザーIDとパスワードを使用してアプリケーションにログインします。エンタープライズ・ロールは、ユーザーをグループ化して、そのグループにアプリケーション・ロールを関連付けるための論理ロールです。エンタープライズ・ロールはテストのためには必要ありません。詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。
作成したユーザーおよびエンタープライズ・ロール(オプション)を1つ以上のアプリケーション・ロールに関連付けます。
メンバー・ユーザー複数のアプリケーション・ロールのアクセス権を付与する必要がある場合は、1メンバー・ユーザーを複数のアプリケーション・ロールに含めることができます。
デフォルトのログイン・ページをカスタム・ログイン・ページで置き換えます(オプション)。
「ADFセキュリティの構成」ウィザードで生成されるデフォルトのログイン・ページは、ADF Facesコンポーネントを利用できません。これは、ADFセキュリティ・ポリシーのテスト用としてのみ便宜的に提供されています。カスタム・ログイン・ページは、ADF Facesコンポーネントを使用するように設計できます。
JDeveloperでアプリケーションを実行し、任意のADFセキュリティ対応リソースにアクセスします。
最初にADFセキュリティ対応リソースにアクセスしようとするとき、セキュリティ・フレームワークによってログインを求められます。
ログインし、予定どおりにページとそのリソースにアクセスできることを確認します。
ログインすると、セキュリティ・フレームワークによって、リソースにアクセスするためのユーザーの権限がチェックされます。たとえば、予期していない401未認可ユーザーのエラーを受け取った場合は、「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セキュリティの構成ウィザードでは、認証と認可を個別に有効化できます。
ADFセキュリティをOPSSに統合するための構成プロセスを単純にするため、JDeveloperでは「ADFセキュリティの構成」ウィザードが用意されています。このウィザードは、ADFセキュリティを使用してFusion Webアプリケーションを保護する開始ポイントとなります。このウィザードはアプリケーションレベルのツールなので、実行すると、アプリケーションに含まれるすべてのユーザー・インタフェース・プロジェクトでADFセキュリティが有効になります。
注意:
「ADFセキュリティの構成」ウィザードにより、アプリケーションのすべてのユーザー・インタフェース・プロジェクトに対してADFセキュリティが有効になります。このウィザードを実行した後で、バインド・タスク・フローに含まれる任意のWebページや、ADFページ定義に関連付けられたすべてのWebページを表示するための権限をユーザーに許可する必要があります。したがって、ウィザードを実行した後では、セキュリティ・ポリシーを定義してユーザーにview権限を付与するまで、アプリケーションは基本的にロックダウンされます。このプロセスの概要は、「ADFセキュリティ・プロセスの概要」を参照してください。
「ADFセキュリティの構成」ウィザードでは、認証と認可を個別に有効化することを選択できます。選択肢は次のとおりです。
ユーザー認証のみを有効化します。
ADFセキュリティでは認証にJava EEコンテナ管理のセキュリティを利用しますが、認証のみを有効化すると、ユーザーのログインとログアウトにはADF認証サーブレットを使用し、Webページの保護にはコンテナ管理のセキュリティ制約を定義することになります。
ユーザー認証を有効化し、認可も有効化します。
認可を有効化することは、ADFリソースに対してセキュリティ・ポリシーを作成することで、Fusion Webアプリケーションに対するアクセスの制御を意図することを意味します。
ADFセキュリティ・フレームワークではこれら2つの方法がサポートされるため、Java EEセキュリティを実装した上で、ADF認証サーブレットを使用したログインとログアウトに対応することができます。ADF認証サーブレットを有効化する利点は、ユーザーがアプリケーションに最初にアクセスするとき、サーブレットが自動的にユーザーにログインを求めることです。ADF認証サーブレットでも、認証が正常に終了すると、定義された開始ページにユーザーがリダイレクトされ、リクエストURLでターゲット・ページを渡す必要はありません。また、ユーザーがアプリケーションからログアウトする際にページ・リダイレクトを管理することもできます。ADFセキュリティで提供されるこのようなリダイレクト機能は、コンテナ管理セキュリティだけを使用する場合にはありません。
「実行時に行われる処理: ADFセキュリティによる認証の処理」で説明されているように、ADFセキュリティでは認証は実行されませんが、Java EEコンテナを利用して構成済のログイン・メカニズムが起動されます。
ベスト・プラクティス:
Java EEセキュリティ制約では、タスク・フローと連動してタスク・フローの現在のページを保護することはできません。このため、ADFタスク・フローを含むようにアプリケーションが設計されている場合、コンテナ管理セキュリティは効果的なソリューションではありません。ADFタスク・フローを使用する場合は、「ADFセキュリティの構成」ウィザードで「ADF認証および認可」オプションを選択します。このオプションを選択すると、セキュリティ・ポリシーを定義してアプリケーションのタスク・フローを保護できます。
ADFセキュリティはWebコンテナに認証を委任するため、「ADFセキュリティの構成」ウィザードを実行すると、ウィザードによってWebコンテナで使用する認証方式の構成を求められます。認証で最も一般的に使用されるタイプは、HTTP Basic認証とフォームベース認証です。Basic認証では、ユーザーがユーザー名とパスワードを入力できるようにブラウザのログイン・ダイアログが使用されます。Basic認証の場合、ユーザーからの資格証明がブラウザによりキャッシュされるため、ログアウトできないことに注意してください。Basic認証は、カスタム・ログイン・ページを作成しないでアプリケーションをテストする場合に便利です。フォーム認証では、アプリケーションの開発者がカスタムのログインUIを指定することができます。フォームベース認証を選択すると、ウィザードを使用して単純なログイン・ページを生成することもできます。デフォルトのログイン・ページは、統合WebLogic Serverでアプリケーションをテストするときに役立ちます。
注意:
生成されるログイン・ページは単純なJSPファイルまたはHTMLファイルであるため、ADF Facesコンポーネントを使用して変更することはできません。ADF Facesコンポーネントを使用するカスタム・ログイン・ページでデフォルトのログイン・ページを置き換える方法の詳細は、「ログイン・ページの作成」を参照してください。
始める前に:
「ADFセキュリティの構成」ウィザードの知識があると役立ちます。詳細は、「ADFセキュリティの有効化」を参照してください。
アプリケーションに対してADFセキュリティを有効化するには:
「ADFセキュリティ」ページでデフォルトの「ADF認証および認可」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、次のようになります。
ADF認証が有効化されます。ユーザーにログインを求め、ページ・リダイレクトを行います。
ADF認可チェックが有効化され、認可ユーザーのみがADFリソースにアクセスできます。
ウィザードによりセキュリティ関連の構成ファイルがすべて更新され、デフォルトでADFリソースがセキュリティ保護されます。表47-2に、ADFセキュリティの設定ウィザードにより更新されるファイルを示します。
表47-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認証サーブレットが動的に認証をトリガーできるようにします。次の例に示すように、ADF認証サーブレットのサーブレット・マッピングが定義され、2つのJava EEセキュリティ制約allPages
およびadfAuthentication
がweb.xml
ファイルに追加されます。
<servlet> <servlet-name>adfAuthentication</servlet-name> <servlet-class> oracle.adf.share.security.authentication.AuthenticationServlet </servlet-class> <init-param> <param-name>success_url</param-name> <param-value>faces/welcome</param-value> </init-param> <init-param> <param-name>end_url</param-name> <param-value>faces/welcome</param-value> </init-param> <init-param> <param-name>disable_url_param</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> ... <servlet-mapping> <servlet-name>adfAuthentication</servlet-name> <url-pattern>/adfAuthentication</url-pattern> </servlet-mapping> ... <security-constraint> <web-resource-collection> <web-resource-name>allPages</web-resource-name> <url-pattern>/</url-pattern> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>adfAuthentication</web-resource-name> <url-pattern>/adfAuthentication</url-pattern> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint>
例で示されているinit-param
要素によって定義されるサーブレット初期化属性は、ログインおよびログアウトが成功した場合のリダイレクトを制御します(それぞれsuccess_url
およびend_url
)。これらのinit-param
要素により、ログイン時およびログアウト時のリダイレクト・ターゲットがアプリケーションによって指定されない場合のデフォルトまたはフォールバック宛先が指定されます。この場合、未検証のリダイレクトの発生を防ぐ固定宛先ホワイトリストがADF認証サーブレットに定義されます。サーブレット初期化属性disable_url_param
を必要に応じてweb.xml
のサーブレットのinit-param
リストに追加して、success_url
およびend_url
がブラウザURLで渡されないようにすることで、ブラウザURL上のこれらのパラメータを利用する悪意のあるリダイレクト攻撃をある程度防止できます。このリダイレクト保護は、特にアプリケーションがAuthenticationService
APIを使用してログインおよびログアウト・リダイレクトをサポートする場合に適切に機能し、リダイレクトURLパラメータはユーザーが変更できないセッション属性として格納されます。
サーブレットのinit-param
要素disable_url_param
による保護は、選択する必要があり、デフォルトでは無効になっています。リダイレクト・パラメータをブラウザURLリクエストで渡すレガシー・アプローチを使用する既存のアプリケーションでは、disable_url_param
属性を有効にしないでください。新しいアプリケーションでは、例に示すように選択(disable_url_param
をtrue
に設定)して、success_url
およびend_url
がブラウザURLで使用されないようにすることをお薦めします。
allPages
制約は「/
」URLにマッピングされるため、Java EEアプリケーション・ルートを保護します。このマッピングにより、ADFセキュリティがアクセスされる前でも、Oracle WebLogic Serverコンテナがユーザー認証を動的にトリガーできるようになります。ユーザーがアプリケーションに最初にアクセスするときに、コンテナがユーザーにユーザー名とパスワードを求めるように強制します。その後、ユーザーがADFセキュリティで保護されたページにアクセスするときは、ユーザーを認証したりADF認証サーブレットにリダイレクトしたりする必要はありません。
注意:
ログインを明示的にトリガーするログイン・リンクまたはログイン・ボタンを用意する場合は、allPages
制約をweb.xml
ファイルから削除できます。ログアウトを実行するリンクまたはボタンも用意します。ログインとログアウトを実行するカスタム・コンポーネントの作成方法の詳細は、「ログイン・ページの作成」を参照してください。動的認証を許可するために制約を保持する場合は、Java EEアプリケーション・ルートの下位項目すべてがこの制約の対象になるため、「カスタム・ログイン・ページのリソースを明示的な認証時にアクセス可能にする方法」で説明するように、サポートするリソースが実行時にログイン・ページに表示されないことがあります。
アプリケーションのすべてのユーザーがログインできる必要があるため、adfAuthentication
リソースに定義されるセキュリティ制約を使用すると、すべてのユーザーがこのWebリソースにアクセスできるようになります。このように、制約に関連付けられるセキュリティ・ロールはすべてのユーザーを含む必要があります。このタスクを簡略化するため、Java EE valid-users
ロールが定義されています。weblogic.xml
ファイルでは、このロールが、Oracle WebLogic Serverによって定義された暗黙のusers
グループにマッピングされます。「valid-usersロールに関する必知事項」で説明するように、Oracle WebLogic Serverは、正しく認証されたすべてのユーザーをusers
グループのメンバーとして構成するため、このマッピングにより、すべてのユーザーがこのロールを持つことが保証されます。
注意:
adfAuthentication
リソース制約は、ADF認証サーブレットに対して1つの標準URLパターンの定義を提供します。このADF認証サーブレットのURLパターンを参照する明示的なログイン・リンクまたはログアウト・リンクをWebページに表示できます。この明示的なログイン・シナリオは、「ADFセキュリティの構成」ウィザードで単純なログイン・フォームを生成し、ADF認証を利用してユーザーにログインを求めるかわりに使用できます。明示的なログイン・シナリオの処理の詳細は、「ログイン・ページの作成」を参照してください。
認可を有効化するため、ウィザードはadf-config.xml
ファイルを更新し、次の例に示すように<JaasSecurityContext>
要素のauthorizationEnforce
パラメータをtrue
に設定します。
<JaasSecurityContext initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory" jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext" authorizationEnforce="true" authenticationRequire="true"/>
認可が有効化されると、ユーザーがコンテナによって認証された後で、ADFセキュリティ・コンテキストがHttpServletRequest
からユーザー・プリンシパルを取得します。ユーザーはユーザー名とパスワードを送信し、そのデータがユーザー情報が格納されているアイデンティティ・ストアのデータと比較されます。一致するデータが見つかると、要求の発信元(ユーザー)が認証されます。その後、ユーザー・プリンシパルはADFセキュリティ・コンテキストに格納され、認可権を判別するために他のセキュリティ関連情報(ユーザーが所属するグループなど)を取得する際にアクセスできます。ADFセキュリティ・コンテキストのアクセス方法の詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。
ウィザードで生成されるログイン・ページおよびエラー・ページは単純なHTMLページです。ユーザー・インタフェース・プロジェクトの最上位フォルダに追加されます。生成されるログイン・ページでは、ユーザーのログイン・リクエストを標準のj_security_check
アクションによって送信するHTMLフォームが定義されます。このアクションとフォームベース認証(ウィザードで提供されるコンテナ認証のデフォルト・オプション)を使用すると、Webコンテナでユーザーに対して様々なWebアプリケーション・リソースを認証できるようになります。
ウィザードはweb.xml
ファイルを更新し、次の例に示すように、フォームベース認証を指定してページの場所を指定します。
<login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.html</form-login-page> <form-error-page>/error.html</form-error-page> </form-login-config> </login-config>
認証されていないユーザーが保護対象のリソースにアクセスしようとすると、ウィザードで生成されたログイン・ページがサーバー側からのリダイレクトによってアプリケーションに表示されます。ログイン・ページへのリダイレクトは、ADFセキュリティ対応のリソースを含むページにユーザーが移動した場合にのみ発生するため、これは暗黙的な認証と呼ばれます。
Webアプリケーションにはパブリック・ページの概念もあり、明示的な認証と暗黙的な認証に対応します。つまり、ユーザーは保護されたコンテンツに移動する前にログイン・リンクをクリックすることによってアプリケーションにログインできるということです。ログイン・リンクの作成および使用の詳細は、「ログイン・ページの作成」を参照してください。
最初に「ADFセキュリティの構成」ウィザードを実行して認証と認可を有効にすると、アプリケーション・レベルでADFリソースが保護されます。さらに、ユーザー・インタフェース・プロジェクトについて特定のプロジェクトレベル設定(認証のタイプや認証のようこそページなど)を選択します。ウィザードによって、選択するプロジェクトのweb.xml
ファイルにWebアプリケーション設定が追加されます。アプリケーションに複数のユーザー・インタフェース・プロジェクトとweb.xml
ファイルが含まれる場合は、ウィザードに戻り、選択する別のユーザー・インタフェース・プロジェクトのweb.xml
ファイルでこれらの設定を構成します。
Java EEコンテナ管理の認証を使用するログイン用のFusion Webアプリケーションとログアウト用のADF認証は、特別な要件なしでOracle Single Sign-On (Oracle SSO)と統合されます。ADF認証サーブレットは、ログアウトの詳細を処理し、ユーザー・セッションを無効にします。ただし、アプリケーションがServlet 3.0によって提供されるログインおよびログアウトのメソッドを使用している場合、Oracle SSOはサポートされません。さらに、Servlet 3.0のログインおよびログアウトは、Java EE 6以降を完全にサポートするアプリケーション・サーバーのみと互換性があります。
ADFセキュリティ対応リソースに依存するページが最初にアクセスされたときにユーザーがまだログインしていない場合は、アプリケーション・サーバーによってセッションが作成され、ADFセキュリティの構成ウィザードの実行時にweb.xml
に構成されたJpsFilter
によってanonymous
ユーザー・プリンシパルとanonymous-role
ロール・プリンシパルを含むサブジェクトが作成されます。このロール・プリンシパルを使用すると、無名ユーザー・セッションでは、認証されていないユーザーがどのADFセキュリティ対応リソース(ADFバインド・タスク・フローまたはページ定義など)にも関連付けられていないパブリックWebページにアクセスできます。ログイン時に、WebLogic Serverは既存の無名ユーザー・セッションを無効にせず、セキュリティ上の理由により、認証されたユーザー・セッションの新しいセッションIDのみを作成します。
注意:
Fusion Webアプリケーションでは、セッションBeanが初期化されるのはセッションの確立時のみです。セッションがanonymous
として作成された場合、WebLogic Serverによって新しいセッションが作成される場合でも、セッションBeanはユーザーのログイン時に再初期化されません。これは、パブリック・ページからセキュリティ保護されたページに移動する場合です。ただし、ユーザーがセキュリティ保護されたページでアプリケーションに入る場合は、ユーザー・ログイン時にセッションBeanが初期化されます。そのため、Fusion Webアプリケーションでは、現在のユーザー・データを認証済セッションから取得するためにセッション・スコープのマネージドBeanを使用しないでください。アプリケーションで現在のユーザーを取得する正しい方法は、ADFセキュリティ・コンテキストから取得することです。ADFセキュリティ・コンテキストを扱うAPIの詳細は、「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。
ADFセキュリティ対応リソースに関連付けられているページの場合は、無名ユーザーがページにアクセスできるようにするには、view
権限をanonymous-role
に明示的に付与する必要があります。無名ユーザーへの権限付与の詳細は、「ADFリソースを公開する方法」を参照してください。
「ADFセキュリティの構成」ウィザードを使用して、アプリケーションのすべてのADFセキュリティ対応リソースのview権限を付与するために、組込みtest-all
アプリケーション・ロールへの自動付与を有効にすることができます。権限(自動view権限またはユーザー定義の明示的な権限)が付与されないと、ADFセキュリティの認可チェックの施行により、アプリケーションの実行とリソースへのアクセスを行えなくなります。test-all
アプリケーション・ロール機能を有効にしてウィザードを実行し、その後、自動view権限を明示的な権限で段階的に置き換えることができます。test-all
アプリケーション・ロールの権限が設定された状態ではアプリケーションをデプロイしないでください。この機能のためにすべてのADFリソースが公開されるためです。ウィザードで組込みtest-all
アプリケーション・ロールの有効化を選択する場合は、アプリケーションをデプロイする前に「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」を参照してください。
valid-users
ロールは、ADFセキュリティによって定義されたJava EEセキュリティ・ロールです。このロールにより、web.xml
ファイルで定義されたadfAuthentication
サーブレットWebリソースにすべてのユーザーがアクセスできることが保証されます。ADFセキュリティの構成ウィザードはweblogic.xml
ファイルを更新し、次の例に示すように、このADFセキュリティ・ロールをusers
プリンシパルにマッピングします。Oracle WebLogic Serverは、正常に認証されたすべてのユーザーをusers
グループのメンバーとして構成するため、このマッピングによりすべてのユーザーがこのロールを持ちます。
<security-role-assignment> <role-name>valid-users</role-name> <principal-name>users</principal-name> </security-role-assignment>
users
プリンシパルは、実行時に、OPSSによって、正常に認証されたサブジェクトに自動的に追加されます。セキュリティの観点から、valid-users
ロールがADF認証をサポートするのは、セキュリティ制約だけを使用してWebリソースへのアクセスを制御する必要がある場合のみです。このマッピングの最終的な結果はJava EEセキュリティに全面的に依存します。JAAS権限は関係ありません。
ADFオブジェクトに対する権限を付与するには、エンタープライズ・グループにマップされるアプリケーション・ロールを作成する必要があります。ロールを定義するには、次の2つの方法があります。これらは、アプリケーション・ロールまたはエンタープライズ・ロールとして定義できます。アプリケーション・ロールはアプリケーションにローカルで、アプリケーションで定義されたユーザーおよびロールのみ含むことができます。エンタープライズ・ロールは、ドメインにデプロイされているすべてのアプリケーションが使用できます。
アプリケーション・ロールを作成して、アプリケーションのポリシー要件を表し、同じview権限を持つユーザーのグループを定義します。アプリケーション・ポリシー・ストアに作成するアプリケーション・ロールは、お使いのアプリケーション固有のものです。たとえば、ワークフローのコンテキストでは、Application Customer Role
やApplication Employee Role
などのアプリケーション・ロールが、Summit ADFサンプル・アプリケーションのSummitADF_TaskFlows
ワークスペースで定義されていることがあります。
実行時には、ユーザーがメンバーとして定義されているアプリケーション・ロールにより、ユーザーにアクセス権が付与されます。このように、セキュリティ・ポリシーを定義する前に、権限の付与先にするアプリケーション・ロールをポリシー・ストアに含める必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Role
など)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-role
またはanonymous-role
)のいずれかでもかまいません。JDeveloperで提供される組込みアプリケーション・ロールを使用すると、「ADFリソースを公開する方法」で説明するようにADFリソースを公開できます。
アプリケーション・ロールを作成した後は、次の手順を実行します。
「ADFセキュリティ・ポリシーの定義」の説明に従って、権限をアプリケーション・ロールに付与します。
「テスト・ユーザーの作成」の説明に従って、テスト・ユーザーを各アプリケーション・ロールに関連付けます。
ベスト・プラクティス:
ADFセキュリティ・フレームワークは、アプリケーション・ロールまたは個々のユーザーに付与された権限に基づいて、ロールベースのアクセス制御メカニズムを施行します。セキュリティのテストのみを行う必要があり、ユーザー・グループを作成する必要がなくても、アプリケーション・ロール(少なくとも1ユーザー・メンバーを含む)を作成しなければなりません。後でADFリソースのセキュリティ・ポリシーを定義するとき、アプリケーション・ポリシー・ストアの概要エディタを使用して、権限に対してアプリケーション・ロールを選択できます。
JDeveloperでは、アプリケーション・ロールをjazn-data.xml
ファイルのポリシー・ストアに格納できます。これは、「アプリケーション・リソース」パネルのDescriptors/META-INFノードに表示されます。
注意:
アプリケーション・ロールを作成するときは、新しいアプリケーション・ロールをアイデンティティ・ストアではなくポリシー・ストアに追加してください。アイデンティティ・ストアに追加するロールによって、エンタープライズ・セキュリティ・ロールが定義されます。また、このロールは、アイデンティティ・ストア内のユーザーをグループ化するときに役立ちます。エンタープライズ・ロールの詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。
jazn-data.xml
ファイルのポリシー・ストアにアプリケーション・ロールを作成するには、jazn-data.xml
ファイルの概要エディタの「アプリケーション・ロール」ページを使用します。このエディタを使用すると、アイデンティティ・ストアのメンバーと、作成するアプリケーション・ロールの関係を表示できます。
始める前に:
アプリケーション・ロールについて理解しておくと役立ちます。詳細は、「アプリケーション・ロールの作成」を参照してください。
アプリケーション・ロールを作成するには:
アプリケーション・ロールをポリシー・ストアに追加すると、アプリケーション・ワークスペースを基準とするsrc/META-INF
ディレクトリにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。アプリケーション・ロールは、次の例に示すように<policy-store>
内の<app-role>
要素に定義されます。ポリシー・ストアの<application>
要素にアプリケーションが指定されるため、作成するすべてのアプリケーション・ロールは、実行時にそのアプリケーションに対してのみ有効になります。他のWebアプリケーションは、独自のアプリケーション・ロールのセットを含むポリシー・ストアを定義できます。
<policy-store> <applications> <application> <name>SummitADFTaskFlows</name> <app-roles> <app-role> <name>Application Employee Role</name> <display-name>Application Employee Role</display-name> <class>oracle.security.jps.service.policystore. ApplicationRole</class> </app-role> ... </app-roles> <jazn-policy> ... </jazn-policy> </application> </applictions> </policy-store>
エンタープライズ・ロールは、ドメインのアイデンティティ・ストア(アプリケーションのアイデンティティ・ストアではなく)で管理されるロールです。ドメインにデプロイされているすべてのアプリケーションが使用できるため、エンタープライズ・ロールは外部ロールとも呼ばれます。
アプリケーション・ロールはFusion Webアプリケーションで使用されるロールです。これはアプリケーション固有であり、アプリケーション・ポリシーで定義するものなので、Java EEコンテナで認識できるとはかぎりません。アプリケーション・ロールは、アプリケーションに定義されたユーザーとロールのみを含むという意味でスコープ指定されています。アプリケーション・ロールはエンタープライズ・ロールにマッピングする必要があります。
jazn-data.xml
ファイルの概要エディタを使用して、アイデンティティ・ストアに追加するユーザーをグループ分けするためのエンタープライズ・ロールを作成します。この仕組みを使用すると、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」で説明するように、定義したアプリケーション・ロールにすべてのユーザー・グループを割り当てて、ADFセキュリティ・ポリシーで定義されたアクセス権を付与できます。
ただし、統合WebLogic Serverでは、JDeveloper内でアプリケーションを実行するためにエンタープライズ・ロールを作成する必要はありません。アプリケーションをテストするためには、少数のテスト・ユーザーを作成して、アプリケーションに直接割り当てるだけで十分な場合があります。アプリケーションをJDeveloperで実行すると、ユーザーと定義済エンタープライズ・ロールが、デフォルトのセキュリティ・プロバイダ(統合WebLogic Serverの埋込みLDAP)に作成されます。
通常、ステージングのためにアプリケーションをデプロイするときは、ポリシー・ストアのみをターゲット・サーバーに移行します。「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、アイデンティティ・ストア(テスト・ユーザーとエンタープライズ・ロールを含む)が移行されないように、JDeveloperデプロイメント・オプションを構成できます。
セキュア・アプリケーションをデプロイすると、Oracle Fusion Middlewareはアプリケーションのポリシー・ストアをドメインレベル・ポリシー・ストアのポリシーとマージします。このタスクを完了するために、Oracle WebLogic Serverの管理者は、最終的にポリシー・ストアのアプリケーション・ロールを既存のドメインレベル・エンタープライズ・ロールにマッピングします。ドメイン・レベルでのこのようにアプリケーション・ロールをマッピングすると、定義したADFセキュリティ・ポリシーに従ってエンタープライズ・ユーザーがアプリケーション・リソースにアクセスできるようになります。また、管理者がドメインレベルでアプリケーション・ロール・マッピングを行うことにより、本番環境のアイデンティティ・ストアの知識がなくても、アプリケーションのADFセキュリティ・ポリシーを開発できるようになります。
ADFセキュリティ実装は、認証および認可という2つの主要概念から構成されます。認証は、アイデンティティ・ストアに基づいてユーザーのアイデンティティを確認し、認可は、ユーザーがポリシー・ストアでアクセス権を付与されたリソースへのアクセス権のみ持つことを確認します。
認可で利用されるポリシー・ストアは、実行時にアクセスされ、指定したオブジェクトに対する事前定義済のアクション(view
など)を実行するための権限を含みます。当初、「ADFセキュリティの構成」ウィンドウを実行した後では、ポリシー・ストアでは権限が定義されていません。また、デフォルトのウィザード・オプション「ADF認証および認可」では認可チェックが有効になるため、ADFセキュリティ対応リソースに依存するアプリケーションのWebページにユーザーはアクセスできません。ユーザーのアクセスを許可するリソースに明示的な権限を定義するには、JDeveloperを使用する必要があります。
ベスト・プラクティス:
デフォルト・オプション「ADF認証および認可」を選択して「ADFセキュリティの構成」ウィザードを実行すると、アプリケーションのWebページがロックダウンされます。指定するページのみのアクセスをユーザーに許可するように明示的な権限を定義するため、このときにFusion Webアプリケーションに最大限の保護を実現できます。このようなガイドラインの詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。
セキュリティ・ポリシーを定義するには、アプリケーションのポリシー・ストアに、権限を付与するアプリケーション・ロールが含まれる必要があります。それは、ユーザーが定義するアプリケーション・ロール(Application Customer Role
など)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-role
またはanonymous-role
)のいずれかでもかまいません。アプリケーション・ロールは、同じロールの各メンバーが同じアクセス権を持つようにユーザーを分類する目的で使用できます。このため、セキュリティ・ポリシーにより、アプリケーション・ロールには、(個別のユーザーでなく)権限のプリンシパルの名前が付けられます。アプリケーション・ロールの定義の詳細は、「アプリケーション・ロールの作成」を参照してください。
ユーザー・インタフェース・プロジェクトの場合、セキュリティ・ポリシーに対応する概要エディタを使用して、ADFタスク・フローとADFページ定義などのADFリソースをセキュリティ保護します。jazn-data.xml
ファイルのエディタを開きます。これには、jazn-data.xml
ファイル(「アプリケーション・リソース」パネル)をダブルクリックするか、メイン・メニューの「アプリケーション」メニューから「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルを開くと、テスト・ユーザー、エンタープライズ・ロールおよびアプリケーション・ロールを作成するために別のエディタ・ページが概要エディタに表示されることに注意してください。
データ・モデル・プロジェクトの場合、エンティティ・オブジェクトまたはその属性のセキュリティを保護するのに、セキュリティ・ポリシーの概要エディタは使用しません。かわりに、これらのオブジェクトにメタデータを直接設定して、データバインドUIコンポーネントがデータを表示するかどうかを管理します。行レベル・セキュリティの権限付与の詳細は、「データのポリシーを定義する方法」を参照してください。
個別のアクセス権限にかかわらず、一部のWebページをすべてのユーザーが表示できるようにするのは、一般的な要件です。たとえば、ホームページは、サイトにアクセスするすべてのユーザーに対して表示する必要がありますが、企業サイトは認証によって身元が確認されたユーザーのみに表示する必要があります。
どちらの場合も、ページを表示する権限がユーザーの特定の権限によって定義されているわけではないので、ページはパブリックであると考えられます。両者の違いは、ユーザーが匿名であるか、それとも既知のアイデンティティであるかです。
ADFセキュリティ・モデルでは、アクセス権限をanonymous-role
プリンシパルに付与することで、セキュリティの欠如とコンテンツの公開アクセスを区別します。匿名ロールは、既知のユーザーと無名ユーザーの両方を含みます。したがって、anonymous-role
に付与される権限を使用すると、認証されていないユーザー(たとえばゲスト・ユーザー)によるリソースへのアクセスを許可できます。認証済ユーザーのみにアクセスを許可するには、authenticated-role
プリンシパルにポリシーを定義する必要があります。
注意:
アプリケーション内の他のページへのリンクを含むパブリック・ホームページの作成方法の詳細は、「パブリックなようこそページの作成方法」を参照してください。
始める前に:
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、「ADFセキュリティ・ポリシーの定義」を参照してください。
次のタスクを完了する必要があります。
「タスク・フローの作成」の説明に従って、バインド・タスク・フローを作成します。
「ページ定義ファイルの処理」の説明に従って、ADFページ定義ファイルを含むWebページを作成します。
「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。
「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。
ADFセキュリティ対応リソースに対する公開アクセス権を付与するには:
セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルが更新されます。
概要エディタは、ファイルの<policy-store>
セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロール(この場合は匿名ロール)です。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。
次の例は、顧客登録タスク・フローを公開するjazn-data.xml
ファイルのセキュリティ・ポリシーを示しています。anonymous-role
に対する権限には、バインド・タスク・フローcustomer-registration-task-flow
の1つのview権限が含まれます。この権限により、すべてのユーザーが顧客登録タスク・フローを開始して顧客登録プロセスを完了できます。匿名ロールに権限を追加することもでき、匿名ロール権限の<permissions>
セクションに表示されます。
<policy-store> ... <jazn-policy> <grant> <grantee> <principals> <principal> <class>oracle.security.jps.internal.core. principals.JpsAnonymousRoleImpl</class> <name>anonymous-role</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/customer-registration-task-flow.xml# customer-registration-task-flow</name> <actions>view</actions> </permission> ... </permissions> ... </grant> ... </jazn-policy> </policy-store>
anonymous-role
およびauthenticated-role
という名前は、Oracle Platform Security Services (OPSS)によって定義される特別なロールです。
「ADFセキュリティの構成」ウィザードを実行すると、匿名ロールのサポートを有効にするJpsFilter
定義がweb.xml
ファイルに構成されます。匿名ロールを有効にすると、無名ユーザー(ログインしていないユーザー)によるサイトのブラウズがADFセキュリティによってサポートされます。反対に、認証ロールは宣言されず、デフォルトで常に識別されます。ADFセキュリティでは両方のロールがサポートされます。
エンド・ユーザーがADFセキュリティ対応リソースに最初にアクセスするとき、システムによってサブジェクトが作成され、匿名ロール・プリンシパルがそのサブジェクトに移入されます。アクセス対象のADFセキュリティ対応リソースのview権限が匿名ロールに付与されているかぎり、ユーザーのアクセスが許可されます。匿名ロールがADFリソースの権限受領者でない場合、ユーザーはログインするように求められます。ログインすると認証ロールがサブジェクトに追加されます。また、ウィザードによってJpsFilter
定義がweb.xml
ファイルに追加されます。remove.anonymous.role
はfalse
に設定され、ユーザーがログインした後でも匿名ロール・プリンシパルが使用可能になります。認証ロール・プリンシパルを使用すると、認証ロールに対して明示的に権限が付与されたリソースにユーザーがアクセスできます。
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFバインド・タスク・フローのアクセス・ポリシーを定義します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はバインド・タスク・フロー定義名)を定義します。
ベスト・プラクティス:
バインド・タスク・フローの個々のWebページに対しては権限を作成しないでください。ユーザーがバインド・タスク・フローにアクセスする場合、すべてのページのセキュリティはタスク・フローに付与する権限により管理されます。また、含まれている(ページ定義が関連付けられている) Webページにはデフォルトでアクセスできないため、ADFセキュリティではユーザーによるタスク・フローのページへの直接アクセスが禁止されます。これにより、タスク・フローの明確なセキュリティ・モデルがサポートされ、すべてのユーザーに単一エントリ・ポイントを強制します。セキュリティ・ポリシーの実装方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。
表47-3で説明するように、概要エディタで「タスク・フロー」ヘッダーの切替えボタンをクリックすると、タスク・フローをソートできます。
表47-3 バインド・タスク・フローのリソース権限切替えボタン
ボタン | 切替えアクション | 説明 |
---|---|---|
![]() |
権限のないバインド・タスク・フローの表示または非表示 |
権限が定義されていないバインド・タスク・フローを表します。タスク・フローがコールするWebページにはすべてのユーザーがアクセスできません。 |
![]() |
権限付きのバインド・タスク・フローの表示または非表示 |
1つ以上の権限が定義されたバインド・タスク・フローを表します。タスク・フローがコールするWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。 |
概要エディタに表示される、利用できるアクションのリストは、タスク・フロー権限クラス(oracle.adf.controller.security.TaskFlowPermission
)によって定義されます。権限クラスは、これらのアクションを、タスク・フローがサポートする操作にマップします。表47-4に、JDeveloperによって表示される、ADFバインド・タスク・フローに対するアクションを示します。
Fusion Webアプリケーションで現在サポートされているのはview
アクションのみです。customize
、grant
またはpersonalize
アクションを選択しないでください。これらはタスク・フロー・セキュリティで将来使用するために用意されています。
表47-4 ADFバインド・タスク・フローのセキュリティ保護されたアクション
許可できるアクション | ユーザー・インタフェースへの影響 |
---|---|
|
Fusion Webアプリケーションのバインド・タスク・フローの読取りと実行を行うユーザーを制御します。 これは、タスク・フローがサポートする唯一の動作です。 |
|
将来の使用のために予約されています。このアクションは実行時にチェックされません。 |
|
将来の使用のために予約されています。このアクションは実行時にチェックされません。 |
|
将来の使用のために予約されています。このアクションは実行時にチェックされません。 |
タスク・フロー・セキュリティ・ポリシーの権限を定義するには、jazn-data.xml
ファイルの概要エディタの「リソース権限」ページを使用します。
始める前に:
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。「ADFセキュリティ・ポリシーの定義」を参照してください。
次のタスクを完了する必要があります。
「タスク・フローの作成」の説明に従って、バインド・タスク・フローを作成します。
ベスト・プラクティス:
同じアプリケーションの別のUIプロジェクトのバインド・タスク・フローを作成している場合、一意のタスク・フロー定義名を割り当てることをお薦めします。これが必要になるのは、権限のタスク・フロー定義名がjazn-data.xml
ポリシー・ストアにパスでスコープ指定されているためです(たとえば、/WEB-INF/
mytaskflow
-definition.xml#
mytaskflow
-definition
)。したがって、権限のプロジェクトレベル・スコープを設定するには、一意の定義名でバインド・タスク・フローを作成するしかありません。
「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。
「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。
ADFバインド・タスク・フローで権限を定義するには:
セキュリティ・ポリシーの概要エディタの「リソース権限」ページで権限を作成することで、ADFページ定義のアクセス・ポリシーを定義します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はページ定義名)を定義します。
ベスト・プラクティス:
個々のWebページの権限を作成するのは、そのページがバインド・タスク・フローの構成ページでない場合のみです。ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。セキュリティ・ポリシーの実装方法の詳細は、「ADFセキュリティの操作のベスト・プラクティス」を参照してください。
表47-5で説明するように、概要エディタで「リソース」ヘッダーの切替えボタンをクリックするとWebページ定義リソースをソートできます。
表47-5 Webページ定義のリソース権限切替えボタン
ボタン | 切替えアクション | 説明 |
---|---|---|
![]() |
権限のないトップレベル・ページの表示または非表示 |
バインドなしタスク・フローに含まれるWebページに対して定義された権限がないページ定義を表します。このWebページにはどのユーザーもアクセスできません。 |
![]() |
権限付きのトップレベル・ページの表示または非表示 |
バインドなしタスク・フローに含まれるWebページに対して定義された1つ以上の権限があるページ定義を表します。このWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。 |
![]() |
バインド・タスク・フローに含まれるページの表示または非表示 |
バインド・タスク・フローにも含まれるWebページに関連付けられたページ定義を表します。このようなWebページ定義には権限を付与しないでください。かわりに、バインド・タスク・フローのセキュリティ・ポリシーを定義します。 |
![]() |
保護できないページ(ページ定義なし)の表示または非表示 |
バインドなしタスク・フローに含まれる、ページ定義が定義されていないWebページを表します。(バインド・タスク・フローに含まれる同様のページは、バインド・タスク・フローの権限によって保護されます。)Webページは、ADFセキュリティ対応リソースにより保護されていないため、すべてのユーザーによりアクセス可能です。「ADFバインドなしのページのポリシー定義に関する必知事項」で説明するように、必要に応じて、空のページ定義ファイルを追加することでページを保護できます。 |
概要エディタに表示される、利用できるアクションのリストは、リージョン権限クラス(oracle.adf.share.security.authorization.RegionPermission
)によって定義されます。権限クラスは、これらのアクションを、WebページのADFページ定義がサポートする操作にマップします。表47-6に、JDeveloperによって表示される、ADFページ定義に対するアクションを示します。
Fusion Webアプリケーションで現在サポートされているのはview
アクションのみです。
customize
、grant
またはpersonalize
アクションを選択しないでください。これらは、WebCenter Portal: Frameworkアプリケーションでのページ定義セキュリティのためだけに実装されています。
表47-6 ADFページ定義のセキュアなアクション
許可できるアクション | ユーザー・インタフェースへの影響 |
---|---|
|
ページを表示できるユーザーを制御します。 これは、ページ定義がサポートする唯一の動作です。 他のすべての操作はOracle WebCenter Portal: Frameworkをサポートしています。 |
|
カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるアプリケーション)またはWebCenter Portalアプリケーションのページに含まれるWebCenter Portalカスタマイズ可能コンポーネント(カスタマイズ可能パネルまたは「詳細フレームの表示」)に対して暗黙の変更(最小化/復元、削除または移動)を実行できるユーザーを制御します。詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』の「WebCenter Portalアセットの概要」を参照してください。 |
|
すべてのWebCenter Portal固有のアクションを組み合せて指定した権限を付与します。他のすべてのアクションの権限付与と同じです。他のユーザーに権限を付与できるユーザーや、Oracle WebCenter PortalのComposerを使用してページのセキュリティ設定を変更できるユーザーも制御します。詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』の「WebCenter Portalアセットの概要」を参照してください。 |
|
カスタム・アプリケーション(Oracle WebCenter PortalのComposerを使用できるアプリケーション)またはWebCenter Portalアプリケーションのページに含まれるWebCenter Portalカスタマイズ可能コンポーネント(カスタマイズ可能パネルまたは「詳細フレームの表示」)に対して暗黙の変更(最小化/復元、削除または移動)を実行できるユーザーを制御します。詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』の「WebCenter Portalアセットの概要」を参照してください。 |
ページ定義セキュリティ・ポリシーの権限を定義するには、セキュリティ・ポリシーの概要エディタの「リソース権限」ページを使用します。
始める前に:
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。「ADFセキュリティ・ポリシーの定義」を参照してください。
次のタスクを完了する必要があります。
「ページ定義ファイルの処理」の説明に従って、ADFページ定義ファイルを含むトップレベルWebページを作成します。
ベスト・プラクティス:
同じアプリケーションの別のUIプロジェクトのトップレベルWebページを作成している場合、一意のページ・ファイル名を割り当てることをお薦めします。これが必要になるのは、権限のページ定義がjazn-data.xml
ポリシー・ストアにパッケージでスコープ指定されているためです(たとえば、view.pageDefs.
mytoppage
PageDef
)。したがって、権限のプロジェクトレベル・スコープを設定するには、一意のファイル名でトップレベル・ページを作成するしかありません。
「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。
「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。
ADFページ定義に権限を定義するには:
アプリケーションによって定義されたADFメソッドは、コマンド・コンポーネントとしてユーザー・インタフェース内にドロップできます。デフォルトでは、メソッドのコマンド・コンポーネントが表示されたページにアクセス可能なユーザーには、このメソッドを実行する権限も与えられます。メソッド操作に対するアクセスを制限する追加のセキュリティを作成するには、リソース権限を作成し、ユーザー・インタフェース・レベルで権限をテストする必要があります。ADFセキュリティでは、ADFメソッドに対する認可チェックは行われません。アプリケーションでの認可チェックを独自に有効化する必要があります。ADFメソッドに対してユーザーに付与したリソース権限に基づき、ユーザー・インタフェースでコマンド・コンポーネントが有効化または無効化されます。
コマンド・コンポーネントとしてページに表示されるメソッドへのユーザー・アクセスを制御するには、次の手順を実行します。
リソース・タイプを作成するとマッチャ・クラスoracle.security.jps.ResourcePermission
に設定されます。これにより、アプリケーションのADFセキュリティで保護されていない部分に対して権限を付与できるようになります。たとえば、顧客への商品の出荷をユーザーが取り消すためのボタンをページに表示できます。ただし、特定のアプリケーション・ロールのメンバーのみが出荷を取り消すことができます。このルールを適用するには、実行時に宣言的にチェック可能なリソース権限をユーザー・インタフェースに作成し、ボタンを有効または無効にします。
保護対象のユーザー・インタフェース・コンポーネントに権限を作成するには、セキュリティ・ポリシーの概要エディタを使用します。
始める前に:
ADFセキュリティによるADFメソッドの処理方法について理解しておくと役立ちます。詳細は、「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。
次のタスクを完了する必要があります。
「メソッドを実行するためのコマンド・コンポーネントの作成」の説明に従い、保護対象のメソッドを実行するコマンド・コンポーネントを作成します。
「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。
「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。
カスタム・リソース・タイプに対するリソース権限を付与するには:
事前に定義されているカスタム・リソース・タイプに対してユーザーのアクセス権をチェックするEL式を定義するには、UIコンポーネントの表示プロパティで開いた「式ビルダー」ダイアログを使用します。アプリケーションを実行すると、EL式によるリソース権限評価の結果に基づき、コンポーネントが有効化または無効化されます。
たとえば、次の例に示すように、af:button#cb1
ボタンのdisabled
属性に対してuserGrantedPermission
式を定義できます。この場合、ユーザーが権限を持っているかどうかが式によってテストされ、その結果ボタンが有効化されるか、ユーザーが権限を所有していない場合はボタンが無効化されます。この式はボタンのrendered
属性に対して定義されているのではないため、ページには常にこのボタンが表示されます。
<af:button actionListener="#{bindings.myMethodName.execute}" text="myMethodName" disabled="#{!securityContext.userGrantedPermission ['resourceName=CancelShipmentButton,resourceType=CancelShipment, action=invoke']} id="cb1"/>
始める前に:
ADFメソッド認可チェックの制限について理解しておくと役立ちます。詳細は、「ADFメソッドへのユーザー・アクセスを制御するポリシーを定義する方法」を参照してください。
次のタスクを完了する必要があります。
式を使用してリソース権限をチェックするには:
セキュリティ・ポリシーを定義すると、セキュリティ・ポリシーの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルが更新されます。
概要エディタは、ファイルの<policy-store>
セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロールです。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。
次の例は、従業員登録のタスク・フローとそのタスク・フローにアクセスするために使用するトップレベルWebページに対して、認証されていないユーザーにアクセス権を付与するjazn-data.xml
ファイルのセキュリティ・ポリシーを示しています。anonymous-role
アプリケーション・ロールに対する権限には、バインド・タスク・フローemp-reg-task-flow
のview権限と、indexPageDef
ページ定義を含むWebページのview権限が含まれます。この権限によって、認証されていないユーザーは従業員登録タスク・フローに入り、ようこそページを表示できるようになります。
Webページに関しては、ようこそページ(index.jsf
)に対して作成されたindexPageDef
ページ定義に権限が定義されていることに注意してください。また、これはバインド・タスク・フローによってまだ保護されていないトップレベルWebページであることにも注意してください。
<policy-store> ... <jazn-policy> <grant> <grantee> <principals> <principal> <name>anonymous-role</name> <class>oracle.security.jps.internal.core.principals. JpsAnonymousRoleImpl</class> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/flows/emp-reg-task-flow-definition.xml# #emp-reg-task-flow-definition</name> <actions>view</actions> </permission> <permission> <class>oracle.adf.share.security.authorization.RegionPermission</class> <name>oracle.summit.view.pageDefs.indexPageDef</name> <actions>view</actions> </permission> ... </permissions> </grant> ... </jazn-policy> </policy-store>
ADFリソースに作成する権限は、標準のJAAS権限です。アプリケーションでADFセキュリティを有効化すると、Oracle WebLogic Server上で実行されているOracle Platform Security Service (OPSS)は、この権限を使用して認可を実行します。認可モードでは、ADFセキュリティは、JAAS権限で実装され、ページへのアクセス権のセキュリティ・チェックを実行する、きめ細かい認可を使用します。ADFセキュリティ施行ロジックは、JAASサブジェクトによって表現されるユーザーが、リソースにアクセスする正しい権限を持っているかどうかを確認します。
サブジェクトには、ユーザーのプリンシパル(ログオン前は無名、ログオン後はユーザー名を含むユーザー・プリンシパル)とロール・プリンシパルのリスト(authenticated-role
、ポリシー・ストアやアイデンティティ・ストアから取得されるいくつかのロールなど)が含まれます。プリンシパルは、ポリシー・ストアに定義されているアプリケーション・ロールのすべてのユーザーのメンバーシップを表すために作成されます。また、各アプリケーション・ロールには複数の権限を関連付けておくことができます。これらは、jazn-data.xml
ファイルの概要エディタで作成されるADFセキュリティ・ポリシーです。
注意:
ADFセキュリティ・ポリシーはアプリケーションごとにスコープ指定されます。このスコープで2つのアプリケーションは、意図しない結果を生じることなく、同じ権限ターゲットを参照します。ポリシー・ストア情報のアプリケーション・スコープを設定するためにアプリケーション・リソースを指定する必要はありません。
統合WebLogic Serverを使用してアプリケーションを実行する前に、テスト・ユーザーを含むアイデンティティ・ストアをプロビジョニングし、構成するアプリケーション・ロールにそれらのユーザーを追加する必要があります。「テスト・ユーザーの作成」で説明するように、アプリケーション・ロールでは、ユーザーまたはユーザー・グループ(エンタープライズ・ロール)に固有のメンバーを定義できます。
その後、実行時に、現在のユーザーがアクセスしようとしているページのview権限を持っているかどうかが、ページのコンテキストによって決まります。
ページがバインド・タスク・フローのアクティビティである場合は、タスク・フロー・コントローラによって権限が決まります。
ページが、ページ定義ファイルが関連付けられたトップレベル・ページである場合は、ADFモデル・レイヤーによって権限が決まります。
次に、Oracle Platform Security Servicesにより、ページにアクセスするために必要な権限を持つロールがサブジェクトに含まれるかどうかが確認されます。ユーザーが認可されると、タスク・フローが開始します。
バインド・タスク・フローとトップレベル・ページ(バインドなしタスク・フローで定義)の場合、ユーザーが認可されないと、ADFコントローラによって例外がスローされ、タスク・フロー構成で指定された例外ハンドラに制御が渡されます。他のエラー・ページの指定の詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。
「ADFセキュリティの構成」ウィザードのデフォルト・オプション「ADF認証および認可」では、認可チェックが有効になり、Webページが保護されます(WebページがADFセキュリティ対応リソースに関連付けられている場合)。したがって、ウィザードを実行した後で、次の両方の条件が存在するとWebページは保護されません。
ページにデータバインドADF Facesコンポーネントが表示されず、ページにADFページ定義が存在していない場合。
ページがデータバインドADFタスク・フローの構成ページでない場合。(ユーザーがバインド・タスク・フローのプロセスとしてアクセスするすべてのページは、タスク・フローの権限でチェックされます。)
「データ・コントロール」パネルを使用してWebページを設計し、データバインドされたADF Facesコンポーネントを作成するときには常に、JDeveloperによってADFページ定義ファイルが生成されます。ただし、WebページがADFバインディングを使用しない場合でも空のページ定義ファイルを作成できます。これには、ユーザー・インタフェース・プロジェクトのWebページを右クリックして、「ページ定義に移動」を選択します。このページ定義ファイルは空にしておくことができます。このページは、データバインドADF FacesコンポーネントをサポートするためにADFバインディングと連携する必要がないためです。
WebページとADFページ定義ファイル(空かどうかに関係なく)をいったん関連付けると、関連付けられたWebページにユーザーがアクセスするときに認可チェックが施行されます。他のADFページ定義と同様にページのセキュリティ・ポリシーを定義できます。空のADFページ定義に対する権限付与の詳細は、「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。
始める前に:
個々のページの定義ファイルのセキュリティについて理解しておくと役立ちます。詳細は、「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。
JDeveloperがページ定義ファイルを生成する通常の方法について理解しておくことも役立ちます。詳細は、「ページ定義ファイルでの作業」を参照してください。
セキュリティ・ポリシーを定義するために空のページ定義を作成するには:
「アプリケーション」ウィンドウで、保護するWebページを探し、ノードを右クリックして「ページ定義に移動」を選択します。
確認ダイアログで「はい」をクリックすると、ページの新しいページ定義が作成されます。
ページ定義はpageDefs
パッケージに追加されます。
一度に複数のリソースに適用する権限を定義する場合は、java.util.regex.Pattern
クラスによって定義されるパターンを作成して、実行時に評価される正規表現を生成します。たとえば、権限を一連のリソースに対応させるには、権限の名前に対して.*
(任意の文字0個以上を表す)という表現を入力できます。ADFセキュリティでは、他のセキュリティ・オブジェクト(プリンシパル名など)については正規表現を使用できません。
この機能を使用すると、次の例に示すように、同じ権限を持つバインド・タスク・フローをグループ化してWEB-INF
の専用のサブフォルダに含め、そのフォルダ全体に権限を定義できます。この場合、ピリオド(任意の文字を表す)の後にアスタリスク修飾子(0回以上を表す)を付けた正規表現を使用します。
... <grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>anonymous-role</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/.*</name> <actions>view</actions> </permission> </permissions> </grant>
jazn-data.xml
ファイルの概要エディタのユーザー・インタフェースでは、正規表現の使用がサポートされていないため、直接ファイルを編集する必要があります。system-jazn-data.xml
ファイルのポリシー・ストアを直接編集しないでください。そのかわりに、正規表現を使用してjazn-data.xml
ファイルに権限を追加します。アプリケーションを実行またはデプロイすると、これらの権限がポリシー・ストアにマージされます。
より複雑な正規表現を使用すると、ポリシーにビジネス・ルールを定義して、非常に限定的な権限のセットを作成できます。たとえば、すべてのページ定義にview権限を付与すると同時に、正規表現で除外セットを定義して特定のページ定義を除くことができます。次の例は、custom
で始まるページ定義名を除いたすべてのページに関してanonymous-role
にview権限を付与する方法を示しています。
<grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>anonymous-role</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.share.security.authorization.RegionPermission</class> <name>[^(custom)].*</name> <actions>view</actions> </permission> </permissions> </grant>
表47-7は、ポリシー定義で使用できる正規表現の基本的なメタ文字の一部を示しています。
表47-7 メタ文字の説明
メタ文字 | 説明 |
---|---|
[abc] |
a、bまたはc(リストに含まれる) |
[^abc] |
a、bまたはc以外の文字(否定) |
[a-zA-Z] |
aからzまたはAからZ、包含的(範囲) |
[a-d[m-p]] |
aからd、またはmからp~= [a-dm-p](和集合) |
[a-z&&[def]] |
d、eまたはf(積集合) |
[a-z&&[^bc]] |
aからzのうち、bおよびcを除く、つまり[ad-z](減算) |
[a-z&&[^m-p]] |
aからzのうち、mからpを除く |
.* |
任意の個数の任意の文字(この表現ではピリオドとアスタリスクを一緒に使用することに注意) |
データ・モデル・オブジェクトのADFエンティティ・オブジェクトはセキュリティ対応です。つまり、開発者が付与することのできるリソース固有の権限が事前定義されています。さらに、エンティティ・オブジェクトの個々の属性だけを保護することもできます。
セキュリティ保護の対象とするエンティティ・オブジェクトでは、UIコンポーネントがADFバインディングによってセキュアなエンティティ・オブジェクトのアクセス先データにバインドされている場合に、そのUIコンポーネントをレンダリングしているWebページに表示されるデータの、ユーザーによる更新が制限されます。さらに、エンティティ・オブジェクトをセキュリティ保護する際、そのエンティティ・オブジェクトに依存するデータ・モデル・プロジェクト内のビュー・オブジェクトも事実上保護します。そのため、セキュリティ保護するエンティティ・オブジェクトは、このビュー・オブジェクトにバインドされたUIコンポーネントに適用される、さらに広範なアクセス・ポリシーを定義します。
ADFエンティティ・オブジェクトを使用して行データを保護するには:
データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクトによって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。
概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission
)によって定義されます。権限クラスは、エンティティ・オブジェクトでサポートされる操作をアクションにマップします。表47-8は、エンティティ・オブジェクトの、セキュア化できる操作を示しています。
表47-8 ADFエンティティ・オブジェクトのセキュア化可能な操作
セキュアな操作 | 想定されるマップされたアクション | 対応する実装 |
---|---|---|
|
|
|
|
|
バインドされたコレクションの属性を更新します。 |
|
|
バインドされたコレクションの1つの行を削除します。 |
注意:
read
操作やupdate
操作とは異なり、delete
アクションにマップされるセキュア化可能な操作は、一意識別子removeCurrentRow
で定義されます。Fusion Webアプリケーションの認可チェックはアクション名ではなく操作名に依存するため、delete
権限名ではなくremoveCurrentRow
操作名をテストする必要があります。エンティティ権限をテストできるようにするエンティティ行APIおよびEL式の詳細は、「エンティティ・オブジェクト操作の認可チェックの実行方法」を参照してください。
エンティティ・オブジェクトがアクセスするすべての行レベル・データを保護するには、エンティティ・オブジェクト用の概要エディタを使用します。
始める前に:
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。
次のタスクを完了する必要があります。
エンティティ・オブジェクトに対する操作をセキュア化する手順:
データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクト属性によって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。
概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission
)によって定義されます。権限クラスは、エンティティ・オブジェクト属性でサポートされる操作をアクションにマップします。表47-9は、エンティティ・オブジェクト属性の、保護可能な操作を示しています。
表47-9 ADFエンティティ・オブジェクト属性のセキュア化可能な操作
セキュアな操作 | 想定されるマップされたアクション | 対応する実装 |
---|---|---|
|
|
バインドされたコレクションの特定の属性を更新します。 |
エンティティ・オブジェクトがアクセスするデータの個々の列を保護するには、エンティティ・オブジェクト用の概要エディタの「属性」ページを使用します。
始める前に:
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。
次のタスクを完了する必要があります。
エンティティ・オブジェクト属性に対する操作をセキュア化する手順:
権限ターゲットが構成されても、エンティティ・オブジェクトの権限ターゲットに対してポリシー権限が明示的に定義されるまで、エンティティ・オブジェクトあるいはその属性から導出されるデータは、セキュリティ保護されないままです。
既存のエンティティ・オブジェクトまたはエンティティ属性の権限ターゲットに対するアクセス・ポリシーを定義するには、セキュリティ・ポリシーの概要エディタを使用します。
始める前に:
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「データのポリシーを定義する方法」を参照してください。
次のタスクを完了する必要があります。
「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。
「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。
「ADFエンティティ・オブジェクトに対する権限マップの定義」の説明に従って、エンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について権限ターゲットを定義します。
エンティティ・オブジェクトまたはエンティティ属性のアクセス・ポリシーを定義するには:
リソース権限を作成することで、セキュア化できる個々のOracle ADFアーティファクトに対するエンド・ユーザーのアクセス権を定義します。しかし、管理とメンテナンスを容易にするため、リソース権限を資格付与として定義することもできます。こうすると、セキュア化可能な複数のアプリケーション・アーティファクトが1つの名前付きセキュリティ・グループとして集約され、これを1つの文によってアプリケーション・ロールに付与できます。たとえば、ADFビジネス・コンポーネント・エンティティ・オブジェクトによってアプリケーション内で公開されるデータへのアクセスを認可しようとする場合、複数のエンティティ・オブジェクトに対して同一のセキュリティ・ポリシーが必要になる可能性があります。各エンティティ・オブジェクトに対してアクセス権限を個別に付与するのではなく、これらの権限を1つの資格としてグループ化し、一括して付与できます。
セキュリティ・ポリシーの概要エディタの「資格付与」ページで、資格付与を作成します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、選択したリソース・インスタンスとアクションとのペアで構成される1つの資格(XML定義では<permission-set>
として識別されます)を定義します。この資格は付与可能なエンティティであり、アプリケーション・ロールに付与できます。
セキュリティ・ポリシーの概要エディタには、リソース・タイプのリストが表示されます。選択したリソース・タイプにより、アプリケーション・ワークスペースのプロジェクト内で定義されたリソース・インスタンスがフィルタ処理されます。また、選択したリソース・タイプにより、概要エディタに表示される使用可能なアクションのリストが決定されます。たとえば、リソース・タイプタスク・フロー権限を選択した場合、概要エディタには、選択したユーザー・インタフェース・プロジェクト内のすべてのタスク・フローが表示されます。また、viewアクションも表示され、これを使用可能なADFバインド・タスク・フロー・リソースに関連付けることができます。
表47-10は、JDeveloperで表示されるリソース・タイプのリストと、各タイプに対して関連付けられるリソースおよびサポートされるアクションを示します。
表47-10 セキュア化できるOracle ADFアーティファクトのリソース・タイプ
リソース・タイプ | サポートされるリソースおよびアクション |
---|---|
|
選択したユーザー・インタフェース・プロジェクト内のADFバインド・タスク・フローに対してviewアクションを定義します。 |
|
選択したユーザー・インタフェース・プロジェクト内のADFページ定義ファイルに基づくリージョンおよびWebページに対してviewアクションを定義します。 |
|
選択したデータ・モデル・オブジェクト内のエンティティ・オブジェクトに対してread、updateおよびdeleteアクションを定義します。 |
|
選択したデータ・モデル・オブジェクト内の特定のエンティティ・オブジェクトのエンティティ・オブジェクト属性に対してupdateアクションを定義します。 |
セキュア化できるOracle ADFアーティファクトに対して資格付与を定義するには、セキュリティ・ポリシーの概要エディタの「資格付与」ページを使用します。
始める前に:
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、「リソース権限を資格付与として集約する方法」を参照してください。
次のタスクを完了する必要があります。
「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。
Oracle ADFアーティファクトに対して資格付与を定義するには:
JDeveloperのセキュリティ・ポリシー・エディタを使用して資格を作成すると、JDeveloperはjazn-data.xml
ファイル内で、アプリケーション・ポリシー・ストアのソースを修正します。ファイルのポリシー・ストア・セクションには、<resource-type>
定義(選択したリソース・タイプに対してサポートされるアクションを識別)、<resource>
定義(アプリケーションから選択してリソース・タイプにマッピングしたリソース・インスタンスを識別)、<permission-set>
定義(1つの資格として付与されるリソースおよびアクションを定義)、および<grant>
定義が含まれ、1つ以上の資格(XML内で権限セットとして定義)が目的のアプリケーション・ロール(権限受領者)に付与されます。
次の例に示すように、Oracle Fusionアプリケーションにおける資格ベースのセキュリティ・ポリシーは、<jazn-policies>
要素内で定義され、単一のアプリケーション・ロールに付与される1つ以上の資格によって構成されます。
<?xml version="1.0" ?> <jazn-data> <policy-store> <applications> <application> <name>MyApp</name> <app-roles> <app-role> <name>AppRole</name> <display-name>AppRole display name</display-name> <description>AppRole description</description> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> <class>oracle.security.jps.service.policystore.ApplicationRole</class> </app-role> </app-roles> <role-categories> <role-category> <name>MyAppRoleCategory</name> <display-name>MyAppRoleCategory display name</display-name> <description>MyAppRoleCategory description</description> </role-category> </role-categories> <!-- resource-specific OPSS permission class definition --> <resource-types> <resource-type> <name>APredefinedResourceType</name> <display-name>APredefinedResourceType display name</display-name> <description>APredefinedResourceType description</description> <provider-name>APredefinedResourceType provider</provider-name> <matcher-class>oracle.security.jps.ResourcePermission</matcher-class> <actions-delimiter>,</actions-delimiter> <actions>write,read</actions> </resource-type> </resource-types> <resources> <resource> <name>MyResource</name> <display-name>MyResource display name</display-name> <description>MyResource description</description> <type-name-ref>APredefinedResourceType</type-name-ref> </resource> </resources> <!-- entitlement definition --> <permission-sets> <permission-set> <name>MyEntitlement</name> <display-name>MyEntitlement display name</display-name> <description>MyEntitlement description</description> <member-resources> <member-resource> <type-name-ref>APredefinedResourceType</type-name-ref> <resource-name>MyResource</resource-name> <actions>write</actions> </member-resource> </member-resources> </permission-set> </permission-sets> <!-- Oracle function security policies --> <jazn-policy> <!-- function security policy is a grantee and permission set --> <grant> <!-- application role is the recipient of the privileges --> <grantee> <principals> <principal> <class> oracle.security.jps.service.policystore.ApplicationRole </class> <name>AppRole</name> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> </principal> </principals> </grantee> <!-- entitlement granted to an application role --> <permission-set-refs> <permission-set-ref> <name>MyEntitlement</name> </permission-set-ref> </permission-set-refs> </grant> </jazn-policy> </application> </applications> </policy-store> </jazn-data>
テストの目的で、ADFセキュリティではjazn-data.xmlファイルにユーザーを作成することを開発者に許可します。
JDeveloperで提供されるエディタを使用して、アイデンティティ・ストアとポリシー・ストアの両方を作成できます。アプリケーション固有のjazn-data.xml
ファイルに両方のリポジトリを作成します。ファイルのアイデンティティ・ストア・セクション用のエディタでは、有効なユーザーIDと割り当てられたパスワードのリストを入力できます。同じエディタを使用して、アプリケーション・ロールを作成し、アプリケーション・ロールのメンバーとしてテスト・ユーザーまたはエンタープライズ・ロールを割り当てることができます。定義されると、この情報はjazn-data.xml
ファイルのポリシー・ストア・セクションに表示されます。
アプリケーションのアイデンティティ・ストアに一時的なユーザーのセットを生成して、本番環境での実際のユーザーの体験をシミュレートします。統合WebLogic Serverでアプリケーションを実行すると、任意のテスト・ユーザーとしてログインでき、アプリケーションのセキュアADFリソースを表示するアクセス権を与えられます。
アイデンティティ・ストアを使用すると、エンタープライズ・ロールにユーザーをグループ分けすることができます。通常は、JDeveloperのデプロイメント・オプションを構成して、アイデンティティ・ストアをステージング環境に移行しないようにするため、jazn-data.xml
ファイルに作成するエンタープライズ・ロールは便宜上のものです。エンタープライズ・ロールの使用方法の詳細は、「エンタープライズ・ロールとアプリケーション・ロールに関する必知事項」を参照してください。
注意:
アイデンティティ・ストアのスタンドアロン・サーバーへのデプロイを選択する場合、Oracle WebLogic Serverに対してすでに構成されているローカル・アイデンティティ・ストアにユーザーとエンタープライズ・ロールを作成しないでください。たとえば、ユーザーweblogic
とエンタープライズ・ロールAdministrators
を含むアイデンティティ・ストアをデプロイする場合は、ターゲット・サーバーのデフォルト管理構成を上書きします。Oracle WebLogic Serverによってデフォルトでインストールされるグローバル・ロールの完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・ロール」の章を参照してください。
ユーザーがリソースを表示できるようにするには、そうしたロールのメンバーであるユーザーではなく、アプリケーション・ロールに対して権限を付与します。したがって、アイデンティティ・ストアにテスト・ユーザーを生成した後で、各ユーザーまたはエンタープライズ・ロール・グループをアプリケーション・ロールに関連付ける必要があります。この関連付けにより、ADFセキュリティ・ポリシーによって定義されたアクセス権がユーザーに付与されます。アクセス権のユーザーへの付与の詳細は、「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」を参照してください。
Oracle WebLogic Serverに対してすでに構成されているユーザー名を選択しないでください(たとえば、webcenter
は入力しないでください)。Oracle WebLogic Serverによりインストールされているユーザー名のリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループおよびセキュリティ・ロール」の章を参照してください。
始める前に:
アイデンティティ・ストアについて理解しておくと役立ちます。「テスト・ユーザーの作成」を参照してください。
テスト・ユーザーおよびグループを作成するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「テスト・ユーザーとロール」を選択します。
セキュリティ・ポリシーの概要エディタの「テスト・ユーザーとロール」ページで、「レルム」ドロップダウン・リストからアプリケーションのレルムを選択して、次の手順を実行します。
JDeveloperでは、レルムjazn.com
がデフォルトで使用されます。
「ユーザー」リストで「新規ユーザー」アイコンをクリックします。
「名前」フィールドにユーザー名を入力します。
「パスワード」フィールドにユーザーのパスワードを入力します。他の任意のフィールドをクリックすると、パスワードがアイデンティティ・ストアに追加されます。
パスワードは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つ以上のメンバー・ユーザーが含まれます。
次の例は、2つのユーザーと2つのエンタープライズ・ロールを含むjazn-data.xml
ファイルのアイデンティティ・ストアを示しています。ユーザーcmagee
はEnterprise Employee Group
エンタープライズ・ロールのメンバーで、ユーザー214
はEnterprise Customer Group
エンタープライズ・ロールのメンバーです。
<jazn-data> <jazn-realm default="jazn.com"> <realm> <name>jazn.com</name> <users> <user> <name>cmagee</name> <display-name>Colin Magee</display-name> <description>Sales Rep</description> <credentials>{903}5AUHlE+qvDxxAhxIMoXJ/WLhMF0ynue7</credentials> </user> <user> <name>214</name> <display-name>Ojibway Retail</display-name> <description>Customer</description> <credentials>{903}rijN2KQCBSeBQ/JNZlv8GwwUiGWk5IQa</credentials> </user> ... </users> <roles> <role> <name>Enterprise Employee Group</name> <members> <member> <type>user</type> <name>cmagee</name> </member> </members> </role> <role> <name>Enterprise Customer Group</name> <members> <member> <type>user</type> <name>214</name> </member> ... </members> </role> ... </roles> </realm> ... </jazn-realm> </jazn-data>
ADFセキュリティ・フレームワークは、アプリケーション・ロールに付与された権限を使用するロールベースのアクセス制御メカニズムを施行するため、アプリケーション固有の一連のロールをポリシー・ストアに定義します。たとえば、ワークフローのコンテキストでは、顧客、製品担当、監督者、管理者などのロールを想定できます。
アプリケーション・ロールを作成したら、アイデンティティ・ストアに作成したユーザーに1つ以上のロールを関連付けることができます。アプリケーション・ロールのメンバーであるユーザーには、実行時にアプリケーション・ロールのアクセス権が付与されます。複数のリソース権限を特定のユーザーに付与する場合は、1ユーザーを複数のアプリケーション・ロールに割り当てることができます。
たとえば、認証された1ユーザーがスーパーバイザ・ロールと従業員ロールに所属し、別の1ユーザーは従業員ロールのみに所属する場合があります。顧客レコードのブラウズと編集を許可するバインド・タスク・フローのセキュリティ・ポリシーでは、スーパーバイザ・ロールにview権限が与えられますが、従業員ロールにはブラウズ・ページのview権限に制限されます。このように、アプリケーション・ロールへの権限付与により複数レベルのアクセスに対応します。認証されたユーザーが、ターゲットADFリソースのview権限を持つアプリケーション・ロールのメンバーでない場合は、ユーザーが認証されていないというメッセージがセキュリティ・フレームワークによって返されます。
始める前に:
アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、「テスト・ユーザーの作成」を参照してください。
次のタスクを完了する必要があります。
「ADFセキュリティの有効化」の説明に従って、ADFセキュリティの構成ウィザードを実行します。
「アプリケーション・ロールの作成」の説明に従って、アプリケーション・ロールを作成します。
「ADFセキュリティ・ポリシーの定義」の説明に従って、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義します。
「JDeveloperでテスト・ユーザーを作成する方法」の説明に従って、テスト・ユーザーを作成し、必要に応じてエンタープライズ・ロール・グループを作成します。
ユーザーをアプリケーション・ロールに関連付けるには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。
セキュリティ・ポリシーの概要エディタの「アプリケーション・ロール」ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。
JDeveloperによってjazn-data.xml
ファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。
「ロール」リストで既存のアプリケーション・ロールを選択し、必要に応じて次のタスクを実行します。
「マッピング」セクションで、「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「ユーザーの追加」を選択します。次に、「ユーザーの選択」ダイアログで、前に作成したユーザーをリストから選択して「OK」をクリックします。
アイデンティティ・ストアにエンタープライズ・ロールを定義している場合、必要であれば、「マッピング」セクションで「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「エンタープライズ・ロールの追加」を選択します。次に、「エンタープライズ・ロールの選択」ダイアログで、前に作成したエンタープライズ・ロールをリストから選択して「OK」をクリックします。
ユーザーにアプリケーション・ロールを関連付けると、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。
ダイアログによって、ファイルの<policy-store>
セクションにユーザー情報が書き込まれます。各アプリケーション・ロールには1つ以上のメンバー・ユーザーまたはエンタープライズ・ロールが含まれます。
次の例は、Enterprise Employee Group
とEnterprise Manager Group
という2つのメンバーが含まれている、Application Employee Role
アプリケーション・ロールを持つjazn-data.xml
ファイル内のポリシー・ストアを示しています。
<policy-store> <applications> <application> <name>SummitADF</name> <app-roles> <app-role> <name>Application Employee Role</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <display-name>Application Employee Role</display-name> <members> <member> <class>oracle.security.jps.internal.core.principals. JpsXmlEnterpriseRoleImpl</class> <name>Enterprise Employee Group</name> </member> <member> <class>oracle.security.jps.internal.core.principals. JpsXmlEnterpriseRoleImpl</class> <name>Enterprise Manager Group</name> </member> ... </members> </app-role> ... </app-roles> <jazn-policy> ... </jazn-policy> </application> </applictions> </policy-store>
暗黙の認証と明示的な認証の両方がADFセキュリティでサポートされます。ログイン・リンク、ログイン・ページ、ようこそページを作成でき、その他の様々なアクションを実行できます。
ADFセキュリティでは、暗黙的認証および明示的認証を使用できます。
暗黙的な認証のシナリオでは、未認証のユーザーがアクセスしようとするWebページが、anonymous-role
に権限付与されていないADFセキュリティ対応リソースに関連付けられている場合、認証が動的にトリガーされます。ユーザーが正常にログインすると、認証されたユーザーが、リクエストしたページのADFセキュリティ対応リソースに対するviewアクセス権を付与されているかどうかを検証するために別のチェックが実行されます。
明示的な認証のシナリオでは、ログイン・リンクが表示された公開ページがアプリケーションに用意され、このリンクをクリックすると、そのユーザーのログインにおいて認証チャレンジがトリガー実行されます。ログイン・リンクには、認証が成功した後に表示するいくつかの他のターゲット・ページ(認証済ユーザーがアクセス権を持っている場合)を指定できます。
「ADF認証に関する必知事項」で説明したように、暗黙的および明示的な認証のシナリオは、ADFセキュリティの構成ウィザードを実行するとデフォルトで処理されます。ただし、デフォルトの生成済ログイン・ページをカスタマイズ(または独自のページを指定)してADF Facesコンポーネントを使用する場合は、コンテナ管理デプロイメント・ディスクリプタ(web.xml
ファイル)を構成する必要があります。
ユーザー認証を明示的に処理するには:
ログイン・リンク・コンポーネントを作成し、アプリケーションのパブリック・ホームページに追加します。
Servlet 3.0固有のAPIを使用して、ユーザーによるログインの試行を処理するマネージドBeanを作成します。
ADF Facesコンポーネントを使用して、JSFログイン・ページを作成します。
ログイン・ページのリソースがアクセス可能であることを確認します。
暗黙的な認証と明示的な認証の詳細は、「実行時に行われる処理: ADFセキュリティによる認証の処理」を参照してください。
アプリケーションのどのページにも追加できる標準的なログイン・リンク・コンポーネントを作成して、ユーザーの認証または以降のログオフができます。このコンポーネントは、ユーザーの認証状態を追跡し、適切なログインまたはログアウトのURLおよびアイコンを戻します。このログイン・リンク・コンポーネントは、ユーザーの認証後、ユーザーを特定のページにリダイレクトします。したがって、このログイン・リンク・コンポーネントを使用すると、一貫性のある単一のオブジェクトを得られます。
認証されていないユーザーに対しては、ログイン・リンク・コンポーネントは図47-16のように表示されます。
図47-16 ユーザーがログインする前のコンポーネント
その後、ユーザーがログイン・リンクをクリックして、適切な資格証明を持つユーザーとしてログインすると、コンポーネントは図47-17のようになります。
図47-17 ユーザーがログインした後のコンポーネント
始める前に:
ADF認証について理解しておくと役立ちます。詳細は、「ログイン・ページの作成」を参照してください。
次のタスクを完了する必要があります。
public_html
ディレクトリにコピーします。注意:
アプリケーションでスキンを使用する場合は、使用されるイメージは適切なスキン・イメージを参照している必要があります。スキンの詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の「スタイルおよびスキンを使用した外観のカスタマイズ」の章を参照してください。
ログイン・リンク・コンポーネントを作成してページに追加するには:
「ADFセキュリティの構成」ウィザードを実行して生成されるデフォルトのログイン・フォームは、JDeveloperでアプリケーションをテストする際に利用できるように提供されます。デフォルトのフォームでは、アプリケーションのユーザー・インタフェースに合せて、ADF Facesコンポーネントを使用してページをカスタマイズすることはできません。図47-19に示すように、カスタマイズ可能なコンポーネントを組み込めるADF Facesベースのログイン・ページによって、デフォルトのフォームを置き換えることができます。
図47-19 ログイン・ページ
ただし、ADF Facesコンポーネントを含むログイン・ページの設計が要件でない場合は、単純なJSPまたはHTMLのログイン・ページを使用することもできます。ADFセキュリティの構成ウィザードの実行時に単純なログイン・ページを生成する方法の詳細は、「ADFセキュリティを有効化する方法」を参照してください。
ADF Facesページとしてログイン・ページを作成する前に、ログインの試行を処理するマネージドBeanを作成する必要があります。このログインBeanの例では、Servlet 3.0固有のAPIを使用し、プログラムによって認証が処理されます。ログインBeanは、doLogin()
メソッドによって、ログイン・リンクから開始されたログイン・アクションを処理します。ログインが成功すると、このメソッドはサーブレットAPIを起動してランディング・ページにリダイレクトします。このBeanをadfc-config.xml
ファイルに追加し、request
スコープで登録します。
注意:
この項で説明するこのバッキングBeanの例では、Oracle Single Sign-On (Oracle SSO)による認証は行われません。このバッキングBeanは、Servlet 3.0によって提供されるログインおよびログアウト・メソッドを使用して認証を処理しています。Servlet 3.0は、Java EE 6以降をサポートするアプリケーション・サーバー上のプログラムによるログインを汎用的にサポートしています。
始める前に:
ログイン・ページの知識があると役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。
次のタスクを完了する必要があります。
ログインのためのバッキングBeanを作成して登録する手順:
ADF Facesレイアウト・コンポーネントおよびADF Facesユーザー・インタフェース・コンポーネントを利用する単純なログイン・ページには、2つの入力フィールドと1つのボタンが含まれます。これらのUIコンポーネントのプロパティを、ログイン・ページのマネージドBeanに定義したログイン・ハンドラ・メソッドにバインドする必要があります。
この手順で作成できるページでは暗黙的な認証はサポートされないことに注意してください。暗黙的な認証を実装する場合には、コンテナ管理の認証をサポートする、デフォルトのウィザードにより生成されたログイン・フォームをカスタマイズできます。Java EEコンテナでは、ユーザーにより送信されたj_username
およびj_password
入力を処理するためにj_security_check
メカニズムに依存するフォームを使用します。ここで説明する明示的な認証シナリオでは、Java EEコンテナ管理の認証は使用しません。
始める前に:
明示的認証について理解しておくと役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。
次のタスクを完了する必要があります。
明示的な認証用の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」ノードの下にドロップします(図47-21)。
「共通コンポーネント」ウィンドウから、ユーザー名フィールド用に「入力テキスト」をドラッグして「パネル・フォーム・レイアウト」ノードにドロップし、パスワード・フィールド用にもう1つの「入力テキスト」をドラッグ・アンド・ドロップします。
入力フィールドの「プロパティ」ウィンドウで、「ラベル」フィールドにUsername
とPassword
を入力し、「動作」セクションを開き、両方のフィールドの「必須」ドロップダウン・リストから「true」を選択します。
「プロパティ」ウィンドウで、パスワード・フィールド用に、「外観」セクションを開き、「機密」ドロップダウン・リストから「true」を選択します。
2つの入力フィールドの値を処理するために、各フィールドで次の手順を実行します。
「構造」ウィンドウで、入力フィールドの1つを選択し(たとえば「af:inputText - Username」ノードを選択)、「プロパティ」ウィンドウで「値」フィールドの横にある「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、Beanのハンドラ・メソッドに対応する式の値を選択します。
たとえば、「構造」ウィンドウでusername入力フィールドを選択した場合は、図47-22のように「式ビルダー」ダイアログでusernameを選択します。
「OK」をクリックします。
「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにフィールドがバインドされます。たとえば、username入力フィールドの場合、式は#{loginPageBean.username}
のようになります(図47-23)。
「コンポーネント」ウィンドウで、「レイアウト」パネルから「パネル枠線レイアウト」をドラッグして、af:panelBoxノードのfooterノードの内側にドロップします(図47-24)。
JSP/HTMLビジュアル・エディタで、ラベルが「端」、「上」および「下」のパネル枠線レイアウト・ファセットを削除します。「開始」ファセットのみを残します。
「構造」ウィンドウで、「パネル枠線レイアウト」ファセットを開いて、「開始」ノードを選択し、「コンポーネント」ウィンドウから「ボタン」をドラッグ・アンド・ドロップします。
「プロパティ」ウィンドウで、ボタン・コンポーネントの「テキスト」フィールドにLogin
を入力します。
ログイン・ボタンのアクションを処理するには、次の手順を実行します。
「構造」ウィンドウで「開始」ノードにある「af:button」を選択し、「プロパティ」ウィンドウで「アクション」フィールドの横の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、ログイン・メソッドに対応する式の値を選択します。
たとえば、ログインBeanにdoLogin()
という名前のメソッドを作成した場合は、「式ビルダー」ダイアログでdoLoginを選択します。
「OK」をクリックします。
「プロパティ」ウィンドウに表示される式により、ログイン・ページのために作成したマネージドBeanにボタンがバインドされます。たとえば、ログイン・ボタンの場合、式は#{loginPageBean.doLogin}
のようになります(図47-25)。
ページを保存します。
アプリケーションはADFセキュリティによって保護されるため、デフォルトでは、バインド・タスク・フローに定義されたすべてのWebページ、およびADFページ定義によって定義されたすべてのWebページにはアクセスできません。すべてのユーザーがログオンできるようにする必要があるため、ログイン・ページは公開する必要があります。このため、ログイン・ページにはデータバインド・コンポーネントを追加しないでください。ログイン・ページでデータバインド・コンポーネントが使用されないかぎり、このページにはデフォルトでアクセスできます。
コンテナがページ(この場合は認証ページ)へのアクセスを許可する前に、定義済の認証ポイントに常にリダイレクトすることを保証するには、これ以上の手順は必要ありません。
「ADFセキュリティの構成」ウィザードを実行して、「ADF認証」オプションを選択したとき(ADF認可を有効にしない)、アプリケーションがカスタム・ログイン・ページまたはカスタム・エラー・ページを使用していると、場合によってはADFセキュリティでweb.xml
ファイルに追加されたデフォルトのJava EEセキュリティ制約を編集する必要があります。次の例に示すように、allPages
セキュリティ制約に定義されるデフォルトのURLパターン(/*
)は、Java EEアプリケーション・ルートの下位項目すべてに対応し、ログイン・ページに使用される各リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)もこれに含まれます。
<security-constraint> <web-resource-collection> <web-resource-name>allPages</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint>
作成するページがリソース(イメージ、CSSファイルまたはJavaScriptライブラリなど)を使用する場合、web.xml
ファイルのデフォルトのallPages
セキュリティ制約により、そのようなリソースが実行時にロードされなくなります。アプリケーションでそれらのリソースを表示するためには、リソースを独自のフォルダに保存し、そのリソース・フォルダがURLパターンに含まれないようにallPages
セキュリティ制約を編集する必要があります。
「ADFセキュリティの構成」ウィザードを実行して、「ADF認証および認可」オプション(デフォルト)を選択した場合は、このようなリソースの問題が生じないことに注意してください。特に、この場合にデフォルトで生成される制約がADF認証サーブレットに対応し、制約(/adfAuthentication
)によってすべてのリソース・ファイルが除外されます。
Webアプリケーションは通常は保護されているため、認証されていないユーザーのための開始地点すなわちホームページが必要になります。このようなパブリックなようこそページを作成するには、アプリケーション内の他のページへのリンクを含み、アプリケーションの開始地点として機能するADF Facesページを作成します。ただし、認証されていないユーザーに対してはパブリック・ページへのリンクしかレンダリングできません。反対に、セキュア・ページへのリンクをレンダリングするのは、ユーザーがログインし、ターゲット・ページを表示する適切な権限を持っている場合のみです。
ベスト・プラクティス:
ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して、新しいブラウザ・ウィンドウまたはタブを開いたとき、アプリケーションのweb.xml
ファイルにようこそページが定義されていないと、ブラウザに403エラーまたは404エラーが表示されます。このエラーを防ぐためには、ようこそページの定義をアプリケーションのweb.xml
ファイルに指定する必要があります。この定義は、「ADFセキュリティの構成」ウィザードを実行して作成できます。このウィザードの実行方法の詳細は、「ADFセキュリティを有効化する方法」を参照してください。
標準のADF Facesページを作成すると、ページはデフォルトでパブリックになり、認証されていないユーザーがアクセスできます。ただし、ようこそページをADFリソースに関連付けた場合(「データ・コントロール」パネルを使用してデータバインドADF Facesコンポーネントをようこそページにドラッグ・アンド・ドロップするなど)、ADFセキュリティによってデフォルトでページが保護されます。セキュリティ・ポリシーの概要エディタを使用して、提供されているanonymous-role
にADFリソースのview権限を付与すると、任意のADFリソースを公開できます。anonymous-role
の詳細は、「ADFリソースの公開時の処理」を参照してください。
ログイン・リンクやログアウト・リンクをパブリックのようこそページに追加して、ログインやアプリケーション使用中のログアウトをユーザーが明示的に行えるようにします。Java EEコンテナ管理セキュリティでは、保護されているリソースにアクセスする際に認証の概念がサポートされますが、ログアウトした後も保護されたアプリケーションにとどまる標準の方法はありません。ただし、一般的なWebアプリケーションの場合、ページがパブリックであれば、ユーザーは同じページにとどまります。あるいは、ページが保護されている場合はようこそページが再び表示されます。各ページにログイン・リンクとログアウト・リンクを追加すると、ユーザーがアプリケーション内の任意の場所でログイン・セッションを終了できます(ようこそページに戻る)。また、ようこそページにこれらのリンクがあると、ユーザーがアプリケーションを開始するときに明示的に認証されます。
たとえば、3つのコンポーネント(出力テキスト領域、イメージ、ログイン/ログアウト・リンク)を含むADF Facesパネル・グループを作成できます。適切なログイン・リンクまたはログアウト・リンクをレンダリングするために、ユーザーの認証ステータスを評価するEL式を使用できます。特に、securityContext.authenticated
を使用すると、次の例に示すようにADFセキュリティ・コンテキストにアクセスできます。この式はtrue
またはfalse
として評価され、この例では、結果によって、表示するログイン・イメージまたはログアウト・イメージとリンクが決まります。次の例に示すように、リンクはセキュリティBeanのlogon
およびlogoff
メソッドをトリガーします。
<af:panelGroupLayout inlineStyle="width:100%; height:15px;" id="ptpgl3"> <af:spacer width="7" height="10" id="pts2"/> <af:outputText value="Welcome #{securityContext.userName}!" inlineStyle="font-weight:bold; width:100px" id="ptot2" rendered="#{securityContext.authenticated}"/> <af:image source="#{securityContext.authenticated ? '/images/lock.gif' : '/images/key.gif'}" id="pti2" inlineStyle="width:16px; height:16px;" shortDesc="switchable icon"/> <af:link text="Logon" id="l1" action="#{securityBean.logon}" rendered="#{!securityContext.authenticated}"/> <af:link text="Logoff" id="l2" action="#{securityBean.logoff}" rendered="#{securityContext.authenticated}"/> <f:facet name="separator"> <af:spacer width="5" height="10" id="pts1"/> </f:facet> </af:panelGroupLayout>
logonおよびlogoffメソッドを実装するセキュリティBeanでは、ADF AuthenticationService
APIを使用してアプリケーションを悪意のあるリダイレクトから保護できます。これにより、web.xml
ファイルにsuccess_url
およびend_url
パラメータをnullとしてホワイトリスト登録してADF認証サーブレットを起動する場合と同じレベルの保護が実現されますが、これはタスク・フローによるナビゲーションの処理に代わるベスト・プラクティスとみなされます。リダイレクトの詳細は、「認証後にユーザーをリダイレクトする方法」を参照してください。
ページ内にリンクを直接レンダリングするかわりに、「明示的な認証用にログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法」で説明するように、ログイン・リンクとログアウト・リンクを含むログイン・リンク・コンポーネントを作成して、ページ・テンプレートに追加できます。
セキュリティ保護されたページに無名ユーザーがアクセスできないように、ようこそページ上のセキュリティ保護されたページをポイントするナビゲーション・コンポーネントを、次の2つの基準に基づいてビューから非表示にする必要があります。
ユーザーが既知のユーザー・アイデンティティで認証されているか
指定されたユーザー・アイデンティティがターゲットの表示権限を持っているか
これらの条件の一方が満たされない場合、パブリック・ページ上でセキュリティ保護されたリソースをポイントするすべてのナビゲーション・コンポーネントは、そのrendered
属性をfalse
に設定して、無名ユーザーに対して非表示にする必要があります。ようこそページでこのような規則を施行するには、「ADFセキュリティでの式言語(EL)の使用」を参照してください。
暗黙的な認証を実装することを選択した場合は、ユーザーが保護されたWebページにアクセスしてログインした後、ADF認証サーブレットは、ログイン・リクエストが発行された最初のページにユーザーをリダイレクトします。ADFセキュリティ認証が有効な場合、ADFは、ADF認証のsuccess_url
パラメータとして元のページをセッション・マップで自動的に渡します。通常、これは必要な動作です。
また、暗黙の認証を実装することを選択した場合、web.xml
ファイル内でsuccess_url
パラメータをinit-param
要素として指定することにより、Fusion Webアプリケーションを悪意のあるリダイレクトから保護できます。ただし、ADF認証サーブレットによって元のページがsuccess_url
パラメータとして自動的に渡され、web.xml
の設定よりも優先されるため、web.xml
のinit-param
設定が有効になるのは、ユーザーがadfAuthentication
URLをブラウザに明示的に入力する場合のみです。
一方、明示的な認証を実装し、ページに明示的なログイン・リンクを表示することを選択した場合、ADFセキュリティ・フレームワークは元のページを判別できません。この場合、ログイン・リンクは、認証後、目的のページへのリダイレクトがADF認証サーブレットによって確実に行われるように、次の例に示すように、Webページのビュー・アクティビティ名をサーブレットのsuccess_url
パラメータとして渡します。
<af:link text="Login" destination="/adfAuthentication?success_url=/faces/viewactivityname"/>
ベスト・プラクティス:
明示的な認証で、Fusion WebアプリケーションがADF認証リダイレクトをADFコントローラのナビゲーション・イベントとして処理するようにするには、リダイレクト・ターゲットをビュー・アクティビティ名で指定します。リダイレクト・ターゲットとしてビュー・アクティビティを指定しない場合、特にaf:button
コンポーネントなどのコマンド・コンポーネントは、ログイン後に必ず元のページに戻ることになります。リダイレクト・ターゲットを表すADF認証サーブレットのパラメータsuccess_url
およびend_url
としてビュー・アクティビティ名を渡すことで、アプリケーションではすべての場合において、制御フロー・ルールを使用してナビゲーションが処理されるようになります。
明示的な認証では、タスク・フロー・ビュー・アクティビティ名でsuccess_url
を定義するベスト・プラクティスに従うと、ユーザーがブラウザに入力を試みるadfAuthentication
URLをADF認証サーブレットが無視するようにすることで、Fusion Webアプリケーションが悪意のアルリダイレクトから保護されます。または、タスク・フロー・アクティビティが不便な場合は、アプリケーションでAuthenticationService
APIを使用して、リダイレクトを安全な方法で処理するログインおよびログアウト・メソッドを実装できます。セキュリティBeanでAPIを使用する方法の詳細は、「異なるホスト・サーバーへのリダイレクトに関する必知事項」を参照してください。
ユーザーが認証されたが、Webページの表示を認可されない場合は、ADF認証サーブレットをアプリケーションのエラー・ページにリダイレクトできます。タスク・フローを使用しない設計のアプリケーションを作成した場合を除いて、Fusion Webアプリケーションのエラー処理は、ADFコントローラの例外ハンドラで制御されます。たとえば、ADFページ定義で保護された、トップレベルのようこそページと1つのブラウズ・ページを含むバインドなしタスク・フローを定義した場合、次の例に示すようにアプリケーションのエラー・ページ(adfc-config.xml
ファイルに指定されたauthorizationErrorPage.jspx
)が表示されます。
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2"> <exception-handler>authorizationErrorPage</exception-handler> <view id="welcomePage"> <page>/welcomePage.jspx</page> </view> <view id="browse"> <page>/browse.jspx</page> </view> <view id="authorizationErrorPage"> <page>/authorizationErrorPage.jspx</page> </view> <control-flow-rule> <from-activity-id>welcomePage</from-activity-id> <control-flow-case> <from-outcome>goToSecuredPage</from-outcome> <to-activity-id>browse</to-activity-id> </control-flow-case> </control-flow-rule> </adfc-config>
ADFコントローラ例外ハンドラのビュー・アクティビティとしてエラー・ページを指定する方法の詳細は、「タスク・フローでの例外の処理」を参照してください。
ユーザーが認証されず、認可の失敗が発生した場合は、フレームワークがADF認証サーブレットにリダイレクトし、ADF認証サーブレットがログインを求めるJava EE制約をトリガーします。この場合、コンテナ管理セキュリティは、web.xml
ファイルの<login-config>
要素に指定されているログイン・ページとエラー・ページを利用します。
タスク・フローを使用せずにFusion Webアプリケーションを作成する場合、次の例に示すようにADFバインディング・フィルタのための<init-param>
設定をweb.xml
に指定できます。アプリケーションにタスク・フローがないこのケースでは、ページ認可チェックがADFバインディング・フィルタによって処理され、unauthorizedErrorPage
パラメータがADFバインディング・リクエスト・ハンドラに渡されます。
注意:
unauthorizedErrorPage
パラメータの機能は、ADFコントローラが使用できない以前のリリースとの互換性のために用意されています。Fusion Webアプリケーションでは、ユーザーをエラー・ページにリダイレクトする必要があるときは、前述の例のようにタスク・フロー例外ハンドラを使用してエラー・ページを指定します。
<filter> <filter-name>adfBindings</filter-name> <filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class> <init-param> <param-name>unauthorizedErrorPage</param-name> <param-value>faces/authorizationErrorPage.jspx</param-value> </init-param> </filter>
ユーザーが保護対象のリソースにアクセスできるように(直接URLアクセスまたはADFセキュリティの保護対象リソースへの移動により)暗黙的な認証を実装することを選択すると、ADFセキュリティ認証サーブレットがJava EEコンテナを開始し、web.xml
ファイルで構成されているログイン・フォームを表示します。暗黙的な認証では、ADF Facesコンポーネントを使用するようにデフォルトのウィザードにより生成されたログイン・フォームをカスタマイズしている場合は、ADF Facesサーブレットを参照するようにサーブレット・マッピングに対するURLパターンを変更する必要があります。
「ADFセキュリティの構成」ウィザードの「認証タイプ」ページでこのように設定できます。あるいは、web.xml
ファイルで直接行うことができます。すでに「ADFセキュリティの構成」ウィザードを実行している場合は、次の手順に従って、説明したようにweb.xml
ファイルが更新されていることを確認できます。
明示的な認証を実装することを選択し、ユーザーが保護対象のリソースにアクセスするためにログインできるようにパブリック・ページを作成した場合は、作成するログイン・フォームはADFセキュリティによりトリガーされません。明示的な認証シナリオでは、web.xml
ファイルを構成する必要はありません。
注意:
「明示的な認証用のADF Facesベースのログイン・ページの作成」で説明しているとおりに、アプリケーションで明示的な認証をプログラム的に実装する際にログイン・ページ・アプリケーション・パスでweb.xml
ファイルを構成すると、予期しない結果が発生し、ログインが失敗することがあります。web.xml
ファイルは、暗黙的な認証を実装しており、デフォルトのウィザードにより生成されたログイン・フォームのようにj_security_check
アクションに依存するフォームを作成した場合にのみ変更してください。
始める前に:
ログイン・ページの知識があると役立ちます。詳細は、「明示的な認証用のログイン・ページを作成する方法」を参照してください。
暗黙的な認証用のADF Facesログイン・ページを参照するには:
ADF認証サーブレットはユーザーにログインを求めるときに、success_url
で定義されているリダイレクト宛先をセッション・マップに配置します。ただし、ユーザーが認証される前にセッションがタイムアウトした場合、セッション・マップはsuccess_url
の値を失い、アプリケーションは宛先ページに移動できなくなります。
ログイン・リダイレクト宛先をアプリケーションが確実に常に使用できるようにするには、success_url
パラメータをタスク・フローのナビゲーション結果ルールとして定義するか、ADFセキュリティの構成ウィザードを実行するときにweb.xml
ファイルに追加される、ホワイトリスト登録された1つのページとして静的に定義します。
web.xml
ファイルはデプロイメント前に定義する必要があるため、Fusion Webアプリケーションでは、接続参照値の定義を伴うリダイレクトURLのsuccess_url
パラメータを構成する別の動的なアプローチがサポートされています。これらの値は、connections.xml
ファイルで直接構成することもできます。
connections.xml
ファイルをADF認証サーブレットのリダイレクト宛先の永続ストアとして使用する手順は次のとおりです。
アプリケーションを現在のリクエスト・ホスト、ポートおよびコンテキスト・ルートにリダイレクトする場合は、宛先URLでホスト名、ポート番号およびコンテキスト・ルートを省略できます。この場合、URLは/faces/pagename
として指定され、/faces
はADF Facesのコンテキストでページをロードし、ADF Facesコンポーネントを使用するように設計されたページをサポートします。
実行時にリダイレクトURLがセッション・マップ上にない場合、ADF認証サーブレットはoracle.adf.share.security.authentication.connections
という名前のinit-param
から接続名を取得してconnections.xml
ファイルから接続を参照します。名前付きの接続がない場合、またはsuccess_url
(ログイン)やend_url
(ログアウト)がconnections.xml
にない場合は、success_url
またはend_url
がweb.xml
に定義されていないかどうかADF認証サーブレットによってチェックされます。
ログアウト時に、Fusion Webアプリケーションの開始サーバーとは異なる任意のWebページまたはホスト・サーバーにユーザーをリダイレクトすることが必要な場合があります。このシナリオでは、宛先ページのURLがリクエスト時にアプリケーションによって配置されないようにすることで、アプリケーションを悪意のあるリダイレクトから保護する必要があり、かわりにセッション・マップを使用します。これを実現するために、次の例に示すように、サーブレットのinit-param
要素disable_url_param
をtrueに設定してweb.xml
ファイルのADF認証サーブレット定義に追加することで、ADFリダイレクト・パラメータがブラウザURLで渡されないようにすることをお薦めします。
<servlet> <servlet-name>adfAuthentication</servlet-name> <servlet-class> oracle.adf.share.security.authentication.AuthenticationServlet </servlet-class> <init-param> <param-name>success_url</param-name> <param-value>faces/welcome</param-value> </init-param> <init-param> <param-name>end_url</param-name> <param-value>faces/welcome</param-value> </init-param> <init-param> <param-name>disable_url_param</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> ...
セッション・マップでリダイレクト・パラメータを渡すこと(そうしなければブラウザURLリクエストでパラメータが公開される)をADFによって強制される前に構築されたレガシー・アプリケーションでは、disable_url_param
をtrue
に設定せず、かわりにターゲットの宛先をセッション・マップに配置することで、ADFインタフェースoracle.adf.share.security.AuthenticationService
を使用してADF固有のログインおよびログアウト・メソッドを処理するセキュリティBeanを実装することを検討してください。
次の例は、AuthenticationService
インタフェースのlogout()
メソッドの使用方法を示しています。このメソッドは、渡されたURLをセッション・マップに内部的に挿入し、ユーザーによってURLに明示的に設定される可能性のあるend_url
パラメータを無視します。同様にlogin()
メソッドはセッション・マップにログインURLの宛先を配置します。異なるサーバー上のWebページにリダイレクトするためにログアウトが必要な場合、メソッド実装では、目的のWebページのURLを渡し、悪意のあるリダイレクトから引き続き保護できます。
import javax.faces.context.ExternalContext; import javax.faces.context.FacesContext; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import oracle.adf.share.security.AuthenticationService; import oracle.adf.share.security.authentication.AuthenticationServiceUtil; public class SecurityBean { public SecurityBean() { super(); } public boolean isAuthenticated() { ExternalContext ectx = FacesContext.getCurrentInstance().getExternalContext(); return ectx.getUserPrincipal() != null; } public void logon() { if (!isAuthenticated()) { FacesContext ctx = FacesContext.getCurrentInstance(); AuthenticationServiceUtil.getAuthenticationService().login("/faces" + ctx.getViewRoot().getViewId(), null, null); } } public void logoff() { if (isAuthenticated()) { AuthenticationServiceUtil.getAuthenticationService(). logout("/faces/index", null); } } }
プログラムによるアプローチの代替では、null値のsuccess_url
およびend_url
パラメータを持つ明示的なリンクでADF認証サーブレットを呼び出すことで、セッション・マップへの宛先URLの配置を処理します。この場合、ADF認証サーブレットは、web.xml
ファイル(またはconnections.xml
ファイル)からリダイレクト値を取得しようとし、ユーザーがURLに入力しようとする値を無視します。このアプローチでは、success_url
およびend_url
パラメータにinit-param
要素を指定することで、web.xml
にADF認証サーブレット定義を構成する必要があります。その結果、これはログインおよびログアウト・リダイレクトに単一の宛先があるホワイトリストを生成する宣言的なアプローチになります。
Fusion Webアプリケーションのweb.xml
ファイルの指定に基づいてBasic認証が有効な場合、ブラウザは認証資格証明をキャッシュします。これは、ADF認証サーブレットによるログアウト・リダイレクトの実行後に、Basic認証によってユーザーを再認証する場合の既知の問題です。このシナリオでは、ログアウト・セッションを完了し、ユーザーによるリソースへのアクセスを防ぐために、ブラウザを終了し、新しいブラウザ・セッションを再開する必要があります。
ADFアプリケーションがログアウトを完了し、ユーザーがログアウト後にリソースにアクセスできないようにするには、基本認証ではなくフォームベースの認証を使用します。「ADFセキュリティを有効化する方法」で説明するように、ADFセキュリティの構成ウィザードを実行してフォームベース認証を選択できます。
ADFセキュリティを有効化してカスタム・エラー・ページを表示する場合、ページ表示のリクエストに応じてアプリケーションがHTTPエラーを生成すると、エラー・ページが表示されます。ただし、特定のバージョンのInternet Explorerでは、ブラウザに、カスタム・エラー・ページか、Internet Explorerに組み込まれているエラー・メッセージのどちらかが表示されます。Internet Explorerにエラー・メッセージのみが表示される場合は、「インターネット オプション」ダイアログの「詳細設定」で、エラー・メッセージ番号を表示するオプションを無効にできます。Internet Explorer 10では、このオプションはデフォルトで有効になっています。「ADFセキュリティの構成」ウィザードで有効化したカスタム・エラー・メッセージを表示するには、「HTTPエラーメッセージを簡易表示する」を無効にする必要があります。
Internet Explorer 10でカスタム・エラー・メッセージを表示するには:
Internet Explorerのツールバーで、「ツール」ボタンをクリックします。
「インターネット オプション」ダイアログで、「詳細設定」タブをクリックします。
「詳細設定」タブで、スクロールして「HTTPエラーメッセージを簡易表示する」を探します。
このオプションをクリックして無効化し、「OK」をクリックします。
ADFセキュリティをテストするために、JDeveloperで、統合WebLogic Serverを使用してアプリケーションを実行し、アプリケーションで定義されたセキュリティ・オブジェクトを移行するかどうかを決定します。
統合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について理解しておくと役立ちます。詳細は、「JDeveloperにおけるセキュリティのテスト」を参照してください。
セキュリティ・デプロイメントを構成し、JDeveloperでアプリケーションを実行するには:
統合WebLogic Serverを使用してアプリケーションを実行するとき、JDeveloperは、「アプリケーション・プロパティ」ダイアログに指定したセキュリティ・デプロイメント構成設定に基づいて、セキュリティ・ポリシーと資格証明をドメイン・レベルに移行します。デプロイメント・プロセスで、JDeveloperは、次の例に示すように、「アプリケーション・プロパティ」の設定に基づいてデプロイメント・アーカイブ・ファイルに追加するweblogic-application.xml
ファイルを更新します。これらの設定はアプリケーション・ソース・ディレクトリのweblogic-application.xml
ファイルには追加されないため、表示されないことに注意してください。
<application-param> <param-name>jps.credstore.migration</param-name> <param-value>OVERWRITE</param-value> </application-param> <application-param> <param-name>jps.policystore.migration</param-name> <param-value>OVERWRITE</param-value> </application-param>
OVERWRITE
値を指定すると、アプリケーションのセキュリティ・ポリシーと資格証明を変更して、開発モードで実行しているOracle WebLogic Server、または統合WebLogic Server(デフォルトで開発モードで実行するように設定されている)にどちらも再デプロイすることができます。
注意:
いずれ本番環境にデプロイする際には、weblogic-application.xml
ファイルの移行設定は無視されます。既存のポリシーと資格証明を上書きできるため、これはセキュリティの脆弱性とみなされます。本番環境へのデプロイの詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。
また、次の例に示すように、JDeveloperはweblogic-application.xml
ファイルをOPSSライフサイクル・リスナーでも更新します。アプリケーションが実行する前に移行プロセスを開始するために、ライフサイクル・リスナーはポリシーと資格証明について移行設定を確認し、ドメイン・レベルでセキュリティ・オブジェクトを上書きします。
<listener> <listener-class> oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener </listener-class> </listener> <listener> <listener-class> oracle.security.jps.wls.listeners.JpsAppVersionLifecycleListener </listener-class> </listener>
移行プロセスで、JDeveloperはOracle Platform Security Services (OPSS)アプリケーション・ロール・メンバー・クラスを統合WebLogic Serverメンバー・クラスにマッピングし、ユーザーをWebLogic Serverアイデンティティ・ストアusers
に移行し、ロールをWebLogic Serverアイデンティティ・ストア・グループに移行します。Oracle WebLogic Serverでは、users
はOPSSのauthenticated-role
と同等の暗黙のグループです。
アイデンティティ・ストアの移行は、weblogic-application.xml
ファイルのアプリケーション・ライフサイクル・リスナー設定では制御されません。かわりに、統合WebLogic Serverで実行するとき、またはJDeveloperからデプロイするときは、Oracle WebLogic Mbeanによってアイデンティティの移行が処理されます。ユーザーがすでに存在している場合、Mbeanはユーザー定義全体を移行しません。ユーザーのパスワードだけを更新します。
「ADFセキュリティの構成」ウィザードを実行すると、jazn-data.xml
ファイルのポリシー・ストアにtest-all
アプリケーション・ロールを追加するオプションを有効にできます。このオプションを有効にするときは、アプリケーションのアプリケーション・ロールへの権限付与のスコープも指定します。
JDeveloperでtest-all
アプリケーション・ロールにview権限を付与し、ウィザードの実行時にユーザー・インタフェース・プロジェクトに表示されるADFタスク・フローとWebページすべてにこのポリシーを適用するには、「既存のオブジェクトのみに付与」を選択します。
JDeveloperでtest-all
アプリケーション・ロールにview権限を付与し、開発者がユーザー・インタフェース・プロジェクトで作成した既存のADFタスク・フローとWebページ、および今後ユーザー・インタフェース・プロジェクトで作成するすべてのADFタスク・フローとWebページにこのポリシーを適用するには、「すべてのオブジェクトに付与」を選択します。「すべてのオブジェクトに付与」オプションを選択してウィザードを初めて実行した後は、ウィザードによりオプション「新規オブジェクトに付与」が表示されます。
ウィザードの実行後、jazn-data.xml
ファイルにtest-all
ロールが表示され、セキュリティ・ポリシーの概要エディタにこのロールが表示されます。test-all
ロールにテスト・ユーザーを移入する必要はありません。ウィザードによって、組込みアプリケーション・ロールanonymous-role
がtest-all
ロールに割り当てられるためです。この場合、すべてのユーザーは自動的にanonymous-role
プリンシパルを保持し、アプリケーションへのアクセスを許可されます。
注意:
アプリケーションをデプロイする前に、「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」の説明に従って、ポリシー・ストアからすべてのtest-all
ロールを削除する必要があります。これにより、未認可のユーザーはアプリケーションのWebページにアクセスできなくなります。
いつでもウィザードを再実行して、自動付与を無効にすることができます。いったん無効になると、新たに作成するADFタスク・フローとWebページはtest-all
ロールを利用しないため、「ADFセキュリティ・ポリシーの定義」で説明するように明示的な付与を定義する必要があります。
統合WebLogic Serverを使用してJDeveloperでアプリケーションをテストするとき、アイデンティティ・ストアが、Oracle Internet Directoryに格納されている情報と一緒に埋込みLDAPサーバーに移行されます。
図47-27に、ユーザーがあらかじめログインせずに、ADFバインド・タスク・フローまたはADFバインディングを含むWebページ(mypage.jspx
など)にアクセスを試行するときの認証プロセスを示します。ユーザーがパブリック・ページのログイン・リンクをクリックしてログインを開始するのではないため、認証は暗黙的に開始されます。セキュリティ保護されたページの場合、無名ユーザーに対して権限付与は行われません。
図47-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セキュリティによる認可の処理」で説明するように、リソースが表示されるかどうかは、ユーザーのアクセス権と、ADFセキュリティのための認可が施行されているかどうかに依存します。
図47-28は、パブリック・ページの「ログイン」リンクから開始するプロセスで、ユーザーが認証される場合の明示的認証処理を示しています。
明示的認証のシナリオでは、(anonymous
ユーザー・プリンシパルとanonymous-role
プリンシパルのみを持つ)認証されていないユーザーが、パブリック・ページの「ログイン」リンクをクリックします(図のステップ1)。「ログイン」リンクは、web.xml
ファイルのJava EEセキュリティ制約を介してセキュリティ保護されているADF認証サーブレットへのダイレクト・リクエストです。
このシナリオでは、現在のページがパラメータとしてADF認証サーブレットに渡されます。暗黙的認証のケースと同じく、セキュリティ制約によってユーザーがログイン・ページにリダイレクトされます(図のステップ2)。暗黙的認証ケースのステップa - ステップdで説明したようにコンテナがユーザーを認証すると、リクエストがADF認証サーブレットに戻されます(図のステップ3)。その後、サーブレットによってユーザーがパブリック・ページに戻されますが、その時点では新しいユーザーおよびロール・プリンシパルが配置されています。
ADF認可が有効になってるとき、ADFバインド・タスク・フローとタスク・フロー外部のWebページ(ADFページ定義がある)はデフォルトで保護されます。ユーザーがこれらのWebページにアクセスしようとすると、ADFセキュリティが、ポリシー・ストアでそのユーザーがアクセス権を付与されているかどうか、確認して判定します。ユーザーがまだ認証されていず、anonymous-role
に対してページが許可されていない場合、ログイン・ページまたはフォームが表示されます。認証されたユーザーでも権限がない場合は、セキュリティ・エラーが表示されます。ポリシー・ストアに適切な権限を構成していない場合、ページは保護された状態に維持され、したがって認証されたユーザーも利用できません。
図47-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
のポリシー・ストアで定義されています。
Oracle ADFアプリケーションは、テスト後にターゲット・アプリケーション・サーバーにデプロイする必要があります。アプリケーションを統合WebLogic Serverで実行でき、スタンドアロンOracle WebLogic Serverにデプロイできます
統合WebLogic Serverを使用したJDeveloperでのテストの後は、アプリケーションをスタンドアロン・サーバーにデプロイすることができます。最初は、ターゲットのサーバーはステージング環境です。本番環境にデプロイする前に、このサーバーのアイデンティティ・ストアを使用して開発のテストを続行できます。つまり、通常は作成したテスト・ユーザーを統合WebLogic Serverで実行するために移行しません。資格証明(cwallet.sso
ファイル内)とセキュリティ・ポリシー(jazn-data.xml
ファイル内)をスタンドアロンOracle WebLogic Serverに移行するために実行するステップは、ターゲット・サーバーで構成されているモードと、デプロイにJDeveloperまたはJDeveloper外部ツールのどちらを使用するかによって異なります。
注意:
JDeveloperからデプロイメント環境へのデプロイの詳細は、「Fusion Webアプリケーションのデプロイ」を参照してください。
ターゲット・サーバーが開発モードで構成されているときは、JDeveloperから直接デプロイできます。この場合、JDeveloperが、デプロイメント・プロセスの一環としてポリシー・ストア、システム資格証明およびアイデンティティ・ストア(ユーザーおよびグループ)の移行を自動的に処理します。アプリケーション・セキュリティ・デプロイメント・プロパティでは、デプロイメント・プロセスがドメインレベルのポリシー・ストアとシステム資格証明を上書きできるようにデフォルトで構成されています。さらに、アイデンティティ・ストア・デプロイメント・プロパティは、テスト・ユーザーを含むアイデンティティ・ストアを移行するようにデフォルトで構成されています。「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、このデフォルトのデプロイメント動作を「アプリケーション・プロパティ」ダイアログで変更できます。
注意:
開発モードで実行するOracle WebLogic Serverへのシステム資格証明の移行が実行されるのは、ターゲット・サーバーが資格証明の上書きを許可するように構成されている場合だけです。システム資格証明の上書きをサポートするためにOracle WebLogic Serverを構成する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。
ターゲット・サーバーが本番モードで構成されているとき、通常は、JDeveloper外部でOracle Enterprise Managerなどのツールを使用して移行タスクを処理します。JDeveloper外部のツールを使用してポリシー・ストアを本番環境のドメインレベルに移行する方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の「OPSSセキュリティ・ストアの構成」の章を参照してください。本番モードで実行するOracle WebLogic Serverでは、どのような状況でもシステム資格証明の上書きはサポートされないことに注意してください。
「ADFセキュリティの構成」ウィザードで自動付与機能を有効にした場合は、アプリケーションをデプロイする前にtest-all
アプリケーション・ロールを削除することをお薦めします。test-all
ロールによってすべてのADFリソースが公開されるため、このロールが存在していると、アプリケーションのリソースが保護されない状態になるリスクが高まります。したがって、アプリケーションレベルのポリシー・ストアを移行する前にこのロールを削除する必要があります。
さらに、アプリケーションのOracle WebLogic Serverへのデプロイを準備するとき、jazn-data.xml
ファイルに作成したテスト・アイデンティティを削除することもお薦めします。こうしておくと、セキュリティ・ポリシーをテストするために作成したユーザーが、ドメインレベルのアイデンティティ・ストアに移行されません。
ベスト・プラクティス:
アプリケーションをスタンドアロン環境にデプロイする場合は、すでにOracle WebLogic Serverに対して構成しているローカル・アイデンティティ・ストアのユーザーおよびエンタープライズ・ロールを移行してはいけません。たとえば、ユーザーweblogic
とエンタープライズ・ロールAdministrators
を含むアイデンティティ・ストアをデプロイする場合は、ターゲット・サーバーのデフォルト管理構成を上書きします。競合の可能性をすべて排除するには、「アプリケーション・アイデンティティ・ストアからテスト・ユーザーを削除する方法」で説明するように、アイデンティティ・ストアの移行を無効にすることができます。
セキュリティ・ポリシーの概要エディタには、ADFセキュリティの組込みtest-all
ロールに対するview権限を持つすべてのリソースを表示する機能があります。概要エディタのこの機能を使用して、test-all
ロールの権限を削除し、アプリケーションで定義するロールの権限で置き換えることができます。
または、jazn-data.xml
ファイルの概要エディタを使用してtest-all
ロールを削除できます。エディタの「アプリケーション・ロール」ページでtest-all
ロールを選択して、「アプリケーション・ロールの削除」ボタンをクリックします。ただし、この方法でtest-all
ロールを削除しても、削除するロールのかわりの権限を作成する必要があります。概要エディタではこれらのタスク両方を一緒に行うことができるため、次の手順で使用方法を説明します。
始める前に:
Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。
test-allアプリケーション・ロールを削除し、カスタム・アプリケーション・ロールで置き換えるには:
デプロイ先のスタンドアロンOracle WebLogic Serverでは、構成済の独自のアイデンティティ・ストアが用意されます。JDeveloperで作成したテスト・ユーザーとエンタープライズ・ロール・グループをドメイン・レベルに移行しないようにするには、jazn-data.xml
ファイルからテスト・ユーザー・レルムを削除する必要があります。
または、JDeveloperからデプロイする場合は、「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」オプションを選択解除して、ユーザーとグループの移行を無効にすることができます。
始める前に:
Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、「セキュア・アプリケーションのデプロイの準備」を参照してください。
アイデンティティ・ストアからテスト・ユーザーとエンタープライズ・ロール・グループを削除するには:
リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルは、ADFセキュリティによって保護されません。アプリケーションのWebページをセキュリティ保護する場合、これらのファイルをセキュリティ保護することは必須ではありませんが、アプリケーションを十分にセキュリティ強化するために、リソース・ファイルを保護したほうが好ましい場合もあります。JavaScriptファイルはブラウザにダウンロードされるため、このときに読取り可能となることに注意してください。
リソース・ファイルを提供するため、ADF Facesフレームワークではorg.apache.myfaces.trinidad.webapp.ResourceServlet
を使用し、これによってリソース・ローダーに処理が委譲されます。Fusion Webアプリケーションのweb.xml
ファイルには、リソース・サーブレットとURLパターンを対応付けるサーブレット・マッピングが含まれます。JDeveloperは、デフォルトで/adf/*
(MyFaces Trinidad Coreの場合)および/afr/*
(ADF Facesの場合)パターンを使用します。
リソース・サーブレットはADFセキュリティによって保護されないため、リソース・サーブレット用のJava EEアクセス・パスを、セキュリティ制約を使用して保護できます。リソース・ファイルに対する独自のセキュリティをweb.xml
ファイル内に実装するには、/adflib/*
、/adf/*
および/afr/*
パスに対するセキュリティ制約を定義して、これらに特定のセキュリティ・ロールを割り当てます。このセキュリティ制約により、すべてのユーザーは、Fusion Webアプリケーションの最初のページにアクセスする前に認証を受けることになります。
次の例は、セキュリティ・ロールresource_role
と、このロールにマッピングされたURLパターンによる制約を示しています。セキュリティ・ロールを定義した後は、ターゲット・サーバーの管理者によってこのロールをOracle WebLogic Serverエンタープライズ・ロール(ユーザー・グループ)にマッピングしてもらうか、または同名のエンタープライズ・ロールを作成してもらう(この場合はマッピングは不要)必要があります。
<security-role> <description>Java EE role to map to an enterprise role. All users who will be allowed to run Fusion web app must be members of that role. </description> <role-name>resource_role</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>resources</web-resource-name> <url-pattern>/adflib/*</url-pattern> <url-pattern>/adf/*</url-pattern> <url-pattern>/afr/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>resource_role</role-name> </auth-constraint> </security-constraint>
ADFセキュリティは無効にできますが、作成された権限は削除されません。このオプションを使用して、前にセキュリティ保護したアプリケーションを非保護で実行できます。
アプリケーション・ポリシー・ストアに対する認可チェックを一時的に実行せずにアプリケーションを実行する必要がある場合、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セキュリティの無効化について理解しておくと役立ちます。詳細は、「ADFセキュリティの無効化」を参照してください。
ADF認可チェックを無効にするには:
「ADFセキュリティ構成の削除」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、web.xml
ファイルとadf-config.xml
ファイルからADF固有のメタデータ(表47-2)が削除されます。
同様に、「ADF認証」オプションを選択してウィザードを実行し、認可チェックのみを無効にすると、次の更新が実行されます。
web.xml
ファイルでADF固有のメタデータは変更されず、allPages
セキュリティ制約が追加されます。
allPages
セキュリティ制約が存在する場合、ユーザーはアプリケーションに最初にアクセスしたときに認証を行うことになります。
次の例に示すようにadf-config.xml
ファイルの<JaasSecurityContext>
要素のauthorizationEnforce
パラメータがfalse
に設定されます。
<JaasSecurityContext initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory" jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext" authorizationEnforce="false" authenticationRequire="true"/>
adf-config.xml
ファイルは、ワークスペースの/.adf/META_INF
フォルダにあります。JDeveloperでは、このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで「ディスクリプタ」→「ADF META-INF」ノードを開くと見つかります。JDeveloperの外部でエディタを使用してadf-config.xml
ファイルを表示する場合、ウィザードによって適用されたファイル内の変更を確認するにはワークスペースを保存する必要があります。
デフォルトのADFリージョンとタスク・フロー認可以外に、追加のセキュリティ構成があります。さらに、ADFアプリケーションを保護して、意図したWebページへのユーザーのアクセスを許可するのに役立つベスト・プラクティスがあります。
ADFセキュリティの有効化プロセスを完了した後、ユーザー・インタフェースにおいてADFセキュリティと連動するようにアプリケーションをカスタマイズすることができます。たとえば、式言語(EL)を使用し、一連のUIコンポーネントのためだけに定義したカスタム権限の評価に基づいて、UIコンポーネントをWebページにレンダリングできます。さらに、マネージドBean内にメソッドを定義して、アプリケーションの情報(ユーザー名やロール・メンバーシップなど)を公開できます。
式言語(EL)を使用するとUIのポリシーを直接評価できますが、Javaを使用するとマネージドBean内でポリシーを評価できます。ADFセキュリティでは、セキュリティ・コンテキストでADFリソースにアクセスするように、EL式で使用できる便利なメソッドがいくつか実装されています。たとえば、EL式とADFセキュリティ・コンテキストAPIのメソッドを使用して、ユーザーが特定のタスク・フローにアクセスできるかどうかを判定できます。優れたセキュリティは、ユーザーがアクセス権を持たないリソースや機能をアプリケーションが非表示にすることを求めます。この理由から、ユーザーが特定のタスク・フローへのアクセスを許可されない場合、そのユーザーの権限を評価して、そのタスク・フローを開始するナビゲーション・コンポーネントをレンダリングするかどうかを判別します。
注意:
ポリシーを評価できるのは、現在のリクエストのみです。この理由から、リクエスト・スコープ外でポリシーを評価すると、予期しない結果が発生することがあるため、ポリシー評価がどこで行われるかを理解することが重要です。
UIコンポーネント内でELを使用すると、コンポーネントの属性値を動的に定義できるようになるため、実行時にUIコンポーネントを変更できます。リソースを保護する場合、対象となるUIコンポーネント属性はrendered
属性です。これを使用して、ユーザーの権限に基づいてコンポーネントの表示と非表示を切り替えることができます。デフォルトでは、rendered
属性はtrue
に設定されています。権限に応じてこの値を動的に変更することで、UIコンポーネントの表示と非表示を設定できます。たとえば、ユーザーが適切な権限を持っている場合は、UIコンポーネントが表示されるようにrendered
属性をtrue
に設定する必要があります。権限を持たない場合は、属性をfalse
に設定して、UIコンポーネントを非表示にする必要があります。
ELを使用してポリシーを評価するには、securityContext
ELネームスペースでADFセキュリティのメソッドを使用する必要があります。これらのメソッドを使用して、特定のユーザーまたはADFリソースに関してADFセキュリティ・コンテキストの情報にアクセスできます。
表47-11に、ユーザーが関連する権限を持つかどうかを判別するために必要なEL式を示します。ユーザーが適切な権限を持っている場合、EL式はtrue
に評価されます。そうでない場合はfalse
を返します。
表47-11 ADFリソースに対するview権限を判定するEL式
式 | 式のアクション |
---|---|
#{securityContext.taskflowViewable['
次に例を示します。 #{securityContext.taskflowViewable ['/WEB-INF/audit-expense-report.xml#audit-expense-report']} |
|
#{securityContext.regionViewable['
|
|
注意:
「valid-usersロールに関する必知事項」で説明したように、ページ権限の場合、マネージドBean内部の遅延バインディングELを使用することにより、ページ定義の値を動的に指定できます。
表47-12には、ADFセキュリティ・コンテキストから、ADFリソースに関連しない一般的な情報を取得するためのEL式を示します。たとえば、ユーザーの名前をユーザー・インタフェースに表示する場合は、現在のユーザー名にアクセスできます。また、現在のユーザーが特定のロールのメンバーかどうか、特定の権限を付与されているかどうかもチェックできます。アプリケーションはこの結果を使用してメニューの非表示と表示を動的に切り替えることができます。
表47-12 ADFセキュリティ・コンテキストでのユーザー情報を判定するEL式
式 | 式のアクション |
---|---|
#{securityContext.userName} |
認証されたユーザーのユーザー名を戻します。 |
#{securityContext.authenticated} |
ユーザーがログインしている場合は |
#{securityContext.userInRole['
|
|
|
|
#{securityContext.userGrantedPermission['permission']}
|
表47-11に示された便利なメソッド |
#{securityContext.userGrantedResource['resource']}
|
この式を使用すると、タスク・フローに含まれないリソース(「ADF Faces」パネルやメニュー項目など)の表示プロパティの権限をテストできます。最初に、保護するUIコンポーネントのカスタム・リソース・タイプを作成します。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。 |
始める前に:
ELの用法について理解しておくと役立ちます。詳細は、「ADFセキュリティでの式言語(EL)の使用」を参照してください。
ナビゲーション・コンポーネントのレンダリングを、ターゲット・タスク・フローまたはページ定義に対してユーザーに付与された権限に関連付ける手順:
アプリケーションを実行すると、ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。
「式ビルダー」を使用してrendered
属性の式を定義すると、開いている.jspx
ファイルのコンポーネント定義がJDeveloperによって更新されます。次の例に示すように、コンポーネントのrendered
属性に、true
またはfalse
に評価される式が追加されます。この例ではコンポーネントはナビゲーション・リンクであり、リンク・テキストCheckout
は別の式で定義されます。このナビゲーション・リンクを含むページによってこのコンポーネントがレンダリングされるのは、チェックアウト・タスク・フローにアクセスするための十分なアクセス権がユーザーにある場合のみです。
<af:commandNavigationItem text="#{res['global.nav.checkout']}" action="globalCheckout" id="cni3" rendered="#{securityContext.taskflowViewable ['/WEB-INF/checkout-task-flow.xml#checkout-task-flow']}" />
セキュリティ権限を評価できるスコープは、リクエストに設定されています。リクエストよりも上位レベルまでスコープ設定されたマネージドBean (マネージドBeanが基礎となっているグローバル・メニューなど)からターゲット・ページにアクセスするための権限を評価する場合は、遅延EL評価(遅延バインディング)を実装する必要があります。Beanの管理プロパティとしてターゲット・ページを渡すことで、マネージドBeanが必要なバインディング情報を取得できるようになった後でEL式が評価されるようになります。ELは、ページが実行されるとすぐに評価されるため、マネージドBeanを基礎としたUIコンポーネントのプロパティ内に直接EL式を配置すると、有効範囲外エラーが発生します。
次の例は、ユーザーが特定のターゲット・ページを表示できるかどうかに基づいてtrue
またはfalse
を返すマネージドBeanのプロパティ(authorized
)を示しています。この場合、_targetPageDef
変数は、ターゲット・ページの名前が含まれる管理プロパティです。UI内で、EL式はauthorized
プロパティを参照します。
public boolean isAuthorized() { if (_targetPageDef != null) { FacesContext fctx = FacesContext.getCurrentInstance(); ADFContext adfCtx = ADFContext.getCurrent(); SecurityContext secCtx = adfCtx.getSecurityContext(); boolean hasPermission = secCtx.hasPermission(new RegionPermission (_targetPageDef, RegionPermission.VIEW_ACTION)); if (hasPermission) { return hasPermission; } else { fctx.addMessage(null, new FacesMessage ( FacesMessage.SEVERITY_WARN, "Access Permission not defined! " , null)); return false; } }
表47-12に示したADFセキュリティのELネームスペースでのセキュリティ式によって、ページにUIコンポーネントを表示する前にユーザー権限、認証およびロール・メンバーシップ・ステータスを確認できます。タスク・フロー・セキュリティやWebページ・セキュリティの一部ではないアプリケーションの機能部分を保護するために、UIコンポーネントをきめ細かく保護する必要がある場合は、EL値userGrantedResource
と、カスタム・リソース・タイプ用に定義したリソース権限を使用します。たとえば、ユーザーがメニュー項目用に作成したリソース権限によって、アプリケーションはCancel Shipment(出荷取消し)のメニュー項目を有効化または無効化して、顧客注文更新の実行者を制限します。
カスタム・リソース・タイプのリソース権限は、ResourcePermission
クラスに依存しています。このクラスはOracle Platform Security Services (OPSS)によって提供され、アプリケーションとともにパッケージ化されています。
セキュリティ・ポリシーの概要エディタを使用して、カスタム・リソース・タイプのセキュリティ・ポリシーを作成します。またWebページでは、セキュリティ式を使用して、リソース権限によって投影されるUIコンポーネントへのユーザーのアクセス権限を評価します。
ベスト・プラクティス:
カスタム・リソース・タイプとResourcePermission
マッチャ・クラスを組み合せることで、ADFセキュリティを開き、権限内で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。Webページへのアクセスを管理するために、カスタム・リソース・タイプを作成する必要はありません。このレベルのアクセスは、セキュリティ・ポリシーの概要エディタで操作できる、ADFセキュリティのデフォルトのview権限によって実現されます。
カスタム・リソース・タイプのリソース・ポリシーを許可するには:
「リソース・タイプの作成」ダイアログを使用して、保護するUIコンポーネントのリソース・タイプを作成します。JDeveloperが、リソース・タイプの定義とOPSS権限クラスoracle.security.jps.ResourcePermission
を一致させます。このクラスを使用して、タスク・フロー・セキュリティまたはWebページ・セキュリティによって保護されないアプリケーションの機能部分に権限を付与できるカスタム・アクションを指定できます。たとえば、メニューのUIコンポーネントを使用してユーザーがアクセスするアプリケーションの機密部分を保護するために、リソース・タイプを作成することがあります。
「リソース・タイプの作成」ダイアログでは、保護するリソースのタイプ(たとえば、MenuProtection
という名前はメニューのUIコンポーネントを識別する)、セキュリティ・ポリシー・ストアに表示される表示名(例: Menu Protection
)、リソース権限でのリソース・タイプの使用方法の説明(例: Resource permission to grant menu item permissions
)を識別できます。このダイアログでは、権限を付与するために使用する1つ以上のカスタム・アクション名を入力することもできます。たとえば、保護されたメニュー項目へのアクセス権を付与するセキュリティ・ポリシーで使用するために、process
というアクション名を入力できます。
始める前に:
ADF権限クラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。
カスタム・リソース・タイプを作成する手順:
jazn-data.xml
ファイルの概要エディタを使用して、カスタム・リソースのADFセキュリティ・ポリシーを作成します。完成したソースは、次の例に示すように、ポリシー・ストアで定義される権限と類似した内容となります。
<grant> <grantee> <principals> <principal> <name>AccountManagersadmin</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.security.jps.ResourcePermission</class> <name>resourceType=MenuProtection,resourceName=CancelShipment</name> <actions>process</actions> </permission> </permissions> </grant>
ターゲット名<permission>
は、カスタム・リソース・タイプと、リソースを割り当てた名前を識別します。たとえば、ユーザーがアカウント内のメニュー選択から出荷を取り消すことができるリソース名は、CancelShipment
という名前になります。
アクションは、カスタム・リソース・タイプによって定義されています。たとえば、メニュー保護では、リソース・タイプによって、メニュー選択を処理する権限を付与するための単一アクションprocess
が定義されます。
始める前に:
ResourcePermission
クラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。
次のタスクを完了する必要があります。
カスタム・リソース・タイプに対してリソース権限を作成する手順:
UIコンポーネントの表示プロパティに対する「式ビルダー」ダイアログを使用して、コンポーネントのレンダリングを制御するEL式を定義します。たとえば、認可ユーザーが出荷を取り消すことができるアプリケーションでメニュー項目を保護するために、アプリケーションは、af:commandMenuItem
によって定義されたメニュー項目のdisabledプロパティに対して、userGrantedResource
式を指定します。次の例に示すように、ユーザーにリソース・タイプに対する権限が付与されているか、その結果メニュー項目が表示されるかどうかが式によってテストされ、ユーザーにリソースに対する権限が付与されていない場合は、メニュー項目が無効化されます。
#{!securityContext.userGrantedResource ['resourceName=CancelShipment;resourceType=MenuProtection;action=process']}
図47-36は、「式ビルダー」ダイアログに式がどのように表示されるかを示します。
始める前に:
ResourcePermission
クラスについて理解しておくと役立ちます。詳細は、「OPSSリソース・パーミッションとELを使用してUIコンポーネントを保護する方法」を参照してください。
次のタスクを完了する必要があります。
「カスタム・リソース・タイプの作成」の説明に従って、カスタム・リソース・タイプを作成します。
「カスタム・リソース・タイプに対するリソース権限の作成」の説明に従って、カスタム権限を使用してADFセキュリティ・ポリシーを作成します。
UIコンポーネントのレンダリングとユーザーに付与されるリソース権限を関連付ける手順:
Fusion Webアプリケーションで、エンティティ・オブジェクトの操作をセキュリティで保護する際にデータ・コレクションのセキュリティを有効にできます。ユーザーには、行セット全体のデータを表示、更新または削除するのに十分な権限が必要です。
oracle.jbo.ViewCriteriaRow
APIでは、エンティティ行のレベルで標準操作(read
、update
、removeCurrentRow
)の認可チェックを実行できます。次の例は、エンティティ行に対して認可チェックAPI、getSecurityHints()
およびallowsOperation()
を使用して、ユーザーにデータを削除する権限があるかどうかをテストする方法を示しています。
if(row.getSecurityHints().allowsOperation("removeCurrentRow").hasPermission()) // code for the data else // display error message
allowsOperation()
メソッドは、保護するアクションの名前ではなく保護された操作名を入力として必要とします。エンティティ行の削除の操作名はremoveCurrentRow
(delete
がアクション名)です。
Fusion WebアプリケーションのJSFページにデータ・バインドされたコンポーネントの基礎となるエンティティ・オブジェクトの認可チェックを実行する場合は、EL式を使用できます。たとえば、次のEL式は、指定された操作を実行する権限がユーザーに付与されている場合にtrueを返します。式で使用されている<operationName>
は、エンティティ・オブジェクトに対して有効にしたread
、update
またはremoveCurrentRow
操作である必要があります。
#{row.hints.allows.
<operationName>
}
認可チェック式は、行コレクションのコンテキストで評価されます。行コレクションのコンテキストの外部でエンティティ権限をチェックする場合は、表47-12に示すようにuserGrantedResource
メソッドを使用する必要があります。
Fusion Webアプリケーション内にセキュリティを実装することは、定義上、ADFセキュリティ・フレームワークのセキュリティ・インフラストラクチャを実装することです。このため、フレームワークのセキュリティ・コンテキストを使用して、アプリケーションのポリシーやセキュリティ全体を定義するときに必要となる情報にアクセスできます。
ADFセキュリティの施行は、アプリケーションと無関係にコンテナ・レベルでオン/オフを切り替えることができるため、認可チェックを行う前に、ADFセキュリティが有効化されているかどうかを判断する必要があります。このためには、次の例に示すように、ADFセキュリティ・コンテキストのisAuthorizationEnabled()
メソッドをコールします。
if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()){ //Authorization checks are performed here. }
Fusion Webアプリケーション内のユーザー・プリンシパルがnull
になることはない(つまり、認証されていないユーザーの場合はanonymous
で、認証されたユーザーの場合は実際のユーザー名になる)ため、ユーザー・プリンシパルがnull
かどうかを確認するだけで、そのユーザーがログオンしているかどうかを判断することはできません。このため、anonymous
ユーザー・プリンシパルがユーザーが認証されていないことを表すことを考慮に入れるメソッドを使用する必要があります。このためには、次の例に示すように、ADFセキュリティ・コンテキストのisAuthenticated()
メソッドをコールします。
// ============ User's Authenticated Status ============= private boolean _authenticated; public boolean isAuthenticated() { _authenticated = ADFContext.getCurrent().getSecurityContext().isAuthenticated(); return _authenticated; }
Fusion Webアプリケーションでは、セキュアでありながらすべてのユーザーに使用可能なパブリック・ページの概念をサポートしています。さらに、Webページ上のコンポーネント(ポートレットなど)では、現在のユーザー・アイデンティティの情報を必要とします。このため、Fusion Webアプリケーションのユーザー名は決してnull
になることはありません。認証されていないユーザーがページにアクセスすると、ユーザー名anonymous
がページ・コンポーネントに渡されます。
現在のユーザー名を判別するには、次の例に示すように、ADFセキュリティ・コンテキストのgetUserName()
メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymous
を返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。
// ============ Current User's Name/PrincipalName ============= public String getCurrentUser() { _currentUser = ADFContext.getCurrent().getSecurityContext().getUserName(); return _currentUser; }
Facesベースのアプリケーションでユーザー名を判別するための従来のメソッド(FacesContext.getCurrentInstance().getExternalContext().getRemoteUser()
)では、認証されていないユーザーに対してnull
が戻されるため、そのメソッドを使用する場合は、パブリック・ユーザーのケースを処理する追加のロジックを使用する必要があります。
Fusion WebアプリケーションはJavaServer Facesベースのアプリケーションなので、次の例に示すように、Faces外部コンテキストのisUserInRole(roleName)
メソッドを使用すると、ユーザーに特定のロールが割り当てられているかどうかを判別できます。ADFセキュリティはJAASポリシーに基づくため、ロール・メンバーシップに基づくADFセキュリティ対応リソースに関連付けられたページを保護するためにJava EEセキュリティ・ロールを使用する必要はありません。ただし、ADFセキュリティ対応リソースに関連付けられていないページについては、メソッドを使用してロールをチェックできます。
この例では、便利なメソッド(checkIsUserInRole
)が定義されています。マネージドBean内でこのメソッドを使用すると、名前付きロールのメンバーシップを属性として公開し、その後EL内で使用できます。
public boolean checkIsUserInRole(String roleName){ return (FacesContext.getCurrentInstance().getExternalContext().isUserInRole(roleName)); } public boolean isCustomer() { return (checkIsUserInRole("Application Customer Role")); }
Java内からセキュリティ・ポリシーを評価するには、ADFセキュリティ・コンテキストのhasPermission
メソッドを使用できます。このメソッドは、(リソースとアクションの組合せにより定義された)権限オブジェクトを取り、ユーザーに対応する権限があればtrue
を返します。
次の例では、ページ名と必要なアクションを渡し、ユーザーの権限に基づいてtrue
またはfalse
を返すことのできる、便利な関数が定義されています。この便利な関数がページ権限を確認するため、RegionPermission
クラスを使用して、hasPermission
メソッドに渡される権限オブジェクトを定義しています。
private boolean TestPermission (String PageName, String Action) { Permission p = new RegionPermission("view.pageDefs." + PageName + "PageDef", Action); if (p != null) { return ADFContext.getCurrent().getSecurityContext().hasPermission(p); } else { return (true); }
バッキングBean内からターゲット・ページのユーザー権限を判別することはできないので、今度はこの便利なメソッドを使用して、Facesナビゲーション・アクションの結果を動的に変更できます。次の例では、1つのコマンド・ボタンがユーザーの権限に応じて異なるターゲット・ページを指していることがわかります。コマンド・ボタンのバッキングBeanは、最も高いレベルで保護されているページ(管理者ページ)から最も低いレベルで保護されているページ(パブリックのようこそページ)までview権限を確認することにより、適切なアクションを適用して、ユーザーに対して権限レベルに応じたページを表示します。適切なアクションを戻すバッキングBeanは、次の例に定義されている便利なメソッドを使用しています。
//Button Definition <af:button text="Goto Your Group Home page" binding="#{backing_content.commandButton1}" id="commandButton1" action="#{backing_content.getSecureNavigationAction}"/> //Backing Bean Code public String getSecureNavigationAction() { String ActionName; if (TestPermission("ManagerPage", "view")) ActionName = "goToManagerPage"; else if (TestPermission("EmployeePage", "view")) ActionName = "goToEmployeePage"; else ActionName = "goToWelcomePage"; return (ActionName); }
次に示すベスト・プラクティスは、ADFセキュリティ・フレームワークによるセキュリティ施行のための規則をまとめたものです。これらのベスト・プラクティスを理解することで、アプリケーションを保護して、意図したWebページにユーザーのアクセスを許可することができます。
アプリケーションを構築するときは最初からADFセキュリティを有効にしてください。
セキュリティを有効化すると、アプリケーションが実質的にロックダウンされます。また、作成する固有のADFセキュリティ対応リソースに対して明示的な権限付与を行う必要が生じます。アプリケーションを構築する際に、これらのリソースについて認識して、権限付与を行うことにより、反復しながらセキュリティをテストできます。こうして、必要な結果を実現するようにアプリケーションを構成できます。
バインド・タスク・フローの権限を定義してください。
バインド・タスク・フローを実行するプロセスでユーザーがアクセスするページは、ページごとの個別の権限チェックは行われず、タスク・フローの権限において実行されます。つまり、タスク・フローに追加するページには、ページ定義レベルでの独自のセキュリティは定義されていません。ユーザーがフローをリクエストする場合、アクセス・レベルに応じて、タスク・フローのすべてのページの表示を許可されるか、まったく許可されないかのどちらかになります。
バインド・タスク・フローの個々のページには権限を定義しないでください。
タスク・フローはユーザーによるページへの直接アクセスを妨げないことを理解することが重要です。公開されているディレクトリにあるすべてのWebページは、URLを使用してブラウザからアクセスできます。バインド・タスク・フローによって参照されるページに直接アクセスできないようにするため、関連するページ定義ファイルについて存在するすべての権限を削除します。バインド・タスク・フローのコンテキスト内でページに追加のセキュリティが必要な場合は、それらのページをサブタスク・フローに含めて、このネストされたタスク・フローに対する権限の定義を追加します。
エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすため、タスク・フローを使用してください。
タスク・フローを使用すると、エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすことができます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローの「URL起動」プロパティをurl-invoke-disallowed
に設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。「URL起動」プロパティの詳細は、「URLを使用したバインド・タスク・フローのコール方法」を参照してください。
未認可のユーザーに対する代替タスク・フローを指定してください。
エンド・ユーザーが、必要な権限を持たないリージョンでバインド・タスク・フローを起動しようとすると、リクエストしたタスク・フローではなく、空白にレンダリングされたリージョンが表示されます。リージョンが空白のままだと、リクエストしたタスク・フローが表示されない理由についてのフィードバックが提供されないため、エンド・ユーザーが当惑する可能性があります。このシナリオの発生時には、認可が必要でない代替タスク・フローを構成することを検討してください。代替タスク・フローの構成の詳細は、「未認可のユーザーによるセキュリティ保護されたタスク・フローへのアクセスの処理」を参照してください。
バインド・タスク・フロー外部の個々のページには権限を定義してください。
ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。ページ定義ファイルとそれがセキュリティ保護するWebページの間には1対1の関係があります。
ADFバインディングを使用しないページを保護する場合は、そのページに対して空のページ定義バインディング・ファイルを作成できます。
ユーザーのアクセス権に基づいてUIコンポーネントをレンダリングするにはカスタム権限を定義してください。
カスタムADF権限クラスを使用すると、ADFセキュリティを拡張して、権限で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。
UIコンポーネントによって表示される行レベル・データに対するユーザーのアクセス権を管理するには、エンティティ・オブジェクト属性権限を定義してください。
エンティティ・オブジェクトおよびエンティティ・オブジェクト属性は両方とも権限クラスを定義します。これを使用して、エンティティ・オブジェクトがデータ・ソースに対して開始する読取り、更新および削除操作の権限を定義できます。これらのデータ・モデル・プロジェクト・コンポーネントの場合、ADFセキュリティ認可を選択するために、アプリケーション・ロールに明示的に権限を付与する必要があります。ただし、エンティティ・オブジェクトの認可を有効にすると、そのエンティティ・オブジェクトによって定義されたすべてのデータ行は権限付与によって保護されます。このレベルの粒度では、表コンポーネントがWebページにレンダリングされるとき、ユーザーのアクセス権に応じて、すべてのデータが表示されるかデータがまったく表示されないかのどちらかになります。コレクション全体を保護するかわりに、データの個々の列を保護することができます。このレベルの粒度は、エンティティ・オブジェクトの個々の属性に設定する権限によってサポートされます。エンティティ・オブジェクトが保護されるとき、ユーザーが見ることができるのは表コンポーネントに表示されるデータの一部のみです。
view権限しかないユーザーに行レベルの作成/挿入操作を公開しないようにするには、タスク・フローまたはページレベルの権限付与を使用してください。
特定のユーザーだけが表の新しい行を更新できるページのアクセスを制御する適切な方法としては、タスク・フローまたはページレベルの権限付与を使用します。ただし、代替手段として、特定の操作に対応する表ボタンを保護することができます。これには、EL式を指定して、ボタンを表示するためのユーザーのアクセス権をテストします。カスタム権限が定義され、userGrantedPermission
式がボタンのRendered
プロパティに設定されているとき、十分な権限を持つユーザーのみにボタンが表示されます。これが役立つのは、ユーザー・インタフェースに表示されるページに制限がなく、行レベルデータのview権限のみがエンティティ・オブジェクトに定義されている場合です。この場合、ユーザーが表示すると、エンティティ・オブジェクトに関連付けられた編集可能な表の「Delete」ボタンは無効な状態で表示されます。ただし、入力表の場合は、ユーザーにupdate権限がなくても、ユーザー・インタフェースによってCreateInsert
操作のボタンが無効になることはありません。
JDeveloperを、ユーザー・アイデンティティのプロビジョニング・ツールとして使用しないでください。
JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、常にシステム管理者が担当します。アプリケーションをデプロイする前に、作成したすべてのユーザーおよびグループをjazn-data.xml
ファイルから削除する必要があります。
ユーザーがファイル名を使用してWebページにアクセスできないようにしてください。
Fusion Webアプリケーションをデプロイするときは、ADFコントローラの構成ファイルに定義されたビュー・アクティビティからユーザーがWebページにアクセスできるように常に許可する必要があります。ユーザーがJSPXファイルの物理名(ファイル名AllDepartments.jspx
など)を使用して直接アクセスすることは許可しないでください。
ビュー・アクティビティの名前がAllDepartments
とすると、このページをコールするには次の2つの方法があります。
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セキュリティ権限を適用します。