[
https://issues.apache.org/jira/browse/HTTPCLIENT-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulrich Colby updated HTTPCLIENT-1873:
-------------------------------------
Description:
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.
_This here is just my opinion, but one of the main reason for using Kerberos in
an enterprise environment is to be able to make use of delegation (double hop
scenarios)._
was:
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. From our tests and my understanding, if a user account is not allowed to
be delegated in a chain, you can still request delegation when creating the
user token, it'll simply not be applied.
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.
_This here is just my opinion, but one of the main reason for using Kerberos in
an enterprise environment is to be able to make use of delegation (double hop
scenarios)._
> 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)
> 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.
> _This here is just my opinion, but 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]
