jasig cas笔记（一）:基础（非代理）认证流程

单点登录的概念不再赘述。而关于jasig cas 的认证流程，其实十分简单明了，直接上图：

上图中几个角色分别为：user（用户）、browser(浏览器)、cas server(jasig cas认证服务)、（app1）应用1、(app2)应用2。

一、两个关键元素：ST、TGC
ST：即service ticket；用于验证用户认证状态的一种凭证。当用户请求某个应用的资源时，若该用户尚未认证，则在用户输入用户名密码进行身份认证，认证成功cas服务会返回一个ticket，访问应用的时候会在url带上这个ticket去cas进行验证，验证有效则允许访问应用资源。

TGC：即ticket-granting cookie；是一个由cas服务设置的cookie。TGC维护了客户端和cas服务的信任关系，当用户认证通过，则cas会在浏览器设置一个TGC，下次用户再次请求时则只需带上TGC，只要此TGC尚未失效，都无需重新认证，否则需再次进行用户名密码登录认证。简单来说，就是让客户机和cas服务建立一个会话（session），会话失效之前都无需重复认证，相当于平时常说的sessionid。

二、主要流程：
下面是基于用户操作的流程
1.用户请求访问app1，在地址栏输入http://app1.pt.com ,如果用户已经认证过且跟app1之间的会话尚未过期，则直接进入app1；如果用户尚未认证或与app1会话已失效，则重定向到cas服务：http://cas.com/login?service=http://app1.pt.com/authc (此处authc是app1中指定的验证ticket的地址)；

2.用户的浏览器发起get请求：http://cas.com/login?service=http://app1.pt.com/authc ，cas服务会向用户展现登录form；

3.用户输入用户名密码，提交至cas服务进行认证。认证不通过则重定向回刚刚的登录form，认证通过则由cas服务则设置一个cookie（TGC）。

4、cas生成一个ticket(ST)，并重定向至http://app1.pt.com/authc?ticket=ST-1818181 ;

5.浏览器向app1发出get请求：http://app1.pt.com/authc?ticket=ST-1818181 ，app1接收到ticket后再发送get请求到cas服务验证ST的合法性：http://cas.com/serviceValidate?service=http://app1.pt.com/authc?ticket=ST-1818181 ,cas服务进行ST验证成功后，返回一个状态为200的xml格式数据，浏览器就此确认ST验证成功。响应浏览器200OK，并在浏览器设置app1sessionid；

6.浏览器带上app1的sessionid则可访问app1的数据资源；

7.此时如果用户想获取同样被cas维护着的app2的数据资源：http://app2.pt.com/ ,将会重定向到http://cas.com/login?service=http://app2.pt.com/authc 并带上第三步设置的TGC，再和app1类似的重复第四步到第六步，获取app2的资源。要注意的是，cas为app1生成的ST跟app2并不不一定一致，或者说是相互独立的ST。至于app1与app2的session是否需要共享，那是另外的话题了。

cas认证流程到此结束！

以上是参考https://apereo.github.io/cas/development/protocol/CAS-Protocol.html 再结合自己的见解得出的总结，不当之处还请批评指正~