Authorization

After a client passes authentication, FlowMQ runs an authorization check on every operation it performs — publish, subscribe, consume, and so on — allowing only the operations that policy permits.

Authorization uses a policy-based model: each policy declares which principals (the identities established at authentication) may perform which actions on which resources, and whether to allow or deny. An explicit DENY always overrides ALLOW. Authorization is available on all plans, and both the authorization configuration and its policies are isolated per project, so projects do not affect one another.

Authorization is managed from the Dashboard's Authorization page: enable authorization, then create and manage policies.

Enable Authorization

In the authorization configuration section of the Authorization page, set the two options and click Save configuration:

Setting	Description
Enforce authorization policies	Whether to run policy checks. When off, policies can still be managed but every request is allowed without checks. Off by default, so FlowMQ works out of the box.
No-match behavior	How requests that match no policy are handled: Deny unmatched requests (the safe default) or Allow unmatched requests.

Changes take effect immediately and are persisted — no restart required.

TIP

On protocols with no authenticator (anonymous access), if Enforce authorization policies is on and No-match behavior is set to deny, every operation is denied when no policy matches. In that case, set No-match behavior to allow, or write an explicit policy that allows the anonymous principal.

Create a Policy

On the Authorization page, click Add Policy to open the wizard, which has four steps: Basic Info, Resources, Actions, and Review.

Basic Info

Set the policy's basic attributes and choose which principals it applies to.

• Policy Name: a unique identifier, used later to view and manage the policy.
• Description: an optional note.
• Effect: Allow (ALLOW) grants access, or Deny (DENY) blocks it.
• Principals: choose who the policy applies to.
  • All Principals: applies to everyone.
  • Specific Principals: match by criteria, combining any of the following (criteria are AND-ed; a blank criterion adds no restriction):
    • Principal IDs: one per line, supporting glob wildcards.
    • Authenticators: one per line, in type:name form (e.g. password:builtin) — to scope the policy to "principals authenticated by a specific authenticator only".
    • Attributes: a key plus values (comma-separated). Multiple attributes are AND-ed, and a single attribute's values are OR-ed; attributes come from a password user or are issued by Webhook authentication.

Resources

Add one or more resources to declare which resources the policy applies to. Each resource is a Resource Type, a Match Mode, and a Resource Pattern.

Resource Type uses each protocol's own terminology:

Resource type	Protocol	Meaning
Topic	MQTT	MQTT topic
Stream	Kafka	Kafka topic
Queue	AMQP	AMQP queue
Exchange	AMQP	AMQP exchange
Consumer Group	Kafka	Kafka consumer group

INFO

Authorization is currently enforced on the publish/subscribe/consume paths of MQTT and Kafka. The queue, exchange, and consumer-group resource types are already part of the model, and enforcement for them is being rolled out.

Match Mode determines how the Resource Pattern matches the requested resource name. Most policies use Filter; choose Literal only when a resource name must match exactly, with + and # treated as ordinary characters.

• Filter (default): interpreted as a topic filter, with + and # expanded per MQTT wildcard rules, and supporting the placeholders below. For an Allow policy, the filter must fully cover the request's scope to permit it; for a Deny policy, it blocks any request it overlaps. For example:

  • Allow + Filter foo/+ does not permit subscribing to foo/#: foo/# can also match foo/a/b, beyond the scope of foo/+.
  • Deny + Filter secret/# blocks subscribing to #: the two overlap.

• Literal: matches the Resource Pattern exactly as a plain string, treating + and # as literal characters. It is typically used to precisely forbid one overly broad subscription — for example, allowing the foo/ subtree while forbidding subscribing to the whole subtree at once:

  Allow    Filter    foo/#
  Deny     Literal   foo/#

  A client may then subscribe to foo/+, foo/bar, and so on, while foo/# is blocked precisely (explicit deny wins).

The Resource Pattern may contain placeholders that are expanded per connection at evaluation time, so a single policy can express rules like "each user may only access resources named after themselves":

Placeholder	Meaning
${principal.id}	The principal identifier (the identity established at authentication)
${principal.authenticator}	The name of the authenticator that authenticated the client
${principal.authenticatorType}	The authenticator type (e.g. password, webhook)
${principal.attributes.<name>}	A named principal attribute (e.g. one issued by Webhook)
${connection.clientId}	The protocol-level client identifier
${connection.sourceIP}	The client IP
${connection.protocol}	The protocol name

For example, a Resource Pattern of user/${principal.id}/# lets each principal access only resources prefixed with its own ID. A placeholder that resolves to nothing expands to an empty string.

TIP

A shared subscription is authorized by its underlying topic filter, exactly like an ordinary subscription.

Actions

Select the operations the policy controls: check All Actions, or pick individual actions.

Action	Description
All Actions (ALL)	Matches every action
Write (WRITE)	Write / produce (publish, Produce)
Read (READ)	Read / consume (subscribe, Fetch)
Create (CREATE)	Create a resource
Delete (DELETE)	Delete a resource
Describe (DESCRIBE)	View metadata
Alter (ALTER)	Modify configuration
List (LIST)	List resources

How protocol operations map: MQTT publish → Topic / Write; MQTT subscribe → Topic / Read; Kafka Produce → Stream / Write; Kafka Fetch → Stream / Read; Kafka create or delete topic → Stream / Create or Delete.

Review

On the Review step, check the effect, principals, resources, and actions, then click Create Policy. The policy takes effect immediately — no restart required.

How Decisions Are Made

For each operation, FlowMQ decides in the following order:

1. If Enforce authorization policies is off, allow directly.
2. Among the policies matching this principal and resource, if any one is a DENY, deny immediately (explicit deny wins).
3. If a matching ALLOW policy exists, allow.
4. If no policy matches, decide by the No-match behavior: deny or allow.

Manage Policies

The policy list on the Authorization page provides View, Edit, Duplicate, Enable / Disable, and Delete actions; each policy can be enabled or disabled individually without deleting it. Authorization configuration and policies are isolated per project — switch projects to view and manage the corresponding rules.

Cross-Protocol Resource Semantics

Authorization resources are independent per protocol: MQTT uses Topic, Kafka uses Stream, and the two do not affect each other. Cross-protocol interoperability is configured through topic filter bindings, not by sharing authorization resources.