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 元素的信息。程序化安全性使用的另外两种方法 getRemoteUser 和 getUserPrincipal 的行为与它们在访问 Servlet 时的行为相同。这两种方法都会返回用于访问 portlet 的已认证的用户信息。
- 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。
下列示例说明了如何使用 portlet 应用程序的 portlet.xml 和 web.xml 文件中包含的安全性约束信息来对 portlet 作出安全性决策。因为对于 Servlet 来说 security-role-ref 元素的使用方式相同,所以本节未讨论该元素(它用于 isUserInRole 调用)。
本节随后的示例中(除非另有说明),在 portlet.xml 中定义了四个 portlet(MyPortlet1、MyPortlet2、MyPortlet3 和 MyPortlet4)。如果 web.xml 文件中存在信息,那么当直接通过 URL 来访问这些信息时,将通过对它们进行组合来保护 portlet。
所有示例都显示了 web.xml 和 portlet.xml 文件的内容。当创建这些部署描述符文件时,请使用您在组装 portlet 应用程序时通常会使用的正确工具。
示例 1:web.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)。
URL | 传输保护 | 用户认证 | 基于角色的授权 |
---|---|---|---|
/MyPortlet1/* | HTTPS | None | None |
/MyPortlet2/* | None | None | None |
/MyPortlet3/* | HTTPS | None | None |
/MyPortlet4/* | None | None | None |
示例 2:web.xml 文件包含特定于 portlet 的安全性约束数据
<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 模式,所以已对 portlet 名称稍作修改。MyPortlet1 现在已修改为 /MyPortlet1/*,它指示 MyPortlet1 URL 中的所有内容都是受保护的。这与 portlet.xml 文件中的信息是相匹配的,这是因为安全性运行时代码会将 portlet.xml 文件中的 portlet-name 元素转换为 URL 模式(例如,将 MyPortlet1 转换为 /MyPortlet1/*),即使对于传输保证也是如此。
- 由于所有 HTTP 方法都必须是受保护的,因此,在该示例中,web.xml 文件中未使用 http-method 元素。
URL | 传输保护 | 用户认证 | 基于角色的授权 |
---|---|---|---|
MyPortlet1/* | HTTPS | 是 | 是(职员) |
MyPortlet2/* | None | 是 | 是(职员) |
MyPortlet3/* | HTTPS | None | None |
MyPortlet4/* | None | None | None |
示例 3:web.xml 文件包含了隐含所有 portlet 的通用安全性约束数据。
<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 并且受“管理员”角色保护,这将需要进行用户认证。
URL | 传输保护 | 用户认证 | 基于角色的授权 |
---|---|---|---|
MyPortlet1/* | HTTPS | None | None |
MyPortlet2/* | None | 是 | 是(管理员) |
MyPortlet3/* | HTTPS | None | None |
MyPortlet4/* | None | 是 | 是(管理员) |
<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 文件中,所以它仍然不受“管理员”角色保护并且不需要进行用户认证。
URL | 传输保护 | 用户认证 | 基于角色的授权 |
---|---|---|---|
MyPortlet1/* | HTTPS | 是 | 是(管理员) |
MyPortlet2/* | None | 是 | 是(管理员) |
MyPortlet3/* | HTTPS | None | None |
MyPortlet4/* | None | 是 | 是(管理员) |