Architecture

PrivMX Bridge: Fundamentals

Within PrivMX Bridge there are fundamental concepts defining it's architecture:

Solutions

A Solution represents an isolated data environment, designed for specific applications or IT solutions. Each Solution is completely separate from the others, to ensure that data, user interactions, and Contexts do not leak between them.

A key architectural feature is that PrivMX Endpoint requires a specific Solution ID during connection. As a result, the Endpoint must first identify and request access to a particular Solution to interact with its internal resources.

Key Features

• Solution Separation: All the data inside Solutions is strictly isolated. There is no automatic sharing or access between Solutions, even though they are hosted within the same PrivMX Bridge instance.

• Creation and Management: Each new Solution is created with its own unique ID, which is provided while connecting to PrivMX Bridge.

• Security Model: Each Solution operates with its own Contexts and keys, ensuring strong data integrity and separation. The Solution itself does not manage or store information about its users; this is delegated to the Contexts.

• User Management: Importantly, the Solution itself does not maintain a global user list. Users are associated only with the specific Contexts. This enhances the security and privacy model by minimizing exposure to unnecessary information about other Contexts or users.

In summary, a Solution provides a compartmentalized space for managing resources relevant to specific IT environments or applications, ensuring clear and strict separation of data.

Contexts

Contexts provide another level of organization and are crucial for user management and data access control. Each Context represents a distinct space within a Solution, where users can be assigned specific roles and permissions using public keys. Every Context has to be assigned to a Solution.

Key Features

• Public Key Assignment: a Context is defined by the developer (it could be referring to a specific app feature or area). Users are associated with a Context by registering their public keys through the REST API provided by PrivMX Bridge.

• User Authentication and Authorization: once users are assigned to a Context, they can authenticate themselves using their private keys. Authentication involves the verification of a digital signature, which is generated by the user’s private key, and verified using their public key stored in the Context. It is a seamless process for the developer, as it is fully handled by PrivMX Endpoint.

• Access Control: user permissions within the Context are determined by Access Control Lists (ACL). These permissions define the actions users can perform within the Context, such as creating, updating, or accessing resources like Threads, Stores, and Inboxes. The ACL model ensures that each user has appropriate rights based on their role and the requirements of a particular Context.

• Resource Creation: Within a Context, authorized users can create different types of encrypted tools:

  • Threads: Secure chat spaces where users can exchange messages. Threads are end-to-end encrypted and accessible only for users with proper permissions.
  • Stores: Encrypted containers for file storage, allowing non-sequential access and efficient file streaming.
  • Inboxes: Containers used for one way communication with external users, useful for scenarios like receiving encrypted data from web forms.

The diagram below visualizes the structure and corelation between Contexts and Solutions: