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?
----- Original Message -----
From: Carlos Pita
To: tomcat-dev@jakarta.apache.org
Sent: Thursday, February 08, 2001 4:42 PM
Subject: Login Form & Authentication

    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