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

Question

我的公司正在构建一个ASP.NET HR应用程序，我们决定为每个客户端创建一个数据库。这可以确保客户端不会意外地查看其他客户端的数据，同时还允许轻松扩展（除了已经讨论过的其他好处here）。

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

我不打算在每个单独的客户端数据库中放置任何用户信息，但我团队中的其他人认为每个数据库缺乏安全性是一个巨大的漏洞（但他们无法清楚地说明复制通用访问逻辑是多么有用）。

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

更新
我的团队感到双用户管理的必要原因之一是访问控制。所有用户都有默认角色（例如管理员，最小访问权限，高级用户等），但客户管理员将能够为有权访问其数据库的用户优化权限。对我来说，这似乎仍然可以在一个中央数据库，但我的团队不同意。想法？

Answer 1

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

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

这里的优势在于您可以移动“客户端”数据库，而不必将它们与安全数据库保持同步。另外，当您尝试查找用户信息时，不需要处理w / cross-db连接。

更新：为了响应您的更新...拥有自己的数据库的每个客户的优势之一还在于，如果客户确实需要，还可以恢复客户。如果您将客户的数据拆分为两个数据库，您如何恢复它？此外，如果用户是在主数据库以外的数据库中定义的，那么您还需要担心跨数据库数据访问。

Answer 2

我一直认为应该在应用程序级别而不是数据库级别强制执行安全性。话虽如此，我认为您的预期方法没有问题。通过中央数据库管理帐户和角色可以使应用程序在长期内更易于维护。

Answer 3

您可能希望使用ASP.NET membership provider来处理身份验证管道。这将适用于您声明的方法，您仍然可以将所有身份验证数据保存在单独的数据库中。但是，我同意Chris的观点，即保留一个数据库将更容易维护。