tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Authentication and authorization questions
Date Wed, 29 Aug 2007 14:59:43 GMT
Hash: SHA1


lightbulb432 wrote:
> Where does Tomcat authentication fit into the request processing lifecycle?
> Does it happen before even the very first filter gets called?

Yes. It's implemented as a Valve that runs before any of your code gets
a chance to run.

> What happens just before and just after authentication?


When a request comes in, Tomcat checks to see if the resource is
protected (by a <security-constraint> in web.xml). If it is, Tomcat
checks to see if there's a Principal associated with the request
(session, I'm guessing).

If there's no Principal, the current request is saved and the user is
redirected to the <form-login-page>. The login page should submit to
j_security_check with the j_username and j_password request parameters.
Once the user is authenticated, Tomcat attempts to re-run the saved
request, and the process starts over again.

If there /is/ a Principal, it checks to see if any of the required role
names for the resource are held by the Principal. If none of the roles
match, you get a 403 error. If there is a role match, the request
continues normally.

> Where does the role-based authorization fit into this process?

See above.

> When you login using form-based authentication, where invalid login attempts
> redirect to the "form-error-page", how do you add a custom message to that
> page saying "Login Failed"? I ask because common practice is to send the
> user to the same login page rather than a different page.

You can do whatever you want, since you get to control the pages for
login and login-error.

> Is it configuration whether Tomcat uses redirects or forwards after
> successful or unsuccessful attempts? What's the default for both?

There is no configuration for this. Some versions forward, others do
not. There is no default because it's not in the specification.

> How can you use JDBCRealm or DataSourceRealm with [numeric] foreign keys from roles
> table to user table, rather than requiring the roles table to duplicate
> whatever field (e.g. username, email address) will actually be entered into
> the login screen?

You can't. You'd have to write your own Realm implementation.

> I ask because using simple text-matching rather than using
> the primary key of the user table seems a bit inefficient

Are you sure about that? You might want to do a performance test on your
database. You're likely to find that string matching is /very/ fast,
especially if you have the columns indexed (and you really should).

> but more
> importantly it may be disallowed from data standards in some organizations.

I think the most important thing is data duplication. Why should I have
to put the user's username into the user_role table multiple times? It
seems silly, but honestly, it's the simplest thing that could possibly
work, which is exactly what the TC devs should have done.

If you don't like the implementation, write your own.

In fact, I don't much care for the TC implementation of the whole
authentication thing anyway, so I have opted to dump it and use
securityfilter instead. Primarily, it allows me to do direct logins
(submit to j_security_check even when no protected resource has been
requested), and I can write my own authenticator that isn't tied to
Tomcat's implementation in any way. That allows me to switch TC versions
or to another vendor entirely without changing a single thing in my
implementation. But that's just me.

- -chris
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message