cas单点登录实现原理

与CAS结合使用的意义
web应用中一个登陆过程，其实就是完成认证与授权。
所谓认证，就是当用户试图进入系统，而系统发现用户没有登陆，就调转到登陆页面。
所谓授权,指用户认证通过之后对该用户赋权限，即该用户能够访问这个系统的哪些功能（即该用户能够访问这个系统的哪些url地址及按钮）
Cas它的功能就是进行用户名密码认证。如果与cas集成，就相当于自身的登录认证功能转移到cas框架上，然后进行认证之后的授权。
CAS原理和协议基础模式
基础模式SSO访问流程主要有以下步骤：
1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。
3. 用户认证：用户身份认证。
【cas单点登录实现原理】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应用可以代理用户去实现后端的认证，而无需前端用户的参与。