[
https://issues.apache.org/jira/browse/KNOX-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandeep More updated KNOX-3483:
-------------------------------
Description:
This Jira is a followup on KNOX-3478. There are two items
# Extensibility
# Fix a gap
These are discussed below:
*Extensibility*
The feature in KNOX-3478 needs to be more extensible
the intention for the feature is to have, say credential "types" and principal
"types" that we can use getType() on to pull data from security context?
example of such type include Credential (type, value), Principal(type, value)
e.g. Credential("token", "ey......"), Principal("UserPrincipal", "Tom"),
Principal("X500Principal", "Acme") etc.
*Feature Gap*
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.
was:
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.
> 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
> Priority: Major
> Fix For: 3.1.0
>
>
> This Jira is a followup on KNOX-3478. There are two items
> # Extensibility
> # Fix a gap
> These are discussed below:
>
> *Extensibility*
> The feature in KNOX-3478 needs to be more extensible
> the intention for the feature is to have, say credential "types" and
> principal "types" that we can use getType() on to pull data from security
> context? example of such type include Credential (type, value),
> Principal(type, value)
> e.g. Credential("token", "ey......"), Principal("UserPrincipal", "Tom"),
> Principal("X500Principal", "Acme") etc.
>
> *Feature Gap*
> 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)
