tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Johanson <>
Subject Re: Calling Realm.authenticate() doesn't register Principal in with the Session??
Date Tue, 07 Feb 2006 23:29:55 GMT
Mark Thomas wrote:
> Ken Johanson wrote:
>> Mark, are you saying that you agree, or disagree, with the usefulness of
>> the idea?
> I am -0 to the idea as a whole. I don't see the point but am happy to
> proivde pointers where I can.
> Mark

Okay - do you have any pointers for this need?: (please forgive me for 
possibly repeating what may have been mentioned earlier)

-A third party API (that I'm writing, just as could anyone else) must be 
'dropped in' to any recent Tomcat version; it must allow users of the 
API to authenticate (using only username and passwd) against whatever 
existing realm they have configured, without ANY changes to that realm's 
config or impl. This INSURES that any existing authentication code 
(form, jdbc) continues to work.

-OR- if there is a way already without using the third party API, what 
is it? Say, something along the lines of setting request-context 
attributes, or beans props (beans being less ideal)..

-Finally, the solution (existing or new) MUST allow code within a 
servlet, jsp, bean, or POJO, etc to pass ONLY a username + password, or 
alternatively only an X509Certificate, into some class who will simply 
return a true|false, or throw an exception on authentication failure.

Hence, the idea allows more flexibility when additional layers are 
REQUIRED atop the authentication pre-processing. An example, would be to 
perform a database lookup of an email address(s) (entered into a login 
form's username field) and translate it into a Principal, is then passed 
into the webapp's preconfigured Realm.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message