Publish/subscribe security

Authentication

All REST API operations require HTTP Basic Authentication. Each client must provide valid credentials with every request to publish messages, subscribe to topics, or retrieve messages from queues.

Each API client in publish/subscribe is represented by an endpoint. REST and WebSocket endpoints are associated with a security definition - access to pub/sub servers will not be allowed unless credentials are correct when such an endpoint makes use of pub/sub APIs. Python and File transfer publishers do not need any credentials - they can always publish messages to any topic.

To create credentials, go to Security → HTTP Basic Auth in Zato Dashboard and fill out the form as in the example below:

Authorization

On successful authentication, access permissions are checked to confirm if a particular endpoint can publish messages to a given topic or receive messages from it.

Authorization is based on patterns - for each endpoint, a list of patterns can be created, each pattern potentially resolving in run-time to one or more topics.

It is possible to configure an endpoint so that it does not have any permission assigned. For instance, it may not have permissions for publication, subscription or none at all.

Note that when you use self.publish from your Zato services, you can always publish to any topic. That is, your services are always authorized to use any topic you want.

Pattern-based permissions

Publication and subscription patterns let you declare what topics each endpoint should be allowed to publish messages to or to receive them from.

A single access pattern may cover multiple topics, possibly including ones that do not exist at the time of an endpoint's creation, and it is customary to arrange topic names and their respective permission patterns in hierarchical structures, going from the broadest elements to the more specific ones using a dot for the separator.

Wildcard syntax

The wildcard * matches any characters within a single topic segment and stops at dots.

Wildcards can appear anywhere in a pattern, including the beginning like *.orders, or middle like orders.*.new.

Pattern examples

Supposing there are several topics:

It is possible to create various access patterns depending on the intended purpose:

Pattern evaluation

Pattern evaluation follows alphabetical order with exact patterns evaluated before wildcards, and the first match wins. For example, if you have patterns transaction.priority and transaction.*, a message to transaction.priority will match the exact pattern first, and evaluation stops there.

Patterns are sorted alphabetically, with wildcards evaluated last. Given patterns orders.*, orders.urgent, alerts.*, alerts.critical, the evaluation order is:

1. alerts.critical (alphabetical, no wildcards)
2. alerts.* (alphabetical, has wildcards)
3. orders.urgent (alphabetical, no wildcards)
4. orders.* (alphabetical, has wildcards)

Separate publication and subscription patterns

Patterns are specified separately for publications and subscriptions and there must be a matching role for the pattern to be taken into account at all. If an endpoint has publication rights to a topic but its role is a Subscriber then it will not be able to publish the message despite correct access rights. This can be used to temporarily revoke publication or subscription rights without a need to redefine permissions.

Permissions for publication are checked each time an endpoint tries to publish a message to a given topic. If there is a pattern that resolves to this topic, the message is accepted. Otherwise, the publication is rejected.

For subscriptions, patterns are resolved when a message is published. That is, at the moment of a publication, all subscribers whose subscription patterns match the name of the topic the message is published to are taken into account and only these subscribers will receive the message.

Getting started with EDA

Using EDA