I read that, but it adds a lot of complexity and there are too many limitations. Worse, tenant db are then strongly dependent on the central database (sequences, dynamic attributes, entity log - not options in our case…) which defeats IMHO the purpose of isolating tenant in their database.
Which is why we prefer a solution of routing once and once only, at login time. Then the user is connected to a standard CUBA database with no drawbacks at all.
That lets the routing problem to solve at login time, whatever the solution you need a login tiers/module, a CUBA app or not. I was thinking about a solution along these lines :
- central schema/db where some process replicates credentials from other schemas/db, mapping user to tenant along the way
- user connects to the CUBA app in central schema/db
- user submits logging, app validates against replicated credentials
- if ok CUBA resets its connection to the correct tenand schema/db
There is still a central schema/db needed like in the proposed solution but the complexity and the risk is largely reduced, and restricted to login time. However this needs CUBA to be able to reset its main connection without restarting the container, I do not measure the difficulty of that.
A variation of this solution could use routing, instead of switching main connection into a single CUBA app, we could have 2 apps : one for login and one for all tenants. Once the login app has validated the login against the tenant app (could be a REST call for instance), it routes the user to the tenant app url with a session ID (no additional login) and with an url parameter defining the tenant schema/db. In that case the central schema only needs to know which user for which tenant, no replicated credentials. That also needs CUBA app initial controller to use this parameter to initialise its database connection.
That would be nice if CUBA platform supports something like this login model at some point in time, as this is a recurrent problem for SaaS applications.