Portlet URL security
WebSphere® Application Server enables direct access to portlet Uniform Resource Locators (URLs), just like servlets. This section describes security considerations when accessing portlets using URLs.
For security purposes, portlets are treated similar to servlets. Most portlet security uses the underlying servlet security mechanism. However, portlet security information resides in the portlet.xml file, while the servlet and JavaServer Pages files reside in the web.xml file. Also, when you make access decisions for portlets, the security information, if any, in the web.xml file is combined with the security information in the portlet.xml file.
Portlet security must support both programmatic security, that is isUserInRole, and declarative security. The programmatic security is exactly the same as for servlets. However, for portlets, the isUserInRole method uses the information from the security-role-ref element in portlet.xml. The other two methods used by programmatic security, getRemoteUser and getUserPrincipal, behave the same way as they do when accessing a servlet. Both of these methods return the authenticated user information accessing the portlet.
- The auth-constraint element, which lists the names of the roles that can access the resources, does not exist in the portlet.xml file. The portlet.xml file contains only the user-data-constraint element, which indicates what type of transport layer security (HTTP or HTTPS) is required to access the portlet.
- The security-constraint information in the portlet.xml file contains the portlet-collection element, while the web.xml file contains the web-resource-collection element. The portlet-collection element contains only a list of simple portlet names, while the web-resource-collection contains the url-patterns as well as the HTTP methods that need protection.
The portlet container does not deal with the user authentication directly. For example, it does not prompt you to collect the credential information. The portlet container must, instead, use the underlying servlet container for the user authentication mechanism. As a result, there is no auth-constraint element in the security-constraint information in the portlet.xml file.
In WebSphere Application Server, when a portlet is accessed using a URL, the user authentication is processed based on the security-constraint information for that portlet in the web.xml file. This implies that to authenticate a user for a portlet, the web.xml file must contain the security-constraint information for that portlet with the relevant auth-constraints contained in it. If a corresponding auth-constraint for the portlet does not exist in the web.xml file, it indicates that the portlet is not required to have authentication. In this case, unauthenticated access is permitted just like a URL pattern for a servlet that does not contain any auth-constraints in the web.xml file. An auth-constraint for a portlet can be specified directly by using the portlet name in the url-pattern element, or indirectly by a url-pattern that implies the portlet.
The following examples demonstrate how the security-constraint information contained in the portlet.xml and web.xml files in a portlet application are used to make security decisions for portlets. The security-role-ref element, which is used for isUserInRole calls, is not discussed here because it is used the same way for servlets.
In the examples later in this section (unless otherwise noted), there are four portlets (MyPortlet1, MyPortlet2, MyPortlet3, MyPortlet4) defined in portlet.xml. The portlets are secured by combining the information, if any, in the web.xml file when they are accessed directly through URLs.
All of the examples show the contents of the web.xml and portlet.xml files. Use the correct tools when creating these deployment descriptor files as you normally would when assembling a portlet application.
Example 1: The web.xml file does not contain any security-constraint data
<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>
In this example, when you access anything under MyPortlet1 and MyPortlet3, and these portlets are accessed using the unsecured HTTP protocol, you are redirected through the secure HTTPS protocol. The transport-guarantee is set to use secure connections. For MyPortlet2 and MyPortlet4, unsecured (HTTP) access is permitted because the transport-guarantee is not set. There is no corresponding security-constraint information for all four portlets in the web.xml file. Therefore, all of the portlets can be accessed without any user authentication and role authorization. The only security involved in this instance is the transport-layer security using Secure Sockets Layer (SSL) for MyPortlet1 and MyPortlet3.
URL | Transport Protection | User Authentication | Role Based Authorization |
---|---|---|---|
/MyPortlet1/* | HTTPS | None | None |
/MyPortlet2/* | None | None | None |
/MyPortlet3/* | HTTPS | None | None |
/MyPortlet4/* | None | None | None |
Example 2: The web.xml file contains portlet specific security-constraint data
<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>
- Because the web.xml file uses url-pattern, the portlet names have been modified slightly. MyPortlet1 is now /MyPortlet1/*, which indicates that everything under the MyPortlet1 URL is protected. This matches the information in the portlet.xml file because the security runtime code converts the portlet-name element in the portlet.xml file to url-pattern (for example, MyPortlet1 to /MyPortlet1/*), even for the transport-guarantee.
- The http-method element in the web.xml file is not used in the example because all HTTP methods must be protected.
URL | Transport Protection | User Authentication | Role Based Authorization |
---|---|---|---|
MyPortlet1/* | HTTPS | Yes | Yes (Employee) |
MyPortlet2/* | None | Yes | Yes (Employee) |
MyPortlet3/* | HTTPS | None | None |
MyPortlet4/* | None | None | None |
Example 3: The web.xml file contains generic security-constraint data implying all portlets.
<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>
In this example, /* implies that all resources that do not contain their own explicit security-constraints should be protected by the Manager role as per the URL pattern matching rules. Because the portlet.xml file contains explicit security-constraint information for MyPortlet1 and MyPortlet3, these two portlets are not protected by the Manager role, only by the HTTPS transport. Because the portlet.xml file cannot contain the auth-constraint information, any portlets that contain security-contraints in it are rendered unprotected when an implying URL (/* for example) is listed in the web.xml file because of the URL matching rules.
In the previous case, both MyPortlet1 and MyPortlet3 can be accessed without user authentication. However, because MyPortlet2 and MyPortlet4 do not have security-constraints in the portlet.xml file, the /* pattern is used to match these portlets and are protected by the Manager role, which requires user authentication.
URL | Transport Protection | User Authentication | Role Based Authorization |
---|---|---|---|
MyPortlet1/* | HTTPS | None | None |
MyPortlet2/* | None | Yes | Yes (Manager) |
MyPortlet3/* | HTTPS | None | None |
MyPortlet4/* | None | Yes | Yes (Manager) |
<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>
In this case, MyPortlet1 is protected by the Manager role and requires authentication. The data-constraint of CONFIDENTIAL is also applied to it because the information in the web.xml file and the portlet.xml file are combined. Because MyPortlet3 is not explicitly listed in the web.xml file, it is still not protected by the Manager role and does not require user authentication.
URL | Transport Protection | User Authentication | Role Based Authorization |
---|---|---|---|
MyPortlet1/* | HTTPS | Yes | Yes (Manager) |
MyPortlet2/* | None | Yes | Yes (Manager) |
MyPortlet3/* | HTTPS | None | None |
MyPortlet4/* | None | Yes | Yes (Manager) |