tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: IIS connector, several connectors with different authentication to one Tomcat
Date Fri, 09 Mar 2012 00:08:33 GMT
Marcel Stör wrote:
> 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

Ok, got that one.

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

I did kind of miss the "one single user" part before, and focused only on the "basic-auth"


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

It may, but it seems unnecessarily complicated.  It believe (but I am not sure) that it 
should be possible to define a single IIS site, but two different URL mappings inside of 
it, one pointing to the URL "/myapp" and submitted to NTLM/SPNEGO, and the other mapping 
to "/myapp/API" and submitted to Basic-auth.  Somehow.  Unfortunately, at the moment I 
don't have an IIS server handy to try this out.
(Rainer, help !)

> The catch: basic-auth works but there seems to be no way we can restrict 
> that channel to a single user. 

That's the requirement I missed. But it should be possible to make this restriction at the

Tomcat level.  I am also no great specialist at the Tomcat container-AAA level, but it 
seems to me that it should be possible to distinguish, in the web.xml of your application,

between "Authentication" (getting a valid user-id) and "Authorization" (allowing this 
authenticated user-id to run this application, or not).

In other words :
- let the basic-auth at the IIS level authenticate the user anyway (any user, no restriction)
- let isapi_redirector pass this user-id to Tomcat (it does that, by default)
- at the Tomcat level, accept the user-id as passed by IIS/isapi_redirector as the "Tomcat

user-id"  (tomcatAuthentication="false" in the Connector)
- but then, in the application's web.xml, for the URL /myapp/API, allow only "thisuser" to

actually run the application (others would get a "forbidden" response).  It should be 
possible to define an <auth-constraint> to do this, no ?
(Tomcat gurus, help !)

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.

Yes, the 2 sites on two different ports do look kind of a patch on a wooden leg.

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

Ok, keeps it simpler.

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

Understood now, if both things are really part of the same app.

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

Yes, I still think that having all clients access Tomcat directly, eliminating IIS from 
the equation, would lead to a simpler and more robust solution, even taking Jespa into 
Jespa also allows for authorization based on the user's AD group, which may be an 
alternative to your "this user only" option.
If you have any trouble configuring Jespa to do what you want, the ioplex support, in my 
experience, is very responsive. If you send them your original problem as described above,

I am sure that they would tell you right away if it is possible to use Jespa to achieve 
what you want, and how to set this up.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message