全部产品
云市场
云游戏

单点登录 和 身份联邦

更新时间:2020-07-17 16:17:01

什么是「身份联邦」?

「身份联邦」并不是一个新词,我们几乎天天都会在使用「身份联邦」概念下的应用场景。但在身份安全领域,即便是在行业内,很多人对「单点登录」的认知都是不准确的,对「身份联邦」甚至没有任何认知,或和「单点登录」的概念混淆不清。而在行业外,可想而知这两个词汇可能带来的困扰。

对于最终使用的用户而言,这两者实现提供的使用体验很相近。实现任意一种,普通用户都只需要登录一次,即可访问所有的应用服务。(当然,对于开发人员和管理人员来讲,身份联邦比单点登录高效地多,也复杂地多。)所以从需求侧,往往对这两个词的混淆不求甚解。

不仅如此,几乎所有新一代的 IAM 统一身份认证平台 都会在某种程度上「同时」实现这两个概念,而又不加说明,这使得两个概念的边界更加模糊。为了让阿里云 IDaaS 的客户对这两个概念有所区分,增强对 IAM 产品的认知,本文会梳理两个概念的区别和优劣。

我们从单点登录开始说起。

单点登录 Single Sign On(SSO)

单点登录 不是一个技术实现方式的定义,而是代表着一种特定用户认证体验的观念。一般而言,单点登录指的是:

用户只需要认证一次,即可用一个身份访问所有在当前可信环境中的所有应用。

只要实现了这种效果,就可以定义为实现了「单点登录」。企业常见的实现方式多种多样,但往往并没有过多考虑安全性和扩展性,远远低估了一套完整统一身份认证系统的复杂度,在实现后也往往需要重新设计或进行外部采购。实现方式包括使用 cookie、jsonp、页面重定向 等等,也包括了一些单点登录标准协议例如 SAML、OIDC 等。(这里会触及到一点「身份联邦」的概念,但远不完整。)

有一些人会把「用户访问所有的应用都共享一套用户名+密码」作为 单点登录 的另一种形式,用户每访问不同应用都需要单独输入一次统一共享用户名+密码,我们认为这种实现方式是「假单点登录」(虽然在一些场景中我们必须通过「密码代填」来实现 SSO),在这里不多讨论,免得让概念更加错综复杂。

往往企业实现单点登录后,各系统身份仍然相对隔离没有打通,很可能应用系统自己的账密登录入口也仍然保留着,各系统仍然单独维护着独立的账号体系。这种情况的问题如下:

  1. 由于一套账号即可通用所有应用,需要依赖每个应用独立维护多因素认证,以达到最低安全要求,避免单点爆破,消耗研发资源。
  2. 员工离职后,需要手动为其从每个应用系统中删除/禁用信息。如有遗忘:
    1. 可能会造成长期信息泄露,造成潜在安全隐患。
    2. 可能会导致企业长期为离职员工维护企业软件 license,造成额外开支。

于此需求,「身份联邦」与「单点登录」的区别浮现出来。

身份联邦 Identity Federation

「身份联邦」是实现「单点登录」的一种标准方式,但「单点登录」远不是「身份联邦」的唯一目的。只要实现了「身份联邦」,即必然已经实现了「单点登录」,而反之不成立。

「身份联邦」的目的是用标准协议来打通不同安全域之间的用户身份,在跨域、跨产品、跨公司的场景中实现身份信息共享,包含了一系列认证、授权、身份治理、跨域身份同步、统一 license 管理、跨域字段转换的策略、协议和最佳实现。使用实现了「身份联邦」的 IAM 服务,将可以在企业 IT 架构中将身份与权限管理层完整抽离出来,并统一到一个安全平台进行管理。「身份联邦」是一个涵盖面非常广(且仍然在快速完善中)的词。

在「身份联邦」的实现中,浮现出了一个身份和权限访问的中央处理机制,负责统筹所有应用的访问服务。各应用系统不再单独维护独立的账号体系,全部转化为统一的登录入口,登录后将用户分发到希望访问的目标应用中去。

这个处理身份和权限管理的核心即为 IDP Identity Provider,在服务中处于身份提供方。其他的业务服务为 SP Service Provider,服务提供方。

身份提供方 IDP Identity Provider

这样一来,每个单独的业务应用将完全无需关注安全的「身份治理」,包括二次认证、密码强度、定期改密、风险识别等等能力,即可通过统一在 IDP 上增加安全机制,实现不需要应用任何改造,即可满足任意场景的访问安全需要。

除此外,IDP 可以统一管理所有用户的隐私设置以及信息共享,很多国家对各自公民的隐私信息都有立法保护,著名的有欧洲的 GDPR 以及加州的 CCPA。出于对合规的诉求,外国企业(特别是面向顾客提供服务的零售、娱乐等行业)往往对于一个统一登录入口、统一管理所有应用访问安全性有刚性需要。国内虽然立法上相对落后,但明确正在加速完善网络安全、隐私安全的保障,很快由安全合规推进的 IDP 需求会迎来爆发期。

由于「身份联邦」强调的互操作性(Interoperability,即系统之间按照标准协议对接而获得的一种解耦性),在「身份联邦」体系中实现的「单点登录」不能再依赖于 cookie,不可限制在特定安全域内,需要统一使用 SAML、OIDC、CAS 等标准协议实现跨域(或非跨域)单点登录、单点登出的能力。由此一来,按照标准协议实施的应用,有能力与任何支持 SAML、OIDC、CAS 的 IDP 进行配置集成,实现依赖于任意 IDP 身份源的单点登录。

同步 Provisioning

单点登录的实现是不需要依赖于同步的,但身份联邦涉及到多套身份体系之间的关联、映射和集中管理,需要同步来作为 IDP 对外连接的关键触角。

企业的 IDP 往往只有一个(或有限的、架构需要的几个),但身份系统在绝大部分关键系统中都存在。如果希望实现在 IDP 中对账号的「一处修改、处处生效」的话,同步机制必不可少。

一个很常见的场景,企业现有的 IAM 作为身份权限管理核心使用,但针对用户的增删改查等操作,仍然需要同步到 AD 中,因为仍然会有应用依赖于 AD 作为他们的 IDP。

IDP 需要具备类似 LDAP、SCIM 这样的标准身份提供、身份交换的协议,与其他的 IDP、SP 在身份层面打通,实现身份联邦治理。

权限管理 Permission Management

有一些 IDP 会延展现有能力,提供统一的权限系统管理能力。这是 FID(Federated Identity Management 联邦身份管理)的自然延伸。当企业中的核心 IDP 包揽了所有应用的身份对接后,员工的生命周期往往在 IDP 中进行集中管理,设置员工权限往往是下一个步骤。

员工能够访问哪些应用,能访问应用中的哪些菜单、按钮甚至数据,都可以算在身份联邦体系中 IDP 可以提供的权限集中管理能力范围内。

社交账号登录 Social Login

「身份联邦」其实很常见,我们天天使用的扫码登录即是一例。

在网络中,支付宝、淘宝、微信等(海外则包括 Facebook、Google 等)存有用户身份信息的平台(IDP 身份提供方),通过 OAuth 协议,将自己的平台用户信息开放给自由注册的第三方调用,并提供统一认证机制(扫码、或者账密登录),统一返回结果给应用(即 SP 服务提供方)。

在 AWS、Google 中都有「联合身份」(Federate Identity)的概念,可以这么理解:「联合身份」是一个动作片段,最终实现的结果是「身份联邦」。

总结 Conclusion

「单点登录」只牵扯到「认证」这一部分的技术实现,可见单点登录的实现是「身份联邦」整体能力的一小块关键部分。「单点登录」强调的 是用户与客户端之间的互动,而「身份联邦」则普遍需要包含用户对用户、用户对服务、以及服务之间的互动。

由此我们可以想象,在公有云上,「身份联邦」将会依托于各层面的身份和权限的协议和标准,组成一个网状结构。网上有两种节点,IDP 和 SP(Service Provider,即业务应用)。任意 IDP 和 IDP,IDP 和 SP 之间,可以按照企业客户需求,通过标准协议、标准定义接口,组成新的网络连接,实现企业特有的「身份联邦」体系,并以此实现集中的身份权限管理,极大程度上优化企业内部 IT 架构,降低管理和使用成本,提高企业运转效率。

阿里云 IDaaS 致力于为客户提供完整的身份管理解决方案,详情参见:https://www.aliyun.com/product/idaas