Add multi tenancy to the application

[shailee-m]

1. App architecture
2. User login registration
3. User rights management

Considerations

• Can a user belong to multiple tenants?
• How to access a specific tenant? Subdomain?
• How to separate tenant data? ForeignKey? Database partition?

This should be compatible with our Mobile Client task #546

[shailee-m]

Approaches to multitenancy:

1. Separate database for each tenant:

There will be a tenant manager collection which enlists all tenants of the platform. Each tenant will have a separate database created when the tenant is registered. The users collection can either be separate for each db or if a user can be a member to multiple tenants there can be a shared collection.

Pros:

1. Physical separation of data can be achieved
2. Current tenant can be stored in login information (to identify the source of data). No modifications to existing queries, publications,collections required

Cons:

1. Cannot use meteor's minimongo. Requires creation of a specific mongo module that connects dynamically to a collection based on the current tenant information.
2. Not sure about the integrity of data as I found a few forums that talk about difficulty in maintaining pub-sub

• https://forums.meteor.com/t/connect-between-multiple-databases-without-restarting-meteor-server/40612

2. Having a common database for all tenants.

There will be only one database having a tenant collection, in addition to the exisiting collections. Each of the existing collection will have and extra key called the tenantID which distinguished the data tenantwise.

Pros:

1. Better data manageability.
2. No tweaking of current meteor mongo system. Pub-sub integrity can be maintained

Cons:

1. Data will be in a shared environment
2. Changes to collection schemas publication and method queries to filter data according to domain

[shailee-m]

For user login and registration:

1. Have a base url where the tenants can register their organisations. From then on they can login/regsiter new users on a subdomain url. (Example, The tenant google will register itself at gerilife.com, where as users of tenant google will register/ login at google.gerlilife.com).

   • Alternatively, each for tenant a dynamic route can be created. I.e. the tenant google will have routes like localhost:3000/google/residents, localhost:3000/google/homes.

2. No separation of tenant by domain. While registering the user sets a domain. Then for tenant distinction during login, the following methods can be used:

   • Add an input field or a dropdown selection field (of all existing tenants) where in the user can mention/select their domain
   • User can set a username while registration and the login credentials provided to user can be username@domain

In a url domain based approach there will not be major changes to the existing login module whereas using the second approach the login and registration modules will require refactoring.

Additional points:
Can introduce a tenantManager user role whose role is limited to managing the tenancies.

[shailee-m]

@brylie

[brylie]

Thanks @shailee-m. We will discuss these options.