- Japan
- [ 変更 ]
 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IBM WebSphere Portalで実行されるJSR 168ポートレットでのJ2EE役割の活用 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dieter Buehler (buehlerd@de.ibm.com), Security Architect, IBM レベル：中級 原文の掲載：2007年3月14日
はじめにWebSphere Portalは高度なアクセス制御管理モデルを提供します。システム管理者はこのモデルで、個々のユーザーに対し、ポータル・ページやポートレットなどの個々のポータル・リソースへのアクセス権を定義できます(『リソース』の項目 [1] および [4] を参照)。このモデルは、個々のポータル・リソースへの一般的なアクセスに関しては非常に柔軟に許可するが(たとえば、Bob にPetShopPortlet の参照を許可するかどうか)、個々のポートレットのビジネス・ロジックにおける特定の操作の保護についてはサポートしていません(たとえば、Bob にPetShopPortlet を通じた価格情報の変更を許可するかどうか)。 J2EE仕様 [5] では、このユース・ケースのための役割の概念が定義されています。これらの役割を使用して、J2EEサーブレットおよびEJBによって公開される機能へのアクセスを保護することができます。さらに、これらの役割をプログラマチックに使用して、サーブレットで用いられている方法と非常によく似た方法でJSR 168ポートレット[6]内のアクセスを制御できます。ポートレットが利用できる機能に制限はありますが、ポートレットでJ2EE役割を使用することは、JSR 168ポートレットによって実装されているビジネス・ロジックへのアクセスを許可する上で柔軟かつ確実な方法です。 この記事では、ポートレット内で使用できるJ2EE権限の概念について紹介します。次に、ポートレット開発者の観点から、これらの概念の活用方法を説明します。最後に、システム管理者の観点から、役割の割り当て方法(ユーザーにビジネス・ロジックへのアクセス権を付与する方法)を説明します。
JSR 168ポートレットで利用できるJ2EE権限の概念このセクションでは、JSR 168ポートレットとともに使用できるJ2EEサーブレットのために定義されたJ2EE権限の概念の一部について説明します。 J2EEサーブレット用の権限は、宣言型の権限とプログラマチックな権限の2つに分けられます。宣言型の権限を使用すると、特定のWebリソース・コレクションに対して、特定のユーザーのみアクセスできるよう制限できます。ここで述べるWebリソース・コレクションとは、HTTPアクションとWebリソースのセットという意味であり、アスタリスク‘*’のワイルド・カードに基づくURLパターンを使用して定義します。ポートレットは、常にポータル経由で間接的にアクセスされます。したがって、この権限の概念は個々のポートレットには意味をなしません。 宣言型の権限に対し、プログラマチックな権限はJSR 168ポートレットでたいへん役に立ちます。サーブレットでのプログラマチックなJ2EEセキュリティーは、 javax.servlet.http.HttpServletRequest インターフェースで3つのメソッドをサポートします。これにより、機密操作を実行したり、操作用のユーザー・インターフェース・ウィジェット(たとえば、HTMLフォーム・ボタンなど)を公開する前に、サーブレット・コード内のアクセス特権をプログラマチックにチェックできます。3つのメソッドは以下のとおりです。
JSR 168 javax.portlet.PortletRequest インターフェースは、同等の意味を持つ同じメソッドを定義します。最初の2つのメソッドは、現在の要求を実行している認証済みユーザーに関する情報を提供するのに対し、isUserInRole()メソッドを使用すると、システム管理者によってこのユーザーに特定の権限役割が付与されているかどうかをチェックできます。このため、権限を許可するユース・ケースでは、isUserInRole()メソッドが特に注目されます。このメソッドにより、ポートレット開発者がこの重要なセキュリティー情報を扱う必要性をなくし、アプリケーション・サーバー・ランタイム内で役割の割り当てデータを維持することができます。 それでは、J2EE役割の概念およびisUserInRole()メソッドについて詳しく見ていきましょう。 J2EE役割 の概念およびisUserInRole()メソッドについて詳しく見ていきましょう。J2EE役割は、システム管理者を通じて個々のユーザーまたはユーザー・グループに割り当てられる、名前付きの特権セットとして定義されます。このような役割に含まれる特権は、宣言的な方法を用いてサーブレット・デプロイメント記述子で定義されます。前のセクションで述べたように、宣言的な方法によって役割に与えられた特権のセットは、URLでのHTTP関連アクションに制限されていて、ポートレット・コンテキストでは意味のある使い方はできません。しかし、ポートレットのビジネス・ロジックでは、追加のビジネス・レイヤー特権をこれらの役割に関連付けることが可能です。 たとえば、前述の架空の PetShopPortlet は、価格情報を変更する特権を ShopOwner という名前の役割に関連付けることができます。これにより、ポートレットのインプリメンテーションは、ユーザーに価格情報の変更を許可する前に、現在のユーザーに ShopOwner 役割が付与されているかどうかをチェックします。一般に、これは以下の2つのことを意味します。
PetShopPortlet をホスティングしているWebSphere Portalサーバー・インスタンスの管理者は、WebSphereコンソールを使用して、構成済みのユーザー・レジストリーに含まれる個々のユーザーまたはユーザー・グループを ShopOwner J2EE役割にマッピングすることができ、これらのユーザーとグループは「価格情報の変更」が事実上許可されます。 ポートレット開発者は、ポートレットによってインプリメントされているビジネス・ロジックに応じて、任意の数の役割を定義できます。たとえば、PetShopPortlet は追加の Visitor 役割と Customer 役割を定義し、ショップに入ってきたユーザーにはVisitor役割を割り当て、取引を認められたユーザーにはCustomer役割を割り当てることができます。 同じユーザーまたはユーザー・グループに、複数の役割を割り当てられます。WebSphere Application Serverは、これらの役割が割り当てられた各ユーザーに対して、役割がユーザーに直接割り当てられたのか、あるいはユーザーが属しているユーザー・グループの少なくとも1つに割り当てられたものかを判断します。 前のセクションで述べたように、宣言型の権限は意味のある方法でポートレットに使用することができません。プログラマチックなJ2EE権限には、WebSphere Portal V6.0内のポートレットに対し制限があります。 J2EE役割宣言の使用およびプログラマチックなisUserInRole()チェックがサポートされているのに対し(前のセクションで説明)、現在、J2EEのsecurity-role-ref概念はWebSphere Portal V6.0のポートレットには使用できません。Javaポートレット仕様1.0で宣言されているように、security-role-refの概念により、役割マッピングの間接参照の別のレイヤーが導入され、Webモジュール・レイヤーに役割を定義できるようになります(web.xmlデプロイメント記述子で<security-role>要素を使用します)。これは、個々のポートレット用に異なる名前が付けられた役割にマッピングできます(対応する<portlet>要素にネストされた<security-role-ref>要素を使用します)。<security-role-ref>要素で定義された役割名は、ポートレット・コードに表示される役割名となります(つまり、isUserInRole()チェックに渡された文字列と一致する必要があります)。<security-role>要素内の名前は、役割の割り当てを管理するシステム管理者に表示される役割名です。 この間接参照により、同じWebモジュール内の異なるポートレットによって公開された個々の役割を、同じWebモジュール・レイヤーのセキュリティー役割名にマッピングできます。このセキュリティー役割をユーザーに割り当てることにより、すべてのポートレット・レベルの役割(<security-role-ref>要素にリンクされたものなど)も、暗黙的にそのユーザーに割り当てられます。 JSR 168ポートレットに使用されているportlet.xmlデプロイメント記述子は、security-role-ref間接参照を含む<portlet>要素を公開します。残念ながら、現在、この間接参照はWebSphere Portal V6.0ではサポートされていません。しかし、幸運なことに、Webモジュール・レイヤーの<security-role>要素内で使用されている役割名は、isUserInRole()メソッドによって直接参照することができます。次のセクションでは、これらが相互にどのように動作するのかを例を用いて説明します。
セキュリティー役割デモ・ポートレットダウンロード・サンプル・ポートレット は、JSR 168ポートレット内でのJ2EE役割の使い方のデモを示します。これは、たいへん小さくかつ単純なポートレットなので、J2EE権限のアスペクトに焦点を当てることができます。このサンプル・ポートレットは、以下の方法を示します。
参考のために、デプロイ可能なポートレットおよび対応するソース・コードがこの記事に添付されています。 役割は、ポートレットのweb.xmlデプロイメント記述子で宣言されます。manager および employee という2つの役割を定義するコードの部分をリスト1に示します。 リスト1. web.xmlデプロイメント記述子での役割の宣言
それぞれの<security-role>要素は、与えられたWebモジュールで定義された1つのJ2EE役割を表します。これには、必須の<role-name>サブ要素とオプションの <description> 要素が含まれます。役割の割り当てを管理するときに、役割名と役割の説明の両方が、WebSphere管理コンソールでシステム管理者に表示されます。このため、システム管理者がどの役割をどのユーザーに付与するのかを意識的に決められるように、個々の役割の特権がわかるように説明を記述してください。 <security-role>要素の<role-name>サブ要素で指定された名前をisUserInRole()メソッドで使用すると、この役割が、現在ポートレット要求を実行しているユーザーに付与されているかどうかをプログラマチックにチェックできます。これについては、次のセクションで説明します。 ポートレット・コードおよびポートレットとともにパッケージされたJSPは、javax.portlet.PortletRequestインターフェースによって公開されるisUserInRole()メソッドを使用して、指定されたポートレット要求を実行しているユーザーに、ポートレットのweb.xmlデプロイメント記述子で定義されたJ2EE役割の1つが割り当てられているかどうかを検証できます。セキュリティー役割デモ・ポートレットのview.jspは、次のコードを使用して、現在のユーザーの役割の割り当てをチェックします。 リスト2. isUserInRole()メソッドを使用した役割の割り当てのチェック
このJSPは、前の手順で定義された2つの役割 manager と employee をチェックし、各役割が現在のユーザーに割り当てられているかどうかをテキストで示します。実際のアプリケーションでは、ポートレットはこれらのテストに基づいてユーザー・インターフェースを調整し(つまり、現在のユーザーに manager 役割が割り当てられている場合にのみ、管理操作用のユーザー・インターフェース・コンポーネントを公開します)、対応する操作を実行する前に、これらの役割の割り当てを検証します。 isUserInRole()メソッドに渡された文字列リテラルは、対応する<security-role>要素内(リスト1)でネストされた<role-name>要素で指定された値に、正確に一致しなければなりません。 J2EE役割ベースの権限を用いるポートレットは、事前デプロイ・モードを使用して常にWebSphere Portalにデプロイする必要があります。つまり、対応するポータル管理ポートレットを使用してポートレットをWebSphere Portalにインストールせずに、まず、ポートレットのWARファイルをWebSphere Application Serverにインストールし、その後、XML構成インターフェースを用いてポートレットをWebSphere Portalに登録します。ポートレットが事前デプロイ・モードを使用してインストールされていない場合は、ポータル管理ポートレットを通じてポートレットを更新するときに、既存の役割の割り当てが失われます。事前デプロイ・モードの詳細については、WebSphere Portal Information Center [9] を参照してください。 ポートレットのデプロイメント中に、セキュリティー役割デモ・ポートレットによって定義された manager 役割または employee 役割を、初期状態としてユーザーに割り当てることができます。 図1. ポートレット・デプロイメント時の役割の初期割り当ての定義  図1に示すように、employee 役割は、システムへの認証に成功したどのユーザーにも割り当てることができます(特に、WebSphere Application Serverによってサポートされている仮想の「全認証者」ユーザー・グループにこの役割を割り当てます)。この例では、従業員だけがポータルへのログインを許可されているものとします。次に、manager役割は、対応する識別名(uid=wpsadmin,o=Default Organization)で識別された1人のユーザーに付与されます。 対応するWebSphere Application Server管理ユーザー・インターフェース(管理コンソール)を使用すると、後で役割の割り当ての追加ができ、また既存の役割の割り当て変更が可能です。WebSphere Application Serverで利用できる役割の割り当て管理機能の詳細については、WebSphere Application Server InfoCenter [3] を参照してください。 ポートレットの動作を検証するために、一般のユーザーがアクセスしたときと(図2参照)、前の手順で manager 役割が付与されたwpsadminユーザーがアクセスしたときで、ポートレットによって生成される出力を比較します。 図2. 一般ユーザーに実行されたセキュリティー役割デモ・ポートレット  図3. manager役割が割り当てられたユーザーに実行されたセキュリティー役割デモ・ポートレット  図2、3からわかるように、前のセクションで説明したJSPは、既存の役割の割り当てを正しく表示しています。
まとめJ2EE役割は、JSR 168ポートレットのビジネス・ロジックに実装された機密操作へのアクセスを許可するために使用できます。サーブレット内のJ2EE権限と比較すると、ポートレットに制限はありますが(宣言的な権限の制約はサポートされません)、ポートレット開発者は、J2EE役割の中心的な概念である役割の割り当てとisUserInRole()メソッドを利用できます。現在、IBM WebSphere Portal V6で唯一欠けているのは、<security-role-ref>の間接参照がまだサポートされていない点です。システム管理者は、既知のJ2EE役割の割り当て管理機能を使用して、特定のポートレット機能への特権の付与や取り消しができます。 この手法の大きな利点は、実際のセキュリティー・ポリシー・データ(誰に何が許可されているか)が、単にJ2EE役割の割り当てとして、IBM WebSphere Application Serverのセキュリティー・ランタイム内で維持されることです。これにより、個々のポートレット開発者はこのアスペクトについて気にする必要がなく、サーバー・セキュリティーの漏えいにつながる領域でコーディング・ミスを効果的に防ぐことができます。さらに、IBM WebSphere Application Server で利用可能なすべてのセキュリティー・インフラストラクチャー統合サポート(JACC(Java Authorization Contract for Containers)による外部権限プロバイダーの統合など)を、これらの役割の割り当てに使用することができます。
ダウンロード
リソース
筆者について（原文のまま）
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
