tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn McCall" <>
Subject Re: Authentication and authorization questions
Date Wed, 29 Aug 2007 10:45:10 GMT

I hope it helps

Glenn Mc

----- Original Message ----- 
From: "lightbulb432" <>
To: <>
Sent: Wednesday, August 29, 2007 2:33 PM
Subject: Authentication and authorization questions

> I have several questions about authentication and authorization in Tomcat
> below, so answer only what you can :) Thanks.
> Where does Tomcat authentication fit into the request processing 
> lifecycle?
> Does it happen before even the very first filter gets called? What happens
> just before and just after authentication?
> Where does the role-based authorization fit into this process?
> 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.

These forms can be jsp's so I guess you can include whatever logic you like 
in them. I haven't tried, but you could theoretically put something like a 
retry count which forwards to a different failure page when the limit is 

> Is it configuration whether Tomcat uses redirects or forwards after
> successful or unsuccessful attempts? What's the default for both?
> How can you use JDBCRealm or DataSourceRealm with 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? I ask because using simple text-matching rather than 
> using
> the primary key of the user table seems a bit inefficient, but more
> importantly it may be disallowed from data standards in some 
> organizations.

I'm not sure what you are asking here. The JDBC realms assume the user ID is 
a primary key (PK). This makes sense as a PK must be unique. Since user id's 
should also be unique, you they would make sense as a natural primary key. 
I'm not sure I understand what the problem is that you are trying to solve 
here. If you are concerned about join performance to the roles table on a 
varchar, I don't think that that would be your major concern. First off most 
databases hash data values to a code (typically a 32, 64, 128 bit value or 
even larger) that is used to locate records on disk. So if you define a 
secondary index on the roles table access to it via the SI should be fairly 
efficient via the user ID irrespecitive of its data type. Second of all the 
database interactions you are going to perform, how many are going to be 
logons? I suspect that the rest of your application would put more of a load 
on the database than the query that determines the roles the user ID is 
associated with. Third consider I/O performance (i.e. reading a data block 
from disk) to the time it is going to take to compare a 64 character value. 
I suspect that most modern processors would be able to perform billions of 
such comparisons in the time it takes to read one data block!

It sounds like you are looking for a surrogate key (i.e. another value - 
presumably system generated - to act as a substitute for the user id). If 
you did this, I doubt you would be saving anything as you would still 
require the database to retrieve user details by the id entered by the user. 
So I can't see how you will be saving anything.

So once again, I tried to imagine what your concern is, but just can't pick 

Still if you wished to pursue this course of action I think you have two 
1) Hide the surrogate relationships behind views and/or
B) develop your own authentication scheme via JAAS.
There is of course a third option:
#) Just go with the flow a.k.a. if it aint broke, don't try to fix it :-)

> Thanks.
> -- 
> View this message in context: 
> Sent from the Tomcat - User mailing list archive at
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message