bq. Unfortunately, HTTPClient does not support direct use of GSSCredential and always assumes implicit credential. Fortunately, there are several ways to solve that problem too.
Is this something you'd be working on? If not, can you point me at an email trail or something describing how to work around this in HttpClient? Thanks! Karl On Fri, Nov 14, 2014 at 1:38 PM, Michael Osipov <micha...@apache.org> wrote: > Am 2014-11-14 um 19:21 schrieb Karl Wright: > >> bq. Obtaining a TGT from within Java with a UPN and a password is a snap >> and can be done with a few line of code. After that, you have a >> GSSCredential and are good to go. No magic here. Maybe I need to >> understand >> your usecase better. >> >> The use case is simple. We have a number of connectors that require >> authentication with Windows - LiveLink, SharePoint, Meridio, FileNet, and >> also some that can be configured to use Windows proxies. We also have >> authorities which need to do the same thing (SharePoint/Native, >> SharePoint/AD, and ActiveDirectory). At the moment, these connections are >> configured by supplying a user name, domain name, and password, and the >> authentication that is done is NTLM -- which is fine, because in many >> cases >> these systems are not configured to be authenticated with Kerberos in any >> case. >> >> However, we do want to fully support Kerberos for those who want to use >> it. In the past, Windows and Linux systems had a specific place where >> tickets were supposed to be stored, and it was not straightforward (or, at >> least, nobody I knew knew how to do it) to populate that repository with >> tickets via Java. Furthermore, since the credentials for a connection >> were >> specific to the connection, having a single ticket store was essentially a >> security hole for this application, so we needed some way to have a local >> ticket store per connection instance. >> > > You can solve you local ticket store by using LoginContext and appropriate > keytabs. Obtain the GSSCredential and go. Every connection instance can act > independently. Regardless of the OS. > > It sounds like GSS goes a long way towards solving that issue, though -- >> as >> long as we can mint tickets, and figure out what the ticket's expiration >> is >> (so that we can reticket as needed). Please let me know if I am missing >> something here. >> > > If you cache the subject issued by the aforementioned LoginContext, you > can always say: GssCredential#getRemainingLifetime or invoke a fresh > LoginContext as you think fit. > > Unfortunately, HTTPClient does not support direct use of GSSCredential and > always assumes implicit credential. Fortunately, there are several ways to > solve that problem too. > > Michael > > >> On Fri, Nov 14, 2014 at 1:06 PM, Michael Osipov <micha...@apache.org> >> wrote: >> >> Am 2014-11-14 um 18:53 schrieb Karl Wright: >>> >>> Hi Michael, >>>> >>>> [...] >>>> >>>> Native code is not something that will work for ManifoldCF because it >>>> must >>>> work the same on linux as well as windows systems. So SSPI cannot be a >>>> replacement for the proprietary NTLM implementation at this time. >>>> >>>> As for Kerberos -- we have people who use it, although with difficulty. >>>> >>>> >>> It shouldn't if done right. >>> >>> What we're really missing is a non-native Java way of obtaining >>> Kerberos >>> >>>> tickets given the appropriate credentials, before it can hope to replace >>>> NTLM. This is because authentication is built into MCF connectors; it >>>> must >>>> be possible to authenticate within the application. >>>> >>>> >>> Obtaining a TGT from within Java with a UPN and a password is a snap and >>> can be done with a few line of code. After that, you have a GSSCredential >>> and are good to go. No magic here. Maybe I need to understand your >>> usecase >>> better. >>> >>> >>> On Fri, Nov 14, 2014 at 12:47 PM, Michael Osipov <micha...@apache.org> >>> >>>> wrote: >>>> >>>> Hi Karl and thanks for the welcome, >>>> >>>>> >>>>> Am 2014-11-14 um 17:44 schrieb Karl Wright: >>>>> >>>>> Welcome onboard! >>>>> >>>>>> >>>>>> I'm the lead with the ManifoldCF project, which is a heavy user of >>>>>> httpclient, and the implementer of the NTLM code that HttpClient >>>>>> currently >>>>>> includes. I'm looking forward to someone keeping up to date with all >>>>>> the >>>>>> various authentication/authorization protocols, since this changes >>>>>> apparently hourly these days. >>>>>> >>>>>> >>>>>> NTLM is a proprietary and tricky beast. Avoid it, if you can, >>>>> migrate to >>>>> Kerberos. >>>>> >>>>> As for auth, I will focus on GSS-API-provided mechs first and those >>>>> from >>>>> SSPI (which supports NTLM natively) then I will take a look at the >>>>> proprietary stuff. >>>>> >>>>> Please keep an eye on my changes and test it once in a while. Give >>>>> feedback if necessary. >>>>> >>>>> >>>>> Michael >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
