[
https://issues.apache.org/jira/browse/HBASE-29557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nihal Jain updated HBASE-29557:
-------------------------------
Description:
Introduce a new module, hbase-auth-filters, that contains a minimal, copy of
the Hadoop auth pieces HBase uses (e.g., AuthenticationFilter and required
helpers). This decouples HBase’s server stack (web UI, REST, Thrift) from
Hadoop’s javax-based auth so we can move to Jetty 12 EE10/Jakarta without being
gated by Hadoop’s servlet/Jetty timeline.
*Motivation*
- Jetty 9 is EOL; we completed the EE8 step with HBASE-29224 and want to move
to EE10 (Jakarta) with HBASE-29542
- Today our servers depend on Hadoop’s javax AuthenticationFilter. That ties
our upgrade pace to Hadoop’s servlet/Jetty cadence.
- By carrying a copy, we unblock HBase now and avoid future coordination
bottlenecks.
*Proposed Change*
- Add a new module: hbase-auth-filters
- Copy only the minimal Hadoop auth classes HBase uses (AuthenticationFilter +
small set of helpers).
- Wire HBase web/REST/Thrift servers to use these classes and ensure we do not
have any regression as we simply copy here.
*Pros*
- Fully decouples HBase’s server stack from Hadoop’s servlet pace; clean
Jakarta path for HBASE-29542.
- Avoids being perpetually tied to Hadoop’s Jetty/servlet cadence.
- Interoperability is preserved with:
-- Current Hadoop lines that remain on javax, and
-- Future Hadoop lines that move to Jakarta
*Compatibility/Support Notes*
- Server-internal change only; no wire or client API changes expected.
- Allows HBase to support Hadoop versions on javax today and those on Jakarta
in the future without forcing a drop of javax-era Hadoop immediately when
Hadoop switches.
- If/when Hadoop publishes Jakarta-native auth, we can evaluate switching to
their artifacts; because we’re decoupled, that can be done on our schedule.
*Cons/Risks*
- We must track upstream fixes in the copied classes.
- Mitigation: keep the surface area minimal; periodically review for
security/bug fixes. These classes have historically been relatively stable.
*Alternatives (not chosen here)*
- Shade/relocate Hadoop auth into a private package and rewrite javax→jakarta
(hadoop-auth-shaded): avoids a source fork but retains coupling to Hadoop
releases and requires re-shading on upstream changes.
- Wait for Hadoop to move to Jakarta with HADOOP-19395: simplest short-term,
but keeps HBase blocked on Hadoop’s schedule.
*Acceptance Criteria*
- HBase servers start and operate on Jetty 12 EE8 using hbase-auth-filters as
it were before
- REST/Thrift/authn flows pass existing test suites (including Kerberos).
- No regression in supported Hadoop versions due to this change.
*Follow-ups*
- Switch to jakarta for the our (then) native auth filter and unblock
HBASE-29542 without waiting for hadoop.
*Fix Version(s)*
- Target: master, branch-3
- Although, This can be backported to branch-2 as well, paving way for our
future jetty migration path
*Class list identified for hbase-auth-filters*
Below is a minimal list of files we may have to copy from hadoop; a PoC will
follow if others think this approach is worth investing our time in.
{{grep -r "javax.servlet." src/main | cut -d: -f1 | sort | uniq}}
*
src/main/java/org/apache/hadoop/security/authentication/server/AltKerberosAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationFilter.java
*
src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationToken.java
*
src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/LdapAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/MultiSchemeAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/PseudoAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
*
src/main/java/org/apache/hadoop/security/authentication/util/FileSignerSecretProvider.java
*
src/main/java/org/apache/hadoop/security/authentication/util/RolloverSignerSecretProvider.java
*
src/main/java/org/apache/hadoop/security/authentication/util/SignerSecretProvider.java
*
src/main/java/org/apache/hadoop/security/authentication/util/ZKSignerSecretProvider.java
was:
Introduce a new module, hbase-auth-filters, that contains a minimal, copy of
the Hadoop auth pieces HBase uses (e.g., AuthenticationFilter and required
helpers). This decouples HBase’s server stack (web UI, REST, Thrift) from
Hadoop’s javax-based auth so we can move to Jetty 12 EE10/Jakarta without being
gated by Hadoop’s servlet/Jetty timeline.
*Motivation*
- Jetty 9 is EOL; we completed the EE8 step with HBASE-29224 and want to move
to EE10 (Jakarta) with HBASE-29542
- Today our servers depend on Hadoop’s javax AuthenticationFilter. That ties
our upgrade pace to Hadoop’s servlet/Jetty cadence.
- By carrying a copy, we unblock HBase now and avoid future coordination
bottlenecks.
*Proposed Change*
- Add a new module: hbase-auth-filters
- Copy only the minimal Hadoop auth classes HBase uses (AuthenticationFilter +
small set of helpers).
- Wire HBase web/REST/Thrift servers to use these classes and ensure we do not
have any regression as we simply copy here.
*Pros*
- Fully decouples HBase’s server stack from Hadoop’s servlet pace; clean
Jakarta path for HBASE-29542.
- Avoids being perpetually tied to Hadoop’s Jetty/servlet cadence.
- Interoperability is preserved with:
-- Current Hadoop lines that remain on javax, and
-- Future Hadoop lines that move to Jakarta
*Compatibility/Support Notes*
- Server-internal change only; no wire or client API changes expected.
- Allows HBase to support Hadoop versions on javax today and those on Jakarta
in the future without forcing a drop of javax-era Hadoop immediately when
Hadoop switches.
- If/when Hadoop publishes Jakarta-native auth, we can evaluate switching to
their artifacts; because we’re decoupled, that can be done on our schedule.
*Cons/Risks*
- We must track upstream fixes in the copied classes.
- Mitigation: keep the surface area minimal; periodically review for
security/bug fixes. These classes have historically been relatively stable.
*Alternatives (not chosen here)*
- Shade/relocate Hadoop auth into a private package and rewrite javax→jakarta
(hadoop-auth-shaded): avoids a source fork but retains coupling to Hadoop
releases and requires re-shading on upstream changes.
- Wait for Hadoop to move to Jakarta: simplest short-term, but keeps HBase
blocked on Hadoop’s schedule.
*Acceptance Criteria*
- HBase servers start and operate on Jetty 12 EE8 using hbase-auth-filters as
it were before
- REST/Thrift/authn flows pass existing test suites (including Kerberos).
- No regression in supported Hadoop versions due to this change.
*Follow-ups*
- Switch to jakarta for the our (then) native auth filter and unblock
HBASE-29542 without waiting for hadoop.
*Fix Version(s)*
- Target: master, branch-3
- Although, This can be backported to branch-2 as well, paving way for our
future jetty migration path
*Class list identified for hbase-auth-filters*
Below is a minimal list of files we may have to copy from hadoop; a PoC will
follow if others think this approach is worth investing our time in.
{{grep -r "javax.servlet." src/main | cut -d: -f1 | sort | uniq}}
*
src/main/java/org/apache/hadoop/security/authentication/server/AltKerberosAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationFilter.java
*
src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationToken.java
*
src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/LdapAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/MultiSchemeAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/server/PseudoAuthenticationHandler.java
*
src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
*
src/main/java/org/apache/hadoop/security/authentication/util/FileSignerSecretProvider.java
*
src/main/java/org/apache/hadoop/security/authentication/util/RolloverSignerSecretProvider.java
*
src/main/java/org/apache/hadoop/security/authentication/util/SignerSecretProvider.java
*
src/main/java/org/apache/hadoop/security/authentication/util/ZKSignerSecretProvider.java
> Decouple dependency on Hadoop AuthenticationFilter classes
> ----------------------------------------------------------
>
> Key: HBASE-29557
> URL: https://issues.apache.org/jira/browse/HBASE-29557
> Project: HBase
> Issue Type: Improvement
> Components: dependencies, jetty12, REST, security, Thrift, UI
> Reporter: Nihal Jain
> Assignee: Nihal Jain
> Priority: Major
>
> Introduce a new module, hbase-auth-filters, that contains a minimal, copy of
> the Hadoop auth pieces HBase uses (e.g., AuthenticationFilter and required
> helpers). This decouples HBase’s server stack (web UI, REST, Thrift) from
> Hadoop’s javax-based auth so we can move to Jetty 12 EE10/Jakarta without
> being gated by Hadoop’s servlet/Jetty timeline.
> *Motivation*
> - Jetty 9 is EOL; we completed the EE8 step with HBASE-29224 and want to
> move to EE10 (Jakarta) with HBASE-29542
> - Today our servers depend on Hadoop’s javax AuthenticationFilter. That ties
> our upgrade pace to Hadoop’s servlet/Jetty cadence.
> - By carrying a copy, we unblock HBase now and avoid future coordination
> bottlenecks.
> *Proposed Change*
> - Add a new module: hbase-auth-filters
> - Copy only the minimal Hadoop auth classes HBase uses (AuthenticationFilter
> + small set of helpers).
> - Wire HBase web/REST/Thrift servers to use these classes and ensure we do
> not have any regression as we simply copy here.
> *Pros*
> - Fully decouples HBase’s server stack from Hadoop’s servlet pace; clean
> Jakarta path for HBASE-29542.
> - Avoids being perpetually tied to Hadoop’s Jetty/servlet cadence.
> - Interoperability is preserved with:
> -- Current Hadoop lines that remain on javax, and
> -- Future Hadoop lines that move to Jakarta
> *Compatibility/Support Notes*
> - Server-internal change only; no wire or client API changes expected.
> - Allows HBase to support Hadoop versions on javax today and those on
> Jakarta in the future without forcing a drop of javax-era Hadoop immediately
> when Hadoop switches.
> - If/when Hadoop publishes Jakarta-native auth, we can evaluate switching to
> their artifacts; because we’re decoupled, that can be done on our schedule.
> *Cons/Risks*
> - We must track upstream fixes in the copied classes.
> - Mitigation: keep the surface area minimal; periodically review for
> security/bug fixes. These classes have historically been relatively stable.
> *Alternatives (not chosen here)*
> - Shade/relocate Hadoop auth into a private package and rewrite
> javax→jakarta (hadoop-auth-shaded): avoids a source fork but retains coupling
> to Hadoop releases and requires re-shading on upstream changes.
> - Wait for Hadoop to move to Jakarta with HADOOP-19395: simplest short-term,
> but keeps HBase blocked on Hadoop’s schedule.
> *Acceptance Criteria*
> - HBase servers start and operate on Jetty 12 EE8 using hbase-auth-filters
> as it were before
> - REST/Thrift/authn flows pass existing test suites (including Kerberos).
> - No regression in supported Hadoop versions due to this change.
> *Follow-ups*
> - Switch to jakarta for the our (then) native auth filter and unblock
> HBASE-29542 without waiting for hadoop.
> *Fix Version(s)*
> - Target: master, branch-3
> - Although, This can be backported to branch-2 as well, paving way for our
> future jetty migration path
> *Class list identified for hbase-auth-filters*
> Below is a minimal list of files we may have to copy from hadoop; a PoC will
> follow if others think this approach is worth investing our time in.
> {{grep -r "javax.servlet." src/main | cut -d: -f1 | sort | uniq}}
> *
> src/main/java/org/apache/hadoop/security/authentication/server/AltKerberosAuthenticationHandler.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationFilter.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandler.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationToken.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/JWTRedirectAuthenticationHandler.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/LdapAuthenticationHandler.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/MultiSchemeAuthenticationHandler.java
> *
> src/main/java/org/apache/hadoop/security/authentication/server/PseudoAuthenticationHandler.java
> *
> src/main/java/org/apache/hadoop/security/authentication/util/CertificateUtil.java
> *
> src/main/java/org/apache/hadoop/security/authentication/util/FileSignerSecretProvider.java
> *
> src/main/java/org/apache/hadoop/security/authentication/util/RolloverSignerSecretProvider.java
> *
> src/main/java/org/apache/hadoop/security/authentication/util/SignerSecretProvider.java
> *
> src/main/java/org/apache/hadoop/security/authentication/util/ZKSignerSecretProvider.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
