I think it's a valuable change to support such a feature. For the authentication and authorization interfaces on the broker side, I have a plan to follow up on "PIP-478: Asynchronous v5 client authentication plugin interfaces and TLS material provider plugin interface" with changes to revisit the broker-side authentication and authorization interfaces (marked as "out of scope" for PIP-478, https://github.com/lhotari/pulsar/blob/lh-pip-478-v5-client-async-auth-and-tls-material-provider/pip/pip-478.md#out-of-scope). This plan about doesn't block PIP-484 since the authnz implementations would be refactored as part of such a possible improvement for v5.
-Lari On 2026/06/13 09:54:01 Pavel Zeger wrote: > Hi all, > > I'd like to open the discussion on *PIP-484: Configurable mTLS principal > mapping*. > > PR: https://github.com/apache/pulsar/pull/26021 > > *Problem*. > Pulsar's built-in TLS auth provider (AuthenticationProviderTls, in > pulsar-broker-common) derives a client's role only from the certificate's > first Common Name (CN), and the extraction is hardcoded - if the CN is > empty or missing, authentication fails outright. > That's a poor fit for two increasingly common deployments: > > - Enterprise PKI, where the identity lives in another DN field (an OU, > emailAddress, or the full DN) and re-issuing certificates just to populate > the CN isn't practical. > - SPIFFE/SPIRE and service meshes, where workload identity is a URI SAN > (spiffe://...) and the CN is intentionally empty - those certificates are > rejected today even though they carry a valid, cryptographically-bound > identity. > > Apache Kafka solves this declaratively with ssl.principal.mapping.rules > (KIP-371). Pulsar has no equivalent for the built-in provider; writing a > custom AuthenticationProvider is a high bar for what should be a few lines > of config. > > *Proposal* (backward compatible). > Add two config options to AuthenticationProviderTls: > > - tlsCertIdentitySource - choose the raw identity: CN (default), DN, or > SAN:URI|DNS|EMAIL. > - tlsAuthPrincipalMappingRules - an ordered list of Kafka-style > RULE:<regex>/<replacement>/[LU] (plus DEFAULT) rules that transform the > extracted identity into the final role. > > With both unset, behavior is identical to today (first CN, fail on empty > CN), so existing deployments are unaffected. The change stays within the > existing String authenticate(...) contract - no wire-protocol, client, or > SPI change. > > Points I'd especially like feedback on: > > 1. Reusing Kafka's rule grammar verbatim vs. a Pulsar-native syntax. > 2. The opt-in behavior change where SAN/DN sources let empty-CN > certificates authenticate. > 3. SAN selection when a certificate carries multiple SANs of the same type > (currently "first in cert order", disambiguated by a rule). > 4. Making sure the new keys are honored by both the broker and the Pulsar > Proxy (the proxy config plumbing is called out explicitly in the PIP). > 5. Whether multi-valued roles / group extraction should be in scope here or > left to a separate PIP. > > The full proposal is in the PR (pip/pip-484.md). > > Thanks, > Pavel Zeger >
