浅析即时通讯开发前置 HTTP SSO 单点登陆接口的原理

一个安全的信息系统,合法身份检查是必须环节。尤其 IM 这种以 “人” 为中心的社交体系,身份认证更是必不可少。

一些 PC 时代小型 IM 系统中,身份认证可能直接做到长连接中(也就是整个 IM 系统都是以长连接为中心:身份鉴权、数据收发、文件传送等等)。但当前主流的 IM(尤其新一代的移动端 IM)中,都是 “长”(指 TCP 或 UDP 长连接)、“短”(是指 Http 短连接)相结合的方式。

一个现代的移动端 IM “长”、“短” 连接配合内容大致如下:

    1)短连接用途 1:前置 HTTP 的 SSO 单点接口来实现身份认证;

    2)短连接用途 2:集群式的 IM 中可能还会有独立(或集成于 SSO 单独登陆接口中)的 SLB 接口(即基于 HTTP 短连接拉取 IM 服务器集群 IP 列表);

    3)短连接用途 3:各种小文件的上传、下载接口实现(头像、图片、语音、文件等)都会是基于 Http 实现;

    4)长连接用途 1:用户的实时上、下线状态通知;

    5)长连接用途 2:实时的加友、加群等指令收发;

    6)长连接用途 3:服务端发起的其它实时指令推送等。

总之:当今主流的移动 IM 系统中,“长”、“短” 连接分工明确,各自将自身的优势发挥到最大化,优点是:系统分工明确、分层清晰、业务划分合理、负载方案成本低、符合移动网络的特性等。

针对上述主流移动 IM 系统中 “长”、“短” 连接的分工方式,其中最为重要也是用户最先接触到的 —— 就是基于 Http 的 SSO 单点登陆接口(有的系统里可能并不叫 SSO 接口,本文讨论的是其广义:即实现身份认证功能的 http 接口),那么这个 SSO 接口工作原理是什么?可以怎么来实现?有无最佳实践建议?

假设一个场景:公司内部有财务、OA、订单服务等各类相互独立的应用系统,员工张三对这些系统有操作权限,如果张三想要登录某个系统进行业务操作,那么他需要输入相应的账号与密码。

想象一下:当公司内部有 100 个应用系统,张三是不是要输入 100 次用户名和密码进行登录,然后分别才能进行业务操作呢?显然这是很不好的体验。

因此我们需要引入一个这样的机制:张三只要输入一次用户名和密码登录,成功登录后,他就可以访问财务系统、OA 系统、订单服务等系统 —— 这就是单点登录。

单点登录的英文全称是 Single Sign On,简称是 SSO:

它的意思是说用户只需要登录一次,就可以在个人权限范围内,访问所有相互信任应用的功能模块,不管整个应用群的内部有多么复杂,对用户而言,都是一个统一的整体。用户访问 Web 系统的整个应用群与访问单个系统一样,登录和注销分别只要一次就够了。

举个简单的例子,你登录了百度网页之后,点击跳转到百度贴吧,这时可以发现你已经自动登录了百度贴吧 —— 这就是单独登陆的原理。即时通讯聊天软件app开发可以加蔚可云的v:weikeyun24咨询

针对本文上半部分的原理介绍,我们以一个真实的信息系统为例,理论联系实际来讲解具体的 SSO 单点登陆技术实现(实际上,用 IM 系统的设计思路来看这个例子,可能有点复杂,但知识是相通的,它更有助于对 SSO 完整知识体系的理解。)

SSO 的技术实现要想做好并不容易,作者认为需求优先级应该先是单点登录和单点注销功能,然后是应用接入的门槛,最后是数据安全性,安全性对于 SSO 也非常重要。SSO 的核心是认证中心,但要实现用户一次登录,到处访问的效果,技术实现需要建立在用户系统、认证中心、权限系统、企业门户的基础上。

各职责如下:

用户系统:负责用户名、密码等帐户信息管理,包括增加、修改、启用、停用用户帐号,同时为认证中心提供对用户名和密码的校验;

认证中心:负责凭证 token 的生成、加密、颁发、验证、销毁、登入 Login、登出 Logout。用户只有拥有凭证并验证通过才能访问企业门户;

权限系统:负责角色管理、资源设置、授权设置、鉴定权限,具体实现可参考 RBAC。权限系统可为企业门户提供用户权限范围内的导航;

企业门户:作为应用系统的集成门户 (Portal),集成了多个应用系统的功能,为用户提供链接导航、用户信息和登出功能等。

主要包含以下内容:

登录认证:接收登录帐号信息,让用户系统验证用户的登录信息;

凭证生成:创建授权凭证 token,生成的凭证一般包含用户帐号信息、过期时间等信息,它是一串加密的字符串,加密算法如 AES{凭证明文 +MD5 加信息},可采用 JWT 标准;

凭证颁发:与 SSO 客户端通信,发送凭证给 SSO 客户端;

凭证验证:接收并校验来自 SSO 客户端的凭证有效性,凭证验证包括算法验证和数据验证;

凭证销毁与登出:接收来自 SSO 客户端的登出请求,记录并销毁凭证,跳转至登录页面。

客户端的实现逻辑大致如下:

1)请求拦截:拦截应用未登录请求,跳转至登录页面;

2)获取凭证:接收并存储由 SSO 服务端发来的凭证,凭证存储的方式有 Cookie、Session、网址传参、Header 等;

3)提交凭证验证:与 SSO 服务端通信,发出校验凭证有效性的请求;

4)获取用户权限:获取该凭证的用户权限,并返回受保护资源给用户;

5)凭证销毁与登出:销毁本地会话,然后跳转至登出页面。

用户的单点登录流程如下:

1)登录:将用户输入的用户名和密码发送至认证中心,然后认证中心调用用户系统来验证登录信息;

2)生成并颁发凭证:通过登录信息的验证后,认证中心创建授权凭证 token,然后把这个授权凭证 token 返回给 SSO 客户端。SSO 客户端拿到这个 token,进行存储。在后续请求中,在 HTTP 请求数据中都得加上这个 token;

3)凭证验证:SSO 客户端发送凭证 token 给认证中心,认证中心校验这个 token 的有效性。凭证验证有算法验证和数据验证,算法验证可在 SSO 客户端完成。

例子中的应用接入与集成具体如下:

1)用户系统:接入国内机票平台的用户系统,负责登录认证;

2)权限系统:接入国内机票平台的权限系统;

3)认证中心:负责生成并颁发凭证、销毁凭证,改造国内机票平台的登入、登出;

4)凭证验证:在国内机票、国际机票应用系统中调用 SSO 客户端组件实现凭证的验证;

5)企业门户:由国内机票平台、国际机票平台承担。

猜你喜欢

转载自blog.csdn.net/wecloud1314/article/details/126284034