具有内部部署ADFS身份验证的MCV Web应用程序

Question

我真的希望在浪费太多时间之前能够得到一些指示。事实上，我甚至没有百分之百确定我需要问这个问题。我正在处理一堆我几乎没有经验的技术。从历史上看，我一直是一个非常简单的vb.net桌面开发人员，所以我正在学习MCV5＆amp; C＃，因为我去。我意识到其中一些可能在错误的地方，但希望指向租约

所以情况是我被许多客户要求开发一个web应用程序/ api，以便他们的现场工作人员可以在办公室外执行某些数据输入功能，并定期反馈到他们的管理系统中。所有这些客户都非常接近相同的需求和管理系统，所以我的目的是构建一个带有多租户数据库的Web应用程序，我可以控制谁可以根据他们的登录信息查看内容。 Web应用程序的核心，数据库等我已经掌控了，事实上所有看起来都很无缝。使用https://msdn.microsoft.com/en-us/library/aa479086.aspx作为起点我认为我可以管理数据库方面的事情。

我真正在苦苦挣扎的是如何最好地保护这个系统。看看visual studio（2015）中可用的选项我认为对我来说最好的选择是使用内部部署ADFS。我的老板已经放下了关于Azure的脚，所以很遗憾不是一个选择，我们几乎拥有自己的服务器农场，而不是能够托管这个。 这里真正的贴纸是我的SA几乎说这不是他的问题，如果你想要ADFS和网络服务器，你可以解决它。他至少给了我一个很好的新服务器VM和Win2012R2，但是不想再和它做任何事了。

所以，问题

1. 在这种情况下甚至需要ADFS，或者我更好地处理这个问题 所有这些都通过标准AD或其他工具进行？即使有可能，这是一个好主意吗？
2. 在开发/测试期间，是否可以使用自签名证书或 我是否会遇到证书错误的麻烦？
3. 配置ADFS时，系统会要求您提供联合身份验证服务名称。在 上面的Senario，我用它来验证Web应用程序， 它是否直接暴露给最终用户？他们会成为 需要在浏览器中键入此内容吗？为此设置外部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所说，在测试期间可以使用它们，只需确保所有测试盒都配置为信任证书，否则您将看到连接丢失< / p>

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

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