The highly customizable Axinom Mosaic platform is a multi-tenant service offering. It uses tenants and environments that you can manage in the Environment Administration Portal.

Environments

As a multi-tenant service offering, the Mosaic Platform gives you the ability to maintain a list of tenants (based on your contract). For each tenant that you own, you are assigned the role of a tenant administrator and gain access to maintain any number of environments within those tenants. In this article, a tenant refers to a grouping of environments.

To perform any environment administration tasks, you can use the Environment Administration Portal. Using the same portal, you may also introduce more tenant Administrators when needed.

Within each environment you maintain, you can enable the Managed Services you want to use, and disable them when you no longer plan on using those services. The Core Services, however, are mandatory for each environment. They are enabled automatically during environment creation and cannot be disabled afterwards.

You can create, maintain, and delete environments in the Environment Administration Portal.

Environment Isolation

All resources which are generated within the Mosaic Platform have an environment-level isolation. The diagram below visualizes the relationships of some of the top-level entities to an environment.

Tenant(Customer)EnvironmentServiceUserServiceAccount1***1*1*

For example, the same user with the email address abc@domain.com may exist in the environment ABC, as well as in the environment XYZ as we maintain storage isolation per environment. They would never conflict with each other.

The records which are created by the user abc@domain.com (i.e. an uploaded image) in the environment ABC are not visible to the same user in environment XYZ.

Multi-Tenant Managed Services

Once you enable a managed service for an environment, the service starts accepting requests from that environment (originating from a User or a Service Account). The requests can take multiple forms. These could be HTTP requests if they are, for example, invoking a service’s GraphQL endpoint. It could also be a RabbitMQ message posted to an exchange when using asynchronous messaging to make the requests. However, the URL endpoints of these Managed Services always remain the same (as they are multi-tenant aware services), and you do not receive new URLs for each managed service that is enabled for an environment.

Therefore, each managed service considers the contents of the access-token attached to every request to decide if the request should be honored or not. For example, when an access-token with the below JWT is sent to a managed service, the service first checks if the tenantId & environmentId present in the payload represent an environment where the specific service is enabled.

{
    "tenantId": "b0f7081a-8097-455d-8216-a3ff680855e1",
    "environmentId": "70cbf548-3669-4fbf-a333-ec789e188e67"
    ...
}

If this first check is successful, then the already mentioned environment isolation logic kicks in on the persistent storage of the service. The data records belonging to the specific tenantId and environmentId are isolated and made available to be accessed by the request.