[
https://issues.apache.org/jira/browse/IMPALA-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012216#comment-18012216
]
Paul Mayer edited comment on IMPALA-12232 at 8/5/25 7:53 PM:
-------------------------------------------------------------
This issue is currently a blocker for adoption in our context and I would like
to share some considerations which may be worth considering when working on a
fix:
*Our setup*
In our organization, we run Impala on Cloudera on Cloud Virtual Warehouses. We
have "Platform JWT Auth" activated, which allows authenticating with Impala
using Apache Knox tokens (Apache Knox being part of the Cloudera distro). We
have our own corporate IDP from which we import user identities into the
platform. Applications usually use federated identities with our IDP, use OIDC
to get identity tokens and want to authenticate with Impala (acting as a
Resource Server in an OAuth 2.0 sense).
*Considerations*
*1. Multi-Issuer Support*
There may be multiple Cloudera customers like us who want to both keep
authentication with Knox JWT tokens enabled (to not break integrations between
products in the Cloudera on Cloud portfolio) _and_ enable authentication with
tokens from external (here: external to the Cloudera ecosystem, "internal" to
the organization deploying Cloudera on Cloud) token providers.
>From that perspective, I would argue that multi-issuer support may be
>desirable, even if not something that many software projects support out of
>the box. Issuer validation could be combined with multi-issuer support as
>follows:
Option 1:
{code:java}
jwks_url=<url>:<name[s]-of-issuer>;<url>:<name[s]-of-issuer-2>{code}
A token validated with a key from the respective JWKS would then need to match
(one of) the respective issuer name(s), while Impala keeps a mapping between
jwks and issuer names. This could support "*" (following e.g. established
practice for proxy_group configs), to allow _any_ issuer name for a specific
issuer (e.g. if no claim is present).
{_}Alternatively{_}, as Option 2, Impala could stay with just supporting a
single jwks_url or jwks_file_path and Impala admins will need to either
aggregate jwks from multiple issuers or mount an aggregate jwks. Under this
scenario, one or more "allow-listed" issuers could be provided:
{code:java}
enable_jwt_issuer_validation=true
jwt_issuers=<names-of-issuers>{code}
*2. OIDC/OAuth 2.0 - Impala as Resource Server*
Use of OIDC is rather widespread and architectural decisions may need to be
looked at from the perspective of enabling (or making more difficult)
compliance with companion specifications to OIDC/OAuth 2.0. Aggregating
multiple issuers' JWKS is rather not in the spirit of OIDC (where there is a
jwks_url for an authorization server and references to keys for signature
validation are communicated in advance). Generally, audiences need to be
validated per token issuer/authz server, meaning that for audience validation,
it probably also makes sense to support a mapping from issuer name to audiences.
{code:java}
enable_jwt_audience_validation=true
jwt_audiences=<name-of-issuer>:<audiences>;<name-of-issuer>:<audiences>{code}
(here, * could again be supported to allow any audiences, even though then a
decision would need to be taken whether that permits missing audience claims
altogether)
*3. Backwards Compatibility*
Multi-issuer support (under Option 1), could either be enabled by a feature
toggle or supported in a little bit of an ugly way by keeping jwks_url
(supporting just a single url, {_}or{_}{*}{{*}} a format like the one proposed
above). With a feature toggle (e.g. enable_multiple_jwks=true) Impala could
expect jwks_urls with the proposed format. The concrete issuer and audience
validation configuration could be hidden behind feature flags that are false by
default, not breaking existing configurations on upgrade.
*4. Other Aspects*
With multiple issuers, also per-token-issuer configuration for server cert
validation, username claims - and potentially, new: issuer and audience claim
names - may need to be supported.
I'm sure there is more I'm missing, but I would be curious how maintainers here
see native multi-issuer support and how the feature should evolve with respect
to established standards (e.g. OIDC). Depending on feedback, I may be able to
give an implementation a stab (but with strategic direction of the feature
carrying quite a bit of weight in terms of _how_ this could be implemented, I
felt raising some of the points I could think of here made sense.
was (Author: JIRAUSER308675):
This issue is currently a blocker for adoption in our context and I would like
to share some considerations which may be worth considering when working on a
fix:
*Our setup*
In our organization, we run Impala on Cloudera on Cloud Virtual Warehouses. We
have "Platform JWT Auth" activated, which allows authenticating with Impala
using Apache Knox tokens (Apache Knox being part of the Cloudera distro). We
have our own corporate IDP from which we import user identities into the
platform. Applications usually use federated identities with our IDP, use OIDC
to get identity tokens and want to authenticate with Impala (acting as a
Resource Server in an OAuth 2.0 sense).
*Considerations*
{*}{*}{*}1. Multi-Issuer Support{*}
There may be multiple Cloudera customers like us who want to both keep
authentication with Knox JWT tokens enabled (to not break integrations between
products in the Cloudera on Cloud portfolio) _and_ enable authentication with
tokens from external (here: external to the Cloudera ecosystem, "internal" to
the organization deploying Cloudera on Cloud) token providers.
>From that perspective, I would argue that multi-issuer support may be
>desirable, even if not something that many software projects support out of
>the box. Issuer validation could be combined with multi-issuer support as
>follows:
Option 1:
{code:java}
jwks_url=<url>:<name[s]-of-issuer>;<url>:<name[s]-of-issuer-2>{code}
A token validated with a key from the respective JWKS would then need to match
(one of) the respective issuer name(s), while Impala keeps a mapping between
jwks and issuer names. This could support "*" (following e.g. established
practice for proxy_group configs), to allow _any_ issuer name for a specific
issuer (e.g. if no claim is present).
{_}Alternatively{_}, as Option 2, Impala could stay with just supporting a
single jwks_url or jwks_file_path and Impala admins will need to either
aggregate jwks from multiple issuers or mount an aggregate jwks. Under this
scenario, one or more "allow-listed" issuers could be provided:
{code:java}
enable_jwt_issuer_validation=true
jwt_issuers=<names-of-issuers>{code}
*2. OIDC/OAuth 2.0 - Impala as Resource Server*
Use of OIDC is rather widespread and architectural decisions may need to be
looked at from the perspective of enabling (or making more difficult)
compliance with companion specifications to OIDC/OAuth 2.0. Aggregating
multiple issuers' JWKS is rather not in the spirit of OIDC (where there is a
jwks_url for an authorization server and references to keys for signature
validation are communicated in advance). Generally, audiences need to be
validated per token issuer/authz server, meaning that for audience validation,
it probably also makes sense to support a mapping from issuer name to audiences.
{code:java}
enable_jwt_audience_validation=true
jwt_audiences=<name-of-issuer>:<audiences>;<name-of-issuer>:<audiences>{code}
(here, * could again be supported to allow any audiences, even though then a
decision would need to be taken whether that permits missing audience claims
altogether)
*3. Backwards Compatibility*
Multi-issuer support (under Option 1), could either be enabled by a feature
toggle or supported in a little bit of an ugly way by keeping jwks_url
(supporting just a single url, {_}or{_}{*}{*} a format like the one proposed
above). With a feature toggle (e.g. enable_multiple_jwks=true) Impala could
expect jwks_urls with the proposed format. The concrete issuer and audience
validation configuration could be hidden behind feature flags that are false by
default, not breaking existing configurations on upgrade.
*4. Other Aspects*
With multiple issuers, also per-token-issuer configuration for server cert
validation, username claims - and potentially, new: issuer and audience claim
names - may need to be supported.
I'm sure there is more I'm missing, but I would be curious how maintainers here
see native multi-issuer support and how the feature should evolve with respect
to established standards (e.g. OIDC). Depending on feedback, I may be able to
give an implementation a stab (but with strategic direction of the feature
carrying quite a bit of weight in terms of _how_ this could be implemented, I
felt raising some of the points I could think of here made sense.
> Verify JWT Audience and Issuer Claims
> -------------------------------------
>
> Key: IMPALA-12232
> URL: https://issues.apache.org/jira/browse/IMPALA-12232
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend, Security
> Reporter: Jason Fehr
> Assignee: Jason Fehr
> Priority: Major
> Labels: Impala, JWT, impala, jwt, security
>
> RFC 8725 contains JWT best practices that state the audience ("AUD") and
> issuer ("ISS") claims from a JWT should be validated if they are present.
> Impala currently has no mechanism to validate these claims.
> Implement [ISS claim
> validation|https://datatracker.ietf.org/doc/html/rfc8725#name-validate-issuer-and-subject]
> and [AUD claim
> validation|https://datatracker.ietf.org/doc/html/rfc8725#name-use-and-validate-audience].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
