Skip to content

Point-to-Point Secure Messaging (PSM)

Point-to-Point Secure Messaging (PSM) icon
  • Category: Data & Infrastructure
  • Primary environment: MaaS Consumer, MaaS Provider
  • Documentation focus: Design reference
  • Maturity: TRL 4–5 (first release, M18)
  • Related architecture docs: Reference Architecture Guide, Environments

The Point-to-Point Secure Messaging (PSM) solution enables safe and efficient communication through an MQTT-based exchange model. Its structure is built around the following components:

The D5.2 usage viewpoint defines roles, permissions, constraints, a role-task matrix, and a use case diagram for this solution.

  • Message Sender: Write messages; constraint: Can only message the available topics
  • Message Receiver: Read messages; constraint: Can only read from available topics
  • Sys Admin: Add Users, Delete Users, Edit Users, Send messages, Get messages, create topics, configure topics, delete topics

Point-to-Point Secure Messaging use case

Use-case diagram extracted from MaaSAI deliverable D5.2.

PSM combines topic management, authentication, producers, consumers, and MQTT brokering to provide secure point-to-point exchange. The functional view shows how messages flow from producers to consumers under controlled topic administration and trusted transport.

Point-to-Point Secure Messaging functional components

Functional components diagram extracted from MaaSAI deliverable D5.2.

The MQTT Broker is the central intermediary that manages messages from Publishers to Subscribers. It receives messages from Publishers, filters them by topic, and sends those messages onward to Subscribers. This core component ensures reliable message routing along with security on the system. The MQTT Broker is containerized and, thus, scalable, easy to deploy, and flexible for cloud and edge deployments. The broker is partly stateful since the persistence of message queues is file-based. This ensures a reliable delivery of messages.

Publishers are MQTT clients responsible for sending messages to specific topics within the MQTT Broker. These clients are designed to be highly flexible; hence multiple software clients are available in various programming languages, which comply with different use cases. Stateless by design, the Publishers send data to the broker without persisting any state locally. They depend on the broker for message routing and delivery.

Subscribers are MQTT clients that listen for messages on specific topics they have subscribed to. Once a message is published to a topic, the Subscriber receives it and processes the information accordingly. Like Publishers, Subscribers are stateless and don’t retain message data once it has been processed. They do handle state temporarily in processing messages but do not persist data beyond the immediate interaction with the broker.

The PSM architecture is designed around a modular, containerized framework that ensures scalability, flexibility, and efficient deployment. The solution integrates various components that facilitate secure, real-time communication between producers and consumers. The core components of the PSM architecture are:

The MQTT Broker serves as the central hub for message communication in the PSM solution. It facilitates secure, topic-based message routing between producers and consumers, ensuring efficient message delivery. Containerized within a Docker environment, the broker provides reliability and flexibility in deployment, handling both transient and persistent messages as required.

Point-to-Point Secure Messaging architecture

Architecture diagram extracted from MaaSAI deliverable D5.2.

PSM follows a lightweight service-oriented architecture composed entirely of open-source technologies.

CategoryTechnology
MessagingEclipse Mosquitto 2 as the MQTT broker; MQTT as the messaging protocol.
IdentityKeycloak for centralised identity and access management.
SecurityOpenSSL for encryption, key handling and certificate management; TLS and mutual TLS (mTLS) on all channels.
ContainerisationDocker and Docker Compose.
Licencepermissive open-source licences — Eclipse Public License (EPL) for Mosquitto and Apache License 2.0 for Keycloak; the integration repository will be finalised under an open-source licence matching consortium agreements before the next release.

PSM acts as the trusted messaging layer of MaaSAI, connecting industrial partners, edge services, monitoring applications, analytics services and the platform’s autonomous agents (WP6), which use it for real-time negotiation and telemetry exchange. It supports multiple client types, including IoT devices, desktop applications, mobile applications and other MQTT-enabled services. The current implementation depends on four external services: the Keycloak identity provider, Docker Engine, Docker Compose and the OpenSSL cryptographic utilities.

  • Clients first obtain a JWT access token through Keycloak’s REST endpoint (OpenID Connect token request); the returned Bearer token is passed as the MQTT password when connecting to the broker.
  • Publish/subscribe operations use standard MQTT commands (mosquitto_pub / mosquitto_sub) over TLS port 8883, presenting a client certificate, key and CA file alongside the JWT.
  • Topic-level authorisation is enforced by the broker according to roles assigned in Keycloak; unauthorised subscription attempts are rejected with an access-denied response.
  • The Keycloak administration UI is used to create users, define roles and configure topic permissions without modifying the broker configuration.

PSM is infrastructure without an end-user UI; the figures below show its architecture model and a functional validation:

PSM architecture diagram

Overall architecture model of the PSM component — MaaSAI deliverable D8.1.

PSM MQTT broker validation

Functional validation: authenticated publish/subscribe through the MQTT broker — MaaSAI deliverable D8.1.

PSM is deployed as a containerised environment orchestrated with Docker Compose, consisting of two primary services: the Keycloak identity and access management server, and the Mosquitto MQTT broker with integrated JWT validation and mTLS support.

RequirementSpecification
OSLinux (Ubuntu recommended)
CPU2–4 vCPUs
RAM4–8 GB
Storage4 GB

Docker Engine 24.x or newer and internet connectivity are also required. Key broker parameters include the TLS-secured MQTT port (8883), the CA and server certificate/key paths, require_certificate to enforce mutual TLS, and the JWT authentication plugin with the Keycloak JWKS URI used to validate tokens.