PIP-206: Refresh different authentication data

[nodece]

Motivation

For the Pulsar protocol, the client passes the authentication data to the broker/proxy by sending the CommandConnect command.

In the Pulsar proxy, we support forwarding the authentication data from the user client to the broker, this authentication data is named the original authentication data, we also need to pass the proxy’s authentication data, this authentication data is named the self authentication data.

The client supports passing two types of authentication data to connect to the broker, self authentication data and original authentication data in the CommandConnect command.

self authentication: -> CommandConnect.authData.

original authentication: -> CommandConnect.originalAuthData.

When the client/proxy is connected to the broker, the broker starts a thread to check if the authentication data is expired. When both authentication data exist, the broker only supports refreshing the original authentication data and ignores refreshing the self authentication data. When self authentication data is expired, we must consider how to refresh the self authentication data.

Check logic:

pulsar/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/ServerCnx.java

Line 749 in c7b7146

AuthenticationState authState = this.originalAuthState != null ? originalAuthState : this.authState;

this.authState is ignored.

Goal

Propose an approach that refreshes the different authentication data.

API Changes

1. Add the original_auth_data field representing which authentication data needs refreshed.

message CommandAuthResponse {
    optional bool original_auth_data = 4 [default = false];
}

3. Add the refreshOriginalAuthentication method to the AuthenticationState interface.

public interface AuthenticationState {
     /**
     * If the authentication state supports refreshing and the credentials are expired,
     * the auth provider will call this method to initiate the refresh process.
     * <p>
     * The auth state here will return the broker side data that will be used to send
     * a challenge to the client
     *
     * @return the {@link AuthData} for the broker challenge to client
     * @throws AuthenticationException
     */
    default AuthData refreshOriginalAuthentication() throws AuthenticationException {
        return AuthData.of("PulsarOriginalAuthRefresh".getBytes(StandardCharsets.UTF_8));
    }
}

Implementation

For the broker, we need to add a method on the org.apache.pulsar.broker.service.PulsarChannelInitializer to check the self authentication data is expired.

For the client like the original client, or the proxy client, we need to parse the original_auth_data field from the CommandAuthChallenge command, then respond to the correct authentication data to the broker to refresh the authentication data.

For the proxy handler, we need to do some forwarding operations to refresh authentication data.

Alternatives

No response

Anything else?

This change is fully compatible with different versions of client and broker, if the client fails to authenticate, the broker disconnects.

Reference

• PulsarProxy does not always refresh authentication tokens received from client #10816

Discussion thread: https://lists.apache.org/thread/0wz12m255t9xvzf4rtc69c8dlov12764
Voting thread: https://lists.apache.org/thread/gk6wwrtgs8hfqd3x8dt81kgoswxhnbpf

[codelipenghui]

@nodece Could you please provide more context about the difference of the self/original auth data?

[nodece]

@codelipenghui This PIP has been updated.

[nodece]

@codelipenghui @michaeljmarshall @merlimat @eolivelli Could you review this PIP? This is important fix.

[nodece]

I have discussed this with @codelipenghui, @tuteng, and @mattisonchao offline. We will handle this issue on the proxy module to avoid adding complex logic to the broker. Just keep one authentication data on the broker!

[michaeljmarshall]

Thanks @nodece, that makes sense to me. Sorry for my delayed review, I'll try to review the next draft quicker.