Security in Web Applications and Components

The Web security features of J2EE use the same model as that used for EJB security. Security is implemented using declarations in the deployment descriptor and programming in the Web pages. Authorization is enforced using roles and principals in the same manner as EJB security.

The key concepts for the Web security model are

• Single login-- A client is only required to authenticate itself once to access all Web pages in a security realm provided by the Web server.

• Spanning of multiple applications-- An authenticated client should be able to use Web pages from different Web applications without having to log in for each application.

• Association with a session-- The security credentials must be associated with the servlet session, so that each servlet or JSP can access the credentials when required for programmatic authorization.

The J2EE Web security model specifies requirements for client authentication as well as authorization for Web applications.

Web Authentication

The J2EE servlet specification defines four mechanisms for authenticating users:

• Basic HTTP

• HTTP Digest

• Forms based

• HTTPS Client

These are briefly discussed in the rest of this section.

Basic HTTP Authentication

The HTTP protocol defines a simple authentication system where the Web server can request the client to supply a username and password. The Web client obtains the username and password of the user and returns them to the Web server for authentication. The popular Web browsers display a simple login form for the user to provide authentication information; you do not have to supply your own.

The username and password are returned to the Web server using a simple encoding scheme. Basic HTTP authentication is simple and effective, but it does not provide confidentiality because hackers monitoring network traffic can easily obtain the username and password. In reality, hackers will find it almost impossible to monitor network traffic outside of their own organization. However, malicious company employees with the requisite knowledge and software will be able to monitor internal networks.

To secure usernames and passwords used in basic authentication, it is usual to switch from using HTTP to HTTPS (HTTP with SSL) when browsing secured web pages (see the section “Securing Web Application Login”).

HTTP Digest Authentication

HTTP Digest authentication works in a similar manner to Basic HTTP authentication except that the username and password are returned in an encrypted form. The encrypted username and password are more secure against illicit monitoring of network traffic.

The Servlet specification does not require HTTP Digest authentication because it is not widely supported by Web clients at the present time.

Forms-based Authentication

J2EE Web applications can specify their own forms-based authentication. This is similar to basic HTTP authentication, but a form is supplied by the application when a user has to be authenticated. The application can supply an authentication form with the same look and feel as the other Web pages in the application, instead of using the simple form provided by the Web browser. Forms-based authentication sends the username and password in plain text and has the same security weaknesses as basic HTTP authentication.

HTTPS Client Authentication

This is the most secure form of authentication because it requires the client to identify itself using a digital certificate. Client authentication is usually implemented using SSL and is supported by the common Web browsers. This is a large subject area, and there is insufficient space for it to be covered in today's lesson. Using SSL requires web server configuration changes and is specific to each web server vendor. The book Tomcat Kick Start from Sams Publishing (ISBN 0-672-32439-3) describes implementing HTTPS client authentication using the open source Apache Tomcat Web server.

After authenticating users, Web applications apply authorization either declaratively, based on a URL, or programmatically within the servlet or JSP code. These two techniques are discussed in the next sections.

Declarative Web Authorization

Authorized access to Web pages is based on the URL of the Web page. By default, all pages are unprotected, but the deployment descriptor for a Web application can define security constraints to force a client to authenticate itself before accessing the protected pages.

Authorization is based on roles and constraints. A Web application defines the roles required to access different functionality within the application. One or more constraints can be defined to authorize access to an individual page or a group of pages based on the roles defined for the application.

As with EJB security roles, the deployer must map the role references used in the deployment descriptor onto principals defined in the target authentication domain.

If declarative security cannot capture your web application security requirements, programmatic security must be used.

Programmatic Web Authorization

Web applications can access the authenticated client's security information using the following methods:

• boolean HttpServletRequest.isUserInRole(String role) Returns true if the client is in the role passed as a parameter.

• Principal HttpServletRequest.getUserPrincipal() Returns a java.security.Principal object representing the client's principal. Unlike the EJBContext.getCallerPrincipal() method, this method can return null if the client has not been authenticated.

• String HttpServletRequest.getRemoteUser() Returns the principal name of the client or null if the client has not been authenticated.

These methods are similar to the EJB programmatic security methods discussed previously and are illustrated in the following section.