Chapter 3 Configuring Web Application Security

Authentication

The types of Web application authentication methods available include:

None no authentication is required.
Basic the server asks the client for its user name and password. You also provide a Realm name. The realm adds additional information to the client who is logging in to your site. For example, if you do not provide a realm name when a client visits your site, the browser displays a message to the client that states "The server at host:port wants you to log in." If you enter a realm name of "Human Resources Web site," the browser displays "The server at Human Resources Web site at host:port wants you to log in."

When an HTTP client sends the HTTP basic authentication header:
- The server authenticates the client using the server-defined authentication scheme and invokes any defined customized authentication component.
- If the request is intended for PowerDynamo, the server still authenticates the client, but the request is denied, and HTTP status code 401 (Unauthorized) is sent back to the client.
- If the authentication fails, the request fails and an error message is sent back to the client. If the request is intended for a Web application, then the Web application manages error handling.
- If the request is intended for a regular static page, the request is denied, and HTTP status code 401 (Unauthorized) is sent back to the client.
Form the Web application developer creates an HTML login page, where the client enters a user name and password. The entire HTML page is sent to the server. You also create an error page that is returned to the client in the event of a server error.
- Login page - enter the location of the login page that is supplied to the client at login. For example, /login.jsp might be your login page.
- Error page - enter the location of the error page that the client is directed to should a server error occur during login. For example, /error.jsp might be your error page.
Login and error pages can vary from a very simple HTML page to a complex page that includes servlets and JSPs.

The location of the error and login pages is relative to the WebApp directory whether or not a "/" is used. For example, if you specify /error.jsp or error.jsp as the location of your error page, the servlet engine assumes that it is contained in the WebApp context.

Below is an example of a form login and error page. The action of the form login page must always be j_security_check. The user name and password fields should be j_username and j_password respectively.

Form login page:
```
<html>
<body>
<h1>Login page</h1>

<form method="POST" action="j_security_check" >
<input type="text" name="j_username">
<input type="password" name="j_password">

<input type="submit" name="j_security_check">
</form>

</body>
</html>
```
Form error page:
```
<html>
<head>
<title>Login Error</title>
</head>
<body> Login error -- please try <a href="login.html">again</a>.
</body>
</html>
```
These examples assume that login.html is the login page, and that the error page and login page are in the same directory.
Client-cert - the client connects to the server using SSL tunneled within HTTP. The client must provide a certificate that the server accepts and authenticates. For more information about SSL, see Chapter 11, "Security Configuration Tasks" and Chapter 12, "Managing Keys and Certificates"

EAServer does not support HTTP digest authentication. If you specify digest authentication, the default, Basic, is used instead.

EAServer supports lazy authentication , which means that the server attempts to identify a client only when the client attempts to access a restricted resource. As long as the client accesses only resources that do not require authorization, the server does not attempt to authenticate the client.

When a server authenticates a client, the client is authenticated for all applications and references on the server. You can implement authentication of a client for an entire server by using cookies or rewriting the URL. A reference to the client's security credentials is saved in a cookie or encoded in the URL.

Form login requirements in a Web application when using HTTPS (SSL)

To use the form login mechanism in your Web application, the client must support cookies. The client can be a browser or a standalone HTTP client. To convert your Web application, which uses the form login mechanism in conjunction with HTTPS, then the transport guarantee for the form login page and the pages that require authorization must be identical. Otherwise, the client will receive multiple HTTP redirects to the same page, resulting in an error.

Here are the steps required to enable HTTPS for the eStore application, which is a large, comprehensive sample application developed by Sun Microsystems to run on J2EE-compliant servers. eStore simulates an online pet store implemented with Java Server Pages, Java servlets, and Enterprise Java Beans. You can download eStore as part of the Sun Microsystems J2EE Blueprints .

Change the transport guarantee for the existing two security constraints from None to Confidentiality or Integrity.
Add a new security constraint. Set the transport guarantee for the new security constraint to the same value as the existing two security constraints.
Add a Web resource collection to the new security constraint. Define a Web resource, and set the URL pattern to "/login.jsp", which is the URL of the form login page.
Refresh the eStore application. Connect to the eStore application from your browser. The form login and subsequent communication occurs using HTTPS.