WebSphere Application Server Network Deployment for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

ポートレット URL のセキュリティー

WebSphere Application Server は、サーブレットのように、 ポートレット Uniform Resource Locator (URL) への直接アクセスを可能にします。 このセクションでは、URL を使用してポートレットにアクセスする際のセキュリティーの考慮事項について説明します。

セキュリティー目的のために、ポートレットは、サーブレットと同様に処理されます。 ほとんどのポートレット・セキュリティーは、基礎となるサーブレット・セキュリティー・メカニズムを使用します。 ただし、サーブレットと JavaServer Pages ファイルが web.xml ファイル内にあるのに対して、 ポートレット・セキュリティー情報は portlet.xml 内にあります。 また、ポートレットに対するアクセス決定を行う場合、 web.xml ファイル内にセキュリティー情報がある場合は、 それが portlet.xml ファイル内のセキュリティー情報と結合されます。

ポートレット・セキュリティーでは、 プログラマチック・セキュリティー (isUserInRole) と宣言セキュリティーの両方がサポートされている必要があります。 プログラマチック・セキュリティーは、サーブレットの場合と完全に同じです。 ただし、ポートレットの場合、isUserInRole メソッドは、 portlet.xml 内の security-role-ref 要素からの情報を使用します。 プログラマチック・セキュリティーで使用されるほかの 2 つのメソッド (getRemoteUsergetUserPrincipal) は、 それらがサーブレットにアクセスするときと同じように振る舞います。 これらのメソッドは、ともにポートレットにアクセスする認証済みユーザー情報を戻します。

ポートレットの宣言セキュリティーの性質は、 portlet.xml ファイル内の security-constraint 情報によって定義されます。 これは、サーブレットに使用される web.xml ファイル内の security-constraint 情報に類似していますが、 その違いは以下のとおりです。

ポートレット・コンテナーは、直接にはユーザー認証を処理しません。 例えば、このコンテナーでは、クレデンシャル情報の収集を指示するプロンプトは出されません。 代わりに、ポートレット・コンテナーは、 ユーザー認証メカニズムに対して基礎となるサーブレット・コンテナーを使用します。 結果として、portlet.xml ファイル内の security-constraint 情報には、 auth-constraint 要素はありません。

WebSphere Application Server では、URL を使用してポートレットにアクセスすると、 web.xml ファイル内にあるそのポートレットの security-constraint 情報に基づいてユーザー認証が処理されます。 これは、ポートレットのユーザーを認証する場合、 web.xml ファイルに、 そのポートレットの security-constraint 情報が含まれており、 その security-constraint 情報に関連する auth-constraint が含まれていなければならないことを意味します。 対応するポートレットの auth-constraint が web.xml ファイルにない場合は、 ポートレットに認証が必要でないことを示します。 この場合は、サーブレットの URL パターンのような非認証アクセスが許可されます。 この URL パターンでは、web.xml ファイルに auth-constraint は含まれていません。 ポートレットの auth-constraint は、url-pattern 要素内のポートレット名を使用して直接指定したり、 ポートレットを意味する url-pattern によって間接的に指定したりすることができます。

注: ポートレットと連動する WebSphere Application Server セキュリティーのポートレットと同じ名前のサーブレットまたは JSP を持つことはできません。

以下の例では、 ポートレット・アプリケーションの portlet.xml ファイルと web.xml ファイルに含まれる security-constraint 情報を使用して、 ポートレットに対するセキュリティー決定を行う方法を例示します。 isUserInRole 呼び出しに使用される security-role-ref エレメントについては、 サーブレットと同じ方法で使用されるため、ここでは説明しません。

以下の例では (別途記載されない限り)、4 つのポートレット (MyPortlet1、 MyPortlet2、MyPortlet3、MyPortlet4) が portlet.xml に定義されています。 ポートレットは、URL を介して直接アクセスされる場合、 web.xml ファイル内の情報 (ある場合) と結合されることによって保護されます。

すべての例で、web.xml ファイルと portlet.xml ファイルの内容が示されます。 これらのデプロイメント記述子ファイルを作成する場合は、通常、ポートレット・アプリケーションをアセンブルするときのように、 適切なツールを使用してください。

例 1: web.xml ファイルには、security-constraint データは含まれていません。

以下の例では、portlet.xml に security-constraint 情報が含まれています。
      <security-constraint>
         <display-name>Secure Portlets</display-name>
         <portlet-collection>
         <portlet-name>MyPortlet1</portlet-name>
         <portlet-name>MyPortlet3</portlet-name>
         </portlet-collection>
         <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
         </user-data-constraint>
      </security-constraint>

この例では、MyPortlet1 and MyPortlet3 の下で何らかのものにアクセスした場合、 およびこれらのポートレットが保護されていない HTTP プロトコルを使用してアクセスされた場合、 ユーザーはセキュア HTTPS プロトコルを介してリダイレクトされます。 transport-guarantee は、セキュア接続を使用するように設定されます。 MyPortlet2 および MyPortlet4 の場合は、transport-guarantee が設定されていないため、 保護されていない (HTTP) アクセスが許可されます。 web.xml ファイルには、4 つのポートレットのいずれについても、 対応する security-constraint 情報はありません。 したがって、すべてのポートレットに、ユーザー認証と役割許可なしでアクセスすることができます。 このインスタンスに関係する唯一のセキュリティーは、 MyPortlet1 および MyPortlet3 の Secure Sockets Layer (SSL) を使用する transport-layer セキュリティーです。

次の表に、個々のポートレットに適用できるセキュリティー制約をリストします。
URL トランスポート保護 ユーザー認証 役割ベースの許可
/MyPortlet1/* HTTPS なし なし
/MyPortlet2/* なし なし なし
/MyPortlet3/* HTTPS なし なし
/MyPortlet4/* なし なし なし

例 2: web.xml ファイルには、ポートレット固有の security-constraint データが含まれています。

次の例では、ポートレットに対応する security-constraint 情報は web.xml に含まれています。 portlet.xml ファイルは、前の例で示したものと同じです。
<security-constraint id="SecurityConstraint_1">
    <web-resource-collection id="WebResourceCollection_1">
      <web-resource-name>Protected Area</web-resource-name>
      <url-pattern>/MyPortlet1/*</url-pattern>
      <url-pattern>/MyPortlet2/*</url-pattern>
      </web-resource-collection>
    <auth-constraint id="AuthConstraint_1">
      <role-name>Employee</role-name>
    </auth-constraint>
</security-constraint>
この例の web.xml ファイルに含まれている security-constraint 情報は、 MyPortlet1 および MyPortlet2 ポートレットの下で、何らかのものにアクセスするときに、ユーザー認証 を行う必要があることを示しています。 URL を使用してこれらのポートレットに直接アクセスする場合に、 使用可能な認証情報がないときは、クレデンシャルを入力するようプロトコルが出されます。 認証された後で、許可検査が行われ、従業員役割にリストされているかを確認されます。 ユーザー/グループから役割へのマッピングは、ポートレット・アプリケーションのデプロイ時に割り当てられます。 前述のリストされた web.xml ファイルで、次のことに注意してください。
次の表に、個々のポートレットに適用できる新規セキュリティー制約をリストします。
URL トランスポート保護 ユーザー認証 役割ベースの許可
MyPortlet1/* HTTPS はい はい (従業員)
MyPortlet2/* なし はい はい (従業員)
MyPortlet3/* HTTPS なし なし
MyPortlet4/* なし なし なし

例 3: web.xml ファイルには、すべてのポートレットを意味する汎用の security-constraint データが含まれています。

以下の例では、ポートレットに対応する web.xml ファイルに security-constraint 情報が含まれています。 portlet.xml ファイルは、最初の例で示したものと同じです。
<security-constraint id="SecurityConstraint_1">
    <web-resource-collection id="WebResourceCollection_1">
      <web-resource-name>Protected Area</web-resource-name>
      <url-pattern>/*</url-pattern>
      </web-resource-collection>
    <auth-constraint id="AuthConstraint_1">
      <role-name>Manager</role-name>
    </auth-constraint>
    </security-constraint>

この例では、/* は、その独自の明示的な security-constraint を含まないすべてのリソースが、 URL パターンの突き合わせルールに従って、 管理者役割によって保護される必要があることを意味します。 portlet.xml ファイルには、MyPortlet1 および MyPortlet3 の 明示的な security-constraint 情報が含まれているため、 これら 2 つのポートレットは、マネージャー役割によって 保護されず、HTTPS トランスポートでのみ保護されます。 portlet.xml ファイルには auth-constraint 情報を 含めることができないので、security-contraints が 含まれているポートレットは、 暗黙指定する URL (例えば /*) が URL 突き合わせルールに 従って web.xml ファイルにリストされている場合は、 いずれも無保護でレンダリングされます。

前述のケースでは、ユーザー認証なしに MyPortlet1 と MyPortlet3 の両方にアクセスできます。 ただし、MyPortlet2 と MyPortlet4 の場合、portlet.xml ファイル に security-constraints がないため、/* パターンを 使用して、これらのポートレットを突き合わせます。 また、これらのポートレットは、 マネージャー役割によって保護されるので、 ユーザー認証が必要です。

次の表に、このようなセットアップの個々のポートレットに適用できる新規セキュリティー制約 をリストします。
URL トランスポート保護 ユーザー認証 役割ベースの許可
MyPortlet1/* HTTPS なし なし
MyPortlet2/* なし はい はい (管理者)
MyPortlet3/* HTTPS なし なし
MyPortlet4/* なし はい はい (管理者)
前述の例では、portlet.xml ファイルに 含まれるポートレット (例えば、MyPortlet1) も保護する必要がある 場合、web.xml ファイルには、 次の例に示すように、/* のほかに 明示的な security-constraint 項目が含まれていなければなりません。
<security-constraint id="SecurityConstraint_1">
         <web-resource-collection id="WebResourceCollection_1">
            <web-resource-name>Protected Area</web-resource-name>
            <url-pattern>/*</url-pattern>
            </web-resource-collection>
         <auth-constraint id="AuthConstraint_1">
            <role-name>Manager</role-name>
          </auth-constraint>
      </security-constraint>
      <security-constraint id="SecurityConstraint_2">
         <web-resource-collection id="WebResourceCollection_2">
            <web-resource-name>Protection for MyPortlet1</web-resource-name>
            <url-pattern>/MyPortlet1/*</url-pattern>
            </web-resource-collection>
         <auth-constraint id="AuthConstraint_1">
            <role-name>Manager</role-name>
          </auth-constraint>
      </security-constraint>

この場合、MyPortlet1 は管理者役割によって保護されているので、認証が必要です。 web.xml ファイルと portlet.xml ファイル内の 情報が結合されているため、 このケースには、CONFIDENTIAL の data-constraint も 適用されます。 MyPortlet3 は、web.xml ファイルで 明示的にリストされていないため、 やはりマネージャー役割では保護されず、 ユーザー認証は必要ありません。

次の表に、この変更の効果を示します。
URL トランスポート保護 ユーザー認証 役割ベースの許可
MyPortlet1/* HTTPS はい はい (管理者)
MyPortlet2/* なし はい はい (管理者)
MyPortlet3/* HTTPS なし なし
MyPortlet4/* なし はい はい (管理者)



関連概念
Web コンポーネント・セキュリティー
認証メカニズム
関連タスク
アセンブリー・ツールを使用した Web アプリケーションの保護
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 8:28:52 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/info/iseriesnd/ae/csec_portlet_url_sec.html