XX移动非法票据问题的处理方案分享

1.问题描述
IAM的集中认证服务CASP为了提高处理性能，引进了JCS缓存机制，设计初期CASP服务由于实际部署结构简单（一般是单机部署），JCS缓存机制的可以满足使用场景。随着项目的逐步发展，IAM的用户量越来越大，CASP的认证压力也越来越大，因此项目部署结构需要升级成多机分布式，用于满足这种不断提高的性能要求，分布式部署结构的弊端导致了JCS缓存数据的分离，对于认证的核心票据就没有办法集中管理。
为了解决核心业务票据的分布式问题，CASP增加了票据转发处理的机制，间接的实现了票据的共享，但是在票据转发的过程中由于代码处理逻辑不当，导致票据的转发无法正常验证通过，部分用户单点登录资源不成功，提示“非法票据”。

序号	概念	全称	中文描述
	JCS缓存		本机缓存
	身份根票据		用户身份凭证
	单点登录票据		携带根票据的传输票据
	CASP票据生成
	CASP票据转发		20008端口
	CASP票据验证
	负载均衡服务		F5
	应用单点登录		携带票据单点登录票据到第三方应用系统

2    问题拆解分析
运用管理工作中的5W1H来具体描述：
2.1    What 发生了什么
2.1.1    身份与票据的关系
用户经过认证成功登录进入IAM后，在用户会话Session中保存了当前用户的身份信息（根票据），用户登出IAM后根票据自动回收。根票据存在于运行时用户的整个生命周期里，作为用户合法身份的凭证。
 
2.2    Who 谁执行的操作
用户主帐号，根票据身份的主人。
2.3    When 什么时间发生异常
IAM正常登录后，根票据保存在会话缓存中，正常情况IAM内部是不需要再次验证用户身份的，当用户发起单点登录，跳转到三方应用系统的时候，根据认证规范，需要对用户的身份做合法性校验。
2.4    Where 在哪里发生的异常
IAM正常登录后，生成根票据并缓存，只有在跳转到第三方系统的情况下，第三方系统内部为了放行用户登录，需要回到CASP验证根票据，从而验证用户的合法身份。。
跳转到三方系统的时候，先将根票据封装成单点登录票据进行传输
 
三方系统接收到单点登录票据字符串后，经过四步处理
参见下图第四步
 
2.5    Why 为什么会出现非法票据
CASP单机部署，就不存在这个问题。
因为大型项目中CASP采用分布式架构部署，但是票据的JCS缓存都是在CASP各自的主机，并没有集中管理，导致无法共享验证票据；后来引入了转发票据的机制，转发的依据就是构造根票据的时候缓存在票据对象中的CreateServerIP值，整个问题就发生在转发票据请求的过程中，根票据没有被转发到生成它的CASP主机，导致无法验证，所以出现了非法票据。
2.5.1    票据的缓存和CASP的部署

2.6    How 怎样发生的
用户主帐号进行单点登录，请求携带单点登录票据到第三方系统，第三方系统请求F5负载IP，负载分发到随机一台CASP来验证用户身份，对比票据携带的IP不是本机生成的根票据的时候，就会立刻转发，此时对比解析出来的IP如果是0.0.0.0，就会无限循环连接本机20008端口，直到自占用到资源耗尽，并且导致其他CASP请求本机20008端口票据验证也不通过，陷入死循环，验证票据服务瘫痪，一旦有请求发过来，就直接非法票据。
3    问题定位
3.1    正常的票据转发过程
下图为举例，详见代码
 
 

 

3.2    发现定时炸弹0.0.0.0
 
 
 

CASP启动过程中，得到本机IP（localAddr）的逻辑没有经过项目上多种情况的验证，会导致出现null的情况，这时在使用本机IP拼装到根票据的时候，就没有可以使用的值，系统默认使用了0.0.0.0，0.0.0.0就像一个危险的定时炸弹，一旦抛出，就循环占用本机的20008端口，当前请求无限循环，并且也占用了其他设备请求当前CASP验证票据的资源。
网上的解释：
一个非常特殊的IP：0.0.0.0
这个IP相当于java中的this，代表当前设备的IP。

严格说来，0.0.0.0已经不是一个真正意义上的IP地址了。
它表示的是这样一个集合：
1、所有不清楚的主机和目的网络。这里的“不清楚”是指在本机的路由表里没有特定条目指明如何到达。
2、对本机来说，它就是一个“收容所”，所有不认识的“三无”人员，一律送进去。
3、如果在网络设置中设置了缺省网关，那么Windows系统会自动产生一个目的地址为0.0.0.0的缺省路由。
4    问题解决
4.1    更正异常代码逻辑
把CASP本机的IP固定化，写入配置文件，防止代码运行时发生的各种不确定异常
 
4.2    搭建集中化缓存服务，替代原有的JCS
三级部署拓扑图如下：