Hi all, I found the previous PIP-484 in the Apache Pony Mail dev list, so I've updated the number to 485 accordingly in the PR.
Apologies for the confusion. Regards, Pavel Zeger 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 >
