【问题标题】:Shared authentication for web servicesWeb 服务的共享身份验证
【发布时间】:2009-10-20 16:56:12
【问题描述】:

我们公司 A 公司可能很快会根据某种许可协议与 B 公司合作。如果通过,B 公司的 Web 服务的用户必须能够访问 A 公司的 Web 服务。换句话说,任何拥有 B 公司服务帐户的用户都应该自动拥有 A 公司的帐户,但无需创建新帐户……他们的帐户应该是共享帐户。

我不是这方面的专家(显然),但我认为这种情况需要类似于 OpenID 的东西,但只是在我们两个网站之间。我们将如何以这种方式共享身份验证?我不熟悉这个主题的措辞,这使得谷歌难以获得指导。这会是单点登录吗?

谢谢。

【问题讨论】:

  • 澄清:1. 如果/当他们想要使用 A 的功能时,必须为 B 的每个用户创建一个 A 帐户。 2. B 使用电子邮件/密码来验证其用户。 3. A 或 B 目前都没有使用 OpenID 或任何其他共享认证方案。 4. 这种情况几乎与 Emil 所描述的 StackOverflow 的工作原理一模一样,只是 A 公司只会与 B 公司(而不是任何 OpenID 提供商)核对以在创建本地帐户之前确定用户是谁。

标签: authentication single-sign-on


【解决方案1】:

您实际上是在描述联合,其中 OpenId 就是一个示例(尽管在这种情况下不适合)。使用联合身份,A 公司允许 B 公司对其用户进行身份验证。此身份验证过程会生成来自 B 公司的令牌,其中包含有关用户的信息(声明),该令牌被发送到 A 公司并用于授权。

联合不是单点登录,它倾向于描述 A 公司运行大量服务和身份验证服务的情况 - 登录身份验证服务允许用户访问所有资源而无需重新- 验证。

如果不知道所涉及的架构是什么,就很难推荐一种方法。传输声明的标准方法是使用 SAML 令牌。在 Microsoft 环境中,您可以使用 Windows 身份框架编写理解 SAML 的 Web 服务,并使用 ADFS“日内瓦”从 Active Directory 发出 SAML 令牌。其他身份存储​​也有类似的解决方案,例如 IBM 的 Higgins。

【讨论】:

    【解决方案2】:

    我认为 OpenID 在这里并不是真正的答案。 B 的 Web 服务的用户当前如何对这些 Web 服务进行身份验证非常重要。我假设他们使用用户名/密码对,并假设您希望他们继续这样做,即使对于 A 的 Web 服务。

    如果是这样,下一个问题是如何传输和验证密码。我假设 B 当前使用“基本身份验证”(您需要与 B 确认)。如果是这样,原则上身份验证是直截了当的:在 A Web 服务中,也使用基本身份验证,这会导致用户将密码以纯文本形式发送给 A。使用 https 加密网络上的密码。

    然后,拥有密码的副本,用 B 验证它们,例如通过让 A 的服务向 B 的某个专用服务发送请求,该服务只是确认密码正确。

    这种设置的缺点是用户必须向 A 透露他们的密码;通过许可协议,您需要建立对 A 不会滥用这些密码的信任(即他们不会存储这些密码,也不会在约定的流程之外使用它们来化身用户)。

    【讨论】:

      【解决方案3】:

      我认为你有两个问题。

      1. 允许 A 公司的机器对 B 公司的用户进行身份验证(反之亦然?)
      2. 为公司 B 用户提供公司 A 机器上的资源。

      单点登录或任何身份验证解决方案(如 OpenID)解决了第一部分(对于静态内容可能就足够了);您仍然需要在 A 公司机器上为这些现在已通过身份验证的用户实际创建帐户或分配资源。

      例如,StackOverflow 使用 OpenID 对用户进行身份验证。这意味着 StackOverflow 可以将确定您是谁的部分留给其他服务,例如 Google 或 Facebook 等。但是,StackOverflow 仍然需要为您创建一个本地帐户,以跟踪您的声誉,向您发送问题的更新,和其他东西。

      对于身份验证部分,这里有几个选项:

      • 如果 A 公司已经支持 OpenID,那么 B 公司可能只是一个 OpenID 提供者。您还需要向 A 公司的网站添加一些代码,以确保使用 OpenID 登录的用户是授权,即来自 B 公司。
      • 如果 A 公司和 B 公司都使用 LDAP(例如 Microsoft Active Directory)来处理内部身份验证,那么您可能可以添加一个转发器,让 A 公司查询 B 公司的 LDAP 服务器来验证用户身份(取决于适当的防火墙隧道)。
      • 或者您可以更静态地执行此操作,方法是让 B 公司提供用户列表,并让 A 公司提前为所有这些用户预先创建帐户。这是最简单的方法,但不能非常有效地处理 B 公司的人员变动,除非您设置了额外的同步过程。在这里,您可能会为每个帐户生成密码(例如,lastname+employeeID 或随机字符串),然后让 B 公司将其分发给其用户。

      【讨论】:

        猜你喜欢
        • 2015-09-07
        • 2020-06-06
        • 2012-04-18
        • 1970-01-01
        • 1970-01-01
        • 2013-11-12
        • 2016-06-10
        • 2013-06-22
        • 2020-11-13
        相关资源
        最近更新 更多