Skip to main content

Extend Authentication and Authorization in Pulsar

Pulsar provides a way to use custom authentication and authorization mechanisms.

Authentication

You can use a custom authentication mechanism by providing the implementation in the form of two plugins.

  • Client authentication plugin org.apache.pulsar.client.api.AuthenticationDataProvider provides the authentication data for broker/proxy.
  • Broker/Proxy authentication plugin org.apache.pulsar.broker.authentication.AuthenticationProvider authenticates the authentication data from clients.

Client authentication plugin

For the client library, you need to implement org.apache.pulsar.client.api.Authentication. By entering the command below, you can pass this class when you create a Pulsar client.

PulsarClient client = PulsarClient.builder()
.serviceUrl("pulsar://localhost:6650")
.authentication(new MyAuthentication())
.build();

You can implement 2 interfaces on the client side:

This in turn requires you to provide the client credentials in the form of org.apache.pulsar.client.api.AuthenticationDataProvider and also leaves the chance to return different kinds of authentication tokens for different types of connections or by passing a certificate chain to use for TLS.

You can find the following examples for different client authentication plugins:

Broker/Proxy authentication plugin

On the broker/proxy side, you need to configure the corresponding plugin to validate the credentials that the client sends. The proxy and broker can support multiple authentication providers at the same time.

In conf/broker.conf, you can choose to specify a list of valid providers:

# Authentication provider name list, which is comma separated list of class names
authenticationProviders=
tip

Pulsar supports an authentication provider chain that contains multiple authentication providers with the same authentication method name.

For example, your Pulsar cluster uses JSON Web Token (JWT) authentication (with an authentication method named token) and you want to upgrade it to use OAuth2.0 authentication with the same authentication name. In this case, you can implement your own authentication provider AuthenticationProviderOAuth2 and configure authenticationProviders as follows.

authenticationProviders=org.apache.pulsar.broker.authentication.AuthenticationProviderToken,org.apache.pulsar.broker.authentication.AuthenticationProviderOAuth2

As a result, brokers look up the authentication providers with the token authentication method (JWT and OAuth2.0 authentication) when receiving requests to use the token authentication method. If a client cannot be authenticated via JWT authentication, OAuth2.0 authentication is used.

For the implementation of the org.apache.pulsar.broker.authentication.AuthenticationProvider interface, refer to code.

You can find the following examples for different broker authentication plugins:

Authorization

Authorization is the operation that checks whether a particular "role" or "principal" has permission to perform a certain operation.

By default, you can use the embedded authorization provider provided by Pulsar. You can also configure a different authorization provider through a plugin. Note that although the Authentication plugin is designed for use in both the proxy and broker, the Authorization plugin is designed only for use on the broker.

Broker authorization plugin

To provide a custom authorization provider, you need to implement the org.apache.pulsar.broker.authorization.AuthorizationProvider interface, put this class in the Pulsar broker classpath and configure the class in conf/broker.conf:

# Authorization provider fully qualified class-name
authorizationProvider=org.apache.pulsar.broker.authorization.PulsarAuthorizationProvider

For the implementation of the org.apache.pulsar.broker.authorization.AuthorizationProvider interface, refer to code.