On Sun, 2022-09-11 at 20:04 +0200, Michael Osipov wrote > > ...
> Uh, this basically means that NTLM will be impossible with connection > pools. The client *must* maintain the state on the TCP connection > because the peer (acceptor) does this as well. In other words, when > then > type 3 message is send, ist *must* go over the same connection > otherwise > the peer (acceptor) will not have a GSS context which waits for > completion. > Not at all. This has _nothing_ to do with the authentication handshake _at all_. What that means is that HttpClient will no longer be able to ensure that persistent NTLM connections with _the same route_ created by NTLM user 1 cannot not be leased to NTLM user 2. User context management will become the responsibility of the caller. Oleg > For SPNEGO, it will be less of a problem because only one roundtrip > is > required and connection tracking on client side isn't necessary. At > least, I haven't seen more than one roundtrip in the last 10+ years. > If > this could ever happen, the client must fail with an exception > similar I > do on the acceptor side in Tomcat [1]. > > Can you point me to the new (alternative) approach? I'd like to take > a > look in the next couple of weeks to understand the impact. I > personally > care *zero* about NTLM, but SPNEGO (Kerberos), are free, well-defined > (RFC) and available as OSS everywhere with MIT Kerberos, Heimdal and > Samba AD as well. > > Michael > > [1] > https://github.com/michael-o/tomcatspnegoad/blob/d169b860186b9f009f66409a5df20d0ae887441c/src/main/java/net/sf/michaelo/tomcat/authenticator/SpnegoAuthenticator.java#L172-L176 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
