tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: IIS connector, several connectors with different authentication to one Tomcat
Date Thu, 08 Mar 2012 14:39:56 GMT
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 ?
(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 ?
Could your client program access the Tomcat host directly ?

> 
>> 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.

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.

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..)

> 
>> 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).



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


Mime
View raw message