所以我们有一个.NEt Owin / Katana Oauth Webapi2承载服务器，它使用.Net Identity和Entity Framework位于SQL Server数据库之上。用户可以使用Oauth从第三方应用程序登录，其中大多数是其他.net MVC应用程序。生活很好。
现在我们发现需要支持所有的事情。客户希望使用SAML2，OpenID，Oauth，JWT等来登录我们的用户。我发现的是连接到身份提供商所需的所有信息，而不是如何真正成为身份提供者。我们正在考虑转向更加企业级的解决方案，如Active Directory，OpenAM，Shibboleth等......但在触发类似的东西之前，我试图获得更多信息。
我在云中查看了Azure ADFS，但与其他解决方案一样，其中一个主要问题是，他们都希望用户在同一个域中并使用该域电子邮件登录。但是我们的应用程序就像facebook或linkedin。每个人都使用不同的电子邮件/域名。用户使用用户名和密码登录，而不是域电子邮件。
如果我设置类似ADFS转储的用户那里的用户然后启动类似thinktecture的身份服务器V3来玩网守我可以允许使用用户名/密码登录并现在发送电子邮件吗？这真的会成为SSO的一站式商店吗？我真的希望获得一些指导，成为我自己的身份提供商并支持所有主要的SSO工具，而无需支付Ping或Auth0等价格过高的SSO服务。
思想？
答案 0 :(得分：2)
所以一些更正。
AD本身不是一个企业级解决方案 - 你需要像ADFS一样的东西。
没有Azure ADFS这样的东西 - 你可以将Azure AD视为结合AD和ADFS的功能。
要使用ADFS，您需要AD中的用户。 idsrv3没有AD身份验证组件 - 尽管您可以编写自己的扩展。
Auth0听起来是一个很好的解决方案 - 我很困惑为什么你不想为此付费，但正在考虑你支付的OpenAM。 Shibboleth是免费的，但不支持您所需的全部范围。
参考：
由于您需要的用户输入范围 - upn / email等，最好的选择是使用idsrv3并扩展它。请注意，您既不需要ADFS也不需要idsrv3，因为它们都是IDP。但是，您可以联合它们，这将允许AD功能，而无需重写它。
答案 1 :(得分：0)
根据您的环境复杂性和跨多个联合标准的用例数量，如果希望拥有可支持的单一解决方案，您很可能会发现自己在寻找供应商提供的SSO / Federation解决方案。您提到了Ping和Auth0这两个非常好的产品，可以节省集成时间并最终降低复杂性。如果您尝试使用开源路由，您很可能会找到多个产品，其中每个产品都集中在特定的标准和/或集成模式。