Pulsar provides a way to use custom authentication and authorization mechanisms.
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.AuthenticationDataProviderprovides the authentication data for broker/proxy.
- Broker/Proxy authentication plugin
org.apache.pulsar.broker.authentication.AuthenticationProviderauthenticates 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()
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.
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
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.
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 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
# Authorization provider fully qualified class-name
For the implementation of the
org.apache.pulsar.broker.authorization.AuthorizationProvider interface, refer to code.