[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16195153#comment-16195153
 ] 

Ulrich Colby commented on HTTPCLIENT-1873:
------------------------------------------

I understand your poibnt of vue.  If you'll allow though, let me try to 
illustrate just once more why I was leaning a bit more towards a system 
property solution.  If you disagree, then I'll modify the current solution to 
use a nullable Boolean as you suggested.

I see the "SpnegoScheme" class to be closer to the Kerberos world than it's 
higher-level HttpClient class.  In Java, when dealing with Kerberos, most 
options are passed by external files and system properties (i.e.: 
java.security.krb5.conf / java.security.auth.login.config / 
javax.security.auth.useSubjectCredsOnly... etc).

Those type of system properties, as far as I know are seldom set at the O/S 
level as system or user environment variables.  They're either passed directly 
to the JVM with the -D option or directly in code with setProperty.  These 
options are expected to be set before or during the initialization of a program 
and then left alone for the lifespan of the JVM instance.

In this case, you have the choice of doing it outside or programmatically in 
code.

What I can do to keep everyone happy, is a hybrid solution; Have a statically 
settable Boolean in case someone wants to explicitly set it.  Then, only if the 
Boolean isn't set, the System property would then be checked (only once, and 
set the Boolean if it exists).

If you're not convinced, just tell me "nay".

Ulrich

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

Reply via email to