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
