Form Based Authentication in Tomcat

Form-based authentication lets developers customize the authentication user interface. The login-config section of web.xml defines the type of authentication mechanism, and the URIs to login and error pages.

Add the below login-config in the web.xml file. When the users directly try to access your web resources, server will redirect the user to form-login-page if the user is not authenticated.

<login-config>

<auth-method>FORM</auth-method>

<form-login-config>

<form-login-page>/jsp/login.html</form-login-page>

<form-error-page>/jsp/login_err.html</form-error-page>

</form-login-config>

</login-config>

The login form must contain fields for entering username and password. These fields must be named j_username and j_password, respectively. This form should post these values to j_security_check logical name.

Here is an example showing how the form should be coded into an HTML page:

<form method="POST" action="j_security_check">

                    <input type="text" name="j_username">

                    <input type="password" name="j_password">

</form>

This form of authentication, which uses base64 encoding, can expose username and password unless all connections are over SSL. 

The Web containers activate the authentication mechanism that has been configured for that resource, when protected Web resources are accessed. 

Web containers perform the following steps to implement security of a Web application.

1.       Determines whether the user has been authenticated when the protected Web resources are accessed.

2.       If the user has not been authenticated yet, requests that the user provide security credentials by redirecting to the login page defined in the deployment descriptor.

3.       Validates the user's credentials against the security realm configured for the container.

4.       Determines whether the authenticated user is authorized to access Web resources defined in the deployment descriptor (web.xml).

In the deployment descriptor of a Web application, form-based authentication does not specify the security realm, as the basic authentication mechanism does. In other words, it does not explicitly declare the type of security realm it should use to authenticate a user. This causes some confusion as to what security realm it actually uses to authenticate the user. 

Web containers perform the following steps to validate a user:

1.       Determines the configured security realm for the container.

2.       Uses that security realm for authentication.

Since database and LDAP provide greater flexibility in maintaining information, most organizations may want this persistence for security authentication and authorization information. 

Many Web containers have support for different types of security realms: database, LDAP, and custom realm. 

For example, in the Tomcat Web container, server.xml configures database as its security realm.

<Realm className="org.apache.catalina.realm.JDBCRealm"  debug="99" driverName="org.apache.derby.jdbc.ClientDriver"  connectionURL="jdbc:derby://localhost:1527/TestDB" userTable="users"  userNameCol="username" userCredCol="password" userRoleTable="user_roles"  roleNameCol="rolename"  />

The <Realm> tag of Tomcat's server.xml defines the type of security realm that the container should use to authenticate a user. Note that the container uses this realm for Web applications whose authentication mechanism is form-based.

Authorization

Once the user has been authenticated, the container retrieves security roles for the authenticated user and checks to see if the user belongs to one of the roles defined in the <auth-constraint> tag of the deployment descriptor. The Web container displays an error message if the user does not belong to one of roles. 

The <security-constraint> tag of the deployment descriptor (web.xml) defines protected Web resources and a list of roles that have access to these Web resources.

                <security-constraint>

                                <web-resource-collection>

                                                <web-resource-name>A Protected Page</web-resource-name>

                                                <url-pattern>/*</url-pattern>

                                                <http-method>DELETE</http-method>

                                                <http-method>GET</http-method>

                                                <http-method>POST</http-method>

                                                <http-method>PUT</http-method>

                                </web-resource-collection>

                                <auth-constraint>

                                                <role-name>manager</role-name>

                                </auth-constraint>

                                <user-data-constraint>

                                                <transport-guarantee>NONE</transport-guarantee>

                                </user-data-constraint>

                </security-constraint>