背景
公司要对一些系统做一个集成,需要实现单点登录功能,我就被赶鸭子上架研究了几天SSO,其中发现CAS挺经典,就在短暂的时间内着重研究了CAS。
原理
以最简单的步骤来说明:
- 搭建一个统一验证中心,用以处理登录状态保存及跳转逻辑
- 对每个应用系统加上filter,保证访问会跳转到统一验证中心上
- 访问未登录的应用系统,首先会跳转到统一验证中心进行登录(这里可以选择数据库去存储登录状态)
- 登录成功后会携带上生成的token跳转回原访问地址
- 访问的应用系统接收到访问携带的token,并进行验证,若正确则放行,错误则拦截
核心思想就是:通过一个额外的服务,生成带有时效性的签证,这个签证能在互信的应用系统上使用。
CAS原理
CAS主要通过AuthenticationFilter和TicketValidationFilter来进行登录及后续处理。
- AuthenticationFilter:负责登录会话状态的检测
- TicketValidationFilter:负责票据签证的校验
具体使用步骤
参考SSO单点系列,这个系列描述的很清楚,我也是使用了这个版本。
注意事项
应用系统web.xml的filter顺序
一定要注意web.xml里顺序问题,因为filter是一个责任链模式,所以要让过滤路径范围小的在前,大的在后面,不然会报错。
过滤器对特殊路径的放行
比方说一些静态资源路径(/res/*)、API路径(/api/*)等,在CAS提到的两个filter中,均不能放行,需要自行继承抽象filter实现,然后再把web.xml定义的filter类路径换成新实现的filter类。
不同难度下的单点登录集成
只使用一个账号的的SSO集成
这种情况一般是演示平台等才出现的,不需要使用到原账户,实现最简单,直接让应用系统拿到验证中心返回信息并校验成功后自登录就行,改动很小。
账号密码互不相同的SSO集成
比方说一个用户,他在A系统的账号是user1/123456,但在B系统的账号是user2/123,且权限各不相同,这时应该把各自的账号信息在验证中心那存一份(或建立单独的用户信息管理系统),并建立对应关系,且要改造验证中心的验证返回信息,让它返回更多有用的信息,供应用系统校验账号的真实性
异构的SSO集成
这种貌似没什么好方法,让代理系统代理那些异构的应用系统,通过集成同构的应用系统和代理系统完成集成。
集成时抽取出单独的用户授权管理
这个应该是最难的,不仅仅是账号密码,整个权限都可以重分配,需要数据抽取同步很多账号角色相关的东西,还要改造很多逻辑,这个我暂时搞不明白。
补充
不论是单点登录或是统一身份验证,做集成,应用系统肯定会有所改动,想要完全不改就能集成进平台里就是天荒夜谭,至于怎么改,如何改而不影响单独使用应用系统的功能,也很考技术人员的火候,这篇文章只是我的一点见解,如有不对之处,请及时指正。