On Thu, 2003-02-13 at 16:51, Craig R. McClanahan wrote:
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.
Never mind SOAP for now. For SAML, there is a SOAP call (as a client)
made inside my intermediating JSP page or Action (the one which consumes
SAML request parameters and produces j_username and j_password), but
that doesn't change the sequence flow I'm trying to nail down here.
> 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.
Container can do step 1, that's fine. Step 1 culminates in rendering MY
page, which I configured by way of <form-login-page> in web.xml. All I'm
asking is, in MY form-login-page, can I NOT do the standard "<form
action="j_security_check">", but instead, do some other stuff which will
result in a hit to another one of my JSP pages FIRST, and then finally
get the user to access j_security_check a couple of HTTP requests later?
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.
So I guess this is really the crux of the matter... Will containers, in
general, expire the "URL path triggering the authentication", if the
next request happens to NOT be for "j_security_check"?
You're saying, "who knows? it's not specified." That by definition isn't
a safe bet.
