On Thu, 13 Feb 2003, Bryan Field-Elliot wrote:
> Date: 13 Feb 2003 16:41:08 -0700
> From: Bryan Field-Elliot <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Cc: Craig R. McClanahan <[EMAIL PROTECTED]>
> Subject: Re: JAASRealm/LoginManager questions
>
> See below:
>
> On Thu, 2003-02-13 at 16:14, Craig R. McClanahan wrote:
>
>
> For Tomcat (at least), such a redirect will not work at all. The
> magic
> "j_security_check" URL is only enabled when the container did its
> "save
> the original request and display the form login page" trick. At all
> other
> times, you'll get a 404.
> That assumption does not match what the spec allows. Even if you
> tried
> this, and even if Tomcat listened to "j_security_check" at other
> times
> (to make your idea work), there is no way to implement step 7 of the
> required functionality of form based login ("the client is
> redirected to
> the resource using the stored URL path") since there is no such
> thing as a
> stored URL path -- you bypassed Step 1 where the storing took place.
>
>
> I assume you're talking about Servlet (2.3) spec section SRV12.5.3, Form
> Based Authentication.
>
> I'm not proposing to skip step 1.
>
OK ... kinda fun to see how creative we can be in twisting the
container's behavior :-).
First problem ... step 1 is only invoked when
* This request is from an unauthenticated user
* This request is for a protected resource
Now, consider the URL to which you're sending the SOAP message in the
first place. Do you protect it with a security constraint or not? If you
do not, Step 1 will never happen (and, in Tomcat, the magic
"j_security_check" will not get enabled). If you do, then container
managed security will have been completed before your filter ever gets a
shot at the request.
> Instead, I'm proposing that in step 3, instead of presenting a <form>
> with action="j_security_check", we give a different action URL, such as
> a JSP page or Struts action. (Actually let's just forget the whole
> "Filter" angle for the time being).
>
In other words, you want to replace the standard logic of form based
authentication (as implemented in
org.apache.catalina.authenticator.FormAuthenticator) with something
different than what it actually does.
That's fine ... that's what it means to create a new Authenticator.
> This JSP page or Struts action takes the request parameters (which will
> include things OTHER than j_username and j_password), and will construct
> a new request (either as a Servlet forward, or as a browser
> POST-by-way-of-Javascript) to "j_security_check", containing the
> appropriate parameters.
>
As above, j_security_check is not turned on unless the *container* did
step 1 itself. And that puts you back to the conundrum described as
"first problem" above.
> I hear you saying that this isn't possible, but I'm not seeing anything
> in the Servlet spec which says, "The next HTTP request from the client,
> after step 1, MUST be the j_security_check POST". Nor does it say, for
> example, "if, after step 1, a request comes in for any URI other than
> j_security_check, then invalidate the original authentication request
> and the
> original-requested-URL-wherever-it's-being-kept-for-later-redirecting".
>
The spec doesn't say that. But it doesn't say that j_security_check is
enabled all the time, either. All the spec says is what *must* be
supported (i.e. the standard approach). Counting on anything beyond that
(even if it might work in some containers) is, by definition, not
portable.
> Still no-go? ;)
>
Sorry ... good try though :-)
> Bryan
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
