Hi again!
After thinking about my previous questions I
decided that a good solution could be:
(Before going to the point I must say that I'm
programming a RequestInterceptor to authenticate the user against an entity EJB,
so I will not use neither SimpleRealm nor JDBCRealm. We could call it EJBRealm
right by now)
I think I could take the following for
(well...almost) granted:
1) AccessInterceptor will not be
interested in j_username or j_password (I hope not only in the current code
but in future releases too).
2) AccessInterceptor will register two Handlers,
one for authentication (that will be mapped to /j_security_check) and
one for login (that will call the registered login servlet or jsp when
needed).
3) EJBRealm authorize (and/or
authenticate) method will be called before any of the 2 handlers. If it can
authorize the request neither of both handlers will be called. If it can't, the
login handler will be called (currently FormAuthHandler).
4) The login handler will redirect the request to
my registered login form. I think I can assume that it will not complain about
j_username or j_password not being defined, because it should know how to
deal with this precondition.
5) My form will not have action=/j_security_check,
from this point I'm disobeying servlet 2.2 traditions. I can do what I want
here, I don't need to register j_password or j_username but only to align to an
authentication method shared with EJBRealm. The registered error form is never
reached (in fact, it is a fake one). j_security_check is never
reached.
Of course, I don't want to pretend that these
points are true. But I need to find a solution based in the least
possible assumptions. What do you think about this one?
Carlos
----- Original Message -----
Sent: Thursday, February 08, 2001 4:42
PM
Subject: Login Form &
Authentication
Hi!
I'm working in a project using
servlets (with Tomcat 3.2) and I have a question regarding the security
mechanisms described in servlet 2.2 spec and how to integrate them
with other aspects of the application than login (for example,
registration). More specifically, the application offers a registration form
in the home page (nothing new here) and a registration form in the same page
as the login form, which should be showed when a resource
declaratively marked as secure is being accessed (nothing new here). So, for
my surprise, I see no way to solve the next 2 problems inside the
2.2 spec (I'm using FORM authentication):
1) in the registration form in
the home page there is no concept of a secured page to go once registered, but
the user should still be logged, so if I call j_security_check it's not
defined what would happen (and the solution is really dirty);
2) in the registration form in
the login page, if the user choose the registration way, the form can't
be directly submited to j_security_check because his/her information
should be saved before being completely lost.
I wanted to be standard, 2.2
standard! But instead I ended reading Tomcat request interceptors sources.
Still I'm looking for a clean solution. I obviously should set the
session j_username and j_password directly and this doesn't seem very
portable. If I do that and then move my servlets to other container than
Tomcat nasty things could happen. I think I would need to get the sources
again (if available) or to program all the security stuff by myself (idea!:
using j_username and j_password in the session to reuse my 6 lines of code). I
can't believe than servlet spec doesn't provide an API to authenticate the
user.
I'm urged to
know:
1) Is there a better
solution?
2) If not, will the solution I
proposed work?
Thank you
Carlos
|