Portlet URL security

Portlet-specific security information resides in portlet.xml. Servlet and JSP security information resides in web.xml. When the application server makes access decisions for portlets, security information in web.xml is combined with the security information in portlet.xml.

Portlet security supports both programmatic and declarative security. The isUserInRole method uses information from the security-role-ref element in portlet.xml. The getRemoteUser and getUserPrincipal methods behave the same way as they do when accessing a servlet. Both of these methods return the authenticated user information accessing the portlet.

Portlet declarative security is defined in portlet.xml and web.xml by the security-constraint informationxml, with the following differences:

• The auth-constraint element, which lists the names of the roles that can access the resources, does not exist in portlet.xml. 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 portlet.xml contains the portlet-collection element, while web.xml 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. It uses the underlying servlet container for the user authentication mechanism. As a result, there is no auth-constraint element in the security-constraint information in portlet.xml.

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

Example 1: The web.xml file does not contain any security-constraint data

In this example, 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 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.

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 this example security-constraint information corresponding 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 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 web.xml previously listed, note the following:

• Because web.xml 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 portlet.xml because the security runtime code converts the portlet-name element in portlet.xml to url-pattern (for example, yPortlet1 to /MyPortlet1/*), even for the transport-guarantee.

• The http-method element in web.xml 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

In this example, 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 portlet.xml 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 portlet.xml 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 previous case, both MyPortlet1 and MyPortlet3 can be accessed without user authentication. However, because MyPortlet2 and MyPortlet4 do not have security-constraints in portlet.xml, 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 portlet.xml (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 portlet.xml 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.

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