On 12.06.2018 02:57, charlie arehart wrote:
-----Original Message-----
From: Igal @ Lucee.org <i...@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: users-h...@tomcat.apache.org
