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 auth required on https but not required on http
Date Wed, 20 Feb 2013 18:40:06 GMT
Andrew Winter wrote:
> On Wed, Feb 20, 2013 at 5:13 AM, André Warnier <aw@ice-sa.com> wrote:
> 
>> The standard modus operandi of this list is to not top-post (makes it more
>> difficult to follow the logical flow of conversation).
>> So I've copied your response and my further comments at end.
>>
>>
>>>  Andrew Winter wrote:
>>>>  I work on an intranet type application.  While on the local network
>>>>> calls
>>>>> are made to regular http and authentication is not allowed due to a
>>>>> large
>>>>> number of established services that call the server without providing
>>>>> authentication.  However, the server accepts calls from the outside over
>>>>> SSL (regular http port is blocked by firewall). In these cases the use
>>>>> of
>>>>> basic authentication is required.  I don't see a way to have work like
>>>>> this.  With our older setup we used Apache as a front end and had a
>>>>> virtual
>>>>> host file for each port.  One used https and basic auth and the other
>>>>> didn't. Both pointed to the same web app.  Now I must send calls
>>>>> directly
>>>>> to Tomcat as we are implementing asynchronous requests.  What can I do
>>>>> here?
>>>>>
>>>>>
>>>>>  Do the same as under httpd (except one thing) : use separate <Host>'s
>>>> within the Tomcat configuration (same as <VirtualHost> under Apache).
>>>> Deploy a separate copy of your webapps within each <Host>'s "appBase".
In
>>>> one <Host>, you protect them via Basic Auth, in the other <Host>
you do
>>>> not.
>>>>
>>>> Under Tomcat, it is not recommended to use the same "appBase" (roughly
>>>> the
>>>> same
>>>> as Apache's "DocumentRoot") for two separate <Host>'s, because this
>>>> creates problems of double deployment etc.  So use two separate sets of
>>>> webapps.  They are still the same webapp, just deployed twice, in
>>>> different
>>>> locations.  Is that a problem for you ?
>>>>
>>>> Roughly (check the proper syntax on tomcat.apache.org) :
>>>>
>>>> server.xml :
>>>>
>>>> ....
>>>>
>>>>   <Engine ...>
>>>>
>>>>     <Host name="host1.company.com" appBase="/some/dir/number1" ..>
>>>>        ...
>>>>     </Host>
>>>>
>>>>     <Host name="host2.company.com" appBase="/some/dir/number2" ..>
>>>>        ...
>>>>     </Host>
>>>>
>>>> ...
>>>>
>>>> /some/dir/number1
>>>>     |- ROOT/
>>>>     |- webapp1
>>>>     |- webapp2
>>>>
>>>> /some/dir/number2
>>>>     |- ROOT/
>>>>     |- webapp1
>>>>     |- webapp2
>>>>
>>>> the 2 "webapp1" are the same (same code, same files,..) (*)
>>>> the 2 "webapp2" are the same
>>>>
>>>> (*) actually, almost the same, since their WEB-INF/web.xml will be
>>>> different : one has to be accessed via HTTPS and use Basic Auth, the
>>>> other
>>>> one not.
>>>>
>>>>
>>>>  Andrew Winter wrote:
>>> Thanks. A lot of file IO goes on with this app. There are a couple of
>> files
>>> in particular that are held open for the life of the app and written to
>>> sporadically. I am thinking that having the same code as two web apps
>> would
>>> lead to those files getting clobbered. Is there a way to make the 'same
>>> appbase with 2 hosts' version work?
>>> On Feb 19, 2013 5:57 PM, "André Warnier" <aw@ice-sa.com> wrote:
>> Well, at first I'd say no.  Even if you were to point both appBase's at
>> the same disk location (and turn off "auto-deploy" !), you would still
>> logically have different "instances" of the webapp running at the same time
>> (one for each host, at least).
>>
>> There are certainly other ways to achieve what you want to do, but I am
>> getting a bit out of my depth here, so be careful of what I'm saying next,
>> and maybe wait for other more qualified people's comments.
>>
>> One way that I could imagine would be to have a single <Host> with an
>> alias, and wrap your webapp inside of a "servlet filter", which would check
>> the host/port that the request came in from. If it came in through the
>> HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet
>> IP address), the filter would allow the request to proceed only if it is
>> authenticated, and otherwise redirect it to a login page e.g.
>> Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow
>> such a thing.  It's a bit like the workhorse for things like that.
>> Otherwise you'd have to write your own (or get it written).
>> As a servlet-filter based solution, that would not require any
>> modification to your webapp.  It would not even know that it is being
>> "wrapped" that way.
>> There are certainly people on this list who would be available for a
>> little job like that.
>> (Not me though).
>>
>>
>>
>>
>>
> Okay, I have this resolved, now.  I went with the FORM authentication
> method and created a servlet that will create a login screen on an
> isSecure() connection. For standard HTTP requests I pass over a self
> submitting form with the credentials included.  This will work for the
> human interfaces and I will just have to deal with any programmatic
> access problems as I find them.
> 
You could probably just "force" an authenticated user into Tomcat (userPrincipal and that

kind of thing) when the connection is internal. That would also probably solve your 
programmatic access case.



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


Mime
View raw message