Asp.net core IdentityServer 4多个外部Active Directory提供程序

我发现自己在一个我甚至不知道从哪里开始的任务之前。所以基本上我有一个正在工作的IS4Auth服务器，它已经为我的应用程序和API服务了一段时间，它工作得很好。我们的解决方案支持常规用户注册/登录，也支持Google和Facebook登录

现在，我们的一位客户向我们提出了一项挑战，要求他们的员工使用现有的广告用户帐户登录我们的应用程序。 当然，我不想只为他们这样做，但我想让它成为所有其他拥有现有广告的企业用户的选择。 我一直在阅读有关联邦网关和windows登录的文章，但肯定需要阅读更多关于它的内容

我主要不知道的是如何允许任何人将他们的广告与我的应用程序连接，然后执行登录过程。理想情况下，我希望通过拥有一个DB表来实现这一点，在该表中我将存储所有第三方广告提供商，并以某种方式将它们加载到AppStart上，但如果我必须为它们中的每一个手动将代码块添加到Startup类中，我将接受它

---

第二个未知是登录过程本身；我是否需要为那些使用AD的公司提供一个单独的登录页面，或者使用现有的登录页面，但在任何人尝试登录时检查我是否为该电子邮件域用户注册了一个提供商？

首先-Server 2016上的ADFS支持OpenID Connect，因此如果可以，我建议您采用这种方法。LDAP是另一种选择，但对于身份验证来说，实现起来要麻烦得多，而且在我看来没有那么好

我们允许客户定义链接到域的策略，这些策略可以支持将身份验证联合到外部OIDC提供程序。在捕获用户的电子邮件地址后，我们会根据他们的域自动将用户路由到正确的流中

---

为了支持这一点，我们创建了一个自定义的OIDC中间件实现，在调用质询时可以在运行时将权限URL和客户端ID等作为参数

如果您的应用和IdentityServer作为身份验证提供商已经有了可用的设置，那么您应该首先问问自己，您希望在哪里集成其他身份验证提供商：那么您希望允许应用的用户通过广告进行身份验证，还是希望在IdentityServer进行身份验证

这两种方法都是有效的，但效果不同，对实施的影响也不同

第一个选择是将广告集成到应用程序中。这意味着当用户登录到你的应用程序时，他们可以决定是使用你的IdentityServer登录，还是使用他们的广告登录。如果您选择这样做，那么您根本不需要触摸您的IdSrv，您只需要在应用程序中添加对另一个外部身份验证提供商的支持，并提供给用户选择。这也意味着新的身份验证选项特定于您的应用程序，不会影响使用您的IdSrv的其他应用程序。当然，你必须为每个应用程序分别执行此操作

另一种方法是将其添加到IdentityServer应用程序中。由于IdSrv也是一个ASP.NET核心应用程序，其工作方式与此基本相同：您为用户提供多种登录方式，然后他们会被重定向回您的应用程序，该应用程序只有一种外部身份：来自您的IdSrv的身份。这里的好处很明显，您不需要为此更改应用程序，所有应用程序都将自动从IdSrv继承该功能

至于广告登录本身：通常，您不需要对此进行配置。为了允许使用广告帐户登录，您的应用服务器也必须是active directory的一部分，并且它只能登录该广告。因此，您不能支持多个广告，只能支持当前广告

登录本身通常通过NTLM进行，在这种情况下，您不需要登录页面，但浏览器将只使用当前帐户或提示登录。您也可以使用登录表单，但随后您必须自己使用广告登录

---

另一种选择是使用ADFS，它是微软自己的Active Directory身份验证提供商，但不仅仅如此。在某种程度上，它与IdSrv非常相似。当与使用广告的公司集成时，他们可能也想部署或已经运行一个广告功能。因此，您可以与它集成，只需将ADF注册为IdSrv或您的应用程序中的外部OIDC身份验证提供商，并为用户提供选择。

介意分享一些您如何制作该中间件的伪代码吗？@PeterKarman总之，我创建了自己的OpenIdConnectHandler子类，并主要覆盖它HandleUnauthorizedAsync并对其进行了更改，以使外部IDP的某些属性（例如权限、客户端ID等）来自ChallengeContext。属性传递到该方法中，而不是传递到定义为 在启动过程中被重新定义。Challenge方法支持传入包含字典的AuthenticationProperties对象，从而允许您从应用程序代码向中间件传递任何您喜欢的内容。