HIVE-29639: Support a pluggable authentication filter for the HiveServer2 WebUI

[magnuma3]

HIVE-29639

What changes were proposed in this pull request?

• Proposal

Add a configurable javax.servlet.Filter slot to the WebUI, mirroring
Spark's spark.ui.filters. Any Filter can then be
installed via configuration alone, with no code changes

Why are the changes needed?

• Problem

In a Kerberized cluster, the HS2 WebUI is typically protected with
SPNEGO (hive.server2.webui.use.spnego + keytab/principal). SPNEGO
works fine for command-line / Kerberos clients, but in a browser it is
clunky: end users need a working Kerberos ticket cache on their
workstation, the browser has to be whitelisted for the SPNEGO domain,
and there is no clean way to plug the UI into an organisation's
broader SSO flow.

Elsewhere in the Hadoop ecosystem, this gap is commonly closed by
KnoxSSO in front of Kerberized NameNode / YARN ResourceManager /
Oozie UIs so end users get a single browser SSO experience instead of
raw SPNEGO, while the services themselves stay Kerberized.

HS2 cannot join that story today. There is no supported way to insert
a custom javax.servlet.Filter into the WebUI servlet pipeline, so
operators either live with browser SPNEGO

Does this PR introduce any user-facing change?

• New configuration

Key	Default	Meaning
hive.server2.webui.use.custom.auth.filter	false	Master switch.
hive.server2.webui.custom.auth.filter	(empty)	Fully-qualified Filter class. Required when the switch is on; empty is rejected at startup.
hive.server2.webui.custom.auth.filter.param.<name>	—	Init parameters passed to the filter. The prefix is stripped; <name> becomes the parameter key.

• Example (KnoxSSO)

hive.server2.webui.use.custom.auth.filter=true
hive.server2.webui.custom.auth.filter=org.apache.hadoop.security.authentication.server.AuthenticationFilter
hive.server2.webui.custom.auth.filter.param.type=org.apache.hadoop.security.authentication.server.JWTRedirectAuthenticationHandler
hive.server2.webui.custom.auth.filter.param.alt-kerberos.non-browser.user-agents=${hadoop.http.authentication.alt-kerberos.non-browser.user-agents}
hive.server2.webui.custom.auth.filter.param.signer.secret.provider=${hadoop.http.authentication.signer.secret.provider}
hive.server2.webui.custom.auth.filter.param.signature.secret.file=${hadoop.http.authentication.signature.secret.file}
hive.server2.webui.custom.auth.filter.param.authentication.provider.url=${hadoop.http.authentication.authentication.provider.url}
hive.server2.webui.custom.auth.filter.param.public.key.pem=${hadoop.http.authentication.public.key.pem}

How was this patch tested?

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.3% Duplication on New Code

See analysis details on SonarQube Cloud

[deniskuzZ]

We also support LDAP for HS2 WebUI. cc @difin
cc @saihemanth-cloudera, @nrg4878 do you think this would be useful?

[saihemanth-cloudera]

Instead of adding a new config, why not extend the existing config to support custom_auth? https://github.com/apache/hive/blob/master/common/src/java/org/apache/hadoop/hive/conf/HiveConf.java#L3914C5-L3914C35

[magnuma3]

Thanks for the review @saihemanth-cloudera!

I initially followed the pattern of the existing hive.server2.webui.use.spnego and hive.server2.webui.use.pam configs.

I noticed that hive.server2.webui.auth.method was introduced more recently in HIVE-28457 (4.1.0) but currently only supports NONE and LDAP, so the WebUI auth configuration is a bit split between the two styles right now.

Is the long-term plan to eventually consolidate use.spnego and use.pam into hive.server2.webui.auth.method as well? That context would help me align this PR with the intended direction.

[saihemanth-cloudera]

We also support LDAP for HS2 WebUI. cc @difin cc @saihemanth-cloudera, @nrg4878 do you think this would be useful?

This has been a pain point for long time without knox in the picture. So I'm +1 to the idea of setting up a custom auth filter.