tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: LDAP on TOMCAT 7.0.30
Date Tue, 29 Jan 2013 23:53:28 GMT
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 :
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 ( works (and you can try it 
for free); and Jespa also works if Tomcat runs under Windows.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message