Sandor Molnar created KNOX-3483:
-----------------------------------
Summary: HadoopAuthPostFilter does not capture the caller JWT as
an AuthTokenCredential, so KNOX-AUTH-SERVICE token forwarding no-ops on
HadoopAuth topologies
Key: KNOX-3483
URL: https://issues.apache.org/jira/browse/KNOX-3483
Project: Apache Knox
Issue Type: Bug
Components: Server
Affects Versions: 3.1.0
Reporter: Sandor Molnar
Assignee: Sandeep More
Fix For: 3.1.0
Follow-up to the token-forwarding work merged in [PR
#1425|https://github.com/apache/knox/pull/1425].
That change taught {{JWTFederationFilter.doFilter()}} to capture the caller's
JWT as an {{AuthTokenCredential}} in the Subject's private credentials, which
{{AbstractAuthResource}} later reads via {{SubjectUtils.getAuthToken() }}to
emit the {{X-Knox-Auth-Token}} header.
However, {{HadoopAuthPostFilter.doFilter()}}
({{{}gateway-provider-security-hadoopauth/.../HadoopAuthPostFilter.java:91{}}})
was not updated. It still calls the single-arg
j{{{}wtFilter.createSubjectFromToken(token){}}}, which resolves to
{{createSubjectFromToken(JWT, null)}} and never adds an
{{{}AuthTokenCredential{}}}.
+Effect:+ On any topology using the {{HadoopAuth}} federation provider with
{{{}support.jwt=true{}}}, no auth-token credential reaches the Subject, so the
{{X-Knox-Auth-Token }}header is silently never emitted - even though the
identical caller receives it on a {{{}JWTProvider{}}}/{{{}SSOCookieProvider{}}}
topology.
+Fix direction:+ update {{HadoopAuthPostFilter.doFilter()}} to use the same
caller-credential capture path {{JWTFederationFilter.doFilter()}} now uses,
rather than the single-arg convenience method.
+Note:+ {{knox-site/docs/config_knoxauth_service.md}} currently attributes this
gap to an inherent "{{{}innermost Subject.doAs wins{}}}" architecture
limitation. That explanation is inaccurate - this is a fixable un-updated call
site - and the doc should be corrected when this ticket is resolved.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
