Am 2022-09-11 um 19:50 schrieb Oleg Kalnichevski:
On Sun, 2022-09-11 at 19:35 +0200, Michael Osipov wrote:
Am 2022-09-11 um 19:24 schrieb Oleg Kalnichevski:
Folks
There has been surprisingly very few bug reports for the 5.2
series,
which can be either a bad thing or a good thing depending on how
one
looks at it. Anyway, I see no reason to delay 5.2 GA any longer. I
would like to get HC 5.2 GA released by October unless someone
objects.
Agree!
While I am at it here is my personal development plan for the 5.3
series
1. Deprecate and disable NTLM by default. Make it opt-int at your
risk
feature with no support.
2. Deprecate and disable Kerberos by default. Make it opt-int at
your
risk feature with no support.
3. Remove connection state tracking by the connection pool
implementations primarily required for NTLM and Kerberos. Both
schemes
actually violate the general HTTP protocol philosophy of being
state-
less. This would greatly simply the connection management logic and
make it possible for us to use third-party connection pool
implementations such as Commons Pool.
If you remove this, how is the above (1, 2) supposed to work when
enabled?
I am able in the future to properly implement SPNEGO? Which is one
token
from the client and one token back from the server to complete the
security context? I other word, then the GSS context is created and
the
request is sent, the context needs to be stored and retrieved with
the
response to complete it and then dispose it. See also [1]
Of course, one can still still implement state-full authentication
schemes. Nothing is going to change in the protocol handling layer.
However connection pools would no longer track connection state. Proper
user context separation will become the responsibility of the caller,
not of HttpClient. In other works the caller will have to make sure
different users have different connection pools.
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.
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]
