tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: ISAPI log question regarding authentication
Date Sat, 12 Jun 2010 11:23:28 GMT
André Warnier wrote:
> Rainer Jung wrote:
>> On 11.06.2010 23:21, Savoy, Melinda wrote:
>>> I am working in my local Eclipse development environment on a Windows 
>>> XP box.  (As stated in a previous post, I was able to get 
>>> authentication working in the Windows 2003 environment after talking 
>>> to a MS IIS engineer)
>>>
>>> I just got off of a phone call with another IIS engineer at Microsoft 
>>> regarding the authentication issue again that I am getting Windows XP 
>>> and we spotted something interesting in the ISAPI log and wanted to 
>>> run it by you guys.
>>>
>>> I've now setup my IIS and browser in Windows XP to FORCE NTLM 
>>> authentication and I am getting in the request, per the ISAPI log, 
>>> the credentials that it passes from IIS to Tomcat.
>>>
>>> What is interesting is that it would appear that from the ISAPI log 
>>> that the AJP is returning a 401 code to the browser and therefore 
>>> executing a Windows Login prompt. Please see bolded/red type below.
>>>

This kind of "graphic highlighting" does not usually work on mailing 
lists, which tend to be "pure text".  If you want to highlight 
something, it is better to insert some blank lines and a comment.

>>> Below is a copy of the entries in my ISAPI log and wanted to get any 
>>> input on WHY it would appear that the redirector is returning a 401 
>>> status back to my IE or Firefox browser(?):
>>
>> Because it receives a 401 response form your web application in Tomcat 
>> and forwards the response as is to the client. So why is your web 
>> application sending a 401?
>>
> By "application", understand the complete webapp stack, including any 
> servlet filters which may be configured there.
> 
> A 401 is not an error.  It is the normal response of the server, in the 
> NTLM protocol, when trying to access a protected resource.
> My guess in this case and at this point, is that it is the "legacy 
> filter" (jCIFS-based) which sits on top of the webapp, and which does 
> not check if the request is already authenticated, but returns a 401 
> right away.  Is that a possibility ?
> 
As an addendum, here is a link to a document which explains the NTLM 
authentication handshake :
http://www.innovation.ch/personal/ronald/ntlm.html
The "NTLM Handshake" section at the beginning summarises what must 
happen.  As you can see, there are 2 consecutive server responses 
containing a 401 "HTTP status" (not an error per se, they are a normal 
part of the protocol).

However, if I follow correctly, in your case, this handshake has already 
taken place once before, between the browser and IIS.  Then IIS is 
satisfied, and forwards the request to Tomcat, via mod_jk, including a 
user-id.

If there is a further NTLM authentication layer at the Tomcat level, it 
should recognise that the request is already authenticated, and not 
start yet another handshake.  But apparently it doesn't, and does start 
another NTLM handshake sequence (with the first 401 response of the 
sequence).
That probably confuses the browser, because it has already gone through 
the sequence, and is already sending an "Authorization:" header with its 
request. And that is probably why the browser now pops up its "Basic 
authentication" login dialog.
Basically what the browser is thinking is : "oh, my NTLM authentication 
doesn't work ! Let's try a Basic authentication then."

Just another note : mod_jk (or the isapi_redirector) knows *nothing* of 
NTLM, nor of any authentication protocols.  It just passes information 
back and forth between IIS (or Apache) and Tomcat.  It does not add or 
subtract any HTTP headers, and does not modify the request nor the 
response content.
The only thing it does in terms of authentication, is that if the 
webserver has a user-id for a request, it forwards this user-id from the 
webserver to Tomcat.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message