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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
