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.

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.