This chapter is from the book
This chapter is from the book
This chapter is from the book
Basic Authentication
Basic authentication is defined by the HTTP/1.1 specification. When a client attempts to access a protected resource, the server prompts for a username and password. If the server can authenticate that username and password, access is granted to the resource; otherwise, the process repeats. The server retries a server-specific number of times, three being typical.
The most notable aspect of basic authentication is its total lack of security. Passwords are transmitted with base64 encoding, which provides no encryption, thus making the passwords vulnerable.
Figure 9-1 illustrates basic authentication with Tomcat 4.0.
){kind=link}
Figure 9-1 Basic Authentication with Tomcat 4.0
From top to bottom in Figure 9-1: An attempt is made to access a protected JSP page—/protected-page.jsp—and the user is presented with a dialog. After the dialog is filled out and the username and password are authenticated, the JSP page is displayed. That JSP page is listed in Example 9-1.a.
Example 9-1.a /protected-page.jsp
<html><head><title>A Protected Page</title></head>
<body>
<%@ include file='show-security.jsp' %></p>
<p>
<% if(request.isUserInRole("tomcat")) { %>
You are in <i>tomcat</i> role<br/>
<% } else {%>
You are <b>not</b> in <i>tomcat</i><br/>
<% } %>
<% if(request.isUserInRole("role1")) { %>
You are in <i>role1</i><br/>
<% } else {%>
You are <b>not</b> in <i>role1</i><br/>
<% } %>
</p>
</body>
</html>
The JSP page listed in Example 9-1.a prints security information and the principal's role—tomcat or role1. Security information is printed by a JSP page that's listed in Example 9-1.b.
Example 9-1.b /show-security.jsp
<font size='4' color='blue'>
Security Information:
</font><br>
<p>
User principal: <%= request.getUserPrincipal().getName() %>.<br/>
User name: <%= request.getRemoteUser() %>.<br/>
Request Authenticated with: <%= request.getAuthType() %>.<br/>
<% if(request.isSecure()) { %>
This connection is secure.<br/>
<% } else { %>
This connection is not secure.<br/>
<% } %>
</p>
Remote Addr: <%= request.getServerName() %><br/>
Remote Host: <%= request.getRemoteHost() %><br/>
Remote Addr: <%= request.getRemoteAddr() %>
The JSP page listed in Example 9-1.b can be handy for debugging authentication.
The protected JSP page listed in Example 9-1.b is specified as a protected resource in the application's deployment descriptor, which is listed in Example 9-1.c.
Example 9-1.c /WEB-INF/web.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2.2.dtd">
<web-app>
<security-constraint>
<!-- web resources that are protected -->
<web-resource-collection>
<web-resource-name>A Protected Page</web-resource-name>
<url-pattern>/protected-page.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- role-name indicates roles that are allowed
to access the web resource specified above -->
<role-name>tomcat</role-name>
<role-name>role1</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Basic Authentication Example</realm-name>
</login-config>
</web-app>
The deployment descriptor listed above restricts access to /protected_page.jsp to principals in either tomcat or role1 roles, and BASIC is specified as the authentication method.
With Tomcat, usernames and passwords are associated with roles in $TOMCAT_HOME/conf/tomcat-users.xml, which is listed in Example 9-1.d.
Example 9-1.d $TOMCAT_HOME/conf/tomcat-users.xml
<tomcat-users> <user name="tomcat" password="tomcat" roles="tomcat" /> <user name="role1" password="tomcat" roles="role1" /> <user name="both" password="tomcat" roles="tomcat,role1" /> </tomcat-users>
The configuration file listed in Example 9-1.d binds the username tomcat and password tomcat, which were used in the application shown in Figure 9-1 on page 256, to the tomcat role. That's why the application shows that the principal is in tomcat role, but not in role1.
The entry for username both in Example 9-1.d illustrates how you can associate a single principal with multiple roles using Tomcat. In Figure 9-1 on page 256, if we had logged in as both, we would be in both tomcat and role1 roles.