[jcifs] jcifs.http.NtlmHttpFilter and POST

[Giampaolo Tomassoni]

> -----Original Message-----
> From: jcifs-bounces+giampaolo=tomassoni.biz at lists.samba.org
> [mailto:jcifs-bounces+giampaolo=tomassoni.biz at lists.samba.org] On
> Behalf Of Michael B Allen
> Sent: Thursday, August 21, 2008 8:28 PM
> To: Giampaolo Tomassoni
> Cc: jcifs at lists.samba.org
> Subject: Re: [jcifs] jcifs.http.NtlmHttpFilter and POST
> 
> On Thu, Aug 21, 2008 at 7:18 AM, Giampaolo Tomassoni
> <Giampaolo at tomassoni.biz> wrote:
> >> Does anyone know why this might be the case?
> >
> > My really really broad guess.
> >
> > NTLM is a per-channel authentication protocol, not a per-request one.
> 
> You probably shouldn't be making really really broad guesses :->

What about brainstorming? :)


> NTLMSSP over HTTP is per-request. At least it's supposed to be.

Michael, I can't find were specs explicitly state NTLMSSP shall be
per-request. Instead, as I pointed out in the message
<000d01c89a83$67b0c350$371249f0$@biz>, par. 1.3.1.1 "NTLM
Connection-oriented Call Flow" point 4 of "MS-NLMP NT LAN Manager (NTLM)
Authentication Protocol Specification
(http://msdn.microsoft.com/en-us/library/cc207850.aspx) states:

"If the challenge and the response prove that the client knows the user's
password, the authentication succeeds and the application protocol continues
according to its specification..."

Now, since HTTP/1.1 supports Persistent Connections, to me the "application
protocol" boundary is not around a single request, but instead spans the
whole connection lifetime. Thereby, a single, successful authentication
exchange is sufficient to authenticate the whole channel. Which, by the way,
makes sense to me: there is no easy way to "steal" an open TCP/IP
connection, thereby there is no need to start more authentication exchanges
on the very same channel.


> If you look at IIS, every request is authenticated.

Sorry, no IIS handy. I'll check it out.


> But for performance
> reasons JCIFS caches the result of an authentication in the user's
> session (which also is not tied to channels incedintally).

This is an implementation choice. I suspect IIS doesn't work the same, don't
you agree? 


> If IE does NTLM with a server it will proactively initiate NTLMSSP
> authentication for POST requests (I don't know how IE decides which
> servers it has authenticated with - it's probably based on the
> hostname) as described in the NTLM HTTP Filter documentation.

Right, granted.


> In this
> case, the filter must be enabled to consume such authentications or IE
> will never send the POST data.

Ah, right: I saw that empty POSTs only meant to "trigger" an authentication
process. They always happen to be in a new connection, besides... ;)


> The problem is that the OP's config is screwed up and the filter isn't
> being engaged properly for the POST targets.

Ok. Then, I was wrong in my far guessing.

This is also because I forgot that empty POSTs (from authenticated pages? to
protected servers?) always happen to be carried by brand-new connections,
then Robert's POST problem couldn't be related to the keep-alive one...

I should get a Tomtom when I go that far...

Thank you, Mike.

Ok, Robert: Mike is right (in your case :) ) : it can't be the keep-alive
problem troubling your app.


> Mike
> 
> --
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/