8.2 Form-Based Authentication

Java Servlet Programming, 2nd Edition > 8. Security > 8.2 Form-Based Authentication

< BACK

CONTINUE >

Servlets can also perform authentication without relying on HTTP authentication, by using HTML forms instead. Using this technique allows users to enter your site through a well-designed, descriptive and friendly login page. For example, imagine you're developing an online banking site. Would you rather let the browser present a generic prompt for username and password or provide your customers with a custom login form that politely asks for specific banking credentials, as shown in Figure 8-1?

Figure 8-1. An online banking login screen

Many banks and other online services have chosen to use form-based authentication. Implementing such a system is relatively straightforward with servlets because form-based authentication is built into Servlet API 2.2. To change from basic authentication to form-based, replace the <login-config> section of the web.xml file in Example 8-3 with the <login-config> section shown in Example 8-5.

Example 8-5. Configuring Form-Based Authentication

    <login-config>         <auth-method>             FORM       <!-- BASIC, DIGEST, FORM, CLIENT-CERT -->         </auth-method>         <form-login-config>  <!-- only useful for FORM -->             <form-login-page>                 /loginpage.html             </form-login-page>             <form-error-page>                 /errorpage.html             </form-error-page>         </form-login-config>     </login-config>

Notice the <auth-method> has been changed from BASIC to FORM. This indicates that form-based authentication should be used for this web application. The <realm-name> tag has also been replaced with <form-login-config>. This tag specifies the login page and error page to use for authentication. The login page should be the well-designed, descriptive, and friendly page asking for the user's credentials. The error page should be the well-designed, descriptive, and possibly mean page telling the server the credentials are no good. Both URLs should be absolute paths rooted at the context root.

Any time the server receives a request for a protected resource, the server checks if the user has already logged in. For example, a server might look for a Principal object stored in the user's HttpSession object. Should the server locate a Principal, the roles of the Principal are compared to those required to access the resource. The user is granted access only if the Principal belongs to the required role. Should the server not locate a Principal or should the Principal not belong to any of the allowed roles, the client is redirected to the login page (but first the server records, probably in the user's HttpSession object, the URL that was originally requested).

The login page contains a form where the user can enter and submit his username and password back to the server. Only if the username and password are valid and belong to a Principal in an allowed role for the originally requested resource is access granted, in which case the server politely redirects the user to that resource. In any other case, the server redirects the client to the error page.

The login page must include a form with special values to ensure the proper data is submitted in the right way to the server. The form must be a POST to the URL j_security_check (no leading slash, although some servers have been known to erroneously require it) with a username sent as j_username and a password sent as j_password. For example:

<FORM METHOD=POST ACTION="j_security_check"> Username: <INPUT TYPE=TEXT NAME="j_username"><br> Password: <INPUT TYPE=PASSWORD NAME="j_password"><br> <INPUT TYPE=SUBMIT> </FORM>

Example 8-6 shows a more realistic loginpage.html file that generates the form shown in Figure 8-2.

Example 8-6. The loginpage.html File

<HTML> <TITLE>Login</TITLE> <BODY> <FORM METHOD=POST ACTION=j_security_check> <CENTER> <TABLE BORDER=0> <TR><TD COLSPAN=2> <P ALIGN=center> Welcome!  Please enter your Name<br>  and Password to log in. </TD></TR> <TR><TD> <P ALIGN=right><B>Name:</B> </TD> <TD> <P><INPUT TYPE=TEXT NAME="j_username" VALUE="" SIZE=15> </TD></TR> <TR><TD> <P ALIGN=RIGHT><B>Password:</B> </TD> <TD> <P><INPUT TYPE=PASSWORD NAME="j_password" VALUE="" SIZE=15> </TD></TR> <TR><TD COLSPAN=2> <CENTER> <INPUT TYPE=submit VALUE="  OK   "> </CENTER> </TD></TR> </TABLE> </FORM> </BODY></HTML>

Figure 8-2 shows the form that is generated.

Figure 8-2. A friendly login form

The error page you specify in the <login-config> section of web.xml can be any HTML file. There are no special tags for it to include, nor unfortunately does it have access to any special information reporting why access was denied or even which page it should point the user at to try again! See Example 8-7 for a simple error page.

Example 8-7. The errorpage.html File

<HTML> <TITLE>Login Denied</TITLE> <BODY> Sorry, your login was denied. Please hit the Back button to try again. </BODY></HTML>

Compared with basic authentication, form-based login has the advantage that the user can enter your site through a friendly and descriptive login page. It shares the problem with basic authentication that the password is transmitted in plain text unless the communication channel has been secured by other means.

Both Basic and form-based login also have the problem that they support no standard logout mechanism. Calling session.invalidate( ) is likely to have that effect for form-based login, but there are no guarantees. Both also rely on the server to validate users, even though there are cases where validation should be done in ways not supported by the server (for example, some banks require an account number, password, and PIN for access). To solve these problems, we can implement custom authentication.

< BACK

CONTINUE >