[
https://issues.apache.org/jira/browse/HTTPCLIENT-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189929#comment-16189929
]
Ulrich Colby commented on HTTPCLIENT-1873:
------------------------------------------
Hi Karsten and Oleg,
We do use a KRB5 file, what you say makes sense, however, my tests show
something a little different happening. First, without setting the
java.security.krb5.conf property, it's supposed to use C:/windows/krb5.ini by
default on Windows, or /etc/krb5.conf on Linux. To confirm it's using it, if I
turn on sun.security.krb5.debug=true, place a bad KDC server in the KRB5.ini, I
see the failure to connect to it on the debug logging and finally end up
receiving a 401. Putting a working KDC server makes everything work. The
options "forwardable=true" (for delegation) and "renewable=true" are also
inside the file.
When I use HttpClient 4.5.2 (on a client), this is what I see happen in
Wireshark (making a RESTful call):
1) A TGS-REQ is made, requesting FORWARDABLE, RENEWABLE-OK, I get a ticket back.
2) Then, right afterwards, a second request is made, with flags FORWARDBLE,
FORWARDED, REWABLE-OK, I get a new ticket back.
3) I connect to the server which itself connects to a backend server,
everything works.
When I use HttpClient 4.5.3, same conditions, this is what I see happen:
1) A TGS-REQ is made, requesting FORWADBLE, RENEWABLE-OK, I get a ticket back.
...no second request is made
2) Then it connects to the server which returns an error. The server log shows
that it gets a Principal, but when getDelegCreds (GSSCredential) is called,
NULL is returned and therefore it can't make the call to the backend server (no
delegation creds were forwarded).
I can't find some good hard documentation on GSSContext that definitely
explains whether or not you're supposed to make the requestCredDeleg, so I went
and looked at source code I could find (openjdk) for
sun.security.jgss.GSSContextImpl (that is the GSSManager instanciates). The
variable "reqCredDelegState" is set to "false" by default. It looks like
nothing sets this variable to anything other than false, unless you call
"requestCredDeleg" before "initSecContext" is called (which assigns something
to "mechCtxt"):
public void requestCredDeleg(boolean state) throws GSSException {
if (mechCtxt == null)
reqCredDelegState = state;
}
As the documentation says, however, you may ask for delegation, but depending
on external factors, you may not get it. You then can confirm with
getCredDelegState whether or not you got it or not.
You suggested extending SpnegoScheme. I don't think it'll work for us if the
SpnegoSchemeFactory and then the HttpClientBuilder each call one another in a
chain and specifically create a SpnegoScheme instance. I'm opened to alternate
solutions however, if you believe this is a problem. A System property or
static flag could be used, or a way of making the SPNegoSchemeFactory
instanciate a customizable "GGSSchemeBase" object. What are your thoughts?
> Kerberos delegation no longer working after HTTPCLIENT-1736 patch in version
> 4.5.3
> ----------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1873
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1873
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic), HttpClient (Windows)
> Affects Versions: 4.5.3, 4.5.4
> Environment: Windows,Linux
> Reporter: Ulrich Colby
> Priority: Minor
> Labels: easyfix
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> In version 4.5.3, the following fix got applied to the httpclient library:
> _ [HTTPCLIENT-1736] do not request cred delegation by default when using
> Kerberos auth.
> Contributed by Oleg Kalnichevski <olegk at apache.org>_
> Although it says "by default", when looking at the affected code it's not the
> case (i.e.: there is no way to request if we want it). From our tests and my
> understanding of Kerberos, if a user account is not allowed to be used for
> delegation, then you can still request delegation, but when creating the user
> token, it'll simply not be applied.
> +Affected area+:
> In the class "GSSSchemeBase", in the method "createGSSContext", we need the
> following line added back:
> *gssContext.requestCredDeleg(true);*
> **OR**
> If you insist of leaving it off for a reason I'm not aware of, having a way,
> maybe through a system property, to say that we want it.
> _IMHO, one of the main reason for using Kerberos in an enterprise environment
> is to be able to make use of delegation (double hop scenarios)._
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
