On Mon, 2018-11-12 at 19:31 -0500, Karl Wright wrote: > Hi Michael, > > I did not contribute this work; I merely obliquely helped integrating > it. > If I recall correctly, there was a reasonable case made for it, but I > don't > remember what it wasy. > > Karl > >
Hi Michael For full background: https://github.com/apache/httpcomponents-client/pull/66 CredSSP is marked experimental. We can still remove it. Oleg > On Mon, Nov 12, 2018 at 5:50 PM Michael Osipov <[email protected]> > wrote: > > > Guys, > > > > I just have discovered that CredSSP has been added with (NTLM, > > yuck) > > some time ago. Can someone point me to a valid use case for this > > over > > HTTP? Karl? As far as I understand CredSSP [1] it is simply not > > compatible with/designed for HTTP and duplicates the transport > > encryption. The main purpose is to securely transport the Kerberos > > UPN > > and password of the user to the target server, e.g., for RDP to > > obtain a > > TGT on the remote machine as if someone is physically in front of > > the > > remote machine. > > > > This makes sense if you work on raw sockets, but on HTTP? > > The CredSspScheme also says that it should work with GSS, but I > > believe > > that this is impossible because as soon as yo have the > > GSSCredential, > > you don't have access to the UPN and password, you have the TGT > > only. > > Neither with JGSS, Heimdal, nor MIT Kerberos unless you acquire > > them > > again, like the RDP login dialog does. > > > > So again, what does it better than HTTPS + SPNEGO with credential > > delegation or contraint delegation also given that this works on > > the > > Windows backend only?! > > > > Michael > > > > [1] https://msdn.microsoft.com/en-us/library/cc226794.aspx > > > > ----------------------------------------------------------------- > > ---- > > 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]
