Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of marcel@frightanic.com
 designates 82.195.224.42 as permitted sender)
Message-ID: <4F5926C5.7090606@frightanic.com>
Date: Thu, 08 Mar 2012 22:38:13 +0100
From: =?ISO-8859-1?Q?Marcel_St=F6r?= <marcel@frightanic.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: IIS connector, several connectors with different authentication
 to one Tomcat
References: <4F58AE98.2080409@frightanic.com> <4F58B869.7090105@ice-sa.com>
 <4F58BB79.4030700@frightanic.com> <4F58C4BC.7070601@ice-sa.com>
In-Reply-To: <4F58C4BC.7070601@ice-sa.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 08.03.2012 15:39, Andr� Warnier wrote:
> Additional notes in the text below.
>
> Marcel St�r wrote:
>> First, thank you so much for the thorough response.
>>
>> On 08.03.2012 14:47, Andr� Warnier wrote:
>>> Marcel St�r wrote:
>>>> Requirement:
>>>> a) /myapp authenticated against AD for all users with Windows
>>>> authentication
>>>> b) /myapp/API authenticated against AD for /one/ user with basic-auth
>>>>
>>>> The plan was to have two sites in IIS with appropriate authentication
>>>> schemes. They both have a 'jakarata' virtual directory pointing to one
>>>> and the same physical path (DLL etc.).
>>>> Then we wanted to alter the security settings on the directory
>>>> excluding all but one user for requirement b). Since this modifies the
>>>> security settings of the physical folder
>
> This is something I do not understand really. You are talking about a
> "location" /myapp/API in the URL space, which is in effect proxied to
> Tomcat. So there should be no need for a physical disk location for
> "/myapp" or "/myapp/API", nor permissions for it at the directory level.
> Or is this some other quirk of IIS ?

Sorry if I confused you (I have to be careful I don't confuse myself, too).

/myapp is the context root of the application as deployed in Tomcat. 
'jakarta' is the virtual directory in IIS that points to 
c:/iis-tomcat-connector. The connector is configured so that /* is 
mapped to the one and only worker. The :80 IIS site has one permission 
scheme: internal Windows authentication.
-> the application is available at :80 over NTLM/SPNEGO

The requirement was to offer the application's SOAP API at /myapp/API 
with basic-auth for one single user.

First we set up a second IIS site at :81 only offers the basic-auth 
authentication scheme. This site also has a virtual directory 'jakarta' 
that points the the same physical path as the 'jakarta' virtual 
directory in the :80 site.
-> the application is available at :81 over basic-auth
I have no idea whether this is a feasible approach at all since we're 
all pretty knew to IIS and the Tomcat connector.

The catch: basic-auth works but there seems to be no way we can restrict 
that channel to a single user. If you modify the permissions of the 
respective 'jakarta' virtual directory in IIS what you effectively 
modify are the security settings of the physical folder 'jakarta' points 
to. That's why we wondered whether setting up a second physical folder 
with the connector would solve this.

However, it all seems like a terrible quirk and I have a feeling we hit 
a dead end.

> (I have also occasionally worked with IIS for authentication and
> proxying, but I'm no great specialist in it; but I would assume that it
> is possible to define this as some kind of "virtual location" or
> something, without having to create a real directory on the IIS host).
>
> we'd have to install the IIS
>>>> Tomcat connector a second time pointing to the same AJP port (one
>>>> Tomcat instance).
>>>>
>>>> Should this work in general?
>>>> Are there better alternatives to implement the given requirements?
>>>>
>>>
>>> You are not really saying at which level you are doing this
>>> authentication (IIS or Tomcat), but I will assume you do it at the IIS
>>> level, and set tomcatAuthentication="false" in the Tomcat AJP Connector.
>>
>> Correct
>>
>>> The first thing I would like to point out is that your (b) mechanism may
>>> not be applicable in some environments, as it may not be allowed by the
>>> network security policies, and the browsers may not even be /allowed/ to
>>> do Basic authentication. You should maybe check that first with the
>>> network admins.
>>
>> I understand that. We're in a closed environment that we don't control
>> but understand.
>>
>>> My second question would be "why 2 sites ?". Does IIS not allow you to
>>> specify authentication requirements on a per-location base inside the
>>> same "site" ?
>>
>> I don't know (yet) - I wish the customer had allowed us to use Apache
>> httpd.
>
> Do you have any other need for the front-end IIS, other than this
> authentication ?

No, not really.

> Could your client program access the Tomcat host directly ?

Yeah, we might be able to convince our customer that this be the best 
option.

>>> Normally, in decent webservers (like Apache httpd and Tomcat ;-)), the
>>> longest matching path "wins", so for a request pointing to "/myapp/API",
>>> the specification in "/myapp/API" should be applied, and not the one for
>>> "/myapp".
>>> You should not need 2 sites, nor two connectors, for this.
>>
>> That'd be my preference, too.
>>
>>> You have also not really explained why you want to do Basic auth for
>>> "/myapp/API". I suspect that it is because this URL would be accessed by
>>> some client other than a browser, and this client is not able to do NTLM
>>> auth. It may help to confirm this.
>>
>> Correct.
>
> So what is the client exactly, and where is it running (from a
> network/Domain point of view) ? It may matter for the best solution.

There are several SOAP clients implemented in either Java or some .NET 
language. They are deployed in different zones in the customer's 
infrastructure. We need to assume that they don't support the 
NTLM/SPNEGO authentication scheme (-> API must be available through 
basic-auth).

> Also, is this a "one-off" thing, or do you want to re-use this general
> kind of solution for other customer cases ? There are differences for
> example if in some cases, your client may be totally outside the
> customer network.

It's one-off, an entirely custom solution.

> Also, do the URL's have to be respectively "/myapp" and "/myapp/API" (so
> to speak) ?
> Or could the API part be a separate webapp and URL like "/myappAPI" ?
>
> (Just trying to refine the response..)

I'd rather not deploy the same Tomcat web app more than once.

>>> In a spirit of widening your scope of investigation, you may also want
>>> to have a look at having your client access Tomcat's "/myapp/API"
>>> directly (bypassing IIS), and in that case do the AD authentication at
>>> the Tomcat level, using Tomcat's SPNEGO authentication Valve, or Waffle
>>> or Jespa (commercial). Jespa for instance provides ample possibilities
>>> to try NTLM/SPNEGO first, and if it doesn't work fall back to Basic auth
>>> (still with an AD back-end).
>>> This scheme would even work via IIS and AJP, if you tell IIS to not
>>> authenticate for "/myapp/API" and proxy the call to Tomcat anyway,
>>> letting Tomcat do the authentication.
>>
>> We only brought IIS into the game because it felt like the easiest
>> option to get NTLM/SPNEGO done. I'm aware of the alternatives but have
>> never used either of them (in contrast to IIS).
>
> I would suggest if possible to simplify your world and eliminate one (or
> two) possible sources of complications or failures. If all you need IIS
> for is authentication, then doing the authentication directly in Tomcat
> allows you to eliminate IIS configuration, and isapi_redirector also.
> (trade-off: you add the authentication complication in Tomcat; but it's
> still probably easier to have all in one place, less logfiles and hosts
> to watch etc..)
>
> ...
>
> Suggestion : go to http://www.ioplex.com/, download the Jespa product
> (includes the documentation PDF), and have a look. Similar capabilities
> are available, more or less, in the earlier-cited open-source products,
> but I know them less than Jespa.
>
> Jespa install as a "servlet filter", wrapping your webapp. It would
> fulfill the kind of requirements you indicate above (and much more), it
> is not expensive, and you can try the downloaded version for 60 days for
> free.
> It would also allow you to do away with IIS totally, if you do not need
> it for anything else than authentication.
> (disclaimer: I have no financial incentive in Jespa. I just use it and
> am happy with it).

The simpler my world the better...We knew from the beginning what our 
options were and opted for IIS. Yes, we could have chosen Tomcat's 
SPNEGO authentication valve, Waffle or Jespa but we have no experience 
with either of them.
Also, since our app uses Spring security we could use Spring's Kerberos 
plugin. However, until Spring 3.1 there's no (easy) way to configure 
that /myapp should use Kerberos and /myapp/API should use basic-auth. 
I'll have a look at Jespa now.

Again, thanks for the effort to understand our setup and requirements. I 
do appreciate that.

Cheers,
Marcel

-- 
Marcel St�r, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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