具有本地 ADFS 身份验证的 MCV Web 应用程序
MCV Web application with On-Premise ADFS Authentication
真的希望我能在浪费太多时间之前得到一些建议。事实上，我什至不能百分百确定我需要在哪里问这个问题。我正在处理一大堆我几乎不了解的技术。从历史上看，我一直是一个非常简单的 vb.net 桌面开发人员，所以我一直在学习 MCV5 和 C#。我意识到其中一些可能在错误的地方，但希望能得到指点
所以情况是我的一些客户要求我开发一个网站 application/api 以便他们的现场工作人员可以在不在办公室时执行某些数据输入功能并定期反馈到他们的管理系统。所有这些客户的要求和管理系统都非常接近，所以我的目的是构建一个带有多租户数据库的单一 Web 应用程序，我可以根据他们的登录控制谁可以看到什么。
Web 应用程序的核心、数据库等我已经掌握了，事实上，所有这些看起来都非常无缝。使用 https://msdn.microsoft.com/en-us/library/aa479086.aspx 作为起点，我认为我可以管理事物的数据库方面。
我真正苦恼的是如何最好地保护这个系统。查看 visual studio (2015) 中可供我使用的选项，我认为对我来说最好的选择是使用本地 ADFS。我的老板已经确定了 Azure，所以不幸的是这不是一个选择，我们内部几乎拥有自己的服务器场，完全有能力托管它。
这里真正的标签是我的 SA 几乎说过这不是他的问题，如果你想要 ADFS 和 Web 服务器，你就把它解决。他给了我一个不错的新服务器 VM，至少带有 Win2012R2，但不想再用它做任何事情。
所以，对于问题
- 在这种情况下甚至需要 ADFS，还是我更好地处理这个问题
全部通过标准 AD 或其他工具？即使有可能，这是个好主意吗？
- Duringdevelopment/testing，可以使用自签名证书还是
我要 运行 遇到证书错误的麻烦吗？
- 配置 ADFS 时，系统会要求您提供联合服务名称。在
上面的 senario，我用它来验证网络应用程序，
它是否直接暴露给最终用户？他们会是
需要在他们的浏览器中输入这个吗？有外部 DNS 条目会更好吗？
我的 2 美分：
- 会有一个学习曲线，但如果所有用户都存储在 AD 中，使用 ADFS 将为您提供一些优势，例如 SSO、与其他提供商的联合，如果您以后需要的话。
- 在 dev/test 期间使用自签名证书没问题。您可以关闭 ADFS 端的证书吊销检查。
- 不，联合服务名称不会暴露给最终用户。我建议您为 ADFS 使用外部 DNS 条目，因为您的用户需要从外部访问它。简而言之，用户很少需要输入 ADFS url。相反，他或她需要访问服务提供商站点，它将把他或她重定向到 ADFS 站点。
这种情况越来越普遍，可以通过 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
真的希望我能在浪费太多时间之前得到一些建议。事实上，我什至不能百分百确定我需要在哪里问这个问题。我正在处理一大堆我几乎不了解的技术。从历史上看，我一直是一个非常简单的 vb.net 桌面开发人员，所以我一直在学习 MCV5 和 C#。我意识到其中一些可能在错误的地方，但希望能得到指点
所以情况是我的一些客户要求我开发一个网站 application/api 以便他们的现场工作人员可以在不在办公室时执行某些数据输入功能并定期反馈到他们的管理系统。所有这些客户的要求和管理系统都非常接近，所以我的目的是构建一个带有多租户数据库的单一 Web 应用程序，我可以根据他们的登录控制谁可以看到什么。 Web 应用程序的核心、数据库等我已经掌握了，事实上，所有这些看起来都非常无缝。使用 https://msdn.microsoft.com/en-us/library/aa479086.aspx 作为起点，我认为我可以管理事物的数据库方面。
我真正苦恼的是如何最好地保护这个系统。查看 visual studio (2015) 中可供我使用的选项，我认为对我来说最好的选择是使用本地 ADFS。我的老板已经确定了 Azure，所以不幸的是这不是一个选择，我们内部几乎拥有自己的服务器场，完全有能力托管它。 这里真正的标签是我的 SA 几乎说过这不是他的问题，如果你想要 ADFS 和 Web 服务器，你就把它解决。他给了我一个不错的新服务器 VM，至少带有 Win2012R2，但不想再用它做任何事情。
所以，对于问题
- 在这种情况下甚至需要 ADFS，还是我更好地处理这个问题 全部通过标准 AD 或其他工具？即使有可能，这是个好主意吗？
- Duringdevelopment/testing，可以使用自签名证书还是 我要 运行 遇到证书错误的麻烦吗？
- 配置 ADFS 时，系统会要求您提供联合服务名称。在 上面的 senario，我用它来验证网络应用程序， 它是否直接暴露给最终用户？他们会是 需要在他们的浏览器中输入这个吗？有外部 DNS 条目会更好吗？
我的 2 美分：
- 会有一个学习曲线，但如果所有用户都存储在 AD 中，使用 ADFS 将为您提供一些优势，例如 SSO、与其他提供商的联合，如果您以后需要的话。
- 在 dev/test 期间使用自签名证书没问题。您可以关闭 ADFS 端的证书吊销检查。
- 不，联合服务名称不会暴露给最终用户。我建议您为 ADFS 使用外部 DNS 条目，因为您的用户需要从外部访问它。简而言之，用户很少需要输入 ADFS url。相反，他或她需要访问服务提供商站点，它将把他或她重定向到 ADFS 站点。
这种情况越来越普遍，可以通过 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