4.6 Authorization

Once a client is authenticated, a J2EE container needs to perform authorization checks. Authorization policies configured in an enterprise describe which users or groups are allowed to access protected J2EE resources. The Application Assembler specifies, in the deployment descriptor of the Web module packaging a Web application, which security roles are required in order to access a URI managed by a J2EE container (see Section 3.7.2 on page 67). Because an Application Assembler is probably not familiar with the deployment environment of the enterprise in which the application is deployed, the Application Assembler specifies authorization policies in terms of J2EE security roles, with a security role being a named collection of J2EE authorizations, implemented as java.security.Permission objects. When a security role is mapped to a user or a group in an enterprise, that user or group is authorized to access the resources protected by those permissions associated with the security role. For example, if the Fabrikam456 travel organization has established that access to online reservations should be allowed only to customers, the deployment descriptor can specify that only the principals corresponding to the Customer security role are authorized to access the travel reservation URLs.

The default behavior of a WAS is to authorize access to all the J2EE resources unless they are explicitly protected. Therefore, System Administrators (see Section 3.7.4 on page 71) can deploy Web resources without declaring them explicitly in a Web module's deployment descriptor.

Web resources are accessed by the URL to which they are mapped. For example, a ReservationServlet can be invoked through the URL http://www.fabrikam456.com/travel/reserve . An Application Assembler, therefore, declares authorization policies in the Web module's deployment descriptor in terms of URLs. In the deployment descriptor, security constraints are defined to restrict access to URLs. Such constraints are associated with a set of URLs relative to the Web application's context path using the security-constraint XML element. For example, if the context path of the Fabrikam456 travel application is /travel , the relative URL to access the ReservationServlet will be specified in terms of the relative URL /reserve .

The relative URLs to which the restriction applies can be defined via URL patterns. In the Web module's deployment descriptor, such a collection of URLs, known as a Web resource collection , is specified through a web-resource-collection XML element. Associated with a Web resource collection is its authorization constraint policy, specified by an auth-constraint element. An authorization constraint policy is specified in terms of J2EE security roles. An example of this is shown in Listing 3.3 on page 75. Security administrators are responsible for managing authorization policies for the users and groups authorized to access the protected URIs. The following subsections describe how protected Web resources can be accessed by authorized users and groups.

4.6.1 Invocation Chain

When building a Web application, it is often useful to forward processing of a request to another servlet or to include the output of another servlet in the response. The javax.servlet.RequestDispatcher interface provides a mechanism to accomplish this through its methods forward() and include() . The RequestDispatcher interface defines an object that receives requests from the client and sends them to any resource, such as a servlet, HTML file, or JSP file, on the server. The servlet container creates the RequestDispatcher object, which is used as a wrapper around a server resource located at a particular path or given by a particular name .

• The forward() method forwards a request from a servlet to another resource on the server. This method allows one servlet to do preliminary processing of a request and another resource to generate the response.

• The include() method includes the content of a resource in the response.

The operations of invoking the forward() and include() methods on the RequestDispatcher object are known as servlet forwards and servlet includes , respectively. Servlet forwards and includes allow for servlet internal invocations. Basically, a servlet can dispatch a request to another servlet or resource on the server without involving the HTTP server. Performing a servlet forward or a servlet include generates an invocation chain ”a chain of multiple servlet, JSP application, and/or HTML file invocations.

From a security point of view, it should be noted that the protection rules for a Web resource accessed through a J2EE container are based on the invocation chain leading to the protected Web resource. In particular, in a J2EE container, only the first servlet or JSP application in an invocation chain is subject to authorization tests. Authorization tests are not performed by the Web container if the request is a result of an entry servlet or a JSP application performing a servlet forward or include; they are performed only on the first, or entry , servlet or JSP application in the invocation chain.

For example, let us consider a scenario in which the servlet AgentInfoServlet, accessible through the /travel/agentInfo relative URL, is to be protected; only users with TravelAgents role are allowed access to it. Likewise, the AgentAddressServlet, associated with the relative URL /travel/agentAddress , is to be protected; in this case, however, the protection is specified such that no one should have direct access to it. Whenever a user with TravelAgent requests the /travel/agentInfo relative URL, the serlvet AgentInfoServlet is invoked. Let us assume that AgentInfoServlet contains a servlet include directive for the AgentAddressServlet by invoking the relative URL /travel/agentAddress . In this scenario, access to the AgentAddressServlet is allowed because it is the result of a servlet include rather than a direct call to the AgentAddressServlet, which would not be allowed. In contrast, if a user tries to directly access the /travel/agentAddress URL directly from a browser, the request is denied , as AgentAddressServlet would be the first servlet handled by the Web container for that particular request. This scenario is depicted in Figure 4.7.

Figure 4.7. Access Dependent on an Invocation Chain

4.6.2 Protecting a Specific URL

Authorization is declared at the granularity of a specific URL by indicating the exact URL path in the web-resource-collection element of the deployment descriptor. Cases exist in which all resources within a directory are to be generally accessible with only a few exceptions; conversely, almost all the resources in another directory should be inaccessible except for a few.

Consider the travel service Web application; the relative URL /travel/reserve is mapped to the ReservationServlet. The context path for the Web application is /travel . The request URL for the servlet would be http://www.fabrikam456.com/travel/reserve . If the ReservationServlet is to be protected such that only a user with Customer or TravelAgent role can access the HTTP methods GET , POST , and PUT ”typically implemented within an HttpServlet as the methods doGet() , doPost() , and doPut() , respectively ”the authorization policy must be declared in terms of the URLs that will be used to access the servlet. This policy is shown in Listing 4.8.

Listing 4.8. Security Constraint Definition for a Specific URL

 <security-constraint>    <web-resource-collection>       <web-resource-name>          ReservationServlet       </web-resource-name>       <url-pattern>/travel/reserve</url-pattern>       <http-method>GET</http-method>       <http-method>POST</http-method>       <http-method>PUT</http-method>    </web-resource-collection>    <auth-constraint>       <role-name>Customer</role-name>       <role-name>TravelAgent</role-name>    </auth-constraint> </security-constraint> 

A URL can be protected by explicitly stating it under the url-pattern element of the web-resource-collection descriptor. Note that the URL is a relative URL ”relative to the Web application's context path. All the HTTP methods that are to be protected are also declared within the web-resource-collection element.

4.6.3 Protecting a URL Pattern

When a set of URLs needs to be protected, it is adminstratively easier to express and manage the authorization policies in terms of URL patterns instead of listing every URL separately. These patterns are used by a Web container when handling URL requests based on servlet-processing rules as defined by the Java Servlet specification.

URL patterns can be specified in a couple of ways in a Web module's deployment descriptor. The following subsections describe URL path-prefix and extension patterns that can be used in addition to using specific URLs.

4.6.3.1 URL Path-Prefix Protection

In Section 4.5.1.2 on page 117, we noted that a specific URL can have multiple path prefixes. Let us consider the URL http://www.fabrikam456.com/travel/travelAgent/reserve . Given that /travel is the context path of the Fabrikam456 Web application, we can specify the protection rules based on the URL /travelAgent/reserve , which is relative to /travel . This URL has two path prefixes: / and /travelAgent . Path prefixes are an administrative convenience. For example, let us assume that the structure of the Fabrikam456 Web site is designed so that all the resources under the URL path http://www.fabrikam456.com/travel/travelAgent/ must be protected and are to be accessible only to users having the TravelAgent security role. Instead of specifying all the resources by name, it is easier to specify the policy by combining a path prefix with a wildcard expression. In the scenario described, the URL path pattern /travelAgent/* can be declared protected such that only users granted the TravelAgent security role can access the resources underneath it. This policy is specified using the security-constraint element in the Web application's deployment descriptor, as shown in Listing 4.9.

Listing 4.9. Deployment Descriptor Fragment Showing Path-Prefix Protection

 <security-constraint>    <web-resource-collection>       <web-resource-name>          Travel agents information       </web-resource-name>       <url-pattern>/travelAgent/*</url-pattern>    </web-resource-collection>    <auth-constraint>       <role-name>TravelAgent</role-name>    </auth-constraint> </security-constraint> 

4.6.3.2 URL Extension Protection

A URL extension is defined as the substring starting with the last dot character. For example, in the JSP URL http://www.fabrikam456.com/travel/welcome.jsp , the extension is the string .jsp . An extension does not, however, include fragments or references. Therefore, in the URL http://www.fabrikam456.com/travel/index.html#WELCOME , the extension includes only the part .html . If several resources with many different extensions are served from a specific path prefix and if only some of them are to be protected, protection based on extension patterns provides an efficient mechanism for this purpose.

Protecting all the URL patterns with extension .jsp under the status directory can be specified by using the security constraint shown in Listing 4.10.

Listing 4.10. Deployment Descriptor Fragment Showing Extension Protection

 <security-constraint>    <web-resource-collection>       <web-resource-name>          Protect only the JSP files       </web-resource-name>       <url-pattern>/status/*.jsp</url-pattern>    </web-resource-collection>    <auth-constraint>        <role-name>TravelAgent</role-name>    </auth-constraint> </security-constraint> 

Besides the standard extensions, such as .jsp and .html , it is possible to define custom extensions.

4.6.4 Protecting from Everyone

A Web application may be designed to contain multiple directories and entry points. There may be assumptions about how a resource is to be accessed. For example, it could be established that a resource or group of resources should be accessible only internally from a servlet and never directly from a client. In such cases, security constraints should be specified in terms of specific URLs or URL patterns, as discussed in Section 4.6.1 on page 126, Section 4.6.2 on page 128, and Section 4.6.3 on page 129. However, instead of specifying a list of authorized roles, an empty auth-constraint descriptor implies that no external access is allowed, as is shown in Listing 4.11.

Listing 4.11. Deployment Descriptor Fragment Forbidding External Access

 <security-constraint>    <web-resource-collection>       <web-resource-name>Not accessible</web-resource-name>       <url-pattern>/private/*</url-pattern>    </web-resource-collection>    <auth-constraint></auth-constraint> </security-constraint> 

4.6.5 Understanding the Precedence Rules

Understanding the precedence of authorization policy constraints is essential, as it has implications on which security constraints are applicable . When a URL request is presented to a Web container, the Web container selects a Web application that has the longest context path matching the start of the requested URL. For example, consider two Web applications, Default and Travel, with respective context paths / and /travel . When a request is submitted for the URL /travel/travelAgent/reserve , the request is mapped to the Travel Web application because the longest matching context path, /travel , is mapped to the Travel Web application. Because the matched prefix is the Web application's context path, the rest of the URL, other than that matched context path, needs to be mapped to a Web component ”for example, a servlet ”that can handle the incoming request. In our example, /travelAgent/reserve is mapped to the TravelAgentReservationServlet. Because a URL may be matched by multiple URL patterns, precedence rules are defined for the Web container.

Precedence rules for matching security constraints are the same as the ones used by a Web container to map URLs to servlets. The Web container will attempt to map a given URL to a security constraint, based on those rules. If no matching rules are found, the URL is assumed to be unprotected . The precedence rules for mapping URLs to servlets are based on case-sensitive matching in the following order:

1. Exact match. If the requested URL path is an exact match to a defined URL mapping for the servlet, the matched servlet is determined to be the target servlet.

2. Path mapping through the longest path prefix . The Web container walks down the directory path one directory at a time by using the forward slash character, / , as path separator. The first successful match is deemed to be the longest matching prefix to handle the request.

3. Extension match. If the last part of the URL is an extension, such as .jsp , the Web container tries to match a servlet that is defined to handle the extension.

When none of these rules matches a requested URL, the Web container passes the request to a servlet that is configured to handle requests by default.

For example, let us assume that a Web application's deployment descriptor defines security constraints for the URL /travelAgent/reserve , the path-prefix URL pattern /travelAgent/* , and the URL extension pattern status/*.jsp .

• An incoming request for the URL http://www.fabrikam456.com/travel/travelAgent/reserve matches both the specific URL /travelAgent/reserve and the URL pattern /travelAgent/* . The precedence rules dictate that owing to an exact match, the security constraints applied by the Web container are the ones associated with the relative URL /travelAgent/reserve .

• An incoming request for the URL http://www.fabrikam456.com/travel/travelAgent/ info matches the URL pattern /travelAgent/* . In this case, therefore, the precedence rules dictate that the security constraints applied by the Web container are the ones associated with the URL path-prefix pattern /travelAgent/* .

• An incoming request for the URL http://www.fabrikam456.com/travel/status/info.jsp matches the URL extension pattern status/*.jsp . In this case, the precedence rules dictate that the security constraints applied by the Web container are the ones associated with the URL extension pattern /status/*.jsp .

This scenario is illustrated in Table 4.1.

Table 4.1. Example Showing Application of Precedence Rules

Requested URL	Matched Security Constraints
http://www.fabrikam456.com/travel/travelAgent/reserve	/travelAgent/reserve
http://www.fabrikam456.com/travel/travelAgent/info	/travelAgent/*
http://www.fabrikam456.com/travel/status/info.jsp	/status/*.jsp

4.6.6 Data Constraints ”Only over SSL!

Transactions between an HTTP client and an HTTP server frequently contain security- or privacy-sensitive data. Such data should be kept confidential to prevent its unauthorized disclosure and modification, especially when it is transmitted over the Internet. One approach is to secure the communication channel itself. Another approach is to protect the data by using programmatic cryptography. The latter approach requires special client-side capabilities that may not be available in a pure Web browser environment. The most common solution to the former approach ”to secure the communication channel ”is obtained by using SSL, a widely adopted protocol that maintains confidentiality and integrity in network communications between clients and servers.

HTTP requests and responses are sent over an SSL connection when the protocol specified is HTTPS. This approach secures the communication between the client and the first server that handles the HTTP requests. This guarantees that client authentication is protected by the SSL protocol. The remainder of the communication connections within an enterprise may also be over SSL for the same reasons of confidentiality and integrity. In order for a Deployer to specify that a particular URL request must be accessed over a secure channel, the Java Servlet specification introduces the concept of a user data constraint . By specifying this constraint in the Web application's deployment descriptor, the Deployer conveys the security constraint to a J2EE Web container to serve a URL only over an HTTPS connection. A user data constraint is used to enforce integrity and confidentiality requirements for the transport layer of the communication between the client and the server. When a request is over HTTP and the transport-guarantee element in the user-data-constraint descriptor is set to INTEGRAL or CONFIDENTIAL , the Web container will redirect the request to be resubmitted over HTTPS.

Listing 4.12 shows an example of a security constraint imposing that the URL /travel/reserve be accessed only over an SSL connection:

Listing 4.12. Deployment Descriptor Fragment Enforcing Integrity and Confidentiality

 <security-constraint>    <web-resource-collection>       <web-resource-name>          ReservationServlet    </web-resource-name>       <url-pattern>/travel/reserve</url-pattern>    </web-resource-collection>    <user-data-constraint>        <transport-guarantee>           CONFIDENTIAL        </transport-guarantee>    </user-data-constraint> </security-constraint> 

As we observed in Section 3.10.1.2 on page 93, the server does not typically differentiate INTEGRAL from CONFIDENTIAL ; both of these values indicate the need to require an SSL connection.