作者简介：刘彤辉，中通信息安全团队全栈开发工程师，负责中通统一认证系统和移动端安全产品的开发工作。

背景

随着公司业务的飞速发展，组织规模的持续扩大，我们需要借助大量各类应用系统进行日常的管理运营，其中有本地部署的核心系统也有公有云部署的各类SAAS服务，有大量自研的也有相当一部分外购的，这就构成了一个相对复杂的混合云架构下异构的IT系统生态，在这种场景下如何做好统一的安全访问控制策略特别是SSO统一认证是我们面临的非常大的挑战。以中通为例，中通快递目前活跃使用的内部系统已有300+，各种系统类型和部署方式均有涉及，所有系统依赖于统一的用户体系，需要对接同一套SSO以实现登录授权和资源访问操作。从安全性和用户体验考虑，我们设计SSO时应当让用户的登录状态在所有应用之间互通，同时也需要让各个应用能自主针对不同的用户做不同的访问权限控制。为满足以上几点，我们实现了一套以OAuth2授权框架为主，同时支持LDAP和JWT等多种身份验证方式，认证与权限管理相结合的SSO系统。

中通SSO特性

  • 认证安全：整个登录授权的验证流程能保证用户信息安全和验证结果可靠

  • 状态互通： 用户的登录状态可以在不同域名、不同部署方式的业务系统中互通

  • 资源管控：用户访问业务系统资源时需要满足资源所有者预先配置的访问策略，我们提供了权限校验和二次验证等手段供业务系统选择

  • 权限管理：用户完成授权认证后，我们可以为业务系统提供该用户在该系统下配置的所有权限数据和私有的用户信息，我们为业务系统提供了统一的配置中心和API支持

  • 开发友好：授权认证满足对主流认证协议和各个平台的支持，同时提供了后端框架级支持，使开发人员仅需填写基础的配置信息即可完成对接

  • 帐号安全：我们通过推广以实人认证为基础的人员帐号强关联手段，大幅加强了帐号信息安全程度，同时解决了敏感操作追溯到人的问题

特性详解

总览

基于零信任原则，我们认为不论内外网，所有非公共资源的请求都需要向资源服务器提供身份权限凭证。我们的服务架构如下:

图1. 中通统一认证服务架构

认证安全

认证是所有业务系统资源请求的第一步。目前常见的认证授权协议有OAuth2，LDAP，OpenID，JWT等，各种协议基于自身的诞生背景和需求的差异，适合的场景各不相同。以下是对各个协议的简单介绍：

OAuth2：OAuth2是一个全世界范围内广泛应用的认证标准，基于该标准实现的SSO单点登录可以使各个业务系统无需关心用户的登录认证流程，只需在用户完整授权认证之后向资源服务器（Resource server）请求自己所需的用户和权限信息，并专注于业务逻辑即可

  • 优点：高可控的资源访问粒度，完善的用户信息隔离功能，能有效保障用户的信息安全

  • 缺点：对接流程较长，需要开发人员理解各个概念，使用不当可能会造成安全漏洞

它的流程如下：

图2. OAuth2授权认证流程

LDAP：LDAP（Light Directory Access Protocol）实际上是基于X.500标准的轻量级目录访问协议，认证流程是业务系统向目录服务请求用户的认证信息，然后自身来决定是否分配资源。

  • 优点：对接简单，使用范围很广，能快速应用到生产环境，大量系统均有对接此协议

  • 缺点：所有业务系统都会直接接触用户包含密码在内的所有信息，如业务系统不可信或存在漏洞，会对用户信息安全造成很大的风险

JWT：JWT(JSON Web Token)是一种安全标准，基本思路是用户通过认证之后，服务端会产生一个加密的Token并返回给用户，服务器验证Token的合法性后即可向用户下发受保护的资源。

  • 优点：JWT与其他验证方式最大的区别是服务端可以不存储任何会话标识，会话的标识、过期时间、加密方式等都存储在客户端所持有的Token中。这种验证方式很容易做水平扩展

  • 缺点：不便于对已颁发出去的Token做控制，若要实现对已颁发的特定token做控制就必须在服务端对其持久化，这违背了JWT设计的初衷

图3. JWT认证流程

OpenID: OpenID是以前使用较为广泛的一种认证方式，它通过服务端生成一串随机字符串，传递给业务系统后业务系统通过这串字符请求资源服务器，若认证通过就返回相应的资源。由于不同应用间没有任何信息限制隔离手段，无法保证足够安全的问题，已于2014年被基于OAuth2的OpenID Connect替代，后者能提供更高的安全保障。

对比以上几种方式，从安全性、资源控制粒度、开发友好等多方面考量，我们采用OAuth2作为业务系统授权的主要认证手段。我们的认证场景如下：

用户在浏览器打开某个业务系统（Client）并需要登录时，会根据应用场景发起认证请求（Authorization Request）跳转到统一认证页面，认证服务器（Authorization Server）通过各种验证方式（用户名密码组合、扫码、推送、多因子验证等）确认用户为合法授权后，会将浏览器重定向至业务系统预先指定的重定向地址（Redirection URI）并附加本次授权颁发的授权码（Authorization Code），业务系统接受到浏览器请求并获得授权码后，通过授权码和认证服务器为业务应用单独颁发的应用密钥，向认证服务器请求目标用户的授权令牌。

图4. 业务系统发起认证所需字段

业务系统获取到用户的授权令牌之后，可以使用令牌到SSO统一的资源服务器（Resource Server）请求对应用户的详细信息， 信息的敏感程度由发起认证请求时传递的scope决定。认证服务器对浏览器授权完成后，会在认证服务器域下设置信任会话，会话信任期内业务系统再次发起的授权请求会被自动放行，这样当用户再打开别的业务系统就不需要重复登录，新打开的业务系统会直接获取到认证服务器颁发的授权码。上述登录认证流程实现了逻辑上的闭环，可以保证认证过程的安全可靠。

为保证业务系统授权的安全性，认证服务器下发的用户令牌一般以短期多次有效的access_token和长期单次有效的refresh_token组成，当用户的access_token失效后，可以使用refresh_token向认证服务器请求一对新的token。

状态互通

为了保证所有业务系统的登录状态同步，除了用户完成一次认证后我们为其设置整个SSO的信任会话外，当用户退出某个业务系统时，本次授权认证的所有关联业务系统也都应当退出登录。为了做到这一点，我们设计实现了以下功能流程：

  • 用户退出业务系统时，业务系统需要调用认证服务器的接口来吊销当前浏览器环境的认证信任会话

  • 认证服务器接受到吊销的请求后，会查找并吊销当前会话颁发的所有用户令牌

由于业务场景的不同，有些应用系统可能在登录后保持自己的会话状态不再与认证服务器交互，这种情况下我们需要主动告知业务系统用户的登录状态变化，为此我们提供了三种方式供业务系统对接：

  • 业务系统可以主动设置一个会话状态变化的地址，认证服务器在用户退出登录或者帐号权限变动时会查找当前所有需要变动的登录会话，通过调用业务系统设置的接口地址来告知用户的变化状态

  • 业务系统可以订阅自身应用的用户状态变化的消息队列，需要业务系统处理的状态变化会以消息的形式推到相应队列中

业务系统前端可以接入统一提供的JSSDK, 每个打开的业务系统窗口都会维持与统一认证服务器的一个长连接，用户状态变化后，JSSDK会以调用子系统接口或者直接插入当前页面DOM来提示用户。

资源管控

为满足业务系统对零信任安全架构的需求，我们应当引导业务系统在所有涉及用户信息的API操作都进行会话合法性验证，这个验证包括用户的登录合法性验证和权限验证，为此我们的认证服务器必须满足高可用，高并发，便于水平扩展等特性以提供稳定的对外服务。认证服务的各个子模块需要尽可能做到解耦合。我们同时实现了以不同的业务系统，不同的API为粒度的流量管控，使不同业务系统的请求都可以得到控制。

中通内部业务系统请求资源时，资源服务器会向授权认证中心校验本次请求的合法性，授权认证服务器通过验证本次请求者的身份与应用配置的资源API定义来判断资源权限并返回操作的放行策略。

图5. 授权资源访问流程

权限管理

我们为业务系统提供了统一的权限管理中心—中通统一权限安全管控系统实践，用户完成登录认证之后，我们会为业务系统提供该用户的基础信息和业务应用下的私有信息及所有权限数据。权限数据分为全局权限和以应用维度隔离的私有权限，应用管理员可以为单个或批量用户配置允许访问目标应用的权限。通过权限的配置，我们可以自由指定哪些用户可以访问哪些资源，甚至直接指定用户可以访问的系统。以登录为例，认证服务器接受到授权请求并发现该用户没有对应业务系统的访问权限的时候，会拒绝对业务系统服务器发放授权码并以指定的信息提示用户。

图6. 登录时的权限控制

开发友好

为方便开发人员对接SSO，我们除了提供文档和各个端的对接Demo以外，还提供了框架级别的对接支持。开发人员只需要配置业务系统的app_id，app_secret，redirect_uri等参数即可完成标准对接流程。对于移动端和PC客户端等非浏览器环境，我们提供了OAuth2的简化模式，整体流程较授权码模式省略了认证发起请求，由客户端直接提交认证信息并返回用户令牌。为了实现对已有的采用其他认证协议的系统的支持，我们增加了协议适配功能，使得原本采用包括但不限于LDAP，JWT，OpenID等对接方式的系统，如邮箱、WIKI等无需做任何业务流程上的改动，只需对接我们的认证接口即可实现协议适配。

帐号安全

帐号安全是企业信息保障中极为重要的一个环节，保证帐号的使用安全和信息安全是信息安全建设的重头工作。帐号安全最终都是要落实到实际使用者的，我们通过全网推广人脸校验，完成了帐号与人员的强对应关系。为保证帐号安全，我们早在2017年在全网范围内下线了造成帐号泄露最大的源头：静态密码登录系统的方式。所有用户登录中通业务系统都需要使用移动端安全应用生成的TOTP动态密码或者扫描登录二维码、推送登录的形式，从登录入口处解决了最大的安全风险点。其次，我们开发实现了基于设备指纹、用户画像、安全态势感知等为基础的帐号风控系统—中通帐号安全实践。通过多个维度的流量分析，我们可以发现帐号行为的异常，并在访问敏感资源的时候要求用户进行更高安全程度的验证。发现用户行为明显异常，如频繁在多设备登录时，我们会要求用户使用短信验证或人脸识别等风控二次验证手段，确认当前帐号使用者确实为帐号所有者本人，增强了对不法分子攻击的防范力度。为应对已认证帐号在不同用户之间流转的问题，我们除了在风控层面识别外，也执行了全网用户定期扫脸验证的策略，保障人员与帐号关联信息的实时性与准确性。

多重验证手段的详细说明

  • 动态密码& 扫描二维码登录：通过内部安全App扫描二维码进行验证授权，对于处理登录的浏览器设备采用的验证首单，为操作用户授予基础的会话信任。

图7. 动态密码与扫码登录

  • 推送登录：对于已登录过的浏览器标识，允许用户使用内部安全App对其直接信任授权。

图8. 推送登录

  • 短信 & 人脸扫描的二次认证：对于高风险操作，除常规的登录验证手段以外，我们还要求用户进行短信或人脸实人认证来确定用户的合法身份。

图9. 人脸验证登录

业务系统未验证state可能造成的CSRF风险流程：

我们假设某个业务系统A拥有自己独立的用户体系，同时希望通过接入统一认证来关联绑定公司内的统一用户体系，场景如下：用户甲在A系统中已经拥有了一个身份标识，他希望通过关联自己在统一用户体系中的名为张三的帐号，使得自己以后登录A系统时直接用张三来认证。用户甲在A系统中发起关联绑定请求，A系统请求认证服务器并获得授权码，再通过授权码换取令牌并最终得到用户甲在认证服务器中用户张三的信息，并完成关联绑定。以上流程的风险点在于，业务系统在得到认证服务器发来的授权码的时候如果不经任何判断，是无法保证授权码与之前发起绑定请求的用户是同一个的，攻击者可以诱导用户点击包含攻击者授权码的信息绑定链接，使得被攻击用户在A系统的帐号被绑定在了攻击者在认证服务器中的帐号，从而完成攻击。这种攻击的预防手段是，业务系统在获取到认证服务器颁发的授权码时，一定要验证认证服务同时返回的state字段是否为发起授权时传入的值，攻击者伪造的绑定链接无法伪造state值。

展望

目前单个用户数据源的单租户模式已经逐渐无法满足日益变化的业务需求，因此我们规划开发了支持多租户的统一认证平台，增加以租户为维度的人员帐号体系之后，我们可以实现租户x应用的场景组合，能够以更细的粒度实现对资源访问的管控，同时能提供更多云平台的应用组件支持，并能结合服务容器化技术，使不同租户的应用自动化部署与水平扩展变得更为便捷。

团队介绍

中通信息安全团队是一个年轻、向上、踏实以及为梦想而奋斗的大家庭，我们的目标是构建一个基于海量数据的全自动信息安全智能感知响应系统及管理运营平台。我们致力于支撑中通快递集团生态链全线业务（快递、快运、电商、传媒、金融、航空等）的安全发展。我们的技术栈紧跟业界发展，前有 React、Vue，后到 Golang、Hadoop、Spark、TiDB、AI 等。全球日均件量最大快递公司的数据规模也将是一个非常大的挑战。我们关注的方向除了国内一线互联网公司外，也关注 Google、Facebook、Amazon 等在基础安全、数据安全等方面的实践。

声明：本文来自中通安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。