On Thu, 13 Feb 2003, Bryan Field-Elliot wrote:
>
> Craig, there is one subtle point I was trying to make, and I'm not sure
> if you got it. I was NOT proposing that my Filter perform
> container-managed sercurity authentications (as you went on to explain
> was impossible).
Well, you want to get in the middle of the container-managed
authentication process ... same thing :-).
> Instead, I was proposing that my Filter re-write the
> request parameters of an incoming FORM-POST into the Servlet-standard
> "j_username" and "j_password", and then Forward (or do I have to
> Redirect?) to the "j_security_check" URI.
>
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.
> My filter would be consuming the SAML response, munging it into other
> parameters (j_username, j_password), and re-posting (or forwarding) to
> j_security_check.
>
> This would let me use: (a) the standard FORM auth-method in web.xml,
> (b), a standard Filter, and (c) a standard JAAS LoginModule, without
> having to write any container-specific code (such as a Tomcat
> Authenticator).
>
> The assumption I am making in order for this to work, is that the
> Servlet spec will allow requests to appear in the middle of the
> FORM-based authentication, AFTER the original form has been rendered to
> the browser, but BEFORE a POST is made to "j_security_check".
>
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.
> With my slightly more detailed explanation, do you still assert that
> this can't work, and that I have no choice (today) but to go to
> container-specific extensions like Tomcat.Authenticator?
>
Yes, I do. There is no way that a Filter can get involved in any standard
container managed authentication process, because it is not invoked until
after the container managed authentication is completed.
It is *possible* that this scenario will change as a result of JSR-196.
But that's for the future, not for the present.
If you don't care about container managed security, of course, you can
write a filter that fakes it, simply by wrapping the incoming request with
a wrapper that returns different things for getRemoteUser(),
getUserPrincipal(), and isUserInRole(). However, that means giving up on
security constraints in web.xml, as well as propogation of the identity to
EJB calls in a J2EE app server. But it may be enough to meet your needs.
For an example of a filter that implements this sort of thing, see
<http://securityfilter.sourceforge.net>.
> Thanks for hashing this out with me,
>
> Bryan
>
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
