Portlet URL 安全性

WebSphere® Application Server 能够直接访问 Portlet 统一资源定位符 (URL),正如 Servlet 一样。本节描述在使用 URL 访问 Portlet 时的安全性注意事项。

为了安全起见,像处理 Servlet 那样来处理 portlet。大多数 portlet 安全性使用底层的 Servlet 安全性机制。但是,portlet 安全性信息位于 portlet.xml 文件中,而 Servlet 和 JavaServer Pages 文件都位于 web.xml 文件中。另外,当对 portlet 作出访问策略时,如果 web.xml 文件中有安全性信息,那么会将它们与 portlet.xml 文件中的安全性信息组合在一起。

Portlet 安全性必须同时支持程序化安全性(即,isUserInRole)和声明式安全性。Portlet 的程序化安全性与 Servlet 的程序化安全性完全相同。但是对于 portlet,isUserInRole 方法使用 portlet.xml 文件中 security-role-ref 元素的信息。程序化安全性使用的另外两种方法 getRemoteUsergetUserPrincipal 的行为与它们在访问 Servlet 时的行为相同。这两种方法都会返回用于访问 portlet 的已认证的用户信息。

portlet 的声明式安全性方面是由 portlet.xml 文件中的安全性约束信息确定的。这与 web.xml 文件中用于 Servlet 的安全性约束信息相似,但还是存在下列差别:
  • portlet.xml 文件中不存在 auth-constraint 元素,该元素用于列示可以访问资源的角色名称。portlet.xml 文件中只包含 user-data-constraint 元素,该元素指示访问 portlet 时需要哪种类型的传输层安全性(HTTP 或 HTTPS)。
  • portlet.xml 文件中的安全性约束信息包含 portlet-collection 元素;而 web.xml 文件包含 web-resource-collection 元素。portlet-collection 元素只包含简单 portlet 名称的列表;而 web-resource-collection 包含 URL 模式以及需要保护的 HTTP 方法。

portlet 容器不直接处理用户认证。例如,它不会提示您收集凭证信息。但是,portlet 容器必须将底层的 Servlet 容器用于用户认证机制。因此,portlet.xml 文件中的安全性约束信息中没有 auth-constraint 元素。

在 WebSphere Application Server 中,当使用 URL 访问 portlet 时,将根据 web.xml 文件中该 portlet 的安全性约束信息来处理用户认证。这意味着,web.xml 文件必须包含 portlet 的安全性约束信息以及该 portlet 中包含的相关认证约束,才能针对该 portlet 来验证用户。如果该 portlet 的相应认证约束不存在于 web.xml 文件中,那么表明不需要该 portlet 也可以执行认证。在这种情况下,允许进行未经认证的访问,就像在 web.xml 文件中不包含任何 auth-constraint 的 Servlet 的 URL 模式一样。可以通过在 url-pattern 元素中使用 portlet 名称来直接指定 portlet 的 auth-constraint,也可以通过隐含 portlet 的 url-pattern 来间接指定 portlet 的 auth-constraint。

注意: 为了 WebSphere Application Server 安全性能够使用 portlet,那么不能使 Servlet 或 JSP 与 portlet 同名。

下列示例说明了如何使用 portlet 应用程序的 portlet.xmlweb.xml 文件中包含的安全性约束信息来对 portlet 作出安全性决策。因为对于 Servlet 来说 security-role-ref 元素的使用方式相同,所以本节未讨论该元素(它用于 isUserInRole 调用)。

本节随后的示例中(除非另有说明),在 portlet.xml 中定义了四个 portlet(MyPortlet1、MyPortlet2、MyPortlet3 和 MyPortlet4)。如果 web.xml 文件中存在信息,那么当直接通过 URL 来访问这些信息时,将通过对它们进行组合来保护 portlet。

所有示例都显示了 web.xmlportlet.xml 文件的内容。当创建这些部署描述符文件时,请使用您在组装 portlet 应用程序时通常会使用的正确工具。

示例 1:web.xml 文件不包含任何安全性约束数据

在以下示例中,安全性约束信息包含在 portlet.xml 中:
      <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 和 MyPortlet3 中的任何内容,并且是使用非安全的 HTTP 协议来访问这些 portlet 时,将通过安全的 HTTPS 协议为您进行重定向。设置了传输保证 (transport-guarantee) 以使用安全连接。对于 MyPortlet2 和 MyPortlet4,由于未设置传输保证,因此允许进行非安全的 (HTTP) 访问。所有这四个 portlet 在 web.xml 文件中都没有相应的安全性约束信息。因此,无须任何用户认证和角色授权就可以访问所有这些 portlet。这种情况下唯一涉及到的安全性就是传输层安全性,即,对 MyPortlet1 和 MyPortlet3 使用安全套接字层 (SSL)。

.
表 1. 适用于各个 portlet 的安全性约束. 下表列示了适用于各个 portlet 的安全性约束。
URL 传输保护 用户认证 基于角色的授权
/MyPortlet1/* HTTPS None None
/MyPortlet2/* None None None
/MyPortlet3/* HTTPS None None
/MyPortlet4/* None None None

示例 2:web.xml 文件包含特定于 portlet 的安全性约束数据

在以下示例中,web.xml 中包含与 portlet 相对应的安全性约束信息。portlet.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 文件中包含的安全性约束信息指示 - 在访问 MyPortlet1 和 MyPortlet2 这两个 portlet 中的任何内容时必须执行用户认证。当尝试直接使用 URL 来访问这些 portlet 并且没有提供任何认证信息时,将提示您输入它们的凭证。经过认证之后,将执行授权检查以了解您是否是作为 Employee 角色列出的。在部署 portlet 应用程序期间,将指定用户/组至角色的映射。在先前列出的 web.xml 文件中,请注意下列事项:
  • 因为 web.xml 文件使用 URL 模式,所以已对 portlet 名称稍作修改。MyPortlet1 现在已修改为 /MyPortlet1/*,它指示 MyPortlet1 URL 中的所有内容都是受保护的。这与 portlet.xml 文件中的信息是相匹配的,这是因为安全性运行时代码会将 portlet.xml 文件中的 portlet-name 元素转换为 URL 模式(例如,将 MyPortlet1 转换为 /MyPortlet1/*),即使对于传输保证也是如此。
  • 由于所有 HTTP 方法都必须是受保护的,因此,在该示例中,web.xml 文件中未使用 http-method 元素。
表 2. 适用于各个 portlet 的安全性约束. 下表列示了适用于各个 portlet 的新安全性约束。
URL 传输保护 用户认证 基于角色的授权
MyPortlet1/* HTTPS 是(职员)
MyPortlet2/* None 是(职员)
MyPortlet3/* HTTPS None None
MyPortlet4/* None None None

示例 3:web.xml 文件包含了隐含所有 portlet 的通用安全性约束数据。

在以下示例中,安全性约束信息包含在与 portlet 相对应的 web.xml 文件中。portlet.xml 文件与第一个示例中的 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>

在此示例中,/* 表示“管理员”角色应当根据 URL 模式匹配规则对不包含自身的显式安全性约束的所有资源进行保护。因为 portlet.xml 文件中包含 MyPortlet1 和 MyPortlet3 的显式安全性约束信息,所以这两个 portlet 不受“管理员”角色保护,只受 HTTPS 传输保护。因为 portlet.xml 文件不能包含 auth-constraint 信息,所以当 web.xml 文件中按照 URL 匹配规则列示了隐含的 URL(例如,/*)时,其 portlet.xml 中包含安全性约束的任何 portlet 都将表现为不受保护。

在先前的情况下,无须经过用户认证就可以访问 MyPortlet1 和 MyPortlet3。但是,因为 MyPortlet2 和 MyPortlet4 在 portlet.xml 文件中没有安全性约束,所以 /* 模式用来匹配这些 portlet 并且受“管理员”角色保护,这将需要进行用户认证。

表 3. 适用于各个 portlet 的安全性约束. 下表列示了适用于具有此设置的各个 portlet 的新安全性约束。
URL 传输保护 用户认证 基于角色的授权
MyPortlet1/* HTTPS None None
MyPortlet2/* None 是(管理员)
MyPortlet3/* HTTPS None None
MyPortlet4/* None 是(管理员)
在上一个示例中,如果还必须保护 portlet.xml 文件中包含的 portlet(例如,MyPortlet1),那么 web.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 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 文件中的信息组合在一起,所以还会对 MyPortlet1 应用数据约束 CONFIDENTIAL。因为 MyPortlet3 未显式列示在 web.xml 文件中,所以它仍然不受“管理员”角色保护并且不需要进行用户认证。

表 4. 适用于各个 portlet 的安全性约束. 下表显示了此更改的影响。
URL 传输保护 用户认证 基于角色的授权
MyPortlet1/* HTTPS 是(管理员)
MyPortlet2/* None 是(管理员)
MyPortlet3/* HTTPS None None
MyPortlet4/* None 是(管理员)

指示主题类型的图标 概念主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_portlet_url_sec
文件名:csec_portlet_url_sec.html