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) は、 それらがサーブレットにアクセスするときと同じように振る舞います。 これらのメソッドは、ともにポートレットにアクセスする認証済みユーザー情報を戻します。
ポートレット・コンテナーは、直接にはユーザー認証を処理しません。 例えば、このコンテナーでは、クレデンシャル情報の収集を指示するプロンプトは出されません。 代わりに、ポートレット・コンテナーは、 ユーザー認証メカニズムに対して基礎となるサーブレット・コンテナーを使用します。 結果として、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>
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/* | なし | はい | はい (管理者) |