CAS第一天入门

1. CAS的直观认识

主要参考：
CAS的官网
CAS的视频教程

CAS的结构

CAS基础图解

a) CAS Server

用于完成对用户信息的认证，需要单独部署（本次学习中使用tomcat进行部署）。本质上CAS Server就是安装在服务器端的一个Web程序，它处理用户名/密码等凭证（与用户交互认证身份及其对应的Service）,向服务器发送相应的认证包（Service及Ticket），并在收到服务器确认的Service与Ticket之后向服务器发送相应用户信息。

b) CAS Client

用于在服务器端中辅助CAS Server。主要工作包括访问网站时的重定向，收到认证包时验证认证包是否有效（其中Client中存储CAS两边协商的Service）若认证成功则将认证包发送给CAS Server，当收到用户信息后执行相应Service的登陆控制工作。

2. CAS系统支持的协议

其中目前主要感兴趣的在于CAS协议及SAML协议。CAS协议可以实现代理认证（proxy authentication），SAML协议可以实现单点登出。

简述代理认证

代理认证
*考虑这样一种场景：有两个应用App1和App2，它们都是受Cas Server保护的，即请求它们时都需要通过Cas Server的认证。现需要在App1中通过Http请求访问App2，显然该请求将会被App2配置的Cas的AuthenticationFilter拦截并转向Cas Server，Cas Server将引导用户进行登录认证，这样我们也就不能真正的访问到App2了。针对这种应用场景，Cas也提供了对应的支持。
*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了。