Chapter 3: Using 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, and if the request is denied, 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, 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 13, “Security Configuration Tasks,” and Chapter 14, “Managing Keys and Certificates.”

You cannot use both “client-cert” and “OS authentication” as Web application security mechanisms at the same time. If you do, clients will not connect to the Web application. See “Configuring OS authentication”.

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, 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. See “Defining a security constraint from the Web Application Properties Security tab” for information about configuring transport guarantee.

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.

Web application direct form login

EAServer supports direct form login, which allows you to access a Web application’s protected content directly without requiring the user to visit the Web application’s form login page.

To enable direct form login, set the following session property:

com.sybase.jaguar.servlet.session.redirecturl

This property specifies the URL of the protected page that you want to access. With the property set, submit a post request to the form login URL with the user name and password specified in the request parameters. If the login succeeds, EAServer redirects the user to the specified page.If you do not specify a page to redirect to before posting a request to the login form, EAServer redirects the user to the page specified by this Web application property:

com.sybase.jaguar.webapplication.default.protectedpage

If this property is not set, EAServer redirects the user to the Web application’s welcome page.

Also, when authentication fails, the following properties are set in the servlet session before invoking the error page:

com.sybase.jaguar.servlet.session.username – the user name specified in the failed login attempt.
com.sybase.jaguar.servlet.session.password – the password specified in the failed login attempt.

These settings are removed when authentication succeeds.