Hi Michael,
I understand how the workaround would work if I should implement it that
way, but I'm less certain about your proposed changes to HttpClient. For
example, for proxies and NTLM this is what I currently do:
CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
credentialsProvider.setCredentials(
new AuthScope(proxyHost, proxyPort),
new NTCredentials(proxyAuthUsername, proxyAuthPassword, currentHost,
proxyAuthDomain));
Are you proposing that there will be a new KerberosCredential (or the
equivalent)? e.g.:
GSSCredential myTicket = ...;
...
credentialsProvider.setCredentials(
new AuthScope(proxyHost, proxyPort),
new KerberosCredential(myTicket));
If this is what you are planning to implement, I may well wait for that
work to be completed, since I think it would save me an extensive amount of
work.
Thanks,
Karl
On Fri, Nov 14, 2014 at 2:36 PM, Michael Osipov <micha...@apache.org> wrote:
> Am 2014-11-14 um 20:00 schrieb Karl Wright:
>
>> 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?
>>
>
> Yes, the default will remain implicit GSSCredential, alternative will be
> to pass the GSSCrdential which can be obtained by LoginContext or even be a
> delegated credential from an HTTP request.
>
> If not, can you point me at an email trail or something describing how to
>> work around this in HttpClient?
>>
>
> You can try the following while the solution above is not available yet:
>
> LoginContext lc = new LoginContext("login-entry-name");
> lc.login();
>
> YourReturnObject instance;
>
> instance = Subject.doAs(lc.getSubject(),
> new PrivilegedExceptionAction<YourReturnObject>() {
>
> public YourReturnObject run() throws SomeException {
>
> // Perform HTTPClient operations
>
> return yourReturnObjectInstance;
> }
> };
>
> Done. Have a look at these sources [1], [2] I wrote, it does exactly what
> you need. Adapt that pattern.
>
> JGSS will by default use the GSSCredential scoped in the subject provided
> by lc.
>
> [1] http://dirctxsrc.sourceforge.net/xref/net/sf/michaelo/
> dirctxsrc/DirContextSource.html#L510
> [2] http://tomcatspnegoad.sourceforge.net/xref/net/sf/
> michaelo/tomcat/authenticator/CurrentWindowsIdentityAuthenticator.html#L93
>
>
> Michael
>
> 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
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>
