+

Search Tips   |   Advanced Search

Portlet URL security


WAS 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 JSPs files reside in web.xml. Also, when you make access decisions for portlets, the security information, if any, in web.xml 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 web.xml 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 web.xml. This implies that to authenticate a user for a portlet, web.xml 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 web.xml, 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 web.xml. 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.

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 below (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 web.xml 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 you 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 web.xml. 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.

The following table lists the security constraints that are applicable to the individual portlets.


Table 1. Security constraints that are 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.

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

The security-constraint information contained in web.xml in this example indicates that the user authentication must be performed when accessing anything under the MyPortlet1 and MyPortlet2 portlets. When you 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 web.xml listed above, note the following:

The following table lists the new security constraints that are applicable to the individual portlets.


Table 2. Security constraints that are applicable to the individual portlets

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 web.xml 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 web.xml because of the URL matching rules.

In the case above, 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.

The following table lists the new security constraints that are applicable to the individual portlets with this setup.


Table 3. Security constraints that are applicable to the individual portlets

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 example above, if also protect a portlet contained in the portlet.xml file (for example, MyPortlet1), web.xml 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 web.xml and the portlet.xml file are combined. Because MyPortlet3 is not explicitly listed in web.xml, it is still not protected by the Manager role and does not require user authentication.

The following table shows the effect of this change.


Table 4. Security constraints that are 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 concepts


Web component security

 

Related tasks


Secure Web apps using an assembly tool