tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Field-Elliot <bryan_li...@netmeme.org>
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
    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.





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