IIS authentication applies to static but not dynamic requests (servlets, JSPs). Any way to control that?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

IIS authentication applies to static but not dynamic requests (servlets, JSPs). Any way to control that?

charlie arehart
Folks, I have found that if Windows authentication (NTLM) is enabled for a site (or folder) in IIS, such authentication does apply (and is honored) for static files (html, images) but NOT dynamic ones (servlets, JSPs). Is that intended?

To be clear, this is the latest Tomcat 8 (8.5.31) and the latest IIS connector (1.2.43). The uriworkermap.properties is configured to pass all requests to Tomcat (not just JSPs, for instance).

What I’m referring to in particular is this: consider that I set the security properties for one of the JSP example folders:

‪ C:\Program Files\Apache Software Foundation\Tomcat 8.5_Tomcat8_5_31\webapps\examples\jsp\jsp2\el

such that my user had been denied access to that folder.

And let’s say I have configured a site in IIS that listens on port 91 to pass to Tomcat. If I open a new browser window (so as to not have any caching of previous authentication), and I visit this URL:

http://localhost:91/examples/jsp/jsp2/el/basic-arithmetic.html

I get a prompt in the browser to login, and if I login with the user whose permissions had been denied, I get a rejection from IIS. (In my case, I am running my Tomcat test site on port 91 in IIS. It’s not at all pertinent if there is a non-std port or port 80 used.)

The key issue is that if I then visit a JSP or servlet, that IS ALLOWED to run, even though a static file is rejected:

http://localhost:91/examples/jsp/jsp2/el/basic-arithmetic.jsp

I have found nothing in the docs to indicate that this is expected behavior. Can anyone offer any thoughts? I am happy to do any tests or shared any needed diagnostics to help resolve this. Thanks.



/charlie

Reply | Threaded
Open this post in threaded view
|

Re: IIS authentication applies to static but not dynamic requests (servlets, JSPs). Any way to control that?

Igal @ Lucee.org
Charlie,

On 6/11/2018 2:38 PM, charlie arehart wrote:

> Folks, I have found that if Windows authentication (NTLM) is enabled for a site (or folder) in IIS, such authentication does apply (and is honored) for static files (html, images) but NOT dynamic ones (servlets, JSPs). Is that intended?
>
> To be clear, this is the latest Tomcat 8 (8.5.31) and the latest IIS connector (1.2.43). The uriworkermap.properties is configured to pass all requests to Tomcat (not just JSPs, for instance).
>
> What I’m referring to in particular is this: consider that I set the security properties for one of the JSP example folders:
>
> ‪ C:\Program Files\Apache Software Foundation\Tomcat 8.5_Tomcat8_5_31\webapps\examples\jsp\jsp2\el
>
> such that my user had been denied access to that folder.
>
> And let’s say I have configured a site in IIS that listens on port 91 to pass to Tomcat. If I open a new browser window (so as to not have any caching of previous authentication), and I visit this URL:
>
> http://localhost:91/examples/jsp/jsp2/el/basic-arithmetic.html
>
> I get a prompt in the browser to login, and if I login with the user whose permissions had been denied, I get a rejection from IIS. (In my case, I am running my Tomcat test site on port 91 in IIS. It’s not at all pertinent if there is a non-std port or port 80 used.)
>
> The key issue is that if I then visit a JSP or servlet, that IS ALLOWED to run, even though a static file is rejected:
>
> http://localhost:91/examples/jsp/jsp2/el/basic-arithmetic.jsp
>
> I have found nothing in the docs to indicate that this is expected behavior. Can anyone offer any thoughts? I am happy to do any tests or shared any needed diagnostics to help resolve this. Thanks.
Are you sure that the static requests are passed to Tomcat?  Can you
verify that in the response headers?

The logical explanation that I can think of is that IIS still serves the
static content, but passes the JSP stuff to Tomcat without checking the
security permissions.

HTH,

Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>

Reply | Threaded
Open this post in threaded view
|

RE: IIS authentication applies to static but not dynamic requests (servlets, JSPs). Any way to control that?

charlie arehart
> -----Original Message-----
> From: Igal @ Lucee.org <[hidden email]>
> Sent: Monday, June 11, 2018 04:55 PM
> To: [hidden email]
> Subject: Re: IIS authentication applies to static but not dynamic requests (servlets, JSPs). Any way to control that?
>
> Charlie,
>
> Are you sure that the static requests are passed to Tomcat?  Can you verify that in the response headers?
>
> The logical explanation that I can think of is that IIS still serves the static content, but passes the JSP stuff to Tomcat without checking the security permissions.
>
> HTH,
>
> Igal Sapir

Thanks, Igal. No, I agree the static files are NOT passed to Tomcat. I wasn't saying that they were. :-) I was implying rather that they do NOT go to Tomcat, and are NOT processed by the Tomcat connector/ISAPI Filter (because they are not in the uriworkermap.properties list of processed URLs).

This was to confirm that they WERE therefore being handled CORRECTLY by IIS, in that a user trying to run the request who did NOT have access to the files (per Windows on the server) would find the request rejected (per the Windows Authentication feature in IIS).

The problem is that jsps and servlets, which ARE passed to Tomcat by the connector (are in the uriworkermap.properties mappings) are NOT being properly rejected by IIS (or the connector, whichever should have control).

Now, I should add that I had in mind at one time a test to change the order of the modules in IIS, to put the ISAPIFilterModule below the WindowsAuthentication and FileAuthorization module, to see if that would "help'. But really, that should not be needed (even if it would help). Users of Tomcat (who want to implement web server file security like this) shouldn't (I'd think) have to know of such a low-level tweak. I would think that the connector (the Tomcat isapifilter.dll) could/should implement such a security for the user. I suppose someone may quibble with that.

I had also meant to test things out in pure asp.net, to see if an aspx page got honored this way (was protected by Windows Auth and file security, like a static file). I forgot to do these before writing. (Someone wanting me to get this to the Tomcat folks for attention pressed me about it, and I forgot these were 2 things I wanted to check before writing in.)

But perhaps someone familiar with all this may have a thought based simply on what has been shared so far.

/charlie


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: IIS authentication applies to static but not dynamic requests (servlets, JSPs). Any way to control that?

André Warnier (tomcat)
On 12.06.2018 02:57, charlie arehart wrote:

>> -----Original Message-----
>> From: Igal @ Lucee.org <[hidden email]>
>> Sent: Monday, June 11, 2018 04:55 PM
>> To: [hidden email]
>> Subject: Re: IIS authentication applies to static but not dynamic requests (servlets, JSPs). Any way to control that?
>>
>> Charlie,
>>
>> Are you sure that the static requests are passed to Tomcat?  Can you verify that in the response headers?
>>
>> The logical explanation that I can think of is that IIS still serves the static content, but passes the JSP stuff to Tomcat without checking the security permissions.
>>
>> HTH,
>>
>> Igal Sapir
>
> Thanks, Igal. No, I agree the static files are NOT passed to Tomcat. I wasn't saying that they were. :-) I was implying rather that they do NOT go to Tomcat, and are NOT processed by the Tomcat connector/ISAPI Filter (because they are not in the uriworkermap.properties list of processed URLs).
>
> This was to confirm that they WERE therefore being handled CORRECTLY by IIS, in that a user trying to run the request who did NOT have access to the files (per Windows on the server) would find the request rejected (per the Windows Authentication feature in IIS).
>
> The problem is that jsps and servlets, which ARE passed to Tomcat by the connector (are in the uriworkermap.properties mappings) are NOT being properly rejected by IIS (or the connector, whichever should have control).
>
> Now, I should add that I had in mind at one time a test to change the order of the modules in IIS, to put the ISAPIFilterModule below the WindowsAuthentication and FileAuthorization module, to see if that would "help'.

Yes, that is probably what you should do. (This being said by a non-IIS specialist).

But really, that should not be needed (even if it would help). Users of Tomcat (who want
to implement web server file security like this) shouldn't (I'd think) have to know of
such a low-level tweak.

You are not really talking about "users of Tomcat" here.  You are talking about a fairly
shophisticated setup with a front-end reverse proxy webserver (which in addition takes
care of user authentication/authorization), and a back-end Tomcat.  That's indeed beyond a
mere "Tomcat user"'s area of competence, and more of a sysadmin's area.  And so it is for
most user authentication scenarios in a www context.

  I would think that the connector (the Tomcat isapifilter.dll) could/should implement
such a security for the user.

Why should it ?
Think of it this way : for the front-end webserver, the isapi module is just "an
application", which processes certain URLs, and generates a response.
Just like the other "application" which returns the local static pages served by IIS, in
response to another kind of URL.
In other words, as far as IIS is concerned, it doesn't even /know/ that in order to
generate those response pages, isapi communicates with some back-end server.
The standard builtin IIS application which returns static pages, also does not handle
authentication/authorization, and it relies on the same built-in WindowsAuthentication and
FileAuthorization which you mention above, to take care of that.
Same thing for isapi (and any other application or "proxy module").

It would complicate things a whole lot if the isapi module would need to take care of the
AAA part. It would need its own duplicate logic to handle that, its own corresponding
setup parameters etc. And it would need this not only for "Windows Authentication", but
for each different kind of authentication one may want to apply inside of IIS (think
Kerberos, SiteMinder, OpenID, SAML, just to name a few).

  I suppose someone may quibble with that.
>

Yeah, see above.


> I had also meant to test things out in pure asp.net, to see if an aspx page got honored this way (was protected by Windows Auth and file security, like a static file). I forgot to do these before writing. (Someone wanting me to get this to the Tomcat folks for attention pressed me about it, and I forgot these were 2 things I wanted to check before writing in.)
>
> But perhaps someone familiar with all this may have a thought based simply on what has been shared so far.
>

As an additional note :
if you do NOT want the front-end IIS webserver to take care of the user authentication for
Tomcat, you can do that too : just do not authenticate these URLs at the IIS level (leave
them "public", as they are now), and implement the Windows authentication inside of
Tomcat, using the SPNEGO module.
But I suggest that you don't, because it is much easier to let IIS do that, and just pass
on the authenticated user-id to Tomcat, through isapi.


> /charlie
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]