[jcifs] NTLM HTTP authentication

[Michael B. Allen]

On Thu, 29 Aug 2002 06:20:23 -0400
"Glass, Eric" <eric.glass at capitalone.com> wrote:

> Attached are some minor changes -- this adds a "jcifs.http.useBasic"
> initparameter which determines whether to enable basic authentication.  I
> currently use IIS with both NTLM and Basic enabled, over HTTPS.  That is
> basically what I am trying to duplicate/replace here; IE clients get the
> nice single-sign-on functionality, but the non-NTLM-capable clients can
> still authenticate.

Let's  say  for  a  second  that  you  were  not using NTLM at all but just
Authentication: Basic instead. If you needed to secure that login would you
add  HTTPS  independantly?  Are  the two configurations (meaning Filter and
mapping  deployment  descriptors) separate? How does your implementation of
Authentication:  Basic  differ  from the standard authentcication setup for
whatever  container  if  you  factor  out  the  NTLM  part?  If they're not
different, how can you be sure? 

> As to the issue below -- I am not sure if doFilter can be guaranteed
> synchronized in the same manner as servlets (via implementation of
> SingleThreadModel).  If I understand correctly (I might not, since I am
> fairly new to NTLM), the issue isn't so much synchronization as it is the
> fact that the protocol requires multiple requests; even if the doFilter
> method was synchronized, it would not be synchronized over multiple
> requests.  If I understand this stuff properly, this is the "normal"
> scenario:

Actually I didn't mean that the actual method itself was "syncronized". You
can  tell  that by just looking at the method signature. I was wondering if
it  was  called  synchronously.  But  in hind sight this is cannot be. That
would be hidiously slow (and unnecessary in most cases). 

> 1. Client accesses the page.
> 2. Server sends the initial WWW-Authenticate message.
> 3. Client repeats the request with the type-1 message.  Server initializes
> the NtlmHttpSession object and stores it in the HttpSession.
> 4. Server sends back an WWW-Authenticate containing the type-2 challenge.
> 5. Client repeats the request with the type-3 message, responding to the
> challenge.  Server retrieves the NtlmHttpSession object from the
> HttpSession, and checks the response (authenticating the user against the
> domain).
> 6. Server sends back the content.
> 
> If I understand your issue, the NetworkExplorer application requires that
> the challenge in step 4 (and the corresponding response) reflect the values
> provided by the server hosting the SMB resource being accessed (which may be
> different from the values initially negotiated).  Is this correct?

Yes, exactly.

My  issue  is that the HttpSession object maintains the password hashes and
general  state  of  the  NTLM  HTTP Authentication process. Even though the
current implementation is minorly flawed in that two or more requests could
be  operating  on that state at the same time, the challenge being sent and
hashes  returned  will be exactly the same so it still works just fine. You
can  see this if you NTLM protect a page with a few graphics -- the browser
will  submit a bunch of requests before the NTLM code can complete one full
NTLM  negotiation. Like I said, this is OK though. It might be wise to just
syncronize  those  encoding/decoding  messages  though. I think we can also
bypass  some of the negotiations after the first. That will speed things up
quite  a bit. The POST requests submit the Authentication: NTLM header with
the type-1-message before form data will be submitted so we have to service
those requests.

The  real  problem  right  now  is with using the negotiated credentials to
access  SMB  resources.  The challenge in step 4 will be different and that
will  cause  the  state of the NtlmHttpSession object to be inconsistent. I
think  I'll  just  have to leave the filter alone and duplicate some of the
NTLM negotiation in an SMB resource accessing base class/servlet that users
can extend (like NetworkExplorer).

Actually the accessing of SMB resources with negotiated credentials creates
a more significant problem. If you use the NTLM HTTP Authentication process
to  negotiate  credentials  for  accessing  an SMB resource you cannot also
negotiate  credentals for validating against the domain controller. I don't
think  it  would work, nor would it be wise, to do NTLM HTTP Authentication
back  to  back  over  the  same  session. We might require that there be an
initial   GET  that  authenticates  thus  freeing  subsequent  requests  to
negotiate  credentials for SMB resources but that's a little clumsy. So the
two  operations  are  mutually  exclusive.  Any  servlet  that accesses SMB
resources  will  have  to  be  configured  NOT to be protected by NTLM HTTP
Authentication.

> -----Original Message-----
> From: Allen, Michael B (RSCH) [mailto:Michael_B_Allen at ml.com]
> Sent: Wednesday, August 28, 2002 11:52 PM
> To: 'jcifs at lists.samba.org'
> Subject: RE: [jcifs] NTLM HTTP authentication
> 
> 
> Does anyone know if doFilter is synchronzed? I'm having some serious issues
> getting
> this to work while accessing SMB resources at the same time with
> NetworkExplorer.
> Even without NetworkExplorer, if doFilter is not syncronized this
> implementation is
> somewhat flawed. If the client sent multiple requests with different
> credentials (not sure
> why it would do that but still) the NtlmHttpSession's state may become
> inconsistent. The
> problem with NetworkExplorer is that to access the SMB resource you have to
> use the
> challenge of the target server in the NTLM HTTP password hash negotiation
> which *does*
> result in different credentials (password hashes) and that's seriously
> mucking up the
> NtlmHttpSession. Geeze, I'm going to have to change this all around.
>  
> **************************************************************************
> The information transmitted herewith is sensitive information intended only
> for use by the individual or entity to which it is addressed. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
>   
> 
> 


-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and more importantly to tasks that have not
yet been conceived.