Later in the chapter we’ll go deeper into authentication, but for now we’ll look at getting just enough authentication data into the system so that we can focus on authorization. A user can’t be authorized until he’s been authenticated.

The servlet specification doesn’t talk about how a Container should implement support for authentication data, including usernames and passwords. But the general idea is that the Container will supply a vendor-specific table containing usernames and their associated passwords and roles. But virtually all vendors go beyond that and provide a way to hook into your company-specific authentication data, often stored in a relational database or LDAP system (which is beyond the scope of this book). Typically, this data is maintained by the administrator.

The security “realm”

Unfortunately, realm is yet another overloaded term in the security world. As far as the servlet spec is concerned, a realm is a place where authentication information is stored. When you’re testing your application in Tomcat, you can use a file called “tomcat-users.xml” (located in tomcat’s conf/directory, NOT within webapps). That one “tomcat-users.xml” file applies to ALL applications deployed under web-apps. It’s commonly known as the memory realm because Tomcat reads this file into memory at startup time. While it’s great for testing, it’s not recommended for production. For one thing you can’t modify its contents without restarting Tomcat.

The tomcat-users.xml file

Enabling authentication

To get authentication working (in other words, to get the Container to ask for a username and password), you need to stick something in the DD. Don’t worry about what this means for now, but if you want to start playing around with authentication, use this:

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