[fix][broker] Check the original principal of proxied HTTP requests with its own authentication data - #26748

Motivation

For requests that come through a proxy, the broker authorizes both the proxy role and the original principal. On the binary protocol, ServerCnx checks the original principal with AuthenticationDataForwarded when the proxy does not forward the client's credentials. On HTTP, AuthorizationService and PulsarWebResource checked the original principal with the request's authentication data, which is authenticated as the proxy. Authorization providers that resolve roles from the authentication data, such as MultiRolesTokenAuthorizationProvider, then evaluated the original principal with the roles of the proxy's token.

The tenant admin check for proxied requests (validateAdminAccessForTenantAsync) also had two inconsistencies. When the proxy role itself was a tenant admin, the original principal was not checked. When it was not, both roles had to be super users, so a tenant admin could not use a super-user proxy.

Modifications

• AuthorizationService:
  • The original principal of a proxied request is checked with AuthenticationDataForwarded instead of the request's authentication data, and a subscription set on the request data is kept. This applies to super user, tenant, namespace, namespace and topic policy, topic, broker, cluster, and function, source and sink checks. The proxy role is still checked with the request's authentication data.
  • Add isSuperUserOrTenantAdmin(tenant, role, authData), which recognizes super users and tenant admins with the provider's own checks: validateTenantAdminAccess for PulsarAuthorizationProvider and its subclasses (which includes the additional roles of multi-role tokens), otherwise the provider's isSuperUser and isTenantAdmin. For PulsarAuthorizationProvider it also checks isTenantAdmin for the role itself, so a tenant admin whose request carries no token, such as a TLS-authenticated proxy, is still recognized.
• PulsarWebResource:
  • The super user check uses the original principal's own authentication data (originalPrincipalAuthData()).
  • For proxied requests that need tenant admin access, the proxy role and the original principal must each be a super user or a tenant admin, using AuthorizationService#isSuperUserOrTenantAdmin. The original principal is checked with its own authentication data.
• AuthenticationDataForwarded: add ofProxiedRequest(AuthenticationDataSource) and getProxiedRequestData(), so a provider can look at the proxied request without treating it as authenticated for the original principal. AuthenticationDataForwarded.INSTANCE is unchanged.
• MultiRolesTokenAuthorizationProvider: for the original principal of a proxied request, the roles of a token in the request are used only when that token is valid and authenticates as the original principal. For example, a client token forwarded by a TLS-authenticated proxy. Otherwise only the original principal's own role is used.
• PulsarAuthorizationProvider resolves roles as before.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• AuthorizationServiceTest#testOriginalPrincipalIsCheckedWithoutProxyAuthData: the original principal is checked with AuthenticationDataForwarded (keeping the subscription) for topic, namespace, policy, tenant, broker, cluster, super user and function, source and sink checks, and the proxy role with the request data.
• AuthorizationServiceTest#testIsSuperUserOrTenantAdminUsesProviderAdminChecks: isSuperUserOrTenantAdmin recognizes super users and tenant admins, and not roles that are only allowed tenant operations.
• MultiRolesTokenAuthorizationProviderTest#testProxiedHttpRequestUsesOnlyTheOriginalPrincipalToken (broker-common): only a valid token of the original principal adds roles; the proxy's token, another principal's token and an invalid token of the original principal add none.
• MultiRolesTokenAuthorizationProviderTest#testTenantAdminRoleWithoutTokenIsRecognized (broker-common): a tenant admin role is recognized when the request carries no token.
• MultiRolesTokenTlsProxyHttpTest (broker): for a proxy that authenticates with a TLS client certificate and forwards the client's headers, a forwarded token of the original principal adds its roles, a missing token or another subject's token adds none, and a tenant-admin proxy with no token can serve a tenant admin but not an ordinary original principal.
• MultiRolesTokenAuthorizationProviderTest#testProxiedRequestsCheckOriginalPrincipalWithItsOwnRole (broker): through a proxy whose token carries additional roles, an ordinary original principal does not get those roles for super user, topic, namespace and tenant admin operations, while a proxy forwarding a super user or a tenant admin keeps working.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

Public API: AuthenticationDataForwarded gains ofProxiedRequest(AuthenticationDataSource) and getProxiedRequestData(), and AuthorizationService gains isSuperUserOrTenantAdmin(String, String, AuthenticationDataSource). Custom authorization providers now receive AuthenticationDataForwarded for the original principal of proxied HTTP requests, as they already do on the binary protocol.