【SSO简介】关于CAS的使用和注意事项

背景

公司要对一些系统做一个集成，需要实现单点登录功能，我就被赶鸭子上架研究了几天SSO，其中发现CAS挺经典，就在短暂的时间内着重研究了CAS。

原理

以最简单的步骤来说明：

• 搭建一个统一验证中心，用以处理登录状态保存及跳转逻辑
• 对每个应用系统加上filter，保证访问会跳转到统一验证中心上
• 访问未登录的应用系统，首先会跳转到统一验证中心进行登录（这里可以选择数据库去存储登录状态）
• 登录成功后会携带上生成的token跳转回原访问地址
• 访问的应用系统接收到访问携带的token，并进行验证，若正确则放行，错误则拦截

核心思想就是：通过一个额外的服务，生成带有时效性的签证，这个签证能在互信的应用系统上使用。

CAS原理

CAS主要通过AuthenticationFilter和TicketValidationFilter来进行登录及后续处理。

• AuthenticationFilter：负责登录会话状态的检测
  
• TicketValidationFilter：负责票据签证的校验

参考 CAS相关过滤器的处理流程

具体使用步骤

参考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集成

这种貌似没什么好方法，让代理系统代理那些异构的应用系统，通过集成同构的应用系统和代理系统完成集成。

集成时抽取出单独的用户授权管理

这个应该是最难的，不仅仅是账号密码，整个权限都可以重分配，需要数据抽取同步很多账号角色相关的东西，还要改造很多逻辑，这个我暂时搞不明白。

补充

不论是单点登录或是统一身份验证，做集成，应用系统肯定会有所改动，想要完全不改就能集成进平台里就是天荒夜谭，至于怎么改，如何改而不影响单独使用应用系统的功能，也很考技术人员的火候，这篇文章只是我的一点见解，如有不对之处，请及时指正。