hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: My introduction and JIRA karma
Date Fri, 14 Nov 2014 18:38:29 GMT
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 <michaelo@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 <michaelo@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-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: dev-help@hc.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message