| Oracle WebCenter Framework開発者ガイド 10g（10.1.3.2.0） E05044-04 |
|
 戻る |
 次へ |
この章では、WebCenterアプリケーション内でOracle ADF Securityを使用して認証および認可を処理する方法について説明します。
この章の内容は、次のとおりです。
WebCenterアプリケーションは動的で実行時駆動型のアプリケーションであり、多くの場合、カスタマイズおよびパーソナライズのフォームでのユーザーからの入力を取り扱います。このため、従来型のJ2EEセキュリティの使用は制限されます。J2EEセキュリティの制限をなくすには、Java Authentication and Authorization Service（JAAS）に基づいたOracle Application Development Framework（Oracle ADF）セキュリティを使用できます。JAASは、Java Community Processを経てJava言語に追加された、アプリケーションでのユーザーの認証と認可の実施を可能にする標準的なセキュリティ・アプリケーション・プログラミング・インタフェース（API）です。
J2EEセキュリティでは、ロールに基づいてパスが保護されます。たとえば、SRDemoアプリケーションでは、中核となる3つのロール（J2EEセキュリティ・ロール）によって、特定の機能を実行する権限のあるユーザーや、ページへのアクセス権を持つユーザーが決定されます。各ユーザーは、3つのロール（ユーザー、技術者または管理者）のいずれかで分類する必要があります。アプリケーションの開発中に、指定されたJ2EEセキュリティ・ロールに特定のURLパターンをマップするセキュリティ制約を定義します。たとえば、URLパターン/app/management/*を管理者ロールにマップすると、管理者のみがこれらのページにアクセスできるようになります。制約、ユーザー・ロールまたはセキュリティ・ロールは、web.xmlファイル内に定義します。これに対し、静的ロールからアイデンティティ管理ソリューション内のロールへのマッピングは、アプリケーション・サーバーのデプロイメント・ディスクリプタ（OC4Jではorion-web.xmlファイル）内に定義します。これらのファイルは両方ともアプリケーションとともにデプロイされるため、実行時にセキュリティ制約を変更することはできません。新しいロールを作成するには、アプリケーションを再デプロイする必要があります。
このような問題は、JAASに基づいたOracle ADF Securityモデルを使用することで解決されます。Oracle ADFは、JAASサービスのOracle実装であるJAZNとの統合を介して、JAASセキュリティ・モデルを実装します。現在まで、JAASは主に認証用に使用されてきましたが、認証モデルの定義ができるような設計にもなっています。（つまり、これがJAASの2番目のAの意味です。）従来、これにはカスタム・コードの使用が必要であり、実装は容易ではありませんでした。しかし、Oracle ADF Securityでは、JAAS認可モデルを宣言的な方法で公開することによって、その実装を簡略化しています。
Oracle ADF Securityを使用すると、アプリケーションにアクセスするために必要な権限（アクティビティ）は静的ロール定義ではなく、アプリケーションとともにデプロイされます。これらの権限は実行時にマップされるため、（デプロイ後に新しいロールを追加した場合などの）セキュリティ・プロファイル情報の変更内容は、アプリケーションを更新しなくても自動的に適用されます。さらに、Oracle ADF Securityは保護されたリソースのURLによる制約を受けないため、リソースに対して詳細な権限を定義できます。また、アプリケーションで、Expression Language（EL）を使用して、実行時ポリシー・ストア内に定義されているユーザーの権限に基づいてページ上のアイテムの表示/非表示を切り替えることができます。このポリシー・ストアは、2つのうちいずれかのJAZNリソース・プロバイダ内に定義できます。1つはJAZN-XMLで、ファイルsystem-jazn-data.xml内に権限付与を指定します。もう1つはJAZN-LDAPで、これらの権限付与をOracle Internet DirectoryなどのLDAPv3準拠ディレクトリ内に格納します。
Oracle ADF Securityを使用すると、アプリケーションの組織を簡略化できます。セキュリティは、セキュリティ制約のURLマッピングを介さずに宣言的な権限によって指定できるため、保護対象のリソースの場所はこれらのセキュリティ制約により決定されることがなく、アプリケーションに論理的な構造でページを編成できるようになります。たとえば、ファイル・タイプ（jsp、jspxなど）に基づいて1つのフラット・ディレクトリ構造でページを格納したり、従来的な階層ディレクトリ・ツリーでページを格納することができます。
Oracle ADF Securityでは重要な新しい機能がアプリケーションに追加されますが、JAAS仕様そのものはJ2EE宣言型セキュリティ・モデルの一部です。つまり、これはJ2EEコンテナ・セキュリティ・プラットフォーム全体の拡張要素です。このため、詳細なOracle ADF Security実装を標準のJ2EEコンテナ・セキュリティの拡張要素とみなすことができます。この実装は、標準のセキュリティ制約の処理完了後に実行されます。
Oracle ADFフレームワーク内では、JAASベースのセキュリティは、特定のサーブレット・フィルタおよびアプリケーションのデータ・バインディング層を使用することにより実施されます。フィルタとバインディング層は連携して受信リクエストをトラップし、現在のユーザーの権限を判別し、それに応じてリクエストを遮断または許可します。
Oracle ADF Securityを使用すると、パスを保護するのではなく、JAASでアクションを保護することになるため、WebCenterアプリケーションを実世界のビジネス・セキュリティ要件に応じて簡単に調整できます。JAASベースのOracle ADF Securityの特長は、次のとおりです。
宣言的なポートレット間セキュリティを、より詳細に設定できます。J2EEセキュリティはURLベースまたはページ・ベースなので、細かいレベルのアクセス制御を設定することはできません。Oracle ADF Securityを使用すると、同じURLで、ロールに応じて異なるレベルのアクティビティの実行を許可できます。
ポリシーはアプリケーションの外部に格納されるため、実行時に、新しいロールおよびそれに関連付けられたアクセス権限を作成できます。
権限の継承を可能にする階層ロールを使用することで、権限の割当てが簡略化されます。J2EEセキュリティ制約で使用されるJ2EEセキュリティ・ロールがフラットであるのに対し、JAAS権限はネスト可能なエンタープライズ・ロールを参照します。
この項では、次のトピックについて説明します。
Oracle ADF Securityでは、暗黙的認証および明示的認証を使用できます。暗黙的認証のシナリオにおいては、図10-1に示すように、認証されていないユーザーがページにアクセスしようとすると、adfBindingsサーブレット・フィルタがリクエストを遮断し、ページがanyoneに対して表示可能であると定義されているかどうかを確認します。
初めてページにアクセスするときに、何もサブジェクトが定義されていない場合、anonymousユーザー・プリンシパルおよびanyoneロール・プリンシパルを含むサブジェクトが作成されます。このロール・プリンシパルを使用して、ユーザーは、anyoneロールに対して表示権限が付与されているページにアクセスできます。たとえば、public.jspなどにアクセスできます。認可の詳細は、10.1.2項「認可」を参照してください。
ただし、リクエストされたページが保護されている場合（mypage.jspxなどのように、anyoneに対して表示可能と定義されていない場合）は、adfBindingsサーブレット・フィルタがOracle ADF認証サーブレットにリクエストをリダイレクトし（ステップ1）、リクエストされたページのURLを成功URLとして渡します。
adfAuthenticationサーブレットにはJ2EEセキュリティ制約が設定されているため、J2EEコンテナによって構成済のログイン・メカニズムが起動されます（ステップ2）。コンテナのログイン構成に基づいて、ユーザーは認証を要求されます。フォームベース認証の場合は、アプリケーション・ログイン・フォームが表示され（ステップa）、ユーザーが資格証明を入力します（ステップb）。その後、フォームがコンテナのj_security_check()メソッドにポストされます（ステップc）。
J2EEコンテナは、構成済のプラッガブル認証モジュールを使用してユーザーを認証し（ステップd）、認証が成功すると、コンテナは認証チャレンジを開始したサーブレットにユーザーをリダイレクトします。この場合は、adfAuthenticationサーブレットにリダイレクトします（ステップ3）。adfAuthenticationサーブレットに戻ると、最初にリクエストされたURLに以降にリダイレクトするために、成功URLの値が使用されます（ステップ4）。
明示的認証のシナリオにおいては、図10-2に示すように、（anonymousユーザー・プリンシパルとanyoneロールのみを持つ）認証されていないユーザーが、パブリック・ページの「Login」リンクをクリックします（ステップ1）。「Login」リンクは、J2EEセキュリティ制約を介して保護されているadfAuthenticationサーブレットへのダイレクト・リクエストです。
このシナリオでは、現在のページがadfAuthenticationサーブレットにパラメータとして渡されています。暗黙的認証の場合と同じように、セキュリティ制約によって、ユーザーはコンテナのログイン・コンポーネントにリダイレクトされます（ステップ2）。暗黙的認証のステップa〜dに示したように、コンテナによりユーザーが認証された後、リクエストはadfAuthenticationサーブレットに戻されます（ステップ3）。その後、サーブレットは、ユーザーをパブリック・ページに戻しますが、今度は新しいユーザー・プリンシパルとロール・プリンシパルを使用します。
この項では、認可機能が、実行時にアクセスされるポリシー・ストア定義に移される方法を示します。ポリシー・ストア定義には、オブジェクトに対するアクションの権限が含まれます。これらの権限は、Oracle JDeveloperでオブジェクトに認可を設定するときに指定します。
図10-3に、認可プロセスを示します。
ユーザーは、アイデンティティ管理ソリューション内のエンタープライズ・ロールStaffのメンバーです。このユーザーがmypage.jspxにアクセスしようとすると、Oracle ADF Securityの強制ロジックによってリクエストが遮断され、権限が必要かどうかを調べるためにそのページのページ定義が確認されます。
ユーザーはまだログインしていないため、セキュリティ・コンテキストにはまだサブジェクト（ユーザーを表すコンテナ）がありません。このため、anonmousユーザー・プリンシパル（ユーザーの一意の定義）とanyoneロール・プリンシパルを持つサブジェクトが作成されます。
anyoneロールに付与されている権限は、保護されたリソースを、すべてのユーザー（認証されたユーザーと認証されていないユーザーの両方）がアクセスできるパブリック・リソースにします。このため、anyoneロール・プリンシパルを使用すると、ユーザーは、anyoneロールに対して表示権限が付与されているページにアクセスできます。たとえば、public.jspなどにアクセスできます。
mypage.jspxにはanyone以外のロールの表示権限が必要なので、ユーザーは認証を要求されます。認証が成功すると、ユーザーに特定のサブジェクトが作成されます。セキュリティ強制ロジックによって、mypage.jspxを表示するのに必要なロールと、ユーザーがそのロールのメンバーになっているかどうかを判別するために、ポリシー・ストアが確認されます。この場合は、ロールStaffに対して表示権限が付与されています。また、ユーザーはこのロールのメンバーであるため、mypage.jspxへのナビゲートを許可されます。
同様の方法で、ユーザーがsecpage.jspにアクセスしようとすると、ユーザーはこのページのview権限を持たないので、アクセスは拒否されます。
Oracle ADFには、ページやデータ・コントロールなどの多数のセキュリティ対応コンポーネントが備わっています。これらのコンポーネントは、事前定義の有効範囲付きアクションのセットを含む特定の権限にマップされます。アクションに権限を付与することで、開発者は、関連付けられた保護されたコンポーネントに対して指定のアクションを実行することをユーザーまたはロールに認可できます。
|
注意: このリリースでは、JAASポリシー・ストア内のポリシー情報の有効範囲はアプリケーション別に設定されません。したがって、2つのアプリケーションが同じ権限ターゲットを参照している場合、両方がそのターゲットに対する同じ権限付与を参照することになります。この場合、意図しない結果が発生することがあります。これを回避するため、アプリケーションで、アプリケーション有効範囲を設定するために、リソースに適切な名前を指定する必要があります。たとえば、ページを単にPage1.jspxという名前にするのではなく、App1_Page1.jspxのようなより限定的な名前にすると、ポリシーを区別しやすくなります。 |
Oracle ADF Securityでは、次の4つの認可ポイントが定義されています。
ページ
メソッド
イテレータ
属性
図10-10に示すような認可エディタを使用すると、特定のロールに対して、オブジェクトにアクションを実行するために必要な認可を定義できます。
認可エディタは、ポリシー・ストア（埋込みOC4J内にあるsystem-jazn-data.xmlファイル）内に定義されているエンタープライズ・ロールを公開し、特定のコンポーネント・タイプ（ページ、メソッド、イテレータまたは属性）に対して定義されているアクションを表示します。たとえば、ViewやEditなどのアクションが表示されます。認可ポリシーを実装するには、表示されている1つ以上のロールに対するアクションをチェックします。
認可エディタは、ポリシー・ストアに権限情報を書き込みます。ポリシーにより、権限タイプ、保護されるリソース、そのリソースに対して実行可能なアクション、およびそのポリシーを割り当てる（権限を付与する）ユーザーが定義されます。ポリシーは、grantによって定義されます。grantには、1つのgranteeと1つ以上のpermissionが含まれます。
granteeは、ポリシーを適用するユーザーを定義します。例10-1に、system-jazn-data.xmlファイル内でgrantを定義する方法を示します。
例10-1 system-jazn-data.xmlファイル内のgrant
<grant>
<grantee>
<principals>
<principal>
<class>oracle.adf.share.security.authentication.ADFRolePrincipal</class>
<name>anyone</name>
</principal>
. . .
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>oracle.srdemo.view.pageDefs.app_SRWelcomePageDef</name>
<actions>view</actions>
</permission>
. . .
</permissions>
</grant>
このgrant内では、SRWelcomeページに対する表示権限がロール・プリンシパルanyoneに割り当てられています。この権限は、SRWelcomeページの関連付けられたページ定義ファイルに対して指定されているものです。
|
注意: ページ・セキュリティ・ポリシーは、RegionPermissionクラスを介して実装します。この例では、ワイルドカード(*)をメソッド名として使用することにより、anyoneロールに、アプリケーション内で（MethodPermissionクラスによって定義された）任意のメソッドを実行する権限も付与されています。 |
ページ権限
ページ認可ポリシーは、ページ定義ファイルに対して定義します。ページ権限を編集するには、10.2.3.2項「アプリケーション内のページの保護」の手順を実行してください。
表10-1に、ページに選択可能なアクションを示します。
表10-1 ページ権限
| アクション | 説明 |
|---|---|
|
View |
ページを表示します。 |
|
Personalize |
ページ上のポートレットをパーソナライズします。ページ上に公開されているポートレットをパーソナライズする場合は、このページ権限が必要です。パーソナライズでは、自分だけに表示される変更を行うことができます。 |
|
Customize |
ページをカスタマイズします。変更内容はすべてのユーザーに表示されます。 |
|
Edit |
ページに表示されているコンテンツを編集します。Editアクションは、このリリースでは適用できません。 |
|
Grant |
他のユーザーに権限を付与します。このアクションは、設計時には使用しません。 |
|
注意: ページにView権限を付与しても、そのページに追加されたメソッド、イテレータおよび属性へのアクセス権限が自動的に付与されるわけではありません。これらの権限は個別に設定する必要があります。 |
メソッド権限
メソッド権限は、アプリケーション内で特定の名前付きメソッド・クラスを実行できるかどうかを設定します。
表10-2に、メソッドに選択可能なアクションを示します。
メソッド権限は、ページそのものへのアクセスではなく、ページ内にアプリケーション・セキュリティを強制するために使用することがしばしばあります。たとえば、ユーザーがdeleteメソッドを実行できるかどうかに基づいて、「削除」ボタンを非表示にすることができます。
イテレータ権限
イテレータ権限は、データ・コントロールを介して公開されたデータ・セット内をスクロールできるかどうか、およびそのデータに対してデータ操作言語（DML）スタイルのアクションを実行できるかどうかを設定します。
表10-3に、イテレータに選択可能なアクションを示します。
表10-3 イテレータ権限
| アクション | 説明 |
|---|---|
|
Create |
新しいレコードを作成します。 |
|
Read |
イテレータが指している現在のデータ・セットを読み取ります。 |
|
Update |
現在選択されているデータ・セットを更新します。 |
|
Delete |
現在選択されているデータ・セットを削除します。 |
属性権限
属性権限は、イテレータ内に返されたオブジェクトの特定の属性を表示および更新できるかどうかを設定します。
表10-4に、属性に選択可能なアクションを示します。
通常は、一部のポータル・ページを、ユーザーの特定のアクセス権限にかかわらずすべてのユーザーが表示できるようにする必要があります。たとえば、インターネット・サイトのようこそページは、そのサイトにアクセスしたすべてのビジターに表示されるようにします。これに対し、企業サイトは、認証を介して識別されたユーザーに対してのみパブリックにします。
どちらの場合も、ページを表示する権限がユーザーの特定の権限によって定義されているわけではないので、ページはパブリックであると考えられます。両者の違いは、ユーザーが匿名であるか、それとも既知のアイデンティティであるかです。
パブリックを使用すると、従来のJ2EEセキュリティとは異なり、まったく保護されていない（セキュリティが有効になっていないか実装されていない）コンテンツとパブリック・コンテンツを区別できます。
Oracle ADF Securityモデルにおいては、anyoneロール・プリンシパルにアクセス権限を付与するという方法で、セキュリティがないこととコンテンツへのパブリック・アクセスを明確に区別しています。anyoneは、既知のユーザーと匿名ユーザーの両方を包含するロールです。このため、anyoneに権限を付与することで、認証されていないユーザー（ゲスト・ユーザーなど）がリソースにアクセスできます。認証されたユーザーにのみパブリック・アクセスを実装するには、usersロール・プリンシパルにポリシーを定義する必要があります。
Oracle WebCenter Suiteにおける外部アプリケーションおよび資格証明プロビジョニングは、ユーザー認証を必要とするアプリケーションのコンテンツにアクセスする手段を提供します。Oracle PDKポートレット・プロデューサの実装が、各自の認証を処理するアプリケーションを基礎にしている場合、そのプロデューサを外部アプリケーション定義と関連付けることができます。設計時にこれを行うには、外部アプリケーションを登録し、Oracle PDKポートレット・プロデューサを登録または編集するときにリストから外部アプリケーションを選択するだけです。実行時には、プロデューサは、外部アプリケーションに関連付けられた情報を使用してアプリケーションに対してユーザーを認証し、結果としてそのポートレットを消費します。プロデューサ・コードは、外部アプリケーションとの認証対話を実際に実行する役割を持つことに注意してください。Oracle WebCenter Suiteに組み込まれている外部アプリケーション・サポートは、認証に必要な情報をOracle PDKを介してポートレット・プロデューサに提供するにすぎません。
ユーザーは要求されるとログイン資格証明を提供します。これらの資格証明は、資格証明ストア内に保存されています。それ以降は、認証時に資格証明ストアによってその情報が提供されます。ユーザーが資格証明を提供するのは1回のみです。この情報はWebCenterアプリケーション・エンドで格納され、ユーザーのWebCenterアプリケーション・ユーザー名にマップされます。以降のリクエストでは、マッピング情報が資格証明ストアから読み取られます。ポートレットの実行時フレームワークによって、資格証明ストアからユーザーのマップ済資格証明が取得されます。
資格証明プロビジョニング・ページは、外部アプリケーション定義を介して提供された情報に基づいて構築されたJSFページ（.jspx）です。実行時、資格証明プロビジョニング・ページには、外部アプリケーション登録を介して指定されたデータ・フィールドからなるログイン・データ・フィールドが表示されます。ユーザーは、データ・フィールドにログイン情報を入力します。ログイン情報はプロデューサに渡され、プロデューサはログイン値をアプリケーションに渡します。アプリケーションは、リクエストされたポートレットをプロデューサに提供します。資格証明プロビジョニング・ページに資格証明を入力すると、資格証明ストア内の資格証明に持続性を持たせることにもなります。
たとえば、プロデューサで、独自の認証メカニズムを備えたポートレット生成アプリケーションから気象ポートレットを提供するとします。この場合、開発者は次のことを行います。
外部アプリケーション登録ウィザードを介して、アプリケーションの認証メカニズムに関する情報を取り込む外部アプリケーションを登録します。
資格証明プロビジョニング・ページ（事前構築済ページ）を追加します。このページのルック・アンド・フィールは変更できます。実行時、このページには、外部アプリケーション登録を介して指定されたログイン・データ入力フィールドが表示されます。
プロデューサの登録または編集時に、外部アプリケーションをOracle PDKポートレット・プロデューサに関連付けます。
実行時、ユーザーが気象ポートレットにアクセスすると、ログイン・ページ（つまり資格証明プロビジョニング・ページ）が表示され、ユーザーはログイン情報を入力します。この情報は、プロデューサを介してポートレット提供アプリケーションに渡されます。（認証後に）ポートレット提供アプリケーションは、気象ポートレットをプロデューサに戻します。次にプロデューサは、気象ポートレットをポートレット消費アプリケーションに提供します。これによって、ユーザーにポートレットが表示されます。
ユーザーが入力したログイン情報は、資格証明ストア内に保存されます。これ以降のセッションのログインは、この資格証明ストアによって処理されます。（ユーザーの資格証明が変更されないかぎり、）ユーザーがログイン情報を再び入力する必要はありません。
外部アプリケーションの登録方法、および資格証明プロビジョニング・ページの作成方法の詳細は、10.7項「資格証明を必要とする外部アプリケーションへのアクセス」を参照してください。
この項では、JAASに基づいたOracle ADF Securityを使用してアプリケーションを保護する方法について説明します。アプリケーションにセキュリティを定義するには、次のようなハイレベルな手順を実行する必要があります。
WebCenterセキュリティは、権限がエンタープライズ・ロールに付与されたロールベースのアクセス制御メカニズムを基礎としているため、開発環境で使用するアイデンティティ管理システム内に適切なロールを作成する必要があります。開発環境の場合は、これらのロールが、デフォルトのアイデンティティ管理ソリューションであるsystem-jazn-data.xmlファイル内に存在している必要があります。
これらのロールを定義するためのオプションは、2つあります。
開発者が、本番環境で使用される実際のロールのリストを保守し、ポリシー定義用にこれらのロールを使用します。これによって、デプロイ時にポリシーを簡単に移行できます。
開発者が、最終的な本番ロールを表す一時的ロール名のリストを定義し、ポリシー定義用にこれらのロールを使用します。デプロイ時に、これらのポリシーを、実際の本番ロールを反映するように更新する必要があります。アプリケーションのデプロイ時にapp-jazn-data.xmlファイル内のポリシー情報を更新する方法の詳細は、12.2.4.2項「ポリシー情報の更新（オプション）」を参照してください。
開発環境内にテスト・ロールおよびユーザーのセットを作成するには、『Oracle WebCenter Frameworkチュートリアル』の「チュートリアルのIDストアの設定方法」を参照してください。
次の手順でADFセキュリティ・ウィザードを実行することにより、アプリケーションを保護します。
アプリケーション・ナビゲータで、「ViewController」を選択します。
図10-4に示すように、「ツール」メニューから「ADFセキュリティ・ウィザード」を選択します。ADFセキュリティ・ウィザードによって、構成プロセスがガイドされます。
必要な場合、「次へ」をクリックして、「ようこそ」ページをスキップします。
図10-5に示すように、「強制認可」を選択します（まだ選択されていない場合）。このオプションによってadfAuthenticationサーブレットが構成され、認可ルール（ページに対する現在のユーザーの権限をチェックできるようにする適切なフィルタ）が構成されます。
「次へ」をクリックして、ウィザードの次のページに進みます。
アプリケーションで使用する適切なJAASプロバイダを選択します。Oracle ADF Securityにより、リソース・プロバイダに対してユーザーが認証されます。デフォルトでは、これは軽量JAZN XMLプロバイダです。このプロバイダによって、system-jazn-data.xml内にレルムおよびポリシー情報が格納されます。
「次へ」をクリックして、ウィザードの次のページを表示します。
図10-6に示すように、このページで「場所」を「OC4Jデフォルト・リポジトリ」に、「デフォルト・レルム」を「jazn.com」に、「JAASモード」を「doAsPrivileged」に設定し、「次へ」をクリックします。
「ログイン」ページで、アプリケーションで使用する認証のフォームを選択します。この認証プロセスは、アプリケーションが稼働しているコンテナに委任されます。このプロセスでは、アプリケーション内部で定義されているセキュリティ・マネージャが使用されます。
図10-7に示すように、「次へ」をクリックして、ウィザードの最後のページを表示します。
このページでは、標準のJ2EEセキュリティ制約を使用して、アプリケーション内の保護するリソースを定義します。WebCenterアプリケーションで使用されるJAASベースのセキュリティ・モデルでは、セキュリティ制約を使用して保護する必要のあるWebリソースは、adfAuthenticationサーブレットのみです。
認証はコンテナに委任されるため、adfAuthenticationサーブレットに対してセキュリティ制約を使用すると、アプリケーション全体でログイン・リンクまたはログアウト・リンクとして使用できる1つの標準URLを定義することが可能です。
|
注意: J2EEコンテナ管理のセキュリティでは、ログオンのための標準方式が定義されています。アプリケーションからログアウトするための標準はありません。したがって、ログイン・プロセスがコンテナに委任されるのに対し、ログアウト・プロセスはadfAuthenticationサーブレットそのものによって処理されます。 |
このページを使用して、アプリケーションで使用されるWebリソースに追加のセキュリティ制約を設定できます。ただし、adfAuthenticationリソースは削除しないでください。adfAuthenticationリソースを削除すると、アプリケーションにログオンできなくなります。アプリケーションのすべてのユーザーがログオンできることが必要なので、adfAuthenticationサーブレットに対して定義されているセキュリティ制約で、すべてのユーザーがこのWebリソースにアクセスすることが許可されている必要があります。このため、制約に関連付けられたセキュリティ・ロールが、すべてのユーザーに対応している必要があります。
コンテナ内に生成されているロールはoc4j-administratorのみなので、すべてのユーザーに対して適切な新しいロールを作成する必要があります。たとえば、ValidUsersを作成します。
「ロールの管理」をクリックします。
「追加」をクリックし、ValidUsersという名前を入力します。
後で、このJ2EEロールをアイデンティティ・ストア・ロールusersにマップします。このロールは、有効な各ユーザーのリストを保守します。セキュリティの観点から、このロールに権限を割り当てると、認証済のパブリック・リソースを効果的に定義できます。つまり、特定の権限を定義しなくても、すべてのユーザーに対してパブリック・リソースが使用可能になります。
「OK」をクリックします。リストにValidUsersロールが表示されます。
「閉じる」をクリックします。
図10-8に示すように、二重矢印（「すべて追加」）をクリックして、「使用可能なロール」リスト内のすべてのロールを「選択したロール」リストに移動します。oc4j-administratorは、「選択したロール」リストから削除してかまいません。
「次へ」をクリックし、「終了」をクリックします。
ADFセキュリティ・ウィザードの使用時に行われる処理
ADFセキュリティが有効化されると、デフォルトで、すべてのアプリケーション・リソースが保護されます。つまり、アプリケーション内のページ、イテレータ、属性およびメソッドはセキュアになり、明示的なセキュリティ・ポリシーが必要になります。このため、セキュリティ・ウィザードを実行した後は、適切な権限（たとえば、ページの表示権限）を明示的に付与する必要があります。そうしない場合、セキュリティ違反が発生します。
ADF Securityウィザードを実行すると、保護対象のアプリケーションを構成するファイルは更新されます。表10-5に、更新されるファイルおよびファイルの変更内容を示します。
表10-5 ADF Securityウィザードにより更新されるファイル
| ファイル | ADF Securityウィザードにより実行される構成 |
|---|---|
|
|
|
|
|
詳細は、付録C「WebCenterアプリケーションのファイル」を参照してください。
WebCenterアプリケーション内にセキュリティを実装することは、定義上、Oracle ADF Frameworkのセキュリティ・インフラストラクチャを実装することです。このため、フレームワークのセキュリティ・コンテキストを使用して、アプリケーションのポリシーやセキュリティ全体を定義するときに必要となる情報にアクセスできます。
この項の内容は、次のとおりです。
セキュリティが有効になっているかどうかの判別
Oracle ADF Securityの強制はアプリケーションと無関係にコンテナ・レベルでオン/オフを切り替えることができるため、権限確認を行う前に、Oracle ADF Securityが有効化されているかどうかを判断する必要があります。このためには、例10-2に示すように、Oracle ADF SecurityコンテキストのisAuthorizationEnabled()メソッドを評価します。
例10-2 Oracle ADF SecurityコンテキストのisAuthorizationEnabled()メソッドの使用
if (ADFContext.getCurrent().getSecurityContext().isAuthorizationEnabled()){
//Permission checks are performed here.
}
ユーザーが認証されているかどうかの判別
WebCenterアプリケーション内のユーザー・プリンシパルがNullになることはない（つまり、認証されていないユーザーの場合はanonymousで、認証されたユーザーの場合は実際のユーザー名になる）ため、ユーザー・プリンシパルがNullかどうかを確認するだけで、そのユーザーがログオンしているかどうかを判断することはできません。このため、anonymousユーザー・プリンシパルがユーザーが認証されていないことを表すことを考慮に入れるメソッドを使用する必要があります。このためには、例10-3に示すように、Oracle ADF SecurityのisAuthenticated()メソッドを評価します。
例10-3 Oracle ADF SecurityコンテキストのisAuthenticated()メソッドの使用
// ============ User's Authenticated Status =============
public boolean isAuthenticated() {
_authenticated = ADFContext.getCurrent().getSecurityContext().isAuthenticated();
return _authenticated;
}
現在のユーザー名の判別
WebCenterアプリケーションでは、セキュアでありながらすべてのユーザーに使用可能なパブリック・ページの概念をサポートしています。さらに、WebCenterページ上のコンポーネント（ポートレットなど）では、現在のユーザー・アイデンティティの情報を必要とします。このため、WebCenterアプリケーション内のユーザー名がNullになることはありません。認証されていないユーザーがページにアクセスすると、ユーザー名anonymousがページ・コンポーネントに渡されます。
現在のユーザー名を判別するには、例10-4に示すように、Oracle ADF SecurityコンテキストのgetUserName()メソッドを評価します。このメソッドは、すべての認証されていないユーザーに文字列anonymousを返し、認証済のユーザーに実際の認証済ユーザーの名前を返します。
例10-4 Oracle ADF SecurityコンテキストのgetUserName()メソッドの使用
// ============ Current User's Name/PrincipalName =============
public String getCurrentUser() {
_currentUser = ADFContext.getCurrent().getSecurityContext().getUserName();
return _currentUser;
}
Facesベースのアプリケーションでユーザー名を判別するための従来のメソッド（FacesContext.getCurrentInstance().getExternalContext().getRemoteUser()）では、認証されていないユーザーに対してNullが返されるため、そのメソッドを使用する場合は、パブリック・ユーザーのケースを処理する追加のロジックを使用する必要があります。
J2EEセキュリティ・ロールのメンバーシップの判別
WebCenterアプリケーション・セキュリティはJAASのポリシーをその軸としていますが、アプリケーション・ページ内のコンポーネントをロールのメンバーシップに基づいて保護するために、引き続きJ2EEセキュリティ・ロールを使用する必要があることがあります。WebCenterアプリケーションはJavaServer Facesベースのアプリケーションなので、例10-5に示すように、Faces外部コンテキストのisUserInRole(roleName)メソッドを使用すると、ユーザーに特定のロールが割り当てられているかどうかを判別できます。
この例では、便利なメソッド（checkIsUserInRole）が定義されています。マネージドBean内でこのメソッドを使用すると、名前付きロールのメンバーシップを属性として公開し、その後EL内で使用できます。
この項では、アプリケーション内のページを保護するために必要な手順を示します。アイデンティティ・ストア内に定義されているロール・メンバーのみにページ・アクセスを許可し、ロール・メンバーがページに対して実行できるアクションを指定できます。この構成は、ページ定義ファイル（<page_name>PageDef.xml）内に格納されています。図10-9に示すように、このファイルにアクセスできます。
|
注意: 編集モードを備えたポートレットをユーザーが実行すると、認証されたアプリケーション・ユーザーに対してのみ、ポートレット・メニューに「パーソナライズ」オプションが表示されます。匿名またはパブリックのユーザーには、編集モードでポートレットをパーソナライズするためのオプションは表示されません。このため、ユーザーが自分のポートレットをパーソナライズするためには、アプリケーションになんらかの形態のセキュリティを実装しておく必要があります。ポートレットやページを作成する開発者の場合、アプリケーション用の完全なセキュリティ・モデルを作成せずに、ポートレットの編集モードをすぐにテストすることが必要になる場合があります。ポートレット・パーソナライズをテストするために必要なセキュリティをすばやく追加する方法の詳細は、10.6項「ポートレット・パーソナライズをテストするための基本認証の構成」を参照してください。 |
アプリケーション内のページに対してセキュリティを有効化する手順は、次のとおりです。
アプリケーション・ナビゲータで、*.jspxページを右クリックします。
図10-9に示すように、「ページ定義に移動」を選択します。
ページ定義がまだ存在していない場合は、「はい」をクリックして、選択したページにページ定義を作成します。
「構造」ペインで、「<page_name>PageDef」を右クリックし、「認可の編集」を選択します。
認可エディタに、アプリケーションのアイデンティティ・ストア・ロールと、各ロールに選択可能なページ・アクションがリストされます。
Grant: ユーザーはページ権限を管理（付与または取消し）できます。このアクションは、設計時には使用しません。
Edit: ユーザーは、ページに表示されているコンテンツを編集できます。Editアクションは、このリリースでは適用できません。
Customize: ユーザーはページを変更できます。この権限が付与されていないユーザーは、ページを変更できません。
Personalize: ユーザーは、ページ上のポートレットをパーソナライズできます。この権限が付与されていないユーザーに対しては、ページ・ポートレットをパーソナライズ・モードにするリンクまたはボタンは表示されません。
View: ユーザーはページを表示できます。この権限が付与されていないユーザーがページにアクセスしようとすると、認可エラーが表示されます。
|
注意: パブリック・ページを定義するには、アイデンティティ管理ソリューション内に物理的には存在していない擬似ロールanyoneにView権限を付与します。認証されていないユーザーからWebCenterアプリケーションのリクエストが受け取られると、ロール・プリンシパルanyoneおよびユーザー・プリンシパルanonymousを使用してサブジェクトが作成されます。 |
認可エディタを使用して、選択したページに対する様々な権限を付与します。
たとえば、図10-10では、managerロールを持つユーザーは選択したページを表示、パーソナライズおよびカスタマイズできます。これに対し、anyoneロールを持つユーザーはページを表示できます。
「OK」をクリックします。これで、ページにセキュリティ・ポリシーが定義されました。アプリケーション内の他のページに対しても、同じ手順を繰り返すことができます。
|
注意: ページ定義ファイルと保護しようとするページの間には1対1の関係がありますが、ページ（ShowOneTabなど）の特定セクションを表すヘッドレス（ダミー）ページ定義ファイルを使用することにより、ページ内の複数の領域を保護することも可能です。このページ定義は物理的なページに実際に関連付けられてはいませんが、それでもこのページ定義にポリシーを定義できます。
このため、このヘッドレス・ページ定義に対して表示権限を定義することにより、ターゲット・ページの実際のページ定義ではなくヘッドレス・ページを参照するという方法で、ページのセクションの表示/非表示を指定できます。 ページのセクションをロール・メンバーシップ別に保護できる場合は、「J2EEセキュリティ・ロールのメンバーシップの判別」で説明されている |
特定のOracle ADFオブジェクトはセキュリティ対応です。これは、開発者が特定のリソースに対して付与できる、コンポーネント固有の事前定義権限があるということです。
Oracle ADF Securityを構成すると、バインディング層にアクセスするすべてのオブジェクトが保護されるため、これらのオブジェクトへの適切なアクセス権限を明示的に定義する必要があります。これには、ページのコンポーネント（コンテンツ統合データ・コントロールなど）に追加できるすべてのイテレータ、属性およびメソッドが含まれます。このため、ページにアクセス・ポリシーを定義するときは、ページそのものにポリシーを定義するのみでなく、そのページに含まれているイテレータ、属性およびメソッドにもポリシーを定義する必要があります。
イテレータ、属性およびメソッドを保護する方法の詳細は、『Oracle Application Development Framework開発者ガイド』の「Oracle ADF Securityを使用した認可の実装」を参照してください。
|
注意: ページ内に含まれるすべてのイテレータ、属性およびメソッドに簡単にポリシーを追加するには、正規表現を使用して、名前付きのオブジェクト・セットを定義できます。これにより、1つのポリシーを複数の保護対象オブジェクトに対応させることができます。正規表現を使用してリソース・グループにポリシーを定義する方法の詳細は、10.2.3.5項「正規表現を使用したリソース・グループのポリシーの定義」を参照してください。 |
この項では、設計時にページにコンテンツを追加するために使用する、Java Content Repository（JCR）データ・コントロールにセキュリティを定義する手順を示します。データ・コントロールの詳細は、5.3項「JCRデータ・コントロールの使用: 例」を参照してください。ページ定義内に作成したデータ・コントロールの新しいメソッド・イテレータ、メソッド・アクション・バインディングおよび属性バインディングに対してセキュリティを有効化する手順は、次のとおりです。
アプリケーション・ナビゲータで、JSPXページを右クリックし、「ページ定義に移動」を選択します。ページ定義が表示されます。
メソッド・イテレータに対する権限を付与するには、図10-11に示すように、「構造」ペインで「実行可能ファイル」ノードを開き、メソッド・イテレータを右クリックして「認可の編集」を選択します。
図10-12に示すように、「認可の編集」ダイアログ・ボックスで、Read権限のみを設定します。
メソッド・アクション・バインディングに対する権限を付与するには、図10-13に示すように、「構造」ペインで「バインディング」ノードを開き、メソッド・アクション・バインディングを右クリックして「認可の編集」を選択します。
図10-14に示すように、「認可エディタ」ダイアログ・ボックスで、Invoke権限のみを設定します。
「OK」をクリックします。
属性バインディングに対する権限を付与するには、図10-15に示すように、「構造」ペインで「バインディング」ノードを開き、属性バインディングを右クリックして「認可の編集」を選択します。
図10-16に示すように、「認可エディタ」ダイアログ・ボックスで、Read権限のみを設定します。
その他の選択可能な操作に対して権限を設定するには、「権限を付与」リストから操作を選択します。
「OK」をクリックします。
Oracle ADF Securityが有効化されると、デフォルトで、すべてのアプリケーション・リソースが保護されます。つまり、アプリケーション内のページ、イテレータ、属性およびメソッドはセキュアになり、明示的なセキュリティ・ポリシーが必要になります。このため、ADFセキュリティ・ウィザードを実行した後は、適切な権限（たとえば、ページの表示権限）を明示的に付与する必要があります。そうしない場合、セキュリティ違反が発生します。
例10-6について考えてみます。ここでは、各メソッド名がmethod_で始まっています。
例10-6 system-jazn-data.xmlファイル内に定義されたメソッド権限
<principal> <class> oracle.adf.share.security.authentication.ADFRolePrincipal </class> <name>anyone</name> </principal> <permission> <class oracle.adf.share.security.authorization.MethodPermission </class> <name>method_1</name> <actions>invoke</actions> </permission> <permission> <class> oracle.adf.share.security.authorization.MethodPermission </class> <name>method_2</name> <actions>invoke</actions> </permission> <permission> <class> oracle.adf.share.security.authorization.MethodPermission </class> <name>method_3</name> <actions>invoke</actions> </permission> <permission> <class> oracle.adf.share.security.authorization.MethodPermission </class> <name>method_4</name> <actions>invoke</actions> </permission> ...
anyoneロールに起動権限を付与する必要のある個別メソッドがもっと多く存在している可能性があるため、anyoneを起動権限に付与するメソッド・セットを表す正規表現で名前を置き換えることで、ポリシー定義を大幅に簡略化できます。
たとえば、例10-7に示すように、以前の権限リストを単一の権限で置き換えることができます。
例10-7 正規表現を使用したメソッドの権限の定義
<principal> <class> oracle.adf.share.security.authentication.ADFRolePrincipal </class> <name>anyone</name> </principal> <permission> <class oracle.adf.share.security.authorization.MethodPermission </class> <name>method_*</name> <actions>invoke</actions> </permission>
認可エディタではユーザー・インタフェースでの正規表現の使用はサポートされていないため、ポリシー・ストア内で直接ポリシーを編集する必要があります。
|
注意: ポリシーを手動で更新する場合は、次の重要な点について考慮してください。
|
より複雑な正規表現を使用すると、ポリシー内にビジネス・ルールを定義して、非常に限定的な権限セットを作成できます。たとえば、すべてのメソッドに対して起動権限を付与しながら、同時に正規表現内で減算セットを定義することによって特定のメソッドを拒否できます。例10-8に、deleteで始まるメソッド名を除くすべてのメソッドに対してanyoneロールに起動権限を付与する方法を示します。
例10-8 特定のメソッドに対してanyoneロールに起動権限を付与
<principal> <class>oracle.adf.share.security.authentication.ADFRolePrincipal</class> <name>anyone</name> </principal> … <permission> <class>oracle.adf.share.security.authorization.MethodPermission</class> <name>[^(delete)].*</name> <actions>invoke</actions> </permission>
表10-6に、ポリシー定義内で使用できる正規表現の基本的なメタ文字の一部を示します。
ポリシーが存在している場合、認証されていないユーザーは保護されたリソースにアクセスできず、リソースにアクセスしようとすると、セキュリティ例外が発生します。セキュリティ上望ましいのは、ユーザーが、アクセス権を持たないリソースや機能に気づかないようにすることです。
たとえば、ユーザーが管理ページを表示する権限を持たない場合、そのユーザーに対しては、そのページへのすべてのナビゲーション・コンポーネントを動的に削除する必要があります。
アプリケーションはまずポリシーを評価して、ユーザーに適切な権限があるかどうかを判別する必要がありますが、最終的に、保護されたリソースまたは機能（「削除」ボタンなど）にアクセスを試行できるかどうかは、ユーザー・インタフェース（UI）コンポーネントのRenderedプロパティによって制御されます。
デフォルトでは、Renderedプロパティはtrueに設定されています。権限に基づいてこの値を動的に変更することにより、UIコンポーネントの表示/非表示を指定できます。たとえば、ユーザーに適切な権限がある場合は、UIコンポーネントが表示されるように、Renderedプロパティをtrueに設定する必要があります。ユーザーに権限がない場合は、プロパティをfalseに設定する必要があります。この場合、UIコンポーネントはビューに表示されません。
|
注意: ポリシーを評価できるのは、現在のリクエストのみです。したがって、リクエスト・スコープ外でポリシーを評価すると、予期しない結果が発生することがあるため、ポリシー評価がどこで行われるかを理解することが重要です。 |
次の各項では、ELおよびJavaを使用してポリシーを評価する方法について説明します。ELを使用すると、UIで直接ポリシーを評価できます。これに対し、Javaを使用すると、マネージドBean内からポリシーを評価できます。
この項の内容は、次のとおりです。
UI要素内でELを使用すると、プロパティを動的に定義して、実行時にUIコンポーネントを変更できます。リソースを保護する場合、対象となるUIプロパティはrenderedプロパティです。このプロパティを使用すると、開発者は使用可能な権限に基づいてコンポーネントの表示/非表示を指定できます。
ELを使用してポリシーを評価するには、関連付けられた権限タイプ（ページ、メソッド、属性およびイテレータ）に関連するバインディング層（#{bindings...}）内にpermissioninfoメソッドを使用する必要があります。permissioninfoメソッドは、指定されたアクションを実行する権限がユーザーにあるかどうかに基づいて、trueまたはfalseを返します。
ページの場合、ターゲット・ページ定義が引数としてpermissioninfoメソッドに渡されます。これ以外の権限タイプについては、bindings要素の下に、保護されたオブジェクトが明示的に指定されます。
次の表に、ユーザーに権限が関連付けられているかどうかを判別するために必要なELを示します。ユーザーに適切な権限がある場合、EL式はtrueに評価されます。ない場合は、falseが返されます。
表10-7 ページへのアクション権限を判別するためのEL
| 権限のあるアクション | 必要なEL |
|---|---|
|
View |
|
|
Personalize |
|
|
Customize |
|
|
Edit |
|
|
Grant |
|
|
注意: ページ権限の場合、マネージドBean内部に遅延バインディングを使用することにより、ページ定義の値を動的に指定できます。 |
表10-8 メソッドへのアクション権限を判別するためのEL
| 権限のあるアクション | 必要なEL |
|---|---|
|
Invoke |
|
表10-9 イテレータへのアクション権限を判別するためのEL
| 権限のあるアクション | 必要なEL |
|---|---|
|
Read |
|
|
Create |
|
|
Update |
|
|
Delete |
|
表10-10 属性へのアクション権限を判別するためのEL
| 権限のあるアクション | 必要なEL |
|---|---|
|
Read |
|
|
Update |
|
ナビゲーション・コンポーネントのレンダリングを、ターゲット・ページに対してユーザーに付与された権限に関連付ける手順は、次のとおりです。
「設計」ビューで、ナビゲーション・コンポーネントが含まれるページを開きます。
保護されたページにナビゲートするために使用するコンポーネントを選択します。
プロパティ・インスペクタで、Renderedプロパティを選択します。
図10-17に示すように、「データにバインド」アイコンをクリックします。
図10-18に示すように、#{bindings.permissionInfo['managerPagePageDef'].allowsView}というEL式を入力します。この例では、保護されるターゲット・ページはmanagerPageです。
「OK」をクリックします。
アプリケーションを実行します。ユーザーがターゲット・ページを表示できるかどうかに基づいて、コンポーネントがレンダリングされるか、非表示になります。
セッション・スコープのマネージドBeanのELの遅延評価
セキュリティ権限を評価できるスコープは、リクエストに設定されています。リクエストよりも上位レベルまでスコープ設定されたマネージドBean（セッション・スコープのマネージドBeanが基礎となっているグローバル・メニューなど）からターゲット・ページにアクセスするための権限を評価する場合は、遅延EL評価（遅延バインディング）を実装する必要があります。セッション・スコープBeanに対して必要なバインディング情報が使用可能になって初めてELが評価されるようにするには、ターゲット・ページをBeanの管理プロパティとして渡します。ELは、ページが実行されるとすぐに評価されるため、セッション・スコープBeanを基礎としたUIコンポーネントのプロパティ内に直接EL式を配置すると、有効範囲外エラーが発生します。
例10-9に、ユーザーが特定のターゲット・ページを表示できるかどうかに基づいてtrueまたはfalseを返すセッション・スコープBeanのプロパティ（Authorized）を示します。この場合、_targetPageDef変数は、ターゲット・ページの名前が含まれる管理プロパティです。UI内で、ELはbindings.permissionInfoではなくauthorizedプロパティを参照します。
例10-9 セッション・スコープのマネージドBean内の遅延EL評価
public boolean isAuthorized()
{
if (_targetPageDef != null) {
FacesContext ctx = FacesContext.getCurrentInstance();
ValueBinding vb = ctx.getApplication().createValueBinding (
"#{bindings.permissionInfo['" + _targetPageDef + "'].allowsView}" );
if (vb != null) {
Object authResult = vb.getValue(ctx);
return (Boolean) authResult;
}
else {
ctx.addMessage(null, new FacesMessage (
FacesMessage.SEVERITY_WARN, "Access Permission not defined! " , null));
return(true);
}
}
Java内からセキュリティ・ポリシーを評価するには、Oracle ADF SecurityコンテキストのhasPermissionメソッドを使用できます。このメソッドは、（リソースとアクションの組合せにより定義された）権限オブジェクトを取り、ユーザーに対応する権限があればtrueを返します。
例10-10では、ページ名と必要なアクションを渡し、ユーザーの権限に基づいてtrueまたはfalseを返すことのできる、便利な関数が定義されています。この便利な関数がページ権限を確認するため、RegionPermissionクラスを使用して、hasPermissionメソッドに渡される権限オブジェクトを定義しています。
例10-10 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ナビゲーション・アクションの結果を動的に変更できます。例10-11では、1つのコマンド・ボタンがユーザーの権限に応じて異なるターゲット・ページを指していることがわかります。コマンド・ボタンでは、最も高いレベルで保護されているページ（管理者ページ）から最も低いレベルで保護されているページ（パブリックのようこそページ）まで表示権限を確認することにより、適切なアクションを適用して、ユーザーに対して権限レベルに応じたページを表示します。適切なアクションを戻すバッキングBeanは、例10-10に定義されている便利なメソッドを使用しています。
例10-11
//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);
}
WebCenterアプリケーションは純粋なJ2EEアプリケーションなので、ADFセキュリティ・ウィザードがJAASベースのセキュリティを実装するように構成されていても、アプリケーションで使用されるJ2EEセキュリティ・ロールからアイデンティティ管理ソリューション内の対応するロールへのロール・マッピングを定義する必要があります。たとえば、J2EEセキュリティ・ロールValidUsers（前のセクションでADFAuthenticationサーブレットに対して定義されたロール）を、すべてのユーザーを包含する対応するロールにマップする必要があります。ロール・マッピングは、orion-web.xmlファイル内に定義します。Oracle JDeveloperの埋込みOC4J内でアプリケーションを実行すると、アプリケーションがその場所で実行され、実際にコンテナにはデプロイされません。このため、保護されたアプリケーションをOracle JDeveloperの埋込みOC4J内部で直接実行する場合は、デプロイメント・ディスクリプタに関する追加の要件がいくつか発生します。
この項の内容は、次のとおりです。
orion-web.xmlデプロイメント・ディスクリプタ・ファイルを作成する手順は、次のとおりです。
アプリケーション・ナビゲータで、「ViewController」を右クリックし、「新規」を選択します。
一番上のリストから「すべてのテクノロジ」を選択します。
左側のパネルで、「General」を開き、「Deployment Descriptors」を選択します。図10-19に示すように、右側のパネルに様々なタイプの選択可能なデプロイメント・ディスクリプタがリストされます。
「OC4Jデプロイメント・ディスクリプタ・ウィザード」を選択し、「OK」をクリックします。
これにより、OC4Jデプロイメント・ディスクリプタ・ウィザードが起動されます。
「次へ」をクリックして、「ようこそ」ページをスキップします。
「orion-web.xml」を選択し、「次へ」をクリックします。
ファイルがすでに存在する場合は、ファイル名がグレー表示されます。
「10.0」を選択し、「終了」をクリックします。
orion-web.xmlが、アプリケーション・ナビゲータで、「ViewController」、「Webコンテンツ」、「WEB-INF」の下に表示されます。
アプリケーション内に定義したJ2EEセキュリティ・ロールをアイデンティティ・ストア・ロールにマップする手順は、次のとおりです。
|
注意: 少なくとも、ADFAuthenticationサーブレットを保護するセキュリティ制約に関連付けられたJ2EEセキュリティ・ロールについては、マッピングを定義する必要があります。 |
この項では、J2EEセキュリティ・ロールValidUsersをアイデンティティ・ストア・ロールusersにマップする例を使用します。次の手順で、orion-web.xml内にセキュリティ・ロール・マッピングを構成します。
「orion-web.xml」を右クリックし、「プロパティ」を選択して、追加のデプロイ・オプションを設定します。
左側のパネルで、「セキュリティ・ロール・マッピング」を選択します。すると、図10-20に示すように、右側にパネルが表示されます。このパネルで、これらのセキュリティ・ロール・マッピングを追加できます。
図10-20 「OC4J Webアプリケーション・デプロイメント・ディスクリプタ」ダイアログ・ボックス
次の手順で、セキュリティ・ロール・マッピングを作成します。
「追加」をクリックします。これにより、図10-21に示すようなウィンドウが表示されます。
「名前」には、J2EEセキュリティ・ロール名ValidUsersを入力します。
「OK」をクリックします。図10-22に示すように、入力したロール名が、マッピング・パネル内と「一般」タブに表示されます。ロール名を編集するには、「一般」タブの「名前」プロパティを使用します。
「グループ」タブをクリックします。マッピング・パネル内で、J2EEセキュリティ・ロールValidUsersが強調表示されていることに注意してください。これは、usersグループをこのJ2EEセキュリティ・ロールにマップするということです。
「グループ名」パネルの右側にある「追加」ボタンをクリックします。図10-23に示すような「グループ」ダイアログ・ボックスが表示されます。
「グループ名」に、usersを入力します。
「OK」をクリックします。
この手順では、J2EEセキュリティ・ロールValidUsersをアイデンティティ・ストア・ロールusersにマップしました。このマッピングを図10-24に示しています。
「OK」をクリックして、OC4Jデプロイメント・ディスクリプタへの変更を保存します。
構成ファイルorion-web.xmlのソース・コードを調べると、security-role-mappingエントリは次のようになっています。
<security-role-mapping name="ValidUsers" impliesAll="false"> <group name="users"></group> </security-role-mapping>
これで、リモート・アプリケーション・サーバーへのデプロイに必要なOC4J Webアプリケーションのデプロイメント・ディスクリプタの構成は完了です。埋込みOC4J内でアプリケーションを実行するには、次の項で説明する追加の構成を実行する必要があります。
WebCenterアプリケーションをリモート・アプリケーション・サーバーにデプロイするには、JAZN移行ツールおよびデプロイ前ツールを実行する必要がありますが、Oracle JDeveloperの埋込みOC4Jを使用すると、アプリケーションを直接実行できます。アプリケーションをリモート・アプリケーション・サーバー（またはスタンドアロンOC4J）にデプロイするとき、必要なJAASモードは、ADFセキュリティ・ウィザードによって構成されたorion-application.xmlデプロイメント・ディスクリプタ・ファイルから判別されます。ただし、Oracle JDeveloperの埋込みOC4Jでアプリケーションを実行するときは、orion-web.xmlデプロイメント・ディスクリプタ・ファイル内にもJAAS情報を指定する必要があります。この情報をorion-web.xmlファイルに追加しない場合、セキュリティはデプロイされたサーバーに対して強制設定されますが、埋込みOC4J内でアプリケーションを実行した場合にはこれが反映されません。埋込みOC4J内で実行するときにセキュリティを強制設定する手順は、次のとおりです。
「orion-web.xml」を右クリックし、「プロパティ」を選択して、追加のデプロイ・オプションを設定します。
左側のパネルで、「JAZN」を選択します。これにより、複数のJAAS認証オプションが表示されます。
図10-25に示すように、「Run asモード」および「権限モードとして実行」を選択します。
「Run asモード」オプションは、サーブレットが特別な権限を持つことを指定し、「権限モードとして実行」オプションは、許可される権限を指定します。
両方のオプションを設定すると、次の行がorion-web.xmlに追加されます。
<jazn-web-app runas-mode="true" doasprivileged-mode="true"/>
この項では、アプリケーション内のどのページにも追加できる標準的なログイン・コンポーネントを作成して、ユーザーの認証または以降のログオフを可能にします。このコンポーネントは、ユーザーの認証状態を追跡し、適切なログインまたはログアウトのURLおよびアイコンを返します。さらに、現在のユーザーの名前（匿名またはログインしているユーザーの名前）を追跡します。このため、このログイン・コンポーネントを使用すると、開発者は一貫性のある単一のオブジェクトを開発できます。図10-26に、Oracle ADFアプリケーション・ページのグローバル・メニュー・ファセットに追加されたログイン・アイコンを示します。
このログイン・コンポーネントは、ユーザーの認証後、ユーザーを現在のページにリダイレクトします。
|
注意: 現在のページがパブリックにアクセス可能でない場合はようこそページにリダイレクトするように、コンポーネントのコードを変更する必要があることもあります。 |
ログイン・コンポーネントを作成する手順は、次のとおりです。
アプリケーションの「ViewController」プロジェクトを開きます。
アプリケーション・ナビゲータで、「WEB-INF」ノードを開き、「faces-config.xml」ファイルを開きます。
構造ウィンドウで、「概要」タブを選択します。
「Managed Bean」を右クリックし、「マネージドBeanの挿入」を選択します。「マネージドBeanの作成」ダイアログ・ボックスが表示されます。
図10-27に示すように、「名前」に「authNLink」、「クラス」に「view.util.AuthNLink」を指定し、「有効範囲」を「セッション」に設定します。「クラスが存在しない場合は生成」を選択します（まだ選択されていない場合）。
「OK」をクリックし、「アプリケーション・ソース」の下の「view.util.AuthNLink.java」ファイルを開きます。
次の例のように、次のプライベート変数をマネージドBean定義に追加します。
public class AuthNLink {
private boolean _authenticated = false;
private String _label = null;
private String _icon = null;
private String _url = null;
private String _currentUser = null;
「ソース」メニューから、「アクセッサの生成」を選択します。
図10-28に示すように、各ノードを開き、getterメソッド（isおよびgetで始まるメソッド）を確認します。
例10-12に示すように、メソッドを定義します。
|
注意: 要求されたら、カーソルを適切な行の上に置いて[Alt]を押しながら[Enter]を押すことにより、ADFContextおよびFacesContextをインポートします。 |
この例には、固定の英語ラベルがあります。コードを国際化するには、これらの文字列をリソース・バンドル内に定義できます。国際化の詳細は、『Oracle Application Development Framework開発者ガイド』の「アプリケーションの国際化」を参照してください。
例10-12 ログイン・コンポーネントのコード
// ============ User's Authenticated Status =============
public boolean isAuthenticated() {
_authenticated =
ADFContext.getCurrent().getSecurityContext().isAuthenticated();
return _authenticated;
}
// ================== Link Label =======================
public String getLabel()
{
// toggle link text based on authenticated state of the user.
if (isAuthenticated())
{ _label = "Click here to log in"; }
else
{ _label = " Click here to log out"; }
return _label;
}
// ================== Link Icon =======================
public String getIcon() {
// toggle icon based on authenticated state of the user.
if (isAuthenticated())
_icon = "logout.gif";
else
_icon = "login.gif";
return (_icon);
}
// ================== Link URL =======================
public String getUrl()
{
String currentPage = null;
String urlBaseRef = null;
String urlBaseRef2 = null;
FacesContext fctx = FacesContext.getCurrentInstance();
currentPage = "/faces" + fctx.getViewRoot().getViewId();
if (isAuthenticated())
_url = "/adfAuthentication?logout=true&end_url=" + currentPage;
else
_url = "/adfAuthentication?success_url=" + currentPage;
return (_url);
}
// ============ Current User's Name/PrincipalName =============
public String getCurrentUser() {
_currentUser = ADFContext.getCurrent().getSecurityContext().getUserName();
return _currentUser;
}
このコードでは、コンポーネントは、Oracle ADF SecurityコンテキストのisAuthenticatedメソッドを使用して、ユーザーが現在認証されているかどうかを判別し、それに応じてリンク・テキスト、リンク・テキストURL、および関連付けられたアイコンを変更します。
ログインおよびログアウトのイメージ・ファイル（GIF、JPGまたはPNGファイル）を、プロジェクトのpublic_htmlディレクトリにコピーします。
|
注意: アプリケーションでスキンを使用する場合は、使用されるイメージが適切なスキン・イメージを参照している必要があります。スキンの詳細は、第9章「カスタマイズ可能コア・コンポーネントのスタイルの定義および適用」を参照してください。 |
ページへのログイン・コンポーネントの追加
ログイン・コンポーネントをページに追加する手順は、次のとおりです。
Oracle ADF Facesページを作成します。詳細は、4.2項「Oracle ADFを使用したOracle JDeveloperでのWebCenterアプリケーション対応ページの構築」を参照してください。
「設計」ビュー内にページを開きます。
コンポーネント・パレットから、「ADF Faces Core」を選択します。
menuButtonsコンポーネントを選択してページ上にドラッグします。
|
注意: Oracle ADFのPanelPageコンポーネントを使用してページをレイアウトする場合、ログイン・リンクなどのグローバル・ナビゲーション・アイテムをmenuGlobalファセット内に配置する必要があります。これにより、ページ上の一貫性のある場所（デフォルトではページの右上隅）にリンクが配置されます。 |
「goMenuItem」を選択し、MenuButtonsコンポーネントにドラッグします。
プロパティ・インスペクタで、goMenuItemのText、DestinationおよびIconプロパティを次の表の値に設定します。
| プロパティ | 値 |
|---|---|
| Text | #{authNLink.label} |
| Destination | #{authNLink.url} |
| Icon | #{authNLink.icon} |
これらのプロパティを設定するには、「データにバインド」ダイアログ・ボックスで「JSFマネージドBean」の下の「authNLink」ノードにナビゲートし、表に指定されている値を設定します。「データにバインド」ダイアログ・ボックスには、次のいずれかの方法でアクセスできます。
「構造」ペインで「goMenuItem」を右クリックし、「プロパティ」をクリックします。「プロパティ」ダイアログ・ボックスで、プロパティの隣の「データにバインド」アイコンをクリックします。
プロパティ・インスペクタで、プロパティの隣のフィールド内の「データにバインド」アイコンをクリックします。
図10-29に「データにバインド」ダイアログ・ボックス内のTextプロパティの設定を示し、図10-30にDestinationプロパティの設定を示します。
ログイン・コンポーネントによって現在のユーザーが追跡されるため、ページ上にユーザーの名前を表示することもできます。このためには、コンポーネント・パレットから「ADF Faces Core」を選択し、「OutputFormatted」コンポーネントをページにドラッグします。
OutputFormattedの値を「The Current User is <i>#{authNLink.currentUser}</i>」に設定します。
ページを保存し、実行します。ページは図10-31のように表示されます。
|
注意: アプリケーション内にセキュリティを強制設定するには、まず、10.2項「アプリケーションのセキュリティの設定」の手順を実行する必要があります。少なくとも、anyoneロールに表示権限を付与する必要があります。 |
「ログイン」をクリックし、適切な資格証明を持つユーザーとしてログインします。ログイン後、ページは図10-32のように表示されます。
この項では、ユーザーが認証のためにリダイレクトされる新しいログイン・ページを作成します。通常、WebCenterアプリケーションにはパブリック・ページの概念が採用され、暗黙的認証と同様に明示的認証が可能です。これは、ユーザーが、保護されたコンテンツにナビゲートする前にログイン・リンクをクリックしてアプリケーションにログインできる（明示的認証）、またはユーザーをアプリケーションのログイン・ページにリダイレクトする保護されたページにナビゲートできる（暗黙的認証）ということです。暗黙的認証および明示的認証の詳細は、10.1項「WebCenterアプリケーションのセキュリティの概要」を参照してください。図10-33に、この章で構築するサンプルのログイン・ページを示します。ログイン・ページにポートレットを追加すると、ログイン・ページそのものとWebCenterアプリケーション内の他のページとを区別できないようにすることができます。
|
注意: この項では、カスタマイズ可能コンポーネントおよびポートレットを含めることのできるOracle ADF Facesベースのログイン・ページを作成する方法を説明します。ただし、これらのコンポーネントを追加する必要がなければ、単純なJSPまたはHTMLログイン・ページを使用してもかまいません。コンテナ・ベースの認証は、コンテナのセキュリティ・モデル内の 単純なログイン・ページを構築する方法の詳細は、『Oracle WebCenter Frameworkチュートリアル』の「手順1: ログイン・ページの作成」を参照してください。 |
アプリケーションのログイン・ページを作成するには、次の作業を実行する必要があります。
Oracle ADF Facesベースのログイン・ページを作成する手順は、次のとおりです。
アプリケーション・ナビゲータで、「ViewController」プロジェクトの下のアプリケーションを右クリックし、「新規」を選択します。
「新規ギャラリ」ダイアログ・ボックスで、「Web Tier」ノードを開きます。
「JSF」を選択します。
「項目」リストで「JSF JSP」を選択します。
「OK」をクリックして、「JSF JSPの作成」ダイアログ・ボックスを表示します。
ウィザードの「ようこそ」ページが表示されたら、「次」をクリックして「JSPファイル」ページを表示します。
「ファイル名」フィールドで、ログイン・ページの名前を指定します。たとえば、ADFLogin.jspxを指定します。
「JSPドキュメント(*.jspx)」を選択します。
「次へ」をクリックして、「コンポーネント・バインディング」ページを表示します。
「新規マネージドBeanでのUIコンポーネントの自動公開」を選択します。
「次へ」をクリックして「タグ・ライブラリ」ページを表示し、「すべてのライブラリ」を選択します。
「選択済のライブラリ」に次のライブラリがリストされていることを確認します。
JSF Core
JSF HTML
ADF Faces Components
ADF Faces HTML
ADFポートレット・コンポーネント
カスタマイズ可能コンポーネント・コア
「終了」をクリックして、ページを作成します。
ページを保存します。
コンポーネント・パレットから、「カスタマイズ可能コンポーネント・コア」を選択します。
「PanelCustomizable」を選択し、「構造」ペインの「h:form」ノードの上にドラッグします。「PanelBox」内にカスタムHTMLフォームを作成しようとしているので、「フォーム要素追加の確認」ダイアログ・ボックスで「いいえ」をクリックします。
プロパティ・インスペクタで、PanelCustomizableのレイアウトをHorizontalに設定します。
図10-34に示すように、「構造」ペインで、「h:form」ノードを「cust:panelCustomizable」ノードにドラッグします。
コンポーネント・パレットを開き、「ADF Faces Core」を選択して、「PanelBox」を「構造」ペイン内の「h:form」タグの上にドラッグします。図10-35に示すように、PanelBoxのTextプロパティをLoginに設定します。
OutputTextコンポーネントを選択し、PanelBoxコンポーネントにドラッグします。
ページを保存します。
次の項では、バッキングBeanによってこのPanelBox領域に適切なログイン・フォームを挿入する方法を示します。
Oracle ADF Facesページとしてログイン・ページを作成したので、コンポーネント・パレットからform要素を使用してログイン・フォームを追加することはできません。これを行うと、Oracle ADF Facesライフサイクルにより実行時にform要素がシリアライズされて、再マップされます。正しくは、バッキングBeanにHTMLを追加して実行時にこれを動的に表示するという方法で、実行にログイン・フォームのHTMLを挿入します。バッキングBeanにHTMLコードを追加し、ログイン・ページ内でHTMLログイン・フォームを参照する手順は、次のとおりです。
アプリケーション・ナビゲータで、「アプリケーション・リソース」ノードを開き、<Page_Name>.javaバッキングBean（ADFLogin.javaなど）を開きます。
Beanの_loginFormBlockを定義するには、ADFLogin.javaファイルの宣言セクション内に次のコードを追加することにより、新しい属性を作成します。
private String _loginFormBlock;
例10-13に示すように、この属性のgetメソッドを、このJavaクラス内の閉じカッコ（}）の直前に追加します。
例10-13 ログイン・ページにログイン・フォームを挿入するLoginFormBlockコード
public String getLoginFormBlock()
{
String htmlBlock = null;
String userNameLabel = "Username";
String passwordLabel = "Password";
String buttonLabel = "Login";
htmlBlock = "\n\n" +
"<!-- === Login Form Block Generated in Backing Bean ==== -->\n" +
"<form name=\"LoginForm\" id=\"LoginForm\" \n" +
" action=\"j_security_check\" method=\"POST\" >\n" +
" <table cellspacing=\"5\" cellpadding=\"0\" border=\"0\" width=\"50%\">\n" +
" <tr>\n" +
" <td nowrap>" + userNameLabel + "</td>\n" +
" <td nowrap><input type=\"text\" name=\"j_username\"/></td>\n" +
" </tr>\n" +
" <tr>\n" +
" <td nowrap>" + passwordLabel + "</td>\n" +
" <td nowrap><input type=\"password\" name=\"j_password\"/></td> \n" +
" </tr>\n" +
" <tr>\n" +
" <td><input type=\"submit\" value=\"" + buttonLabel + "\"/></td> \n" +
" </tr>\n" +
" </table>\n" +
"</form>\n" +
"<!-- ================================================= -->\n\n" ;
_loginFormBlock = htmlBlock;
return (_loginFormBlock);
}
このコードにより、ログイン・ブロック全体が単純な出力文字列として返されます（<verbatim>タグの必要性が簡略化されます）。
Javaファイルを保存します。
図10-36に示すように、プロパティ・インスペクタで、前に作成したoutputTextオブジェクトの値をloginFormBlock属性の次の値に設定します。
#{backing_ADFLogin.loginFormBlock}
これにより、図10-37に示すように、ページ内に文字列全部がテキストとして表示されます。
図10-38に示すように、outputTextオブジェクトのEscapeプロパティをFalseに設定して、静的HTMLを文字列としてレンダリングします。
ファイルを保存します。
この手順はオプションですが、WebCenterアプリケーションにOracle ADF Facesベースのログイン・ページを使用すると、ページにポートレットを追加して、カスタマイズ可能な情報をページに追加したり、この情報をアプリケーションそのものの一部にすることができるというメリットがあります。この例では、リッチ・テキスト・ポートレットおよびOmniPortletをログイン・ページに追加します。詳細は、14.3.1項「リッチ・テキスト・ポートレット」および14.3.4項「OmniPortlet」を参照してください。
続行前に、ポートレット・プロデューサが登録されていることを確認します。詳細は、4.3.1.1項「WSRPポートレット・プロデューサの登録」および4.3.1.2項「PDK-Javaポートレット・プロデューサの登録」を参照してください。
ポートレットをログイン・ページに追加する手順は、次のとおりです。
「PanelCustomizable」を「構造」ペイン内の「h:form」タグの上にドラッグします。
コンポーネント・パレットから、リッチ・テキスト・ポートレット・プロデューサを選択し、リストからリッチ・テキスト・ポートレットを選択して「PanelCustomizable」コンポーネントの上にドラッグします。
コンポーネント・パレットから、「ADF Faces Core」を選択し、「ObjectSeparator」をリッチ・テキスト・ポートレットの下の「PanelCustomizable」コンポーネントの上にドラッグします。
コンポーネント・パレットから、OmniPortletプロデューサを選択し、リストからOmniPortletを選択して「PanelCustomizable」コンポーネントの上にドラッグします。
ページを保存します。ページは図10-39のように表示されます。
ログイン・プロセスの一部としてコンテナからログイン・ページが呼び出されるため、適切なポートレットおよびセキュリティのコンテキストを確立するために、リクエストをADFバインディング・フィルタに転送する必要があります。このためには、web.xmlファイル内でADFバインディング・フィルタのマッピングを構成する必要があります。そのための手順は、次のとおりです。
アプリケーション・ナビゲータで、「WEB-INF」ノードを開き、「web.xml」を右クリックし、「プロパティ」を選択してプロパティ・パレットを開きます。
左パネル内で「フィルタ・マッピング」を選択し、「add」をクリックして、adfBindingsフィルタに新しいマッピングを定義します。これにより、「Webアプリケーション・フィルタ・マッピングの作成」ダイアログ・ボックスが表示されます。
フィルタ名として「adfBindings」を指定し、「サーブレット名」オプションをクリックし、サーブレット名としてFacesサーブレットを指定します。図10-40に示すように、ディスパッチャ・タイプとして「フォワード」および「インクルード」が選択されていることを確認します。
「OK」をクリックします。
ログイン・ページはコンテナから直接呼び出されるため、Oracle ADF Facesナビゲーション・プロセスの一部とはなっていません。このため、ログイン・ページを呼び出すときは、Oracle ADF Facesサーブレットを強制的に呼び出す必要があります。そのための手順は、次のとおりです。
アプリケーション・ナビゲータで、「WEB-INF」ノードを開き、「web.xml」を右クリックし、「プロパティ」を選択してプロパティ・パレットを開きます。
「プロパティ」パネルで、「ログイン構成」をクリックします。
図10-41に示すように、「ログイン・ページ」の値を設定してOracle ADF Facesサーブレットへの参照を追加し、ログイン・ページがOracle ADF Facesライフ・サイクルfaces/ADFlogin.jspxページの一部となるようにします。
「OK」をクリックして、web.xmlへの変更を保存します。
アプリケーションがOracle ADF Securityによって保護されているので、アプリケーション内のすべてのページは保護されています。このため、これらのページに対して明示的なポリシーを定義する必要はありません。すべてのユーザーがログオンできることが必要なので、ログイン・ページはパブリックにアクセス可能にする必要があります。ページがパブリックとして定義されていない場合は、ページ（この場合は認証ページ）へのアクセスが許可される前に、コンテナにより常に定義済の認証ポイントにリダイレクトされることになります。
特定のロールを持つユーザーが特定のアクションを実行できるように、ログイン・ページに適切な権限を定義する必要があります。たとえば、すべてのユーザー（ロールanyone）は、ページを表示できる必要があります。また、ポートレットを編集する必要のある特定のユーザーは、ログイン・ページのカスタマイズ権限を持つ必要があります。
|
注意: アプリケーション内にセキュリティを強制設定するには、まず、10.2項「アプリケーションのセキュリティの設定」の説明に従って、アプリケーションにセキュリティ・インフラストラクチャを構成する必要があります。 |
ログイン・ページにアクセス・ポリシーを定義する手順は、次のとおりです。
アプリケーション・ナビゲータで、「ADFLogin.jspx」を右クリックします。
「ページ定義に移動」を選択します。
新しいページ定義の作成を要求されたら、「はい」をクリックします。ページ定義ファイルが「構造」ペイン内に開きます。
ページ定義ファイルを右クリックし、「認可の編集」を選択します。これにより、認可エディタが表示されます。
anyoneにView権限を付与します。
「OK」をクリックします。
ログイン・ページにはカスタマイズ可能なポートレットが含まれるため、適切なロールにページのCustomize権限を付与する必要があります。
ログイン・ページにカスタマイズ可能なポートレットが含まれ、適切な権限を持つユーザー・グループがそのポートレットを編集する場合、アプリケーションの内部（管理ページなど）からもログイン・ページにアクセスできるようにする必要があります。その場合、ユーザーは、コンテナから直接ページにダイレクトされるのではなく、標準的なOracle ADF Facesナビゲーションを介してページにダイレクトされます。この場合、ログイン・コンポーネントは意味を持たないため、認証されたユーザーがログイン・フォームを誤って再び送信することがないよう、非表示にする必要があります。図10-42に、認証されたユーザーに表示されるログイン・ページを示します。
前に作成したADFLogin.jspxページで「PanelBox」をクリックし、ユーザーが現在認証されている場合はrenderedプロパティをfalseに設定します。このためには、図10-43に示すように、authNLinkマネージドBeanのauthenticatedプロパティを使用します。
認証されたユーザーがログイン・ページにアクセスできるように、ナビゲーション・ケースがfaces-config.xmlファイル内に定義されていることを確認します。次に、アプリケーション内に適切なOracle ADF Facesナビゲーション・コンポーネントを使用して、ログイン・ページにナビゲートしてカスタマイズできるようにします。ページを保存し、アプリケーションを実行します。
WebCenterアプリケーションは通常は保護されているため、認証されていないユーザーのための開始ポイントまたはホームページを用意する必要があります。このようなパブリックのようこそページを作成するには、アプリケーションの入口点となるOracle ADF Facesページを作成し、アプリケーション内の他のページへのリンクを追加します。ただし、認証されていないユーザーにはパブリック・ページのみがレンダリングされるようにします。逆に言えば、ターゲット・ページの適切な表示権限を持っているユーザーがログインして初めて、保護されたページへのリンクがレンダリングされるようにします。
アプリケーションのパブリック・ページを作成する手順は、次のとおりです。
4.2項「Oracle ADFを使用したOracle JDeveloperでのWebCenterアプリケーション対応ページの構築」の説明に従って通常のOracle ADF Facesページを作成した後は、すべてのユーザー（認証されたユーザーと認証されていないユーザーの両方）がページにアクセスできるように設定する必要があります。このためには、次の手順を実行する必要があります。
ようこそページ（welcome.jspxなど）を右クリックし、ページ定義に移動します。要求されたら、新しいページ定義を作成します。
「構造」ペインで、ページ定義を右クリックし、「認可の編集」を選択します。認可エディタが表示されます。
ロールanyoneにView権限を付与します。
必要に応じて、Customize権限およびPersonalize権限を付与します。
「OK」をクリックして、ページを保存します。
これにより、system-jazn-data.xmlファイル内でanyoneロールに表示権限が追加されます。Oracle ADF Securityによって保護されているアプリケーションでは、各ユーザーは自動的にこの擬似ロールのメンバーになります（anyoneロール・プリンシパルがユーザーのサブジェクトに自動的に追加されます）。したがって、パブリック・ページは、誰にでも使用可能な、特殊なタイプの保護されたページです。これに対し、J2EEセキュリティでは、パブリック・ページの定義はセキュリティ制限が設定されていないというだけのことです。このように、Oracle ADF Securityモデルでは、パブリック・アクセス用の保護されたページと、保護された実装がないということは区別されています。
パブリックのようこそページにログイン・リンクおよびログアウト・リンクを追加すると、ユーザーがアプリケーションの使用中に明示的にログインおよびログアウトできます。J2EEコンテナ管理セキュリティでは、保護されたリソースにアクセスする際の認証という概念はサポートされていますが、保護されたアプリケーションからログアウトしたり、アプリケーションにとどまるための標準的な方法は備わっていません。しかし、このような操作は、WebCenterアプリケーションにおいて一般的です。そのページがパブリックであればページは変わらず、そのページが保護されていればようこそページに戻ります。各ページにログイン・リンクおよびログアウト・リンクを追加すると、ユーザーはアプリケーションのどのページからでもログイン・セッションを終了する（ようこそページに戻る）ことができますが、ようこそページにこれらのリンクを設定すると、ユーザーはアプリケーションにログインするときに明示的に認証できます。
10.3項「アプリケーションのログイン・コンポーネントの作成」の説明に従って、ログイン・リンクおよびログアウト・リンクを追加するには、ログイン・コンポーネントをアプリケーションに追加してから、ログイン・リンクおよびログアウト・リンクをページに追加する必要があります。
保護されたページに匿名ユーザーがアクセスできないように、ようこそページ上の保護されたページへのナビゲーション・コンポーネントを、次の2つの基準に基づいてビューから非表示にする必要があります。
ユーザーが既知のユーザー・アイデンティティで認証されているか
指定されたユーザー・アイデンティティがターゲットの表示権限を持っているか
このいずれかの基準が満たされていない場合は、パブリック・ページ上の保護されたリソースへのナビゲーション・コンポーネントのrendered属性は、renderedプロパティをfalseに設定して、匿名ユーザーに対して非表示にする必要があります。ようこそページ内にこれらのルールを強制設定するには、10.2.4項「アプリケーションでのセキュリティ・ポリシーの強制設定」を参照してください。
ポートレット・パーソナライズは、特定の認証されたユーザーに関連付けられています。このため、編集モードを備えたポートレットを実行すると、ポートレットのドロップダウン・メニューの「パーソナライズ」オプションは、認証されたアプリケーション・ユーザーにのみ表示されます。匿名ユーザーまたはパブリック・ユーザーには、ポートレットをパーソナライズするためのオプションはありません。ポートレットやページを作成する開発者の場合、アプリケーション用の完全なセキュリティ・モデルを作成せずに、ポートレットの編集モードをすぐにテストすることが必要になる場合があります。このようなテストを実行するには、アプリケーションにごく基本的な認証を構成してから、テストの完了後にその認証を削除すれば簡単です。
|
注意: この手順は、編集モードを備えたすべてのポートレット（Omniportlet、Webクリッピング、JPSおよびPDK-Java）に有効です。 |
10.2.1項「保護されたWebCenterアプリケーションを開発するためのロールの定義」の説明に従って、ユーザーskingおよび管理者ロールを作成します。
10.2.2項「アプリケーションのセキュリティの構成」の説明に従って、ADFセキュリティ・ウィザードを使用してアプリケーションを保護します。ウィザードの「ログイン」ページで、「HTTP Basic認証(RFC 2617)」を選択します。これにより、アプリケーションで基本認証を使用することが指定されます。
10.2.3.2項「アプリケーション内のページの保護」の手順を実行して、ポートレットが含まれるページを保護します。
10.2.5.1項「デプロイメント・ディスクリプタ・ファイルの作成」の説明に従って、orion-web.xmlファイルを作成して、埋込みOC4J内でアプリケーションを実行します。
埋込みOC4J内でアプリケーションを実行し、有効なユーザーとしてログインして、ポートレットの編集モードをテストします。
ポートレットの編集モードのテストが完了したら、次の手順を実行すると、このテスト・セキュリティをすばやく削除できます。
アプリケーション・ナビゲータで、テストするポートレットが含まれるページが属するプロジェクトをクリックします。
「ツール」メニューから、「ADFセキュリティ・ウィザード」を選択します。
「ようこそ」ページが表示されたら、「次へ」をクリックします。
「すべてのADFセキュリティ設定の削除」を選択します。
ウィザードの「終了」ページが表示されるまで、「次へ」をクリックします。「終了」をクリックします。セキュリティが削除されます。セキュリティが削除されたことを確認する場合は、ブラウザを終了してからアプリケーションを再実行します。ページにアクセスすると、ログインを要求されず、ポートレットのドロップダウン・メニューに「パーソナライズ」オプションが表示されないはずです。
Oracle PDKポートレット・プロデューサの実装が、独自の認証を処理するアプリケーションを基礎にしている場合、そのアプリケーションをプロデューサと関連付ける必要があります。設計時にこれを行うには、外部アプリケーションを登録し、Oracle PDKポートレット・プロデューサを登録または編集するときにリストから外部アプリケーションを選択するだけです。
Oracle WebCenter Suiteには、外部アプリケーションをWebCenterアプリケーションに登録し、外部アプリケーションへのログイン用の資格証明プロビジョニング・ページを追加する方法が備わっています。資格証明プロビジョニング・ページの詳細は、10.1.3項「外部アプリケーションの資格証明およびポートレット」を参照してください。
|
注意: このリリースでは、WebCenterアプリケーションの外部アプリケーション・サポートは、ポートレットでの用途に限られています。つまり、ポートレットはアプリケーションに設定されているユーザーの格納済資格証明を返し、それを使用してリモート・アプリケーションに対してユーザーを認証できます。しかし、ポートレットから外部アプリケーションに直接リンクすることは、今のところサポートされていません。たとえば、WebCenterアプリケーション・ページ上のリンクから外部アプリケーションを起動することはできません。外部アプリケーションを使用するように開発されたポートレットでは、外部アプリケーションへのダイレクト（ディープ）リンクを使用していないことを確認することが重要です。これを使用すると、認証リクエストが発生しますが、ログインURLがポートレットに送信されません。自動のプロキシ・シングル・サインオンがないために、このような状態が発生します。可能な場合、ポートレットでインライン・レンダリング・モデルを使用することをお薦めします。このモデルでは、外部アプリケーションのURLは、ポートレットのフレームワークを介してアクセスされます。 |
この項では、外部アプリケーションの登録、および資格証明プロビジョニング・ページの追加について説明します。また、登録詳細の編集および削除のプロセスについても説明します。この項の内容は、次のとおりです。
この項では、外部アプリケーションの登録と、登録詳細の編集および削除について説明します。この項の内容は、次のとおりです。
外部アプリケーションの登録ウィザードを使用して、外部アプリケーションへの認証に必要なデータ・タイプ（ログイン名など）を指定し、その情報を格納します。
外部アプリケーションを登録する手順は、次のとおりです。
アプリケーション・ナビゲータで、WebCenterアプリケーションまたはプロジェクトを右クリックし、ポップアップ・メニューから「新規」を選択します。
「新規ギャラリ」で、「General」ノードの下の「External Applications」を選択します。
右ペインで「外部アプリケーション」を選択し、「OK」をクリックします。
これにより、外部アプリケーションの登録ウィザードが開きます。
「ようこそ」ページで、「次へ」をクリックして、「名前」ページに移動します。
オプションで、「ようこそ」ページの先に進む前に、「次回にこのページを表示しない」チェック・ボックスを選択すると、次回からこのウィザードを使用するときに「ようこそ」ページは表示されません。
「名前」ページの「名前」フィールドに、アプリケーションを識別する一意の名前を入力します。
この名前は、WebCenterアプリケーション内で一意である必要があります。
「次へ」をクリックします。
「一般」ページの「ログインURL」フィールドに、HTMLログイン・ページの送信先のURLを入力します。
このURLを取得するには、アプリケーションのログイン・フォームのHTMLソースを表示します。
|
注意: デプロイ前ツールでは、事前デプロイの段階で外部アプリケーション・データを変更することはできません。このため、外部アプリケーションが別のコンピュータまたはインスタンス上に存在している場合は、WebCenterデプロイメント・プロファイルからEARファイルを作成する直前に、外部アプリケーション・ログインURLを更新する必要があります。ログインURLの最初の部分を、http://m1.abc.com:7777/から（たとえば）http://lbr.abc.com/に変更します。 |
「ユーザー名/IDフィールド名」フィールドに、アプリケーションでユーザー名フィールドに使用されるラベル（User Nameなど）を入力します。
「パスワード・フィールド名」フィールドに、アプリケーションでパスワード・フィールドに使用されるラベル（Passwordなど）を入力します。
「認証方式」リストから、アプリケーションのログイン方式を選択します。
次のうちから選択します。
GET
サーバーにページ・リクエストを送信します。ログインURLの一部としてログイン資格証明を送信します。
POST
フォーム本体内でログイン資格証明を送信します。
BASIC
ログインURLの一部としてログイン資格証明を送信します。Basic認証方式では、特定のインスタンス内にユーザー名とパスワードが公開されるため、セキュリティ・リスクが存在することに注意してください。
「次へ」をクリックします。
「追加フィールド」ページで、外部アプリケーションのログイン・フォームとともに送信される追加フィールドの名前および値を入力します。
「フィールドの追加」ボタンをクリックして、新しい入力フィールドを作成します。
フィールド名
外部アプリケーションのHTMLログイン・フォームへのユーザー入力を必要とする追加フィールドに対して一意の名前を入力します。
フィールド値
対応するフィールド名のデフォルト値を入力します。
ユーザーに表示
これを選択すると、フィールドが外部アプリケーションのログイン画面に表示されます。フィールドを表示しない（選択しない）場合、すべてのユーザーで外部アプリケーションへのログインに使用されるデフォルト値を指定する必要があります。値がユーザー固有の場合、フィールドはそのユーザーに表示される必要があります。ユーザーは、外部アプリケーションの資格証明プロビジョニング・ページで、このフィールドの値を入力できます。
|
注意: 「フィールドの削除」オプションを使用すると、選択した行を削除できます。 |
「OK」をクリックして、外部アプリケーションを登録します。
外部アプリケーションを登録した後は、プロデューサをアプリケーションに関連付ける必要があります。これは、Oracle PDK-Javaポートレット・プロデューサの登録時または編集時に実行できます。関連する設定には、「接続」タブの「プロデューサと外部アプリケーションとの関連付け」、プロデューサの「登録の詳細」タブの「プロデューサ・セッションの有効化」（外部アプリケーションの場合、このプロパティは自動的に有効化される）などがあります。詳細は、4.3.1.2項「PDK-Javaポートレット・プロデューサの登録」を参照してください。
|
注意: 外部アプリケーション認証を必要とするプロデューサを登録したのに、このプロデューサを外部アプリケーションと関連付けない場合、このプロデューサからJSF JSPページにポートレットを追加してページを実行すると、次のエラーで、（外部アプリケーション認証を必要とする別のプロデューサ用に作成された）資格証明プロビジョニング・ページへのログイン資格証明の更新リンクが表示されることがあります。1. External application ID was found to be null while rendering the Credential Provisioning page! 2. Cause: The credential page was probably run standalone. 3. Action: The credential page needs to be invoked from the link in portlets, from producers associated with the external application. Running the credential page standalone is not supported. |
外部アプリケーションの登録後、資格証明プロビジョニング・ページを作成します。このページを使用すると、外部アプリケーションの認証データ・フィールド（つまり、ログイン・ページ）を動的に表示できます。また、外部アプリケーションのポートレットを使用するアプリケーションでは、（資格証明プロビジョニング・ページも含めて）アプリケーション・ページを保護する必要があります。このためには、Oracle JDeveloperの「ツール」メニューにある「ADFセキュリティ・ウィザード」を使用します。資格証明プロビジョニング・ページの詳細は、10.7.2項「資格証明プロビジョニング・ページの使用」を参照してください。
外部アプリケーションに指定されている登録詳細を修正するには、外部アプリケーションの登録情報の編集ウィザードを使用します。
外部アプリケーションの登録詳細を編集する手順は、次のとおりです。
アプリケーション・ナビゲータで、外部アプリケーションを右クリックし、ポップアップ・メニューから「編集」を選択します。
外部アプリケーションの登録情報の編集ウィザードで、タブをクリックしてウィザードを進め、その値を修正します。
次のうちから選択します。
名前
一般
追加フィールド
詳細は、10.7.1.1項「外部アプリケーションの登録」を参照してください。
「OK」をクリックして、変更を保存してウィザードを終了するか、「取消」をクリックして、保存せずにウィザードを終了します。
外部アプリケーションの登録詳細を削除する手順は、次のとおりです。
アプリケーション・ナビゲータで、外部アプリケーションを右クリックし、ポップアップ・メニューから「削除」を選択します。
あるいは、アプリケーション・ナビゲータで外部アプリケーションを選択し、「編集」メニューから「削除」を選択します。
「外部アプリケーションの削除」ダイアログ・ボックスで、「はい」を選択します。
WebCenterアプリケーション内の1つの外部アプリケーション登録を削除する場合、アプリケーションの各プロジェクトから、それに関連付けられた資格証明プロビジョニング・ページも削除する必要があります。さらに、外部アプリケーションに関連付けられているOracle PDKポートレット・プロデューサの登録を解除することをお薦めします。外部アプリケーションを削除した後、関連付けられたプロデューサを登録解除しない場合、これらのプロバイダのポートレットが機能しなくなり、実行時エラーが発生することがあります。
資格証明プロビジョニング・ページは、アプリケーション登録詳細を消費して、アプリケーション・ログイン・ページを提供します。ユーザーは、このログイン・ページで資格証明を入力して外部アプリケーションに対して認証できます。ユーザー資格証明は資格証明ストアに保存されます。これ以降のセッションのログインは、この資格証明ストアによって処理されます。（ユーザーの資格証明が変更されないかぎり、）ユーザーがログイン情報を再び入力する必要はありません。
この項では、設計時の資格証明プロビジョニング・ページの追加と、実行時の資格証明の追加について説明します。この項の内容は、次のとおりです。
資格証明プロビジョニング・ページは、外部アプリケーション登録を介して提供された情報に基づいて構築されたJSFページ（.jspx）です。
資格証明プロビジョニング・ページを追加する手順は、次のとおりです。
外部アプリケーションを登録します。
詳細は、10.7.1.1項「外部アプリケーションの登録」を参照してください。
アプリケーション・ナビゲータで、ポートレットの作成用にスコープ設定されたプロジェクトを右クリックし、ポップアップ・メニューから「新規」を選択します。
ポートレットの作成用にスコープ設定されたプロジェクトを作成する方法の詳細は、3.1項「WebCenterアプリケーションの作成」を参照してください。
「新規ギャラリ」で、「General」ノードの下の「External Applications」を選択します。
右ペインで、「資格証明プロビジョニング・ページ」を選択します。
「OK」をクリックします。
ファイルCredentialProvisioner.jspxは、デフォルトで、アプリケーション・ナビゲータの「Webコンテンツ」ノードの下のプロジェクト・ルートに追加されます。このページを手動で移動または名前変更した場合は、ナビゲーション・ルール（より正確には、_adfp_external_apps_credential_page <from-outcome>ナビゲーション・ルール内の<to-view-id>エントリ）を、この変更を反映するように更新します。
ログイン情報の動的レンダリングは、extAppCredentialProvBeanを使用したデータ・バインディングによって可能になります。このページのルック・アンド・フィールは自由に調整できますが、faces-config.xmlファイル内のextAppCredentialProvBeanエントリは変更できません。
誤ってextAppCredentialProvBeanエントリを変更した場合は、「新規ギャラリ」から資格証明プロビジョニング・ページを再度追加することにより、このファイルを上書きできます。
実行時、資格証明プロビジョニング・ページにログイン・データ・フィールドが表示されます。ユーザー名やパスワードのフィールドの他に、外部アプリケーション登録を介して指定したデータ・フィールドも表示されます。ユーザーは、フィールドにログイン情報を入力します。この情報はプロデューサに渡され、プロデューサはログイン値をアプリケーションに渡します。アプリケーションは、リクエストされたポートレットをプロデューサに提供します。
ユーザーは要求されるとログイン資格証明を提供します。これらの資格証明は、資格証明ストア内に保存されています。それ以降は、認証時に資格証明ストアによってその情報が提供されます。（資格証明が変更されないかぎり、）ユーザーが資格証明を提供するのは1回のみです。
実行時に資格証明を資格証明プロビジョニング・ページに追加する手順は、次のとおりです。
ポートレット・ページで、外部アプリケーションにアクセスするためのユーザー名を入力します。
外部アプリケーションにアクセスするためのパスワードを入力します。
表示されているその他のフィールドを入力します。
他の情報収集フィールドが表示されるかどうかは、アクセス先の外部アプリケーション定義によって異なります。
「OK」をクリックして、資格証明を格納し、ポートレット・ページに戻ります。これで、ポートレット・ページからポートレットにアクセスできるようになります。
以降のポートレット・セッションでは、ユーザー資格証明は資格証明ストアから提供されるため、このログインは透過的に行われます。資格証明が変更された場合は、ログイン・ページが再度表示されます。
要求されたら、外部アプリケーション・ポートレット内の「ログイン情報の更新」リンクをクリックして、実行時に資格証明プロビジョニング・ページにアクセスする必要があります。資格証明プロビジョニング・ページを直接起動したり、その他の方法で資格証明プロビジョニング・ページにアクセスしないでください。
|
注意: 外部アプリケーション対応のプロデューサから、ポートレットが含まれるページが属する各プロジェクト内に、資格証明プロビジョニング・ページを追加する必要があります。これを行わないと、実行時にポートレットの「ログイン情報の更新」リンクにアクセスできなくなります。 |
Secure Sockets Layer（SSL）通信では、認証局により発行された信頼できる証明書を使用する必要があります。これにより、認証局により発行または署名された証明書の真正性が保証されます。広く受け入れられている認証局は、キーストア（<JDEV_HOME>\jdk\jre\lib\securityディレクトリ内にあるcacertsファイル）内にリストされています。広く受け入れられていない認証局により発行されたセキュリティ証明書を使用するポートレット・プロデューサからポートレットにアクセスしようとすると、信頼できない認証局からセキュリティ証明書が発行されたことを通知するセキュリティ・アラートが表示されます。つまり、その証明書はキーストア内で使用可能になっていません。このようなポートレットにアクセスするたびにプロンプトが表示されないようにするには、この証明書をキーストアに登録する必要があります。
証明書をキーストアに登録する手順は、次のとおりです。
<JDEV_HOME>\jdk\jre\lib\securityにナビゲートします。
cacertsファイルをバックアップします。
Internet ExplorerでプロデューサURLにアクセスして、証明書を取得します。
|
注意: FireFoxの最近のバージョンでは、証明書をエクスポートする手段が備わっていません。 |
図10-44に示すように、「セキュリティの警告」ダイアログ・ボックスで、「証明書の表示」をクリックします。
「証明書」ダイアログ・ボックスで、「証明のパス」タブをクリックします。
図10-45に示すように、デフォルトでダミーの子証明書が選択されます。ルート証明書を選択し、「証明書の表示」をクリックします。
「詳細」タブをクリックし、「ファイルにコピー」をクリックします。
図10-46に示すように、「証明書のエクスポート ウィザード」で、「エクスポートするファイル」が表示されるまで、デフォルト設定を受け入れて「次へ」をクリックします。
「ファイル名」フィールドに<JDEV_HOME>\jdk\jre\lib\security\root.cerを入力し、「次へ」をクリックします。
「完了」をクリックします。
コマンド・プロンプトで、デフォルトのディレクトリを<JDEV_HOME>\jdk\jre\lib\securityに設定し、次のコマンドを実行します。
keytool -import -file root.cer -keystore cacerts -storepass changeit
このコマンドを実行することにより、root.cer証明書がキーストアにインポートされます。
プロンプトでyを入力して、この証明書を信頼することを確認します。
証明書を使用してcacertsファイルが更新されていることを確認します。
ポートレットおよびカスタマイズ可能コンポーネントに対する各アクションは、デフォルトでは保護されていません。ポートレットまたはカスタマイズ可能コンポーネントをカスタマイズできるかどうかは総じて、ページ権限から継承されます。ポートレットまたはカスタマイズ可能コンポーネント内に詳細なアクティビティの権限を付与する場合は、ページ・レベルのセキュリティ継承を無視し、必要なアクションに対してセキュリティを直接定義できます。
ユーザーがポートレットまたはカスタマイズ可能コンポーネントに対してアクションを実行できるかどうかは、adf-config.xmlファイル内のアプリケーション・ワイドなスイッチの値（enableSecurity）に基づくページ・セキュリティから継承されます。アプリケーションの作成中にWebCenterアプリケーション・テンプレートを選択した場合、adf-config.xmlファイルは<APPLICATION_NAME>/.adf/META-INFディレクトリ内に配置されています。enableSecurity要素は、デフォルトではadf-config.xml内で使用できません。例10-14および例10-15に示すように、ポートレットおよびカスタマイズ可能コンポーネントのページ・レベルのセキュリティ継承を上書きまたは拡張するには、adf-config.xmlファイル内のポートレット・セキュリティおよびカスタマイズ可能コンポーネント・セキュリティのセクションの下に、enableSecurity要素を追加する必要があります。
例10-14 adf-config.xmlのポートレット・セキュリティ・セクション内のenableSecurity要素
<!-- ============================================================================== PORTLETS ACTIONS SECURITY ============================================================================== --> <adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> .......................................... </adfp:adf-config-child>
例10-15 adf-config.xmlのカスタマイズ可能コンポーネント・セキュリティ・セクション内のenableSecurity要素
<!-- ============================================================================== CUSTOMIZABLE COMPONENTS ACTIONS SECURITY ============================================================================== --> <cust:customizableComponentsSecurity xmlns:cust="http://xmlns.oracle.com/adf/faces/customizable"> <cust:enableSecurity value="true"/> <cust:actionsCategory> .......................................... </cust:customizableComponentsSecurity>
ポートレットおよびカスタマイズ可能コンポーネントに対するアクションのセキュリティは、次のレベルで実装できます。
ページ・レベル: ポートレットおよびカスタマイズ可能コンポーネントがページ・レベルの権限を継承するように、これらのコンポーネントのセキュリティを定義できます。これがデフォルトの動作です。
デフォルトでは、ポートレットおよびカスタマイズ可能コンポーネントは、パーソナライズやカスタマイズなど、ページ・レベルの権限から許容されるアクションを継承します。つまり、ページのカスタマイズ権限を持つユーザーは、そのページ上のコンポーネントのカスタマイズ・アクションに対する権限を持ちます。enableSecurity要素を使用すると、セキュリティ継承動作を上書きできます。この要素は、次のいずれかの値を取ります。
true: true（デフォルト）に設定した場合、ユーザーがコンポーネントを変更できるかどうかは、まずページ権限から決定され、次に、その権限タイプに定義されている現在のアクション・セットに応じて調整されます。ユーザーにカスタマイズ権限がある場合は、カスタマイズ・カテゴリを構成するアクション（移動やカスタマイズなど）がユーザーに選択可能になります。ただし、これらのアクションは、adf-config.xmlファイル内に定義されているアクションによって上書きされます。たとえば、エンドユーザーがポートレットはカスタマイズできるが、ページ・レイアウトはカスタマイズできないようなページ設計が必要だとします。この場合、ページ設計者は、enableSecurityをtrueに設定することにより、ユーザーにページに対するカスタマイズ権限を強制的に持たせます。カスタマイズ可能コンポーネントに対してcustomizeActionsCategoryをfalseに設定すると、ページ・レイアウトはカスタマイズできなくなりますが、その場合もポートレットのカスタマイズはできます。（customizeActionsCategoryのデフォルトはtrueなので、ポートレットに対してこれを明示的に設定する必要はありません。）
false: falseに設定した場合、ユーザーのページ権限は無視され、adf-config.xmlファイル内に手動で指定したリストに基づいて選択可能なアクションが決まります。この場合、アクションはグローバルになり、すべてのユーザーに選択可能になります。つまり、すべてのポートレットおよびカスタマイズ可能コンポーネントに対して、デフォルトのページ権限（ポートレットの表示/パーソナライズ/カスタマイズ、およびカスタマイズ可能コンポーネントの表示/カスタマイズ）が選択可能になります。
アクション・カテゴリ・レベル: ポートレットまたはカスタマイズ可能コンポーネントの、特定のカテゴリに属するすべてのアクションに対してセキュリティを定義できます。
adf-config.xmlファイル内にactionsCategory要素を追加すると、複数のアクションに対するセキュリティを同時に定義できます。有効化したactionCategory属性に基づいて、ポートレットまたはカスタマイズ可能コンポーネントに適切な権限が設定されます。
アクション・レベル: ポートレットまたはカスタマイズ可能コンポーネントの各アクションに対してセキュリティを定義できます。
adf-config.xmlファイル内でactions要素を使用すると、各アクションを有効化または無効化できます。有効化したactions属性に基づいて、ポートレットまたはカスタマイズ可能コンポーネントに適切な権限が設定されます。
|
注意:
|
次の各項では、ポートレットおよびカスタマイズ可能コンポーネントのアクションに対するセキュリティを、アクション・カテゴリ・レベルおよびアクション・レベルで実装する方法について説明します。
ポートレットのアクションをアプリケーション・レベルでページから継承する場合、adf-config.xmlファイルのポートレット・セキュリティ・セクション内でenableSecurityをtrueに設定することにより、ポートレットのセキュリティを定義できます。trueの値は、ユーザーの権限がページ権限から決定され、次に指定されたactionsCategory要素とactions要素に応じて補完されることを示します。アクション・カテゴリおよび各アクションを定義することにより、特定のページ権限内で使用可能な各アクションを公開するかどうかを制御できます。
前述のような様々なレベルでポートレットのアクションにセキュリティを実装するには、次の各項でセキュリティ設定を定義する必要があります。
adf-config.xmlファイルのポートレット・セキュリティ・セクション内にactionsCategory要素を追加すると、アプリケーション内のポートレット上に公開されるアクション・グループを定義できます。有効化したactionsCategory属性に基づいて、ポートレットに適切な権限が設定されます。表10-11に、様々なactionsCategory属性と、デフォルトでサポートされるポートレット・アクションを示します。
表10-11 actionsCategory属性とポートレット・アクションのマッピング
| 属性値 | サポートされるアクション |
|---|---|
|
viewActionsCategory |
Render isHelpModeAvailable isNormalModeAvailable isAboutModeAvailable isPreviewModeAvailable isDetailModeAvailable isLinkModeAvailable isPrintModeAvailable |
|
customizeActionsCategory |
isMovable isCustomizeModeAvailable isMinimizable isMaximizable isConfigModeAvailable |
|
personalizeActionsCategory |
isPersonalizeModeAvailable |
例10-16に、adf-config.xmlファイルのポートレット・セキュリティ・セクションに追加できるactionsCategoryエントリを示します。この例では、カスタマイズを禁止するためにcustomizeActionsCategoryがfalseに設定されています。これらの要素の値にはExpression Language（EL）を使用できます。
例10-16 ポートレット・セキュリティ・セクション内のactionsCategory要素
<!-- ============================================================================== PORTLETS ACTIONS SECURITY ============================================================================== --> <adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> <adfp:actionCategory name="viewActionsCategory" value="true"/> <adfp:actionCategory name="customizeActionsCategory" value="false"/> <adfp:actionCategory name="personalizeActionsCategory" value="true"/> </adfp:actionsCategory> <adfp:actions> .......................................... </adfp:actions> </adfp:adf-config-child>
adf-config.xmlファイルのポートレット・セキュリティ・セクション内にactions要素を使用すると、各ポートレット・アクションを有効化または無効化できます。有効化したaction属性に基づいて、ポートレットに適切な権限が設定されます。
例10-17に、adf-config.xmlファイルのポートレット・セキュリティ・セクションに追加できるactionsエントリの例を示します。これらの要素の値にはELを使用できます。この場合、isCustomizeModeAvailableをfalseに設定することによって、カスタマイズを禁止しています。
例10-17 ポートレット・セキュリティ・セクション内のactions要素
<!-- ============================================================================== PORTLETS ACTIONS SECURITY ============================================================================== --> <adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet"> <adfp:enableSecurity value="true"/> <adfp:actionsCategory> .......................................... </adfp:actionsCategory> <adfp:actions> <adfp:action name="Render" value="true"/> <adfp:action name="isMovable" value="true"/> <adfp:action name="isCustomizeModeAvailable" value="false"/> <adfp:action name="isPersonalizeModeAvailable" value="true"/> </adfp:actions> </adfp:adf-config-child>
ELを使用した営業時間外のポートレットのカスタマイズの禁止
たとえば、通常の営業時間外にはポートレットのカスタマイズができないように構成されたアプリケーションでは、継承されたポートレット・セキュリティを上書きする必要があります。このためにはまず、例10-18に示すようなメソッドが含まれるマネージドBean（たとえば、appBusinessRulesという名前のマネージドBean）を作成する必要があります。
例10-18 appBusinessRulesマネージドBean内に定義されたInsideBizHoursメソッド
public String isInsideBizHours()
{
Calendar rightNow = Calendar.getInstance();
int currentHr = rightNow.get(rightNow.HOUR_OF_DAY);
// Do not enable customize operation outside of standard business hours
if ((currentHr > 9) && (currentHr < 17))
return "true";
else
return "false";
}
その後は、例10-19に示すように、adf-config.xmlファイルのポートレット・セキュリティ・セクション内のactionsCategory要素からこのマネージドBeanを参照できます。
例10-19 adf-config.xmlファイル内で参照されるInsideBizHoursメソッド
<adfp:adf-config-child xmlns:adfp="http://xmlns.oracle.com/adfp/portlet">
<adfp:enableSecurity value="true"/>
<adfp:actionsCategory>
<adfp:actionCategory name="customizeActionsCategory"
value="#{appBusinessRules.InsideBizHours}"/>
</adfp:actionsCategory>
</adfp:adf-config-child>
この例では、アプリケーションが営業時間内に実行される場合のみ、customizeActionsCategoryがtrueに設定されます。この時間外は、ページに対する権限がユーザーに付与されていても、ポートレットはカスタマイズできません。明示的に定義されていないその他のカテゴリはすべて、ページから継承されます。
ELを使用した、企業ネットワーク外のポートレットのパーソナライズおよびカスタマイズの禁止
この例では、ユーザーがアプリケーションに企業プロキシ・サーバーを介してアクセスしたか、それとも企業ネットワーク内部からアクセスしたかを判別するために、マネージドBeanによってリクエストのIPアドレスが確認されます。この単純な例では、リクエストにプロキシ・サーバーのIPアドレスが含まれていれば、そのリクエストは企業ネットワークの外部から発生したものと想定します。IPアドレスが危険にさらされることがあるため、一般には、完全にセキュリティの基礎をIPアドレスにすることはお薦めしません。このために、例10-20に示すメソッドをマネージドBeanに追加する必要があります。
例10-20 appBusinessRulesマネージドBean内に定義されたInsideCorpNetworkメソッド
public boolean isInsideCorpNetwork()
{
// Do not enable personalize and customize operations
// for requests that go through the corporate proxy
FacesContext ctx = FacesContext.getCurrentInstance();
ExternalContext ectx = ctx.getExternalContext();
HttpServletRequest myrequest = (HttpServletRequest) ectx.getRequest();
String currentIP = myrequest.getRemoteAddr();
if (currentIP.equals(getProxyServerIP()))
return false;
else
return true;
}
その後は、例10-21に示すように、adf-config.xmlファイルのポートレット・セキュリティ・セクション内のactionsCategory要素からこのマネージドBeanを参照できます。
例10-21 adf-config.xmlファイル内で参照されるInsideCorpNetworkメソッド
<adfp:adf-config-child xmlns="http://xmlns.oracle.com/adfp/portlet">
<adfp:enableSecurity value="true"/>
<adfp:actionsCategory>
<adfp:actionCategory name="customizeActionsCategory"
value="#{appBusinessRules.InsideCorpNetwork}"/>
<adfp:actionCategory name="personalizeActionsCategory"
value="#{appBusinessRules.InsideCorpNetwork}"/>
</adfp:actionsCategory>
</adfp:adf-config-child>
この例では、アプリケーションのリクエストのIPアドレスが企業プロキシのIPアドレスと一致しない場合のみ、customizeActionsCategoryおよびpersonalizeActionsCategoryがtrueに設定されます。ここでは、内部リクエストが有効なクライアントIPアドレスを持っていることを前提としています。明示的に定義されていないその他のカテゴリはすべて、ページから継承されます。
adf-config.xmlファイルのカスタマイズ可能コンポーネント・セキュリティ・セクション内でenableSecurityがtrueに設定されている場合、カスタマイズ可能コンポーネントのアクションにアプリケーション・レベルでセキュリティを定義できます。デフォルトでは、アプリケーションにセキュリティを実装すると、この要素はtrueに設定されます。trueの値は、adf-config.xml内に指定されているactionsCategoryおよびactionsの値以外に権限チェックが行われることを示します。
前述のように様々なレベルでカスタマイズ可能コンポーネントのアクションにセキュリティを実装するには、次の各項に示す作業を実行する必要があります。
adf-config.xmlファイルのカスタマイズ可能コンポーネント・セキュリティ・セクション内にactionsCategory要素を追加すると、複数のカスタマイズ可能コンポーネント・アクションに対するセキュリティを同時に定義できます。有効化したactionsCategory属性に基づいて、カスタマイズ可能コア・コンポーネントに適切な権限が設定されます。
表10-12に、様々なactionsCategory属性と、デフォルトでサポートされるカスタマイズ可能コンポーネント・アクションを示します。
表10-12 actionsCategoryの属性とカスタマイズ可能コンポーネント・アクションのマッピング
| 属性値 | サポートされるアクション |
|---|---|
|
viewActionsCategory |
Render isHelpAvailable |
|
customizeActionsCategory |
isMovable isCustomizeModeAvailable isMinimizable isMaximizable isShowContentEnabled |
|
editActionsCategory |
isEditable |
例10-22に、adf-config.xmlファイルのカスタマイズ可能コンポーネント・セキュリティ・セクションに追加できるactionsCategoryエントリを示します。
例10-22 カスタマイズ可能コンポーネント・セキュリティ・セクション内のactionsCategory要素
<!--
==============================================================================
CUSTOMIZABLE COMPONENTS ACTIONS SECURITY
==============================================================================
-->
<cust:customizableComponentsSecurity
xmlns:cust="http://xmlns.oracle.com/adf/faces/customizable">
<cust:enableSecurity value="true"/>
<cust:actionsCategory>
<cust:actionCategory name="viewActionsCategory" value="true"/>
<cust:actionCategory name="customizeActionsCategory" value="false"/>
<cust:actionCategory name="editActionsCategory" value="true"/>
</cust:actionsCategory>
<cust:actions>
..........................................
</cust:actions>
</cust:customizableComponentsSecurity>
例10-23に示すように、これらの要素の値にはELを使用できます。
例10-23 actionCategoryエントリ内のカスタマイズ可能コンポーネントで使用されるEL
<cust:actionsCategory>
<cust:actionCategory name="customizeActionsCategory" value="#{appBusinessRules.InsideCorpNetwork}"/>
</cust:actionsCategory>
例10-20に示すように、appBusinessRulesというマネージドBeanが定義されています。
adf-config.xmlファイルのカスタマイズ可能コンポーネント・セキュリティ・セクション内にactions要素を使用すると、カスタマイズ可能コンポーネントの各アクションを有効化または無効化できます。有効化したactions属性に基づいて、カスタマイズ可能コア・コンポーネントに適切な権限が設定されます。
例10-24に、adf-config.xmlファイルのカスタマイズ可能コンポーネント・セクションに追加できるactionsエントリを示しています。これらの要素の値にはELを使用できます。
例10-24 カスタマイズ可能コンポーネント・セキュリティ・セクション内のaction要素
<!--
==============================================================================
CUSTOMIZABLE COMPONENTS ACTIONS SECURITY
==============================================================================
-->
<cust:customizableComponentsSecurity
xmlns:cust="http://xmlns.oracle.com/adf/faces/customizable">
<cust:enableSecurity value="true"/>
<cust:actionsCategory>
..........................................
</cust:actionsCategory>
<cust:actions>
<cust:action name="isHelpAvailable" value="true"/>
<cust:action name="isEditable" value="true"/>
<cust:action name="isCustomizeModeAvailable" value="false"/>
</cust:actions>
</cust:customizableComponentsSecurity>
ここまでに、adf-config.xmlファイルを編集することにより、カスタマイズ可能コンポーネントのアクションに対するセキュリティを有効化または無効化する方法を示しました。表10-12に示すように、adf-config.xmlファイル内のactions要素とactionsCategory要素には特定のデフォルト・マッピングがあります。これらのデフォルト・マッピングは、faces-config.xmlファイルを編集することにより変更できます。これらの設定はオプションです。関連する手順については、次の項で説明します。
Web Services for Remote Portlets（WSRP）仕様では、コンシューマとポートレット・プロデューサの間でアイデンティティをセキュアに伝播するためにWeb Services Security（WS-Security）を利用できることが示されています。ただし、WSRPそれ自体が、ポートレット・プロデューサへのエンドユーザー・アイデンティティのセキュアな伝播を提供するわけではありません。WSRP仕様は、セキュアなアイデンティティ伝播に対しては明示的に他のセキュリティ標準に準拠しており、使用する必要のある特定のWS-Securityプロファイルやオプションを扱うことはありません。セキュアなメカニズムがない場合、WSRPでは、ユーザー・カテゴリという概念が定義されています。ユーザー・カテゴリは、JSR168ポートレットで使用されるセキュリティ・ロールに類似したロールにマップできます。WSRPとWS-Securityを組み合せて使用することにより、エンド・ツー・エンドのセキュリティが確実になります。
WS-Securityを使用しないアイデンティティ伝播
WS-SecurityなしでWSRPを使用すると、SOAPメッセージ内のuserContext構造に、ユーザー・プロファイル情報とユーザー・カテゴリ情報が含まれます。この情報はセキュアでないと考えられるため、パーソナライズ機能およびカスタマイズ機能以外には使用しないでください。機密的なリソースの認可には使用しないでください。この情報は、JSR168 APIのisUserInRole(role)およびgetUserPrincipal内にも公開されます。例10-25内のコードは、サンプル・ポートレットのマークアップ・レンダリング・コードでisUserInRole APIを使用して、表示するコンテンツを決定する方法を示しています。
例10-25 isUserInRole(role) API
private void doViewHtml(RenderRequest request, RenderResponse response)
throws PortletException,
IOException {
// To do: markup the required content.
PrintWriter out = response.getWriter();
out.print("<p>Welcome");
out.println("</p>");
if (request.isUserInRole("moderator")){
out.println("<p>MODERATOR</p>" );
} else {
out.println("<p>not moderator</p>" );
}
if (request.isUserInRole("participant")){
out.println("<p>PARTICIPANT</p>" );
} else {
out.println("<p>not participant</p>" );
}
if (request.isUserInRole("viewer")){
out.println("<p>VIEWER</p>" );
} else {
out.println("<p>not viewer</p>" );
}
}
WS-Securityを使用したアイデンティティ伝播
WS-SecurityをWSRPとともに利用すると、ユーザーのアイデンティティはSOAPメッセージ本体の外部のWS-Securityヘッダー内に伝播されます。これは、ユーザー名トークン形式を使用するユーザー・アサーションであり、コンシューマを認証してアサーションの整合性を保つためにデジタル署名されます。
このメカニズムを使用すると、JSR 168 APIのisUserInRoleおよびgetUserPrincipalが、SOAPメッセージのuserContext内の情報ではなく、WS-Security認証から生成されたセキュリティ・コンテキストに基づいて確立されます。
WS-Securityを使用すると、WebCenterアプリケーションおよびそれにより消費されるプロデューサのセットの構成と管理が複雑になります。しかし、状況によっては、WS-Securityは、WebCenterアプリケーションにより公開される情報のセキュリティを確実にする、SOAアーキテクチャの重要な要素となります。
Oracle WebCenter Frameworkでは、（セキュリティ・トークンおよびメッセージ本体をデジタル署名して真正性と整合性を保証するための）次のトークン・プロファイルがサポートされています。
パスワードなしのユーザー名トークン
SAMLトークン（プロデューサがサブジェクト・アサーションを確認するために使用する送信者保証方式を使用）
セキュリティ・トークンおよびSOAPメッセージ本体をデジタル署名すると、次の目的を達成できます。
コンシューマ認証
アサーションおよびメッセージ整合性
コンシューマ認証
ポートレット・プロデューサで機密的な情報（給与明細情報など）を生成する場合、正当なコンシューマからの情報表示リクエストにのみ応答する必要があります。
WS-Securityを使用し、プロデューサでセキュリティ・トークンおよびメッセージ本体がデジタル署名されるように設定すれば、プロデューサは、正当なコンシューマの公開鍵を使用して署名を検証できます。署名を検証できない場合は、リクエストが不正なコンシューマから発行された可能性があります。デジタル署名の検証を必須にすることで、機密的な情報は正当なコンシューマにのみ送信されます。
アサーションおよびメッセージ整合性
セキュリティ・トークンおよびメッセージ本体をデジタル署名すると、Webサービスのリクエストを発行したコンシューマのアイデンティティを検証する他にも、トークンとメッセージが改ざんされていないことが保証されます。これにより、介入者攻撃（正当なりクエストが妨害され、セキュリティ・トークン内のユーザー名が別のユーザー名に置換されて、他のユーザーに対して返される給与情報が表示される可能性がある）などの問題が回避されます。トークンをデジタル署名すると、改ざんが不可能になります。トークンを変更すると、プロデューサ・エンドで署名を検証できなくなり、リクエストされた給与情報ではなくSOAPフォルトが返されます。
サポートされているプロデューサ
WS-Security実装は、Oracle WebCenter Suite 10.1.3.2 WSRPコンテナによってサポートされています。その他のWSRPベンダーが、ユーザー名トークンとSOAPメッセージ本体に基づくXMLデジタル署名を使用した、パスワードを使用しないユーザー名トークンのWS-Security構成をサポートしている場合もあります。
セキュリティ・ドメインの意味
この項で説明するようなセキュアなアイデンティティ伝播を使用する場合、コンシューマ（WebCenterアプリケーション）に対して認証されたユーザーのユーザー名が、資格証明の再マッピングや提供なしで、プロデューサに伝播されます。ここでは、プロデューサがこのユーザー名を認識していて、関連付けられたセキュリティ・ドメイン内でこのユーザーを見つけられることが暗黙の前提です。したがって、この構成の管理を簡略化するために、コンシューマとプロデューサが同じセキュリティ・プロバイダ（アイデンティティ・ストア）を共有していることを確認することを強くお薦めします。
図10-47に、全体的なWSRPポートレット・セキュリティ・アーキテクチャをまとめます。
次の各項で、WebCenterアプリケーションからJSR-168標準ベースのWSRPポートレットにセキュアにアクセスする方法を説明します。
WSRPプロデューサおよびWebCenterアプリケーションのセキュリティ資格証明は、Javaキーストア（JKS）またはOracleウォレットを使用して取得および管理できます。キーストアまたはウォレットは、使用可能な公開鍵および秘密鍵の情報を提供するファイルです。キーは、認証やデータ整合性など、様々な目的に使用されます。また、ピアの証明書の検証に必要なユーザー資格証明およびトラスト・ポイントも、ウォレットまたはキーストア内にセキュアに格納されます。
OracleウォレットおよびJKSの詳細は、『Oracle Application Server Web Servicesセキュリティ・ガイド』を参照してください。
この項の内容は、次のとおりです。
orapkiユーティリティを使用すると、Oracleウォレットを生成できます。この項の内容は、次のとおりです。
認証局のウォレットの作成
証明書は、ネットワーク・アイデンティティと対応する公開鍵をバインドする、署名付きのデータ構造です。証明書には2つのタイプ（ユーザー証明書および信頼できる証明書）があります。ユーザー証明書は、公開鍵と秘密鍵の交換においてエンド・エンティティのアイデンティティを検証するために、サーバー・アプリケーションなどのエンド・エンティティによって使用されます。これに対し、信頼できる証明書とは、CAが発行したユーザー証明書を検証するためにCAが提供する証明書など、信頼できるすべての証明書のことです。
この項では、テスト目的で独自の認証局（CA）を生成します。実際の認証局を使用する場合は、この手順を省略できます。認証局とは、発行または署名した証明書の真正性を保証するエンティティです。
認証局を作成する手順は、次のとおりです。
次の例に示すように、認証局関連ファイルを格納するディレクトリを作成し、そのディレクトリにナビゲートします。
mkdir ca cd ca
次の例に示すように、ORACLE_HOME/binディレクトリにあるorapkiユーティリティを使用して、認証局を表すウォレットを作成します。
orapki wallet create -wallet ca_wallet -pwd welcome1
次の例に示すように、自己署名済のルート証明書をウォレットに追加します。
orapki wallet add -wallet ca_wallet -pwd welcome1 -dn "cn=root_test,c=us" -keysize 2048 -self_signed -validity 3650
次の例に示すように、認証局の公開鍵を、作成する他のウォレットで使用される証明書のフォームでエクスポートします。
orapki wallet export -wallet ca_wallet -pwd welcome1 -dn "cn=root_test,c=us" -cert root_test.cer cd ..
このコマンドにより、自己署名済の証明書がcaディレクトリのroot_test.cerファイルにエクスポートされます。
コンシューマのウォレットの作成
この項では、コンシューマのウォレットを作成します。ここでのコンシューマは、WSRPを介してリモート・ポートレット・プロデューサにより生成されたポートレットを消費するWebCenterアプリケーションです。
コンシューマのウォレットを作成する手順は、次のとおりです。
次の例に示すように、前に作成したcaディレクトリ内に、すべての関連ファイルを格納するためのディレクトリ（consumerなど）を作成し、consumerディレクトリに移動します。
mkdir consumer cd consumer
次の例に示すように、空のウォレットを作成し、ウォレットにアクセスするためパスワードを指定します。
orapki wallet create -wallet consumer_wallet -pwd welcome1
次の例に示すように、証明書リクエストを生成できるウォレットにエントリを追加し、リクエストを生成します。
orapki wallet add -wallet consumer_wallet -pwd welcome1 -dn "cn=mywebcenter,c=us" -keysize 2048
次の例に示すように、ウォレットから証明書リクエストをエクスポートします。
orapki wallet export -wallet consumer_wallet -pwd welcome1 -dn "cn=mywebcenter,c=us" -request creq.txt
このコマンドにより、指定されたファイルcreq.txtに証明書リクエストがエクスポートされます。
前に作成した認証局ウォレットと、作成したばかりの証明書リクエストを使用して、署名付き証明書を生成します。これには、次の例に示すコマンドを使用してください。
orapki cert create -wallet ../ca_wallet -pwd welcome1 -request creq.txt -cert mywebcenter.cer -validity 3650
このコマンドにより、有効期間が3650日間の証明書cert.txtが作成されます。これは、証明書を発行する認証局と同様です。
次の例に示すコマンドを使用して証明書を検査し、その証明書に認証局ウォレットから認証局として発行者test_rootが指定されていることを確認します。
orapki cert display -cert mywebcenter.cer -complete
このコマンドの出力は、次のようになります。
{ fingerprint = d72ad668f2080eec50b65d3254e7b4d5, notBefore = Mon Dec 04 14:38:5
4 PST 2006, notAfter = Thu Dec 01 14:38:54 PST 2016, holder = CN=mywebcenter,C=u
s, issuer = CN=root_test,C=us, serialNo = 0, sigAlgOID = 1.2.840.113549.1.1.4,
key = { modulus = 314884176036895407457111380339124001153916819457886938130073164
66491702054112788966463056555272544102605057391702786162416825660680989204938981
36083123707588730587306333857150738020737960803324519027546624976478615482735062
49311969288116920907810200123456329599692568441307608473442677638235059030372763
96576120231060821377869996681090896136038676747964745359958271161004529457095590
40284680296091276073838918946308169577415359123456663657894033293472170366722836
45060044652256894479892976475267015999868137477785728310679164218193742125023418
72105028176137424737248643367731491981820389154137052649234214917208418497, exponent = 65537 } }
次の例に示すように、認証局のルート証明書をコンシューマ・ウォレットに追加します。
orapki wallet add -wallet consumer_wallet -pwd welcome1 -trusted_cert -cert ../root_test.cer
|
注意: 実際の認証局（Verisignや、次のリストに示された認証局など）を使用する場合は、この手順を実行する必要はありません。
これらの既知の認証局ルート証明書は、Oracleウォレット内にすでに存在しています。テスト用に独自の認証局を作成する場合、またはあまり知られていない認証局を使用する場合は、次の手順を実行して、証明書をウォレット内に発行するために使用されるルート証明書を追加する必要があります。 |
次の例に示すように、WebCenterアプリケーションのアイデンティティを表す、新しく発行されたユーザー証明書mywebcenter.cerをウォレットに追加します。
orapki wallet add -wallet consumer_wallet -pwd welcome1 -user_cert -cert mywebcenter.cer
次の例に示すコマンドを使用して、ウォレットのコンテンツを表示します。
orapki wallet display -wallet consumer_wallet -pwd welcome1
このコマンドの出力は、次のようになります。
Requested Certificates: User Certificates: Subject: CN=mywebcenter,C=us Trusted Certificates: Subject: CN=root_test,C=us Subject: CN=GTE CyberTrust Root,O=GTE Corporation,C=US Subject: OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Secure Server Certification Authority,O=RSA Data Security\, Inc.,C=US Subject: CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US Subject: CN=Entrust.net Secure Server Certification Authority,OU=(c) 2000 Entrust.net Limited,OU=www.entrust.net/SSL_CPS incorp. by ref. (limits liab.), O=Entrust.net Subject: CN=Entrust.net Certification Authority (2048),OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net Subject: CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US
プロデューサのウォレットの作成
キーストア設定プロセスの最後の手順は、使用するプロデューサに対してウォレットを生成することです。プロデューサは、getMarkupインタフェースを介して受け取ったリクエストのWS-Securityヘッダー内にある、コンシューマから受け取ったセキュリティ・トークンの真正性を検証するために、コンシューマの公開鍵を必要とします。
これには、署名に使用するコンシューマの証明書とルート証明書が含まれたウォレットが必要です。これらは、信頼できる証明書としてウォレットに追加されます。
プロデューサのウォレットを作成する手順は、次のとおりです。
次の例に示すように、前に作成したcaディレクトリ内にプロデューサ用のディレクトリを作成し、そのプロデューサにナビゲートします。
mkdir producer cd producer
次の例に示すコマンドを使用して、空のウォレットを作成します。
orapki wallet create -wallet producer_wallet -pwd welcome1
必要な場合、次の例に示すように、CAのルート証明書をウォレットに追加します。
orapki wallet add -wallet producer_wallet -pwd welcome1 -trusted_cert -cert ../root_test.cer
次の例に示すように、コンシューマの証明書を信頼できる証明書としてプロデューサのウォレットに追加します。
orapki wallet add -wallet producer_wallet -pwd welcome1 -trusted_cert -cert ../consumer/mywebcenter.cer
次の例に示すコマンドを使用して、ウォレットのコンテンツを表示します。
orapki wallet display -wallet producer_wallet -pwd welcome1
Javaキーストア（JKS）は、Sun Microsystemsが定義している専有キーストア形式です。JKS内にキーおよび証明書を作成して管理するには、Java JDKとともに配布されているkeytoolユーティリティを使用します。
この項では、JKSを使用してキーストアおよびキーを構成する方法について説明します。WSRPプロデューサおよびWebCenterアプリケーションに対してWeb Services Security（WS-Security）の信頼できる認証を有効にするには、まず、コンシューマ・サイドとプロデューサ・サイドの両方でキーストアを構成する必要があります。Oracle JDeveloperに付属のkeytoolユーティリティ（<JDEV_HOME>/jdk/bin）を使用して、キーストアを設定します。
この項の内容は、次のとおりです。
コンシューマのJavaキーストアの作成
ここでのコンシューマは、WSRPを介してリモート・ポートレット・プロデューサにより生成されたポートレットを消費するWebCenterアプリケーションです。コンシューマのJavaキーストアを作成する手順は、次のとおりです。
JDEV_HOME/jdk/binに移動し、コマンド・プロンプトを開きます。
次のようにgenKeyコマンドを使用して、新しいキー・ペア（公開鍵および関連付けられた秘密鍵）を作成します。
keytool -genkey -alias consumer -keyalg "RSA" -sigalg "SHA1withRSA" -dname "CN=test, OU=Unknown, O=Unknown, L=Unknown, ST=California, C=US" -keypass welcome1 -keystore consumer.jks -storepass welcome1
キーストアを表示します。次の例に示すコマンドを使用すると、キーストアのコンテンツが表示されます。
keytool -list -v -keystore consumer.jks -storepass welcome1
次のコマンドを使用して、署名キー・ペアの証明書リクエスト・ファイルを作成します。
keytool -certreq -file consumer.csr -alias consumer -keystore consumer.jks -keypass welcome1 -storepass welcome1
認証局（CA）から信頼できる証明書をリクエストします。
VeriSign、Thawte、Entrustなどのパブリック認証局が多数あります。また、Netscape、Microsoft Certificate Servers、Entrust CA製品のような製品を組織に使用して、独自の認証局を実行することもできます。
root.cerファイルを作成し、CAにより提供されたルート証明書のコンテンツをコピーしてこのファイルに貼り付けます。
次のコマンドを使用して、ルート証明書をインポートします。
keytool -import -file root.cer -keystore consumer.jks -storepass welcome1
CAからの中間証明書に対して、この手順を繰り返します。
trusted.cerファイルを作成し、CAにより提供された信頼できる証明書のコンテンツをコピーしてこのファイルに貼り付けます。
次のコマンドを使用して、信頼できる証明書をインポートします。
keytool -import -file trusted.cer -alias consumer -keypass welcome1 -keystore consumer.jks -storepass welcome1
プロデューサのJavaキーストアの作成
キーストア設定プロセスの次の手順は、プロデューサに対してJavaキーストアを生成することです。プロデューサは、getMarkupインタフェースを介して受け取ったリクエストのWS-Securityヘッダー内にある、コンシューマから受け取ったセキュリティ・トークンの真正性を検証するために、コンシューマの公開鍵を使用します。このためには、署名に使用するコンシューマの証明書とルート証明書が含まれたJavaキーストアがプロデューサに必要です。これらの証明書は、信頼できる証明書としてJavaキーストアに追加されます。
プロデューサのJavaキーストアを作成する手順は、次のとおりです。
JDEV_HOME/jdk/binに移動し、コマンド・プロンプトを開きます。
次のコマンドを使用して、コンシューマJavaキーストアから証明書をエクスポートします。
keytool -export -file producer.cer -alias consumer -keystore consumer.jks -storepass welcome1
次のコマンドを使用して、前の手順でエクスポートした証明書をプロデューサのJavaキーストアにインポートします。
keytool -import -file producer.cer -alias consumer -keystore producer.jks -storepass welcome1
プロデューサ・エンドで必要な構成は、アプリケーションを介して消費するWSRPコンテナによって異なります。Oracle WebCenter Suite 10.1.3.2.0上で稼働するOracle WSRPコンテナから、ポートレットを消費できます。
|
注意: Oracle WebCenter Frameworkとの統合で、構成する必要のあるトークン・プロファイルは、パスワードもSAMLトークンもなしのユーザー名トークンです。 |
この項の例で、Oracle WebCenter Suite 10.1.3.2.0インストールのOracle WSRPコンテナの構成について説明します。これは、Oracle Application Serverリリース10.1.3.2.0上にデプロイされたOracle WSRPコンテナです。このコンテナは、OC4JとのWS-Security統合を利用します。
プロデューサのデプロイおよび構成
WS-Securityのプロデューサを構成する前に、まず、18.9項「アプリケーション・サーバーへのポートレットのデプロイ」の手順を実行して、標準準拠のポートレット・プロデューサをOracle WebCenter Suite 10.1.3.2.0 WSRPコンテナにデプロイする必要があります。
プロデューサをデプロイした後は、次の手順を実行して、WS-Securityのプロデューサを構成します。
次のURLにナビゲートして、Application Server Controlコンソールにアクセスします。
http://<host_name>.<domain>:<port>/em
次に例を示します。
http://server.domain.com:7781/em
コンソールのURLを調べるには、readme.txtファイルを参照してください。インストール後、このテキスト・ファイルは次の場所に保存されています。
UNIXの場合: ORACLE_HOME/install/readme.txt
Windowsの場合: ORACLE_HOME\install\readme.txt
ログインします。
ユーザー名とパスワードは、インストール中に指定したものです。
Application Server Controlコンソールのホームページで、OC4Jインスタンスにナビゲートします。たとえば、OC4J_WebCenterにナビゲートします。
「Webサービス」タブをクリックします。
Webサービスが何も表示されない場合、Webサービスがまだリクエストされていないために、Application Server Controlコンソールで表示されないことが原因です。
Application Server ControlコンソールでWebサービス・インタフェースの表示を有効にする手順は、次のとおりです。
「アプリケーション」タブをクリックし、アプリケーションをクリックします。たとえば、「richtextportlet」をクリックします。
「アプリケーション」ページで、プロデューサ・アプリケーションのWebモジュールをクリックします。
「Webモジュール」ページで、「Webモジュールのテスト」リンクをクリックします。
「Webモジュールのテスト」ページに、プロデューサのベースURLが標準のWebモジュールとして表示されます。
図10-48に示すように、/infoをベースURLに追加します。
「Webモジュールのテスト」をクリックします。
WSRPプロデューサのテスト・ページで、「Webサービスの説明」の下のリンクの1つをクリックします。
ブラウザにポートレットのWSDLが表示されます。
WSRP v1 WSDLを選択した場合は、例10-26および図10-49に示すように、このWSDL内で、WSRPベース・サービスの場所を示す行を見つける必要があります。
例10-26 WSRP v1 WSDL内のベース・サービスURL
http://hostname.company.com:7781/secondSampleV1/portlets/WSRPBaseService
WSRP v2 WSDLを選択した場合は、例10-27および図10-50に示すように、このWSDL内で、WSRPマークアップ・サービスの場所を示す行を見つける必要があります。
これらのURLの1つをブラウザ・ウィンドウ内にコピーして、WSRPベース・サービスまたはWSRPマークアップ・サービスにアクセスします。
結果の画面は無視してかまいません。このページをリクエストする理由は、図10-51に示すように、WSRPBaseService（またはMarkup）を取得してWebサービスのリストに表示するためです。WS-Securityに構成する必要があるサービスは、getMarkupインタフェースが含まれるこのサービスのみです。
「アプリケーション」ページで、「Webサービス」をクリックします。
「WSRP_v2_Markup_Service」をクリックします。
「管理」タブをクリックします。
図10-51に示すように、「管理」タブで、「セキュリティ」機能の隣の「構成の編集」アイコンをクリックします。
図10-51 Application Server Controlコンソールでの「WSRPBaseService」
図10-52に示すように、「セキュリティ構成の編集」ページで、ポート・レベルまたは操作レベルの構成を実行できます。
キーストアの構成
キーストアを構成する手順は、次のとおりです。
Application Server Controlコンソールで、「アプリケーション」タブ、関連するアプリケーション・リンク、「Webサービス」タブ、「WSRPBaseService」リンク、「管理」タブ、「機能の有効化/無効化」の順にクリックします。
リストから「セキュリティ」を選択し、「移動」をクリックして「セキュリティ」を「有効な機能」リストに移動します。
「OK」をクリックします。
「セキュリティ」の隣の「構成の編集」をクリックします。
「キーストアとアイデンティティ証明書」をクリックし、「アプリケーション固有のキーストアの使用」を選択します。キーストアに次の値を入力します。
図10-53に示すように、「キーストアとアイデンティティ証明書」ページで、キーストアに次の値を指定します。
Keystore Name = <Any name> Keystore Path = <Keystore path in the file system> Keystore Type = JKS Keystore Password = <Keystore password> Confirm Keystore Password = <same as above><>
|
注意: Oracleウォレットを使用する場合、「アイデンティティ証明書」セクションは空のままにしておいてください。WS-Securityコードにより、署名を検証するためにウォレット内で適切な証明書が検索されます。 |
「OK」をクリックします。
インバウンド・ポリシーの構成
インバウンド・ポリシーを構成する手順は、次のとおりです。
Application Server Controlコンソールで、「アプリケーション」タブ、関連するアプリケーション・リンク、「Webサービス」タブ、「WSRPBaseService」リンク、「管理」タブ、「機能の有効化/無効化」の順にクリックします。リストから「セキュリティ」を選択し、「OK」をクリックします。
「セキュリティ」機能に対して表示されている「構成の編集」アイコンをクリックします。
「インバウンド・ポリシー」をクリックします。
図10-54に示すように、Application Server Controlコンソールの「インバウンド・ポリシー」の「認証」ページで、「ユーザー名/パスワード認証の使用」を選択した場合、「パスワード・タイプ」を指定します。
SAML認証を使用する場合は、「送信者保証の許容」および「署名の検証」を選択する必要があります。
オプションで、図10-55に示すように、「完全性」タブをクリックし、「メッセージ本文に署名が必要」オプションを選択します。
コンシューマ・エンドでメッセージ本文が署名されます。このオプションを選択すると、メッセージ本文の署名がプロデューサ・エンドで検証されるため、リクエストの完全性がさらに保証されます。
「OK」をクリックします。
|
注意: WebCenterアプリケーションを再デプロイするときは、インバウンド・ポリシーを再び構成する必要があります。 |
パスワードなしのユーザー名トークンに対するWebサービスの構成
ユーザーがすでに認証されていて信頼できる場合、かつ、アイデンティティ・ストア内にそのユーザーが存在するかどうか検証するだけでよい場合は、この構成を実行してください。パスワードなしのユーザー名トークンにWebサービスを構成するには、手動でwsmgmt.xmlファイルを編集します。
|
注意: Application Server Controlコンソールを使用してこの構成を実行することは、このリリースではサポートされていません。 |
wsmgmt.xmlファイルはインスタンス・レベルの構成ファイルであり、OC4Jインスタンス内にデプロイされたWebサービスのセキュリティ構成全部を格納します。インバウンド要素が構成されている場合、サーバー・インターセプタは実行時にwsmgmt.xmlファイルを使用して、セキュリティ・ポリシーを強制設定します。
この構成を手動で実行する手順は、次のとおりです。
OC4J_HOME/config/ディレクトリでwsmgmt.xmlファイルを見つけます（OC4J_HOMEは、Oracleホーム・ディレクトリの下のOC4Jの場所です）。例10-28に、このファイルのコードを示します。
例10-28 サンプルのwsmgmt.xmlファイル
<port app="SecondSampleV1" web="SecondSampleV1" service="WSRP_v1_Service" port="WSRPBaseService">
<runtime enabled="security">
<security>
<key-store name="portal" path="/scratch/pencarna/wss/portal/portal.jks"
type="JKS" store-pass="->SecondSampleV1.WSRPBaseService.keystore.portal.jks"/>
<signature-key alias="paul" key-pass="->SecondSampleV1.WSRPBaseService.key.paul"/>
<inbound>
<verify-username-token password-type="PLAINTEXT" require-nonce="false" require-created="false"/>
</inbound>
</security>
</runtime>
</port>
このファイル内で、次の行を変更します。
<verify-username-token password-type="PLAINTEXT" require-nonce="false" require-created="false"/>
変化後のURLは、次のとおりです。
<verify-username-token> <property name="username.token.allow.nopassword" value ="true"/> </verify-username-token>
username.token.allow.nopasswordというBOOLEANプロパティの値によって、Webサービスがパスワードを要求せずにユーザー名トークンを認証するかどうかが決まります。
wsmgmt.xmlファイルを保存します。
WSRPポートレットのコンシューマは、WebCenterアプリケーションです。この項では、WebCenterアプリケーションでポートレット・リクエストにWS-Securityヘッダーを含めるために必要な構成手順を示します。
この項の内容は、次のとおりです。
コンシューマ・システムへのキーストア情報の転送
WebCenterアプリケーションでキーストアを使用できるようにするには、コンシューマ・キーストアを、アプリケーションが稼働しているシステムに移動する必要があります。
コンシューマ・キーストアを移動する手順は、次のとおりです。
C:\ca\consumer\consumer_walletディレクトリにナビゲートします。
WebCenterアプリケーションが稼働しているシステムに、ewallet.p12ファイルをFTP転送またはコピーします。
キーストア・パスの更新
WebCenterアプリケーションをOracle Application Serverインスタンスにデプロイした後は、このインスタンスのキーストア・パスを、絶対パスを使用するように更新する必要があります。たとえば、/scratch/machine1/product/10.1.3.2.0/OracleAS_1/j2ee/OC4J_WebCenter/applications/myWSRPApp/adf/META-INF/webCenter.jksのように更新します。
キーストア・パスを更新するには、Application Server Controlコンソールの資格証明MBeanで「setCredential」操作を使用できます。資格証明MBeanは、接続に関連するセキュアなプロパティを更新するために使用されるアプリケーションMBeanです。12.5項「デプロイ済アプリケーションでの資格証明の更新」の手順に従って、「setCredential」操作を実行してください。
キーストア・パスを更新した後、OC4Jインスタンスを再起動します。
ユーザー名トークン・プロファイルのコンシューマの構成
Oracle JDeveloperを使用してWSRPプロデューサをWebCenterアプリケーションに登録するとき、コンシューマ・エンドでユーザー名トークン・プロファイルにセキュリティ設定を定義できます。
WSRPプロデューサをWebCenterアプリケーションに登録し、セキュリティを定義する手順は、次のとおりです。
Oracle JDeveloperのアプリケーション・ナビゲータで、プロデューサを作成するプロジェクトを右クリックし、ポップアップ・メニューから「新規」を選択します。
「新規ギャラリ」ダイアログ・ボックスの「カテゴリ」で、「Web Tier」ノードを開き、「Portlets」を選択します。
「項目」で、「WSRPプロデューサの登録」を選択します。
「OK」をクリックします。
WSRPポートレット・プロデューサの登録ウィザードの各ステップで、次の内容を指定します。
ステップ1で、接続に一意の名前を指定します。
ステップ2で、プロデューサのURLエンドポイントを指定します。
ステップ3で、デフォルトの実行時間として60の値を受け入れます。
ステップ4で、次の項目を指定します。
トークン・プロファイル: ユーザー名トークン
デフォルト・ユーザー: <user_ name>
XML署名: バイナリ・セキュリティ・トークン
ステップ5で、次の項目を指定します。
ストア・パス: 「参照」をクリックして、10.10.1.2項「Javaキーストアを使用したキーストアの設定」で作成したキーストアにナビゲートして選択します。
ストア・パスワード: <キーストアのパスワード>
ストア・タイプ: <自動的に移入>
署名キーの別名: 移入されている別名から選択
署名キーのパスワード: <証明書別名のパスワード>
これらのフィールドの詳細は、4.3.1.1項「WSRPポートレット・プロデューサの登録」を参照してください。
「終了」をクリックして、登録を完了します。
「ViewController」プロジェクトの下にUNTPage.jspxという新しいJSF JSPページを作成します。
このページに対して「新規マネージドBeanでのUIコンポーネントの自動公開」を選択します。
次のライブラリを使用します。
ADF Faces Components
ADF Faces HTML
ADFポートレット・コンポーネント
カスタマイズ可能コンポーネント
JSF Core
JSF HTML
コンポーネント・パレットで、前に登録したプロデューサを選択し、ポートレットをフォーム内にドロップします（「構造」ペインを使用して、ポートレットがフォーム内に配置されていることを確認します）。
オプションで、10.2.3.2項「アプリケーション内のページの保護」の手順を実行することにより、ページを保護します。
ページを実行し、適切な資格証明を使用してログインします。ポートレットが表示されるはずです。
SAMLトークン・プロファイルのコンシューマの構成
Oracle JDeveloperを使用してWSRPプロデューサをWebCenterアプリケーションに登録するとき、コンシューマ・エンドでSAMLトークン・プロファイルにセキュリティ設定を定義できます。
WSRPプロデューサをWebCenterアプリケーションに登録し、セキュリティを定義する手順は、次のとおりです。
Oracle JDeveloperのアプリケーション・ナビゲータで、プロデューサを作成するプロジェクトを右クリックし、ポップアップ・メニューから「新規」を選択します。
「新規ギャラリ」ダイアログ・ボックスの「カテゴリ」で、「Web Tier」ノードを開き、「Portlets」を選択します。
「項目」で、「WSRPプロデューサの登録」を選択します。
「OK」をクリックします。
WSRPポートレット・プロデューサの登録ウィザードの各ステップで、次の内容を指定します。
ステップ1で、接続に一意の名前を指定します。
ステップ2で、プロデューサのURLエンドポイントを指定します。
ステップ3で、デフォルトの実行時間として60の値を受け入れます。
ステップ4で、次の項目を指定します。
トークン・プロファイル: SAMLトークン
デフォルト・ユーザー: <user_ name>
発行者名: www.oracle.com
XML署名: バイナリ・セキュリティ・トークン
ステップ5で、次の項目を指定します。
ストア・パス: 「参照」をクリックして、10.10.1.2項「Javaキーストアを使用したキーストアの設定」で作成したキーストアにナビゲートして選択します。
ストア・パスワード: <キーストアのパスワード>
ストア・タイプ: <自動的に移入>
署名キーの別名: 移入されている別名から選択
署名キーのパスワード: <証明書別名のパスワード>
これらのフィールドの詳細は、4.3.1.1項「WSRPポートレット・プロデューサの登録」を参照してください。
「終了」をクリックして、登録を完了します。
「ViewController」プロジェクトの下にUNTPage.jspxという新しいJSF JSPページを作成します。
このページに対して「新規マネージドBeanでのUIコンポーネントの自動公開」を選択します。
次のライブラリを使用します。
ADF Faces Components
ADF Faces HTML
ADFポートレット・コンポーネント
カスタマイズ可能コンポーネント
JSF Core
JSF HTML
コンポーネント・パレットで、前に登録したプロデューサを選択し、ポートレットをフォーム内にドロップします（「構造」ペインを使用して、ポートレットがフォーム内に配置されていることを確認します）。
オプションで、10.2.3.2項「アプリケーション内のページの保護」の手順を実行することにより、ページを保護します。
ページを実行し、適切な資格証明を使用してログインします。ポートレットが表示されるはずです。
本番環境では、アプリケーションがOracle Application Server内のOC4Jにデプロイされます。通常、OC4Jインスタンスは、認証用のOracle Identity ManagementおよびOracle Single Sign-Onのリポジトリとして、LDAPベースのOracle Internet Directoryを使用します。このため、Oracle Internet Directoryまたは外部LDAPプロバイダをアイデンティティ・ストアとして使用し、認証にシングル・サインオンを使用するように、WebCenterアプリケーションを構成することが必要です。
この構成は、Oracle Application Server内のOC4Jにアプリケーションをデプロイするときに実行します。WebCenterアプリケーションのデプロイに関連するステップの詳細は、図12-4を参照してください。
この項の内容は、次のとおりです。
Oracle Internet Directoryを使用するようにWebCenterアプリケーションを構成するには、次のいずれかの方法を使用できます。
ADFセキュリティ・ウィザードを実行し、図10-56に示すような「Oracle JAASプロバイダ」画面でデフォルトの「軽量XMLプロバイダ」を選択します。次に、実行時にApplication Server Controlコンソールを使用して、LDAPベースのプロバイダ（Oracle Internet Directoryなど）を使用するようにアプリケーションを構成します。
ADFセキュリティ・ウィザードを実行し、図10-56に示すような「Oracle JAASプロバイダ」画面で「LDAPプロバイダ」を選択して、直接LDAPベースのプロバイダから開始します。この場合、開発環境で使用したLDAPプロバイダと実行時に使用するLDAPプロバイダが同じであることが期待されます。
|
注意: このオプションは、認証に対してのみ使用できます。Oracle ADF認可を使用していて、「認可」画面を使用してセキュリティ対応コンポーネントの権限付与を設定しようとする場合は、このオプションを設定しても、ポリシーはLDAPサーバーに自動的に格納されません。このため、Oracle ADF認可を使用している場合は、開発中にXMLプロバイダを使用し、デプロイ時またはデプロイ後にLDAPプロバイダに対して構成を行う必要があります。 |
Oracle Internet Directoryを使用するようにWebCenterアプリケーションを構成する手順は、次のとおりです。
WebCenterアプリケーションの開発およびOracle ADF Securityの設定
WebCenterアプリケーションを開発し、ADFセキュリティ・ウィザードを使用して、このアプリケーションにOracle ADF Securityを設定します。
WebCenterアプリケーションのパッケージ化
この手順では、必要なすべてのファイルが標準のJ2EE形式およびディレクトリ構造でEARファイルとしてパッケージ化されます。この作業を実行するには、12.2.1項「WebCenterアプリケーションのパッケージ化」の手順に従ってください。
WebCenterアプリケーションの事前デプロイ
この手順では、ファイル内に含まれる開発参照がターゲット参照に変更されます。ターゲットのEARファイルは、Oracle JDeveloperに同梱のデプロイ前ツールを使用して作成します。この作業を実行するには、12.2.2.2項「WebCenterアプリケーションおよびJCRアダプタ・ベースのアプリケーションの事前デプロイ」の手順に従ってください。
OC4JインスタンスとOracle Internet Directoryの関連付け
WebCenterアプリケーションをOracle Application Server内のOC4Jインスタンスにデプロイする前に、Oracle Internet DirectoryをOC4Jインスタンスに関連付ける必要があります。
この作業は、OC4JインスタンスがまだOracle Internet Directoryに関連付けられていない場合にのみ実行してください。Application Server Controlコンソールを使用して、OC4JインスタンスをLDAPベースのOracle Internet Directoryのインスタンス（Oracle Identity Managementのリポジトリ）に関連付けます。そのための手順は、次のとおりです。
Application Server Controlコンソールで、インスタンスのOC4Jホームページにナビゲートし、「管理」タブをクリックします。
表示される「管理」ページで、「アイデンティティ管理」タスク（「セキュリティ」タスクの1つ）を選択します。
表示される「アイデンティティ管理」ページで、「構成」を選択します。
ここでは、Oracle Internet DirectoryインスタンスがまだOC4Jインスタンスに関連付けられていないことが前提となります。したがって、Oracle Internet Directoryホスト名およびポートは「未構成」として表示されます。別のOracle Internet DirectoryインスタンスがこのOC4Jインスタンスと以前に関連付けられた場合は、『Oracle Containers for J2EEセキュリティ・ガイド』の「Oracle Internet Directoryの関連付けの変更」を参照してください。
表示される「アイデンティティ管理の構成: 接続情報」ページで、次のようにします。
Oracle Internet Directoryインスタンスに完全修飾ホスト名（myoid.oracle.comなど）を指定します。Oracle Internet Directoryユーザーに識別名（cn=orcladminなど）を指定します。ディレクトリ内のユーザーは、それぞれ一意の識別名を持つ必要があります。ここで指定するユーザーは、Oracle Internet Directoryインスタンス内のiASAdminsロールに属している必要があります。Oracle Internet Directoryユーザーのパスワードを指定します。これは、Oracle Internet Directory内に作成されるoc4jadminユーザーのデフォルト・パスワードとしても設定されます（ただし、oc4jadminアカウントがすでに作成されている場合は、別のOC4JインスタンスがOracle Internet Directoryインスタンスに関連付けられているため、除きます）。Oracle Internet Directoryインスタンスに対してSSL接続または非SSL接続のいずれを使用するか、および使用する適切なポートを指定します。SSLのポートは通常636で、非SSLのポートは通常389です。（SSLまたはポート設定を後で変更するには、前の手順で示した『Oracle Containers for J2EEセキュリティ・ガイド』の項で説明されているように、OC4JとOracle Internet Directoryの関連付けを設定しなおす必要があります。）完了したら、次のページに進みます。
「アイデンティティ管理の構成: オプションで、Application Server Control」ページで、Oracle Identity ManagementをApplication Server Control用のセキュリティ・プロバイダとして指定できます。（これを指定すると、Oracle Internet Directoryインスタンス内に定義されているユーザーおよびロールのみがApplication Server Controlにアクセスできるようになります。）
完了したら、次のページに進みます。
「アイデンティティ管理の構成: オプションで、デプロイ済アプリケーション」ページで、OC4Jインスタンス内にデプロイされているアプリケーションごとに、セキュリティ・プロバイダとしてOracle Internet Directory（実際はOracle Identity Management）をSSO付きまたはSSOなしで指定できます。
完了したら、「構成」を選択し、要求されたらインスタンスを再起動します。これで、OC4JとOracle Internet Directoryの関連付けのプロセスは完了です。「アイデンティティ管理」ページが再び表示されます。
WebCenterアプリケーションのデプロイ
Application Server Controlコンソールを使用してWebCenterアプリケーションをOC4Jインスタンスにデプロイする準備ができました。この作業を実行するには、12.2.3項「Application Server Controlコンソールを使用したWebCenterアプリケーションのデプロイ」の手順に従ってください。
|
注意: デプロイ計画のポイントの1つとして、デプロイ中に、セキュリティ・プロバイダをOracle Internet Directoryに変更できます。次の項で、これを行わなかった場合に、デプロイ後にセキュリティ・プロバイダをOracle Internet Directoryに変更する方法を示します。 |
この時点では、WebCenterアプリケーションは稼働しますが、ポリシー情報はまだ移行されていないため、すべてのセキュリティ機能が働くわけではありません。
WebCenterアプリケーションのセキュリティ・プロバイダでOracle Internet Directoryを使用するように変更
次の手順では、Oracle Internet DirectoryをWebCenterアプリケーション用のセキュリティ・プロバイダとして追加します。そのための手順は、次のとおりです。
Application Server Controlコンソールで、WebCenterアプリケーションが含まれるOC4Jインスタンスにナビゲートし、アプリケーションを選択して「管理」タブをクリックします。
表示される「管理」ページで、「セキュリティ・プロバイダ」タスクを選択します。
「セキュリティ・プロバイダの変更」をクリックします。
「セキュリティ・プロバイダ・タイプ」リストから、「Oracle Identity Managementセキュリティ・プロバイダ」を選択します。
「OK」をクリックします。
WebCenterアプリケーションを再起動します。
セキュリティおよびアプリケーション・ロールの移行
セキュリティおよびアプリケーション・ロールをOracle Internet Directoryに移行するための手順は、次のとおりです。
JAZN移行ツールを使用して、アプリケーションEARファイルの一部としてパッケージ化されているapp-jazn-data.xmlファイルから、LDAPベースのOracle Internet Directory用のLDIFファイルにポリシー情報を移行します。
このツールを使用すると、開発環境からデプロイ済本番環境への移行が容易になります。
例10-29に、XMLからLDAPへの移行を容易にするための構文を示します。
例10-29 XMLからLDAPへの移行のための構文
java oracle.security.jazn.tools.JAZNMigrationTool -D binddn -w passwd -h ldaphost -p ldapport -st xml -dt ldap -sf <source file> -df <dest file> -m policy|realm|all(default)
JAZN移行ツールの使用方法の詳細は、12.2.4.3項「JAZN移行ツールの使用」を参照してください。
LDIFファイルを変更して、Oracle Internet Directory内にすでに存在しているエントリをすべて削除します。ユーザー・パスワードは、Oracle Internet Directoryパスワード・ポリシーに準拠している必要があります。
ldapmodifyコマンドを使用して、LDIFファイル内のポリシー情報をOracle Internet Directoryに追加します。この作業を実行するには、12.2.4.4項「ldapmodifyコマンドライン・ツールの使用」の手順に従ってください。
|
関連項目: ldapmodifyコマンドの詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。 |
ロール・マッピングの構成
開発環境が対応するエンタープライズ・ロール参照を使用して構成され、その後のJAZN情報の移行がJAZN移行ツールのallモードで実行された場合、デプロイされたアプリケーションでは適切なロール・マッピングが使用可能になります。
ただし、開発環境で一時ロールを使用してポリシーおよびセキュリティ制約をマップした場合は、これらのポリシーをデプロイする前に、これらのロール参照を適切なエンタープライズ・ロールに変換する必要があります。たとえば、開発者が、デプロイ・サーバー上のhr-directorsロールと同じロールにエンタープライズ・ロールmymanagersを使用した場合、app-jazn-data.xmlファイルとorion-application.xmlファイルもそれに応じて更新する必要があります。例10-30に示すように、JAZN移行ツールを実行する前に、app-jazn-data.xml内でポリシー情報を変更します。
例10-30 app-jazn-data.xmlファイル内のgrant
<grant>
<grantee>
<principals>
<principal>
<realm-name>jazn.com</realm-name>
<type>role</type>
<class>oracle.security.jazn.spi.xml.XMLRealmRole</class>
<name>hr-directors</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>view.pageDefs.welcomePageDef</name>
<actions>customize,personalize,view</actions>
</permission>
</permissions>
</grant>
同様に、（ORACLE_HOME/j2ee/home/application-deployments/<Application_Name>ディレクトリにある）orion-application.xmlファイル内に定義されているエンタープライズ・ロール・マッピングに対するJ2EEセキュリティも、デプロイ・サーバーのエンタープライズ・ロールを反映するように更新する必要があります。たとえば、例10-31に示すように、開発で使用したロールから本番ロールhr-directorsへのJ2EEセキュリティ・ロールhr_managersのマッピングを変更できます。
例10-31 orion-application.xmlファイル内のセキュリティ・ロール・マッピング
<security-role-mapping name="hr_managers">
<group name="hr-directors" />
</security-role-mapping>
OC4Jの再起動
OC4Jインスタンスを再起動します。
これで、WebCenterアプリケーションが使用可能になります。
Oracle Single Sign-Onでは、Oracle Internet Directoryに対してユーザーが認証されます。したがって、Oracle Single Sign-Onを使用するようにWebCenterアプリケーションを構成するには、まず、「OC4JインスタンスとOracle Internet Directoryの関連付け」の項に示された手順を実行して、Oracle Internet Directoryを使用するようにOC4Jインスタンスを構成する必要があります。
アプリケーションでOracle Single Sign-Onを使用するための手順は、次のとおりです。
Application Server Controlコンソールで、インスタンスのOC4Jホームページにナビゲートし、「管理」タブをクリックします。
表示される「管理」ページで、「セキュリティ・プロバイダ」タスクを選択します。
「SSO認証の有効化」オプションを選択します。
『Oracle Containers for J2EEセキュリティ・ガイド』の「SSOの構成（オプション）」で説明されているすべての手順を実行します。
『Oracle Containers for J2EEセキュリティ・ガイド』の手順を実行するとき、最初の手順「SSO登録ツールの実行」で、次の例を使用してSSO登録ツールを実行します。
% $ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path $ORACLE_HOME \ -site_name myhost.mydomain.com -config_mod_osso TRUE \ -mod_osso_url http://myhost.mydomain.com:7777 -remote_midtier \ -config_file $ORACLE_HOME/Apache/Apache/conf/osso/midtier_osso.conf
指定した名前で新しいファイルが作成されます。このファイルには、SSOと関連付ける中間層のSSOパートナ・アプリケーション構成が含まれます。このファイルを、構成する中間層にコピーします。
|
注意: 既存のosso.confファイルは上書きできないため、osso.confを構成ファイル名として使用すると、エラーが発生します。ファイル名は、中間層のホストおよびポートを表す名前にすることをお薦めします。たとえば、midtier1_7779_osso.confのような名前にします。 |
「OK」をクリックします。
Java Single Sign-On（SSO）ソリューションは、他のOracle Single Sign-On製品のように、追加の必須のインフラストラクチャに依存していません。Java SSOは、OracleAS JAAS Provider Identity Managementフレームワークを基礎にしています。
Java SSOを使用するようにWebCenterアプリケーションを構成するには、OC4Jインスタンスの1つでJava SSOアプリケーションを起動してから、Application Server Controlコンソールを介してJava SSOおよびパートナ・アプリケーションを構成する必要があります。
実際に実行する手順、および分散環境でこれを設定する方法の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の「OC4J Javaシングル・サインオン」を参照してください。
Java SSOは、Oracle Internet Directoryや任意の外部LDAPプロバイダとともに動作するように構成できます。このためには、Application Server Controlコンソールを使用するか、orion-application.xmlファイル内の<jazn>要素をLDAPに設定します。実際に実行する手順は、『Oracle Containers for J2EEセキュリティ・ガイド』の「OC4J Javaシングル・サインオン」を参照してください。
WebCenterアプリケーションを、外部のLDAPプロバイダをアイデンティティ・ストアとして使用するように構成できます。そのための手順は、次のとおりです。
次のいずれかの方法で、LDAPプロバイダを使用するようにWebCenterアプリケーションを構成します。
ADFセキュリティ・ウィザードを実行し、図10-56に示すような「Oracle JAASプロバイダ」画面でデフォルトの「軽量XMLプロバイダ」を選択します。次に、実行時にApplication Server Controlコンソールを使用して、LDAPベースのプロバイダ（Oracle Internet Directoryなど）を使用するようにアプリケーションを構成します。
ADFセキュリティ・ウィザードを実行し、図10-56に示すような「Oracle JAASプロバイダ」画面で「LDAPプロバイダ」を選択して、直接LDAPベースのプロバイダから開始します。この場合、開発環境で使用したLDAPプロバイダと実行時に使用するLDAPプロバイダが同じであることが期待されます。
WebCenterアプリケーションを開発し、ADFセキュリティ・ウィザードを使用して、このアプリケーションにOracle ADF Securityを設定します。
12.2.1項「WebCenterアプリケーションのパッケージ化」の手順を実行して、WebCenterアプリケーションをパッケージ化します。
12.2.2項「WebCenterアプリケーションの事前デプロイ」の手順を実行して、WebCenterアプリケーションを事前デプロイします。
12.2.3項「Application Server Controlコンソールを使用したWebCenterアプリケーションのデプロイ」の手順に従って、WebCenterアプリケーションをデプロイします。
「WebCenterアプリケーションのセキュリティ・プロバイダでOracle Internet Directoryを使用するように変更」の手順を実行し、「セキュリティ・プロバイダ・タイプ」リストから「サード・パーティのLDAPサーバー用のOracleセキュリティ・プロバイダ」を選択して、外部LDAPプロバイダをセキュリティ・プロバイダとして追加します。
初めてLDAPプロバイダを使用する場合は、「ロール・マッピングの構成」の手順を実行して、ロール・マッピングを構成します。
OC4Jを再起動します。
JAZN移行ツールを使用して、アプリケーションEARファイルの一部としてパッケージ化されているapp-jazn-data.xmlファイルから、外部LDAPプロバイダ用のXMLファイルにポリシー情報を移行します。
例10-32に、app-jazn-data.xmlファイルから外部LDAPプロバイダ用のsystem-jazn-data.xmlファイルへの移行を容易にするための構文を示します。
例10-32 XMLからXMLへの移行のサンプル
java oracle.security.jazn.tools.JAZNMigrationTool -st xml -dt xml -sf ORACLE_HOME/j2ee/OC4J_Apps/applications/webCenterArchive1/adf/META-INF/app-jazn-data.xml -df ORACLE_HOME/j2ee/OC4J_Apps/config/system-jazn-data.xml -m all
詳細は、12.2.4.3項「JAZN移行ツールの使用」を参照してください。
これは、ポリシー情報を（ターゲットのsystem-jazn-data.xmlファイルに）移行する場合のみに適用されます。外部LDAPプロバイダにはユーザーおよびグループの情報しか格納されていないため、JAZN移行ツールを使用してユーザーおよびロールの情報を直接外部LDAPプロバイダに移行することはできません。ポリシーおよびその他の情報は、XMLファイルに格納されています。JAZN移行ツールでは、外部LDAPプロバイダに適したLDIFファイルを作成できません。このツールでは、Oracle Internet Directory専用のLDIFファイルを（適切なディレクトリ情報ツリーおよびスキーマとともに）作成することができます。
移行したポリシー情報を、LDAPPrincipalを使用するように手動で編集します。
前の手順で説明したポリシー情報を移行した結果、ターゲットのsystem-jazn-data.xmlファイル内のエントリには、XMLRealmRoleプリンシパル・クラスを参照するgranteeが含まれます。外部LDAPプロバイダとともに使用する場合は、LDAPPrincipalクラスを使用するように、これらのエントリを更新する必要があります。たとえば、system-jazn-data.xmlのgrantee要素内に次のようなプリンシパル構成が含まれるとします。
<principal> <realm-name>jazn.com</realm-name> <type>role</type> <class>oracle.security.jazn.spi.xml.XMLRealmRole</class> <name>jdoe</name> </principal>
この場合、次のようにこの構成を手動で更新して、<realm-name>要素と<type>要素を削除し、XMLRealmRoleのかわりにLDAPPrincipalを指定する必要があります。
<principal> <class>oracle.security.jazn.realm.LDAPPrincipal</class> <name>jdoe</name> </principal>
名前にjazn.com/jdoeなどのレルム接頭辞が含まれる場合は、名前がjdoeのみになるように、レルム接頭辞を削除する必要があります。
外部LDAPプロバイダ内に、必要なユーザー・アカウントおよびロール・アカウントを手動で作成します。必ず、ユーザー名およびロール名は、手順9でターゲット・サーバーに移行したポリシー構成内で参照されているプリンシパルに準拠する名前にしてください。
この作業の実行方法の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。
|
関連項目: JAASモードおよびその構成方法の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の「OC4Jでの認可」を参照してください。 |
Oracle Access Manager（旧称はOracle COREid Access and Identity）を使用するようにWebCenterアプリケーションを構成するには、『Oracle Containers for J2EEセキュリティ・ガイド』の「Oracle Access Manager」を参照してください。
ファイルベースのセキュリティ・プロバイダからOracle Access Managerに切り替える際は、『Oracle Containers for J2EEセキュリティ・ガイド』の「Oracle Access Manager」に指定されているように、system-jazn-data.xml内のポリシーを更新する必要があります。
さらに、次の点を考慮してください。
grantee要素は、サブ要素realm-nameおよびtypeを持つことはできません。名前にレルムの接頭辞が含まれる場合は、その接頭辞を削除する必要があります。たとえば、jazn.com/usersはusersに変更する必要があります。
クラスoracle.security.jazn.spi.xml.XMLRealmRoleへの参照は、oracle.security.jazn.realm.CoreIDPrincipalに変更する必要があります。
例10-33に示されているgrantを、例10-34に示されているgrantに更新する必要があります。
例10-33 レルム名およびtypeサブ要素が含まれるsystem-jazn-data.xmlファイル・コンテンツ
<grant>
<grantee>
<principals>
<principal>
<realm-name>jazn.com</realm-name>
<type>role</type>
<name>page-viewer</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.MethodPermission</class>
<name>testjcr.getItems</name>
<actions>invoke</actions>
</permission>
<permission>
<class>oracle.adf.share.security.authorization.MethodPermission</class>
<name>testjcr.advancedSearch</name>
<actions>invoke</actions>
</permission>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>view.pageDefs.PortalExtAppPageDef</name>
<actions>view</actions>
</permission>
. . .
</permissions>
</grant>
例10-34 Oracle Access Managerで使用するsystem-jazn-data.xmlファイル
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jazn.realm.CoreIDPrincipal</class>
<name>page-viewer</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.share.security.authorization.MethodPermission</class>
<name>testjcr.getItems</name>
<actions>invoke</actions>
</permission>
<permission>
<class>oracle.adf.share.security.authorization.MethodPermission</class>
<name>testjcr.advancedSearch</name>
<actions>invoke</actions>
</permission>
<permission>
<class>oracle.adf.share.security.authorization.RegionPermission</class>
<name>view.pageDefs.PortalExtAppPageDef</name>
<actions>view</actions>
</permission>
. . .
</permissions>
</grant>
『Oracle Containers for J2EEセキュリティ・ガイド』に記載されている構成作業の他にも、次の作業を実行する必要があります。
初めてLDAPプロバイダを使用する場合は、「ロール・マッピングの構成」の手順を実行して、ロール・マッピングを構成します。
OC4Jを再起動します。
JAZN移行ツールを使用して、アプリケーションEARファイルの一部としてパッケージ化されているapp-jazn-data.xmlファイルから、外部LDAPプロバイダ用のXMLファイルにポリシー情報を移行します。
例10-35に、app-jazn-data.xmlファイルから外部LDAPプロバイダ用のsystem-jazn-data.xmlファイルへの移行を容易にするための構文を示します。
例10-35 XMLからXMLへの移行のサンプル
java oracle.security.jazn.tools.JAZNMigrationTool -st xml -dt xml -sf ORACLE_HOME/j2ee/OC4J_Apps/applications/webCenterArchive1/adf/META-INF/app-jazn-data.xml -df ORACLE_HOME/j2ee/OC4J_Apps/config/system-jazn-data.xml -m all
詳細は、12.2.4.3項「JAZN移行ツールの使用」を参照してください。
