+

Search Tips   |   Advanced Search

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. When we 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 declarative security aspect of the portlets is defined by the security-constraint information in the portlet.xml file. This is similar to the security-constraint information used for the servlets in the web.xml file with the following differences:

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 WAS, 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 using the portlet name in the url-pattern element, or indirectly by a url-pattern that implies the portlet.

We cannot have a servlet or JSP with the same name as a portlet for WAS security to work with 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

In the following example, the security-constraint information is contained in 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>

In this example, when we access anything under MyPortlet1 and MyPortlet3, and these portlets are accessed using the unsecured HTTP protocol, we 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 SSL for MyPortlet1 and MyPortlet3.


Security constraints applicable to the individual portlets

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

In the following example, the security-constraint information that corresponds to the portlet is contained in web.xml. The portlet.xml file is the same as that shown in the previous example.

The security-constraint information contained in the web.xml file in this example indicates that the user authentication must be performed when accessing anything under the MyPortlet1 and MyPortlet2 portlets. When we attempt to access these portlets directly using URLs, and there is no authentication information available, we are prompted to enter their credentials. After we are authenticated, the authorization check is performed to see if we are listed in the Employee role. The user/group to role mapping is assigned during the portlet application deployment. In the web.xml file previously listed, note the following:

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.

In the following example, the security-constraint information is contained in the web.xml file that corresponds to the portlet. The portlet.xml file is the same as that shown in the first example. 

<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)

If in the previous example, if we must also protect a portlet contained in the portlet.xml file (for example, MyPortlet1), the web.xml file should contain an explicit security-constraint entry in addition to /* as shown in the following example: 

      <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.


Security constraints applicable to the individual portlets

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)


Related:

  • Web component security
  • Secure web applications using an assembly tool