tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: JAASRealm/LoginManager questions
Date Thu, 13 Feb 2003 23:51:55 GMT

On Thu, 13 Feb 2003, Bryan Field-Elliot wrote:

> Date: 13 Feb 2003 16:41:08 -0700
> From: Bryan Field-Elliot <>
> To: Tomcat Users List <>
> Cc: Craig R. McClanahan <>
> 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

> Still no-go? ;)

Sorry ... good try though :-)

> Bryan


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

View raw message