SSO单点登录可以自己实现吗？--开源软件诞生10

ERP与SSO的恩怨情仇--第10篇

用日志记录“开源软件”的诞生

赤龙 ERP 开源地址：

点亮星标，感谢支持，与开发者交流 kzca2000

码云：https://gitee.com/redragon/redragon-erp

GitHub：https://github.com/redragon1985/redragon-erp

赤龙ERP官网：https://www.redragon-erp.com

为什么要用单点登录

首先大部分系统都不是孤立存在的，尤其是信息化系统。它们往往在一个大的平台上，由多个独立的系统组成。如果想访问多个系统，那么多次重复的进行登陆往往是不能接受的，那么一个统一的登陆入口就变得必不可少。这就是单点登录。

单点登录的特点是：

（1）统一的登陆入口和注销入口

（2）共享的用户信息数据

（3）可实现跨域、跨多应用、跨多浏览器的认证

（4）可实现较高的安全认证机制

（5）可扩展的授权机制

是否需要实现自己的SSO

是否需要实现自己的SSO呢？要回答这个问题。首先要明白SSO是如何实现的。那我们先来看看登陆如何实现，常见的做法是，输入用户名、密码、验证码，点击登陆验证用户名和密码是否正确，验证通过后获取用户信息，并跳转请求的页面。登陆状态和用户信息一般会存储在session、cookie或本地缓存；当然有时还会引入token验证登陆状态。

这个过程看似实现很简单，但里面有个致命的问题，不管session、cookie或本地缓存，都是存储在应用服务器本地的，这就使得统一认证、共享状态、跨域等多个问题变得不可能。下面我们来看看SSO是如何做的：

（1）当客户端发送请求访问应用的某一路径，应用会先判断当前用户本地的登陆状态，如果当前用户存在登陆状态则正常访问；如果用户没有登录则重定向到单点登录的服务端

（2）单点登录服务端会先通过cookie验证当前用户在服务端存储的登陆状态，如果存在则跳转回应用路径，并在客户端存储登陆状态。如果当前用户没有登录，则进行用户认证。（即输入用户名和密码的登陆动作）

（3）服务器认证成功后，会产生一个票据，带着这个票据并设置cookie跳转回客户端的接收路径

（4）客户端会在接收路径中重新访问服务端，去验证票据的合法性，成功后反馈用户的认证信息和相关数据给客户端

现在明白了单点登录是如何实现的，下面来回答本节开始的问题。要看使用场景，如果是互联网的项目我建议自己实现或优化此流程实现，但我现在研发的是一款开源ERP，在考虑安全性，可扩展性、时间成本等多方面的前提下，当然没有必要自己开发，拿成熟的产品优化即可。下面来看看我做了哪些优化。

CAS与Shiro的整合

CAS是Apache的开源SSO，解决的是认证的问题；Shiro是安全性框架，解决的是授权和会话管理。这也是【赤龙ERP】使用的两个技术。基本流程是：

（1）Cas先做用户认证，并获取用户信息（此过程通过SSL加密）。

（2）Shiro与Cas整合，在cas认证成功后交由shiro绑定认证状态、用户信息，并在shiro中获取用户权限，所有信息均存储在会话中。

（3）通过shiro配置实现对所有请求的拦截，并可以通过标签控制页面显示的内容（shiro的授权都是通过角色和权限两级完成的）。

【赤龙ERP】对CAS和Shiro做了哪些优化

其实不管是Cas和Shiro本来的功能上都有一些欠缺，在【赤龙ERP】中我做了相关优化。

（1）cas的登录页面的客户化，cas本身的登陆页面不好看，所以需要针对不同的场景做客户化。

（2）cas的登录页面更多数据的提交，本身登陆页面只接受用户名和密码的提交，不支持其他字段，但往往有时需要提交更多的字段，比如：账套。

（3）cas对于通过接口进行用户验证的功能比较欠缺，在此也做了弥补。

（4）cas记住密码的功能在和Shiro整合后存在一些问题，在此已解决。

（5）cas用户注销和Shiro整合后，存在一些情况下无法同步注销的问题，在此已解决。

（6）Shiro本身的会话存储在Ehcache本地缓存中，但整合Cas后会出现跨域、跨浏览器、跨应用的数据同步问题，优化后将会话存储在Redis中。

希望您读完本文可以帮助笔者进入【码云】或【GitHub】搜索“赤龙ERP”点击星标。等待着您的支持！