chris derham wrote:
Does that mean that Tomcat treats WIA similar to HTTP BASIC (or maybe
DIGEST) unless you've approved a particular domain/host? That's
interesting. Can you just enter anything you'd like? For instance, can
I authenticate to a server that is expecting WIA from a Linux
workstation just by entering my domain credentials into the dialog?
That certainly sounds nice: the Microsoft Windows crowd doesn't have
to authenticate (explicitly, that is... their credentials are that
they are currently logged-into a machine on the network) but everyone
else can also get in.
If tomcat is setup to work with SPNEGO authentication, then when a new
session requires authentication, the server asks the client for a
kerberos token. Under IE this will be passed silently. Under FF if you
have configured the "network.automatic-ntlm-auth.trusted-uris" to the
url of the server, this will be passed silently. If you setup your
*nix machines to login to active directory they will have a kerberos
token. If you also make the FF setting change, they to will then be
able to silently login by sending through the kerberos token.
I think as you configure the server, you can specify what to do it
SPNEGO fails. I guess one option would be to fail back to http basic.
If you didn't want to get the *nix machines to login to active
directory, then I guess that would be a way to go. Guess that it all
depends on the security requirements
I believe that you both are close to the correct understanding, but that it helps to
clearly distinguish the various parts of the process, and be very clear about the
terminology (which unfortunately is quite confusing, because many people are using terms
like SPNEGO, GSSAPI, "Active Directory authentication", NTLM, "Windows Integrated
Authentication" etc. all over the place without .. really knowing precisely what they are
talking about).
The first few paragraphs here : http://en.wikipedia.org/wiki/SPNEGO
explain what SPNEGO is, and that SPNEGO in itself is not an authentication mechanism. It
is kind of the "preliminary" layer which allow a browser and a server to negociate which
real authentication mechanism they both support and are going to use in the real
authentication which happens next.
And what happens next can be based on /either/ Kerberos or NTLM (or Basic for that
matter), which are different mechanisms.
I know little about Kerberos, but in the context of workstations belonging to a Windows
Domain environment, running web-based applications and desiring to use a Windows-based
form of authentication and SSO for these web-based applications, most organisations which
I have come in contact with until now (including some large multinational ones) do not use
Kerberos as an authentication mechanism; most of them still use NTLM (v2 nowadays).
In summary and approximately, this is how WIA/NTLM works :
- the browser picks up the user-id which the user used to login onto his Windows
workstation when he started Windows
- the browser transmits this user-id to the webserver it is communicating with, in some
form (it actually takes several coded message exchanges for that)
- the webserver verifies this user-id with a back-end Windows Domain Controller
- the Windows Domain Controller in turn uses a back-end to check this user-id (this
back-end being generally an Active Directory server)
- if all of the above works as it should, the webserver accepts this user-id, and makes it
available to the web applications that run on this webserver on behalf of that browser,
for as long as this browser-server connection persists.
(and if a new connection is established, the cycle is repeated)
Now as long as the workstation runs Windows, the browser is IE, the webserver is IIS, both
the workstation and the webserver are in the same "intranet", the IIS webserver has access
to a Windows Domain Controller, the user-id is valid etc.. then all of this happens
automatically behind the scenes and without the user noticing anything.
And if any of these conditions is not true, then you will need to put together alternative
pieces of the puzzle to make "Windows Integrated Authentication" work.
The good news is that in most cases these pieces exist.
The bad news is that you really need to know where to find the needed pieces, how to set
them up, and to know that sometimes the behaviour is a bit different from the basic one above.
(Such as the fact that FF by default displays a dialog, where IE does not; and that this
FF dialog looks just like a Basic Authentication dialog, but it isn't. The authentication
taking place is still NTLM, not Basic; but the popup looks the same).
(And just to make things a bit more confusing : in about 50% of the cases that I have come
across - either as a conscious decision or as an oversight of the domain admins, if NTLM
fails then Basic authentication will take place, both in IE and in FF, and provided the
user enters the correct user-id and password, the webserver will accept it; and the popup
dialog looks the same too).
On the browser side, you need one that supports WIA. IE does (of course), and so does FF.
Others, I don't know.
If the browser is IE, it will accept to even try WIA authentication only if the webserver
is either in the same "intranet" or at least marked as a "trusted" server.
(So don't try this over the Internet).
If the OS under which the browser is running is not Windows, then the browser will not be
able to pick up a valid Windows user-id from the OS (of course); so then it will have to
ask one fom the user, via a dialog.
(So that is probably what is going to happen in the case Chris mentioned at the beginning;
but I don't really know, I have never tried).
If the webserver is not IIS (which has the WIA code builtin), then you will need to add to
the webserver a piece that can do WIA authentication. If you are running this webserver on
a Windows machine, then you will find several alternatives for that. If your webserver is
running under another OS (e.g. Linux), then there are less alternatives available.
For example, if your webserver is Tomcat and it is running on a Linux platform, then I am
personally not sure (and I can't really tell from the Tomcat documentation) if the SPNEGO
Valve works or not. But I do know that Jespa (www.ioplex.com) works (and you can try it
for free); and Jespa also works if Tomcat runs under Windows.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
