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”点击星标。等待着您的支持!