Tomcat Security and Analysis - 2

TOMCAT SECURITY AND ANALYSIS

Etisalat

DEVELOPER

bangalore

india

BLOGGER

SEX

Authentication
By default, you do not need to authenticate to access Tomcat resources. Authentication is needed only when specified in the deployment descriptor with the auth-constrain element. You use a web client (typically a web browser) to authenticate with Tomcat using one of the following mechanisms:
HTTP Basic Authentication
HTTP Digest Authentication
Form Based Authentication
HTTPS Client Authentication
HTTP Basic Authentication
When your browser prompts you for a username and password in a dialog box, you are using HTTP basic authentication to logon to a web server. This is also know as browser-based authentication because the web server requests the browser to authenticate you through the HTTP 1.0 protocol. In the dialog box, you also see the name of a realm to which you will be authenticated. The realm does not necessarily reflect a security policy domain, which is also referred to as a realm. Think of an HTTP basic authentication realm as a "database" of usernames and passwords that identify valid users of a web application (or set of web applications), plus a list of the roles associated with each valid user.
Once you enter your username and password, they are base64 encoded and sent by the browser to Tomcat (for both secure and non-secure resources). Tomcat authenticates you, and then reauthenticates each subsequent request against the specified realm. You cannot logout as your username and password remain in browser memory until you exit. Hence, you must exit the browser to "logout".
Because the username and password are not encrypted, and the target server's identity is not authenticated by the browser, basic authentication alone is not secure. You can improve security by using a secure transport mechanism such as HTTPS, or security at the network level such as a VPN. However, if you switch to HTTP (after authenticating with basic authentication and HTTPS), your browser continues to send your username and password with each subsequent request in cleartext until you exit.
HTTP Digest Authentication
HTTP digest authentication is also performed by the browser upon request by the web server and based on a username, password, and realm. However, in this case your password is digested with the secure MD5 algorithm before it is sent by the browser.
You can specify in Tomcat's element a digest attribute, which must be one of the digest algorithms supported by the java.security.MessageDigest class (SHA, MD2, or MD5). When you select this option, the contents of the password that is stored in the realm must be the digest version of the password. The client must also digest the password using the same algorithm before it is sent. When the realm authenticate() method is called, the password you input is compared with the value returned by the realm and, if equal, you are authenticated.
Because your password is digested, HTTP digest authentication is more secure than basic. However, it does suffer from the same security issues as basic authentication. As it is not supported by popular browsers, HTTP digest authentication is not required by the servlet specification, but it is implemented by Tomcat. As with basic authentication, your credentials are stored in the browser's memory until it is exited.
Form Based Authentication
This is the most popular web authentication mechanism in use. It provides the application developer with the greatest control over the look and feel of the “login screen”, enables closing of user sessions without exiting the browser, and is more secure than basic authentication.
The web application deployment descriptor contains elements to specify a "login form" and an "error page". The HTML login form must contain fields for entering a username and a password, which must be named "j_username" and "j_password", respectively. When you attempt to access a protected resource, Tomcat checks if you are authenticated. If not, the following steps occur:

1. Tomcat saves the entire HTTP request, then redirects the browser to the configured login form.
2. You enter your username and password in the login form's "j_username" and "j_password" fields.
3. The browser posts the form back to the server using the "j_security_check" action.
4. The container attempts to authenticate the user using the configured security realm.
5. If authentication fails, the error page is returned with the status code of the response set to 401.
6. If authentication succeeds, the principal is checked to determine if you have a role authorized to access the resource.
7. If you are authorized, Tomcat processes the original HTTP request. If authentication fails, or you are not authorized to access the requested resource, the configured error page is returned.

Because your username and password are not encrypted and the target server is not authenticated, form-based authentication using HTTP is not secure. If you are using form-based authentication, you should use a secure transport mechanism such as HTTPS, or security at the network level such as a VPN. However, form-based authentication is more secure than basic authentication when switching back and forth between HTTPS and HTTP as your username and password are not sent with each request.

Another advantage of form-based over basic authentication is that the application can programmatically close your authenticated session, enabling you to logout without restarting your browser. In this respect, calling the HttpSession.invalidate method seems like it should work, but it does not because HTTP sessions are totally independent of authentication (e.g., you can have an HTTP session without authenticating and authenticate without having an HTTP session).

Previous   Next