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
The requirement was to offer the application's SOAP API at /myapp/API
with basic-auth for one single user.
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.
The catch: basic-auth works but there seems to be no way we can restrict
that channel to a single user. 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.
(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.
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.
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).
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.
Again, thanks for the effort to understand our setup and requirements. I
do appreciate that.
Cheers,
Marcel
--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
