Am 2021-11-20 um 17:41 schrieb Oleg Kalnichevski:
Folks
Presently NTLM & SPNEGO are stated as supported authentication schemes,
by the project which is, quite frankly, not the case. There are partial
implementations in various state of decay contributed some while ago by
contributors long gone with no one on the project both capable and
willing to maintain that code and deal with user reported issues.
I think we should drop the pretense and start dealing with the problem.
If we cannot adequately support those features we should consider
deprecating and eventually removing them entirely.
As the first step I would like to propose NTLM & SPNEGO be made an opt-
in feature as of version 5.3. Users would have to explicitly enable
NTLM & SPNEGO support to make HttpClient engage in an NTLM or SPNEGO
handshake.
This may encourage people vested in NTLM and SPNEGO come forth and help
support those features.
Also, the deprecation or removal of NTLM would unable us to drop
connection state tracking support and greatly simplify the connection
management APIs.
Let me both comment since I have experience with them and on
contributions in general.
Contributions: I generally, for all ASF projects I maintain, reject
contributions I cannot test or do not have access to the technology to
do so (it must be freely, namely OSS). I have recently deleted 130 000
LoC in Maven SCM for commercial SCMs because none of us is able to test
them.
Now let's get into those two:
NTLM: Although the client part is fully documented these days, this
mechanism is very problematic in many ways. It is connection-bound and
generally not suited for HTTP which is stateless, in fact IIS disabled
it on HTTP/2 for obvious reasons. There is no OSS implementation (at
least I am not aware of) on the server-side (if you put apart innards of
Samba) which gives me the ability to hook into Apache HTTPd or Tomcat,
ideally as an opaque GSS-API or jGSS mechanism and test properly. You
always need a domain controller, ideally Active Directory and a Windows
server with IIS to test this. The server needs to talk to the DC likely
through MS-RPC (DCE-RPC) (part of the protocol). There is no way I am
going to do this. Only SSPI supports this out of the box. Moreover, the
mechanism is deprecated for many years by Microsoft and replaced with
standard Kerberos.
If your company hasn't moved to Kerberos or client certs then something
is seriously wrong with your company.
My verdict: There is no way we can make this right/reliable/correct. If
you check MS-NLMP [1] there are constant updates putting a burden on us.
I support its removal in 6.0.
SPNEGO: This is a pseudo-mechanism negotiating sub-mechanisms (NTLM or
Kerberos). Although a Microsoft invention also, this has an RFC and is
completely open. When I talk about SPNEGO I always mean Kerberos
negotiated, nothing else. Pure Kerberos does *not* exist over HTTP, thus
no need to support it. Kerberos is freely available (for all OSes) and a
KDC can be set up with MIT Kerberos, Heimdal or Samba or GNU/Linux or
FreeBSD to test. I have a test network in VirtualBox which just works.
It is just effort for the implementor to do so, but easier than brain
surgery.
SPNEGO/Kerberos does *not* require any connection binding, I have been
using it for more than 10 years and I have *never* seen more than one
roundtrip, see also [2]. Neither with MIT Kerberos, Microsoft Kerberos
or Java Kerberos.
One of the biggest problems with many OSS approaches I have seen on the
client side: they are crap and logically broken. Namely, they violate
RFC 7546 [3] and don't make things right. Even curl is broken [3]. The
only OSS library I know to be correct is libserf. Many just don't read
the RFCs to make things right, compared to you! Ping Identity is also
broken. I told this to our service support at work, he was pissed off.
6,5 years I ago I have created HTTPCLIENT-1625 to make things right, 4.x
flow was not suitable, in 5.x this was reworked and I believe it will
work, but don't know for sure. Shamely, I haven't had enough free time
to tackle this issue, I am requirements-driven from work after all and
didn't have this one for Java in all those years, clients were in C or C#.
Both the JGSS code and the JNA-based code for SSPI aren't really good.
As soon as a business need arises here at work, I will start working on it.
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.
My verdict: What we have now for SPNEGO/Kerberos should be removed in
6.0, *but not* the technical support to integrate it properly into
HttpClient.
I used it daily on four OSes on client-side and server-side, it just
works with zero headache for the user. In modern C# applications
interactively, or headless in ancient Fortran apps via C. Even fully
automated in GitLab runners for access APIs on Tomcat.
Michael
[1]
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4
[2] https://github.com/gssapi/mod_auth_gssapi/issues/204
[3] https://datatracker.ietf.org/doc/html/rfc7546
[4] https://curl.se/docs/knownbugs.html#curl_never_completes_Negotiate_o
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
