cas单点登录实现原理

与CAS结合使用的意义

web应用中一个登陆过程，其实就是完成认证与授权。

所谓认证，就是当用户试图进入系统，而系统发现用户没有登陆，就调转到登陆页面。

所谓授权,指用户认证通过之后对该用户赋权限，即该用户能够访问这个系统的哪些功能（即该用户能够访问这个系统的哪些url地址及按钮）

Cas它的功能就是进行用户名密码认证。如果 与cas集成，就相当于 自身的登录认证功能转移到cas框架上，然后 进行认证之后的授权。

CAS原理和协议 基础模式

基础模式SSO访问流程主要有以下步骤：

1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。

2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。

3. 用户认证：用户身份认证。

4. 发放票据：SSO服务器会产生一个随机的 。

5. 验证票据：SSO服务器验证票据 的合法性，验证通过后，允许客户端访问服务。

6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

如上图：CAS 与受保护的客户端应用部署在一起，以方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求，同时，CAS 会分析HTTP请求中是否包含请求 ( ST上图中的) ，如果没有，则说明该用户是没有经过认证的；于是CAS 会重定向用户请求到 CAS （Step 2），并传递（要访问的目的资源地址）。 Step 3是用户认证过程，如果用户提供了正确的， CAS 随机产生一个相当长度、唯一、不可伪造的 ，并缓存以待将来验证，并且重定向用户到 所在地址（附带刚才产生的 ）,并为客户端浏览器设置一个 （TGC）；CAS 在拿到和新产生的 过后，在Step 5和Step6中与CAS 进行身份核实，以确保 的合法性。

在该协议中，所有与CAS 的交互均采用SSL协议，以确保ST和TGC的安全性。协议工作过程中会有两次重定向的过程。但是 CAS 与CAS 之间进行验证的过程对于用户是透明的（使用）。

各服务首次访问：若用户没有登录过执行以下图全部流程。若以在其他服务中登录则执行到下图第二步

同服务第二次访问（因为之前已创建,所以不会再去cas ）

CAS如何实现 SSO

当用户访问另一个应用的服务再次被重定向到CAS 的时候，CAS 会主动获到这个TGC ，然后做下面的事情：

1) 如果User持有TGC且其还没失效，那么就走基础协议图的Step4，达到了 SSO 的效果；

2) 如果TGC失效，那么用户还是要重新认证 (走基础协议图的Step3)。

辅助说明

CAS的SSO实现方式可简化理解为：1个和N个。CAS 创建，在所有应用认证时使用，各应用通过创建各自的来标识用户是否已登录。

用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在里读取到用户信息，所以就不会去CAS 认证。如果在此浏览器里访问别的web应用时，客户端应用中的过滤器在里读取不到用户信息，就会去CAS 的login接口认证，但这时CAS 会读取到浏览器传来的（TGC），所以CAS 不会要求用户去登录页面登录，只是会根据参数生成一个，然后再和web应用做一个验证的交互而已。

共享

可以通过Nginx+实现共享，这样既可以同步信息，又能使其他应用不用再做首次认证

Cas登录过期时间

1、修改Cas 的过期时间

修改Cas 下cas/WEB-INF/-/cies.xml（的过期时间，单位为秒）

p:ds="28800"

p:="1800"/>

2、修改Cas 的过期时间

向Cas 下WEB-INF/web.xml添加以下代码（过期时间，单位为分钟）：

30

CAS代理模式

该模式形式为用户访问App1，App1又依赖于App2来获取一些信息，如：User -->App1 -->App2。

这种情况下，假设App2也是需要对User进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致User的IE窗口不停地闪动)，CAS引入了一种Proxy认证机制，即CAS 可以代理用户去访问其它Web应用。

代理的前提是需要CAS 拥有用户的身份信息(类似凭据)。之前我们提到的TGC是用户持有对自己身份信息的一种凭据，这里的PGT就是CAS 端持有的对用户身份信息的一种凭据。凭借TGC，User可以免去输入密码以获取访问其它服务的 ，所以，这里凭借PGT，Web应用可以代理用户去实现后端的认证，而无需前端用户的参与。