tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Field-Elliot <>
Subject Re: JAASRealm/LoginManager questions
Date Fri, 14 Feb 2003 00:10:20 GMT

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
    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
    > 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
    > include things OTHER than j_username and j_password), and will
    > 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*
    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
    enabled all the time, either.  All the spec says is what *must* be
    supported (i.e. the standard approach).  Counting on anything beyond
    (even if it might work in some containers) is, by definition, not

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message