每个客户端使用单个数据库时的用户身份验证？

Question

我的公司正在构建一个ASP.NET HR应用程序，并且我们决定为每个客户端创建一个数据库。这可以确保客户不会意外查看其他客户的数据，同时还可以实现简单的可扩展性（其他益处，已经讨论过here）。

我的问题是 - 在这种情况下处理安全和数据访问的最佳方式是什么？我的意图是使用一个通用的登录/帐户数据库，将用户引导到正确的服务器/数据库。这个公共数据库还将包含每个用户/角色都可以访问的应用程序功能。

我并不打算在每个客户端数据库中放入任何用户信息，但我的团队中的其他人却认为每个数据库缺乏安全性是一个巨大的漏洞（但他们无法阐明如何复制常见访问逻辑有用）。

我错过了什么吗？我们是否应该在客户端数据库级别添加额外的安全/身份验证层？

更新：
我的一个团队认为双用户管理的原因是必要的是由于访问控制。所有用户都有一个默认角色（例如管理员，最小访问权限，高级用户等），但客户端管理员将能够改进访问其数据库的用户的权限。对我来说，这似乎是可行的，在一个中央数据库，但我的团队不同意。思考？

Answer 1

我一直认为安全应该在应用程序级而不是数据库级执行。据说，我认为你的预期方法没有问题。通过中央数据库管理帐户和角色，从长远来看，应用程序更易于维护。

Answer 2

您可能想要考虑使用ASP.NET membership provider来处理认证管道。这将适用于你陈述的方法，你仍然可以将所有的认证数据保存在一个单独的数据库中。但是，我同意Chris的观点，即保持一个数据库的可维护性将更高。

Answer 3

我们有一个SaaS解决方案，它使用每个客户端模型的一个数据库。我们也有一个共同的“安全”数据库。但是，我们将所有用户信息存储在各个客户端数据库中。

当用户登录到系统时，他们告诉我们三条信息，用户名，密码和客户端ID。客户端ID用于在“安全”数据库中查找其主数据库，然后代码连接到其主数据库以检查其用户名/密码。这样一来，客户端在数据库中是完全独立的。当然，你需要一些超出用户名的信息来确定他们的主数据库。可能是我们的客户端ID方法，或者如果您使用每个客户端的子域方法，则可能是请求的域名。

这里的优点是你可以移动“客户端”数据库到w/out中，并且必须保持它们与安全数据库同步。另外，当您尝试查找用户信息时，您不需要处理w/cross-db连接。

更新：为了响应您的更新......每个拥有自己数据库的客户的优势之一就是能够在客户真正需要时恢复客户。如果你已经将客户的数据分成两个数据库，你如何恢复它？另外，如果用户在主数据库以外的其他数据库中定义，则需要担心跨数据库访问。