Skip to content

Access-Controlled Topic

Topic access policy — instantiates Topic-Brokered Event Distribution

A topic whose publish and subscribe rights are governed by an explicit access policy, so only authorized producers can emit to it and only authorized consumers can see it.

An Access-Controlled Topic binds an authorization policy to a subject: attached to the topic is a statement of who may publish and who may subscribe, which the broker enforces on every attach and every emit. Its distinguishing concern is confidentiality and provenance of the event stream itself — not which events a subscriber wants (a filter) but which a subscriber is permitted to see, and not merely that a message is well-formed but that it came from an authorized publisher. In brokered pub/sub the broker is a powerful shared intermediary through which sensitive events flow; the access-controlled topic is what keeps that intermediary from becoming an open channel where any connected party can read a stream or forge into it.

Example

A hospital publishes lab results to clinical.lab-results, a stream containing protected health information. The topic carries an access policy: only the laboratory information system holds publish rights, and only the EHR, the ordering physician's service, and the audit archive hold subscribe rights. When an analytics team's connector tries to subscribe "just to count throughput," the broker denies the attach — the connector is not on the policy — and the denial is logged.

Because the events are sensitive even in transit, the topic is also configured so payloads are encrypted end-to-end between the lab system and authorized subscribers, so that even an operator with access to the broker's storage cannot read a result. A would-be publisher that lacks the lab system's credential cannot inject a forged result at all. The topic's identity is inseparable from its policy: to exist on this subject is to have been authorized for it.

How it works

  • Policy bound to the subject. Each controlled topic carries an explicit allow-list (or role/scope grant) for publish and for subscribe, evaluated by the broker at connect and emit time.
  • Authenticate the publisher. A producer must present a credential establishing it as an authorized source before an emit is accepted, so downstream consumers can trust provenance.
  • Gate visibility on subscribe. An attach request is checked against the subscribe policy; unauthorized parties are refused and cannot enumerate or read the stream.
  • Reduce trust in the broker itself. Where the stream is sensitive, payloads can be encrypted or signed end-to-end so a compromised or curious broker sees ciphertext, not content.

Tuning parameters

  • Authorization model — per-identity allow-lists versus role- or scope-based grants. Fine-grained lists are precise but heavy to maintain; roles scale but can over-grant.
  • Publish vs. subscribe asymmetry — how tightly each side is controlled. Many topics need one trusted publisher and many readers; others invert it.
  • Broker trust level — treat the broker as trusted (policy enforcement only) or untrusted (add end-to-end encryption and message signing). Less trust means stronger safeguards but key-management cost.
  • Grant lifetime — long-lived credentials versus short-lived, rotated tokens. Short lifetimes limit the blast radius of a leak but add renewal machinery.
  • Denial visibility — whether an unauthorized party learns the topic exists at all, or is refused opaquely. Opacity resists reconnaissance but complicates legitimate debugging.

When it helps, and when it misleads

Its strength is that it makes the broker safe to share for sensitive streams: authorization travels with the subject, provenance is established at publish, and — with end-to-end protection — even the trusted intermediary is prevented from being a single point of total exposure, honoring least privilege[1] rather than "everyone on the bus can read everything."

It misleads when access control is confused with the weaker mechanisms around it. A content filter that happens to exclude an event is not protection — the subscriber can widen the filter; only the topic policy actually withholds. Coarse roles quietly become over-grants that no one audits, recreating the open channel the mechanism was meant to prevent. And policy at the broker does nothing about a compromised broker unless end-to-end protection is added — teams often assume "it's access-controlled" covers a threat model it doesn't. The discipline is to separate may-see (this mechanism) from want-to-see (the filter), review grants against least privilege on a cadence, and match the trust level to the real threat rather than assuming the broker is safe.

How it implements the components

  • authorization_and_visibility_policy — it carries and enforces the allow/deny rules for who may subscribe to and read the topic, deciding visibility rather than mere relevance.
  • publisher_authority_profile — it authenticates producers and admits emits only from authorized sources, giving consumers trustworthy provenance.
  • broker_compromise_safeguard — where configured for end-to-end encryption or signing, it limits what a compromised or over-trusted broker can read or forge.

It does not decide which permitted events a subscriber actually wants (Content-Based Subscription Filter), route or fan the events out (Message Broker, Fan-Out Exchange), or validate the message's structure (Schema Registry).

References

[1] The principle of least privilege — granting each party only the access its function requires and no more. Applied to a topic, it argues for withholding subscribe rights by default and granting them explicitly, rather than making streams readable to everyone attached to the broker. ↩