[jcifs] Concurrency with NTLM and servlets (and static method s? )

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Frode E. Moe [SMTP:frode at coretrek.no]
> Sent:	Friday, November 29, 2002 6:45 AM
> To:	jcifs at lists.samba.org
> Subject:	[jcifs] Concurrency with NTLM and servlets (and static methods? )
> 
> Hello!
> 
> I'm considering using jCIFS for doing NTLM authentication
> in my servlets, and I browsed the source briefly.
> 
> I noticed that NtlmServlet calls several static methods in
> SmbSession, such as SmbSession.getChallenge() and SmbSession.logon().
> 
> Apparently getChallenge() propagates further to create a new
> SmbTransport if there are no existing transport matching the connection
> details (remote+local address+port).
> 
> getChallenge() then continues to call negotiate() on the SmbTransport.
> 
> How can this work when several users access the servlet concurrently?
> 
	SmbTransport.getSmbTransport is static synchronized.

> Does an SmbTransport support multiple sessions (with different credentials?)
> 
	Yes.

> Even if that works, is this not a race condition (as I understand,
> a client first requests the challenge and then afterwards sends the password
> hashes in a second request   - disregarding the initial request that only results
> in a HTTP 401 auth required message) ?
> 
> Consider the following scenario: 
> 
>    user1: requests NTLM auth     --->
>                                 <---   server: sends result of getChallenge()
>                                
>    user2: requests NTLM auth     --->
>                                 <---   server: sends result of getChallenge()
>                                 
> Isn't the result of getChallenge() equal both times because the same transport
> is used?
> 
	If the SmbTransport object is the same (and it will be if the server and port passed
	to the static synchonized getSmbTransport method are the same) the challenge
	will be the same.

> and then...
>                                                                       
>    user1: sends passwords hashes --->
>                                 <---   server: ???
> 
> What happens now? Will the first user authenticate OK since trans.negotiate()
> only initiates negotiation once and the second user fail because the session now is logged on?
> 
	The client will "negotiate" with the server. In the case of NTLM HTTP Authentication the "server"
	will be the "domain controller". The challange returned is not specific to the domain/user/password
	type credentials. It is an attribute of the server and thus it is valid for all users authenticating
	against that "domain controller". The domain/user/pass credentials are passed in the SMB_COM_SESSION_SETUP_ANDX request. This will establish a "session" (not to be confused
	with the HTTP session) and there will be one for each user being authenticated.


> Is this a problem, and if it is will the solution be to avoid using all
> the static "helper" methods and maintain one SmbTransport for each user? 
> (I notice it's a thread so it's probably not the best thing to put into a user's
> session).
> 
> 
> Any comments? Am I seeing problems where there are none?
> 
	The NTLM HTTP Authentication code and the jcifs.http package is new and I have not had any
	feedback on highly concurrent usage. However if there is a problem it's not what you have
	described.

>  I don't know enough about
> the internals of the SMB protocol to be sure of all the interactions between
> SmbTransport and SmbSession. 
>     
> 
>   - Frode
>   
>