公司子系统整合统一登录的架构-CSDN博客

本文链接：https://blog.csdn.net/dong001687/article/details/83817476

如下图是公司的统一登录界面：

众多子系统的登录页面不再使用，所有登录走统一登录页面，登录时选择你要登录的系统，这里以我改造的安全管理系统为例。

在安全管理系统项目中加入一个整合的jar包，其实就是一个拦截器，拦截所有请求，看请求中是否有携带登录标识（此标识是包含统一登录端生成的一个唯一ID），如果没有在，则从定向到统一登录的页面。

然后在子系统的web.xml中配置这个拦截器生效。

之后每次从统一登录页面登录的时候，选择一个子系统，输入用户名和密码（用户名和密码在前台加密，同时携带的还有统一登录端生成的唯一UUID,还有一个status字段，也是一个UUID),然后（1）进入子系统的AuthoFilter拦截器，验证请求中是否有携带指定的标识，如果没有提示原因，如果有执行逻辑，拿着统一登录端的几个参数和子系统本地初始化的几个参数去（2-1）请求统一登录服务

进行授权，（其实就是获取code,然后再用code再次请求换取token,然后获取用户信息，访问子系统）在统一登录端会进行一系列验证（用户名，密码，PSID，子系统等）返回code信息，最后再（2-2）跳到子系统

再次进入子系统的过滤器，进行验证，这次code不为null,所以再去（3-1）统一登录端获取token,

服务端根据子系统的唯一标识和username，查找token,找不到则生成一个token,然后（3-2）响应给子系统

然后子系统拿到token,执行下一个过滤器。下一个过滤器会再次去验证用户名和密码

注意：这次不是去统一登录端去验证，而是去统一登录端上次保存的redis库中去验证。验证成功进行后续的系统操作。

这种就是要部署一个认证中心。

认证中心就是一个专门负责处理登录请求的独立的 Web 服务。

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。

应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。

这里顺便介绍两款认证中心的开源实现：

Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了Apereo 基金会，项目也随之更名为 Apereo CAS。
XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。

总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。

常规的是这种步骤：