CAS单点登录原理解析

CAS单点登录原理解析

    SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。CAS是一种基于http协议的B/S应用系统单点登录实现方案，认识CAS之前首先要熟悉http协议、Session与Cookie等Web开发基本知识。

1.http协议

    HTTP是一个客户端和服务器端请求和应答的标准，我们全后端开发对接的Rest接口就是基于http协议。http协议包含http请求消息（HttpRequest）和http应答消息（HttpResponse）两部分。参考内容：https://www.cnblogs.com/rayray/p/3729533.html

• 理解http协议是无状态协议的含义
• 熟记常见的http协议状态码，其中302等与cas相关
• 熟记常见的http请求头，其中Cookie等与cas相关
• 熟记常见的http应答头，其中Set-Cookie、Location等与cas相关

2.Session与Cookie会话机制

    http协议本身是无状态的，但有时候我们需要http请求保持状态，我们引入Session与Cookie。
Session用在服务端，用于存储当前所有客户端需要保持的状态值，并为每一个客户端生成一个唯一编码，然后通过http响应头Set-Cookie将这个编码发送给客户端。

    Cookie用在客户端，用于记录后端发来过的唯一编码，该编码与服务端上的对应的状态值对应，在下一次请求的时候通过http请求头Cookie带上这个编码，服务端就能根据这个编码获取该客户端之前记录的所有状态值。

3.普通登录

    登录成功后，在Session中写入登录用户的信息，退出时清空Session中的用户信息。可以通过filter实现。

4.CAS单点登录| 两次前端跳转、一次后端验证

4.1首次访问（访问第一个应用系统App1）

    CAS首次登录会经过两次前端跳转、一次后端验证。在应用系统端需要集成CasClient的jar包，把其中的filter配置到站点web.xml中，用于拦截请求、判断登录、发起跳转或发起验证等。在SSO服务器上部署CasServer的war包，需要配置用户数据源，根据需求修改登录页面。

   第一次前端跳转：客户端访问应用系统，应用系统判断Session发现未登录，返回302跳转到sso登录页面，并传递service参数给sso，该service参数有两个作用：

1. service一般传递应用系统url地址，用于sso认证通过后回跳到应用系统；
2. service参数同时会被cas服务端的作为cas客户端的唯一标记记录下来，用于后期匹配相应的认证凭据；

   第二次前端跳转：浏览器显示登录页面，用户输入账号密码登录成功后，sso会返回302跳转回到原来请求的应用系统页面，并携带ticket参数，作为认证票据，同时通过Set-Cookie向浏览器记录TGT，（TGT的作用将在下一个应用系统需要登录的时候体现出作用，是避免重复登录的关键）

    一次后台验证：应用系统接收到带有ticket的请求后，从后台直接向sso服务器发起一个http请求，将service和ticket作为参数，用于验证ticket的有效性；如果ticket有效，sso服务器将返回该ticket对应的登录用户名。

4.2再次访问（访问第二个应用系统app2）

    当用户已经登录过一个应用系统以后，在同一个浏览器上访问第二个应用系统，根据单点登录的要求此时不应该再登录，而是直接进入第二个系统。但是实际上还是需要经过两次前端跳转、一次后端验证，只不过此时的两次跳转是连续的，中间不会再出现登陆页面，用户感受不到。判断的依据就是前面第4步通过Set-Cookie保存到客户端的TGT（Ticket Granted Cookie ）。

    相比首次访问，少了之前的第3步(不需要再出现登录页面)，因为此时在第二步跳转时，携带了之前保存的TGT，cas服务端通过TGT可以得知用户信息，因此直接生成ticket返回给应用系统。所以此时是两次连续的302跳转，用户看到的效果就是直接进入第二个应用系统了。

5. 案例讲解

5.1 循环跳转异常案例

    异常现象说明：某项目前后端分开部署出现这样一个现象，前端映射域名为http://xxx.abc.cn/gl，后端映射域名为http://xxx.abc.cn/gl/rest，单独访问后端登录没有任何问题，但是访问前端登陆后界面出现反复跳转不停刷新的问题。

    异常排查：循环跳转原理，SSO登录后返回应用系统，应用系统后台认证获取用户信息存入Session，由于某种原因造成Session信息丢失，导致应用系统认为还未登录，于是又跳转SSO，此时SSO已经登录不会再出登陆页面，直接生成ticket返回应用系统，应用系统Session再次丢失，进入反复跳转认证的死循环，前端界面表现为不停的刷新。

    因此关键问题在于分析Session信息丢失的原因，一般来讲有两种可能：1是系统本身逻辑问题把之前写入Session的登录信息清空了，2是两个站点的cookie作用域相同而相互覆盖，从而导致后台Session被重置。

    分析发现该项目属于第二种情况，前后端cookie都在http://xxx.abc.cn/域下面，解决办法修改cookie作用域或者修改cookie中Jsessionid的命名，防止相互覆盖。