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
