[ 
https://issues.apache.org/jira/browse/HADOOP-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

KWON BYUNGCHANG updated HADOOP-19904:
-------------------------------------
    Description: 
h3. Problem
HttpServer2's access log always records `-` in the `%u` position even
for authenticated requests:
Affects every HttpServer2-backed daemon (NN/DN/RM/NM/HttpFS/KMS).

h3. Root cause
`AuthenticationFilter` wraps `HttpServletRequest` so downstream
filters and servlets see the user via `getRemoteUser()`. The wrap
only flows through the filter chain. Jetty's `RequestLogHandler`
runs outside the chain on the base `Request`, whose
`getAuthentication()` stays as `NOT_CHECKED` forever.

Jetty's native auth path (`jetty-security` Authenticators) sets
`Request.setAuthentication(...)` directly, which is why standard
deployments don't have this issue. Hadoop avoids `jetty-security`
for container portability and pays this cost.

h3. Fix
Add a static helper `JettyAuthenticationHelper.publishRemoteUser(...)`
in hadoop-auth that:

1. Reads the effective user (`getRemoteUser()` or an explicit name),
2. Calls `Request.setAuthentication(...)` on the base `Request` with
   a minimal inline `Authentication.User` (no `jetty-security`
   dependency),

Invocation sites cover the paths where the effective user is decided:

- `AuthenticationFilter.doFilter(filterChain, request, response)` —
  the protected hook called after wrapping. Subclasses
  (`ProxyUserAuthenticationFilter`, `DelegationTokenAuthenticationFilter`)
  wrap with doAs/UGI and route through `super.doFilter`, so this
  single hook covers them.
- `DelegationTokenAuthenticationHandler.managementOperation` for
  `GETDELEGATIONTOKEN`/`RENEW`/`CANCEL` — the handler writes the
  response inline and returns false, skipping the filter chain, so
  the helper is called directly there.
- `JspHelper.getUGI` for HDFS Web UI / WebHDFS servlets that resolve
  UGI outside the filter chain.

No `HttpServer2` configuration changes required; calls are inline at
each path. Works for both Kerberos and pseudo-auth (both feed the
user through `getRemoteUser()` / `requestUgi`).

 

  was:
h2. Problem
HttpServer2's access log always records `-` in the `%u` position even
for authenticated requests:
Affects every HttpServer2-backed daemon (NN/DN/RM/NM/HttpFS/KMS).
 
h2. Root cause
`AuthenticationFilter` wraps `HttpServletRequest` so downstream
filters and servlets see the user via `getRemoteUser()`. The wrap
only flows through the filter chain. Jetty's `RequestLogHandler`
runs outside the chain on the base `Request`, whose
`getAuthentication()` stays as `NOT_CHECKED` forever.
 
Jetty's native auth path (`jetty-security` Authenticators) sets
`Request.setAuthentication(...)` directly, which is why standard
deployments don't have this issue. Hadoop avoids `jetty-security`
for container portability and pays this cost.
 
h2. Fix
Install a small Servlet `Filter` (in hadoop-common) after the
auth filters that:
 
1. Reads `getRemoteUser()` from the wrapped request,
2. Calls `Request.setAuthentication(...)` on the base `Request`
with a minimal inline `Authentication.User` (no
`jetty-security` dependency).
 
`HttpServer2.initializeWebServer` installs it automatically after
`FilterInitializer`s; no configuration needed. Works for both
Kerberos and pseudo-auth — both feed the user through
`getRemoteUser()`.
 
h2. Known gap
`DelegationTokenAuthenticationHandler.managementOperation` writes
its response inline and returns `false`, so `AuthenticationFilter`
skips `filterChain.doFilter`. The bridge filter doesn't run for
token mgmt requests; the handler attaches directly there.
 
 


> HttpServer2 access log does not record the authenticated user
> -------------------------------------------------------------
>
>                 Key: HADOOP-19904
>                 URL: https://issues.apache.org/jira/browse/HADOOP-19904
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: KWON BYUNGCHANG
>            Priority: Major
>              Labels: pull-request-available
>
> h3. Problem
> HttpServer2's access log always records `-` in the `%u` position even
> for authenticated requests:
> Affects every HttpServer2-backed daemon (NN/DN/RM/NM/HttpFS/KMS).
> h3. Root cause
> `AuthenticationFilter` wraps `HttpServletRequest` so downstream
> filters and servlets see the user via `getRemoteUser()`. The wrap
> only flows through the filter chain. Jetty's `RequestLogHandler`
> runs outside the chain on the base `Request`, whose
> `getAuthentication()` stays as `NOT_CHECKED` forever.
> Jetty's native auth path (`jetty-security` Authenticators) sets
> `Request.setAuthentication(...)` directly, which is why standard
> deployments don't have this issue. Hadoop avoids `jetty-security`
> for container portability and pays this cost.
> h3. Fix
> Add a static helper `JettyAuthenticationHelper.publishRemoteUser(...)`
> in hadoop-auth that:
> 1. Reads the effective user (`getRemoteUser()` or an explicit name),
> 2. Calls `Request.setAuthentication(...)` on the base `Request` with
>    a minimal inline `Authentication.User` (no `jetty-security`
>    dependency),
> Invocation sites cover the paths where the effective user is decided:
> - `AuthenticationFilter.doFilter(filterChain, request, response)` —
>   the protected hook called after wrapping. Subclasses
>   (`ProxyUserAuthenticationFilter`, `DelegationTokenAuthenticationFilter`)
>   wrap with doAs/UGI and route through `super.doFilter`, so this
>   single hook covers them.
> - `DelegationTokenAuthenticationHandler.managementOperation` for
>   `GETDELEGATIONTOKEN`/`RENEW`/`CANCEL` — the handler writes the
>   response inline and returns false, skipping the filter chain, so
>   the helper is called directly there.
> - `JspHelper.getUGI` for HDFS Web UI / WebHDFS servlets that resolve
>   UGI outside the filter chain.
> No `HttpServer2` configuration changes required; calls are inline at
> each path. Works for both Kerberos and pseudo-auth (both feed the
> user through `getRemoteUser()` / `requestUgi`).
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to