tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Contexts and Path and Authentication
Date Wed, 09 Dec 2009 22:40:46 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message