【问题标题】:How to Be an Identity Provider for all the things?如何成为所有事物的身份提供者?
【发布时间】:2016-03-15 01:35:51
【问题描述】:

所以我们有一个 .NEt Owin / Katana Oauth Webapi2 Bearer 服务器,它位于使用 .Net Identity and Entity Framework 的 SQL Server 数据库之上。用户可以使用 Oauth 从 3rd 方应用程序等登录,其中大部分是其他 .net MVC 应用程序。生活很好。

现在我们发现需要支持所有的东西。客户希望使用 SAML2、OpenID、Oauth、JWT 等来登录我们的用户。我发现的是连接到身份提供者所需的所有信息,而不是如何真正成为身份提供者。我们正在考虑转向更企业级的解决方案,如 Active Directory、OpenAM、Shibboleth 等……但在触发类似的事情之前,我正在尝试获取更多信息。

我研究了云中的 Azure ADFS,但与其他解决方案一样,主要问题之一是他们都希望用户在同一个域中并使用该域电子邮件登录。然而,我们的应用程序就像 facebook 或linkedin。每个人都使用不同的电子邮件/域。用户使用用户名和密码而不是域电子邮件登录。

如果我设置 ADFS 之类的东西将用户转储到那里,然后启动 thinktecture 的身份服务器 V3 之类的东西来播放网守,我可以允许使用用户名/密码登录,然后现在发送电子邮件吗?这真的会成为 SSO 的一站式商店吗?我真的在寻找一些指导来成为我自己的身份提供者并支持所有主要的 SSO 工具,而不必为 Ping 或 Auth0 等价格过高的 SSO 服务付费。

想法?

【问题讨论】:

    标签: oauth-2.0 openid saml-2.0 federated-identity thinktecture-ident-server


    【解决方案1】:

    根据您的环境复杂性和跨多个联合标准的用例数量,如果您希望拥有一个可以支持的单一解决方案,您很可能会发现自己正在寻找供应商提供的 SSO/联合解决方案。您提到了 Ping 和 Auth0,这是两个非常好的产品,可以节省您的集成时间并最终降低复杂性。如果您尝试走开源路线,您很可能会发现多个产品,每个产品都专注于特定的标准和/或集成模式。

    【讨论】:

      【解决方案2】:

      所以一些更正。

      AD 本身并不是企业级解决方案 - 您需要在它之上添加一些东西,例如 ADFS。

      没有 Azure ADFS 这样的东西 - 您可以将 Azure AD 视为结合了 AD 和 ADFS 的功能。

      要使用 ADFS,您需要 AD 中的用户。 idsrv3 没有 AD 身份验证组件 - 尽管您可以编写自己的扩展。

      Auth0 听起来是一个很好的解决方案 - 我很困惑为什么您不想为此付费,但您也在考虑您付费的 OpenAM。 Shibboleth 是免费的,但不支持您所需的全部范围。

      参考:

      由于您需要的用户输入范围 - upn / 电子邮件等。最好的选择是使用 idsrv3 并对其进行扩展。请注意,您不需要同时使用 ADFS 和 idsrv3,因为它们都是 IDP。但是,您可以将它们联合起来,这将允许 AD 功能而无需重写。

      【讨论】:

      • 虽然 IdSrv3 可以通过 Kentor.AuthServices 充当 SAML2 SP,但不支持充当 SAML2 Idp。当然可以基于 AuthServices 构建一个模块,但工作量很大。
      • 没错,但 SAML 更像是一种企业概念,而不是应用程序概念。您仍然可以使用 WS-Fed 或 OpenID Connect 进入 IDP,并使用 SAML 退出上游。
      猜你喜欢
      • 1970-01-01
      • 2021-09-12
      • 1970-01-01
      • 2014-11-27
      • 1970-01-01
      • 1970-01-01
      • 2015-05-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多