我在寻找内部Web应用程序到数据库层的端到端身份验证的最佳实践。Intranet应用程序的数据库身份验证
我看到的最常见的情况是使用一个SQL帐户，其权限设置为应用程序所需的权限。此帐户由所有应用程序调用使用。然后，当人们需要通过查询工具访问数据库时，或者通过查询访问创建一个单独的组，并且人们可以访问该组。
我看到的另一个场景是使用完整的Windows身份验证端到端。因此，用户自己被添加到具有所有权限设置的组中，以便用户能够在应用程序的参数外进行更新和更改。这通常涉及到将人员保护到适当的存储过程，以便他们不直接更新表。
第一种情况似乎比较容易维护，但如果应用程序中存在安全漏洞，则整个数据库都会受到危害，这引发了担忧。
第二种情况似乎更安全，但是在数据库上的存储过程中存在大量业务逻辑的反面关注。这似乎限制了Nhibernate和LINQ等一些非常酷的技术的使用。然而，在这个时代，人们可以通过多种不同的方式使用数据，我们不会预见混搭等等，这是最好的方法。
戴尔 - 就是这样。如果您想为这些用户提供对底层数据存储的访问权限，请通过服务完成。根据我的经验，那些从Uni/College走出来的经验丰富的电脑用户最容易受到伤害。俗话说，他们知道就够危险了。
如果他们想自动执行部分工作，并且他们可以显示他们有必要的知识，那么请继续，将他们的域帐户访问权限授予后端。这样，他们通过自己的小型VBA自动化所做的任何事情都与他们的帐户相关联，并且您知道在数据流失时应该看看谁。
我的基本观点是数据库是应用程序的谚语圣杯。你想尽可能少的手指在那个特定的饼。
作为一名顾问，无论何时我听到有人允许普通用户加入数据库，我的眼睛都会亮起来，因为我知道当我打电话给我解决问题时，它最终会成为我的大薪水。
就我个人而言，我不希望数据库中的普通最终用户。对于Intranet应用程序（特别是驻留在域中的应用程序），我将提供一个用于应用程序访问数据库的单个帐户，该帐户只具有应用程序运行所需的权限。
然后通过用户的域帐户来控制对应用程序的访问（关闭IIS中的匿名访问等）。
IF用户需要，并能证明，直接访问数据库，那么他们域帐户将被赋予访问数据库，他们可以登录到使用适当的工具DBMS。
我一直负责在过去一年内开发多个内部Web应用程序。
我们的解决方案使用Windows身份验证（Active Directory或LDAP）。
我们的目的仅仅是允许使用现有公司ID /密码的简单登录。我们还希望确保现有部门仍负责验证和管理访问权限。
虽然我无法回答关于Nhibernate或LINQ的争论，但除非您具有特定的杀手功能，否则Active Directory或LDAP非常简单，足以实施和维护它，值得尝试。
Stephen - 将正常的最终用户保留在数据库之外很好，但我想知道如果在这个时代有这么多经验丰富的计算机用户从大学/学院走出来，如果这是正确的道路。如果有人想自动执行部分工作，其中包括VBA更新数据库，我允许他们通过正常的应用程序进行更新，那么我们会通过限制他们的访问权限来以这种方式损失收益。
我想这里暗示的另一种途径是你可以通过服务打开应用程序，然后通过组来保护这些服务，并保持用户与数据库分离。
然后通过授权，您可以允许部门根据Jonathan的帖子通过组来控制对自己帐户的访问。