Support forwarding selected ExternalAuth response headers to upstream backends

[alexandrunegoita-WI]

Is your feature request related to a problem? Please describe.

The ExternalAuth Policy can allow or deny a request, but it does not currently provide a declarative way to forward selected headers returned by the authentication service to the upstream backend.

Our authentication service returns trusted identity headers such as:

• Tenant-UUID
• User-UUID
• Permissions
• Licenses
• License-Constraints
• X-Session-ID

With community ingress-nginx, this is supported through the nginx.ingress.kubernetes.io/auth-response-headers annotation. Without equivalent support, the backend receives the request but not the authenticated user and tenant context.

Describe the solution you'd like

Add an optional allowlist of authentication response headers to spec.externalAuth, for example:

spec:
  externalAuth:
    authURI: /v1/auth
    authServiceName: application/auth-service
    authServicePorts:
      - 80
    headersToBackend:
      - Tenant-UUID
      - User-UUID
      - Permissions
      - Licenses
      - License-Constraints
      - X-Session-ID

After a successful 2xx authentication response, the listed headers should be copied from the auth response to the request sent to the upstream backend.

Values returned by the trusted authentication service should replace any client-provided headers with the same names. Only explicitly configured headers should be forwarded.

The exact field name could also be responseHeaders or another name preferred by the maintainers.

Describe alternatives you've considered

Using snippets or a custom NGINX template, which introduces security, governance, and maintenance concerns.
Implementing authentication separately in every backend application.
Maintaining a private fork of the controller.
Switching to another ingress controller that supports forwarding authentication response headers.

Additional context

An attempted responseHeaders field is currently rejected because it is not part of the ExternalAuth CRD schema.

This capability is required for migration from community ingress-nginx, where the equivalent configuration is:

nginx.ingress.kubernetes.io/auth-url: http://auth-service.application.svc.cluster.local/v1/auth
nginx.ingress.kubernetes.io/auth-response-headers: Tenant-UUID, User-UUID, Permissions, Licenses, License-Constraints, X-Session-ID

Thank you!

[github-actions]

Hi @alexandrunegoita-WI thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

I've parsed the text of your issue and it looks like you might be mixing up the two Ingress Controllers, please take a look at this page to see the differences between nginx/kubernetes-ingress (this repo) and kubernetes/ingress-nginx.

If your issue concerns any of the enterprise features please open a ticket with F5 directly (For NGINX Plus customers NGINX Ingress Controller (when used with NGINX Plus) is covered by the support contract.)

Cheers!

[ciarams87]

Thank you for bringing this to our attention @alexandrunegoita-WI!

Recommended design notes for whoever picks this up:

Proposed shape: authResponseHeaders: []string on ExternalAuth, e.g.:

externalAuth:
  authURI: /v1/auth
  authServiceName: application/auth-service
  authResponseHeaders:
  - Tenant-UUID
  - User-UUID
  - Permissions

Directives required: auth_request_set (capture) + proxy_set_header (forward), per backend location, e.g.

location /tea {
    ...
    auth_request_set $auth_resp_tenant_uuid $upstream_http_tenant_uuid;
    proxy_set_header Tenant-UUID $auth_resp_tenant_uuid;
    auth_request_set $auth_resp_user_uuid   $upstream_http_user_uuid;
    proxy_set_header User-UUID   $auth_resp_user_uuid;

    proxy_pass http://vs_default_cafe_tea;
}

Note: No existing field can express this - action.proxy.requestHeaders.set supports NGINX variables but not $upstream_http_* of the auth subrequest, and extending its allowlist wouldn't work because that variable isn't in scope at proxy_set_header evaluation time in that context.

Sizing: Spans CRD/validation/config-gen/templates across both VirtualServer (spec+route) and Ingress (standard+minion) - 5 attachment paths, all needing separate propagation logic since the policy can render at server or location context depending on attach point.

Recommended decisions for implementation: header names restricted to [A-Za-z0-9-] (no _, to avoid X-Session-ID/X_Session_ID collision on the derived NGINX variable); auth-service value always wins over any client-supplied or VirtualServer-configured header of the same name; plain name list only, no renaming in v1.

[nginx-discourse-bot]

This issue has been mentioned on NGINX Community Forum. There might be relevant details there:

https://community.nginx.org/t/supported-replacement-for-ingress-nginx-auth-response-headers-with-externalauth-policy-and-snippets-disabled/10203/3