使用 Active Directory 对面向 WWW 的网站中的用户进行身份验证答案

【问题标题】：Using Active Directory to authenticate users in a WWW facing website使用 Active Directory 对面向 WWW 的网站中的用户进行身份验证
【发布时间】：2010-03-13 13:10:30
【问题描述】：

我正在考虑启动一个需要安全的新网络应用程序（如果没有其他原因，我们将在某个时候需要 PCI（支付卡行业）认证）。

根据以前使用 PCI（在域上）的经验，首选方法是使用集成的 windows 身份验证，然后使用 kerberos 通过应用程序将其一直传递到数据库（因此 NT 用户在数据库中具有权限） .这允许更好的审计以及对象级权限（即最终用户无法读取信用卡表）。

这样做的好处是，即使有人破坏了网络服务器，他们也无法从数据库中收集任何/很多额外信息。此外，网络服务器不存储任何数据库凭据（可能是一个简单的匿名用户，对简单的网站配置只有很少的权限）

所以，现在我正在研究将在公共互联网上发布的新网络应用程序。一个建议是拥有一个 Active Directory 服务器并在 AD 上为站点的每个用户创建 Windows 帐户。然后这些用户将被放置到适当的 NT 组中，以决定他们应该拥有哪些 DB 权限（以及他们可以访问哪些页面）。

ASP.Net 已经提供了 AD 成员资格提供程序和角色提供程序，因此这应该很容易实现。

围绕这一点有很多问题 - 可扩展性、可靠性等...去做吧。

任何意见表示赞赏

【问题讨论】：

标签： asp.net security iis dns

【解决方案1】：

在一个项目中使用过 ADAM，我发现它很受用。开发人员的文档可能很少，它具有将其与完整 AD 区分开来的怪癖，最重要的是，我无法从 MS 那里得到关于它是否会在未来得到完全支持的直接答案。我得到的印象是，ADAM 是个混蛋，新的联合服务 (ADFS) 是他们希望人们去的地方。只是将 ADAM 存储从一个成员服务器移动到另一个成员服务器是一件很痛苦的事情。话虽如此，我与 ADAM 的问题与商店的开发和维护有关，它绝对具有扩展能力并且是可靠的。也就是说，有时您需要深入研究 LDAP/目录魔法的第 80 级咒语，以确定它在做什么或不做什么。

对于面向公众的网站，AD/ADAM 可能对 IMO 来说太过分了。您可以使用 SqlMembership 提供程序之类的备用 MembershipProviders 来获得有关凭据的良好安全级别。如果您想走得更远，您可以使用数据库加密（SQL Server 至少内置此功能）来加密属于 PII（个人身份信息）领域的信息，当然还可以加密备份。数据库支持的身份验证存储的优势在于您拥有数据库产品提供的所有工具来横向扩展、执行备份、控制访问等等。

编辑：让我补充一下，使用 .NET，您可以设置您的站点，使其在 Windows 用户下运行并使用 Windows 身份验证连接到数据库（假设数据库支持它）。因此，不需要将凭据存储在配置文件中。但是，如果您出于某种原因必须存储凭据，则可以使用 DPAPI 对配置文件中的凭据进行加密。

补充在回答有关保护加密密钥的问题时，您有几个选择。第一个是简单地散列信用卡号码。这大大简化了访问数据的任何问题，但这意味着客户每次购买都必须重新输入他们的卡号。如果您想记住客户的卡号，那么您就进入了维护解密密钥的新领域。在这种情况下，您绝对应该对数据库使用 Windows 身份验证并查看 SQL Server 2008 的可扩展密钥管理功能，该功能允许您将第三方密钥管理程序连接到 SQL 的加密功能中。这样，只有网站用户才能访问用于解密的密钥。还有其他解决方案可以确保网站不会受到损害。更大的担忧是有人得到了未被检测到的数据库副本。这是一个关于使用 SQL Server 来符合 PCI 的链接：

Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.

【讨论】：

谢谢 - 我也被一位朋友警告不要使用 ADAM（出于类似原因）。虽然我们可以在配置文件中加密密码，但我们不会仍然失去数据库中所有的对象级权限吗？即最终用户可以从信用卡表中读取？另外，如果网络服务器可以使用加密凭据登录数据库，那么任何破坏网络服务器的人都可以这样做吗？
扩展了我的 OP 以讨论 CC 号码的加密。如果您使用的是 Windows 身份验证，则开发人员无法劫持该帐户以获取数字。可以运行其他测试以确保站点不会被劫持，但即使它被劫持（并且假设站点受到 SQL 注入的完全保护），黑客也会想要使用它来获取数据库的副本。在这种情况下，这将毫无用处，因为他没有解密密钥。
感谢您的链接 - 看起来很有用！

【解决方案2】：

几个想法

运行 AD/AM - Active Directory Application Mode。

它可以很好地扩展。它与 AD 的核心代码相同。类似的管理能力。可靠的可靠性。与 ASPNET AD 成员资格提供程序一起使用。

它包含在 Windows 中。

还可以考虑通过ADFS 2 探索联合身份系统。

与 AD/AM 不同，这种方法相当领先。微软尚未提供 ADFS v2 服务器的最终版本，但它处于“候选发布”阶段。如果您愿意成为早期采用者，ADFS2 有可能采用联合身份方法。这意味着您可以接受来自各种现有来源的身份令牌：谷歌登录、雅虎登录、any OpenId source，并将其用作您网站上的身份。用户不必“注册”并向您进行身份验证。相反，您的站点将尊重某些受信任的第三方提供的身份和身份验证，并根据该身份执行授权。

【讨论】：

谢谢 - ADFS 2 听起来很有希望，我们已经在 VS 2010 RC 中为 .Net 4 开发 - 所以早期采用也不应该是一个问题。一些注册/授权的委托实际上在某些方面帮助了我们（尽管可能与我们自己的系统一起）。我希望能够进行一些辩论，因为我想要一系列观点 - 所以我打算让 Q 开放，直到赏金到期之前。谢谢

【解决方案3】：

这不是一个直接的答案，但拥有 AD 用户帐户意味着您需要该用户的 Windows CAL。另一种方法是向用户颁发客户端证书并将客户端证书映射到 IIS 中的 AD 用户。

您也可以考虑使用AzMan 以及从 Windows 2008 开始提供的 SQL 存储或开源 netsqlazman。

【讨论】：

谢谢，我什至没有考虑过这种方法——我们将有最终用户和“客户”使用该系统。我们可以（在一定程度上）控制的客户，但最终用户将是公开的——这是一种用户友好的体验吗？（颁发/安装证书）？
对于 joe 公共客户端证书一点也不友好。首先，您需要为每个用户创建不同的证书，并记录哪个用户拥有哪个证书。您可能还必须为证书提供较短或不同的到期日期。安装客户端证书并提示用户每次选择您的证书也不友好。它仅适用于有限的内部用户或 B2B 场景。
感谢您的回答 - 这很可能是我将在未来项目中使用的东西，但不幸的是，它不适合这种情况。不过，感谢您的回复！