3

I am building a multi-tenant application in a shared database model. I would like to encrypt sensitive data so that only a particular tenant could have access to his data. What is the best mode to keep/provision passwords and where should I keep them in a multi-tenant environment?

Dan
  • 163
  • 4
  • I was thinking a password that only the tenant knows... – Griffin Nowak Jun 20 '13 at 06:31
  • @Griffin the problem is the "tenant" may be an organization with hundreds of employees, with all the complications that this implies. Having a "tenant password" would mean every end-user would need to know it (besides his own password), and sharing a secret between so many people would eventually weaken it to nothing. – mgibsonbr Jun 20 '13 at 14:21
  • I thought only 1 person needed to know. – Griffin Nowak Jun 20 '13 at 18:20

1 Answers1

2

Authenticating an user in a multi-tenant application is not fundamentally different from authenticating in a single-tenant one. Before you know who that user is and which permissions or capabilities or roles he has, you don't know which subset of data should be available to him. Once authenticated, you can limit the data exposed to him, using whatever controls your application supports (e.g. filtering, permissions, encryption).

A multi-tenant system has the same needs, except that now the user belongs to an organization, and all the data in you DB is partitioned around that organization. You might want to have stronger protections inter-tenants than intra-tenant, but it's still a matter of discovering who the user is and what data he can access.

The article you linked suggests one approach, using encryption as part of its defence-in-depth:

When an end user logs on, the application uses impersonation to access the database using the tenant's security context, which grants the application process access to the tenant's private key. The application (still impersonating the tenant, of course) can then use the tenant's private key to decrypt the tenant's symmetric key and use it to read and write data.

But notice that this assumes the user is already logged in (and thus is authenticated with the system); before that happens, there's no way the system can know which tenant he belongs to. Unless of course all users from the same tenant had some sort of shared credentials used first to authenticate the tenant, then use their individual credentials to authenticate themselves, but this opens another can of worms.

So my suggestion would be having a single database table for all users, where an username (or pair tenantname-username) and the associated credentials (password hash, public key, OTP key, etc) authenticates the user and then uses the information "who the user is" and "which tenant he belongs to" to unlock access to the rest of the data. And make sure nobody but the service provider has access to that table's contents.

mgibsonbr
  • 2,905
  • 2
  • 20
  • 35