Attila Turoczy created HIVE-29730:
-------------------------------------
Summary: OIDC Authentication and Identity Mapping for HiveServer2
and JDBC Clients
Key: HIVE-29730
URL: https://issues.apache.org/jira/browse/HIVE-29730
Project: Hive
Issue Type: New Feature
Components: HiveServer2
Reporter: Attila Turoczy
HiveServer2 already supports JWT-based authentication over HTTP transport.
However, the current implementation is primarily a bring-your-own-token
mechanism rather than a complete, production-grade OAuth 2.0 / OpenID Connect
authentication solution.
Clients must obtain the JWT externally and pass it to HiveServer2. HiveServer2
validates the token using the configured JWKS endpoint and derives the session
user from the token subject. This provides basic boundary authentication, but
several capabilities required for secure and user-friendly cloud deployments
are currently missing or limited.
The goal of this initiative is to enhance the existing HiveServer2 JWT support
and provide a complete OIDC-based authentication experience for Hive clients,
without changing the existing downstream Kerberos, delegation-token, or Hadoop
execution model.
Enhance JWT validation with configurable support for:
* OIDC discovery through {{/.well-known/openid-configuration}}
* Issuer validation
* Audience validation
* Authorized party validation where applicable
* Scope and role validation
* {{{}nbf{}}}, expiration, and configurable clock-skew handling
* Explicitly allowed signing algorithms
* Multiple trusted issuers or identity providers
* Automatic JWKS refresh and key rotation
* Resilient JWKS caching and retry behavior
* Secure handling of JWT-related configuration properties
h4. 2. Configurable identity and group mapping (? maybe separate task)
Allow administrators to configure how JWT claims are mapped to the Hive
identity.
Examples:
{{hive.server2.authentication.jwt.user.claim=preferred_username
hive.server2.authentication.jwt.groups.claim=groups}}
The implementation should support common claims such as:
* {{sub}}
* {{preferred_username}}
* {{email}}
* {{upn}}
* {{groups}}
* {{roles}}
* tenant-related claims
The resolved identity must be passed consistently to:
* HiveServer2 sessions
* Ranger authorization
* Audit logging
* Proxy-user and impersonation checks
Audit records should preserve both the authenticated token identity and the
effective Hive user when they differ.{{}}
h4. Backward-compatible migration mode
The implementation should preserve support for existing authentication
mechanisms.
HiveServer2 should continue to support configurations where Kerberos and
JWT/OIDC authentication are enabled in parallel, allowing customers to migrate
clients gradually.
For example:
{{hive.server2.authentication=KERBEROS,JWT}}
The authentication mechanism should be selected according to the incoming HTTP
authorization scheme.
h3. Motivation
Kerberos-based client authentication creates significant setup and usability
challenges in cloud and containerized environments.
Users may need to configure:
* Java
* Kerberos client libraries
* {{krb5.conf}}
* DNS and realm resolution
* Keytabs or ticket initialization
* Ticket renewal
OIDC authentication would allow HiveServer2 to integrate with modern identity
providers such as:
* Microsoft Entra ID
* Keycloak
* Okta
* Auth0
* Other standards-compliant OIDC providers
This would provide a more secure and user-friendly authentication model while
preserving compatibility with the existing Hive and Hadoop execution
architecture.
h3. Expected Benefits
* Simplified Hive client onboarding
* Better cloud and Kubernetes integration
* No requirement to distribute user keytabs
* Short-lived and centrally managed access tokens
* Improved support for standalone Beeline distributions
* Consistent identity mapping between HiveServer2 and Ranger
* Safer identity-provider key rotation
* Gradual migration from Kerberos client authentication
* Standards-based integration with enterprise identity providers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
