tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Basic authentication without a secure connection
Date Mon, 04 May 2009 18:35:45 GMT
Hi.

So now we're making progress.
Unfortunately, I don't think that there is a "simple" solution.

I think that the easiest solution to implement in this case, would be :
- remove the authentication filter you have at the Tomcat level.
- put an Apache httpd front-end to /both/ your Struts application 
(server) and your php application (server). This Apache httpd will act 
as a proxy to both back-end servers, and look like a single server to 
your users.
- do the Basic user authentication at the level of the front-end Apache 
httpd, and pass this authenticated user-id to either back-end (Tomcat or 
php host) when needed.


So we would have :

browser <--> front-end <--> Struts
                        <--> PHP

The front-end authenticates, and passes the id to Struts or PHP.


The reason : let me describe what happens in the case of a Basic 
authentication (the way your php host does it) :
1) the browser initially sends a request like
http://msphphost.company.com/some-php-app.php
2) at the level of that php host, the configuration is that this URI 
(/some-php-app.php) is protected, with a Basic authentication.
(It also has a "realm", which is kind of a name for a specific area of 
the server. Say that this is "Protected Application")
So the server sends back a response to the browser : "401 Authorization 
required". Along with that status code, it also sends a HTTP header like
Authorization: type: Basic, Realm: "Protected Application"
3) when the browser receives this response 401, it immediately pops up 
the user login dialog.  In the title bar of this dialog, the browser 
usually displays the realm sent by the server, in this case "Protected 
Application".
4) the user enters his user-id and password.
5) the browser encodes this user-id and password (very weakly) in a 
Base-64 string.
6) the browser now sends the same request again to the same host :
http://msphphost.company.com/some-php-app.php
but this time, it adds a HTTP header :
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxx
7) the server gets this new request, and now it finds the Authorization 
header. Provided this is a valid user-id and password, the server 
returns the requested content.

Now, after the above happens once, whenever the browser will access 
/this same host/ and receive a 401 Authentication required response with 
/the same realm/ as before, the browser will automatically, without 
asking the user again, resend the request with that same Authorization 
header. (As long as the user does not close the browser; if the user 
closes the browser, this "memory" is lost).
And the server, because of (7) above, will be happy and deliver the content.

(That was the reason I suggested you install HttpFox, because you will 
be able to see this really step by step, as it is happening).

The key elements above are :
- it must be the same hostname
- it must be the same realm name
- it must be Basic authentication
If those 3 elements are not all there, then it will not work, and the 
browser will pop up the login dialog again.

In other words, if the browser accesses the applications on two 
different hosts, it will not work.
That is why I suggest to use a front-end server.
Here are some details :

1) The users will always use a URL like
http://frontend.mycompany.com/my-struts-app
or
http://frontend.mycompany.com/my-php-app

2) the front-end server will have 2 "areas" configured :
"/my-struts-app"
and
"/my-php-app"
Both these areas will be protected by Basic authentication, and they 
will have the same realm name (say "AllMyApps").

3) the first time a user asks for one of these links, the browser will 
pop up a login dialog to login the user.
After that, the front-end server knows the user-id.

4) the front-end server will now, on the base of the requested URI, 
forward the call to either the Tomcat server, or the PHP server.
In both cases, it will also forward the user-id, together with the request.

5) when the respective back-end server sends back the response (to the 
front-end server), the front-end server returns it to the browser.
For the browser, both appear to come from the same server, the realm is 
the same, and it is always Basic authentication.  So the browser will 
never ask the user to login again, and keep sending the same 
"Authorization:" header.

Any questions ?
;-)






Tokajac wrote:
> Answer on the FIRST question:
> I want to have Struts and php applications on separate hosts (if possible). 
> If not, I will consider possibility for putting them on same host...
> 
> 
> SECOND:
> Tomcat application is using j_security_check, not Basic authentication. 
> User-id and password are kept in session. They can be reached anytime.
> 
> 
> The scenario that you wrote is exactly what I want.
> How can I implement it?
> 
> 
> I'll also look after HttpFox.
> 
> 
> Regards(!!!)
> 
> 
> 
> awarnier wrote:
>> Mmmm wait.. I think I am starting to understand what you want.
>>
>> A question first : are the Tomcat server (+Struts) and the php 
>> application on the same host ?
>>
>> A second question : does your Tomcat host know the login user-id and 
>> password of the users ? In other words, can the host where Tomcat runs 
>> /verify/ the user login ?
>>
>> Is what you want the following ?
>> You want that the users connect to the Tomcat host first, login, and 
>> then that this login would be valid for both the Tomcat application and 
>> also the php application ?
>> So that, in your Struts application, you could just give them a link to 
>> the php application, and when they click on that link they go the php 
>> application, but do not have to login again ?
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message