It is still unclear to me whether there is a security issue with using the existing Kerberos/SPNEGO implementation. Sorry if I am missing a clear message here.
On Sat, Nov 27, 2021 at 5:02 AM Oleg Kalnichevski <ol...@apache.org> wrote: > On Fri, 2021-11-26 at 18:39 +0100, Michael Osipov wrote: > > Am 2021-11-23 um 20:14 schrieb Oleg Kalnichevski: > > > Folks > > > > > > Here's my proposal > > > > > > HttpClient 5.2: > > > > > > * Announce the plan to deprecate and eventually remove NTLM support > > > and experimental SPNEGO / Kerberos support > > > > > > * Ask downstream projects to get in touch with us. Invite > > > interested > > > parties to participate in Kerberos support improvements > > > > OK for me. > > > > > HttpClient 5.3: > > > > > > * Make NTLM / SPNEGO / Kerberos disabled by default requiring an > > > explicit opt-in from the user. Mark respective implementations > > > deprecated. > > > > Also OK for me also. I have explicitly disabled SPNEGO for Wagon > > some > > time ago. It simply did not make any sense. > > > > > * Remove stateful connection support > > ^^^^^^^^^^^^^^^^^^^^^^ > > This contradicts the option still to explicitly enable to > > providers. > > Did you mistype? > > > > Hi Michael > > > What I propose is that the support for connection state tracking be > removed in 5.3. It is an extra security mechanism presently used by > NTLM only. It adds a lot of otherwise unnecessary complexity to the > connection pooling logic and the APIs. I would like to get rid of it > sooner. > > > > > > * Invite interested parties to participate in Kerberos support > > > improvements > > > > > > > > > HttpClient 6.0: > > > > > > * Remove NTLM support > > > > > > * Remove SPNEGO / Kerberos support if still broken > > > > Can you answer my previous request? > > > What is important to know for you when you want to remove code: The > > > security context loop is always client initiated and required to be > > > completed by a token sent from the server with the response unless > > > it > > > is 401/407. So the HttpClient needs to store the context somewhere > > > until it receives the response, completes security context and > > > frees > > > the security context. This is on a per-request basis. If the > > > context > > > is not completed with the response then the authentication should > > > not > > > be trusted, either an exception should be through or a > > > warning/error > > > must be logged. > > > > Will this still be possible for SPNEGO to be implemented properly > > after > > the remove of stateful connection support? > > Of course. There will be no changes to the Auth APIs. It will always be > possible to add NTLM and Kerberos as extra authentication schemes if > desired. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
