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

[tomcat]

On 12.06.2018 02:57, charlie arehart wrote:

-Original Message-
From: Igal @ Lucee.org 
Sent: Monday, June 11, 2018 04:55 PM
To: users@tomcat.apache.org
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




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

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  
> Sent: Monday, June 11, 2018 04:55 PM
> To: users@tomcat.apache.org
> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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