Below...
I hope it helps
Glenn Mc
----- Original Message -----
From: "lightbulb432" <[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
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
reached.
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
it!
Still if you wished to pursue this course of action I think you have two
options.
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:
http://www.nabble.com/Authentication-and-authorization-questions-tf4345698.html#a12380709
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
