[jcifs] jcifs.http.NtlmHttpFilter and POST
Giampaolo at Tomassoni.biz
Thu Aug 21 23:37:28 GMT 2008
> -----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. 184.108.40.206 "NTLM
Connection-oriented Call Flow" point 4 of "MS-NLMP NT LAN Manager (NTLM)
Authentication Protocol Specification
"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
> 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.
> 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.
> Michael B Allen
> PHP Active Directory SPNEGO SSO
More information about the jcifs