You need to properly design it, look at how you are going to separate your tenants when it comes to RBAC, data, etc. But you need to do that for every platform you choose.
If you have a monolithic design, and (for example) you want to be able to have the same username for every tennant (say 'admin'), it obviously needs some changes. Which depend on your architecture. For example, are you going to use a tennant_id in every table to indicate whos data it is? Or are you going to use different tables for each tennant, for example prefixed with a tennant name or id?
In our case, we have no data in the frontend, everything is in the backend and accessed via an authenticated and encrypted REST API.
We use Keystone (from the cloudstack project) to provide us with authentication and autorisation. It already has a multi-tennant architecture, can be used as SSO platform, and links into authentication, authorisation and encryption of our CEPH storage. It provides a client and tenant UID that we use througout the system.
We use Fuel REST applications/(micro)services for the test of the backend. We are currently designing a rewrite to an event sourcing / CQRS architecture to provide better scaling and offsite replication.
The framework bit of this rewrite is intended to become Fuel v2 (if all goes well).
Donate
