posted 15 years ago
When you use web.xml to define security, you're offloading security to your web application container. Which is as it should be if you intend to authenticate and authorize via a Tomcat Security Realm.
However, container-managed security means exactly that. You don't write your own login code, the container manages the login. The user ID and password are never directly accessible by the application. Which is also good, since if someone hacks the application, they cannot plunder it for login information.
The closest thing you'll have is the User Principal object, which is constructed by the Realm when the user is logged in. You can obtain a reference to this by invoking getUserPrincipal() on your request object. Usually the userID will be the ID in the principal, although I suppose a Realm could supply any unique identifier it wanted to.
In accordance with good security mearures, the password isn't visible at all, and in fact, isn't sent back to Tomcat in most cases. The SQL equivalent is:
In a case like this, if the correct password was supplied, the return count will be nonzero (hopefully it will be 1!). An invalid user ID or password would return back zero, without giving any hints to hackers as to what a valid user ID or password might be.
Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer
