ポートレット 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 つのメソッド (getRemoteUser と getUserPrincipal) は、 それらがサーブレットにアクセスするときと同じように振る舞います。 これらのメソッドは、ともにポートレットにアクセスする認証済みユーザー情報を戻します。
- auth-constraint エレメントは、リソースにアクセスできるロールの名前をリストしますが、 portlet.xml ファイルには存在しません。 portlet.xml ファイルに含まれるのは、 user-data-constraint エレメントだけです。 これは、ポートレットにアクセスする場合に、 どのタイプのトランスポート層セキュリティー (HTTP または HTTPS) が必要であるかということを示しています。
- portlet.xml ファイル内の security-constraint 情報には portlet-collection エレメントが含まれ ていますが、web.xml ファイルには web-resource-collection エレメントが含まれています。 portlet-collection 要素に含まれるのは、 単純なポートレット名のリストだけですが、 web-resource-collection には url-pattern と保護が必要な HTTP メソッドが含まれています。
ポートレット・コンテナーは、直接にはユーザー認証を処理しません。 例えば、このコンテナーでは、クレデンシャルの収集を指示するプロンプトは出されません。 代わりに、ポートレット・コンテナーは、 ユーザー認証メカニズムに対して基礎となるサーブレット・コンテナーを使用します。 結果として、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 によって間接的に指定したりすることができます。
以下の例では、 ポートレット・アプリケーションの 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 データは含まれていません。
<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 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 ファイルは url-pattern を使用するため、ポートレット名は若干変更されています。 MyPortlet1 は /MyPortlet1/* になります。 これは、MyPortlet1 URL の下にあるすべてが保護されていることを示しています。 これは、portlet.xml ファイル内の情報に一致します。 その理由は、transport-guarantee の場合であっても、セキュリティー・ランタイム・コードによって、 portlet.xml ファイル内の portlet-name エレメントが url-pattern に変換される (例えば、MyPortlet1 から /MyPortlet1/* に) ためです。
- すべての HTTP メソッドを保護する必要があるため、 web.xml ファイル内の http-method エレメントはこの例では使用されません。
URL | トランスポート保護 | ユーザー認証 | ロール・ベースの許可 |
---|---|---|---|
MyPortlet1/* | HTTPS | はい | はい (従業員) |
MyPortlet2/* | なし | はい | はい (従業員) |
MyPortlet3/* | HTTPS | なし | なし |
MyPortlet4/* | なし | なし | なし |
例 3: 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 を含まないすべてのリソースが、 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/* | なし | はい | はい (管理者) |
<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/* | なし | はい | はい (管理者) |