一、标准流程描述

CAS官网的标准流程：

流程描述：

First Access：

第一次访问app.example.com（service地址），请求参数中session为空，app service没做过权限认证，所以重定向到CAS认证服务（cas.example.com/cas/login），经过URL编码的service地址作为参数一同传过去；
浏览器接收到重定向请求，跳转到CAS认证服务，因为请求参数中session为空，没有TGT信息，所以该用户没有登陆过。返回CAS的login页面；
用户在login页面提交后，用户名和密码提交到CAS，CAS对用户进行校验，通过之后生成一个TGT，并将它作为CAS的session key。重定向到service地址，参数为CAS提供的ST。
第二次访问app.example.com，这次携带了ST参数。app系统调用CAS的ServiceValidate服务，参数为service地址和ST。CAS通过ST验证，将ST，service地址以及新生成的app系统的局部sessionid存储到CAS数据库中（注销时用到），同时返回一个xml文件，包含了成功标识，认证对象和其他自定义的属性。app系统将ST和认证信息封装到局部session里，sessionid为CAS数据库中刚刚生成的那个。重定向到service地址。
第三次访问app.example.com，这次携带了sessionid。app系统通过session校验，返回请求的资源。

注：第3步和第4步中，CAS给用户提供了ST，用户又拿着ST到CAS进行ServiceValidate鉴权，可能会觉得多此一举。这是为了防止用户伪造ST。app系统并不知道用户访问时携带的ST是否合法（有可能是我们直接在地址栏输入的），所以需要再去CAS里询问一下，该用户是否有效。

Second Access To Same App：

携带session信息访问app系统，和单系统的权限认证模式相同，不需要再经过CAS认证。

First Access To Diff App：

第一次访问app2.example.com，未携带局部session信息，重定向到CAS认证服务（cas.example.com/cas/login），经过URL编码的service地址作为参数一同传过去，由于浏览器有CAS的全局session信息（TGT），直接通过CAS的用户校验，之后重定向到service地址，参数为CAS提供的另一个ST，之后的步骤相同。

流程类比：

CAS的login页面相当于大厦的保安处，大厦需要出入证才能进入（CAS session），CAS相当于接待大厅，app和app2相当于具体的部门楼层，需要各自的部门出入证（app session）才能进入。TGT相当于进入大厦的申请单，ST相当于进入部门的申请单。

第一次要去app部门的时候，没有大厦出入证，会被重定向到保安处，填写申请单（TGT），接待大厅判断此人是否是本公司员工，如果是的话将员工的申请单信息录入大厦出入证（CAS session）中，并发给员工。同时将员工进入app部门的申请单（ST）也发给员工。到达app部门时，部门接待处会向接待大厅验证申请单的合法性，确认是合法申请单时接待大厅会对员工信息做登记（存储到CAS数据库），告诉部门接待处已经成功通过验证并登记成功。部门接待处将员工信息录入到部门出入证（app session）中，发给员工。员工拿着部门出入证，进入部门。

第二次要去app部门的时候，如果有部门出入证（app session），可以一路绿灯直接进入。

第一次要去app2部门的时候，由于只有大厦出入证（CAS session），所以需要到接待大厅领取进入app2部门的申请单（ST），再去app2部门申请出入证（app session）。

注：

出入证都是一式两份。接待处一份，员工一份。

任何一方（接待处或员工）的大厦出入证失效后，所有的出入证都必须重新办理。

申请单是有时限的，当申请单过期时，必须重新填写申请单，领取出入证。