Ken Bowen wrote:
Can you use url-rewriting (tukey.com) to get what you want:
/secure/yyy --> /formauth/secure/yyy --> Form based auth
etc???
On Dec 9, 2009, at 4:07 PM, Anthony Jay wrote:
Hi All,
etc...
Ok, my try here. And by the same token - haha - I will give a chance to
Chris to jump in.
- there is (preferably) one application. As Chuck is saying, it should
not care /how/ the user was authenticated, just that he is.
That's just a getRemoteUser() for you, isn't it?
- unfortunately, the Holy Servlet Spec does not foresee nor allow that 2
alternative methods of authentication would be used. It's either
"form-based" or "Basic" (at least for container-based authentication).
So the hell with the Servlet Spec and container-based authentication,
let's turn our own.
- but, as far as I recall, Anthony has, as users, humans who are capable
of filling-in a form, but also stupid programs who cannot and can only
do basic. The humans can however (mostly) be distinguished from the
machines in some way (preferably by the URL they request).
This looks to me the perfect case for a servlet filter.
The filter applies to all requests to the webapp.
It examines the request, and first it must determine if this request is
already authenticated.
A) that is the case if :
- the request itself contains an "Authorization:" header. This would
mean that whatever it is on the other side has already gone through
Basic authentication once for this same realm, and is resending the
authentication "token" along with the request.
(In other words, it is a machine, or a human posing as one).
Then, the job consists of Base64-decoding the header value, retrieve the
user-id, and tell Tomcat what it is. (funnily, I don't know how to do
that). And of course we let the request go through to the application.
(We may also want to check these credentials, if it is not too heavy).
Alternatively
- the request contains an authentication cookie (header). I'm not quite
sure what the security level desired is here. But I suppose that if
Basic authentication is one of the options, it cannot be that high, or
else all this goes through HTTPS.
The job then consists of interpreting this authentication cookie,
extract a user-id from it (or from something saved on the server side),
and tell Tomcat about it (which I still don'tknow how to do, but Chris
will know).
And of course we let the request go through to the application.
(We may also want to check these credentials, if it is not too heavy,
and if we do not trust the user not to mess around with the cookies).
We also make a note to send an (updated?) cookie along with the response.
B) Neither of the above is true, so the request is not authenticated.
We have to decide if this request is or not the post of an
authentication form (unless /login e.g. is a separate webapp).
- If it is, we need to retrieve the form parameters, and check the
credentials. If they don't fit, return the same login form.
If they do fit, retrieve the user-id and tell Tomcat about it.
Also make a note that a cookie will have to be sent along with the response.
We also redirect the request to the URL which the user wanted in the
first place, and which we smartly saved before.
- If it is not (a login form), then it is a "normal" request from either
a human or a program (the URL tells us).
- If from a user, return a login form. In that login form, smartly
save the URL which the user wanted, but which he is not getting as long
as he doesn't show his credentials.
- If from a program, return a 401 response (AAA required), and let
the remote program deal with it.
There are a couple of restrictions to the scheme (such as the fact that
the first human request should not be a POST with a body; and there is
no logout; and I kind of skipped roles here).
Any comments ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
