我发现自己在一项我什至不知道从哪里开始的任务之前。所以基本上我有一个可以正常工作的IS4身份验证服务器，该服务器已经为我的App和API服务了一段时间，并且运行良好。我们的解决方案支持常规用户注册/登录以及Google和Facebook登录。
现在，我们面临来自一位客户的挑战，这使他们的员工可以使用其现有的AD用户帐户登录我们的应用程序。 自然，我不想只为他们这样做，而是想让它成为具有现有AD的所有其他企业用户的选择。 我一直在阅读有关联合网关和Windows登录的信息，但是肯定需要阅读更多有关它的信息。
对我来说，主要的未知数是如何允许任何人将其广告与我的应用程序连接，然后执行登录过程。理想情况下，我想通过一个数据库表来存储所有第三方AD提供程序并以某种方式在应用程序启动时加载它们，但是如果我必须为每个它们手动将代码块添加到Startup类中，我会忍受的。
第二个未知是登录过程本身；是否需要为使用AD的公司提供单独的登录页面，或者使用现有的登录页面，但是每当有人尝试登录时，是否检查我是否为该电子邮件域用户注册了提供程序？
答案 0 :(得分：2)
首先-Server 2016上的ADFS支持OpenID Connect，因此，我建议您采用这种方法。 LDAP是另一种选择，但是对于身份验证而言，实现起来比较麻烦，而且在我看来还不是那么好。
我们允许客户定义链接到域的策略，这些策略可以支持对外部OIDC提供商的联合身份验证。捕获用户的电子邮件地址后，我们会根据其域自动通过正确的流程来引导用户。
为此，我们创建了一个自定义的OIDC中间件实现，可以在调用Challenge（）时在运行时将授权URL和客户端ID等作为参数。
答案 1 :(得分：2)
如果您已经具有可以使用您的应用程序和IdentityServer作为身份验证提供程序的有效设置，那么您应该首先问自己想在哪里进行其他身份验证提供程序的集成：因此，您想允许您的应用程序用户进行身份验证吗？使用AD，还是您希望在IdentityServer上进行。
这都是有效的方法，但效果不同，实现含义也不同。
第一个选择是将AD集成到您的应用程序中。这意味着，当用户登录到您的应用程序时，他们可以决定是使用IdentityServer登录还是使用其AD登录名。如果选择执行此操作，则根本不需要触摸IdSrv，只需在应用程序中添加对其他外部身份验证提供程序的支持，并为用户提供选择。这也意味着新的身份验证选项特定于您的应用程序，不会影响使用您的IdSrv的其他应用程序。但是，当然，您必须为每个应用单独执行此操作。
另一种选择是将其添加到IdentityServer应用中。由于IdSrv也是ASP.NET Core应用程序，因此它的工作方式几乎相同：您为用户提供了多种登录方式，然后将他们重定向回仅具有一种外部身份的应用程序：一个来自您的IdSrv。这样做的好处显然是您不需要为此更改应用程序，所有应用程序都会自动从IdSrv继承功能。
关于AD登录本身：通常，您不需要配置它。为了允许使用AD帐户登录，您的应用服务器也必须是活动目录的一部分，并且只能登录该AD。因此，您不能支持多个AD，而仅支持当前。
登录本身通常是通过NTLM进行的，在这种情况下，您不需要登录页面，但浏览器将仅使用当前帐户或提示登录。您也可以使用登录表单，但随后您必须自己用AD登录。
另一种替代方法是使用ADFS，它是Microsoft自己的Active Directory身份验证提供程序（但不仅如此）。在某种程度上，它与IdSrv非常相似。与使用AD的公司集成时，他们似乎很可能也希望部署ADFS或已经运行了ADFS。因此，您可以与之集成，只需将ADFS注册为IdSrv（或您的应用程序）中的外部OIDC身份验证提供程序，并为用户提供选择。