SSO架构设计

avatar

一、sso架构以及CAS

SSO就是Single Sign On的缩写，也就是“单点登录”，主要解决的问题是用户在某一子系统登录后能够漫游其他系统
CAS是Central Authentication Service的缩写，也就是“中央认证服务”，是一种将用户的权限判断集中管理的思想。

二、sso架构实现原理

• 中心服务器cas server控制登录与注销状态
• 访问任何一个子系统时，子系统到中心服务器取当前已登录的用户的用户名，若当前子系统未登录则用此用户名在子系统的session中登录；若中心服务器中已注销此用户则子系统也在session中注销此用户。
• 中心服务器存储用户名和密码，子系统只保存用户名，不保存密码，子系统的登录验证都交由中心服务器处理
• 注销时，直接在中心服务器注销

三、宽拓sso实现思路

1, sso和用户、项目、组织架构管理在公司项目群中的位置

sso是管理账户信息的总入口，所有子系统的登录和登出都通过sso进行授权，子系统不处理用户账户问题。
avatar同样受到sso的授权影响,但是sso的账户数据是avatar来进行维护的，彼此相辅相成。

2，cas的实现原理

• 浏览器端：发出请求，收到结果，显示结果[]

• 子系统端: 查看用户是否登录，登录返回结果，没登录重定向到cas server,server进行登录认证后回调回子系统，通过返回的url中携带参数ticket来捕获server颁发的ticket, 获取到ticket后调用server的validate接口验证ticket有效性，有效则server返回用户的信息。

• cas server端获取ticket:子系统重定向到server的login页面，在访问login之前server的过滤器拦截该请求，同时获取用户浏览器中存在cookie中的tgc，如果不存在则转到登录表单页面，如果存在则验证tgc有效，有效则根据tgt生成新的ticket，无效则转到登录页面

• 当用户登录后，在server本地记录用户的信息(tgt)，同时在用户浏览器设置cookie(tgc),生成ticket，通过子系统传来的回调地址进行重定向，并在url中携带参数ticket。

• cas server端验证ticket: 验证通过返回用户信息，失败返回报错信息

• 统一登出: 子系统调用server端的logout接口或者直接在cas server进行登出，当server登出后，会清除掉登出用户对应的tgt，并根据service记录(service为子系统的回调地址),遍历向子系统发出登出请求(server端使用httpURLConnection)，配置在子系统的cas client的filter会监听到server端的logout请求，来进行session的销毁和tgc的清除。

四、sso面临的问题和解决办法

1,cas不能直接支持前后端分离的模式

• RESTFUL 虽然cas不能直接支持前后端分离的模式，但是提供了完整的 restful login api，经过研究后发现，restful 调用会直接获取到tgt，cas 本意是获取到tgt自行处理，但对于web端前后端分离的模式，直接处理tgt并保持与其他项目的同步登陆登出的兼容需要单独开发，于是此方式放弃掉。
• SESSION 前后端分离需要保持session的一致性，由于交互时默认会生成新的session，虽然可以通过ajax的属性配置保持sessionid的一致，但是不是根本的解决办法，由于cas server设置cookie是根据请求地址的域名来存储，在开发的时候前后端是两个server，虽然上线时可以合并为一个server，但也不是根本的解决办法，另外前端还需要一致记录后端的sessid，此方式也弃用掉。
• TOKEN市场上通用的做法是基于token的模式，通过token来进行交互，cas server中的tickert也是此模式，前后端的用户状态验证一定是使用token来进行验证，前端携带token访问后台，后台验证token来获取用户信息，所有还是要使用此模式来解决cas 的问题。

2,前后端分离的解决办法

后端依旧进行所有的cas server交互和存储session， 并在登录后生成signature回调给前端调用。

• 纯后端的验证已证实可行，那么前端在访问后端接口时，要在在header中加入一个signature,后端会在每次访问时验证该signature,验证失败则报错返回给前端。
• 前端在访问后台时设置钩子函数，当response返回了验证失败信息后，重定向到后端指定页面，并携带前端的回调地址。
• 重定向到后端的指定地址后，后端会进行用户登录授权，同cas进行交互，此时用户浏览器页面跳转顺序为: 前端->后端->cas server->后端->前端
• 在后端进行一系统用户信息的授权或者验证后，在cas server验证或者登录了用户信息，在后端得到并校验了token，获取到用户信息之后，记录用户信息，并生成一个signature，通过前端的回调地址进行重定向，并在url中携带了这个signature，前端获取到这个并生成一个signature并在下次访问后端接口时携带上，便可以获取资源了。
• 当前端需要登出时，调用后端登出接口，由后端完成所有登出操作，同时失效signature
• 当其他系统或者cas登出时，后端会收到登出请求，清除用户信息，并失效signature。

前端获取signature流程：

3,具体操作实例

参考 前端获取signature使用教程

五、当前的sso进度

• 非分离项目整合cas
  
  • 测试完成
  • 配置完成

• 分离项目整合
  
  • 测试完成
  • 配置完成

• cas server 源码改写
  
  • 支持参数传入tgc来设置cookie[1]

• cas client 依赖 源码改写
  
  • 支持当server端发送logout请求后同步清除signature
  • 支持未来移动端或者b/s端的统一登录
  • 目前无法实现移动端或者b/s端的统一登出，由于其与web端的特殊性分析其登出不需要跟web端统一登出。

• jira、confulence的对接
  
  • 待测试,理论可行,由于cas和jira等版本不同会出现兼容性问题，所以需要实际的测试。

六、针对jira和confulence的接入

cas 整合jira的原型已经测试成功，详情请见 cas整合jira演示说明
confulence未进行原型测试，相关配置是相同的。
cas 整合jira的安装步骤见 cas整合jira安装教程 ,其中jira版本为7.8.0 ,cas版本为5.2.7

七、未来的需求猜想

• cas server 集群: 未测试，后期版本的开发再研究考虑。
• b/s端，移动端项目的接入:暂时不考虑
• 项目集群后的session和signature的存储和同步: avatar一期暂时存储在自编写的Cache中，后期会使用redis进行存储，开发集群后会用redis进行session的共享。