一、什么是CAS
CAS及单点登录服务。用户只要到CAS认证一次,即可以在不同的平台应用中跳转,不需要二次输入密码。门户使用CAS是由于需要接入供应链平台。供应链平台主要为企业商户提供贷款服务,接入CAS后,商户通过门户登录后,可通过相应链接直接登录到供应链平台,而不需要进行二次登录;同时,门户注销登录后,供应链管理平台也将同步注销。
二、CAS的意义:
日后对于基于企业账户的平台应用都可以接入CAS,由CAS做统一的登录验证,而不需要每个应用都做自己的登录验证(都是基于同样的账户,同样的管理)。例如:门户的交费易和资金归集两个产品线可以考虑拆分成两个应用,对于双产品线的商户登录资金归集应用后,可以通过链接直接转跳交费易应用。
三、CAS集群的需要:
CAS作为企业账户平台的认证中心,所有引用系统的认证工作,都将请求到CAS来完成。因此CAS服务器是整个应用的关键节点,CAS发生故障,所有系统都将无法登陆。同时,CAS的负载能力要足够强,能够承担所有的认证请求响应。
利用负载均衡和集群技术,不仅能克服CAS单点故障,同时将认证请求发布到多台CAS服务器上,有效减轻单台CAS服务器的请求压力。
四、CAS的工作流程:
1、用户登录CAS客户端应用(例如门户),门户判断用户没有登录(无Session),重定向到CAS服务器。
2、CAS服务器检查用户没有响应的票据,引导用户进入登录页面(CAS的登录页面)。
3、用户输入用户名、密码进行登录。
4、CAS服务器认证成功,生成TGT(登录CAS的票据)写入用户的Cookie,
1、 同时重定向到门户,带上了ST(登录门户的票据)
2、 门户请求CAS验证该ST有否有效
3、 如果ST有效,门户创建相关的session
4、 登录成功,用户进入门户页面
5、 用户点击门户中的供应链的链接,转跳到供应链平台
6、 供应链平台检查用户未登录供应链,重定向到CAS
7、 因为用户的Cookie 中有票据(TGT),所以CAS验证用户之前已经登录,所以无需转跳登录页面,而是生成ST。然后重定向会供应链。
8、 供应链拿着ST到CAS验证有效性
9、 ST有效,则供应链创建相关的Session
10、 用户登录供应链成功。
CAS单点登录主要是基于票据(Ticket)来实现的。因为要实现CAS集群,必须要多台CAS之间共享所有的Ticket,目前门户的CAS票据是存储在数据库中来实现共享的,同时,CAS使用SpringWebFlow作为认证流程,而webflow需要使用session存储流程相关信息,所以要实现CAS的Session共享。目前使用的是tomcat的默认的session共享(使用组播)。
五、上线CAS过程遇到的问题及解决方案:
1、CAS登录使用的是https,首次上线时CAS所在的F5未挂https证书,导致重定向CAS时报错。 解决方案:在F5的VS上挂https证书。
2、门户拿ST票据到CAS做票据验证时,报错:找不到路由No route to host。与网络组沟通后,明确是因为是http post请求时,从 b.bestpay.com.cn 到 b.bestpay.com.cn(自己找自己是找不到的,因为没有相关路由)。 解决方案:把验证票据的CAS地址改为内负载,走http
3、改为内负载后,再次升级,发现依然报错java.net.SocketException: Unexpected end of file from server。后来明确错误是,原来的CAS内负载端口是挂了https证书的,使用http方式的话是走不通的。解决方案:新建一个内负载,该负载不挂https证书,专门供票据验证使用。
4、验票据使用新的内负载地址,其他浏览器可以登录CAS服务器(此时只是开了一台CAS应用),但IE浏览器无法登录。定位是IE下,相同的二级域名之间服务转跳引起。 解决方案: 为CAS申请一个新的二级域名
5、两台CAS服务器都启动后,用户登录门户存在二次登录的问题。即输入用户名密码提交后,页面刷新,要重新输入才可以登录。 定位问题是:CAS的Session共享有问题,应用服务器使用多网卡或虚拟网卡的话,需要修改tomcat的组播默认配置。
6、单点登录解决后,发现单点退出有问题。即门户退出后,发请求到CAS,CAS通知供应链做退出。 定位问题是: CAS通知供应链时,发送的是http post,使用的是 https://loan.bestpay.com.cn 。取的是登录时候的供应链服务器地址。发现还是找不到域名,需要走内负载,但CAS去退出的服务器地址服务通过配置文件进行配置,只能修改CAS源码做一个地址映射。及发送退出通知到供应链时,将https 地址映射成 http内负载地址