Karl, the dicsussion isn't about NTLM, but SPNEGO/Kerberos only.
Am 2021-11-21 um 01:22 schrieb Karl Wright:
This is not a security issue. The implementation of NTLM is just as secure
as the Microsoft implementation. That's not terribly secure but that's
inherent in their design.
Karl
On Sat, Nov 20, 2021 at 7:02 PM larry mccay <lmc...@apache.org> wrote:
This is a concerning statement and I need some additional information to
determine what sort of risk is inherent in the current implementation.
Perhaps we should take those details off list if this is a security issue.
I'll need to determine whether there are any workarounds or usage patterns
that we can use to ensure that we are safe.
Currently we do not preemptively send tokens and we use our own delegation
tokens after the first authentication.
On Sat, Nov 20, 2021 at 2:58 PM Michael Osipov <micha...@apache.org>
wrote:
Am 2021-11-20 um 20:46 schrieb larry mccay:
Hi -
I am the Apache Knox PMC chair and a committer on Hadoop and other
ecosystem projects.
FYI, Apache Knox is indeed dependent on SPNEGO in httpclient.
Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or
proxyuser pattern within Hadoop it requires all proxies that dispatch
requests on behalf of other users to authenticate via Kerberos/SPNEGO.
Knox is not the only proxyuser in the ecosystem and likely not the only
one
that is leveraging HttpClient this way.
It is used within a huge number of Hadoop deployments both on-prem and
in
the cloud and SPNEGO is critical to the security of these deployments.
If this would be critical for security then you would not rely on it. It
does not complete the security context for you. As sad as it sounds.
I am currently in a project at work where I try to get rid of the Ping
Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient
is used, in Spring and JMeter. Maybe this well an opportunity to make it
right, but this will only land in 5.2.x, maybe 5.1.x if the API allows
it.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
