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.
Ken
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
