Authentication mechanisms on J2EE (tomcat)

Read here about quick review of terminologies involved in authentication.

Authentication mechanism is setup in 3 steps.

1. Configure realm
2. Create and configure users and roles
3. Configure authentication

Configure Realms in Tomcat

Although the Servlet Specification describes a portable mechanism for applications to declare their security requirements (in the web.xml deployment descriptor), there is no portable API defining the interface between a servlet container and the associated user and role information.
Therefore, Tomcat defines a Java interface (org.apache.catalina.Realm) that can be implemented by "plug in" components to establish this connection. Six standard plug-ins are provided, supporting connections to various sources of authentication information:

JDBCRealm - Accesses authentication information stored in a relational database, accessed via a JDBC driver.
DataSourceRealm - Accesses authentication information stored in a relational database, accessed via a named JNDI JDBC DataSource.
JNDIRealm - Accesses authentication information stored in an LDAP based directory server, accessed via a JNDI provider.
UserDatabaseRealm - Accesses authentication information stored in an UserDatabase JNDI resource, which is typically backed by an XML document (conf/tomcat-users.xml).
MemoryRealm - Accesses authentication information stored in an in-memory object collection, which is initialized from an XML document (conf/tomcat-users.xml).
JAASRealm - Accesses authentication information through the Java Authentication & Authorization Service (JAAS) framework.

It is also possible to write your own Realm implementation, and integrate it with Tomcat. To do so, you need to:

1. Implement org.apache.catalina.Realm,
2. Place your compiled realm in $CATALINA_HOME/lib,
3. Declare your realm as described in the "Configuring a Realm" section below,
4. Declare your realm to the MBeans Descriptor.

MemoryRealm is the default realm.

Create and configure users and roles

This changes based on the type of Realm you are configuring. For memory realm, In tomcat-users.xml add the below entries within tomcat-users tags.

<role name="eipe" password="eipe" rolename="director" roles="director" user="">
<user name="jason" password="jason" roles="director">
</user></role>

This creates a role called "director" and 2 users with access to it. Read about other realms here


Configure authentication

Security configuration for web application could be setup
- declaratively by use of the deployment descriptor mechanismor
- declaratively by use of annotations or/and
- programmatically

The following example follows declarative configuration.

Authentication mechanisms available on J2EE container:

- HTTP Basic
- Form Based
- Client certificate (HTTPS Client)
- Mutual authentication
- Digest authentication

Creating a web application to test these mechanisms.

<servlet>
 <servlet-name>SecureServlet</servlet-name>
 <servlet-class>com.test.SecureServlet</servlet-class>
</servlet>
<servlet-mapping>
 <servlet-name>SecureServlet</servlet-name>
 <url-pattern>/secure</url-pattern>
</servlet-mapping>

<security-constraint>
 <web-resource-collection>
  <web-resource-name>Servlet is protected from POST calls</web-resource-name>
  <url-pattern>/secure</url-pattern>
  <http-method>POST</http-method>
  <http-method>GET</http-method>
 </web-resource-collection>
 <web-resource-collection>
  <web-resource-name>JSP page protected from any access</web-resource-name>
  <url-pattern>/secure.jsp</url-pattern>
  <http-method>GET</http-method>
 </web-resource-collection>
 <auth-constraint>
  <role-name>directors</role-name>
 </auth-constraint>

 <user-data-constraint>
  <!-- transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE -->
  <transport-guarantee>NONE</transport-guarantee>
 </user-data-constraint>
</security-constraint>

HTTP basic authentication

HTTP Basic Authentication requires that the server request a user name and password from the web client and verify that the user name and password are valid by comparing them against a database of authorized users. When basic authentication is declared, the following actions occur:
A client requests access to a protected resource.
The web server returns a dialog box that requests the user name and password.
The client submits the user name and password to the server.
The server authenticates the user in the specified realm and, if successful, returns the requested resource.

Add the below config to web.xml to enable BASIC authentication

<login-config>
    <auth-method>BASIC</auth-method>
</login-config>

HTTP basic authentication is not a secure authentication mechanism. Basic authentication sends user names and passwords over the Internet as text that is Base64 encoded, and the target server is not authenticated. This form of authentication can expose user names and passwords. If someone can intercept the transmission, the user name and password information can easily be decoded. However, when a secure transport mechanism, such as SSL, or security at the network level, such as the IPSEC protocol or VPN strategies, is used in conjunction with basic authentication, some of these concerns can be alleviated.

Form-based login authentication

Form-based authentication allows the developer to control the look and feel of the login authentication screens by customizing the login screen
and error pages that an HTTP browser presents to the end user. When form-based authentication is declared, the following actions occur:
A client requests access to a protected resource.
If the client is unauthenticated, the server redirects the client to a login page.
The client submits the login form to the server.
The server attempts to authenticate the user.
If authentication succeeds, the authenticated user’s principal is checked to ensure it is in a role that is authorized to access the resource.
If the user is authorized, the server redirects the client to the resource using the stored URL path.
If authentication fails, the client is forwarded or redirected to an error page.

<login-config>
 <auth-method>FORM</auth-method>
 <form-login-config>
   <form-login-page>/login.jsp</form-login-page> 
   <form-error-page>/index.jsp</form-error-page>
 </form-login-config>
</login-config>

login.jsp

<form action="j_security_check" method="POST">
<table><tbody>
<tr>   <td colspan="2">Login to the Secret application:</td>  </tr>
<tr>   <td>Name:</td>   <td><input name="j_username" type="text" /></td>  </tr>
<tr>   <td>Password:</td>   <td><input name="j_password" type="password" /></td>  </tr>
<tr>   <td colspan="2"><input type="submit" value="Enter" /></td>  </tr>
</tbody></table>
</form>

The login and error page locations are specified relative to the location of the deployment descriptor.
Form-based authentication is not particularly secure. In form-based authentication, the content of the user dialog box is sent as plain text,
and the target server is not authenticated. This form of authentication can expose your user names and passwords unless all connections
are over SSL. If someone can intercept the transmission, the user name and password information can easily be decoded. However, when a secure transport mechanism, such as SSL, or security at the network level, such as the IPSEC protocol or VPN strategies, is used in conjunction with form-based authentication, some of these concerns can be alleviated.

This is widely used over a secure layer (SSL).


Client certificate (HTTPS Client) authentication

HTTPS Client Authentication requires the client to possess a Public Key Certificate (PKC). If you specify client authentication, the web server will authenticate the client using the client’s public key certificate.
HTTPS Client Authentication is a more secure method of authentication than either basic or form-based authentication. It uses HTTP over SSL (HTTPS), in which the server authenticates the client using the client’s Public Key Certificate (PKC). Secure Sockets Layer (SSL) technology provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. You can think of a public key certificate as the digital equivalent of a passport. It is issued by a trusted organization, which is called a certificate authority (CA), and provides identification for the bearer.

Before using HTTP Client Authentication, you must make sure that the following actions have been completed:
- Make sure that SSL support is configured for your server.
- Make sure the client has a valid Public Key Certificate.
The following example shows how to declare HTTPS client authentication in your deployment descriptor:

<login-config>
    <auth-method>CLIENT-CERT</auth-method>
</login-config>

Mutual authentication

- Certificate-based mutual authentication
- User name- and password-based mutual authentication

When using certificate-based mutual authentication, the following actions occur:

A client requests access to a protected resource.
The web server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.

In user name- and password-based mutual authentication, the following actions occur:

A client requests access to a protected resource.
The web server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its user name and password to the server, which verifies the client’s credentials.
If the verification is successful, the server grants access to the protected resource requested by the client.
If successful, the server grants access to the protected resource requested by the client.


Digest authentication

Like HTTP basic authentication, HTTP Digest Authentication authenticates a user based on a user name and a password. However, the authentication is performed by transmitting the password in an encrypted form which is much more secure than the simple Base64 encoding used by basic authentication.
However like BASIC authentication the control is given to the browser to ask and transmit the username and password information.

Digest authentication is not currently in widespread use

<login-config>
    <auth-method>DIGEST</auth-method>
</login-config>

Securing using SSL: http://docs.oracle.com/javaee/5/tutorial/doc/bnbxw.html#bnbyb


http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JNDIRealm