标签：单点登录 bsp image 开发 ica 失败 操作 简单 重要
最近工作开始用到认证，写了一个关于登录的模块开发。以前也做过一些基于oauth2授权和oss这种登录操作。这里写个总结吧。
1 何为登录？
简单的单体登录就是输入个用户名、密码，然后和数据库做一个对比，如果正确就进入访问页面，如果失败就根据限制条件返回提示。
单体项目中用过shiro这种，所谓的realm域的概念就是这样的，通过生成token写入到浏览器session，也就是所谓的jsessionid，然后放入到浏览器的cookie中，设置一个过期失效的时间，这样就可以完成当下次登录请求来临的时候，直接验证jsessionid这样操作。
而在分布式场景和多个系统的时候，需要一个登录动作完成，多个系统都不用登录，也就是比如淘宝账号登录后，支付宝、天猫等也可以免登录这样的场景需求。
2 简单来说两类 认证类和授权类
像根据安全性需求不一样，就是所谓单体登录服务的强势程度，比如当外部资源借助微信账号登录，而微信账号数据强授权平台，它不会将很多的用户信息全部放给平台，因为它会按照用户和自己业务对该登录请求进行一个授权操作，也就是我们常用的oauth2这种。
也就是所谓强服务就会弱客户，而cas这种呢，就是客户端比较强势，会把用户一些重要的票据信息放入到客户端本身，服务端对其控制性不强。
本文也就主要讲一下cas
cas流程
先借个图（侵删）：
简单的说一下：
当客户端A请求访问，经过自己的过滤器，会向cas服务请求，检查发现cookie里面没有TGT信息，会进入到登录页面，同样的会对用户输入和服务端进行对比，当验证通过，cas服务会生成一个ticket（小）票据信息，TGT是大票自己存一份，会将ticket发给客户端，根据之前携带的请求信息重定向到原来要访问的页面，客户端会根据过滤器将ticket写入到cookie里面，这样就完成了第一请求。
当A再次请求的时候，因为之前有cookie在里面session，浏览器和客户端可以自由访问。而当B系统访问的时候，又会重定向到cas认证中心，因为上次登录过了，会从cookie里面携带TGC信息，发现TGC对应了一个TGT，于是会签发一个ticket给B客户端，这样B客户端同样获得操作，这样就可以喝浏览器愉快的玩耍了。
代理模式
当A请求直接访问B请求的时候，请求会被B的filter拦截进行重定向到cas，这样就回不到B请求页面了。提供了proxy代理式访问。
官网的大图。
Cas Proxy可以让我们轻松的通过App1访问App2时通过Cas Server的认证，从而访问到App2。其主要原理是这样的，App1先通过Cas Server的认证，然后向Cas Server申请一个针对于App2的proxy ticket，之后在访问App2时把申请到的针对于App2的proxy ticket以参数ticket传递过去。App2的AuthenticationFilter将拦截到该请求，发现该请求携带了ticket参数后将放行交由后续的Ticket Validation Filter处理。Ticket Validation Filter将会传递该ticket到Cas Server进行认证，显然该ticket是由Cas Server针对于App2发行的，App2在申请校验时是可以校验通过的，这样我们就可以正常的访问到App2了。
就先写到这吧
标签：单点登录 bsp image 开发 ica 失败 操作 简单 重要
原文地址：https://www.cnblogs.com/wangxiaobobo/p/14300302.html
