联合身份模式

将身份验证委托给外部标识提供者。 这可以简化开发、最小化对用户管理的要求,并改善应用程序的用户体验。

上下文和问题

用户通常需要使用多个应用程序,这些应用程序由与用户有业务关系的不同组织提供和托管。 这些用户可能需要使用每个应用程序的特定(和不同)的凭据。 这可能:

  • 导致用户体验不连贯。 当用户拥有许多不同的凭据时,他们常常会忘记登录凭据。
  • 暴露安全漏洞。 当用户离开公司时,帐户必须立即取消设置。 在大型组织中尤为容易忽略这一点。
  • 使用户管理复杂化。 管理员必须管理所有用户的凭据,并执行其他任务,例如提供密码提醒。

用户通常喜欢对所有这些应用程序使用同一凭据。

解决方案

实现可以使用联合身份的身份验证机制。 将用户身份验证与应用程序代码分离,并将身份验证委托给受信任的标识提供者。 这可以简化开发,并允许用户使用更广泛的标识提供者 (IdP) 进行身份验证,同时最小化管理开销。 它还允许明确地将身份验证与授权分离。

可信任的标识提供者包括公司目录、本地联合服务、由业务伙伴提供的其他安全令牌服务 (STS),或可以对拥有 Microsoft、Google、Yahoo! 或 Facebook帐户的用户进行身份验证的社交标识提供者。

该图说明了当客户端应用程序需要访问要求身份验证的服务时的联合身份模式。 身份验证由与 STS 协同工作的 IdP 执行。 IdP 颁发安全令牌,该安全令牌提供已进行身份验证用户的信息。 该信息(又称为声明)包括用户的标识,并且还可包含其他信息(如角色成员资格和更具体的访问权限)。

此模型通常称为基于声明的访问控制。 应用程序和服务基于令牌中包含的声明授权访问功能。 需要身份验证的服务必须信任 IdP。 客户端应用程序联系执行身份验证的 IdP。 如果身份验证成功,IdP 将向 STS 返回包含标识用户的声明的令牌(请注意,IdP 和 STS 可以是同一服务)。 STS 可以基于预定义规则,在将其返回到客户端之前,转换和扩大令牌中的声明。 然后,客户端应用程序可以将此令牌传递到服务,作为其标识的证明。

在信任链中可能有额外的 STS。 例如,在下面描述的方案中,本地 STS 信任负责访问标识提供者以对用户进行身份验证的另一 STS。 这是在企业方案中的常见方法,其中包含本地 STS 和目录。

联合身份验证为跨不同域的信任标识的问题提供了一个基于标准的解决方案,并且可以支持单一登录。 它在所有类型的应用程序(尤其是云托管应用程序)中变得越来越普遍,因为它支持单一登录,无需与标识提供者的直接网络连接。 用户不必为每个应用程序输入凭据。 这增加了安全性,因为它可避免访问多个不同应用程序所需的凭据创建,并且它还对除原始标识提供者外的所有标识提供者隐藏用户凭据。 应用程序仅可查看令牌中包含的已经过身份验证的标识信息。

联合身份还具有一大优点,即标识提供者负责管理标识和凭证。 应用程序或服务不需要提供标识管理功能。 此外,在公司方案中,如果公司目录信任标识提供者,则不需要知道用户。 这会免去在目录中管理用户标识的所有管理开销。

问题和注意事项

设计实现联合身份验证的应用程序时,请考虑以下事项:

  • 身份验证可以是单点故障。 如果将应用程序部署到多个数据中心,请考虑将标识管理机制部署到同一数据中心,以维护应用程序的可靠性和可用性。
  • 通过身份验证工具,可基于身份验证令牌中的角色声明配置访问控制。 这通常称为基于角色的访问控制 (RBAC),并且它允许对功能和资源的访问进行较具体级别的控制。
  • 与公司目录不同,使用社交标识提供者的基于声明的身份验证通常不提供经过身份验证的用户的信息(电子邮件地址和名称除外)。 某些社交标识提供者(如 Microsoft 帐户)仅提供唯一标识符。 应用程序通常需要维护注册用户的一些信息,并能够将此信息与令牌中的声明中包含的标识符相匹配。 这通常通过用户首次访问应用程序时的注册来完成,在每次身份验证之后,信息作为附加声明注入到令牌中。
  • 如果为 STS 配置了多个标识提供者,则它必须检测用户应重定向到哪个标识提供者(用于身份验证)。 这个过程称为主页领域发现。 STS 可以基于用户提供的电子邮件地址或用户名、用户正在访问的应用程序的子域、用户的 IP 地址范围或存储在用户浏览器 cookie 中的内容来自动执行此操作。 例如,如果用户在 Microsoft 域中输入电子邮件地址(例如 user@live.com),则 STS 会将用户重定向到 Microsoft 帐户登录页面。 在以后的访问中,STS 可以使用 cookie 来指示最后的登录使用的是 Microsoft 帐户。如果自动发现无法确定主页领域,则 STS 会显示列出受信标识提供者的主页领域发现页,用户必须选择其中之一来使用。

何时使用此模式

此模式适用于以下方案:

  • 企业中的单一登录。 在此方案中,需要对公司安全边界外的云托管的公司应用程序进行员工身份验证,而无需要求他们在每次访问应用程序时登录。 用户体验与使用本地应用程序时的用户体验相同,在登录到公司网络时进行身份验证,此后即可访问所有相关应用程序,无需再次登录。
  • 与多个合作伙伴的联合身份。 在此方案中,需要对公司员工以及在公司目录中没有帐户的业务合作伙伴进行身份验证。 这在企业到企业应用程序、与第三方服务集成的应用程序,以及已合并或共享资源的具有不同 IT 系统的公司中很常见。
  • SaaS 应用程序中的联合身份。 在此方案中,独立软件供应商为多个客户端或租户提供即用型服务。 每个租户使用合适的标识提供者进行身份验证。 例如,公司用户将使用其公司凭据,而租户的使用者和客户将使用其社交标识凭据。

此模式在以下情况中可能不起作用:

  • 应用程序的所有用户都可以由一个标识提供者进行身份验证,并且无需使用任何其他标识提供者进行身份验证。 这在使用公司目录(可在应用程序中访问)进行身份验证的业务应用程序中很典型,身份验证的方式是通过使用 V** 或(在云托管方案中)通过本地目录与应用程序之间的虚拟网络连接。
  • 最初使用不同的身份验证机制构建应用程序,可能使用了自定义用户存储,或不具备处理基于声明的技术使用的协商标准的能力。 将基于声明的身份验证和访问控制更新到现有应用程序可能很复杂,并且可能不具有成本效益。

本文分享自微信公众号 - 只喝牛奶的杀手(killerhub),作者:azure

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-01-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 防损层模式

    在不共享相同语义的不同子系统之间实施外观或适配器层。 此层转换一个子系统向另一个子系统发出的请求。 使用此模式可确保应用程序的设计不受限于对外部子系统的依赖。 ...

    只喝牛奶的杀手
  • Feign(上)

    在spring Cloud Netflix栈中,各个微服务都是以HTTP接口的形式暴露自身服务的,因此在调用远程服务时就必须使用HTTP客户端。我们可以使用JD...

    只喝牛奶的杀手
  • 外部配置存储模式

    将配置信息从应用程序部署包移出,移到一个集中的位置。 这可以提供用于简化管理和控制配置数据,以及用于在应用程序和应用程序实例之间共享配置数据的机会。

    只喝牛奶的杀手
  • 推荐算法图推荐-基于随机游走的personalrank算法实现

    推荐算法图推荐 基于图的模型(graph-based model)是推荐系统中的重要内容。其实,很多研究人员把基于邻域的模型也称为基于图的模型,因为可以把基于邻...

    学到老
  • 调研:深度解析IaaS行业的现状与趋势

    T客汇官网:tikehui.com 撰文:李哲 ? 移动信息化研究中心数据显示: 对于IaaS层的具体产品/服务,企业用户当前的选择主要集中在提供数据存储/灾备...

    人称T客
  • day110-项目发布配置

    少年包青菜
  • DataIO & ByteArrayIo

    mathor
  • 达观数据创始人陈运文:算法技术剖析海量数据,数据价值驱动企业收益

    在数据不断增加和算法技术日益优良的并行时代,借助技术去挖掘数据蕴藏的价值,利用数据蕴藏的价值去驱动企业的运营和发展,这是技术、数据、企业收益三者之间的良性循环,...

    数据猿
  • 使用拓扑数据分析理解卷积神经网络模型的工作过程

    神经网络在各种数据方面处理上已经取得了很大的成功,包括图像、文本、时间序列等。然而,学术界或工业界都面临的一个问题是,不能以任何细节来理解其工作的...

    用户3578099
  • 谁是2017年的顶级开源项目?一探究竟

    本文介绍了在开源界比较有名的六个项目。如果你对其中的某个项目不了解的话,赶快来学习一下吧。 ? 今天,让我们一起来看一下2017年开源界的六个顶级玩家。下面列出...

    CSDN技术头条

扫码关注云+社区

领取腾讯云代金券