Multi-tenant authentication strategies

[databrecht]

@armando

I have an application with several customers. I want to give each customer an isolated child-database, due the benefits of true data isolation, better performance and less complex queries that child-databases provides vs having all the customers in the same DB.

I just wanted to point out that in terms of performance, it might be neglectable. A collection scales and should not become slower when the amount of data in it increases. The other two reasons could be a good motivator. The data separation is indeed very clean but there are also limitations to this approach:

• You need to deal with two secrets a token for the master user database and a key for the child database, that could also be perceived as an advantage in some scenarios.
• You won’t have transactions/joins over multiple databases.
• You can’t take advantage of Identity() in ABAC since you can’t transfer the Identity() of your user token to another database.

If any of these are a requirement, it might be easier to link your documents to a user reference and keep them in one database. You could also opt to put each ‘customer’ in different collections and programmatically determine what collection the query is going to address. A less clean separation but you could do transactions over these collections. If not, multiple databases would be a fine choice.

@armando

What’s the recommended way to handle the authentication in this scenario? Storing the child-databases admin keys along the users_collection data is the only way? is there a better way or a better strategy?

I can’t say there is one recommended way, each application is different. I did want to let you know that you do not necessarily have to store the actual key (not sure if that was the idea), you could perfectly store the database references that you could obtain with Database(“your database”) and get a key on the fly in your backend via an Admin key on the parent database and/or reclaim that key once you ‘log out’ that specific user via Delete. The disadvantage is that you need a powerful key in your backend, the advantage is that you don’t need to store keys again which are already stored by FaunaDB in a secure way. Storing them as plain text in a document is not ideal.

Finally, as mentioned in the very related post that just came in: Does the multi-tenancy model support syncing schemas and aggregating across child databases? - #2 by databrecht, I’ll try to get a better answer and free some time to write a comprehensible article on the pros and cons of each approach.