Skip to main content

Multi-tenancy

Multi-tenancy refers to a software architecture principle where a single instance of a software application serves multiple users or tenant organizations. Each tenant's data is isolated and remains invisible to other tenants, despite being stored on the same physical hardware. This approach maximizes resource sharing and efficiency, reduces costs, and simplifies maintenance and updates across the system.

Akkess support for multi-tenancy​

Akkess is specifically designed to streamline the integration of multi-tenancy support into your existing system architecture. The platform's core functionality revolves around the use of an Access token, which, when utilized by a user to access a service, enables the service to retrieve all necessary information for data management tasks. This encompasses querying, storing, and organizing data in a manner that is both secure and efficient.

A fundamental aspect of Akkess architecture is its robust mechanism for ensuring data isolation, which guarantees that information belonging to different tenants is kept separate. This separation is critical for maintaining the privacy and integrity of each tenant's data, thus ensuring that the multi-tenant environment operates without compromise.

Through Akkess, developers can easily implement a system that supports multiple tenants, enhancing the scalability and flexibility of their services, while upholding stringent security standards.

How does it work?​

When a caller issues an Akkess access token, the token is specific to a particular tenant and should only be used to access that tenant's data. When the token is presented to a service, the service can use the information contained within the token to evaluate the caller's access level and construct a command to its logic and database that only affects or returns allowed data.

Token example​

{
  "jti": "0d2786f7-aa40-4231-a6ce-4eccbd95a491",
  "iss": "https://api.akkess.io/authorization/v1",
  "sub": "65cb6159e377923e328b7382",
  "aud": "63c65dee83abd41be9f61108", // The tenant Id for tenant tokens
  "exp": 1707831173,
  "iat": 1707827573,
  "acc": "63c65dee83abd41be9f61104", // The account Id
  "app": "63c65dee83abd41be9f61106", // The application Id
  "tid": "63c65dee83abd41be9f61108", // The tenant Id
  "ars": [
    {
      "r": [
        "BASIC_USER"
      ],
      "n": [
        "65cb60ffe377923e328b7380"
      ]
    }
  ]
}

If the token is used when calling a service, the service can use the information in the token to evaluate which tenant the caller belongs to. The service can then use this information to for example enrich data stored to be able to add data separation between tenants.

There are three levels available in the token:

  • Account - The highest level in Access. An account can have several applications and tenants.
  • Application - The application level is used to separate data between different applications.
  • Tenant - The tenant level is used to separate data between different tenants.

Database table with tenant separation​

A table containing messages. The message belongs to a user and the user belongs to a tenant.

| message_id        | user_id         | tenant_id                 | message                | 
--------------------------------------------------------------------------------------------
| 1                 | u-1             | 63c65dee83abd41be9f61108  | Hello world            |

The service can now take the tenantId from the token and use it to query the database to only return messages that belong to the tenant.

SELECT * FROM messages WHERE tenant_id = '63c65dee83abd41be9f61108' AND user_id = 'u-1';

This is a really easy and robust way to implement multi-tenancy in your system.

You could even enrich your data with accountId and applicationId to be able to separate data on a higher level. Could be good for generating reports, billing, metrics etc.

TenantId could also be a good source for indexing and partitioning data in the database.

A tenant does not necessarily have to be a company. For example, it could be an environment, like production, staging, test, etc. This is an easy solution for letting different environments share the same runtime system.

Copyright © 2019 Akkess