Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2(11.1.2.2.0) B69399-01 |
|
![]() 前 |
![]() 次 |
この章では、Fusion WebアプリケーションでADFセキュリティを有効化して、Oracle Application Development Framework (Oracle ADF)リソースのリソース権限を定義し、それらのリソースに関連するWebページをユーザーが表示できるかどうかを制限する方法を説明します。
この章の内容は次のとおりです。
ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。ADFセキュリティはOracle Platform Security Services (OPSS)アーキテクチャの上に構築されます。このアーキテクチャはそれ自体がOracle WebLogic Serverと密接に統合されています。それ以外にも、ユーザー・ログインおよびリソースの保護を処理できるセキュリティ対応モデルはありますが、ADFバインド・タスク・フロー、ADFバインディングを使用するトップレベルのWebページ(バインド・タスク・フローに含まれないページ)、および最も低いレベルの粒度でADFエンティティ・オブジェクトとその属性によって定義されたデータ列に対して宣言型で許可ベースの保護を実現するのに、ADFセキュリティは非常に適しています。このドキュメントでは、ADFセキュリティ・フレームワークが保護するこれらの個々のリソースを、ADFセキュリティ対応リソースと呼びます。
35.3項「ADFセキュリティの有効化」の説明に従い、ADFセキュリティの構成ウィザードを実行して、Fusion WebアプリケーションのADFセキュリティを有効化します。このウィザードにより、Fusion Webアプリケーション全体のADFセキュリティを構成するため、ADFセキュリティ対応リソースに関連付けられたWebページはデフォルトで保護されます。つまり、ADFセキュリティを有効化すると、アプリケーションがロックダウンされるので、そのページはデフォルトでセキュアであるとみなされます。
ADF Securityを有効にしたら、ユーザーにアクセス権を付与する必要があります。これによってユーザーは、Fusion WebアプリケーションのWebページを表示できるようになります。ユーザーに付与するアクセス権は、ページのADFセキュリティ対応リソース用に指定するセキュリティ・ポリシーとして知られています。タスク・フローの入力やWebページの表示を行うユーザー権限を制御するのは、最終的にはADFリソースにおけるセキュリティ・ポリシーになります。
ADF SecurityはJava Authentication and Authorization Service(JAAS)に基づいているので、セキュリティ・ポリシーによりプリンシパル(ユーザーまたはアプリケーション・ロール)、ADFリソースおよび権限(リソースのADF権限クラスで定義される操作)が識別されます。たとえば、Fusion Order DemoアプリケーションのStoreFrontモジュールでは、チェックアウトタスクフロー
のタスク・フローにより含まれるWebページを保護し、ログイン済ユーザー(認証済ユーザー)にのみアクセス権を付与します。実行時、ADFセキュリティ・フレームワークではタスク・フローのセキュリティ・ポリシーに対して認可チェックを実行して、ユーザーに表示操作を完了する権限があるかどうかを識別します。この場合、ユーザーがチェックアウト・プロセスを完了しようとする場合は、セキュリティ・ポリシーでは表示の権限をユーザーに付与する必要があります。
ユーザーとADFリソースに対してセキュリティ・ポリシーを定義するタスクを簡略化するために、ADF SecurityではADFバインド・タスク・フローとそこに含まれるWebページに対して1つのセキュリティ・ポリシーを定義できる包含階層を定義します。つまり、バインド・タスク・フロー・レベルでセキュリティ・ポリシーを定義すると、フローのエントリ・ポイントが保護されます。次に、そのフロー内のすべてのページが、定義されたポリシーによって保護されます。また、個々のユーザーにアクセス権を付与するかわりに、ユーザーをアプリケーション・ロールにグループ化し、そのロールにview権限を付与します。
特に、Fusion Webアプリケーションで次のADFセキュリティ対応リソースのためのセキュリティ・ポリシーを定義して、ユーザーがWebページにアクセスできるようにします。
ADFバインド・タスク・フローはタスク・フローのエントリ・ポイントを保護します。エントリ・ポイントが、そのフローに含まれるページへのユーザーのアクセスを制御します。
たとえば、新規顧客に登録プロセスを説明する一連のWebページがあるとすると、バインド・タスク・フローによって、そのプロセスのページ・ナビゲーションが制御されます。バインド・タスク・フローの詳細は、18.1.2項「バインド・タスク・フローについて」を参照してください。
バインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、認可チェックは行われません。バインドなしタスク・フローの構成ページを保護する必要がある場合は、ページに関連するページ定義ファイルの権限を定義します。
Webページに関連するADFページ定義ファイル
たとえば、ページに売上数上位の製品の要約が表示されることがありますが、これには、そのページに関連付けられたADFページ定義ファイルのADFバインディングによって調整されたデータが使用されます。ページ定義とADFバインディングの詳細は、13.7項「ページ定義ファイルでの作業」を参照してください。
ADFエンティティ・オブジェクトとエンティティ・オブジェクトの属性(データ行を参照し、ユーザー・インタフェースに表示するコレクションの定義に使用されます)
たとえば、WebページにADF Facesの表コンポーネントが表示されることがあります。これには、ADFバインディングがエンティティ・オブジェクトの属性にデータ・ソースとしてマップする列が表示されます。エンティティ・オブジェクトの場合、ADFセキュリティを有効化してもエンティティ・オブジェクト行は自動的に保護されません。エンティティ・オブジェクトまたはその属性を明示的に保護するセキュリティ・ポリシーを定義しないかぎり、ユーザーが引続きデータにアクセスできます。エンティティ・オブジェクトの詳細は、4.1項「エンティティ・オブジェクトについて」を参照してください。
JDeveloperツールではセキュリティの反復開発がサポートされるため、ADFリソースに作成するセキュリティ・ポリシーの作成、テストおよび編集が容易になります。JDeveloperでのテスト・ユーザーの作成に進み、統合WebLogic Serverでアプリケーションを実行して、保護されたリソースにエンド・ユーザーがどのようにアクセスするかをシミュレートできます。この章では、ユーザー・アイデンティティとログイン資格証明のリポジトリ(アイデンティティ・ストアと呼ばれる)を構成する方法を説明します。
注意: この章で説明するアイデンティティ・ストアはすべて、統合WebLogic Serverでの実行を目的として作成するテスト・ユーザー・アイデンティティに関係しています。35.9項「セキュア・アプリケーションのデプロイの準備」で説明するように、Oracle WebLogic Serverにデプロイするとき、通常はこのようなユーザーをステージング環境に移行することはありません。 |
ADFセキュリティを有効化したが、テスト・ユーザーにアクセス権を付与するセキュリティ・ポリシーをまだ定義していないという状況を避けるため、ADFセキュリティの構成ウィザードでは、一時的なview権限を既存のすべてのADFリソースに付与できます(view権限が各ADFリソースのセキュリティ・ポリシーに追加されます)。ウィザードのこのオプションでは、自動付与を行わずに、各リソースの作成時にADFリソースのセキュリティ・ポリシーを定義する選択肢と、view権限を自動付与してから、セキュリティ・ポリシーを定義してその権限を1つずつ置き換える選択肢があります。セキュリティの反復開発の選択肢については、35.2項「ADFセキュリティ・プロセスの概要」で説明します。
ヒント: ADFセキュリティを有効化し、ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義する前に、ADF認可チェックの規則を理解する必要があります。この規則を理解すると、計画しているセキュリティの実装に役立ちます。これらの規則の詳細は、35.1.2項「ADFセキュリティのユースケースと例」を参照してください。 |
Fusion Webアプリケーション・リソースを保護するADFセキュリティ・モデルは、Java EEセキュリティ・モデルで使用されているセキュリティ制約のURLマッピングに基づくものではありません。実際の処理でも、セキュリティ制約はJavaServer Faces (JSF) Webアプリケーションの保護には適していません。ページ・ナビゲーションが特定のページURLでサポートされないためです。たとえば、ユーザーがタスク・フローの次のページにナビゲートしても、そのフロー内ではURLは変化しません。新しいページが表示されるときに、URLベースのセキュリティ制約をトリガーする手段がありません。
かわりに、ADFセキュリティはJava Authentication and Authorization Service (JAAS)セキュリティ・モデルを実装しています。JAASは既存のJavaセキュリティ・モデル上に構築され、すべてのJAAS実装(JAASサービスのOracle Platform Security Services (OPSS)実装も含む)と統合されるため、JAASモデルはポリシー・ベースです。URLセキュリティ制約を利用するアプリケーションがセキュリティ非対応となるのは、セキュリティを管理するためにJava EEコンテナに依存するためです。これに対して、Fusion Webアプリケーションは、ユーザー定義ポリシーに基づいてリソースへのアクセスを認可するために、ADFセキュリティ・フレームワークへの明示的なコールを必要とします。つまり、ADFセキュリティを有効化して、ADFリソースのアクセス・ポリシーを定義したときに、アプリケーションがセキュリティ対応になります。
ADFセキュリティによりJAAS認可モデルの実装が簡略化されます。この実装では、ADFリソースに対するセキュリティ・ポリシーを宣言して公開し、それらのリソースに対する認可チェックを実行時に行うことで、セキュリティ対応アプリケーションの作成に必要な作業を最小限に抑えます。
JDeveloperのポリシー・ストアはファイルベースで、ADFリソースのセキュリティ・ポリシーを定義する権限と呼ばれるエントリのリストを含みます。権限エントリには、保護対象のリソースに操作(たとえば、ADFバインド・タスク・フローに関連付けられたWebページへのアクセス)を実行するためにユーザーに付与されるすべての権限が含まれます。権限はポリシー・ストアでアプリケーション・ロール・プリンシパルに対して付与されます。
ADFセキュリティによってJAASモデルが拡張されます。ADFセキュリティ・フレームワーク権限クラスで指定されるアクションを使用して権限を定義できるようになります。このようなクラスはADFリソースに固有であり、リソースでサポートされる操作にアクションをマッピングします。Fusion Webアプリケーションのポリシー・ストアに含まれる権限では、次の項目が指定されます。
リソースの権限クラスによって定義されるアクションと、アプリケーションのADFリソース・インスタンスを関連付ける、1つ以上の権限(現在、バインド・タスク・フローとページ定義リソースでサポートされるのは表示アクションのみです)
権限の付与先として、アプリケーションによって定義されるアプリケーション・ロール(同じアクセス権を付与するメンバー・ユーザーまたはエンタープライズ・ロール(オプション)を移入します)
エンティティ・オブジェクトの場合、権限クラスでは読取り、削除および更新アクションが定義されます。
ADF権限クラスとサポートされるアクションの詳細は、付録C「ADFセキュリティ権限の付与」を参照してください。
ADFセキュリティを使用すると、Webアプリケーションを現実のビジネス・セキュリティ要件に適応させやすくなります。アプリケーション・リソースへのパスを保護するのではなく、JAASによってADFリソースに対する表示操作を保護するためです。JAASベースのADFセキュリティでは次の機能が提供されます。
ADFリソース(バインド・タスク・フローなど)の宣言セキュリティのサポート
Java EEセキュリティはURLベースまたはページベースであるため、カスタム・コードなしではナビゲーションを制御できません。ADFセキュリティでは、ユーザーがタスク・フローを開始できるかどうかを制御できます。つまり、タスク・フローに対する1つのセキュリティ・ポリシーによって、複数のWebページへのアクセスを制御できます。また、宣言セキュリティではアクセス・パスではなくADFリソースを保護できるため、アプリケーションの別の場所でADFリソースを再利用するときも、保護された状態が維持されます。
権限の継承を可能にするアプリケーション・ロールを使用した権限割当ての簡略化
Java EEセキュリティ制約で使用されるJava EEセキュリティ・ロールが平面的であるのに対し、JAAS権限を付与するアプリケーション・ロールはネストすることができ、Oracle WebLogic Serverドメインが定義するエンタープライズ・ロールにマップすることもできます。
セキュリティ・コンテキストで、ADFリソースにアクセスするためにEL式で使用するユーティリティ・メソッド
ADFセキュリティのEL式ユーティリティ・メソッドを使用すると、ユーザーが既知の操作を実行できるかどうかを判定することができます。たとえば、ユーザーが特定のタスク・フローを表示できるかどうかを判定することができます。
また、JDeveloperを使用すると、統合WebLogic Serverでセキュリティをテストするためのテスト・ユーザーとパスワードをすぐに作成できます。Oracle WebLogic Serverにデプロイする準備ができたら、アプリケーション固有の認可ポリシーをサーバーに移行できます。管理者はアプリケーションがLDAPユーザー・リポジトリを使用するように構成できます。
表35-1に、ADFセキュリティの有効化により、アプリケーションや様々なADFセキュリティ対応リソースが受ける影響を示します。ADFセキュリティを最も効果的に使用する方法の詳細は、35.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。
表35-1 ADFセキュリティ対応リソースのサマリー
ADFリソース | ADFによるセキュリティの施行方法 | アクセス権の付与方法 |
---|---|---|
すべてのユーザー・インタフェース・プロジェクトのバインド・タスク・フロー |
デフォルトで保護されます。ユーザーがバインド・タスク・フローを開始するために権限が必要です。 |
タスク・フローの権限を定義します。 バインド・タスク・フローのWebページに関連付けられている個々のページ定義ファイルの権限は、定義しないでください。 |
すべてのユーザー・インタフェース・プロジェクトのページ定義ファイル |
デフォルトで保護されます。ページ定義に関連付けられたページをユーザーが表示するために権限が必要です。 |
Webページがバインド・タスク・フローに含まれる場合は、このタスク・フローに対する権限を定義します。 Webページがバインド・タスク・フローに含まれない場合、またはWebページがバインドなしタスク・フローに含まれる場合は、ページ定義のみの権限を定義します。 バインドなしタスク・フローはADFセキュリティ対応コンポーネントではないため、権限を定義できないことに注意してください。 |
データ・モデル・プロジェクトのエンティティ・オブジェクト |
デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。 |
データ・コレクション全体レベルでアクセスを制御する必要がある場合のみ、データを保護するためにエンティティ・オブジェクトの権限を定義します。保護対象のエンティティ・オブジェクトを参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 エンティティレベルのセキュリティは注意して使用してください。または、エンティティ属性レベルでのセキュリティの定義を検討します。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。 |
データ・モデル・プロジェクトのエンティティ・オブジェクトの属性 |
デフォルトでは保護されません。ユーザーによるアクセスを防ぐために権限が必要です。 |
データ・コレクションの列レベルでアクセスを制御する必要がある場合は、データを保護するためにエンティティ・オブジェクト属性の権限を定義します。保護対象のエンティティ属性を参照するすべてのコンポーネントによって表示されるユーザー・インタフェースのデータが保護されます。 データ・モデル・プロジェクトの権限は、エンティティ・オブジェクトそのもののメタデータとして保存され、ADFポリシー・ストアには含まれないことに注意してください。 |
ADFセキュリティの処理を開始する前に、その他のADF機能を理解しておくと役に立ちます。次に、関連する他の機能へのリンクを示します。
Oracle Platform Security Servicesのセキュリティ機能の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
Fusion WebアプリケーションのADFリソースを保護するときはJDeveloperを使用します。ADFセキュリティでは、アプリケーションのバインド・タスク・フロー、およびバインドなしタスク・フローに含まれるすべてのWebページが保護されます。この保護を有効にするには、ADFセキュリティの構成ウィザードを実行し、その後、ADFセキュリティ・ポリシーを定義して各リソースのユーザー・アクセス権を定義します。
アプリケーションのユーザー・インタフェースを作成するときは、ADFセキュリティの構成ウィザードをいつでも実行できます。選択肢は次のとおりです。
UIプロジェクトのWebページの作成と、関連するADFリソースのセキュリティ・ポリシーの定義を繰り返しながら行います。
UIプロジェクトのすべてのWebページの作成を完了してから、関連するADFリソースのセキュリティ・ポリシーを定義します。
設計とテストの反復プロセスは、様々な設計時ツールでサポートされています。
新しいバインド・タスク・フローまたはADFページ定義ファイルをユーザー・インタフェース・プロジェクトで作成するたびに、新しいADFリソースがjazn-data.xml
ファイルの概要エディタに表示されます。概要エディタを使用し、アプリケーション全体に関してWebページに関連付けられたADFリソースのセキュリティ・ポリシーを定義します。また、概要エディタを使用してADFリソースをソートすると、セキュリティ・ポリシーがまだ定義されていないADFリソースを簡単に見つけることができます。
ADFアイデンティティ・ストアの少数のテスト・ユーザーをプロビジョニングするには、別のエディタを使用します。JDeveloperに作成するアイデンティティ・ストアを使用して、ユーザー資格証明(ユーザーIDとパスワード)を定義できます。エディタには、作成するユーザーと、ユーザーを割り当てるアプリケーション・ロールの関係も表示され、ADFセキュリティ・ポリシーで定義されるアクセス権を付与することができます。
JDeveloperは設計時に、ポリシー・ストアとアイデンティティ・ストアのすべての変更内容をアプリケーション全体で1つのファイルに保存します。開発環境では、これはjazn-data.xml
ファイルです。エディタを使用してjazn-data.xml
ファイルを構成すると、統合WebLogic Serverでアプリケーションを実行でき、ポリシー・ストアの内容がドメインレベルのストア(system-jazn-data.xml
ファイル)に追加されます。また、テスト・ユーザーは、統合WebLogic Serverがアイデンティティ・ストアとして使用する埋込みLDAPサーバーに移行されます。ドメインレベルのストアを使用すると、作成したテスト・ユーザーとしてログオンしてセキュリティ実装をテストできます。
セキュリティに関するすべての設計時ツールは、図35-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とパスワードを使用してアプリケーションにログインします。エンタープライズ・ロールは、ユーザーをグループ化して、そのグループにアプリケーション・ロールを関連付けるための論理ロールです。エンタープライズ・ロールはテストのためには必要ありません。詳細は、35.4.3項「エンタープライズ・ロールとアプリケーション・ロールについて」を参照してください。
作成したユーザーおよびエンタープライズ・ロール(オプション)を1つ以上のアプリケーション・ロールに関連付けます。
メンバー・ユーザー複数のアプリケーション・ロールのアクセス権を付与する必要がある場合は、1メンバー・ユーザーを複数のアプリケーション・ロールに含めることができます。
デフォルトのログイン・ページをカスタム・ログイン・ページで置き換えます(オプション)。
ADFセキュリティの構成ウィザードで生成されるデフォルトのログイン・ページは、ADF Facesコンポーネントを利用できません。これは、ADFセキュリティ・ポリシーのテスト用としてのみ便宜的に提供されています。
JDeveloperでアプリケーションを実行し、任意のADFセキュリティ対応リソースにアクセスします。
最初にADFセキュリティ対応リソースにアクセスしようとするとき、セキュリティ・フレームワークによってログインを求められます。
ログインし、予定どおりにページとそのリソースにアクセスできることを確認します。
ログインすると、セキュリティ・フレームワークによって、リソースにアクセスするためのユーザーの権限がチェックされます。たとえば、予期していない401未認可ユーザーのエラーを受け取った場合は、35.11.4項「ADFセキュリティの操作のベスト・プラクティス」に従って権限を作成したことを確認します。
ステージングの準備
ステージング環境または本番環境でOracle WebLogic Serverにデプロイするためにセキュア・アプリケーションを準備する手順:
すべてのADFセキュリティ対応リソースについてtest-all
ロールのすべての権限を削除し、定義した権限で置き換えます。
ADFリソースはデフォルトで保護されるため、アプリケーションをテストする開発者にview権限が付与されるのは、セキュリティ・ポリシーが定義された後です。ADFセキュリティの構成ウィザードでは、test-all
ロールに対して、すべてのADFリソースへのアクセスを可能にする権限を生成するオプションがあります。企業のセキュリティを危険にさらさないために、test-all
ロールに対するすべての一時権限は、自ら定義した明示的な権限でいずれ置き換える必要があります。
作成したすべてのユーザー・アイデンティティを削除します。
JDeveloperはアイデンティティ・ストアのプロビジョニング・ツールとして使用しないでください。また、テスト目的で作成したユーザー・アイデンティティをアプリケーションとともにデプロイしないように注意してください。ユーザー・アイデンティティをアプリケーションとともにデプロイすると、悪質なユーザーが予想外のアクセス手段を獲得してしまう恐れがあります。かわりに、ドメインレベルのアイデンティティ管理システムによって提供されるツールを使用して、ユーザー・アイデンティティを構成する作業を、システム管理者が担当します。
ポリシー・ストアに表示されるアプリケーション・ロールが、最終的に管理者がドメインレベルのグループにマッピングするロールであることを確認します。
ADF Facesリソース・ファイルを保護するセキュリティ制約を定義するかどうかを決定します。
リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルはADFセキュリティによって保護されませんが、アプリケーションにアクセスしようとするすべてのユーザーを認証する必要がある場合は、それらのファイルのJava EEアクセス・パスを保護できます。
完成したポリシー・ストアと資格証明ストアをターゲット・サーバーに移行します。
アプリケーションがOracle WebLogic環境のサーバーにデプロイされると、アプリケーションのポリシーと資格証明は自動的にドメイン・ポリシー・ストアに移行されます。これらのストアの自動的な移行は、ターゲット・サーバーの構成によって制御されます。JDeveloper外部でデプロイメントを実行するためにOracle Enterprise Managerを使用する場合、移行構成設定はこのツールで指定できます。jazn-data.xml
ポリシーおよびcwallet.sso
資格証明の移行の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
ADFセキュリティをOPSSに統合するための構成プロセスを単純にするため、JDeveloperではADFセキュリティの構成ウィザードが用意されています。このウィザードは、ADFセキュリティを使用してFusion Webアプリケーションを保護する最初の一歩となります。このウィザードはアプリケーションレベルのツールなので、実行すると、アプリケーションに含まれるすべてのユーザー・インタフェース・プロジェクトでADFセキュリティが有効になります。
注意: ADFセキュリティの構成ウィザードにより、アプリケーションのすべてのユーザー・インタフェース・プロジェクトに対してADFセキュリティが有効になります。このウィザードを実行した後で、バインド・タスク・フローに含まれる任意のWebページや、ADFページ定義に関連付けられたすべてのWebページを表示するための権限をユーザーに許可する必要があります。したがって、ウィザードを実行した後では、セキュリティ・ポリシーを定義してユーザーにview権限を付与するまで、アプリケーションは基本的にロックダウンされます。このプロセスの概要は、35.2項「ADFセキュリティ・プロセスの概要」を参照してください。 |
ADFセキュリティの構成ウィザードでは、認証と認可を個別に有効化することを選択できます。選択肢は次のとおりです。
ユーザー認証のみを有効化します。
ADFセキュリティでは認証にJava EEコンテナ管理のセキュリティを利用しますが、認証を有効化すると、ユーザーのログインとログアウトにはADF認証サーブレットを使用し、Webページの保護にはコンテナ管理のセキュリティ制約を定義することになります。
ユーザー認証を有効化し、認可も有効化します。
認可を有効化することは、ADFリソースに対してセキュリティ・ポリシーを作成することで、Fusion Webアプリケーションに対するアクセスの制御を意図することを意味します。
ADFセキュリティ・フレームワークではこれら2つの方法がサポートされるため、Java EEセキュリティを実装した上で、ADF認証サーブレットを使用したログインとログアウトに対応することができます。ADF認証サーブレットを有効化する利点は、ユーザーがアプリケーションに最初にアクセスするとき、サーブレットが自動的にユーザーにログインを求めることです。ADF認証サーブレットでも、認証が正常に終了すると、定義された開始ページにユーザーがリダイレクトされます。また、ユーザーがアプリケーションからログアウトする際にページ・リダイレクトを管理することもできます。ADFセキュリティで提供されるこのようなリダイレクト機能は、コンテナ管理セキュリティだけを使用する場合にはありません。
ベスト・プラクティス: Java EEセキュリティ制約では、タスク・フローと連動してタスク・フローの現在のページを保護することはできません。このため、ADFタスク・フローを含むようにアプリケーションが設計されている場合、コンテナ管理セキュリティは効果的なソリューションではありません。ADFタスク・フローを使用する場合は、ADFセキュリティの構成ウィザードで「ADF認証および認可」オプションを選択します。このオプションを選択すると、セキュリティ・ポリシーを定義してアプリケーションのタスク・フローを保護できます。 |
ADFセキュリティはWebコンテナに認証を委任するため、ADFセキュリティの構成ウィザードを実行すると、ウィザードによってWebコンテナで使用する認証方式の構成を求められます。認証で最も一般的に使用されるタイプは、HTTP Basic認証とフォームベース認証です。Basic認証では、ユーザーがユーザー名とパスワードを入力できるようにブラウザのログイン・ダイアログが使用されます。Basic認証の場合、ユーザーからの資格証明がブラウザによりキャッシュされるため、ログアウトできないことに注意してください。Basic認証は、カスタム・ログイン・ページを作成しないでアプリケーションをテストする場合に便利です。フォーム認証では、アプリケーションの開発者がカスタムのログインUIを指定することができます。フォームベース認証を選択すると、ウィザードを使用して単純なログイン・ページを生成することもできます。デフォルトのログイン・ページは、統合WebLogic Serverでアプリケーションをテストするときに役立ちます。
注意: 生成されるログイン・ページは単純なJSPファイルまたはHTMLファイルであるため、ADF Facesコンポーネントを使用して変更することはできません。ADF Facesコンポーネントを使用するカスタム・ログイン・ページでデフォルトのログイン・ページを置き換える方法の詳細は、35.7項「ログイン・ページの作成」を参照してください。 |
作業を始める前に、次のようにします。
ADFセキュリティの構成ウィザードの知識があると役立ちます。詳細は、35.3項「ADFセキュリティの有効化」を参照してください。
アプリケーションに対してADFセキュリティを有効化する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。
ADFセキュリティ・ページではデフォルトで「ADF認証および認可」オプションが選択されています。「次へ」をクリックします。
デフォルト・オプションが選択された状態でウィザードを実行すると、アプリケーションはADFセキュリティ対応リソースの認可を施行します。ADFリソースの認可の施行とは、アプリケーションのWebページにアクセスできるようにするために、それらのリソースに対するセキュリティ・ポリシーを定義することを意味します。定義を行うまでは、ADFバインド・タスク・フローに依存するすべてのページとADFページ定義は保護された状態になります。
ADFセキュリティを構成するためのウィザードの他の2つのオプションは、ADFセキュリティを有効化する場合は使用しないでください。これらのオプションを使用すると、一時的にADFセキュリティを無効化して、35.10項「ADFセキュリティの無効化」で説明するようにセキュリティ保護なしでアプリケーションを実行できます。
具体的には図35-2に示すように、ウィザードの最初のページには3つのオプションがあり、デフォルトのオプションとして「ADF認証および認可」が有効になっています。
「ADF認証および認可」(デフォルト)では、ADF認証サーブレットが有効化され、ユーザーがログインおよびログアウトする際に構成済のWebページにリダイレクトできます。このオプションを使用すると、ADF認可を有効化して、ADFリソースについて定義したセキュリティ・ポリシーに対する認可チェックを施行することもできます。このオプションを選択した場合は、アプリケーション・ロールを定義し、明示的な権限をそのロールに割り当てて、ADFセキュリティ対応リソースへのアクセスを管理します。
「ADF認証」を選択すると、アプリケーションのページが最初にアクセスされたときに、ADF認証サーブレットがユーザーのログインを要求します。また、Java EEアプリケーション・ルート「/」をJava EEセキュリティ制約(ユーザー認証をトリガーする)にマップすることで、ページ・リダイレクトがサポートされます。ウィザードによりADF認可が無効になるため、ADFリソースに対するセキュリティ・ポリシーが存在するかどうかに関係なく、認可チェックは実行されません。一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。
「ADFセキュリティ・コンフィギュレーションの削除」を選択すると、ADF認証サーブレットが無効化され、ADF Securityはポリシー権限を確認できなくなりますが、既存のポリシー・ストアは変更されません。この場合、標準的なJava EEセキュリティを使用して、ユーザーに対して、ログインし、認証を受け、URLセキュリティ制約に対してアクセス権をテストすることことを求めることができます。ウィザードをこのオプションで実行すると、ADFリソースに対するきめ細かいセキュリティが無効になることに注意してください。
「認証タイプ」ページで、ユーザーがログイン情報を送信したときにアプリケーションで使用する認証タイプを選択します。「次へ」をクリックします。
ADF認証サーブレットがBasic認証で作動せず、ログアウトしたユーザーがリソースにアクセスできるという問題が明らかになっています。Basic認証のかわりにフォームベース認証を使用してください。この問題の詳細は、35.7.5項「ADFサーブレットのログアウトとブラウザのキャッシュについて」を参照してください。
「フォームベース認証」を選択した場合は、「デフォルト・ページの生成」を選択して、ウィザードでデフォルトのログイン・ページおよびエラー・ページを生成できます。デフォルトでは、図35-3に示すように、ウィザードによってユーザー・インタフェース・プロジェクトのトップ・レベルにログイン・ページとエラー・ページが生成されます。場所を変更する場合は、ユーザー・インタフェース・プロジェクトを基準としたフルパスを指定します。
自動ポリシー付与ページでは、デフォルトで選択されている「自動付与なし」オプションをそのままにしておきます。「次へ」をクリックします。
「自動付与なし」を選択すると、アプリケーション固有の明示的な権限を定義する必要があります。test-all
アプリケーション・ロールを使用すると、ADF認可により施行される制限アクセスなしで、アプリケーション・リソースを実行してテストできるので便利です。ただし、このようにすると、アプリケーションの一部のリソースが保護されない状態になるリスクが高まります。
または、ウィザードを使用してtest-all
アプリケーション・ロールに権限を付与できます。test-all
ロールへの権限付与を有効化すると、アプリケーションのアクセス・ポリシーを調整する用意ができるまで、ADFリソースに対する明示的な権限の定義を延期することができます。自動付与の有効化を決めた場合は、test-all
ロールの権限をアプリケーションの明示的な権限で置き換えるまで、アプリケーション開発をあまり進めずに、アプリケーションの内容が確定してしまわないようにしてください。明示的な権限により、ユーザーがこれらのリソースにアクセスするために必要な権限(たとえばページのview
)が確立されます。test-all
ロールの詳細は、35.8.3項「組込みtest-allアプリケーション・ロールを使用する方法」を参照してください。
「認証されたようこそページ」で、ログイン後にユーザーを特定のWebページに移動させる場合に「認証の成功時にリダイレクト」を選択します。「次へ」をクリックします。
「認証の成功時にリダイレクト」オプションを選択しないと、ログインを開始したページにユーザーが戻されます。ただし、ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して新しいブラウザ・ウィンドウまたはタブを開くと、ようこそページの定義がアプリケーションのweb.xml
ファイルにない場合は、403エラーまたは404エラーを受け取ります。このオプションを使用して、ようこそページを指定すると、その定義がアプリケーションのweb.xml
ファイルに追加されます。
指定するWebページにADF Facesコンポーネントが含まれる場合、/faces/
のコンテキストでページを定義する必要があることに注意してください。たとえば、adffaces_welcome.jspx
のパスは、「ようこそページ」フィールドに、/faces/adffaces_welcome.jspx
と表示されます。
他のリダイレクト・オプションの指定の詳細は、35.7.4項「認証後にユーザーをリダイレクトする方法」を参照してください。
サマリー・ページで選択内容を確認し、「終了」をクリックします。
ADFセキュリティ・ページでデフォルトの「ADF認証および認可」オプションを選択して「ADFセキュリティの構成」ウィザードを実行すると、次のようになります。
ADF認証が有効化されます。ユーザーにログインを求め、ページ・リダイレクトを行います。
ADF認可チェックが有効化され、認可ユーザーのみがADFリソースにアクセスできます。
ウィザードによりセキュリティ関連の構成ファイルがすべて更新され、デフォルトでADFリソースがセキュリティ保護されます。表35-2に、ADFセキュリティの設定ウィザードにより更新されるファイルを示します。
表35-2 ADF認証および認可で更新されるファイル
ファイル | ファイルの場所 | ウィザードの構成 |
---|---|---|
|
ユーザー・インタフェース・プロジェクトに相対する |
|
|
Webアプリケーション・ワークスペースに相対する |
|
|
Webアプリケーション・ワークスペースに相対する |
|
|
Webアプリケーション・ワークスペースに相対する |
|
|
.Webアプリケーション・ワークスペースに相対する |
|
認証はWebコンテナに委任されるため、ウィザードはweb.xml
ファイルを更新して、ADF認証サーブレットによる認証を有効化します。例35-1に示すように、ADF認証サーブレットのサーブレット・マッピングが定義され、2つのJava EEセキュリティ制約allPages
およびadfAuthentication
がweb.xml
ファイルに追加されます。
例35-1 web.xmlファイルのADF認証ディスクリプタ
<servlet> <servlet-name>adfAuthentication</servlet-name> <servlet-class> oracle.adf.share.security.authentication.AuthenticationServlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> ... <servlet-mapping> <servlet-name>adfAuthentication</servlet-name> <url-pattern>/adfAuthentication</url-pattern> </servlet-mapping> ... <security-constraint> <web-resource-collection> <web-resource-name>allPages</web-resource-name> <url-pattern>/</url-pattern> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>adfAuthentication</web-resource-name> <url-pattern>/adfAuthentication</url-pattern> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint>
allPages
制約は「/
」URLにマッピングされるため、Java EEアプリケーション・ルートを保護します。このマッピングにより、ADFセキュリティがアクセスされる前でも、ADF認証サーブレットがユーザー認証を動的にトリガーできるようになります。ユーザーがアプリケーションに最初にアクセスするときに、コンテナがユーザーにユーザー名とパスワードを求めるように強制します。その後、ユーザーがADFセキュリティで保護されたページにアクセスするときは、ユーザーを認証したりADF認証サーブレットにリダイレクトしたりする必要はありません。
注意: ログインを明示的にトリガーするログイン・リンクまたはログイン・ボタンを用意する場合は、 |
アプリケーションのすべてのユーザーがログインできる必要があるため、adfAuthentication
リソースに定義されるセキュリティ制約を使用すると、すべてのユーザーがこのWebリソースにアクセスできるようになります。このように、制約に関連付けられるセキュリティ・ロールはすべてのユーザーを含む必要があります。このタスクを簡略化するため、Java EE valid-users
ロールが定義されています。weblogic.xml
ファイルでは、このロールが、Oracle WebLogic Serverによって定義された暗黙のusers
グループにマッピングされます。このマッピングにより、すべてのユーザーがこのロールを持つことが保証されます。35.3.7項「valid-usersロールについて」で説明するように、Oracle WebLogic Serverは、正しく認証されたすべてのユーザーをusers
グループのメンバーとして構成するためです。
注意:
|
認可を有効化するため、ウィザードはadf-config.xml
ファイルを更新し、例35-2
に示すように<JaasSecurityContext>
要素のauthorizationEnforce
パラメータをtrueに設定します。
例35-2 adf-config.xmlファイルでのAuthorizationEnforceフラグの有効化
<JaasSecurityContext initialContextFactoryClass="oracle.adf.share.security.JAASInitialContextFactory" jaasProviderClass="oracle.adf.share.security.providers.jps.JpsSecurityContext" authorizationEnforce="true" authenticationRequire="true"/>
認可が有効化されると、ユーザーがコンテナによって認証された後で、ADFセキュリティ・コンテキストがHttpServletRequest
からユーザー・プリンシパルを取得します。ユーザーはユーザー名とパスワードを送信し、そのデータがユーザー情報が格納されているアイデンティティ・ストアのデータと比較されます。一致するデータが見つかると、要求の発信元(ユーザー)が認証されます。その後、ユーザー名はADFセキュリティ・コンテキストに格納され、認可権を判別するために他のセキュリティ関連情報(ユーザーが所属するグループなど)を取得する際にアクセスできます。ADFセキュリティ・コンテキストのアクセス方法の詳細は、35.11.3項「ADFセキュリティ・コンテキストからの情報の取得」を参照してください。
ウィザードで生成されるログイン・ページおよびエラー・ページは単純なHTMLページです。ユーザー・インタフェース・プロジェクトの最上位フォルダに追加されます。生成されるログイン・ページでは、標準のj_security_check
アクションを含むフォームが定義されます。このフォームは、コンテナのセキュリティ・モデル内のj_SecurityCheck
メソッドに対する入力としてユーザー名とパスワードを取ります。
ウィザードはweb.xml
ファイルを更新し、例35-3に示すように、フォームベース認証を指定してページの場所を指定します。
最初にADFセキュリティの構成ウィザードを実行して認証と認可を有効にすると、アプリケーション・レベルでADFリソースが保護されます。さらに、ユーザー・インタフェース・プロジェクトについて特定のプロジェクトレベル設定(認証のタイプや認証のようこそページなど)を選択します。ウィザードによって、選択するプロジェクトのweb.xml
ファイルにWebアプリケーション設定が追加されます。アプリケーションに複数のユーザー・インタフェース・プロジェクトとweb.xml
ファイルが含まれる場合は、ウィザードに戻り、選択する別のユーザー・インタフェース・プロジェクトのweb.xml
ファイルでこれらの設定を構成します。
Java EEコンテナ管理セキュリティでは標準のログイン方法が定義されます。ログアウトしてセキュア・アプリケーション内にとどまる標準の方法はありません。したがって、ログイン・プロセスはコンテナに委任されますが、ログアウト・プロセスはADF認証サーバーそのもので処理されます。
ADFセキュリティ対応リソースに依存するページが最初にアクセスされたとき、サブジェクトが定義されていないと、anonymous
ユーザー・プリンシパルとanonymous-role
ロール・プリンシパルを含むサブジェクトを構成するようにOPSSがJPSFilter
によって構成されます。このロール・プリンシパルを使用すると、認証されていないユーザーが、どのADFセキュリティ対応リソース(ADFバインド・タスク・フローまたはページ定義など)にも関連付けられていないパブリックWebページにアクセスできます。
ADFセキュリティ対応リソースに関連付けられているページの場合は、無名ユーザーがページにアクセスできるようにするには、view
権限をanonymous-role
に明示的に付与する必要があります。無名ユーザーへの権限付与の詳細は、35.5.1項「ADFリソースを公開する方法」を参照してください。
ADFセキュリティの構成ウィザードを使用して、アプリケーションのすべてのADFセキュリティ対応リソースのview権限を付与するために、組込みtest-all
アプリケーション・ロールへの自動付与を有効にすることができます。権限(自動view権限またはユーザー定義の明示的な権限)が付与されないと、ADFセキュリティの認可チェックの施行により、アプリケーションの実行とリソースへのアクセスを行えなくなります。test-all
アプリケーション・ロール機能を有効にしてウィザードを実行し、その後、自動view権限を明示的な権限で段階的に置き換えることができます。test-all
アプリケーション・ロールの権限が設定された状態ではアプリケーションをデプロイしないでください。この機能のためにすべてのADFリソースが公開されるためです。ウィザードで組込みtest-all
アプリケーション・ロールの有効化を選択する場合は、アプリケーションをデプロイする前に35.9.1項「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」を参照してください。
valid-users
ロールは、ADF Securityによって定義されたJava EEセキュリティ・ロールです。このロールにより、web.xml
ファイルで定義されたadfAuthentication
サーブレットWebリソースにすべてのユーザーがアクセスできることが保証されます。ADFセキュリティの構成ウィザードはweblogic.xml
ファイルを更新し、例35-4に示すように、このADFセキュリティ・ロールをusers
プリンシパルにマッピングします。Oracle WebLogic Serverは、正常に認証されたすべてのユーザーをusers
グループのメンバーとして構成するため、このマッピングによりすべてのユーザーがこのロールを持ちます。
例35-4 weblogic.xmlファイルでのvalid-usersロールのマッピング
<security-role-assignment> <role-name>valid-users</role-name> <principal-name>users</principal-name> </security-role-assignment>
users
プリンシパル名はOPSSによって定義される特別なプリンシパルで、エンタープライズ・ロールと似た目的で使用されます。このプリンシパルは、実行時に、OPSSによって、正常に認証されたサブジェクトに自動的に追加されます。セキュリティの観点から、valid-users
ロールがADF認証をサポートするのは、セキュリティ制約だけを使用してWebリソースへのアクセスを制御する必要がある場合のみです。このマッピングの最終的な結果はJava EEセキュリティに全面的に依存します。JAAS権限は関係ありません。
アプリケーション・ロールを作成して、アプリケーションのポリシー要件を表し、同じview権限を持つユーザーのグループを定義します。アプリケーション・ポリシー・ストアに作成するアプリケーション・ロールは、お使いのアプリケーション固有のものです。たとえば、ワーク・フローのコンテキストでは、fod-customer
、fod-productSpecialist
、fod-supervisor
およびfod-admin
などのアプリケーション・ロールがあります。fod
はこれらのロールがFusion Order Demoアプリケーション固有であることを示します。
実行時には、ユーザーがメンバーとして定義されているアプリケーション・ロールにより、ユーザーにアクセス権が付与されます。このように、セキュリティ・ポリシーを定義する前に、権限の付与先にするアプリケーション・ロールをポリシー・ストアに含める必要があります。それは、ユーザーが定義するアプリケーション・ロール(fod-users
など)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-role
またはanonymous-role
)のいずれかでもかまいません。JDeveloperで提供される組込みアプリケーション・ロールを使用すると、35.5.1項「ADFリソースを公開する方法」で説明するようにADFリソースを公開できます。
アプリケーション・ロールを作成した後は、次の手順を実行します。
権限をアプリケーション・ロールに付与します。35.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
テスト・ユーザーを各アプリケーション・ロールに関連付けます。35.6項「テスト・ユーザーの作成」を参照してください。
ベスト・プラクティス: ADFセキュリティ・フレームワークは、アプリケーション・ロールまたは個々のユーザーに付与された権限に基づいて、ロールベースのアクセス制御メカニズムを施行します。セキュリティのテストのみを行う必要があり、ユーザー・グループを作成する必要がなくても、アプリケーション・ロール(少なくとも1ユーザー・メンバーを含む)を作成しなければなりません。後でADFリソースのセキュリティ・ポリシーを定義するとき、アプリケーション・ポリシー・ストアの概要エディタを使用して、権限に対してアプリケーション・ロールを選択できます。 |
JDeveloperでは、アプリケーション・ロールをjazn-data.xml
ファイルのポリシー・ストアに格納できます。これは、「アプリケーション・リソース」パネルのDescriptors/META-INFノードに表示されます。
注意: アプリケーション・ロールを作成するときは、新しいアプリケーション・ロールをアイデンティティ・ストアではなくポリシー・ストアに追加してください。アイデンティティ・ストアに追加するロールによって、エンタープライズ・セキュリティ・ロールが定義されます。また、このロールは、アイデンティティ・ストア内のユーザーをグループ化するときに役立ちます。エンタープライズ・ロールの詳細は、35.4.3項「エンタープライズ・ロールとアプリケーション・ロールについて」を参照してください。 |
jazn-data.xml
ファイルのポリシー・ストアにアプリケーション・ロールを作成するには、jazn-data.xml
ファイルの概要エディタのアプリケーション・ロール・ページを使用します。このエディタを使用すると、アイデンティティ・ストアのメンバーと、作成するアプリケーション・ロールの関係を表示できます。
作業を始める前に、次のようにします。
アプリケーション・ロールについて理解しておくと役立ちます。詳細は、35.4項「アプリケーション・ロールの作成」を参照してください。
アプリケーション・ロールを作成する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。
jazn-data.xml
概要エディタのアプリケーション・ロール・ページで、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。
JDeveloperによってjazn-data.xml
ファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。
「ロール」リストで「新規」アイコンをクリックします。
「名前」フィールドにロール名を入力します。他のいずれかのフィールドをクリックすると、アプリケーション・ロールがポリシー・ストアに追加されます。
テスト・ユーザーをアイデンティティ・ストアにすでに設定している場合は、35.6.3項「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」に従ってユーザーとロールをマッピングできます。
アプリケーション・ロールをポリシー・ストアに追加すると、アプリケーション・ワークスペースを基準とするsrc/META-INF
ディレクトリにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。アプリケーション・ロールは、例35-5に示すように<policy-store>
内の<app-role>
要素に定義されます。ポリシー・ストアの<application>
要素にアプリケーションが指定されるため、作成するすべてのアプリケーション・ロールは、実行時にそのアプリケーションに対してのみ有効になります。他のWebアプリケーションは、独自のアプリケーション・ロールのセットを含むポリシー・ストアを定義できます。
例35-5 ポリシー・ストアでのアプリケーション・ロール定義
<policy-store> <applications> <application> <name>StoreFrontModule</name> <app-roles> <app-role> <name>fod-users</name> <display-name>FOD Users</display-name> <class>oracle.security.jps.service.policystore. ApplicationRole</class> </app-role> ... </app-roles> <jazn-policy> ... </jazn-policy> </application> </applictions> </policy-store>
エンタープライズ・ロールは、(アプリケーション・ポリシー・ストアではなく)ドメイン・ポリシー・ストアで管理されるロールです。エンタープライズ・ロールは、ドメインにデプロイされているすべてのアプリケーションで使用でき、ドメイン・アイデンティティ・ストアに定義されます。通常は、ドメインに構成された認証プロバイダの順序付けられたリストによって表されます。
アプリケーション・ロールはFusion Webアプリケーションで使用されるロールです。これはアプリケーション固有であり、アプリケーション・ポリシーで定義するものなので、Java EEコンテナで認識できるとはかぎりません。アプリケーション・ロールは、アプリケーションに定義されたユーザーとロールのみを含むという意味でスコープ指定されています。アプリケーション・ロールはエンタープライズ・ロールにマッピングする必要があります。
jazn-data.xml
ファイルの概要エディタを使用して、アイデンティティ・ストアに追加するユーザーをグループ分けするためのエンタープライズ・ロールを作成します。この仕組みを使用すると、35.6.3項「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」で説明するように、定義したアプリケーション・ロールにすべてのユーザー・グループを割り当てて、ADFセキュリティ・ポリシーで定義されたアクセス権を付与することができます。
ただし、統合WebLogic Serverでは、JDeveloper内でアプリケーションを実行するためにエンタープライズ・ロールを作成する必要はありません。アプリケーションをテストするためには、少数のテスト・ユーザーを作成して、アプリケーションに直接割り当てるだけで十分な場合があります。アプリケーションをJDeveloperで実行すると、ユーザーと定義済エンタープライズ・ロールが、デフォルトのセキュリティ・プロバイダ(統合WebLogic Serverの埋込みLDAP)に作成されます。
通常、ステージングのためにアプリケーションをデプロイするときは、ポリシー・ストアのみをターゲット・サーバーに移行します。35.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、アイデンティティ・ストア(テスト・ユーザーとエンタープライズ・ロールを含む)が移行されないように、JDeveloperデプロイメント・オプションを構成できます。
セキュア・アプリケーションをデプロイすると、Oracle Fusion Middlewareはアプリケーションのポリシー・ストアをドメインレベル・ポリシー・ストアのポリシーとマージします。このタスクを完了するために、Oracle WebLogic Serverの管理者は、最終的にポリシー・ストアのアプリケーション・ロールを既存のドメインレベル・エンタープライズ・ロールにマッピングします。ドメイン・レベルでのこのようにアプリケーション・ロールをマッピングすると、定義したADFセキュリティ・ポリシーに従ってエンタープライズ・ユーザーがアプリケーション・リソースにアクセスできるようになります。また、管理者がドメインレベルでアプリケーション・ロール・マッピングを行うことにより、本番環境のアイデンティティ・ストアの知識がなくても、アプリケーションのADFセキュリティ・ポリシーを開発できるようになります。
認可で利用されるポリシー・ストアは、実行時にアクセスされ、指定したオブジェクトに対する事前定義済のアクション(view
など)を実行するための権限を含みます。当初、ADFセキュリティの構成ウィンドウを実行した後では、ポリシー・ストアでは権限が定義されていません。また、デフォルトのウィザード・オプション「ADF認証および認可」では認可チェックが有効になるため、ADFセキュリティ対応リソースに依存するアプリケーションのWebページにユーザーはアクセスできません。ユーザーのアクセスを許可するリソースに明示的な権限を定義するには、JDeveloperを使用する必要があります。
ベスト・プラクティス: デフォルト・オプション「ADF認証および認可」を選択してADFセキュリティの構成ウィザードを実行すると、アプリケーションのWebページがロックダウンされます。このとき、Fusion Webアプリケーションに最大限の保護を実現できます。指定するページのみのアクセスをユーザーに許可するように、明示的な権限を定義するためです。このようなガイドラインの詳細は、35.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。 |
セキュリティ・ポリシーを定義するには、アプリケーションのポリシー・ストアに、権限を付与するアプリケーション・ロールが含まれる必要があります。それは、ユーザーが定義するアプリケーション・ロール(fod-users
など)でも、OPSSで定義される2つの組込みアプリケーション・ロール(authenticated-role
またはanonymous-role
)のいずれかでもかまいません。アプリケーション・ロールは、同じロールの各メンバーが同じアクセス権を持つようにユーザーを分類する目的で使用できます。このため、セキュリティ・ポリシーにより、アプリケーション・ロールには、(個別のユーザーでなく)権限のプリンシパルの名前が付けられます。アプリケーション・ロールの定義の詳細は、35.4項「アプリケーション・ロールの作成」を参照してください。
ユーザー・インタフェース・プロジェクトに対しては、jazn-data.xml
ファイルの概要エディタを使用してADFリソース(ADFタスク・フローおよびADFページ定義など)を保護します。jazn-data.xml
ファイルのエディタを開きます。これには、jazn-data.xml
ファイル(「アプリケーション・リソース」パネル)をダブルクリックするか、メイン・メニューの「アプリケーション」メニューから「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルを開くと、テスト・ユーザー、エンタープライズ・ロールおよびアプリケーション・ロールを作成するために別のエディタ・ページが概要エディタに表示されることに注意してください。
データ・モデル・プロジェクトに対しては、エンティティ・オブジェクトまたはその属性を保護するためにjazn-data.xml
ファイルの概要エディタは使用しません。かわりに、これらのオブジェクトにメタデータを直接設定して、データバインドUIコンポーネントがデータを表示するかどうかを管理します。行レベル・セキュリティの権限付与の詳細は、35.5.11項「データのポリシーを定義する方法」を参照してください。
個別のアクセス権限にかかわらず、一部のWebページをすべてのユーザーが表示できるようにするのは、一般的な要件です。たとえば、ホームページは、サイトにアクセスするすべてのユーザーに対して表示する必要がありますが、企業サイトは認証によって身元が確認されたユーザーのみに表示する必要があります。
どちらの場合も、ページを表示する権限がユーザーの特定の権限によって定義されているわけではないので、ページはパブリックであると考えられます。両者の違いは、ユーザーが匿名であるか、それとも既知のアイデンティティであるかです。
ADFセキュリティ・モデルでは、アクセス権限をanonymous-role
プリンシパルに付与することで、セキュリティの欠如とコンテンツの公開アクセスを区別します。匿名ロールは、既知のユーザーと無名ユーザーの両方を含みます。したがって、anonymous-role
に付与される権限を使用すると、認証されていないユーザー(たとえばゲスト・ユーザー)によるリソースへのアクセスを許可できます。認証済ユーザーのみにアクセスを許可するには、authenticated-role
プリンシパルにポリシーを定義する必要があります。
作業を始める前に、次のようにします。
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、35.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
次のタスクを完了する必要があります。
バインド・タスク・フローを作成します。18.2項「タスク・フローの作成」を参照してください。
ADFページ定義ファイルを含むWebページを作成します。13.7項「ページ定義ファイルでの作業」を参照してください。
ADFセキュリティの構成ウィザードを実行します。35.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。35.4項「アプリケーション・ロールの作成」を参照してください。
ADFセキュリティ対応リソースに対する公開アクセス権を付与する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから次のいずれかのリソースを選択します。
「タスク・フロー」(バインド・タスク・フローを公開する場合)。アプリケーションによって、タスク・フローそのものに定義した権限の下でWebページが表示されます。つまり、バインド・タスク・フローのすべての構成Webページが公開されます。
「Webページ」(個別のWebページを公開する場合)。通常、これらのページはバインドなしタスク・フローに定義された、アプリケーションのトップレベル・ページ(ホームページなど)です。
「リソース」列で、アクセス権を付与するADFリソースを選択します。
選択するリソースは、リソース名の横の最初の列にロック・アイコンが表示されている必要があります。ロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図35-4ではADFリソースcustomer-registration-task-flow
(バインド・タスク・フロー)は権限が定義されていないため、ロック・アイコンが表示されています。
ヒント: 概要エディタの先頭列のヘッダーにあるキー切替えアイコンをクリックして、すでに権限が定義されたリソースの非表示と表示を切り替え、権限のないリソースのみを表示します。キー・アイコンは、リソースに権限が定義されており、十分なアクセス権を持つユーザーがアクセスできることを示します。 |
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、次の組込みアプリケーション・ロールから1つを選択します。
anonymous-roleは、サイトにアクセスするすべてのユーザーがリソースにアクセスできることを意味します。このロールへの権限付与が必要となるのは、ユーザーがログインしなくても、ADFセキュリティ対応リソースに関連するWebページにアクセスできるようにする場合です。たとえば、顧客の登録を管理するタスク・フローについてanonymous-role
に権限を付与します。
authenticated-roleは、認証されたユーザー(サイトにアクセスしてログインしたユーザー)のみがリソースにアクセスできることを意味します。たとえば、従業員登録のタスク・フローについてauthenticated-role
に権限を付与します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列では、Viewアクションが選択されたままにしておきます。
デフォルトでは、図35-5に示すように、概要エディタにはViewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。
セキュリティ・ポリシーを定義すると、jazn-data.xml
ファイルの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルが更新されます。
概要エディタは、ファイルの<policy-store>
セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロール(この場合は匿名ロール)です。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。
例35-6に示すjazn-data.xml
ファイルのセキュリティ・ポリシーでは顧客登録タスク・フローが公開されます。anonymous-role
に対する権限には、バインド・タスク・フローcustomer-registration-task-flow
の1つのview権限が含まれます。この権限により、すべてのユーザーが顧客登録タスク・フローを開始して顧客登録プロセスを完了できます。匿名ロールに権限を追加することもでき、匿名ロール権限の<permissions>
セクションに表示されます。
例35-6 アプリケーションレベルのポリシー・ストアでのanonymous-roleに対する権限
<policy-store> ... <jazn-policy> <grant> <grantee> <principals> <principal> <class>oracle.security.jps.internal.core. principals.JpsAnonymousRoleImpl</class> <name>anonymous-role</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/customer-registration-task-flow.xml# customer-registration-task-flow</name> <actions>view</actions> </permission> ... </permissions> ... </grant> ... </jazn-policy> </policy-store>
anonymous-role
およびauthenticated-role
という名前は、Oracle Platform Security Services (OPSS)によって定義される特別なロールです。
ADFセキュリティの構成ウィザードを実行すると、匿名ロールのサポートを有効にするJpsFilter
定義がweb.xml
ファイルに構成されます。匿名ロールを有効にすると、無名ユーザー(ログインしていないユーザー)によるサイトのブラウズがADFセキュリティによってサポートされます。反対に、認証ロールは宣言されず、デフォルトで常に識別されます。ADFセキュリティでは両方のロールがサポートされます。
エンド・ユーザーがADFセキュリティ対応リソースに最初にアクセスするとき、システムによってサブジェクトが作成され、匿名ロール・プリンシパルがそのサブジェクトに移入されます。アクセス対象のADFセキュリティ対応リソースのview権限が匿名ロールに付与されているかぎり、ユーザーのアクセスが許可されます。匿名ロールがADFリソースの権限受領者でない場合、ユーザーはログインするように求められます。ログインすると認証ロールがサブジェクトに追加されます。また、ウィザードによってJpsFilter
定義がweb.xml
ファイルに追加されます。remove.anonymous.role
はfalse
に設定され、ユーザーがログインした後でも匿名ロール・プリンシパルが使用可能になります。認証ロール・プリンシパルを使用すると、認証ロールに対して明示的に権限が付与されたリソースにユーザーがアクセスできます。
ADFバインド・タスク・フローのアクセス・ポリシーを定義するには、jazn-data.xml
ファイルの概要エディタのリソース権限ページで権限を作成します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はバインド・タスク・フロー定義名)を定義します。
ベスト・プラクティス: バインド・タスク・フローの個々のWebページに対しては権限を作成しないでください。ユーザーがバインド・タスク・フローにアクセスする場合、すべてのページのセキュリティはタスク・フローに付与する権限により管理されます。また、含まれている(ページ定義が関連付けられている) Webページにはデフォルトでアクセスできないため、ADFセキュリティではユーザーによるタスク・フローのページへの直接アクセスが禁止されます。これにより、タスク・フローの明確なセキュリティ・モデルがサポートされ、すべてのユーザーに単一エントリ・ポイントを強制します。セキュリティ・ポリシーの実装方法の詳細は、35.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。 |
表35-3で説明するように、概要エディタで「タスク・フロー」ヘッダーの切替えボタンをクリックすると、タスク・フローをソートできます。
表35-3 バインド・タスク・フローのリソース権限切替えボタン
ボタン | 切替えアクション | 説明 |
---|---|---|
|
権限のないバインド・タスク・フローの表示または非表示 |
権限が定義されていないバインド・タスク・フローを表します。タスク・フローがコールするWebページにはすべてのユーザーがアクセスできません。 |
|
権限付きのバインド・タスク・フローの表示または非表示 |
1つ以上の権限が定義されたバインド・タスク・フローを表します。タスク・フローがコールするWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。 |
概要エディタに表示される、利用できるアクションのリストは、タスク・フロー権限クラス(oracle.adf.controller.security.TaskFlowPermission
)によって定義されます。権限クラスは、これらのアクションを、タスク・フローがサポートする操作にマップします。表35-4に、JDeveloperによって表示される、ADFバインド・タスク・フローに対するアクションを示します。
Fusion Webアプリケーションで現在サポートされているのはview
アクションのみです。customize
、grant
またはpersonalize
アクションを選択しないでください。これらはタスク・フロー・セキュリティで将来使用するために用意されています。
表35-4 ADFバインド・タスク・フローのセキュリティ保護されたアクション
許可できるアクション | ユーザー・インタフェースへの影響 |
---|---|
|
Fusion Webアプリケーションのバインド・タスク・フローの読取りと実行を行うユーザーを制御します。 これは、タスク・フローがサポートする唯一の動作です。 |
|
今後の使用のために確保されています。このアクションは実行時にチェックされません。 |
|
今後の使用のために確保されています。このアクションは実行時にチェックされません。 |
|
今後の使用のために確保されています。このアクションは実行時にチェックされません。 |
タスク・フロー・セキュリティ・ポリシーの権限を定義するには、jazn-data.xml
ファイルの概要エディタのリソース権限ページを使用します。
作業を始める前に、次のようにします。
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、35.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
次のタスクを完了する必要があります。
バインド・タスク・フローを作成します。18.2項「タスク・フローの作成」を参照してください。
ベスト・プラクティス: 同じアプリケーションの別のUIプロジェクトのバインド・タスク・フローを作成している場合、一意のタスク・フロー定義名を割り当てることをお薦めします。これが必要になるのは、権限のタスク・フロー定義名が |
ADFセキュリティの構成ウィザードを実行します。35.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。35.4項「アプリケーション・ロールの作成」を参照してください。
ADFバインド・タスク・フローで権限を定義する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択します。
概要エディタに、アプリケーションで定義されるすべてのタスク・フローが表示されます。タスク・フローは、ユーザー・インタフェース・プロジェクトの「Webコンテンツ/ページ・フロー」ノードに表示されるタスク・フロー定義ファイル(.xml
)で定義されます。
「リソース」列で、アクセス権を付与するタスク・フローを選択します。
最初にバインド・タスク・フローに権限付与を行うとき、最初の列のタスク・フロー名の横に「権限のないリソースを表示します。」アイコン(ロック・アイコン)が表示されます。概要エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。
ヒント: 「リソース」列のヘッダーの権限付きリソースアイコン(キー・アイコン)をクリックすると、すでに権限が定義されているすべてのタスク・フローが非表示になります。こうすることで、図35-6のように権限のないタスク・フローのみが表示されます。さらに、タスク・フロー名の一部を検索フィールドに入力すると、文字が一致する名前のタスク・フローのみを表示できます。 |
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。35.5.3項「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、35.4項「アプリケーション・ロールの作成」に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列では、Viewアクションが選択されたままにしておきます。
デフォルトでは、図35-7のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。customize、grantまたはpersonalizeアクションを選択しないでください。これらは将来の使用のために用意されているものです。実行時にADFセキュリティでチェックされることはありません。
TaskFlowPermission
クラスによってタスク・フロー(タスク・フローの操作にマッピングされる特定のアクション)が定義されます。表35-4を参照してください。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のタスク・フロー定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。35.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
ADFページ定義のアクセス・ポリシーを定義するには、jazn-data.xml
ファイルの概要エディタのリソース権限ページで権限を作成します。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、個別のアプリケーション・ロールのメンバーを認可する権限を付与した権限ターゲット(この場合はページ定義名)を定義します。
ベスト・プラクティス: 個々のWebページの権限を作成するのは、そのページがバインド・タスク・フローの構成ページでない場合のみです。ページ定義バインディング・ファイルが関連付けられているページで、ページレベル・セキュリティがチェックされるのは、そのページが直接アクセスされる場合、またはバインドなしタスク・フロー内でアクセスされる場合のみです。セキュリティ・ポリシーの実装方法の詳細は、35.11.4項「ADFセキュリティの操作のベスト・プラクティス」を参照してください。 |
表35-5で説明するように、概要エディタで「リソース」ヘッダーの切替えボタンをクリックするとWebページ定義リソースをソートできます。
表35-5Webページ定義のリソース権限切替えボタン
ボタン | 切替えアクション | 説明 |
---|---|---|
|
権限のないトップレベル・ページの表示または非表示 |
バインドなしタスク・フローに含まれるWebページに対して定義された権限がないページ定義を表します。このWebページにはどのユーザーもアクセスできません。 |
|
権限付きのトップレベル・ページの表示または非表示 |
バインドなしタスク・フローに含まれるWebページに対して定義された1つ以上の権限があるページ定義を表します。このWebページには、権限が付与されたアプリケーション・ロールのメンバーであるすべてのユーザーがアクセスできます。 |
|
バインド・タスク・フローに含まれるページの表示または非表示 |
バインド・タスク・フローにも含まれるWebページに関連付けられたページ定義を表します。このようなWebページ定義には権限を付与しないでください。かわりに、バインド・タスク・フローのセキュリティ・ポリシーを定義します。 |
|
保護できないページ(ページ定義なし)の表示または非表示 |
バインドなしタスク・フローに含まれる、ページ定義が定義されていないWebページを表します。(バインド・タスク・フローに含まれる同様のページは、バインド・タスク・フローの権限によって保護されます。)Webページは、ADFセキュリティ対応リソースにより保護されていないため、すべてのユーザーによりアクセス可能です。35.5.9項「ADFバインドなしのページのポリシー定義について」で説明するように、必要に応じて、空のページ定義ファイルを追加することでページを保護できます。 |
概要エディタに表示される、利用できるアクションのリストは、リージョン権限クラス(oracle.adf.share.security.authorization.RegionPermission
)によって定義されます。権限クラスは、これらのアクションを、WebページのADFページ定義がサポートする操作にマップします。表35-6に、JDeveloperによって表示される、ADFページ定義に対するアクションを示します。
Fusion Webアプリケーションで現在サポートされているのはview
アクションのみです。
表35-6 ADFページ定義のセキュアなアクション
許可できるアクション | ユーザー・インタフェースへの影響 |
---|---|
|
ページを表示できるユーザーを制御します。 これは、ページ定義がサポートする唯一の動作です。 |
ページ定義セキュリティ・ポリシーの権限を定義するには、jazn-data.xml
ファイルの概要エディタのリソース権限ページを使用します。
作業を始める前に、次のようにします。
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、35.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
次のタスクを完了する必要があります。
ADFページ定義を含むトップレベルWebページを作成します。13.7項「ページ定義ファイルでの作業」を参照してください。
ベスト・プラクティス: 同じアプリケーションの別のUIプロジェクトのトップレベルWebページを作成している場合、一意のページ・ファイル名を割り当てることをお薦めします。これが必要になるのは、権限のページ定義が |
ADFセキュリティの構成ウィザードを実行します。35.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。35.4項「アプリケーション・ロールの作成」を参照してください。
ADFページ定義に権限を定義する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択します。
概要エディタのリソース権限ページには、ADFページ定義が関連付けられているページも含め、すべてのWebページが表示されます。ADFデータバインディングを使用するあらゆるWebページや、空のページ定義を作成しておいたあらゆるWebページも含まれます。ページ定義は、ユーザー・インタフェース・プロジェクトの「アプリケーション・ソース」ノードに表示されるPageDef.xml
ファイルで定義されます。
「ページ定義」列で、アクセス権を付与するページ定義を選択します。
最初にページ定義に権限付与を行うとき、最初の列のページ定義名の横に「権限のないリソースを表示します。」アイコン(ロック・アイコン)が表示されます。エディタに表示されるロック・アイコンは、リソースに定義済のセキュリティ・ポリシーがなく、そのためロックされている(権限を定義するまで、ユーザーがアクセスできない)ことを示します。たとえば、図35-8のページ定義account_updateUserInfo
には権限が付与されていないためロック・アイコンが表示されます。図35-8の他のページ定義には「バインド・タスク・フローに含まれるページ」アイコンが表示されます。これらはトップレベル・ページではなく、含まれているバインド・タスク・フローによって保護されるためです。
「バインド・タスク・フローに含まれるページ」アイコンが表示されている個々のWebページ定義には権限を作成しないでください。関連付けられたWebページのセキュリティ・ポリシーは、バインド・タスク・フローによって保護されます。たとえば、図35-8のaccount_addressDetails.jsff
リージョンに関連付けられているページ定義は、それが含まれているバインド・タスク・フローによって保護されます。
ヒント: ページ定義名の一部を検索フィールドに入力すると、文字が一致する名前のページ定義のみを表示できます。たとえば、 |
ヒント: 権限付きリソースのアイコン(キー・アイコン)をクリックすると、すでに権限があるすべてのページ定義を非表示にできます。「リソース」列のヘッダーの「バインド・タスク・フローに含まれるページを表示」切替えボタンがオフになっており、バインド・タスク・フローに含まれるページ定義がすべて非表示になっていることを確認します(デフォルトでは、これらのページが非表示になるように設定されています)。この場合、図35-9に示すように、権限がないトップレベル・ページ(および保護できないページ)が表示されます。 |
「ロールに付与済」列で「権限受領者の追加」アイコンをクリックして、「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。35.5.3項「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、35.4項「アプリケーション・ロールの作成」に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列では、Viewアクションが選択されたままにしておきます。
デフォルトでは、図35-10のように概要エディタにviewが選択されて表示されます。Fusion Webアプリケーションで現在サポートされるアクションはviewアクションだけです。
RegionPermission
クラスによってページ定義(ページの操作にマッピングされる特定のアクション)が定義されます。表35-6を参照してください。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のページ定義に、異なるアプリケーション・ロールに対する複数の権限がある場合があります。35.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
アプリケーションによって定義されたADFメソッドは、コマンド・コンポーネントとしてユーザー・インタフェース内にドロップできます。デフォルトでは、メソッドのコマンド・コンポーネントが表示されたページにアクセス可能なユーザーには、このメソッドを実行する権限も与えられます。メソッド操作に対するアクセスを制限する追加のセキュリティを作成するには、ADFメソッドに対するリソース権限を作成し、ユーザー・インタフェース・レベルで権限をテストする必要があります。ADFセキュリティでは、ADFメソッドに対する権限チェックは行われません。アプリケーションでの権限チェックを独自に有効化する必要があります。ADFメソッドに対してユーザーに付与したリソース権限に基づき、ユーザー・インタフェースでコマンド・コンポーネントが有効化または無効化されます。
リソース権限を使用してADFメソッドをセキュリティ保護するには:
ADFメソッドにリソース権限を付与します。
ユーザー・インタフェースで権限付与を施行します。
実行メソッドの操作は、ADFメソッド権限クラス(oracle.adf.share.security.authorization.MethodPermission
)によって定義されます。起動権限アクションを実行操作にマッピングするリソース権限を作成します。
プロジェクトによって定義したADFメソッドに対するリソース権限を作成するには、セキュリティ・ポリシーの概要エディタを使用します。
作業を始める前に、次のようにします。
ADFセキュリティによるADFメソッドの処理方法について理解しておくと役立ちます。詳細は、35.5.6項「ADFメソッドのポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、35.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
28.2項「メソッドを実行するためのコマンド・コンポーネントの作成」の説明に従い、保護対象のメソッドを実行するコマンド・コンポーネントを作成します。
ADFセキュリティの構成ウィザードを実行します。35.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。35.4項「アプリケーション・ロールの作成」を参照してください。
ADFメソッドに対するリソース権限を付与するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「ADFメソッド」を選択します。
概要エディタのリソース権限ページに、アプリケーションで定義されるすべてのメソッドが表示されます。
「リソース」列で、アクセス権を付与するADFメソッドを選択します。
初めてADFメソッドに権限付与を行うとき、先頭列のメソッド名の隣には権限のないリソースアイコン(ロック・アイコン)が表示されています。エディタに表示されるロック・アイコンは、リソースにセキュリティ・ポリシーが定義されていないためにロックされている(権限を定義するまでユーザーがアクセスできない)ことを示します。ただし、ADFメソッドの場合は、ADFセキュリティによって権限チェックが施行されないため、すべてのメソッドは常にアクセス可能です。メソッドに対するセキュリティを施行するには、ユーザー・インタフェースで権限チェックを実行する必要があります。
「ロールに付与済」列で「権限受領者の追加」アイコンをクリックして、「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。35.5.3項「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、35.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列では、Invokeアクションが選択されたままにしておきます。
デフォルトでは、概要エディタではInvokeが選択されています。invokeアクションは、ADFメソッドに対してサポートされる唯一のアクションです。
MethodPermission
クラスによってinvokeアクションが定義され、実行メソッドの操作にマッピングされます。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のADFメソッド・リソースに、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。35.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
メソッドに対するユーザーのアクセス権をチェックするEL式を定義するには、UIコンポーネントの表示プロパティに対して表示した「式ビルダー」ダイアログを使用します。アプリケーションを実行すると、EL式によるADFメソッド権限チェックの結果に基づき、コンポーネントが有効化または無効化されます。
たとえば、例35-7に示すように、af:commandButton#cb1
ボタンのdisabled
属性に対してuserGrantedPermission
式を定義できます。この場合、ユーザーが権限を持っているかどうかが式によってテストされ、その結果ボタンが有効化されるか、ユーザーが権限を所有していない場合はボタンが無効化されます。この式はボタンのrendered
属性に対して定義されているのではないため、ページには常にこのボタンが表示されます。
例35-7 ADFメソッド権限のカスタム式
<af:commandButton actionListener="#{bindings.myMethodName.execute}" text="myMethodName" disabled="#{!securityContext.userGrantedPermission ['permissionClass=oracle.adf.share.security.authorization.MethodPermission, target=MyMethodResourceName, action=invoke']} id="cb1"/>
作業を始める前に、次のようにします。
ADFメソッド権限チェックの制限について理解しておくと役立ちます。詳細は、35.5.6項「ADFメソッドのポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、35.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
式を使用してADFメソッド権限をチェックするには:
アプリケーション・ナビゲータで、ページをダブルクリックします。
ADFメソッドの実行に使用されるコマンド・コンポーネントを選択します。
「プロパティ・インスペクタ」で、「無効」フィールドの右側に表示されている「プロパティ・メニュー」ドロップダウン・メニューから「式ビルダー」を選択します。
「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedPermissionを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。
権限文字列は、permissionClass=
qualifiedClassName
;target=
artifactName
;action=
actionName
のようにセミコロンで連結した文字列として入力します。たとえば、ページ内のメソッドの起動に使用するコマンド・ボタンを有効化または無効化するには、例35-7に示すような式を入力します。このとき、userGrantedPermission
のターゲットをリソース権限名と同じ名前にします。
例35-7では、アプリケーション・ポリシー・ストア内で定義したMyMethodResourceName
という名前のADFメソッド権限に基づいて、式が権限を評価します。
「OK」をクリックします。
セキュリティ・ポリシーを定義すると、jazn-data.xml
ファイルの概要エディタによって、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルが更新されます。
概要エディタは、ファイルの<policy-store>
セクションにポリシー情報を書き込みます。セキュリティ・ポリシーすなわち権限には、権限受領者と1つ以上の権限が含まれます。権限受領者は、ポリシーの定義対象のアプリケーション・ロールです。各権限では、保護対象のリソースと、そのリソースに対して実行できるアクションが定義されます。
例35-8に示すjazn-data.xml
ファイルのセキュリティ・ポリシーでは、チェックアウト・タスク・フローが保護され、ユーザーがアカウント情報を更新できるトップレベルWebページが保護されます。fod-users
アプリケーション・ロールに対する権限には、バインド・タスク・フローcheckout-task-flow
のview権限と、account_updateUserInfoPageDef
ページ定義を含むWebページのview権限が含まれます。この権限を使用すると、fod-users
アプリケーション・ロールのメンバーとして認証されたユーザーだけが、チェックアウト・タスク・フローを開始したり、ユーザー情報更新ページを表示したりすることができます。
Webページに関しては、ユーザー情報更新ページ(updateUserInfo.jspx
)に対して作成されたaccount_updateUserInfoPageDef
ページ定義に権限が定義されていることに注意してください。また、これはバインド・タスク・フローによってまだ保護されていないトップレベルWebページであることにも注意してください。
例35-8 アプリケーションレベル・ポリシー・ストアの権限
<policy-store> ... <jazn-policy> <grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>fod-users</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/checkout-task-flow.xml#checkout-task-flow</name> <actions>view</actions> </permission> <permission> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>oracle.fodemo.storefront.pageDefs.acct_updateUserInfoPageDef</name> <actions>view</actions> </permission> ... </permissions> </grant> ... </jazn-policy> </policy-store>
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を使用してアプリケーションを実行する前に、テスト・ユーザーを含むアイデンティティ・ストアをプロビジョニングし、構成するアプリケーション・ロールにそれらのユーザーを追加する必要があります。35.6項「テスト・ユーザーの作成」で説明するように、アプリケーション・ロールでは、ユーザーまたはユーザー・グループ(エンタープライズ・ロール)に固有のメンバーを定義できます。
その後、実行時に、現在のユーザーがアクセスしようとしているページのview権限を持っているかどうかが、ページのコンテキストによって決まります。
ページがバインド・タスク・フローのアクティビティである場合は、タスク・フロー・コントローラによって権限が決まります。
ページが、ページ定義ファイルが関連付けられたトップレベル・ページである場合は、ADFモデルによって権限が決まります。
次に、Oracle Platform Security Servicesにより、ページにアクセスするために必要な権限を持つロールがサブジェクトに含まれるかどうかが確認されます。ユーザーが認可されると、タスク・フローが開始します。
バインド・タスク・フローとトップレベル・ページ(バインドなしタスク・フローで定義)の場合、ユーザーが認可されないと、ADFコントローラによって例外がスローされ、タスク・フロー構成で指定された例外ハンドラに制御が渡されます。他のエラー・ページの指定の詳細は、35.7.4項「認証後にユーザーをリダイレクトする方法」を参照してください。
ADFセキュリティの構成ウィザードのデフォルト・オプション「ADF認証および認可」では、認可チェックが有効になり、Webページが保護されます(WebページがADFセキュリティ対応リソースに関連付けられている場合)。したがって、ウィザードを実行した後で、次の両方の条件が存在するとWebページは保護されません。
ページにデータバインドADF Facesコンポーネントが表示されず、ページにADFページ定義が存在していない場合。
ページがデータバインドADFタスク・フローの構成ページでない場合。(ユーザーがバインド・タスク・フローのプロセスとしてアクセスするすべてのページは、タスク・フローの権限でチェックされます。)
データバインドADF Facesコンポーネントを作成するために「データ・コントロール」パネルを使用してWebページを設計すると、JDeveloperによってADFページ定義ファイルが生成されます(詳細は、13.7項「ページ定義ファイルでの作業」を参照してください)。ただし、WebページがADFバインディングを使用しない場合でも空のページ定義ファイルを作成できます。これには、ユーザー・インタフェース・プロジェクトのWebページを右クリックして、「ページ定義に移動」を選択します。このページ定義ファイルは空にしておくことができます。このページは、データバインドADF FacesコンポーネントをサポートするためにADFバインディングと連携する必要がないためです。
WebページとADFページ定義ファイル(空かどうかに関係なく)をいったん関連付けると、関連付けられたWebページにユーザーがアクセスするときに認可チェックが施行されます。他のADFページ定義と同様にページのセキュリティ・ポリシーを定義できます。空のADFページ定義に対する権限付与の詳細は、35.5.5項「ページ定義を参照するWebページのポリシーを定義する方法」を参照してください。
セキュリティ・ポリシーを定義するために空のページ定義を作成する手順:
アプリケーション・ナビゲータで、保護するWebページを探し、ノードを右クリックして「ページ定義に移動」を選択します。
確認ダイアログで「はい」をクリックすると、ページの新しいページ定義が作成されます。
ページ定義はpageDefs
パッケージに追加されます。
一度に複数のリソースに適用する権限を定義する場合は、java.util.regex.Pattern
クラスによって定義されるパターンを作成して、実行時に評価される正規表現を生成します。たとえば、権限を一連のリソースに対応させるには、権限の名前に対して.*
(任意の文字0個以上を表す)という表現を入力できます。ADFセキュリティでは、他のセキュリティ・オブジェクト(プリンシパル名など)については正規表現を使用できません。
この機能を使用すると、例35-9に示すように、同じ権限を持つバインド・タスク・フローをグループ化してWEB-INF
の専用のサブフォルダに含め、そのフォルダ全体に権限を定義できます。この場合、ピリオド(任意の文字を表す)の後にアスタリスク修飾子(0回以上を表す)を付けた正規表現を使用します。
例35-9 アプリケーションレベル・ポリシー・ストアに定義されたフォルダ全体のタスク・フロー権限
... <grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>anonymous-role</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.controller.security.TaskFlowPermission</class> <name>/WEB-INF/.*</name> <actions>view</actions> </permission> </permissions> </grant>
jazn-data.xml
ファイルの概要エディタのユーザー・インタフェースでは、正規表現の使用がサポートされていないため、直接ファイルを編集する必要があります。system-jazn-data.xml
ファイルのポリシー・ストアを直接編集しないでください。そのかわりに、正規表現を使用してjazn-data.xml
ファイルに権限を追加します。アプリケーションを実行またはデプロイすると、これらの権限がポリシー・ストアにマージされます。
より複雑な正規表現を使用すると、ポリシーにビジネス・ルールを定義して、非常に限定的な権限のセットを作成できます。たとえば、すべてのページ定義にview権限を付与すると同時に、正規表現で除外セットを定義して特定のページ定義を除くことができます。例35-10は、custom
で始まるページ定義名を除いたすべてのページに関してanonymous-role
にview権限を付与する方法を示しています。
例35-10 正規表現とメタ文字を使用したポリシー権限の定義
<grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>anonymous-role</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.share.security.authorization.RegionPermission</class> <name>[^(custom)].*</name> <actions>view</actions> </permission> </permissions> </grant>
表35-7は、ポリシー定義で使用できる正規表現の基本的なメタ文字の一部を示しています。
データ・モデル・オブジェクトのADFエンティティ・オブジェクトはセキュリティ対応です。つまり、開発者が付与することのできるリソース固有の権限が事前定義されています。さらに、エンティティ・オブジェクトの個々の属性だけを保護することもできます。
セキュリティ保護の対象とするエンティティ・オブジェクトでは、UIコンポーネントがADFバインディングによってセキュアなエンティティ・オブジェクトのアクセス先データにバインドされている場合に、そのUIコンポーネントをレンダリングしているWebページに表示されるデータの、ユーザーによる更新が制限されます。さらに、エンティティ・オブジェクトをセキュリティ保護する際、そのエンティティ・オブジェクトに依存するデータ・モデル・プロジェクト内のビュー・オブジェクトも事実上保護します。そのため、セキュリティ保護するエンティティ・オブジェクトは、このビュー・オブジェクトにバインドされたUIコンポーネントに適用される、さらに広範なアクセス・ポリシーを定義します。
作業を始める前に、次のようにします。
ADFセキュリティ・ポリシーについて理解しておくと役立ちます。詳細は、35.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
エンティティベースのビュー・オブジェクトについて理解しておくと役立ちます。エンティティ・ベースのビュー・オブジェクトの詳細は、5.2項「単一のデータベース表からのビュー・オブジェクト行の移入」を参照してください。
ADFエンティティ・オブジェクトを使用して行データを保護する手順:
保護するエンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について、特定のアクションの権限マップを定義します。
ポリシー・ストアに追加したアプリケーション・ロールに権限を付与します。
エンティティ・オブジェクトまたはその個々の属性の操作を保護できます。
データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクトによって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。
概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission
)によって定義されます。権限クラスは、エンティティ・オブジェクトでサポートされる操作をアクションにマップします。表35-8は、エンティティ・オブジェクトの、セキュア化できる操作を示しています。
表35-8 ADF Business Componentsのセキュア化できる操作
ADFコンポーネント | セキュアな操作 | 想定されるマップされたアクション | 対応する実装 |
---|---|---|---|
ADF Business Componentsエンティティ・オブジェクト |
|
|
|
|
|
バインドされたコレクションの属性を更新します。 |
|
|
|
バインドされたコレクションの1つの行を削除します。 |
エンティティ・オブジェクトがアクセスするすべての行レベル・データを保護するには、エンティティ・オブジェクト用の概要エディタを使用します。
作業を始める前に、次のようにします。
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、35.5.11項「データのポリシーを定義する方法」を参照してください。
次のタスクを完了する必要があります。
エンティティ・オブジェクトに対する操作をセキュア化する手順:
アプリケーション・ナビゲータに表示されるデータ・モデル・プロジェクトで、セキュア化するエンティティ・オブジェクトをダブルクリックします。
概要エディタで、「一般」ナビゲーション・タブをクリックします。
一般ページで「セキュリティ」セクションを開き、エンティティ・オブジェクトについて保護する操作を選択します。
「セキュリティ」セクションに、EntityPermission
クラスで定義されている、保護できる操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表35-8に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。
たとえば、read権限を有効化するには、図35-11に示すように選択します。権限が、エンティティ・オブジェクトのXML定義に表示されます。
エンティティ・オブジェクトがアクセスするデータの個々の列を保護するには、エンティティ・オブジェクト用の概要エディタの属性ページを使用します。
データ・モデル・プロジェクトでは、エンティティ・オブジェクトの概要エディタを使用して、エンティティ・オブジェクト属性によって許可される特定の操作について権限マップを定義します。メタデータを構成するのは、権限クラス、権限名およびバインディング操作にマップされた一連のアクションです。
概要エディタに表示される、利用できる操作のリストは、エンティティ・オブジェクト権限クラス(oracle.adf.share.security.authorization.EntityPermission
)によって定義されます。権限クラスは、エンティティ・オブジェクト属性でサポートされる更新操作をupdateアクションにマップします。表35-9は、エンティティ・オブジェクト属性の、セキュア化できる操作を示しています。
表35-9 ADFエンティティ・オブジェクト属性のセキュア化可能な操作
セキュアな操作 | 想定されるマップされたアクション | 対応する実装 |
---|---|---|
|
|
バインドされたコレクションの特定の属性を更新します。 |
エンティティ・オブジェクトがアクセスするデータの個々の列を保護するには、エンティティ・オブジェクト用の概要エディタの属性ページを使用します。
作業を始める前に、次のようにします。
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、35.5.11項「データのポリシーを定義する方法」を参照してください。
他のOracle ADF機能を使用して追加できる機能を理解しておくことも役立ちます。詳細は、35.1.3項「ADFセキュリティの追加機能」を参照してください。
次のタスクを完了する必要があります。
エンティティ・オブジェクト属性に対する操作をセキュア化する手順:
アプリケーション・ナビゲータで、保護する属性を定義するエンティティ・オブジェクトをダブルクリックします。
概要エディタで、「属性」ナビゲーション・タブをクリックします。
属性ページで保護する属性を選択し、「セキュリティ」タブをクリックして、update操作を選択します。
「セキュリティ」タブに、EntityAttributePermission
クラスで定義されるセキュア化可能な操作が表示されます。このクラスがエンティティ・オブジェクトのマッピングを行います。表35-9に示すように、特定のアクションがエンティティ・オブジェクトの操作にマッピングされます。
たとえば、update権限を有効化するには、図35-12に示すように選択します。権限マップが、エンティティ・オブジェクトのXML定義に表示されます。
権限ターゲットが構成されても、エンティティ・オブジェクトの権限ターゲットに対してポリシー権限が明示的に定義されるまで、エンティティ・オブジェクトあるいはその属性から導出されるデータは、セキュリティ保護されないままです。
既存のエンティティ・オブジェクトまたはエンティティ属性の権限ターゲットに対するアクセス・ポリシーを定義するには、セキュリティ・ポリシーの概要エディタを使用します。
作業を始める前に、次のようにします。
エンティティ・オブジェクトのADFセキュリティについて理解しておくと役立ちます。詳細は、35.5.11項「データのポリシーを定義する方法」を参照してください。
次のタスクを完了する必要があります。
ADFセキュリティの構成ウィザードを実行します。35.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。35.4項「アプリケーション・ロールの作成」を参照してください。
35.5.11.1項「ADFエンティティ・オブジェクトに対する権限マップの定義」の説明に従って、エンティティ・オブジェクトまたはエンティティ・オブジェクトの属性について権限ターゲットを定義します。
エンティティ・オブジェクトまたはエンティティ属性のアクセス・ポリシーを定義するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
セキュリティ・ポリシーの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「ADFエンティティ・オブジェクト」または「ADFエンティティ・オブジェクト属性」を選択します。
概要エディタのリソース権限ページに、これまでに権限ターゲットを定義したすべてのエンティティ・オブジェクト(またはエンティティ属性)が表示されます。
「リソース」列で、アクセス権を付与するADFエンティティ・オブジェクトまたはエンティティ属性を選択します。
初めてADFエンティティ・オブジェクトまたはエンティティ属性に権限付与を行うとき、図35-13に示すように、先頭列のメソッド名の隣には権限のないリソースアイコン(ロック・アイコン)が表示されています。エディタに表示されるロック・アイコンは、リソースにセキュリティ・ポリシーが定義されていないためにロックされている(権限を定義するまでユーザーがアクセスできない)ことを示します。
「ロールに付与済」列で「権限受領者の追加」アイコンをクリックして、「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、権限の受領者にするアプリケーション・ロールを選択します。
「アプリケーション・ロールの選択」ダイアログには、jazn-data.xml
ファイルのアプリケーション・ロールが表示されます。35.5.3項「実行時に行われる処理: 組込みロールの使用方法」で説明したように、組込みOPSSアプリケーション・ロール、anonymous-roleおよびauthenticated-roleも表示されます。
アプリケーション固有のアプリケーション・ロールが表示されていない場合は、35.4項「アプリケーション・ロールの作成」の説明に従ってロールを作成します。
「アプリケーション・ロールの選択」ダイアログで「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列で、特定のアプリケーション・ロールに付与するアクションを選択します。
エンティティ・オブジェクトに対し、概要エディタではデフォルトでreadアクションが選択されています。表35-8に示すように、対応する権限ターゲットをすでに構成している場合は、updateアクションおよびdeleteアクションを選択できます。
エンティティ・オブジェクト属性に関しては、表35-9に示す権限ターゲットに対し、概要エディタではデフォルトでupdateアクションが選択されています。エンティティ・オブジェクト属性に対してサポートされる他のアクションはありません。
図35-14では、エンティティ・オブジェクトに対し、fod-usersアプリケーション・ロールに対してdelete、readおよびupdate権限が付与されています。
この手順を必要なだけ繰り返して、追加の権限を作成します。
同一のADFエンティティ・オブジェクトまたはエンティティ属性に、異なるアプリケーション・ロールに対する複数の権限が定義される場合があります。35.5.7項「セキュリティ・ポリシーの定義時の処理」で説明するように、権限はjazn-data.xml
ファイルのポリシー・ストア定義に含まれます。
リソース権限を作成することで、セキュア化できる個々のOracle ADFアーティファクトに対するエンド・ユーザーのアクセス権を定義します。しかし、管理とメンテナンスを容易にするため、リソース権限を資格付与として定義することもできます。こうすると、セキュア化可能な複数のアプリケーション・アーティファクトが1つの名前付きセキュリティ・グループとして集約され、これを1つの文によってアプリケーション・ロールに付与できます。たとえば、ADF Business Componentsエンティティ・オブジェクトによってアプリケーション内で公開されるデータへのアクセスを認可しようとする場合、複数のエンティティ・オブジェクトに対して同一のセキュリティ・ポリシーが必要になる可能性があります。各エンティティ・オブジェクトに対してアクセス権限を個別に付与するのではなく、これらの権限を1つの資格としてグループ化し、一括して付与できます。
資格付与の作成は、jazn-data.xml
ファイルの概要エディタの資格付与ページで行います。作成する権限は、jazn-data.xml
ファイルのポリシー・ストア・セクションにメタデータとして表示されます。このメタデータは、選択したリソース・インスタンスとアクションとのペアで構成される1つの資格(XML定義では<permission-set>
として識別されます)を定義します。この資格は付与可能なエンティティであり、アプリケーション・ロールに付与できます。
セキュリティ・ポリシーの概要エディタには、リソース・タイプのリストが表示されます。選択したリソース・タイプにより、アプリケーション・ワークスペースのプロジェクト内で定義されたリソース・インスタンスがフィルタ処理されます。また、選択したリソース・タイプにより、概要エディタに表示される使用可能なアクションのリストが決定されます。たとえば、リソース・タイプタスク・フロー権限を選択した場合、概要エディタには、選択したユーザー・インタフェース・プロジェクト内のすべてのタスク・フローが表示されます。また、viewアクションも表示され、これを使用可能なADFバインド・タスク・フロー・リソースに関連付けることができます。
表35-10は、JDeveloperで表示されるリソース・タイプのリストと、各タイプに対して関連付けられるリソースおよびサポートされるアクションを示します。
表35-10 セキュア化できるOracle ADFアーティファクトのリソース・タイプ
リソース・タイプ | サポートされるリソースおよびアクション |
---|---|
|
選択したユーザー・インタフェース・プロジェクト内のADFバインド・タスク・フローに対してviewアクションを定義します。 |
|
選択したユーザー・インタフェース・プロジェクト内のADFページ定義ファイルに基づくリージョンおよびWebページに対してviewアクションを定義します。 |
|
選択したデータ・モデル・オブジェクト内のエンティティ・オブジェクトに対してread、updateおよびdeleteアクションを定義します。 |
|
選択したデータ・モデル・オブジェクト内の特定のエンティティ・オブジェクトのエンティティ・オブジェクト属性に対してupdateアクションを定義します。 |
セキュア化できるOracle ADFアーティファクトに対して資格付与を定義するには、jazn-data.xml
ファイルの概要エディタの資格付与ページを使用します。このエディタは、セキュリティ・ポリシー概要エディタとも呼ばれます。
作業を始める前に、次のようにします。
次のタスクを完了する必要があります。
アプリケーション・ロールを作成します。35.4項「アプリケーション・ロールの作成」を参照してください。
Oracle ADFアーティファクトに対して資格付与を定義するには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「資格付与」を選択します。
セキュリティ・ポリシー概要エディタの資格付与ページで、「資格」リストの「資格の追加」アイコンをクリックします。
概要エディタに、アプリケーションで定義されるすべてのリソースが表示されます。
「リソース」セクションで「メンバー・リソースの追加」アイコンをクリックし、メンバー・リソースを資格に追加します。
「リソースの選択」ダイアログで、「リソース・タイプ」ドロップダウン・リストからリソースを選択して、「ソース・プロジェクト」リストから必要なプロジェクトを選択します。
ダイアログに、アプリケーション・ワークスペース内のすべてのプロジェクトが表示されます。
「使用可能なリソース」リストからリソースを選択し、「追加」アイコンをクリックします。
ダイアログに、選択したプロジェクトによって定義されたすべてのリソースが表示されます。
「アクション」リストで、選択したリソースに対する目的のアクションを選択します。
図35-15に示す概要エディタでは、タスク・フローに対してViewアクションが選択され、資格に追加されています。
必要なその他のリソースをリストに追加します。
セキュリティ・ポリシー概要エディタの「付与」セクションで、「ロール付与の追加」アイコンをクリックし、アプリケーション・ロールに資格を付与します。
「アプリケーション・ロールの選択」ダイアログで、1つ以上のカスタム・アプリケーション・ロールを選択します。
ダイアログに、jazn-data.xml
ファイル内のすべてのアプリケーション・ロールが表示されます。事前定義されたアプリケーション・ロール(Oracle Fusionアプリケーションの用語では職務ロールとも呼びます)に権限を追加しないでください。JDeveloperで自分で作成したカスタム・アプリケーション・ロール、またはこの目的でITセキュリティ・マネージャによって作成されたカスタム・アプリケーション・ロールのみを選択してください。
「OK」をクリックします。
これらの手順を繰り返して他のリソースを追加し、同一カスタム・アプリケーション・ロールの同一資格に対して、これらのリソースの権限を作成します。
JDeveloperのセキュリティ・ポリシー・エディタを使用して資格を作成すると、JDeveloperはjazn-data.xml
ファイル内で、アプリケーション・ポリシー・ストアのソースを修正します。ファイルのポリシー・ストア・セクションには、<resource-type>
定義(選択したリソース・タイプに対してサポートされるアクションを識別)、<resource>
定義(アプリケーションから選択してリソース・タイプにマッピングしたリソース・インスタンスを識別)、<permission-set>
定義(1つの資格として付与されるリソースおよびアクションを定義)、および<grant>
定義が含まれ、1つ以上の資格(XML内で権限セットとして定義)が目的のアプリケーション・ロール(権限受領者)に付与されます。
例35-11に示すように、Oracle Fusionアプリケーションにおける資格ベースのセキュリティ・ポリシーは、<jazn-policies>
要素内で定義され、単一のアプリケーション・ロールに付与される1つ以上の資格によって構成されます。
例35-11 jazn-data.xmlファイル内の資格ベース・ポリシー定義
<?xml version="1.0" ?> <jazn-data> <policy-store> <applications> <application> <name>MyApp</name> <app-roles> <app-role> <name>AppRole</name> <display-name>AppRole display name</display-name> <description>AppRole description</description> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> <class>oracle.security.jps.service.policystore.ApplicationRole</class> </app-role> </app-roles> <role-categories> <role-category> <name>MyAppRoleCategory</name> <display-name>MyAppRoleCategory display name</display-name> <description>MyAppRoleCategory description</description> </role-category> </role-categories> <!-- resource-specific OPSS permission class definition --> <resource-types> <resource-type> <name>APredefinedResourceType</name> <display-name>APredefinedResourceType display name</display-name> <description>APredefinedResourceType description</description> <provider-name>APredefinedResourceType provider</provider-name> <matcher-class>oracle.security.jps.ResourcePermission</matcher-class> <actions-delimiter>,</actions-delimiter> <actions>write,read</actions> </resource-type> </resource-types> <resources> <resource> <name>MyResource</name> <display-name>MyResource display name</display-name> <description>MyResource description</description> <type-name-ref>APredefinedResourceType</type-name-ref> </resource> </resources> <!-- entitlement definition --> <permission-sets> <permission-set> <name>MyEntitlement</name> <display-name>MyEntitlement display name</display-name> <description>MyEntitlement description</description> <member-resources> <member-resource> <type-name-ref>APredefinedResourceType</type-name-ref> <resource-name>MyResource</resource-name> <actions>write</actions> </member-resource> </member-resources> </permission-set> </permission-sets> <!-- Oracle function security policies --> <jazn-policy> <!-- function security policy is a grantee and permission set --> <grant> <!-- application role is the recipient of the privileges --> <grantee> <principals> <principal> <class> oracle.security.jps.service.policystore.ApplicationRole </class> <name>AppRole</name> <guid>F5494E409CFB11DEBFEBC11296284F58</guid> </principal> </principals> </grantee> <!-- entitlement granted to an application role --> <permission-set-refs> <permission-set-ref> <name>MyEntitlement</name> </permission-set-ref> </permission-set-refs> </grant> </jazn-policy> </application> </applications> </policy-store> </jazn-data>
JDeveloperで提供されるエディタを使用して、アイデンティティ・ストアとポリシー・ストアの両方を作成できます。アプリケーション固有のjazn-data.xml
ファイルに両方のリポジトリを作成します。ファイルのアイデンティティ・ストア・セクション用のエディタでは、有効なユーザーIDと割り当てられたパスワードのリストを入力できます。同じエディタを使用して、アプリケーション・ロールを作成し、アプリケーション・ロールのメンバーとしてテスト・ユーザーまたはエンタープライズ・ロールを割り当てることができます。定義されると、この情報はjazn-data.xml
ファイルのポリシー・ストア・セクションに表示されます。
アプリケーションのアイデンティティ・ストアに一時的なユーザーのセットを生成して、本番環境での実際のユーザーの体験をシミュレートします。統合WebLogic Serverでアプリケーションを実行すると、任意のテスト・ユーザーとしてログインでき、アプリケーションのセキュアADFリソースを表示するアクセス権を与えられます。
アイデンティティ・ストアを使用すると、エンタープライズ・ロールにユーザーをグループ分けすることができます。通常は、JDeveloperのデプロイメント・オプションを構成して、アイデンティティ・ストアをステージング環境に移行しないようにするため、jazn-data.xml
ファイルに作成するエンタープライズ・ロールは便宜上のものです。エンタープライズ・ロールの使用方法の詳細は、35.4.3項「エンタープライズ・ロールとアプリケーション・ロールについて」を参照してください。
注意: アイデンティティ・ストアのスタンドアロン・サーバーへのデプロイを選択する場合、Oracle WebLogic Serverに対してすでに構成されているローカル・アイデンティティ・ストアにユーザーとエンタープライズ・ロールを作成しないでください。たとえば、ユーザー |
ユーザーがリソースを表示できるようにするには、そうしたロールのメンバーであるユーザーではなく、アプリケーション・ロールに対して権限を付与します。したがって、アイデンティティ・ストアにテスト・ユーザーを生成した後で、各ユーザーまたはエンタープライズ・ロール・グループをアプリケーション・ロールに関連付ける必要があります。この関連付けにより、ADFセキュリティ・ポリシーによって定義されたアクセス権がユーザーに付与されます。アクセス権のユーザーへの付与の詳細は、35.6.3項「テスト・ユーザーとアプリケーション・ロールを関連付ける方法」を参照してください。
作業を始める前に、次のようにします。
アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、35.6項「テスト・ユーザーの作成」を参照してください。
テスト・ユーザーおよびグループを作成する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「ユーザー」を選択します。
jazn-data.xml
ファイルの概要エディタのユーザー・ページで、「レルム」ドロップダウン・リストからアプリケーションのレルムを選択し、次の手順を実行します。
JDeveloperによってデフォルト・レルムjazn.com
が自動的に作成されます。
「ユーザー」リストで「新規ユーザー」アイコンをクリックします。
「名前」フィールドにユーザー名を入力します。
Oracle WebLogic Serverに対してすでに構成されているユーザー名を選択しないでください(たとえば、webcenter
は入力しないでください)。Oracle WebLogic Serverによりインストールされているユーザー名のリストは、『Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
「パスワード」フィールドにユーザーのパスワードを入力します。他の任意のフィールドをクリックすると、パスワードがアイデンティティ・ストアに追加されます。
パスワードは8文字以上で指定し、特殊文字(!、%、^、&、$など)を少なくとも1つ含める必要があります。
必要に応じて、jazn-data.xml
ファイルの概要エディタで「エンタープライズ・ロール」ナビゲーション・タブをクリックし、アプリケーションのレルムを「レルム」ドロップダウン・リストから選択して、次の手順を実行します。
ユーザーをグループ分けしてアプリケーション・ロールに追加する場合のみ、エンタープライズ・ロールを作成します。統合WebLogic Serverを使用してアプリケーションを実行するためのテスト・ユーザーを作成する目的であれば、エンタープライズ・ロール・グループを作成する必要はありません。
「エンタープライズ・ロール」リストで「新規ロール」アイコンをクリックします。
「名前」フィールドにエンタープライズ・ロール名を入力します。他のいずれかのフィールドをクリックすると、ロールがアイデンティティ・ストアに追加されます。
エンタープライズ・ロール・グループを作成する場合、Oracle WebLogic Serverに対してすでに構成されているロール名を選択しないでください(たとえば、Administrators
は入力しないでください)。Oracle WebLogic Serverによりインストールされている全デフォルト・グループ名のリストは、『Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
ユーザー・アイデンティティとエンタープライズ・ロール・グループを含むアイデンティティ・ストアをプロビジョニングすると、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。
ダイアログによって、アイデンティティ・ストアに対応するファイルの<jazn-realm>
セクションにユーザー情報が書き込まれます。各ユーザー・アイデンティティには、ユーザー名とユーザー・ログイン・パスワードが含まれます。各エンタープライズ・ロールには1つ以上のメンバー・ユーザーが含まれます。
例35-12に、2つのユーザーと2つのエンタープライズ・ロールを含むjazn-data.xml
ファイルのアイデンティティ・ストアを示します。ユーザーahunold
とsking
は両方ともfod-users
エンタープライズ・ロールのメンバーで、sking
のみがfod-admin
エンタープライズ・ロールのメンバーです。
例35-12 アプリケーションレベル・アイデンティティ・ストアのユーザーとエンタープライズ・ロール
<jazn-data> <jazn-realm default="jazn.com"> <realm> <name>jazn.com</name> <users> <user> <name>sking</name> <guid>09FC5C61F68111DCAF1DB790A6B3BAC5</guid> <credentials>{903}A0VQ5ozADte7EKIJzcTi6xMZ7YDpRXY5</credentials> </user> <user> <name>ahunold</name> <guid>09FEA650F68111DCAF1DB790A6B3BAC5</guid> <credentials>{903}/SQSrKZYCLW068VJpHaodILd48mJI47w</credentials> </user> ... </users> <roles> <role> <name>fod-users</name> <guid>0A084340F68111DCAF1DB790A6B3BAC5</guid> <members> <member> <type>user</type> <name>sking</name> </member> <member> <type>user</type> <name>ahunold</name> </member> ... </members> </role> <role> <name>fod-admin</name> <guid>0A0CFE30F68111DCAF1DB790A6B3BAC5</guid> <members> <member> <type>user</type> <name>sking</name> </member> ... </members> </role> ... </roles> </realm> ... </jazn-realm> </jazn-data>
ADFセキュリティ・フレームワークは、アプリケーション・ロールに付与された権限を使用するロールベースのアクセス制御メカニズムを施行するため、アプリケーション固有の一連のロールをポリシー・ストアに定義します。たとえば、ワークフローのコンテキストでは、顧客、製品担当、監督者、管理者などのロールを想定できます。
アプリケーション・ロールを作成したら、アイデンティティ・ストアに作成したユーザーに1つ以上のロールを関連付けることができます。アプリケーション・ロールのメンバーであるユーザーには、実行時にアプリケーション・ロールのアクセス権が付与されます。複数のリソース権限を特定のユーザーに付与する場合は、1ユーザーを複数のアプリケーション・ロールに割り当てることができます。
たとえば、認証された1ユーザーがスーパーバイザ・ロールと従業員ロールに所属し、別の1ユーザーは従業員ロールのみに所属する場合があります。顧客レコードのブラウズと編集を許可するバインド・タスク・フローのセキュリティ・ポリシーでは、スーパーバイザ・ロールにview権限が与えられますが、従業員ロールにはブラウズ・ページのview権限に制限されます。このように、アプリケーション・ロールへの権限付与により複数レベルのアクセスに対応します。認証されたユーザーが、ターゲットADFリソースのview権限を持つアプリケーション・ロールのメンバーでない場合は、ユーザーが認証されていないというメッセージがセキュリティ・フレームワークによって返されます。
作業を始める前に、次のようにします。
アイデンティティ・ストアについて理解しておくと役立ちます。詳細は、35.6項「テスト・ユーザーの作成」を参照してください。
次のタスクを完了する必要があります。
ADFセキュリティの構成ウィザードを実行します。35.3項「ADFセキュリティの有効化」を参照してください。
アプリケーション・ロールを作成します。35.4項「アプリケーション・ロールの作成」を参照してください。
ADFセキュリティ対応リソースのセキュリティ・ポリシーを定義します。35.5項「ADFセキュリティ・ポリシーの定義」を参照してください。
テスト・ユーザーを作成し、必要に応じてエンタープライズ・ロール・グループを作成します。35.6.1項「JDeveloperでテスト・ユーザーを作成する方法」を参照してください。
ユーザーをアプリケーション・ロールに関連付ける手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「アプリケーション・ロール」を選択します。
jazn-data.xml
ファイルの概要エディタのアプリケーション・ロール・ページでは、「セキュリティ・ポリシー」ドロップダウン・リストからアプリケーションのポリシー・ストアを選択します。
JDeveloperによってjazn-data.xml
ファイルに作成されるポリシー・ストアは、自動的にアプリケーションの名前に基づきます。
「ロール」リストで既存のアプリケーション・ロールを選択し、必要に応じて次のタスクを実行します。
「マッピング」セクションで、「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「ユーザーの追加」を選択します。次に、「ユーザーの選択」ダイアログで、前に作成したユーザーをリストから選択して「OK」をクリックします。
アイデンティティ・ストアにエンタープライズ・ロールを定義している場合、必要であれば、「マッピング」セクションで「ユーザーまたはロールの追加」アイコンのドロップダウン・メニューをクリックして、「エンタープライズ・ロールの追加」を選択します。次に、「エンタープライズ・ロールの選択」ダイアログで、前に作成したエンタープライズ・ロールをリストから選択して「OK」をクリックします。
ユーザーにアプリケーション・ロールを関連付けると、Webアプリケーション・ワークスペースを基準とした/src/META-INF
ノードにあるjazn-data.xml
ファイルがJDeveloperによって更新されます。
ダイアログによって、ファイルの<policy-store>
セクションにユーザー情報が書き込まれます。各アプリケーション・ロールには1つ以上のメンバー・ユーザーまたはエンタープライズ・ロールが含まれます。
例35-13に、jazn-data.xml
ファイルのポリシー・ストアを示します。ここには、2つのメンバーsking
とahunold
を含むfod-users
アプリケーション・ロールがあります。
例35-13 アプリケーションレベル・ポリシー・ストアでのユーザーとアプリケーション・ロールの関連付け
<policy-store> <applications> <application> <name>StoreFrontModule</name> <app-roles> <app-role> <name>fod-users</name> <display-name>FOD Users</display-name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class> <name>sking</name> </member> <member> <class>oracle.security.jps.internal.core.principals.JpsXmlUserImpl</class> <name>ahunold</name> </member> ... </members> </app-role> ... </app-roles> <jazn-policy> ... </jazn-policy> </application> </applictions> </policy-store>
ADFセキュリティでは、暗黙的認証および明示的認証を使用できます。
暗黙的な認証のシナリオでは、未認証のユーザーがアクセスしようとするWebページが、anonymous-role
に権限付与されていないADFセキュリティ対応リソースに関連付けられている場合、認証が動的にトリガーされます。ユーザーが正常にログインすると、認証されたユーザーが、リクエストしたページのADFセキュリティ対応リソースに対するviewアクセス権を付与されているかどうかを検証するために別のチェックが実行されます。
明示的な認証のシナリオでは、ログイン・リンクが表示された公開ページがアプリケーションに用意され、このリンクをクリックすると、そのユーザーのログインにおいて認証チャレンジがトリガー実行されます。ログイン・リンクには、認証が成功した後に表示するいくつかの他のターゲット・ページ(認証済ユーザーがアクセス権を持っている場合)を指定できます。
暗黙的な認証のシナリオは、ADFセキュリティの構成ウィザードを実行するとデフォルトで処理されます。35.3.5項「ADF認証について」を参照してください。
明示的な認証のシナリオを処理するには、ADFセキュリティの構成ウィザードによってweb.xml
ファイルに追加されるallPages
セキュリティ制約を置き換え、ADF認証サーブレットに定義されているセキュリティ制約を使用して認証チャレンジをトリガーする必要があります。
注意: JSFベースのログイン・ページ用のユーザー・インタフェースを作成するこの手順は、Oracle WebLogic Server固有のAPI、およびこれによってサポートされるログイン・プロセスに依存します。Oracle WebLogic ServerにFusion Webアプリケーションをデプロイする場合のみ、この手順を使用します。 |
ユーザー認証を明示的に処理する手順:
ログイン・リンク・コンポーネントを作成し、アプリケーションのパブリック・ホームページに追加します。
Oracle WebLogic Server固有のAPIを使用して、ユーザーによるログインの試行を処理するマネージドBeanを作成します。
ADF Facesコンポーネントを使用して、JSFログイン・ページを作成します。
ADF Facesログイン・ページを使用するようにコンテナ管理デプロイメント・ディスクリプタ(web.xml
ファイル)を構成します。
アプリケーションのどのページにも追加できる標準的なログイン・リンク・コンポーネントを作成して、ユーザーの認証または以降のログオフができます。このコンポーネントは、ユーザーの認証状態を追跡し、適切なログインまたはログアウトのURLおよびアイコンを戻します。このログイン・リンク・コンポーネントは、ユーザーの認証後、ユーザーを特定のページにリダイレクトします。したがって、このログイン・リンク・コンポーネントを使用すると、一貫性のある単一のオブジェクトを得られます。
認証されていないユーザーに対しては、ログイン・リンク・コンポーネントは図35-16のように表示されます。
その後、ユーザーがログイン・リンクをクリックして、適切な資格証明を持つユーザーとしてログインすると、コンポーネントは図35-17のようになります。
作業を始める前に、次のようにします。
ADF認証について理解しておくと役立ちます。詳細は、35.7項「ログイン・ページの作成」を参照してください。
次のタスクを完了する必要があります。
public_html
ディレクトリにコピーします。
注意: アプリケーションでスキンを使用する場合は、使用されるイメージは適切なスキン・イメージを参照している必要があります。スキンの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「スタイルおよびスキンを使用した外観のカスタマイズ」の章を参照してください。 |
ログイン・リンク・コンポーネントを作成してページに追加する手順:
アプリケーション・ナビゲータで、コンポーネントを表示するWebページをダブルクリックします。
コンポーネント・パレットのADF Facesページで「実行イメージ・リンク」を選択して、ページまでドラッグします。
構造ウィンドウでaf:goImageLinkを右クリックし、「プロパティに移動」を選択します。
プロパティ・インスペクタで、条件付き言語(EL)式で指定されるリンク・テキストがレンダリングされるように、実行イメージ・リンク・コンポーネントの「テキスト」フィールドを設定します。
たとえば、次のようなEL式を入力できます。
#{securityContext.authenticated ? "Click to log out" : "Click to log in"}
現在のユーザーが認証されると、securityContext
Beanのauthenticated
プロパティがtrueに評価され、ログアウト・オプションがレンダリングされます。それ以外の場合はログイン・オプションのリンクがレンダリングされます。
プロパティ・インスペクタで、条件付きEL式で指定されるURLにユーザーが転送されるように、実行イメージ・リンク・コンポーネントの「宛先」フィールドを設定します。
たとえば、次のようなEL式を入力できます。
#{securityContext.authenticated ? "/adfAuthentication?logout=true& end_url=/faces/welcome.jspx" : "/adfAuthentication?success_url=/faces/welcome.jspx"}
ユーザーがリンクをクリックすると、URLパラメータend_url
およびsuccess_url
が宛先をADF認証サーブレットに転送します。現在のユーザーが認証されると、securityContext
Beanのauthenticated
プロパティがtrueに評価され、ようこそページに転送されます。ユーザーが認証されない場合、ログイン・ページに転送する必要はありません。ADF認証サーブレットでトリガーされるログインは、コンテナ管理セキュリティ構成によって処理されるためです。ログアウトは、セッションを無効にするADF認証サーブレットによって処理されることに注意してください。ログアウトはADFセキュリティによって処理されますが、プロセスを完了するためにブラウザ・キャッシュを消去する必要があります。Basic認証とブラウザ・キャッシュに関連する既知の問題の詳細は、35.7.5項「ADFサーブレットのログアウトとブラウザのキャッシュについて」を参照してください。
プロパティ・インスペクタで、条件付きEL式で指定されるリンク・コンポーネント・イメージがレンダリングされるように、実行イメージ・リンク・コンポーネントの「アイコン」フィールドを設定します。
たとえば、次の式は、ユーザーが認証されない場合にリンク・コンポーネント・イメージをロックのGIFとしてレンダリングします。それ以外の場合は、キーのGIFでイメージをレンダリングします。
#{securityContext.authenticated ? "/images/lock.gif" : "/images/key.gif"}
図35-18に、ログイン・リンク・コンポーネントをグローバル・メニュー・ファセットに追加するとどのように表示されるかを示します。
ADFセキュリティの構成ウィザードを実行して生成されるデフォルトのログイン・フォームは、JDeveloperでアプリケーションをテストする際に利用できるように提供されます。デフォルトのフォームでは、アプリケーションのユーザー・インタフェースに合せて、ADF Facesコンポーネントを使用してページをカスタマイズすることはできません。図35-19に示すように、カスタマイズ可能なコンポーネントを組み込めるADF Facesベースのログイン・ページによって、デフォルトのフォームを置き換えることができます。
ただし、ADF Facesコンポーネントを含むログイン・ページの設計が要件でない場合は、単純なJSPまたはHTMLのログイン・ページを使用することもできます。ADFセキュリティの構成ウィザードの実行時に単純なログイン・ページを生成する方法の詳細は、35.3.1項「ADFセキュリティを有効化する方法」を参照してください。
通常、Webアプリケーションにはパブリック・ページの概念があり、明示的な認証と暗黙的な認証に対応します。つまり、ユーザーがログイン・リンクをクリックしてアプリケーションにログインしてから、保護されたコンテンツにナビゲートできる場合と、保護されたページにナビゲートすると、アプリケーションのログイン・ページにリダイレクトされる場合があります。暗黙的な認証と明示的な認証の詳細は、35.8.4項「実行時に行われる処理: ADFセキュリティによる認証の処理」を参照してください。
ADF Facesページとしてログイン・ページを作成する前に、ログインの試行を処理するマネージドBeanを作成する必要があります。コンテナベースの認証は、コンテナのセキュリティ・モデル内のj_SecurityCheck
メソッドを利用します。Beanで定義されるログイン・メソッドがこのメソッドを使用して認証を施行します。このBeanをadfc-config.xml
ファイルに追加し、request
スコープで登録します。
注意: この手順で作成するバッキングBeanは、Oracle WebLogic Server固有のAPIとOracle WebLogic Serverでサポートされるログイン・プロセスに依存することに注意してください。Oracle WebLogic ServerにFusion Webアプリケーションをデプロイする場合のみ、この手順を使用します。 |
作業を始める前に、次のようにします。
ログイン・ページの知識があると役立ちます。詳細は、35.7.2項「ログイン・ページを作成する方法」を参照してください。
次のタスクを完了する必要があります。
次のクラスパス・エントリを含む新しいライブラリを作成して、ログインのためのバッキングBeanを作成するユーザー・インタフェース・プロジェクトに追加します。
modules/com.bea.core.weblogic.security.auth_1.1.0.0.jar
oracle.wlserver_10.3/server/lib/wls-api.jar
ユーザー・インタフェース・プロジェクトがこのライブラリを使用することで、、バッキングBeanコード・サンプルの次のimport文をコンパイルして解決できます。
import weblogic.security.SimpleCallbackHandler; import weblogic.security.services.Authentication; import weblogic.servlet.security.ServletAuthentication;
ライブラリを作成し、プロジェクトに追加する処理の詳細は、『Oracle Fusion Middleware Oracle JDeveloperユーザーズ・ガイド』の「アプリケーションとプロジェクトの操作について」を参照してください。
ログインのためのバッキングBeanを作成して登録する手順:
アプリケーション・ナビゲータで、ユーザー・インタフェース・プロジェクト・ノードを右クリックして、「新規」を選択します。
「新規ギャラリ」で、「一般」を展開し、「Java」、「Javaクラス」の順に選択して、「OK」をクリックします。
「Javaクラスの作成」ダイアログで、ログイン・ページのバッキングBeanクラス・ファイルの名前を入力し、デフォルトのオプション「スーパークラスからのコンストラクタ」と「抽象メソッドの実装」を無効にして、「OK」をクリックします。
たとえば、LoginPageName.javaのように、ログイン・ページ名に基づいてバッキングBeanの名前を付けると便利です。
アプリケーション・ナビゲータで「アプリケーション・ソース」ノードを開き、新しいLoginPageName.javaバッキングBeanをダブルクリックします。
ソース・エディタで、LoginPageName
.java
ファイルの宣言セクションに次のコードを追加して2つのprivateフィールドを作成します。
private String _username; private String _password;
両方のフィールドのパブリック・アクセッサを生成または作成します。
ソース・エディタを右クリックして、「アクセッサの生成」を選択すると、次のパブリック・アクセッサがファイルに追加されます。
public void setUsername(String _username) { this._username = _username; } public String getUsername() { return _username; } public void setPassword(String _password) { this._password = _password; } public String getPassword() { return _password; }
doLogin()
メソッドをこのJavaクラスに追加して、ユーザーのログイン試行を処理します。
1 public String doLogin() { 2 String un = _username; 3 byte[] pw = _password.getBytes(); 4 FacesContext ctx = FacesContext.getCurrentInstance(); 5 HttpServletRequest request = 6 (HttpServletRequest)ctx.getExternalContext().getRequest(); 7 CallbackHandler handler = new SimpleCallbackHandler(un, pw); 8 try { 9 Subject mySubject = Authentication.login(handler); 10 ServletAuthentication.runAs(mySubject, request); 11 ServletAuthentication.generateNewSessionID(request); 12 String loginUrl = "/adfAuthentication?success_url=/faces" + 13 ctx.getViewRoot().getViewId(); 14 HttpServletResponse response = 15 (HttpServletResponse)ctx.getExternalContext().getResponse(); 16 sendForward(request, response, loginUrl); 17 } catch (FailedLoginException fle) { 18 FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, 19 "Incorrect Username or Password", 20 "An incorrect Username or Password" + 21 " was specified"); 22 ctx.addMessage(null, msg); 23 } catch (LoginException le) { 24 reportUnexpectedLoginError("LoginException", le); 25 } 26 return null; 27 }
doLogin()
メソッドは、次のタスクを実行します。
行5~6は、FacesContext
からのHTTPリクエストをカプセル化するオブジェクトを取得します。
行7はCallbackHandler
を作成します。これは、セキュリティ操作のための情報を取得するオブジェクトです。SimpleCallbackHandler
により、セキュリティ操作が、コンストラクタに渡されたユーザー名とパスワードを取得できるようになります。他のCallbackHandler
実装は別のソースからユーザー名とパスワードを取得できます。
行9はSubject
を作成します。これは、CallbackHandler
によって提供される情報から資格証明をカプセル化するオブジェクトです。
行10は、Subject
によってカプセル化された資格証明を使用して、リクエストを発行するユーザーを記録しようとします。
行11は、ユーザーが正常に認証された後で、セッションのセッションIDを確実に変更するようにします。これは、セキュリティの脆弱性を招くセッション固定攻撃に対してアプリケーションをオープンにしないために必要です。
行12~13は、ユーザーの転送先のURLを作成します。getViewId()
コールは、コンテキスト・ルートから現在レンダリングされているページへのパスを返します。つまり、行が実行されるときユーザーがhome.jspx
ページを表示している場合、forwardURL
は/adfAuthentication?success_url=/faces/home.jspx
に設定されます。
行14~15は、FacesContext
からのHTTPレスポンスをカプセル化するオブジェクトを取得します。
行16はメソッドsendForward()
をコールします。このメソッドは、行12~13で指定されたURLにユーザーを転送するためにこの項で後から実装します。
行17~22はFailedLoginException
を処理します。これは、入力された資格証明が正しくないときにスローされる例外です。新しいメッセージをFacesContext
に追加して例外を処理します。
行23~24はLoginException
を処理します。これは、ログインにかかわる多様な問題によってスローされます。たとえば、資格証明が正しくない場合、ロックされたアカウントにログインを試行した場合、または期限切れパスワードを使用した場合に例外が生成されます。FailedLoginException
はLoginException
のサブクラスですが、FailedLoginException
は行17で捕捉されるため、不正確な資格証明以外のログインの問題がある場合のみ、これらの行が実行されます。reportUnexpectedLoginError()
は、ログイン・プロセスの様々な問題を処理するために実装するメソッドです。
行26はnullを返して、ADFコントローラが制御フロー・ケースを試行しないようにします。
次のクラスをインポートします。
javax.faces.application.FacesMessage javax.faces.context.FacesContext javax.security.auth.Subject javax.security.auth.callback.CallbackHandler javax.security.auth.login.FailedLoginException javax.security.auth.login.LoginException javax.servlet.http.HttpServletRequest javax.servlet.http.HttpServletResponse weblogic.security.SimpleCallbackHandler weblogic.security.services.Authentication weblogic.servlet.security.ServletAuthentication
メソッドsendForward()
およびreportUnexpectedLoginError()
のスタブを作成します。
アクションを含むsendForward()
メソッドを追加します。
1 private void sendForward(HttpServletRequest request, 2 HttpServletResponse response, 3 String forwardUrl){ 4 FacesContext ctx = FacesContext.getCurrentInstance(); 5 RequestDispatcher dispatcher = request.getRequestDispatcher(forwardUrl); 6 try { 7 dispatcher.forward(request, response); 8 } catch (ServletException se) { 9 reportUnexpectedLoginError("ServletException", se); 10 } catch (IOException ie) { 11 reportUnexpectedLoginError("IOException", ie); 12 } 13 ctx.responseComplete(); 14 }
sendForward()
メソッドは、次のタスクを実行します。
行5はRequestDispatcher
を作成します。これはレスポンスを特定のURIに転送します。
行7はRequestDispatcher
を使用して、現在のHTTPレスポンスをURLに転送します。
行8~9はServletException
を処理します。これがスローされるのは、RequestDispatcher
のターゲットURIが例外をスローするときです。
行10~11はIOException
を処理します。これがスローされるのは、リクエストを読み取ることができないとき、またはレスポンスを書き込むことができないときです。
行13はHTTPレスポンスを完了とマークして、ブラウザがレンダリングを終了できるようにします。
次のクラスをインポートします。
javax.servlet.RequestDispatcher javax.servlet.ServletException java.io.IOException
reportUnexpectedLoginError()
メソッドを実装します。
private void reportUnexpectedLoginError(String errType, Exception e){ FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, "Unexpected error during login", "Unexpected error during login (" + errType + "), please consult logs for detail"); FacesContext.getCurrentInstance().addMessage(null, msg); e.printStackTrace(); }
このreportUnexpectedLoginError()
メソッドは、サマリー・エラー・メッセージをFacesContext
に追加し、例外のフル・スタック・トレースをコンソールに出力します。
Javaファイルを保存します。
アプリケーション・ナビゲータで、WEB-INFノード内のadfc-config.xmlノードをダブルクリックします。
adfc-config.xml
ファイルのエディタ・ウィンドウで「概要」タブをクリックします。
タスク・フローの概要エディタで、「マネージドBean」ナビゲーション・タブをクリックします。
マネージドBeanページの「マネージドBean」セクションで、「追加」アイコンをクリックして、Bean名と完全修飾クラス名を入力し、request
スコープを選択します。
たとえば、クラス名は図35-20のoracle.foddemo.security.Login
のようになります。
すべてを保存します。
ADF Facesレイアウト・コンポーネントおよびADF Facesユーザー・インタフェース・コンポーネントを利用する単純なログイン・ページには、2つの入力フィールドと1つのボタンが含まれます。これらのUIコンポーネントのプロパティを、ログイン・ページのマネージドBeanに定義したログイン・ハンドラ・メソッドにバインドする必要があります。
作業を始める前に、次のようにします。
ログイン・ページの知識があると役立ちます。詳細は、35.7.2項「ログイン・ページを作成する方法」を参照してください。
次のタスクを完了する必要があります。
ADF Facesベースのログイン・ページを作成する手順:
アプリケーション・ナビゲータで、ユーザー・インタフェース・プロジェクト・ノードを右クリックして、「新規」を選択します。
「新規ギャラリ」で「Web層」を展開し、「JSF」、「JSFページ」の順に選択し、「OK」をクリックします。
「JSFページの作成」ダイアログで、「XMLドキュメントの作成(*.jspx)」を選択します。
「ファイル名」フィールドで、ログイン・ページの名前を指定します。たとえば、LoginPage.jspx
を入力します。
他のオプションは選択しません。また、マネージドBeanでUIコンポーネントを公開するオプションは選択しないでください。ログイン・ページのために作成したマネージドBeanにコンポーネントを手動でバインドします。
「OK」をクリックします。
ページを保存します。
コンポーネント・パレットのADF Facesページで、「レイアウト」パネルから「パネル・ボックス」をドラッグし、構造ウィンドウのaf:formノードの下にドロップします。
プロパティ・インスペクタで、「テキスト」、「水平方向」、「幅」および「高さ」フィールドを設定します。
たとえば、Fusion Order DemoアプリケーションのMaster Price Listモジュールに表示されるログイン・ページを再作成するには、次のように入力します。
「テキスト」にLogin Information
を設定します。
「アイコン」に/images/key_ena.png
を設定します。
「幅」および「高さ」に300
および200
ピクセルを設定します。
コンポーネント・パレットから「パネル・フォーム・レイアウト」をドラッグして、構造ウィンドウのaf:panelBoxノードの下にドロップします(図35-21)。
コンポーネント・パレットのADF Facesページで、ユーザー名フィールド用に「入力テキスト」を「パネル・フォーム・レイアウト」ノードにドラッグし、パスワード・フィールド用にもう1つの「入力テキスト」をドラッグします。
プロパティ・インスペクタで、各入力フィールドの「ラベル」フィールドをUsername
およびPassword
に設定し、両方のフィールドの「動作 - 必須」フィールドをtrueに設定します。
プロパティ・インスペクタで、パスワード・フィールドの「外観 - 機密」フィールドをtrueに設定します。
2つの入力フィールドの値を処理するために、各フィールドで次の手順を実行します。
構造ウィンドウで、入力フィールドの1つを選択し(たとえばaf:inputText - Usernameノードを選択)、プロパティ・インスペクタで「値」フィールドの右側にある「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、Beanのハンドラ・メソッドに対応する式の値を選択します。
たとえば、構造ウィンドウでusername入力フィールドを選択した場合は、図35-22のように「式ビルダー」ダイアログでusernameを選択します。
「OK」をクリックします。
「プロパティ・インスペクタ」に表示される式により、ログイン・ページのために作成したマネージドBeanにフィールドがバインドされます。たとえば、username入力フィールドの場合、式は#{loginPageBean.username}
のようになります(図35-23)。
コンポーネント・パレットの「パネル枠線レイアウト」を、af:panelBoxノードのfooterノードの内側にドラッグ・アンド・ドロップします(図35-24)。
JSP/HTMLビジュアル・エディタで、ラベルが「端」、「上」および「下」のパネル枠線レイアウト・ファセットを削除します。「開始」ファセットのみを残します。
構造ウィンドウで、「パネル枠線レイアウト」ファセットを開いてstartノードを選択し、コンポーネント・パレットから「ボタン」をドラッグ・アンド・ドロップします。
プロパティ・インスペクタで、ボタン・コンポーネントの「テキスト」フィールドをLogin
に設定します。
ログイン・ボタンのアクションを処理するには、次の手順を実行します。
構造ウィンドウでstartノードにあるaf:commandButtonを選択し、プロパティ・インスペクタで「アクション」フィールド右側の「プロパティ・メニュー」ドロップダウン・メニューをクリックして、「式ビルダー」を選択します。
「式ビルダー」で「ADFマネージドBean」を開き、作成したログインBeanを開いて、ログイン・メソッドに対応する式の値を選択します。
たとえば、ログインBeanにdoLogin()
という名前のメソッドを作成した場合は、「式ビルダー」ダイアログでdoLoginを選択します。
「OK」をクリックします。
「プロパティ・インスペクタ」に表示される式により、ログイン・ページのために作成したマネージドBeanにボタンがバインドされます。たとえば、ログイン・ボタンの場合、式は#{loginPageBean.doLogin}
のようになります(図35-25)。
ページを保存します。
ログイン・ページはコンテナから直接コールされるため、ADF Facesナビゲーション・プロセスには含まれません。このため、ログイン・ページをコールするときに、ADF Facesサーブレットへのコールを強制的に行う必要があります。
ADFセキュリティの構成ウィザードの認証タイプ・ページでこのように設定できます。あるいは、web.xml
ファイルで直接行うことができます。すでにADFセキュリティの構成ウィザードを実行している場合は、次の手順に従って、説明したようにweb.xml
ファイルが更新されていることを確認できます。
作業を始める前に、次のようにします。
ログイン・ページの知識があると役立ちます。詳細は、35.7.2項「ログイン・ページを作成する方法」を参照してください。
ADF Facesライフ・サイクルの一部としてログイン・ページを参照する手順:
アプリケーション・ナビゲータでWEB-INFノードを開き、web.xmlをダブルクリックします。
概要エディタで、「セキュリティ」ナビゲーション・タブをクリックします。
セキュリティ・ページで「ログイン認証」セクションを開き、ADF Facesサーブレットへの参照を含むようにログイン・ページを設定します。こうすることで、ログイン・ページがADF Facesライフサイクル/faces/ADFlogin.jspx
ページの一部になります。
ファイル・ブラウザを使用してページを追加すると、web.xml
ファイルに入力されるパスに/faces
が指定されません。ADF Facesサーブレットのサーブレット・マッピング・パスを参照するようにパスのエントリを変更します。たとえば、マッピングで指定されるURLパターンが/faces/*
の場合、パスを/faces/
yourpage
.jspx
とする必要があります(図35-26)。
アプリケーションはADFセキュリティによって保護されるため、デフォルトでは、バインド・タスク・フローに定義されたすべてのWebページ、およびADFページ定義によって定義されたすべてのWebページにはアクセスできません。すべてのユーザーがログオンできるようにする必要があるため、ログイン・ページは公開する必要があります。このため、ログイン・ページにはデータバインド・コンポーネントを追加しないでください。ログイン・ページでデータバインド・コンポーネントが使用されないかぎり、このページにはデフォルトでアクセスできます。
コンテナがページ(この場合は認証ページ)へのアクセスを許可する前に、定義済の認証ポイントに常にリダイレクトすることを保証するには、これ以上の手順は必要ありません。
ADFセキュリティ・ウィザードを実行して「ADF認証」オプションを選択した場合(ADF認可を有効にしない)、アプリケーションでカスタム・ログイン・ページまたはカスタム・エラー・ページを使用するのであれば、必要に応じて、ADFセキュリティによってweb.xml
ファイルに追加されたデフォルトのJava EEセキュリティ制約を編集する必要があります。例35-26に示すように、allPages
セキュリティ制約に定義されるデフォルトのURLパターン(/*
)は、Java EEアプリケーション・ルート以下すべてに対応します。つまり、ログイン・ページに使用される各リソース・ファイル(イメージ、スタイル・シート、JavaScriptライブラリなど)もこれに含まれます。
例35-14 ADF認証専用のJava EEセキュリティ制約
<security-constraint> <web-resource-collection> <web-resource-name>allPages</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>valid-users</role-name> </auth-constraint> </security-constraint>
作成するページがリソース(イメージ、CSSファイルまたはJavaScriptライブラリなど)を使用する場合、web.xml
ファイルのデフォルトのallPages
セキュリティ制約により、そのようなリソースが実行時にロードされなくなります。アプリケーションでそれらのリソースを表示するためには、リソースを独自のフォルダに保存し、そのリソース・フォルダがURLパターンに含まれないようにallPages
セキュリティ制約を編集する必要があります。
ADFセキュリティの構成ウィザードを実行して、「ADF認証および認可」オプション(デフォルト)を選択した場合は、このようなリソースの問題が生じないことに注意してください。特に、この場合にデフォルトで生成される制約がADF認証サーブレットに対応し、制約(/adfAuthentication
)によってすべてのリソース・ファイルが除外されます。
Webアプリケーションは通常は保護されているため、認証されていないユーザーのための開始地点すなわちホームページが必要になります。このようなパブリックなようこそページを作成するには、アプリケーション内の他のページへのリンクを含み、アプリケーションの開始地点として機能するADF Facesページを作成します。ただし、認証されていないユーザーに対してはパブリック・ページへのリンクしかレンダリングできません。反対に、セキュア・ページへのリンクをレンダリングするのは、ユーザーがログインし、ターゲット・ページを表示する適切な権限を持っている場合のみです。
ベスト・プラクティス: ユーザーが[Ctrl]を押しながら[N]を押すか[Ctrl]を押しながら[T]を押して、新しいブラウザ・ウィンドウまたはタブを開いたとき、アプリケーションの |
標準のADF Facesページを作成すると、ページはデフォルトでパブリックになり、認証されていないユーザーがアクセスできます。ただし、ようこそページをADFリソースに関連付けた場合(「データ・コントロール」パネルを使用してデータバインドADF Facesコンポーネントをようこそページにドラッグ・アンド・ドロップするなど)、ADFセキュリティによってデフォルトでページが保護されます。jazn-data.xml
ファイルの概要エディタを使用して、提供されているanonymous-role
にADFリソースのview権限を付与すると、任意のADFリソースを公開できます。anonymous-role
の詳細は、35.5.2項「ADFリソースの公開時の処理」を参照してください。
ログイン・リンクやログアウト・リンクをパブリックのようこそページに追加して、ログインやアプリケーション使用中のログアウトをユーザーが明示的に行えるようにします。Java EEコンテナ管理セキュリティでは、保護されているリソースにアクセスする際に認証の概念がサポートされますが、ログアウトした後も保護されたアプリケーションにとどまる標準の方法はありません。ただし、一般的なWebアプリケーションの場合、ページがパブリックであれば、ユーザーは同じページにとどまります。あるいは、ページが保護されている場合はようこそページが再び表示されます。各ページにログイン・リンクとログアウト・リンクを追加すると、ユーザーがアプリケーション内の任意の場所でログイン・セッションを終了できます(ようこそページに戻る)。また、ようこそページにこれらのリンクがあると、ユーザーがアプリケーションを開始するときに明示的に認証されます。
たとえば、3つのコンポーネント(出力テキスト領域、イメージ、実行リンク)を含むADF Facesパネル・グループを作成できます。適切なログイン・リンクまたはログアウト・リンクをレンダリングするために、ユーザーの認証ステータスを評価するEL式を使用できます。特に、securityContext.authenticated
を使用すると、例35-15に示すようにADFセキュリティ・コンテキストにアクセスできます。この式はtrue
またはfalse
として評価され、この例では、結果によって、表示するログイン・イメージまたはログアウト・イメージとリンクが決まります。例35-15に示すように、ADF認証サーブレットのsuccess_url
およびend_url
パラメータは、ターゲット・ページwelcome.jspx
と関連付けられたビュー・アクティビティwelcome
として渡されます。URLパラメータに対するWebページ名ではなく、ビュー・アクティビティ名を渡すことで、Fusion Webアプリケーションではページ・ナビゲーションの処理にタスク・フローの制御フロー・ルールが使用されるようになります。
例35-15 ログイン/ログアウト・リンクをレンダリングするADF FacesコンポーネントとEL式
<af:panelGroupLayout inlineStyle="width:100%; height:15px;" id="ptpgl3"> <af:spacer width="7" height="10" id="pts2"/> <af:outputText value="Welcome #{securityContext.userName}!" inlineStyle="font-weight:bold; width:100px" id="ptot2" rendered="#{securityContext.authenticated}"/> <af:image source='#{securityContext.authenticated ? "/images/lock.gif" : "/images/key.gif"}' id="pti2" inlineStyle="width:16px; height:16px;" shortDesc="switchable icon"/> <af:goLink text="#{securityContext.authenticated ? "Logout" : "Login"}" destination="#{securityContext.authenticated ? "/adfAuthentication?logout=true&end_url=/faces/welcome" : "/adfAuthentication?success_url=/faces/welcome"}" inlineStyle="color:White; font-size:14px; font-weight:bold;"/> <f:facet name="separator"> <af:spacer width="5" height="10" id="pts1"/> </f:facet> </af:panelGroupLayout>
ページ内にリンクを直接レンダリングするかわりに、35.7.1項「ログイン・リンク・コンポーネントを作成してパブリックWebページに追加する方法」で説明するように、ログイン・リンクとログアウト・リンクを含むログイン・リンク・コンポーネントを作成して、ページ・テンプレートに追加できます。
セキュリティ保護されたページに無名ユーザーがアクセスできないように、ようこそページ上のセキュリティ保護されたページをポイントするナビゲーション・コンポーネントを、次の2つの基準に基づいてビューから非表示にする必要があります。
ユーザーが既知のユーザー・アイデンティティで認証されているか
指定されたユーザー・アイデンティティがターゲットの表示権限を持っているか
これらの条件の一方が満たされない場合、パブリック・ページ上でセキュリティ保護されたリソースをポイントするすべてのナビゲーション・コンポーネントは、そのrendered
属性をfalse
に設定して、無名ユーザーに対して非表示にする必要があります。ようこそページでこのような規則を施行するには、35.11.1「ADFセキュリティでの式言語(EL)の使用」を参照してください。
ユーザーが保護されたWebページにアクセスしてログインした後、ADF認証サーブレットは、ログイン・リクエストが発行された最初のページにユーザーをリダイレクトします。ADFセキュリティ認証が有効な場合、ADF認証サーブレットは、URLに対するADF認証のsuccess_url
パラメータとして元のページを自動的に渡します。認証後、保護されたページへのリダイレクトがADF認証サーブレットによって確実に行われるように、例35-16に示すように、Webページのビュー・アクティビティ名をサーブレットのsuccess_url
パラメータとして渡します。
例35-16 success_urlを含むWebページの明示的なログイン・リンク
<af:goLink text="Login" destination="/adfAuthentication?success_url=/faces/viewactivityname"/>
ベスト・プラクティス: Fusion WebアプリケーションがADF認証リダイレクトをADFコントローラのナビゲーション・イベントとして処理するようにするには、リダイレクト・ターゲットをビュー・アクティビティ名で指定します。かわりにWebページ名を指定した場合、ユーザーのログイン後、ADFコントローラ・ハンドラがターゲット・ページに関連付けられた制御フロー・ルールを特定できなくなる可能性があります。リダイレクト・ターゲットとしてビュー・アクティビティを指定しない場合、特に |
さらに、元のページにリダイレクトできないケースを処理するために、web.xml
ファイル内でsuccess_url
パラメータを<init-param>
として指定できます。こうすると、保護されたWebページにユーザーがアクセスし、ログインのためにリダイレクトされるとき、フレームワークによって、元のページがURLのsuccess_url
パラメータとして自動的に渡され、web.xml
の設定よりも優先されます。したがって、web.xml
の<init-param>
設定が有効になるのは、ユーザーがadfAuthentication
URLをブラウザに明示的に入力する場合のみです。
ユーザーが認証されたが、Webページの表示を認可されない場合は、ADF認証サーブレットをアプリケーションのエラー・ページにリダイレクトできます。タスク・フローを使用しない設計のアプリケーションを作成した場合を除いて、Fusion Webアプリケーションのエラー処理は、ADFコントローラの例外ハンドラで制御されます。たとえば、ADFページ定義で保護された、トップレベルのようこそページと1つのブラウズ・ページを含むバインドなしタスク・フローを定義した場合、例35-17に示すようにアプリケーションのエラー・ページ(adfc-config.xml
ファイルに指定されたauthorizationErrorPage.jspx
)が表示されます。
例35-17 タスク・フローを使用するアプリケーションのエラー・ページ・リダイレクト
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller" version="1.2"> <exception-handler>authorizationErrorPage</exception-handler> <view id="welcomePage"> <page>/welcomePage.jspx</page> </view> <view id="browse"> <page>/browse.jspx</page> </view> <view id="authorizationErrorPage"> <page>/authorizationErrorPage.jspx</page> </view> <control-flow-rule> <from-activity-id>welcomePage</from-activity-id> <control-flow-case> <from-outcome>goToSecuredPage</from-outcome> <to-activity-id>browse</to-activity-id> </control-flow-case> </control-flow-rule> </adfc-config>
ADFコントローラ例外ハンドラのビュー・アクティビティとしてエラー・ページを指定する方法の詳細は、22.4項「タスク・フローでの例外の処理」を参照してください。
ユーザーが認証されず、認可の失敗が発生した場合は、フレームワークがADF認証サーブレットにリダイレクトし、ADF認証サーブレットがログインを求めるJava EE制約をトリガーします。この場合、コンテナ管理セキュリティは、web.xml
ファイルの<login-config>
要素に指定されているログイン・ページとエラー・ページを利用します。
タスク・フローを使用せずにFusion Webアプリケーションを作成する場合、例35-18に示すようにADFバインディング・フィルタのための<init-param>
設定をweb.xml
に指定できます。アプリケーションにタスク・フローがないこのケースでは、ページ認可チェックがADFバインディング・フィルタによって処理され、unauthorizedErrorPage
パラメータがADFバインディング・リクエスト・ハンドラに渡されます。
注意:
|
例35-18 タスク・フローを使用しないアプリケーションのエラー・ページ・リダイレクト
<filter> <filter-name>adfBindings</filter-name> <filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class> <init-param> <param-name>unauthorizedErrorPage</param-name> <param-value>faces/authorizationErrorPage.jspx</param-value> </init-param> </filter>
アプリケーションのweb.xml
ファイルの指定に基づいてBasic認証が有効な場合、ブラウザは認証資格証明をキャッシュします。これはBasic認証の既知の問題です。ADF認証サーブレットがログアウトを完了できず、ユーザーがログアウト後もリソースにアクセスできます。このシナリオでは、ログアウト・セッションを完了するために、ブラウザを閉じて新しいブラウザ・セッションを再起動する必要があります。ADF認証サーブレットがログアウトを完了し、ログアウト後はユーザーがリソースにアクセスできないようにするには、Basic認証のかわりにフォームベース認証を使用します。35.3.1項「ADFセキュリティを有効化する方法」で説明するように、ADFセキュリティの構成ウィザードを実行してフォームベース認証を選択できます。
統合WebLogic Serverにより、アプリケーションを直接JDeveloper内部で実行して、アプリケーションで定義するアプリケーション・ポリシー、ユーザーおよび資格証明などのセキュリティ・オブジェクトを移行するかどうかを決定できます。デフォルトでは、アプリケーションを実行するたびにすべてのセキュリティ・オブジェクトが統合WebLogic Serverに移行されます。
JDeveloperはデフォルトで、アプリケーションを実行するたびにアプリケーション・リポジトリから統合WebLogic Serverにセキュリティ・オブジェクトをデプロイするよう構成されています。この動作は、「アプリケーション・プロパティ」ダイアログでのセキュリティ・デプロイメント・オプションの選択により、次のように変更できます。
ドメインレベル・ポリシーをアプリケーションのjazn-data.xml
ファイル内のポリシーにより上書きするかどうかを決定します。
システム資格証明をアプリケーションのcwallet.sso
ファイルにより上書きするかどうかを決定します。
jazn-data.xml
ファイルのアイデンティティ・ストアの一部をドメインレベル・アイデンティティ・ストアに移行するかどうかを決定します。
デプロイ設定を変更しない場合、アプリケーションを実行するたびに、JDeveloperはドメイン・レベルのセキュリティ・ポリシーおよびシステム資格証明を上書きします。また、テスト目的で作成した新しいユーザー・アイデンティティを移行し、統合WebLogic Serverがそのアイデンティティ・ストアで使用する埋込みLDAPサーバー内の既存のユーザー・パスワードを更新します。しかし、統合WebLogic Server内の既存のセキュリティ・オブジェクトを更新せずにアプリケーションを実行する場合には、このオプションを選択できます。
作業を始める前に、次のようにします。
統合WebLogic Serverについて理解しておくと役立ちます。詳細は、35.8項「JDeveloperでのセキュリティのテスト」を参照してください。
セキュリティ・デプロイメントを構成し、JDeveloperでアプリケーションを実行する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「セキュリティ・デプロイメントの構成」を選択します。
「アプリケーション・プロパティ」ダイアログのデプロイメント・ページの「セキュリティ・デプロイメント・オプション」セクションで、統合WebLogic Serverにデプロイするセキュリティ・オブジェクトを選択します。
デフォルトでは、アプリケーションを実行するたびに、JDeveloperによって、ドメイン・レベルのアプリケーション・ポリシーとシステム資格証明がアプリケーションのアプリケーション・ポリシーとシステム資格証明で上書きされます。これらリポジトリのいずれかを上書きしない場合は、「アプリケーション・ポリシー」または「資格証明」を選択解除します。選択解除した場合、JDeveloperでは新しいポリシーまたは資格証明のみがドメインレベル・ストアにマージされます。
デフォルトでは、アプリケーションを実行するたびに、テスト目的で作成する新規ユーザーのアイデンティティがJDeveloperによって移行され、統合WebLogic Serverでアイデンティティ・ストア用に使用される埋込みLDAPサーバーにある既存のユーザー・パスワードが更新されます。「ユーザーとグループ」を選択解除して、アプリケーションのアイデンティティ・ストアの移行を無効にできます。
「OK」をクリックします。
アプリケーション・ナビゲータで、保護されたWebページが含まれるユーザー・インタフェース・プロジェクトを右クリックし、「実行」を選択します。
ユーザー・インタフェース・プロジェクトで「実行」を選択すると、JDeveloperでは、プロジェクトについて構成済のデフォルト実行ターゲットを使用してアプリケーションが実行されます。たとえば、実行ターゲットとしてタスク・フロー・アクティビティを構成して、アプリケーションを起動できます。デフォルトの実行ターゲットを構成するには、18.5項「タスク・フローのテスト」を参照してください。
アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。
統合WebLogic Serverを使用してアプリケーションを実行するとき、JDeveloperは、「アプリケーション・プロパティ」ダイアログに指定したセキュリティ・デプロイメント構成設定に基づいて、セキュリティ・ポリシーと資格証明をドメイン・レベルに移行します。デプロイメント・プロセスで、JDeveloperは、例35-19に示すように、「アプリケーション・プロパティ」の設定に基づいてデプロイメント・アーカイブ・ファイルに追加するweblogic-application.xml
ファイルを更新します。これらの設定はアプリケーション・ソース・ディレクトリのweblogic-application.xml
ファイルには追加されないため、表示されないことに注意してください。
例35-19 アーカイブweblogic-application.xmlファイルでのデフォルト・セキュリティ・デプロイメント設定
<application-param> <param-name>jps.credstore.migration</param-name> <param-value>OVERWRITE</param-value> </application-param> <application-param> <param-name>jps.policystore.migration</param-name> <param-value>OVERWRITE</param-value> </application-param>
OVERWRITE
値を指定すると、アプリケーションのセキュリティ・ポリシーと資格証明を変更して、開発モードで実行しているOracle WebLogic Server、または統合WebLogic Server(デフォルトで開発モードで実行するように設定されている)にどちらも再デプロイすることができます。
注意: いずれ本番環境にデプロイする際には、 |
また、例35-20に示すように、JDeveloperはweblogic-application.xml
ファイルをOPSSライフサイクル・リスナーでも更新します。アプリケーションが実行する前に移行プロセスを開始するために、ライフサイクル・リスナーはポリシーと資格証明について移行設定を確認し、ドメイン・レベルでセキュリティ・オブジェクトを上書きします。
例35-20 アーカイブweblogic-application.xmlファイルのセキュリティ移行リスナー
<listener> <listener-class> oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener </listener-class> </listener> <listener> <listener-class> oracle.security.jps.wls.listeners.JpsAppVersionLifecycleListener </listener-class> </listener>
移行プロセスで、JDeveloperはOracle Platform Security Services (OPSS)アプリケーション・ロール・メンバー・クラスを統合WebLogic Serverメンバー・クラスにマッピングし、ユーザーをWebLogic Serverアイデンティティ・ストアusers
に移行し、ロールを統合WebLogic Serverアイデンティティ・ストア・グループに移行します。Oracle WebLogic Serverでは、users
はOPSSのauthenticated-role
と同等の暗黙のグループです。
例35-21 system-jazn-data.xmlファイル内のアプリケーション・ロール・フラグメント
<app-roles> <app-role> <name>fod-users</name> <guid>FFFF394F696E786F4134485764511002</guid> <display-name/> <description/> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <name>fod-users</name> <class>weblogic.security.principal.WLSGroupImpl</class> </member> </members> </app-role> </app-roles>
アイデンティティ・ストアの移行は、weblogic-application.xml
ファイルのアプリケーション・ライフサイクル・リスナー設定では制御されません。かわりに、統合WebLogic Serverで実行するとき、またはJDeveloperからデプロイするときは、Oracle WebLogic Mbeanによってアイデンティティの移行が処理されます。ユーザーがすでに存在している場合、Mbeanはユーザー定義全体を移行しません。ユーザーのパスワードだけを更新します。
ADFセキュリティの構成ウィザードを実行すると、jazn-data.xml
ファイルのポリシー・ストアにtest-all
アプリケーション・ロールを追加するオプションを有効にできます。このオプションを有効にするときは、アプリケーションのアプリケーション・ロールへの権限付与のスコープも指定します。
JDeveloperでtest-all
アプリケーション・ロールにview権限を付与し、ウィザードの実行時にユーザー・インタフェース・プロジェクトに表示されるADFタスク・フローとWebページすべてにこのポリシーを適用するには、「既存のオブジェクトのみに付与」を選択します。
JDeveloperでtest-all
アプリケーション・ロールにview権限を付与し、開発者がユーザー・インタフェース・プロジェクトで作成した既存のADFタスク・フローとWebページ、および今後ユーザー・インタフェース・プロジェクトで作成するすべてのADFタスク・フローとWebページにこのポリシーを適用するには、「すべてのオブジェクトに付与」を選択します。「すべてのオブジェクトに付与」オプションを選択してウィザードを初めて実行した後は、ウィザードによりオプション「新規オブジェクトに付与」が表示されます。
ウィザードを実行した後では、test-all
ロールがjazn-data.xml
ファイルに含まれ、jazn-data.xml
ファイルの概要エディタで確認できます。test-all
ロールにテスト・ユーザーを移入する必要はありません。ウィザードによって、組込みアプリケーション・ロールanonymous-role
がtest-all
ロールに割り当てられるためです。この場合、すべてのユーザーは自動的にanonymous-role
プリンシパルを保持し、アプリケーションへのアクセスを許可されます。
注意: 35.9.1項「アプリケーション・ポリシー・ストアからtest-allロールを削除する方法」で説明するように、アプリケーションをデプロイする前に、 |
いつでもウィザードを再実行して、自動付与を無効にすることができます。いったん無効になると、新たに作成するADFタスク・フローとWebページはtest-all
ロールを利用しないため、35.5項「ADFセキュリティ・ポリシーの定義」で説明するように明示的な付与を定義する必要があります。
統合WebLogic Serverを使用してJDeveloperでアプリケーションをテストするとき、アイデンティティ・ストアが、Oracle Internet Directoryに格納されている情報と一緒に埋込みLDAPサーバーに移行されます。
図35-27に、ユーザーがあらかじめログインせずに、ADFバインド・タスク・フローまたはADFバインディングを含むWebページ(mypage.jspx
など)にアクセスを試行するときの認証プロセスを示します。ユーザーがパブリック・ページのログイン・リンクをクリックしてログインを開始するのではないため、認証は暗黙的に開始されます。セキュリティ保護されたページの場合、無名ユーザーに対して権限付与は行われません。
図35-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セキュリティのための認可が施行されているかどうかに依存します。35.8.5項「実行時に行われる処理: ADFセキュリティによる認可の処理」を参照してください。
図35-28は、パブリック・ページの「ログイン」リンクから開始するプロセスで、ユーザーが認証される場合の明示的認証処理を示しています。
明示的認証のシナリオでは、(anonymous
ユーザー・プリンシパルとanonymous-role
プリンシパルのみを持つ)認証されていないユーザーが、パブリック・ページの「ログイン」リンクをクリックします(図のステップ1)。「ログイン」リンクは、web.xml
ファイルのJava EEセキュリティ制約を介してセキュリティ保護されているADF認証サーブレットへのダイレクト・リクエストです。
このシナリオでは、現在のページがパラメータとしてADF認証サーブレットに渡されます。暗黙的認証のケースと同じく、セキュリティ制約によってユーザーがログイン・ページにリダイレクトされます(図のステップ2)。暗黙的認証ケースのステップa~ステップdで説明したようにコンテナがユーザーを認証すると、リクエストがADF認証サーブレットに戻されます(図のステップ3)。その後、サーブレットによってユーザーがパブリック・ページに戻されますが、その時点では新しいユーザーおよびロール・プリンシパルが配置されています。
ADF認可が有効になってるとき、ADFバインド・タスク・フローとタスク・フロー外部のWebページ(ADFページ定義がある)はデフォルトで保護されます。ユーザーがこれらのWebページにアクセスしようとすると、ADF Securityが、ポリシー・ストアでそのユーザーがアクセス権を付与されているかどうか、確認して判定します。ユーザーがまだ認証されていず、anonymous-role
に対してページが許可されていない場合、ログイン・ページまたはフォームが表示されます。認証されたユーザーでも権限がない場合は、セキュリティ・エラーが表示されます。ポリシー・ストアに適切な権限を構成していない場合、ページは保護された状態に維持され、したがって認証されたユーザーも利用できません。
図35-29は、認可プロセスを示しています。
このユーザーは、ポリシー・ストアに定義されたアプリケーション・ロールstaffのメンバーです。ユーザーがまだログインしていないため、セキュリティ・コンテキストにはサブジェクト(ユーザーを表すコンテナ・オブジェクト)がありません。そのかわりに、Oracle Platform Security Servicesにより、ADFセキュリティに対して、anonymous
ユーザー・プリンシパル(ユーザーの一意の定義)とanonymous-role
プリンシパルを持つサブジェクトが提供されます。
anonymous-role
プリンシパルを使用すると、通常、ユーザーはADFリソースで定義されないページのみ(public.jsp
ページなど)にアクセスできます。これに対して、ADFタスク・フローで定義されたページまたはADFページ定義ファイルを使用するタスク・フロー外部のページはすべてデフォルトで保護され、ユーザーはアクセスできません。このセキュリティ・ポリシーの例外は、ポリシー・ストアでADFリソースに対するanonymous-role
アクセスを付与する場合です。この場合、ユーザーはADFリソースによって定義されたページにすぐにアクセスすることはできません。
(ADFページ定義などで指定されている)mypage.jspx
など、ADFリソースによって定義されたWebページにユーザーがアクセスしようとすると、ADFセキュリティ施行ロジックがそのリクエストを遮断し、また、すべてのADFリソースがデフォルトでセキュリティ保護されているため、ユーザーは自動的に認証を要求されます(anonymous-role
がADFリソースへのアクセスを付与されていないと想定)。
認証が正常に終了すると、ユーザーは特定のサブジェクトを取得します。ここでセキュリティ施行ロジックがポリシー・ストアをチェックして、mypage.jspx
の表示を許可されるロールと、ユーザーがそのロールのメンバーかどうかを判別します。mypage.jspx
のこの例ではview権限がスタッフ・ロールに付与されています。ユーザーはそのロールのメンバーであるため、mypage.jspx
にナビゲートできます。
同様の方法で、ADFリソースにより定義されている別のページsecpage.jsp
にユーザーがアクセスしようとすると、ユーザーはこのページで必要なview権限を持たないため、アクセスが拒否されます。
ユーザーまたはロールは、リソース・プロバイダですでに定義されているものです。アプリケーション・ロールは、jazn-data.xml
のポリシー・ストアで定義されています。
統合WebLogic Serverを使用したJDeveloperでのテストの後は、アプリケーションをスタンドアロン・サーバーにデプロイすることができます。最初は、ターゲットのサーバーはステージング環境です。本番環境にデプロイする前に、このサーバーのアイデンティティ・ストアを使用して開発のテストを続行できます。つまり、通常は作成したテスト・ユーザーを統合WebLogic Serverで実行するために移行しません。セキュリティ・ポリシーとシステム資格証明を(cwallet.sso
ファイルから)スタンドアロンOracle WebLogic Serverに移行するために実行するステップは、ターゲット・サーバーで構成されているモードと、デプロイにJDeveloperまたはJDeveloper外部ツールのどちらを使用するかによって異なります。
ターゲット・サーバーが開発モードで構成されているときは、JDeveloperから直接デプロイできます。この場合、JDeveloperが、デプロイメント・プロセスの一環としてポリシー・ストア、システム資格証明およびアイデンティティ・ストア(ユーザーおよびグループ)の移行を自動的に処理します。アプリケーション・セキュリティ・デプロイメント・プロパティでは、デプロイメント・プロセスがドメインレベルのポリシー・ストアとシステム資格証明を上書きできるようにデフォルトで構成されています。さらに、アイデンティティ・ストア・デプロイメント・プロパティは、テスト・ユーザーを含むアイデンティティ・ストアを移行するようにデフォルトで構成されています。35.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、このデフォルトのデプロイメント動作を「アプリケーション・プロパティ」ダイアログで変更できます。
注意: 開発モードで実行するOracle WebLogic Serverへのシステム資格証明の移行が実行されるのは、ターゲット・サーバーが資格証明の上書きを許可するように構成されている場合だけです。システム資格証明の上書きをサポートするOracle WebLogic Serverの構成の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
ターゲット・サーバーが本番モードで構成されているとき、通常は、JDeveloper外部でOracle Enterprise Managerなどのツールを使用して移行タスクを処理します。JDeveloper外部のツールを使用して、ポリシー・ストアを本番環境のドメインレベルに移行する方法の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。本番モードで実行するOracle WebLogic Serverでは、どのような状況でもシステム資格証明の上書きはサポートされないことに注意してください。
ADFセキュリティの構成ウィザードで自動付与機能を有効にした場合は、アプリケーションをデプロイする前にtest-all
アプリケーション・ロールを削除することをお薦めします。test-all
ロールによってすべてのADFリソースが公開されるため、このロールが存在していると、アプリケーションのリソースが保護されない状態になるリスクが高まります。したがって、アプリケーションレベルのポリシー・ストアを移行する前にこのロールを削除する必要があります。
さらに、アプリケーションのOracle WebLogic Serverへのデプロイを準備するとき、jazn-data.xml
ファイルに作成したテスト・アイデンティティを削除することもお薦めします。こうしておくと、セキュリティ・ポリシーをテストするために作成したユーザーが、ドメインレベルのアイデンティティ・ストアに移行されません。
ベスト・プラクティス: アプリケーションをスタンドアロン環境にデプロイする場合は、すでにOracle WebLogic Serverに対して構成しているローカル・アイデンティティ・ストアのユーザーおよびエンタープライズ・ロールを移行してはいけません。たとえば、ユーザー |
jazn-data.xml
ファイルの概要エディタには、ADFセキュリティの組込みtest-all
ロールに対するview権限を持つすべてのリソースを表示する機能があります。概要エディタのこの機能を使用して、test-all
ロールの権限を削除し、アプリケーションで定義するロールの権限で置き換えることができます。
または、jazn-data.xml
ファイルの概要エディタを使用してtest-all
ロールを削除できます。エディタのアプリケーション・ロール・ページでtest-all
ロールを選択して、「アプリケーション・ロールの削除」ボタンをクリックします。ただし、この方法でtest-all
ロールを削除しても、削除するロールのかわりの権限を作成する必要があります。概要エディタではこれらのタスク両方を一緒に行うことができるため、次の手順で使用方法を説明します。
作業を始める前に、次のようにします。
Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、35.9項「セキュア・アプリケーションのデプロイの準備」を参照してください。
test-allアプリケーション・ロールを削除し、カスタム・アプリケーション・ロールで置き換える手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「タスク・フロー」を選択し、「test-allのみが付与されたタスク・フローを示します」チェックボックスを選択して、この組込みロールに対する権限を含むタスク・フローのリストを表示します。
test-all
ロールに対する権限が存在しない場合、概要エディタの「リソース」リストには何も表示されません。test-all
ロールが定義されるのは、ADFセキュリティの構成ウィザードで有効にした場合のみです。有効になっている場合、test-all
の権限を含むそれらのタスク・フローが図35-30のように表示されます。
「リソース」列でリストの最初のタスク・フローを選択します。
「付与先」列でtest-allを選択し、「権限受領者の削除」アイコンをクリックします。
「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。その後、「アプリケーション・ロールの選択」ダイアログを使用して必要なロールを追加します。
これらのステップを繰り返し、残りのすべてのタスク・フローでtest-all
ロールを削除して、独自のアプリケーション・ロールで置き換えます。
概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストから「Webページ」を選択し、ステップを繰り返して、すべてのWebページとそのADFページ定義についてtest-all
ロールを削除します。
「test-allのみが付与されたタスク・フローを示します」/「test-allのみが付与されたWebページを示します」チェックボックスが選択された状態で、概要エディタにtest-all
権限付きのリソースが表示されていないことを確認します。
デプロイ先のスタンドアロンOracle WebLogic Serverでは、構成済の独自のアイデンティティ・ストアが用意されます。JDeveloperで作成したテスト・ユーザーとエンタープライズ・ロール・グループをドメイン・レベルに移行しないようにするには、jazn-data.xml
ファイルからテスト・ユーザー・レルムを削除する必要があります。
または、JDeveloperからデプロイする場合は、ユーザーとグループの移行を無効にすることができます。これには、35.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明するように、「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」オプションを選択解除します。
作業を始める前に、次のようにします。
Oracle WebLogic Serverについて理解しておくと役立ちます。詳細は、35.9項「セキュア・アプリケーションのデプロイの準備」を参照してください。
アイデンティティ・ストアからテスト・ユーザーとエンタープライズ・ロール・グループを削除する手順:
メイン・メニューで「アプリケーション」メニューを選択し、「保護」→「ユーザー」を選択します。
jazn-data.xml
ファイルのエディタ・ウィンドウで「ソース」タブをクリックします。
jazn-data.xml
ファイルのソースで<jazn-realm>要素の左側の「-」アイコンをクリックすると、図35-31のように要素全体が折りたたまれます。
この要素が選択された状態で[Delete]を押し、ファイルを保存します。
リソース・ファイル(イメージ、スタイルシート、JavaScriptライブラリなど)とは、アプリケーションの個々のページをサポートするためにFusion Webアプリケーションがロードするファイルです。これらのファイルは、ADFセキュリティによって保護されません。アプリケーションのWebページをセキュリティ保護する場合、これらのファイルをセキュリティ保護することは必須ではありませんが、アプリケーションを十分にセキュリティ強化するために、リソース・ファイルを保護したほうが好ましい場合もあります。JavaScriptファイルはブラウザにダウンロードされるため、このときに読取り可能となることに注意してください。
リソース・ファイルを提供するため、ADF Facesフレームワークではorg.apache.myfaces.trinidad.webapp.ResourceServlet
を使用し、これによってリソース・ローダーに処理が委譲されます。Fusion Webアプリケーションのweb.xml
ファイルには、リソース・サーブレットとURLパターンを対応付けるサーブレット・マッピングが含まれます。JDeveloperは、デフォルトで/adf/*
(MyFaces Trinidad Coreの場合)および/afr/*
(ADF Facesの場合)パターンを使用します。
リソース・サーブレットはADFセキュリティによって保護されないため、リソース・サーブレット用のJava EEアクセス・パスを、セキュリティ制約を使用して保護できます。リソース・ファイルに対する独自のセキュリティをweb.xml
ファイル内に実装するには、/adflib/*
、/adf/*
および/afr/*
パスに対するセキュリティ制約を定義して、これらに特定のセキュリティ・ロールを割り当てます。このセキュリティ制約により、すべてのユーザーは、Fusion Webアプリケーションの最初のページにアクセスする前に認証を受けることになります。
例35-22は、セキュリティ・ロールresource_role
と、このロールにマッピングされたURLパターンによる制約を示します。セキュリティ・ロールを定義した後は、ターゲット・サーバーの管理者によってこのロールをOracle WebLogic Serverエンタープライズ・ロール(ユーザー・グループ)にマッピングしてもらうか、または同名のエンタープライズ・ロールを作成してもらう(この場合はマッピングは不要)必要があります。
例35-22 リソース・ファイルに対するweb.xmlファイル内のURL制約
<security-role> <description>Java EE role to map to an enterprise role. All users who will be allowed to run Fusion web app must be members of that role.
</description> <role-name>resource_role</role-name> </security-role> <security-constraint> <web-resource-collection> <web-resource-name>resources</web-resource-name> <url-pattern>/adflib/*</url-pattern> <url-pattern>/adf/*</url-pattern> <url-pattern>/afr/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>resource_role</role-name> </auth-constraint> </security-constraint>
アプリケーション・ポリシー・ストアに対する認可チェックを一時的に実行せずにアプリケーションを実行する必要がある場合、JDeveloperではADFセキュリティを無効にできます。こうすると、既存のセキュリティ・ポリシーで提供される保護なしで、アプリケーションを実行し、すべてのリソースにアクセスできます。
アプリケーションのレベルでADFセキュリティを無効にするには、ウィザードを実行して次のオプションの1つを選択します。
「ADF認証」を選択すると、ADF認可が無効になりますが、ADF認証サーブレットは有効なままです。このオプションでは、Java EEアプリケーション・ルート「/」を、ユーザー認証をトリガーするJava EEセキュリティ制約にマップすることで、ユーザーがアプリケーションのページに最初にアクセスしたときにログインを要求します。認可チェックが施行されないため、ADFリソースはセキュリティ対応になりません。したがって、一度ログインすると、ユーザーはADFリソースを含むすべてのWebページを利用できます。
「ADFセキュリティ構成の削除」を選択すると、ADF認証サーブレットが無効になり、ADFリソースの認可チェックも無効になります。この場合、ユーザー認証とADFリソースのセキュリティがない状態でアプリケーションを実行できます。
どちらのオプションもADFセキュリティを再有効化する目的でいつでも選択できます。このウィザードでは特に、アプリケーション開発者がADFリソースに対して定義したセキュリティ・ポリシーを含む、アプリケーションのポリシー・ストアは変更されません。このため、いつでもウィザードに戻り、「ADF認証および認可」オプションを選択し、アプリケーションの既存のポリシー・ストアやアイデンティティ・ストアに対してADFセキュリティを再有効化できます。
作業を始める前に、次のようにします。
ADFセキュリティの無効化について理解しておくと役立ちます。詳細は、35.10項「ADFセキュリティの無効化」を参照してください。
ADF認可チェックを無効にするには:
メイン・メニューで「アプリケーション」を選択し、「保護」→「ADFセキュリティの構成」を選択します。
ADFセキュリティ・ページで「ADF認証」オプションまたはADFセキュリティ構成の無効化オプションを選択します。「次へ」をクリックします。
これらのオプションのいずれかを設定してウィザードを実行すると、ユーザー・インタフェース・プロジェクトのADFリソースはセキュリティ対応でなくなります。
「終了」をクリックします。
ADFセキュリティの有効化プロセスを完了した後、ユーザー・インタフェースにおいてADFセキュリティと連動するようにアプリケーションをカスタマイズすることができます。たとえば、式言語(EL)を使用し、一連のUIコンポーネントのためだけに定義したカスタム権限の評価に基づいて、UIコンポーネントをWebページにレンダリングできます。さらに、マネージドBean内にメソッドを定義して、アプリケーションの情報(ユーザー名やロール・メンバーシップなど)を公開できます。
式言語(EL)を使用するとUIのポリシーを直接評価できますが、Javaを使用するとマネージドBean内でポリシーを評価できます。ADFセキュリティでは、セキュリティ・コンテキストでADFリソースにアクセスするように、EL式で使用できる便利なメソッドがいくつか実装されています。たとえば、EL式の便利なメソッドを使用して、ユーザーが特定のタスク・フローにアクセスできるかどうかを判定することができます。優れたセキュリティは、ユーザーがアクセス権を持たないリソースや機能をアプリケーションが非表示にすることを求めます。この理由から、ユーザーが特定のタスク・フローへのアクセスを許可されない場合、そのユーザーの権限を評価して、そのタスク・フローを開始するナビゲーション・コンポーネントをレンダリングするかどうかを判別します。
注意: ポリシーを評価できるのは、現在のリクエストのみです。この理由から、リクエスト・スコープ外でポリシーを評価すると、予期しない結果が発生することがあるため、ポリシー評価がどこで行われるかを理解することが重要です。 |
UIコンポーネント内でELを使用すると、コンポーネントの属性値を動的に定義できるようになるため、実行時にUIコンポーネントを変更できます。リソースを保護する場合、対象となるUIコンポーネント属性はrendered
属性です。これを使用して、ユーザーの権限に基づいてコンポーネントの表示と非表示を切り替えることができます。デフォルトでは、rendered
属性はtrue
に設定されています。権限に応じてこの値を動的に変更することで、UIコンポーネントの表示と非表示を設定できます。たとえば、ユーザーが適切な権限を持っている場合は、UIコンポーネントが表示されるようにrendered
属性をtrue
に設定する必要があります。権限を持たない場合は、属性をfalse
に設定して、UIコンポーネントを非表示にする必要があります。
ELを使用してポリシーを評価するには、securityContext
ELネームスペースでADFセキュリティのメソッドを使用する必要があります。これらのメソッドを使用して、特定のユーザーまたはADFリソースに関してADFセキュリティ・コンテキストの情報にアクセスできます。
表35-11に、ユーザーが関連する権限を持つかどうかを判別するために必要なEL式を示します。ユーザーが適切な権限を持っている場合、EL式はtrue
に評価されます。そうでない場合はfalse
を返します。
表35-11 ADFリソースに対するview権限を判定するEL式
式 | 式のアクション |
---|---|
#{securityContext.taskflowViewable['
たとえば、次のように入力します。 #{securityContext.taskflowViewable ['/WEB-INF/audit-expense-report.xml#audit-expense-report']} |
|
#{securityContext.regionViewable[' |
|
注意: ページ権限の場合、マネージドBean内部の遅延バインディングELを使用することにより、ページ定義の値を動的に指定できます。35.3.7項「valid-usersロールについて」を参照してください。 |
表35-12には、ADFセキュリティ・コンテキストから、ADFリソースに関連しない一般的な情報を取得するためのEL式を示します。たとえば、ユーザーの名前をユーザー・インタフェースに表示する場合は、現在のユーザー名にアクセスできます。また、現在のユーザーが特定のロールのメンバーかどうか、特定の権限を付与されているかどうかもチェックできます。アプリケーションはこの結果を使用してメニューの非表示と表示を動的に切り替えることができます。
表35-12 ADFセキュリティ・コンテキストでのユーザー情報を判定するEL式
式 | 式のアクション |
---|---|
#{securityContext.userName} |
認証されたユーザーのユーザー名を戻します。 |
#{data.adfContext.enterpriseName} |
認証されたユーザーのエンタープライズ名を戻します。エンタープライズ名はユーザーが自ら認識している別名で、ログインに使用できます。 |
#{data.adfContext.enterpriseId} |
認証されたユーザーのエンタープライズIDを戻します。 |
#{securityContext.authenticated} |
ユーザーがログインしている場合は |
#{securityContext.userInRole[' |
|
|
|
#{securityContext.userGrantedPermission['permission']}
|
表35-11に示された便利なメソッド |
#{securityContext.userGrantedResource['resource']}
|
この式を使用すると、タスク・フローに含まれないリソース(ADF Facesパネルなど)の たとえば、そのリソースに付与されている権限に基づいて、ページでのパネルの表示と非表示を切り替える場合、式は次のようになります。 #{securityContext.userGrantedResource ['resourceName=myPanel1; resourceType=myLayoutPanel; action=myAction']} ポリシー・ストアでは、リソースに対する権限の <permission> <class>oracle.security.jps. ResourcePermission</class> <name>resourceType=myLayoutPanel, resourceName=myPanel1</name> <actions>myAction</actions> </permission> |
作業を始める前に、次のようにします。
ELの用法について理解しておくと役立ちます。詳細は、35.11.1項「ADFセキュリティでの式言語(EL)の使用」を参照してください。
ナビゲーション・コンポーネントのレンダリングを、ターゲット・タスク・フローまたはページ定義に対してユーザーに付与された権限に関連付ける手順:
アプリケーション・ナビゲータで、ページをダブルクリックします。
セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
プロパティ・インスペクタで、「レンダリング済」フィールドの右側に表示されている「プロパティ・メニュー」ドロップダウン・メニューから、「式ビルダー」を選択します(図35-32)。
「式ビルダー」で「ADFバインディング」のsecurityContextノードを開いて適切なEL値を選択します。次に、「式」フィールドに、アクセスしようとしているADFリソースの修飾名を入力します。
たとえば、図35-33に示すようにアプリケーションで表示するタスク・フローへのアクセスを制限するには、次のような式を作成します。
#{securityContext.taskflowViewable ['/WEB-INF/audit-expense-report.xml#audit-expense-report']}
この例では、式によって、ターゲット・タスク・フローaudit-expense-report
を表示するためのユーザーのアクセス権が判別されます。ユーザーにアクセス権がある場合、式はtrue
として評価され、rendered
属性は値true
を受け取ります。
ヒント: 「式ビルダー」ダイアログの「説明」を開くと、選択したセキュリティELメソッドに関する追加情報を参照できます。 |
「OK」をクリックします。
アプリケーションを実行すると、ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。
「式ビルダー」を使用してrendered
属性の式を定義すると、開いている.jspx
ファイルのコンポーネント定義がJDeveloperによって更新されます。例35-24に示すように、コンポーネントのrendered
属性に、true
またはfalse
に評価される式が追加されます。この例ではコンポーネントはナビゲーション・リンクであり、リンク・テキストCheckout
は別の式で定義されます。このナビゲーション・リンクを含むページによってこのコンポーネントがレンダリングされるのは、チェックアウト・タスク・フローにアクセスするための十分なアクセス権がユーザーにある場合のみです。
セキュリティ権限を評価できるスコープは、リクエストに設定されています。リクエストよりも上位レベルまでスコープ設定されたマネージドBean (マネージドBeanが基礎となっているグローバル・メニューなど)からターゲット・ページにアクセスするための権限を評価する場合は、遅延EL評価(遅延バインディング)を実装する必要があります。Beanの管理プロパティとしてターゲット・ページを渡すことで、マネージドBeanが必要なバインディング情報を取得できるようになった後でEL式が評価されるようになります。ELは、ページが実行されるとすぐに評価されるため、マネージドBeanを基礎としたUIコンポーネントのプロパティ内に直接EL式を配置すると、有効範囲外エラーが発生します。
例35-25に、ユーザーが特定のターゲット・ページを表示できるかどうかに基づいてtrue
またはfalse
を返すマネージドBeanのプロパティ(authorized
)を示します。この場合、_targetPageDef
変数は、ターゲット・ページの名前が含まれる管理プロパティです。UI内で、EL式はauthorized
プロパティを参照します。
例35-25 マネージドBean内の遅延EL評価
public boolean isAuthorized() { if (_targetPageDef != null) { FacesContext fctx = FacesContext.getCurrentInstance(); ADFContext adfCtx = ADFContext.getCurrent(); SecurityContext secCtx = adfCtx.getSecurityContext(); boolean hasPermission = secCtx.hasPermission(new RegionPermission (_targetPageDef, RegionPermission.VIEW_ACTION)); if (hasPermission) { return hasPermission; } else { fctx.addMessage(null, new FacesMessage ( FacesMessage.SEVERITY_WARN, "Access Permission not defined! " , null)); return false; } }
ADFセキュリティELネームスペースの値userGrantedPermission
(表35-11)を使用して、ページにUI要素をレンダリングするかどうかを判別できます。作成する式で、認証されたユーザーのカスタム権限を評価できます。カスタム権限は、JAAS権限の作成ダイアログを使用して作成するJAAS権限クラスです。このダイアログで作成できるクラスは、oracle.adf.share.security.authorization.ADFPermission
クラスを拡張して、権限がADFセキュリティによって使用できるようにします。
Fusion Webアプリケーションのカスタム権限により、セキュリティ・ポリシーを定義する際の柔軟性が向上します。たとえば、カスタム権限には、保護対象のUI要素に対応する名前を付けることができます。いったん権限を作成したら、jazn-data.xml
ファイルの概要エディタを使用し、jazn-data.xml
ポリシー・ストアによって定義されたアプリケーション・ロールに権限を付与することでADFリソースのセキュリティ・ポリシーを作成します。
ベスト・プラクティス: カスタムADF権限クラスを使用すると、ADFセキュリティを拡張して、権限で使用できるカスタム・アクションを定義できます。このため、セキュリティ・ポリシーを柔軟に定義できるようになり、ADFリソースの権限クラスによって定義された組込みアクションをオーバーロードしなくても、ユーザーによるUIコンポーネントの表示を管理できます。Webページへのアクセスを管理するためにカスタム権限を作成する必要がないことに注意してください。このレベルのアクセスは、 |
カスタムJAAS権限を使用してポリシーを評価するには:
カスタムJAAS権限クラスを作成します。
カスタム権限を使用してADFセキュリティ・ポリシーを作成します。
UIコンポーネントのレンダリングを、ユーザーに付与されるカスタム権限に関連付けます。
カスタムJAAS権限クラスを作成するには、JAAS権限クラスの作成ダイアログを使用します。このカスタムJAAS権限クラスは、指定したパッケージにJDeveloperによって追加されます。たとえば、例35-26に示すように、Fusion Order Demoアプリケーションのoracle.fodemo.storefront.store.view
パッケージは、カスタム権限クラスAccountPermission.java
を定義します。
例35-26 カスタムJAAS権限クラス
package oracle.fodemo.storefront.store.view; import oracle.adf.share.security.authorization.ADFPermission; import oracle.adf.share.security.authorization.PermissionActionDescriptor; import oracle.adf.share.security.authorization.PermissionTargetDescriptor; public class AccountPermission extends ADFPermission { private static final PermissionActionDescriptor[] actions = {new PermissionActionDescriptor("view", "view")}; private static final PermissionTargetDescriptor[] targets = {new PermissionTargetDescriptor("attributeValue", "Attribute")}; public AccountPermission(String name, String actions) { super(name, actions); } public static PermissionActionDescriptor[] getPermissionActionDescriptors() { return actions; } public static PermissionTargetDescriptor[] getPermissionTargetDescriptors() { return targets; } }
作業を始める前に、次のようにします。
ADF権限クラスについて理解しておくと役立ちます。詳細は、35.11.2項「カスタムJAAS権限とELを使用したポリシーの評価方法」を参照してください。
カスタムJAAS権限クラスを作成する手順:
アプリケーション・ナビゲータで、カスタムJAAS権限クラスを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で「すべてのアイテム」と「JAAS権限」を順に選択し、「OK」をクリックします。
JAAS権限の作成ダイアログで、権限の名前と完全修飾パッケージ名を入力します。
権限名としては一般的な名前を選択できます。
「アクション」リストに、アクション権限のための名前を入力します。
アクション名は、権限の目的を特定できるように具体的な名前を付けることができます。同一コンポーネントに様々な目的で権限を適用する場合は、リストに複数のアクションを追加できます。たとえば、マネージャと従業員の両方がページ・メニューを見られるように許可しますが、マネージャは特定のメニュー項目の選択も行えるようにします。
「ターゲット」リストでは「属性」の選択をそのままにしておきます。
カスタムJAAS権限のアクションを使用してポリシー・ストアにポリシーを作成してから、実際のターゲット名を指定します。
「OK」をクリックします。
カスタム権限に基づくADFセキュリティ・ポリシーを作成するには、jazn-data.xml
ファイルの概要エディタを使用します。完成したソースは、例35-27に示すように、Fusion Order Demoアプリケーションのポリシー・ストアで定義されるカスタム権限と類似した内容となります。
例35-27 カスタム権限の定義
<grant> <grantee> <principals> <principal> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>fod-admin</name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.fodemo.storefront.store.view.AccountPermission</class> <name>AccountPermission</name> <actions>view</actions> </permission> </permissions> </grant>
<permission>
ターゲット名は、権限を特定できるような任意の名前を付けることができます。たとえば、ユーザーが各自の口座番号を表示するための権限であれば、AccountPermission
のような名前を付けます。
入力可能なアクションは、カスタムJAAS権限クラスによって定義されています。たとえば、Fusion Order Demoアプリケーションでは、oracle.fodemo.storefront.store.view.AccountPermission
クラスによって単一のアクションview
が定義されています。
作業を始める前に、次のようにします。
ADF権限クラスについて理解しておくと役立ちます。詳細は、35.11.2項「カスタムJAAS権限とELを使用したポリシーの評価方法」を参照してください。
次のタスクを完了する必要があります。
カスタム権限を使用してADFセキュリティ・ポリシーを作成する手順:
メイン・メニューで「アプリケーション」を選択し、「保護」→「リソース権限」を選択します。
jazn-data.xml
ファイルの概要エディタのリソース権限ページで、「リソース・タイプ」ドロップダウン・リストからカスタム・リソースを選択します。
概要エディタにすべてのカスタム・リソースが表示されます。最初はカスタム・リソースに関連付けられているリソース・タイプはありませんが、図35-34のようにエディタによってハイライト表示されます。
「リソース・タイプ」フィールドの横の「新規リソース・タイプ」アイコンをクリックします。
「リソース・タイプの作成」ダイアログで名前とアクションを入力し、「OK」をクリックします。
概要エディタのリソース権限ページにおいて、「付与先」列で「権限受領者の追加」アイコンをクリックして「アプリケーション・ロールの追加」を選択します。
「アプリケーション・ロールの選択」ダイアログで、アプリケーション・ロールを選択して「OK」をクリックします。
概要エディタのリソース権限ページの「アクション」列で必要なアクションを選択します。
図35-35のように、概要エディタにカスタム権限が表示されます。
UIコンポーネントの表示プロパティに対して開いた「式ビルダー」ダイアログを使用して、EL式を定義します。たとえば、Fusion Order Demoアプリケーションでは、myOrders.jpx
ページによって、af:outputText#ot18
テキスト・フィールドのvalue
属性に対して式userGrantedPermission
が定義されています(例35-28)。この場合、ユーザーに権限があるかどうかが式によってテストされ、口座番号(bindings.AccountNumber.inputValue
)が表示されます。または、ユーザーに権限がない場合は口座番号のかわりにXXXXXXXXXXXX
が表示されます。この式はテキスト・フィールドのrendered
属性に対して定義されているのではないため、ページには常にこのフィールドが表示されます。
アプリケーションを実行すると、ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。
例35-28 Value属性に対するカスタム権限式
#{securityContext.userGrantedPermission ['permissionClass=oracle.fodemo.storefront.store.view.AccountPermission; target=AccountPermission;action=view'] ? bindings.AccountNumber.inputValue : 'XXXXXXXXXXXX'}
図35-36は、「式ビルダー」ダイアログに式がどのように表示されるかを示します。
作業を始める前に、次のようにします。
ADF権限クラスについて理解しておくと役立ちます。詳細は、35.11.2項「カスタムJAAS権限とELを使用したポリシーの評価方法」を参照してください。
次のタスクを完了する必要があります。
35.11.2.1項「カスタムJAAS権限クラスの作成」の説明に従って、カスタムJAAS権限クラスを作成します。
35.11.2.2項「カスタム権限を使用したADFセキュリティ・ポリシーの作成」の説明に従って、カスタム権限を使用してADFセキュリティ・ポリシーを作成します。
UIコンポーネントのレンダリングとユーザーに付与されるカスタム権限を関連付ける手順:
アプリケーション・ナビゲータで、ページをダブルクリックします。
セキュリティ保護されたページに移動するために使用するコンポーネントを選択します。
プロパティ・インスペクタで、「レンダリング済」フィールドの右側に表示されている「プロパティ・メニュー」ドロップダウン・メニューから「式ビルダー」を選択します。
「式ビルダー」で、「ADFバインディング」のsecurityContextノードを開いてuserGrantedPermissionを選択します。次に、「式」フィールドに、権限を定義する連結文字列を入力します。
権限文字列は、permissionClass=
qualifiedClassName
;target=
artifactName
;action=
actionName
のようにセミコロンで連結した文字列として入力します。たとえば、テキスト・フィールドによってページに表示される口座番号を保護するには、例35-29に示すような式を入力します。このとき、userGrantedPermission
の権限はカスタムJAAS権限と同じ名前です。
例35-29 カスタムJAAS権限式
#{securityContext.userGrantedPermission ['permissionClass=oracle.fodemo.storefront.store.view.AccountPermission; target=AccountPermission;action=view']}
例35-29では、アプリケーション・ポリシー・ストアに追加したAccountPermission
という名前のカスタムJAAS権限定義に基づいて、権限が式によって評価されます。
「OK」をクリックします。
Fusion Webアプリケーション内にセキュリティを実装することは、定義上、ADFセキュリティ・フレームワークのセキュリティ・インフラストラクチャを実装することです。このため、フレームワークのセキュリティ・コンテキストを使用して、アプリケーションのポリシーやセキュリティ全体を定義するときに必要となる情報にアクセスできます。
ADFセキュリティの施行は、アプリケーションと無関係にコンテナ・レベルでオン/オフを切り替えることができるため、認可チェックを行う前に、ADFセキュリティが有効化されているかどうかを判断する必要があります。このためには、例35-30に示すように、ADFセキュリティ・コンテキストのisAuthorizationEnabled()
メソッドをコールします。
Fusion Webアプリケーション内のユーザー・プリンシパルがnull
になることはない(つまり、認証されていないユーザーの場合はanonymous
で、認証されたユーザーの場合は実際のユーザー名になる)ため、ユーザー・プリンシパルがnull
かどうかを確認するだけで、そのユーザーがログオンしているかどうかを判断することはできません。このため、anonymous
ユーザー・プリンシパルがユーザーが認証されていないことを表すことを考慮に入れるメソッドを使用する必要があります。このためには、例35-31に示すように、ADFセキュリティ・コンテキストのisAuthenticated()
メソッドをコールします。
Fusion Webアプリケーションでは、セキュアでありながらすべてのユーザーに使用可能なパブリック・ページの概念をサポートしています。さらに、Webページ上のコンポーネント(ポートレットなど)では、現在のユーザー・アイデンティティの情報を必要とします。このため、Fusion Webアプリケーションのユーザー名は決してnull
になることはありません。認証されていないユーザーがページにアクセスすると、ユーザー名anonymous
がページ・コンポーネントに渡されます。Fusion Webアプリケーションがユーザーのエンタープライズ名を登録しているときは、エンタープライズ名も取得できます。エンタープライズ名はユーザーが自ら認識している別名で、ログインに使用できます。
現在のユーザー名を判別するには、例35-32に示すように、ADFセキュリティ・コンテキストのgetUserName()
メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymous
を返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。
例35-32 ADFセキュリティ・コンテキストのgetUserName()メソッドの使用
// ============ Current User's Name/PrincipalName ============= public String getCurrentUser() { _currentUser = ADFContext.getCurrent().getSecurityContext().getUserName(); return _currentUser; }
Facesベースのアプリケーションでユーザー名を判別するための従来のメソッド(FacesContext.getCurrentInstance().getExternalContext().getRemoteUser()
)では、認証されていないユーザーに対してnull
が戻されるため、そのメソッドを使用する場合は、パブリック・ユーザーのケースを処理する追加のロジックを使用する必要があります。
現在のユーザーのエンタープライズ名を判別するには、例35-33に示すように、ADFコンテキストのgetEnterpriseName()
メソッドを評価します。
例35-33 ADFコンテキストのgetEnterpriseName()メソッドの使用
// ============ Current User's Enterprise Name ============= public String getEnterpriseName() { _enterpriseName = ADFContext.getCurrent().getEnterpriseName(); return _enterpriseName; }
現在のユーザーのエンタープライズIDを判別するには、例35-34に示すように、ADFコンテキストのgetEnterpriseId()
メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymous
を返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。
Fusion WebアプリケーションはJavaServer Facesベースのアプリケーションなので、例35-35に示すように、Faces外部コンテキストのisUserInRole(roleName)
メソッドを使用すると、ユーザーに特定のロールが割り当てられているかどうかを判別できます。ADFセキュリティはJAASポリシーに基づくため、ロール・メンバーシップに基づくADFセキュリティ対応リソースに関連付けられたページを保護するためにJava EEセキュリティ・ロールを使用する必要はありません。ただし、ADFセキュリティ対応リソースに関連付けられていないページについては、メソッドを使用してロールをチェックできます。
この例では、便利なメソッド(checkIsUserInRole
)が定義されています。マネージドBean内でこのメソッドを使用すると、名前付きロールのメンバーシップを属性として公開し、その後EL内で使用できます。
Java内からセキュリティ・ポリシーを評価するには、ADFセキュリティ・コンテキストのhasPermission
メソッドを使用できます。このメソッドは、(リソースとアクションの組合せにより定義された)権限オブジェクトを取り、ユーザーに対応する権限があればtrue
を返します。
例35-36では、ページ名と必要なアクションを渡し、ユーザーの権限に基づいてtrue
またはfalse
を返すことのできる、便利な関数が定義されています。この便利な関数がページ権限を確認するため、RegionPermission
クラスを使用して、hasPermission
メソッドに渡される権限オブジェクトを定義しています。
例35-36 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ナビゲーション・アクションの結果を動的に変更できます。例35-37では、1つのコマンド・ボタンがユーザーの権限に応じて異なるターゲット・ページを指していることがわかります。コマンド・ボタンのバッキングBeanは、最も高いレベルで保護されているページ(管理者ページ)から最も低いレベルで保護されているページ(パブリックのようこそページ)までview権限を確認することにより、適切なアクションを適用して、ユーザーに対して権限レベルに応じたページを表示します。適切なアクションを戻すバッキングBeanは、例35-36に定義されている便利なメソッドを使用しています。
例35-37 認可チェックに基づくページ・ナビゲーション結果の変更
//CommandButton Definition <af:commandButton text="Goto Your Group Home page" binding="#{backing_content.commandButton1}" id="commandButton1" action="#{backing_content.getSecureNavigationAction}"/> //Backing Bean Code public String getSecureNavigationAction() { String ActionName; if (TestPermission("ManagerPage", "view")) ActionName = "goToManagerPage"; else if (TestPermission("EmployeePage", "view")) ActionName = "goToEmployeePage"; else ActionName = "goToWelcomePage"; return (ActionName); }
次に示すベスト・プラクティスは、ADFセキュリティ・フレームワークによるセキュリティ施行のための規則をまとめたものです。これらのベスト・プラクティスを理解することで、アプリケーションを保護して、意図したWebページにユーザーのアクセスを許可することができます。
アプリケーションを構築するときは最初からADFセキュリティを有効にしてください。
セキュリティを有効化すると、アプリケーションが実質的にロックダウンされます。また、作成する固有のADFセキュリティ対応リソースに対して明示的な権限付与を行う必要が生じます。アプリケーションを構築する際に、これらのリソースについて認識して、権限付与を行うことにより、反復しながらセキュリティをテストできます。こうして、必要な結果を実現するようにアプリケーションを構成できます。
バインド・タスク・フローの権限を定義してください。
バインド・タスク・フローを実行するプロセスでユーザーがアクセスするページは、ページごとの個別の権限チェックは行われず、タスク・フローの権限において実行されます。つまり、タスク・フローに追加するページには、ページ定義レベルでの独自のセキュリティは定義されていません。ユーザーがフローをリクエストする場合、アクセス・レベルに応じて、タスク・フローのすべてのページの表示を許可されるか、まったく許可されないかのどちらかになります。
バインド・タスク・フローの個々のページには権限を定義しないでください。
タスク・フローはユーザーによるページへの直接アクセスを妨げないことを理解することが重要です。公開されているディレクトリにあるすべてのWebページは、URLを使用してブラウザからアクセスできます。バインド・タスク・フローによって参照されるページに直接アクセスできないようにするため、関連するページ定義ファイルについて存在するすべての権限を削除します。バインド・タスク・フローのコンテキスト内でページに追加のセキュリティが必要な場合は、それらのページをサブタスク・フローに含めて、このネストされたタスク・フローに対する権限の定義を追加します。
エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすため、タスク・フローを使用してください。
タスク・フローを使用すると、エンド・ユーザーに対して公開されるアクセス・ポイント数を減らすことができます。たとえば、アプリケーション内の残りの各ページに移動するための単一ページを表示する、1つのバインドなしタスク・フローを構成します。アプリケーション内の残りのページに対しては、バインド・タスク・フローを使用します。これらのバインド・タスク・フローのURL起動プロパティをurl-invoke-disallowed
に設定することで、アプリケーションのアクセス・ポイントは1つのみ(バインドなしタスク・フローのページ)となります。URL起動プロパティの詳細は、19.6.4項「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セキュリティ権限を適用します。