具有本地 ADFS 身份验证的 MCV Web 应用程序

Question

真的希望在我浪费太多时间之前能得到一些指示。事实上，我什至不能百分百确定我需要在哪里问这个问题。我正在处理一大堆我几乎没有经验的技术。从历史上看，我一直是一个非常简单的 vb.net 桌面开发人员，所以我边走边学 MCV5 和 C#。我意识到其中一些可能是在错误的地方，但希望在租赁指针

所以情况是，我的一些客户要求我开发一个 Web 应用程序/API，以便他们的现场工作人员可以在不在办公室时执行某些数据输入功能，并定期向他们的管理系统反馈。所有这些客户都有非常接近相同的要求和管理系统，所以我的意图是构建一个带有多租户数据库的单个 Web 应用程序，我可以控制谁可以根据他们的登录来查看什么。 Web 应用程序的核心、数据库等我已经了解了，事实上，一切看起来都非常无缝。以https://msdn.microsoft.com/en-us/library/aa479086.aspx 为起点，我想我可以管理数据库方面的事情。

我真正苦苦思索的是如何最好地保护这个系统。查看 Visual Studio (2015) 中可供我使用的选项，我认为对我来说最好的选择是使用 On-Premise ADFS。我的老板已经对 Azure 采取了行动，所以很遗憾，这不是一个选择，我们几乎拥有自己的服务器场，而不是能够托管它。 这里真正的标签是我的 SA 几乎说这不是他的问题，如果你想要 ADFS 和 Web 服务器，你可以解决它。他至少给了我一个带有 Win2012R2 的不错的全新服务器 VM，但不想再与它有任何关系。

所以，对于问题

1. 在这种情况下甚至需要 ADFS，还是我更好地处理这个问题 全部通过标准广告或其他工具？即使有可能，这是个好主意吗？
2. 在开发/测试期间，是否可以使用自签名证书或 我会遇到证书错误的麻烦吗？
3. 配置 ADFS 时，系统会要求您提供联合服务名称。在 上面我使用它来验证网络应用程序的场景， 它是否曾经直接暴露给最终用户？他们会不会 需要在他们的浏览器中输入这个吗？并且为此设置外部 DNS 条目会更好吗？

Answer 1

我的 2 美分：

1. 会有一个学习曲线，但如果所有用户都存储在 AD 中，那么使用 ADFS 将为您带来一些优势，例如 SSO，如果您以后需要它可以与其他提供商联合。
2. 在开发/测试期间使用自签名证书很好。您可以在 ADFS 端关闭证书吊销检查。
3. 不，联合服务名称不会暴露给最终用户。我建议您为 ADFS 设置外部 DNS 条目，因为您的用户需要从外部访问它。简而言之，用户很少需要输入 ADFS url。相反，他或她需要访问服务提供商站点，该站点会将他或她重定向到 ADFS 站点。

Answer 2

这种情况越来越普遍，可以使用 AD FS 无缝处理。理想情况下，您想要做的是：

• 部署您的 AD FS 场
• 配置您的 Web 应用程序以信任您的 ADFS STS
• 当您需要添加将使用您的多租户应用程序的客户时，请添加与该客户的联合信任（即您的 AD FS 和客户的 AD FS 之间的联合信任）

这将确保您在添加客户时不必为每个用户处理身份管理。当客户尝试登录您的 WebApp 时，他将通过他的 AD FS 进行身份验证，您的 AD FS 将获取令牌并对其进行签名并将其呈现给 Web 应用程序。这将为他们提供 SSO，每个人都已经开始期待它成为事实上的 :)

自签名证书 - 正如 Thuan 所说，在测试期间使用它们是可以的，只需确保所有测试盒都配置为信任证书，否则您将看到周围的连接中断

联合服务名称 - 如上面设置摘要中所述，联合服务名称永远不需要向客户组织的最终用户公开。据他所知，他已经习惯了他的 AD FS 身份验证。

您可能需要考虑在 Azure 中部署 AD FS： AD FS deployment in Azure