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
