起源
在一个企业发展的过程中,用到的系统会慢慢增多,使用人员在多个系统中操作时需要登录各个系统,而且可能每个系统账号都不一样,这对使用人员来说很不方便,于是就产生了单点登录,在一个系统登录其他的系统就不用登陆。
实现过程
在做单点登录之前先来回顾下单系统登录的操作,首先进入系统登录页面,填写登录信息提交表单,系统后台对账号密码进行验证,验证通过就会建立Session ,然后把sessionid通过cookie发送给浏览器,下次再请求系统时cookie会跟着发送过去,此时就已经知道该账号已经登陆了。
那么既然系统A已经登录认证过了,是不是再请求别的系统B时也就认证通过了呢?
首先要解决的是session共享问题,系统A认证登录过后在服务器中建立了一个session对应的当前会话,并把sessionId放到了cookie中返回给了浏览器,系统B显然是没有系统A的session的,此时可以使用Redis 把session缓存其中多个系统都共用。
session的问题解决了那么前端的cookie呢?浏览器请求系统A获得的cookie 是不能跨域请求到系统中B的。
cookie不能跨域,那么我们可以把这两个系统放到同一域名下,分为不同的二级域名。比如www.abc.OA.com 和www.abc.HR.com 它们的父级域名 www.abc.com。
但是考虑到多个系统架构不同,语言也可能不同,共享session 有点麻烦,且如果是不同域呢?有没有更好的方式呢?
此时引入正题,就是由耶鲁大学提出的CAS(Central Authentication Service)一个著名的SSO解决方案。
流程如下:
- 用户访问A系统,验证此用户未登陆。
- 重定向至cas,cas中也没有登陆,返回登陆页面
- 填写用户名、密码,cas进行认证后,产生一个Ticket(随机字符串认证用的)将登录状态写入cas的session,返回给浏览器cas下的Cookie,并将将Ticket放入URL中返回(如:www.a.com/pageA?ticket=123)
- 浏览器被重定向请求系统A,系统A拿着ticket去cas验证是否是伪造的,cas认证通过,在cas中注册系统A创建全局会话,并通知系统A验证通过。
- 系统A建立session,返回给浏览器系统A的cookie,并把浏览器请求的页面返回。
- 再次访问A系统另一个受限页面时因为浏览器中已携带该域cookie,则直接返回资源给浏览器。
验证后系统B登陆流程如下:
补充
CAS的SSO实现方式可简化理解为:1个Cookie和N个Session。CAS Server创建cookie,在所有应用认证时使用,各应用通过创建各自的Session来标识用户是否已登录。
ST(Service Ticket)
1、 ST只能使用一次
CAS协议规定,无论 Service Ticket验证是否成功, CAS Server都会清除服务端缓存中的该Ticket,从而可以确保一个Service Ticket不被使用两次。
2、 ST在一段时间内失效
CAS规定ST只能存活一定的时间,然后CAS Server会让它失效。默认有效时间为5分钟。
3、 ST是基于随机数生成的
ST必须足够随机,如果ST生成规则被猜出,Hacker就等于绕过CAS认证,直接访问对应的服务。
码农翻身读后感