JDeveloperでのOpssADFDemoAppの確認

このOBEを始める前に、『OPSS環境のセットアップ』のOBEを完了する必要があります。

このOBEを始める前に、『WebLogicでのOID認証プロバイダの構成』のOBEを完了する必要があります。

起動パネルの「」アイコンを使用して、JDeveloper IDEを開きます。

JDeveloperの起動時に、JDeveloperスプラッシュ・スクリーンが表示されます。 注： 使用するJDeveloperのバージョンが若干違っても、問題ありません。 仮想イメージのJDeveloperのバージョンは、11.1.1.2です。

Select Roleウィンドウが表示されたら、Default Roleは選択されたままにして、「OK」をクリックします。 これで、すべてのJDeveloperテクノロジーを利用できるようになります。

Tip of the Dayウィンドウが表示されたら、このウィンドウを閉じます。 このメッセージが再度表示されないようにするには、「Show tips at startup」チェック・ボックスをオフにします。

アプリケーション・ナビゲータにNew Application...オプションとOpen Application...オプションが表示されたら、「Open Application...」を選択します。

/home/oracle/labs/apps/OpssADFDemoAppフォルダを参照し、「OpssADFDemoApp.jws」プロジェクト・ファイルを選択して、「Open」をクリックします。

Projectsビューのすべてのツリー・ノードを展開して、プロジェクト内のすべてのファイルが表示されるようにします。

Application Resourcesビューのすべてのツリー・ノードを展開して、プロジェクト内のすべてのデプロイメント・ディスクリプタ・ファイルが表示されるようにします。

OpssADFDemoAppアプリケーションが開いて、JDeveloper IDEで表示できるようになりました。このアプリケーションがOPSSでどのように動作するのか確認できます。

Application Resourcesビューで「jps-config.xml」ファイルをダブルクリックして、エディタでファイルを開きます。

注： jps-config.xmlファイルはOpssADFDemoAppのMETA-INFフォルダ内にパッケージ化されているため、IDEでの開発時にこのアプリケーションのすべてのOPSS構成はJava SEに基づいたものになります。 アプリケーションがOPSS対応のサーバーにデプロイされると、適用されるOPSS構成はWebLogicドメインのjps-config.xmlファイルになります。

ファイルを選択していない場合は、「Overview」タブをクリックして、ファイルをグラフィカルに表示します。 このチュートリアルでは、このファイル表示を使用しています。 必要に応じて、「Source」タブを使用してファイルを確認することもできます。このタブでは、ファイルのXMLソース全体が表示されます。

次のような画面が表示されます。

この画面には、jps-config.xmlファイルの構成設定が表示されます。 次の構成設定が含まれています。 Security Contexts、Identity Store、Credential Store、Login Modules、Key Storeサービス。 上記に示すように、デフォルトのページではSecurity Contextsが選択されています。 OpssADFDemoAppとanonymousの2つのコンテキストがあります。 デフォルトのコンテキストはOpssADFDemoAppです。anonymousコンテキストは、システムでまだ認証されていないユーザー向けのログインを示すために構成します。

注： Anonymous Providerはなくなる予定です。UIでは無視してください。 Anonymous Providerの機能は、OPSSフレームワークの他の部分に実装されています。

まず、Security Contextsセクションについて確認します。

セキュリティ・コンテキストの構成

Security Contextsタブには、環境に構成されているJPSコンテキストが表示されます。 OpssADFDemoAppコンテキストに重点を置いて説明します。 OpssADFDemoAppコンテキストの横にあるプラス記号をクリックし、ビューを展開します。コンテキストの構成が表示されます。

ここには、環境に構成されているさまざまなコンテキストが表示されます。 次のようなコンテキストが表示されます。

• Identity Store
• Credential Store
• Key Store
• Login Modules

この環境のIDストアは、idstore.xmlという名前で参照されます。 この名前は任意の名前にできますが、この場合は、IDストアがファイルベースのXMLストアに含まれていることを示す、一般的なネーミング規則に従っています。

資格証明ストアは、credstoreという名前で参照されます。 この名前は、使用されているストアのタイプを示すものではありませんが、これはADF開発環境であるため、これもファイルベースであると想定できます。この構成では、cwallet.ssoファイルが参照されます。 すぐ後で、この構成について詳しく見てみます。

この環境にキー・ストアは構成されていないため、このパラメータには<no selection>と表示されています。

Login Modulesセクションのチェック・ボックスは、このJPSコンテキストに選択されているログイン・モジュールがidstore.loginmoduleであることを示しています。

IDストア構成について詳しく見てみます。

IDストアの構成

「Identity Store」タブをクリックし、idstore.xmlサービス・インスタンスの構成を表示します。

この場合、グラフィカルな表示には、IDストアの完全な構成は表示されません。 この環境のセキュリティ・レルムがjazn.comであることが表示されます。 完全な構成を表示するには、「Source」タブをクリックし、ファイル内で次のコード・スニペットのようなserviceInstanceを見つけます。

ヒント： Structureビューを使用すると、ファイル内の要素を簡単に見つけることができます。 「jpsConfig」ノードと「serviceInstances」ノードを展開し、最後のserviceInstanceの横の要素を選択します。この要素が、idstore.xmlインスタンスの正しい要素です。

<serviceInstance provider="idstore.xml.provider" name="idstore.xml">
  <property value="./jazn-data.xml" name="location"/>
  <property value="OBFUSCATE" name="jps.xml.idstore.pwd.encoding"/>
  <property value="jazn.com" name="subscriber.name"/>
</serviceInstance>

ここには、IDストア構成について詳しく示されています。

この時点では、jazn-data.xmlファイルの確認については気にしないでください。 これについては、次の項で説明します。

Overviewタブに戻って、次のステップに進みます。

資格証明ストアの構成

「Credential Store」タブをクリックし、credstoreサービス・インスタンスの構成を表示します。

現在のところ、資格証明ストアが構成されていないため、場所のみ指定されています。 アプリケーションに関連付けられているか、アプリケーション内にパッケージ化されているcwallet.ssoファイルがないため、資格証明ストアがありません。 また、IDストアとポリシー・ストアがファイルベースのXMLファイルであるため、ブートトラップ資格証明ストアは不要です。

次に、ログイン・モジュールの構成について詳しく見てみます。

ログイン・モジュールの構成

「Login Modules 」タブをクリックし、ログイン・モジュールの構成を表示します。 idstore.loginmoduleエントリの横にあるプラス記号を展開し、idstore.loginmoduleサービス・インスタンスの構成を表示します。

スクリーンショットのパラメータの定義は次のとおりです。

次に、ADFセキュリティの構成方法について見てみます。

OPSSセキュリティを使用するためのADFの構成

JDeveloper IDEを使用して、ADFアプリケーションで使用するセキュリティのタイプを構成できます。 Application Navigatorタブでアプリケーションを右クリックし、「Secure」→「Configure ADF Security」を選択します。

注： 実際にはここで設定を変更しませんが、この構成を行う方法を示しています。

Configure ADF Securityウィザードが表示されます。 最初の画面で、アプリケーションのセキュリティ・モデルを選択できます。 次の3つから選択できます。

• ADF Authentication and Authorization
• ADF Authentication
• Remove ADF Security Configuration

これらの各選択肢の詳しい説明を参照するには、ウィザードの最初のページに表示されている「ADF authentication and authorization」リンクをクリックします。 関連するJDeveloperインライン・ヘルプ・システムが開きます。 準備できたら、「Next」をクリックします。

ウィザードの次のステップで、アプリケーションのWebベースの側面で使用する認証のタイプを選択できます。 各選択肢の詳しい説明を参照するには、このウィザード・ページに表示されている「authentication type」リンクをクリックします。 これらの設定の関連するJDeveloperインライン・ヘルプ・システムが開きます。 準備できたら、「Next」をクリックします。

ウィザードの次のステップで、ポリシーによる権限許可をアプリケーションでどのように管理するのかを選択できます。 各選択肢の詳しい説明を参照するには、このウィザード・ページに表示される「ADF policy grants」リンクをクリックします。 これらの設定の関連するJDeveloperインライン・ヘルプ・システムが開きます。 準備できたら、「Next」をクリックします。

ウィザードの次のステップで、このアプリケーションで正しく認証されたユーザーに表示されるWelcomeページを選択できます。 何も構成せずに、すべてをデフォルト値のままにします。準備ができたら「Next」をクリックします。

ウィザードに、この時点までに行った構成の選択の概要が表示されます。 この画面に、ADF、Java EE、WebLogic拡張、およびOPSS構成ファイルの場所、およびアプリケーション内でこれらがパッケージ化されている場所が表示されます。 ADFセキュリティはすでに必要な内容に構成されているため、「Cancel」をクリックしてこれらの設定を無視します。

JDeveloperでADFアプリケーションにjps-config.xmlファイルを構成する方法について説明しました。 次に、OPSSファイルベースのストアjazn-data.xmlを見てみます。

Application Resourcesビューで「jazn-data.xml」ファイルをダブルクリックし、エディタでファイルを開きます。

注： jazn-data.xmlファイルはOpssADFDemoAppのMETA-INFフォルダ内にパッケージ化されているため、OPSSセキュリティ・ストアはファイルベースになっています。 この手順を実行すると分かるように、このファイルも、アプリケーションのファイルベースのIDストアとして機能します。 そのため、ADF開発者は、LDAPベースのIDストアを実行、構成、または接続しなくても、ユーザー、グループ、ロールをすばやく容易に作成して、アプリケーションをテストできます。 また、LDAPまたはデータベース・セキュリティ・ストアを実行、構成、または接続しなくても、アプリケーションのセキュリティ・ポリシーをすばやく容易に作成できます。 すべてがアプリケーション内で自己完結しています。

アプリケーションがOPSS対応のサーバーにデプロイされると、OPSSセキュリティ・ストアのデータが、WebLogicドメインに構成されているOPSSセキュリティ・ストアにマージされます。 ユーザーとグループのデータは、一般に、環境によって異なるため、通常、IDストアのデータはマージされません。

ファイルを選択していない場合は、「Overview」タブをクリックして、ファイルをグラフィカルに表示します。 このチュートリアルでは、このファイル表示を使用しています。 必要に応じて、「Source」タブを使用してファイルを確認することもできます。このタブでは、ファイルのXMLソース全体が表示されます。

次のような画面が表示されます。

この画面には、jazn-data.xmlファイルの構成設定が表示されます。 次の構成設定が含まれています。 Users、Enterprise Roles（またはGroups）、Application Roles、Resource Grants、Entitlement Grants。 デフォルト・ページではUsersが選択されており、ここに示されているように表示されます。 開発の目的で、Jane Doe とJohn Smithの2つのユーザーがファイル内に構成されています。

まず、Usersタブを確認します。

ユーザーの構成

Usersタブには、ADF開発環境に構成され、jazn.comセキュリティ・レルムの一部として定義されているユーザーが表示されます。 このページで、次のことを制御します。

1. 特定のユーザーを検索する
2. IDストア内のユーザーを管理する
3. IDストア内のユーザーの詳細情報を管理する
4. エンタープライズ・ロール（グループ）およびアプリケーション・ロールへのユーザーのマッピングを管理する

少し時間をとってこのページを確認し、このページの内容を把握します。 準備ができたら、次のステップに進みます。

次に、エンタープライズ・ロールの構成について見てみます。

エンタープライズ・ロールの構成

「Enterprise Roles」タブをクリックし、IDストアに構成されているエンタープライズ・ロールの構成を表示します。 このページで、次のことを制御します。

1. 特定のエンタープライズ・ロールを名前で検索する
2. IDストア内のエンタープライズ・ロールを管理する
3. IDストア内のエンタープライズ・ロールの詳細情報を管理する
4. エンタープライズ・ロール（グループ）およびアプリケーション・ロールへのユーザーのマッピングを管理する

少し時間をとってこのページを確認し、このページの内容を把握します。また、以下の質問に回答してください。

• employeesエンタープライズ・ロールにマッピングされているユーザーおよびグループはどれですか。
• employeesエンタープライズ・ロールに割り当てられているアプリケーション・ロールはありますか。 ある場合、どのアプリケーション・ロールが割り当てられていますか。
• supervisorsエンタープライズ・ロールにマッピングされているユーザーおよびグループはどれですか。
• supervisorsエンタープライズ・ロールに割り当てられているアプリケーション・ロールはありますか。 ある場合、どのアプリケーション・ロールが割り当てられていますか。

次に、アプリケーション・ロールの構成について見てみます。

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

「Application Roles」タブをクリックし、OPSSセキュリティ・ストアに構成されているアプリケーション・ロールの構成を表示します。 このページで、次のことを制御します。

1. 特定のアプリケーション・ロールを名前で検索する
2. OPSSセキュリティ・ストア内のアプリケーション・ロールを管理する
3. アプリケーションで構成されるアプリケーション・ロールの範囲を指定する
4. OPSSセキュリティ・ストア内のアプリケーション・ロールの詳細情報を管理する
5. アプリケーション・ロールへのユーザーのマッピングを管理する、およびアプリケーション・ロールに割り当てられている権限付与を表示する

次のスクリーンショットでは、Managerロールがすでに展開され、Developerロールが子ロールであることを示しています。 これは、アプリケーション・ロール階層の一例です。 Managerロールに作成されたポリシーは、Developerロールにも自動的に適用されます。

少し時間をとってこのページを確認し、このページの内容を把握します。また、以下の質問に回答してください。

• anonymous-roleにマッピングされているユーザーまたはロールはありますか。 ある場合、なぜですか。また、ない場合、なぜですか。
• authenticated-roleにマッピングされているユーザーまたはロールはありますか。 ある場合、なぜですか。また、ない場合、なぜですか。
• authenticated-roleに付与されている権限は何ですか。
• Managerアプリケーション・ロールにマッピングされているユーザーまたはロールはありますか。 ある場合、どのユーザーまたはロールがマッピングされていますか。
• Developerアプリケーション・ロールにマッピングされているユーザーまたはロールはありますか。 ある場合、どのユーザーまたはロールがマッピングされていますか。
• ManagerロールまたはDeveloperロールに権限が付与されていますか。

回答

• anonymous-roleにマッピングされているユーザーまたはロールはありません。 このロールは、ユーザーに手動では割り当てるものではありません。 代わりに、このロールは、アプリケーションのログインが不要な側面にユーザーがアクセスしており、またログインしていない場合に、ユーザーのSubjectに追加されます。
• authenticated-roleにマッピングされているユーザーまたはロールはありません。 このロールは、ユーザーに手動では割り当てるものではありません。 代わりに、このロールは、ユーザーがシステムに正しくログインした後で、ユーザーのSubjectに追加されます。
• はい。authenticated-roleに、taskFlowCall1というADFタスク・フローの表示権限が付与されます。 これを確認するには、「authenticated-role」エントリをクリックし、ページの右側にある「Grants」タブをクリックします。
• はい。supervisorsエンタープライズ・ロールがManagerアプリケーション・ロールにマッピングされています。 また、employeesエンタープライズ・ロールもManagerアプリケーション・ロールにマッピングされています。これは、employeesエンタープライズ・ロールがsupervisorsエンタープライズ・ロールにマッピングされているためです。 このタブでこれを直接確認することはできませんが、Enterprise Rolesタブのsupervisorsエンタープライズ・ロールに戻ると、employeesがsupervisorsエンタープライズ・ロールにマッピングされていることを確認できます。
• はい。employeesエンタープライズ・ロールがDeveloperアプリケーション・ロールにマッピングされています。
• これは難しい質問です。 答えは、"はい"であり、"いいえ"でもあります。どちらのロールにも、権限付与は直接には構成されていません。 ただし、ユーザーのロールがManagerロールまたはDeveloperロールである場合、このユーザーはシステムに正しくログインしているはずです。 つまり、いずれかのアプリケーション・ロールのメンバーであるユーザーは、authenticated-roleアプリケーション・ロールのメンバーでもあるため、taskFlowCall1の表示権限が暗黙的に付与されます。 authenticated-roleに付与された権限は、これらのユーザーに適用されます。

次に、リソース権限付与の構成について見てみます。

リソース権限付与の構成

「Resource Grants」タブをクリックし、OPSSセキュリティ・ストアに構成されている、アプリケーション・リソースへのアクセス権を付与するポリシーの構成を表示します。 このページで、次のことを制御します。

1. アプリケーションで構成されるリソース権限付与の範囲を指定する
2. このページを使用する際に考慮するセキュリティのベスト・プラクティスに関する、JDeveloperヘルプ・システムにリンクする
3. 権限付与を適用するリソース・タイプとソース・プロジェクトを指定する
4. test-all権限付与のタスク・フローのみ表示するのか、インポートされたADFライブラリのタスク・フローを表示するのかを指定する
5. 特定のリソースを名前で検索する
6. OPSSセキュリティ・ストアのリソースを管理する
7. アプリケーション・ロール、ユーザー、エンタープライズ・ロール、コード・ソースなどの、リソース権限付与の権限受領者を管理する
8. このポリシーの一部として権限付与されるアクション（または権限）を管理する

このページで、taskFlowCall1タスク・フローの表示権限をauthenticated-roleのすべてのユーザーに付与するポリシーが定義されています。 ポリシー、つまりリソース権限付与が表示されない場合、「」アイコンをクリックすると、権限付与が構成されているすべてのリソースが表示されます。

少し時間をとってこのページを確認し、内容を把握したら、このステップを続行します。

JDeveloperによってこれがADFアプリケーションであることが認識されて、jazn-data.xml ファイルのグラフィカルな表示にADFフォーカスが追加されます。 そのままで使用できるリソース・タイプは、Task FlowとWeb Pageです。 これらのリソース・タイプのいずれかを選択すると、選択したリソース・タイプの利用可能なADFアプリケーション・リソースがビューに表示され、これらのADFアプリケーション・リソースにセキュリティ・ポリシーを構成できるようになります。 taskFlowCall1リソースのリソース権限付与を表示できるのと同様に、リソース・タイプをWeb Pageに変更できます。変更すると、以下のスナップショットに示すように、ADFアプリケーションのWebページが表示されます。 このアプリケーションのいずれのWebページにもポリシーが定義されていないことも確認できます。

Resource Typeとして「Web Page」を選択し、表示された各Webページを選択すると、ポリシー認可の権限付与がないことが分かります。

この画面のソース・プロジェクトは、現在、ViewControllerに設定されています。 Source Projectの横にある検索アイコンをクリックして、フィルタにModelソース・プロジェクトを追加すると、このプロジェクトのリソースを一覧に表示できます。 ただし、Modelプロジェクトにはソースは一切存在しないため、ここでは、この操作は時間の無駄になります。

また、Resource Typeドロップダウン・リストの横にある「」アイコンをクリックして、独自のリソース・タイプを作成することもできます。 ただし、この新しいリソース・タイプを使って作成および取得したリソース・インスタンスでは、コード内にAPI呼出しを追加して、カスタム・リソースに権限付与されているポリシーを適用する必要があります。これは、これらのポリシーがADFで認識されていないためです。

使用する予定がない場合でも、新しいリソース・タイプを作成してみます。

• Resource Typeドロップダウン・リストの横にある追加アイコンをクリックします。



• Create Resource Typeウィンドウが表示されます。
• 名前としてMyResourceTypeを入力します。
• Display Nameは空白のままにします。
• Matcher Classはデフォルト（oracle.security.jps.ResourcePermission）のままにします。
• Descriptionは空白のままにします。
• Actionsページの追加ボタンを使用して、view、update、およびdeleteというアクションを追加します。
• 「OK」をクリックして、リソース・タイプの作成を終了します。



• 作成したリソース・タイプを確認します。 ドロップダウン・リストで、新しいリソース・タイプと同じ名前が付いた、新しいリソース・タイプを選択できるようになります。



リソース・タイプは、OPSSによって保護できる実際のリソースではありません。リソース・インスタンスを取得するテンプレートのようなものです。 リソース・インスタンスは、OPSSによって保護できます。 また、Resource Grantsページで使用している設定に関係なく、使用するリソース・タイプと一致するリソースが表示されます。 これは、使用するリソース・タイプが、認識されているADFリソース・タイプでないためです。 Source Projectフィルタに<Not Applicable>と表示されることから、これが分かります。 つまり、このリソース・タイプに対して、独自のリソースを作成し、アプリケーション・コード内のOPSS APIを使用する必要があるこれらのリソースに、認可を適用する必要があります。 これは、ADF OPSSに対応していないJava EEアプリケーションが動作するしくみと同じです。

次に、新しいリソース・インスタンスを作成します。

• Resourcesペインで追加アイコンをクリックします。



• Create Resourceウィンドウが表示されます。
• 名前としてMyResourceInstanceを入力します。
• Display Nameは空白のままにします。
• Descriptionは空白のままにします。
• 「OK」をクリックして、リソース・インスタンスの作成を終了します。



• 作成したリソース・インスタンスを確認します。 Resourcesペインに新しいリソースが表示されています。



リソース・インスタンスを作成しました。 次に、リソース権限付与を作成して、特定のユーザーがリソースで特定の権限を実行できるようにする必要があります。

新しいリソース権限付与を作成します。

• Granted To ペインで追加アイコンをクリックし、「Add Application Role」を選択します。



• Create Application Rolesウィンドウが表示されます。
• ロールとして「Developer」を選択します。
• 「OK」をクリックして、この権限付与のロールの選択を終了します。



• 権限付与が作成されていることを確認します。 Developerロールが、Granted Toペインに表示されているこのリソースの権限受領者であることが分かります。 また、Actionsペインに、このリソース・タイプに作成したアクションが設定されています。 次に、Developerロールに対して付与するアクション（1つまたは複数）を選択する必要があります。



• 3つのアクションすべてを選択して、新しいリソースのすべての権限へのアクセスをDeveloperロールに付与します。



• 新しいリソース・タイプを作成し、このリソース・タイプに基づいてリソース・インスタンスを作成し、Developerロールにこのリソースの表示、更新、削除権限へのアクセスを許可するリソース権限付与を作成しました。jazn-data.xmlファイルのソースを表示して、どのような構成になっているかを確認できます。
• 「Source」タブをクリックして、ファイルのXMLソースを表示します。
• 作成したリソース権限付与が含まれている<jazn-policy>内で、XML要素<resource-type>、<resource>、および<grant>スタンザを見つけます。 XMLは次のようになっています。

<resource-types>
 <resource-type>
  <name>MyResourceType</name>
  <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
  <actions-delimiter>,</actions-delimiter>
  <actions>view,update,delete</actions>
 </resource-type>
</resource-types>
<resources>
 <resource>
  <name>MyResourceInstance</name>
  <type-name-ref>MyResourceType</type-name-ref>
 </resource>
</resources>
<jazn-policy>
 ...
 <grant>
  <grantee>
   <principals>
    <principal>
     <name>Developer</name>
     <class>oracle.security.jps.service.policystore.ApplicationRole</class>
    </principal>
   </principals>
  </grantee>
  <permissions>
   <permission>
    <class>oracle.security.jps.ResourcePermission</class>
    <name>resourceType=MyResourceType,resourceName=MyResourceInstance</name>
    <actions>delete,update,view</actions>
   </permission>
  </permissions>
 </grant>
</jazn-policy>

• これは開発者向けのコースではないため、この構成を保持する必要はありません。 この構成は、リソース・タイプ、リソース・インスタンス、関連するアクションを構成する方法、およびこれらのアーチファクトを使用して認可ポリシーの権限付与を構成する方法について、単に例を紹介する目的で示しました。 次のステップに進む前に、ファイルからこの構成を削除できます。

次に、エンタイトルメント権限付与の構成について見てみます。

エンタイトルメント権限付与の構成

「Entitlement Grants」タブをクリックし、OPSSセキュリティ・ストアに構成されている、アプリケーション・リソースへのアクセス権を付与するポリシーの構成を表示します。 このページで、次のことを制御します。

1. アプリケーションで構成されるエンタイトルメント権限付与の範囲を指定する
2. このページを使用する際に考慮するセキュリティのベスト・プラクティスに関する、JDeveloperヘルプ・システムにリンクする
3. ポリシー・ストア内に構成されるエンタイトルメントを指定する
4. 選択したエンタイトルメントの情報を表示する
5. タブを使って、このエンタイトルメントに含まれているリソースと権限付与間を切り替える
6. エンタイトルメントに含まれているリソースを管理する。 Grantsタブを選択している場合、このタブで、アプリケーション・ロール、ユーザー、エンタープライズ・ロール、コード・ソースなど、エンタイトルメント権限付与の権限受領者を管理できます。
7. このポリシーの一部として権限付与されるアクション（または権限）を管理する

このアプリケーションでは、現在、エンタイトルメントは使用されていません。 次のページでは、エンタイトルメント構成ツールの場所を示しています。 必要に応じて、Entitlementsセクションのプラス記号アイコンをクリックして、独自のエンタイトルメントを作成できます。