Version 3.2 Documentation

Publish/subscribe security

Security of publish/subscribe-based processes and workflows should be examined on several levels:

  • Making sure that API clients have the correct credentials (authentication)
  • Making sure that API clients have permissions to access topics (authorization)
  • Data in flight
  • Data in rest
  • Defaults
  • Runtime access to Zato Dashboard and servers

Authentication and authorization

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.

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, e.g. /customer/*/new may resolve to /customer/uk/new or /customer/de/new 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.

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 assigned. 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.

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

Data in flight and in rest

The load-balancer in front of pub/sub Zato servers may be configured to use TLS which will force endpoints to encrypted the communication. Servers within a Zato cluster may be configured to use TLS

Data in rest is not encrypted, be it in RAM or in persistent storage - if encryption is needed, endpoints should either implement it themselves or a hook service can dynamically encrypt data received from publishers. Alternatively, the SQL database that the message broker uses for persistent storage may be configured so that it keeps data in rest encrypted.

Defaults

  • In accordance with the overall architecture of the platform, there are no default passwords or secrets - everything is always automatically generated and set to random values (UUID4).

  • Topic /zato/demo/sample is a demo topic created for illustration purposes.

  • Endpoint zato.pubsub.demo.endpoint is created to make it easy to access the demo /zato/demo/sample topic. This endpoint has access to that one topic only.

  • Endpoint zato.pubsub.default.internal.endpoint is created - this is used internally by Zato. The endpoint has full access to all topics.

Access to Dashboard and servers

  • Users with credentials to web-admin can manage all pub/sub objects, including ability to browse messages, delete them or to publish new ones.

  • Users with SSH access to Zato servers are able to access all pub/sub objects for any purposes.