You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Istvan Toth (Jira)" <ji...@apache.org> on 2025/10/21 15:15:00 UTC
[jira] [Comment Edited] (HTTPCLIENT-2402) Handle SecurityManager removal
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18031369#comment-18031369 ]
Istvan Toth edited comment on HTTPCLIENT-2402 at 10/21/25 3:14 PM:
-------------------------------------------------------------------
bq. I am fine with SPNEGO working properly with the classic transport only as the first step. We can look at supporting it with the async transport later.
That is not the case. SPNEGO does work fine with the Async transport, you just need to extract the GSSAPI crendentials and add them in an explicitly with a credentials provider.
The problem only manifests when don't specify explicit credentials, and GSSAPI falls back to retrieving it from the JAAS context i.e. when we pass null credentials here :
https://github.com/stoty/httpcomponents-client/blob/068cd9a63ada07619811a6d78ace4cebc91591f7/httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/gss/GssSchemeBase.java#L322
bq. We need to remove all references to SecurityManager from our code base first.
-We need SecurityManager for testing SPNEGO on JDK 1.8-17 . The replacement Subject.callAs() API is only added in JDK 18.
SecurityManager is only referred in httpclient-tests so it does not affect the client JARs.
SecurityUtils is handling the shims depending on the JVM version.
If you still want to remove it, I guess we could access it via reflection, like we do with other classes in SecurityUtils.-
bq. There is a simple rule: Security contexts are NOT thread safe and shall not be reused between threads. One thread/worker equals one security context. This is what happens if you do: https://github.com/ezhov-evgeny/webdav-client-python-3/issues/93
You are referring to GSSContext, but I was referring to implicit JAAS security context, which stores the current Subject set by Subject.doAs() Subject.callAs() in a thread local or equivalent structure.
While in the async case I think that GSSContext CAN be accessedd from different threads, I believe that the the upper layers already take care of the synchronization, and won't access the AuthScheme object concurrently.
was (Author: stoty):
bq. I am fine with SPNEGO working properly with the classic transport only as the first step. We can look at supporting it with the async transport later.
That is not the case. SPNEGO does work fine with the Async transport, you just need to extract the GSSAPI crendentials and add them in an explicitly with a credentials provider.
The problem only manifests when don't specify explicit credentials, and GSSAPI falls back to retrieving it from the JAAS context i.e. when we pass null credentials here :
https://github.com/stoty/httpcomponents-client/blob/068cd9a63ada07619811a6d78ace4cebc91591f7/httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/gss/GssSchemeBase.java#L322
bq. We need to remove all references to SecurityManager from our code base first.
We need SecurityManager for testing SPNEGO on JDK 1.8-17 . The replacement Subject.callAs() API is only added in JDK 18.
SecurityManager is only referred in httpclient-tests so it does not affect the client JARs.
SecurityUtils is handling the shims depending on the JVM version.
If you still want to remove it, I guess we could access it via reflection, like we do with other classes in SecurityUtils.
bq. There is a simple rule: Security contexts are NOT thread safe and shall not be reused between threads. One thread/worker equals one security context. This is what happens if you do: https://github.com/ezhov-evgeny/webdav-client-python-3/issues/93
You are referring to GSSContext, but I was referring to implicit JAAS security context, which stores the current Subject set by Subject.doAs() Subject.callAs() in a thread local or equivalent structure.
While in the async case I think that GSSContext CAN be accessedd from different threads, I believe that the the upper layers already take care of the synchronization, and won't access the AuthScheme object concurrently.
> Handle SecurityManager removal
> ------------------------------
>
> Key: HTTPCLIENT-2402
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2402
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Reporter: Istvan Toth
> Priority: Major
>
> There are two aspect to these changes:
> - replacing Subject.doAs() with Subject.callAs()
> - handling the changed thread semantics, where the Current Subject is nonger propagated to new Threads.
> Httpclient doesn't currently use the disabled methods.
> They are used in HTTPCLIENT-2358, which already includes the SecurityUtils to map the doAs/CallAs function based on the JVM version.
> The Subject propagation issue breaks SPNEGO authentication for the Async client, as the Subject is no longer propagated to the executor threads for the Async operations.
> There is no current test for that, I will add new tests to HTTPCLIENT-2358 to cover this case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org