The PIP will be simplified (the PulsarTlsMaterialProvider part). I haven't yet updated the PIP document.
-Lari On 2026/05/29 20:10:49 Lari Hotari wrote: > Hi Pulsar community, > > I'd like to propose PIP-478: Asynchronous v5 client authentication plugin > interfaces and TLS material provider plugin interface. It fills in the client > authentication design for the new Java client API (the v5 modules introduced > by > PIP-466), which only sketched a stub and explicitly invited a follow-up > proposal. This is that follow-up. > > The proposal replaces the v4 "kitchen-sink" AuthenticationDataProvider with a > small core Authentication interface plus narrow, opt-in capability interfaces, > segregated by transport (Pulsar binary protocol vs HTTP) and by style > (single-pass vs multi-round challenge/response). All credential work is > asynchronous (CompletableFuture), so a slow token refresh can no longer block > the Netty event loop — the client-side counterpart to PIP-97's broker-side > async > work. It also adds a framework-managed PulsarHttpClient SPI so auth plugins > such > as OAuth2 and Athenz share the runtime's HTTP/DNS resources instead of > spinning > up their own clients, and a purpose-driven PulsarTlsMaterialProvider SPI that > replaces PIP-337's PulsarSslFactory / PulsarSslConfiguration. Compatibility > bridges in both directions keep the v4 surface and existing third-party > plugins > working unchanged. > > Broker-side authentication is intentionally out of scope and will be addressed > in a sibling PIP with the same design principles. The feature targets Pulsar > 5.0. > > Full proposal: > https://github.com/lhotari/pulsar/blob/lh-pip-478-v5-client-async-auth-and-tls-material-provider/pip/pip-478.md > PR: https://github.com/apache/pulsar/pull/25890 > > Looking forward to your feedback! > > Lari >
