Q:	Q: I understand that putting in an empty <auth-constraint/> element tells the Container that NOBODY from any role can access the constrained resource. But I don’t understand WHY you would ever do that. What good is a resource that nobody can access?
A:	A: When we said, “NOBODY”, we meant, “Nobody from OUTSIDE the web app”. In other words, a client can’t access the constrained resource, but another part of the web app can. You might want to use a request dispatcher to forward to another part of the web app, but you don’t ever want clients to request that resource directly. Think of 100% constrained resources as sort of like private methods in a Java class—for internal use only.
Q:	Q: Why does the <auth-constraint> element go inside <security-constraint> but NOT inside the <web-resource-collection> element?
A:	A: This way, you can specify a single <auth-constraint> element (which could include multiple roles), and then specify multiple resource collections for which the <auth-constraint> role list applies. For example, you might define an <auth-constraint> for a Frequent Buyer role, and then put <web-resource-collection> elements in for the all the different parts of the web app where a Frequent Buyer gets special access.
Q:	Q: Do I actually have to sit there and type in every one of my users with their passwords and roles?
A:	A: If you’re using the test memory realm from Tomcat, yes. But chances are, in the real world you’re using a production server that gives you a hook into the LDAP or database where your real user security info is stored.