hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: My introduction and JIRA karma
Date Fri, 14 Nov 2014 18:21:35 GMT
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.

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.

Karl


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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message