Cas原理备忘-

cas原理和流程

经常有新人问我cas的原理，解释了很多遍，有时候会很不耐烦。恰好看到文章单点登陆服务端搭建教程用文字描述的很细致，所以顺手抄录了其中的关键描述。目的是以后有人问，直接把摘录的blog扔给他。

---

1. 用户通过browser请求cas client A端的资源。

2. client A端发现用户未登录(client没有收到ST)，redirect到cas server，并且把用户请求服务的url发送给server；server发现用户浏览器中没有TGC(Ticket Granting Cookie)，就跳转到登录页面。

3. 用户在登录页面登录并登录成功。

4. server在用户的浏览器中设置一个TGC(Ticket Granting Cookie)，并且在server端保存一个TGT(Ticket Granting Tciket)，然后把用户重定向到{client A网址+ST(Service Ticket)}，其中ST是由TGT生成的。

5. client A端通过GET的方法收到ST，向server端验证这个ticket的有效性，这一步主要是为了防止恶意用{client网址+杜撰的ST}来访问client A，所以虽然ST是server发送给client A的，client A仍然需要向server验证其有效性。

6. ticket有效，server端返回ticket对应的用户的用户名，client A端为用户提供请求的服务。

上述是未登录的用户访问client A的过程，用户通过以上步骤已经登录了CAS系统，此时他访问CAS系统中信任的client B端，是不用登录的，实现步骤如下：

---

1. 用户通过browser请求cas client B端的资源。

2. client B端发现没有收到ST，redirect到cas server，并且把用户请求服务的url发送给server；server发现用户浏览器中有TGC(Ticket Granting Cookie)，验证该TGC后，用server端存储的TGT生成一个ST。

3. server把用户重定向到{client B网址+ST(Service Ticket)}。

4. client B端通过GET的方法收到ST，向server端验证这个ticket的有效性.

5. ticket有效，server端返回ticket对应的用户的用户名，client B端为用户提供请求的服务，这样用户就不用再次登录就可以访问到client B了。

所以从上述过程中，可以看到client端既不能接触到用户的用户名密码，也不能接触到用户的凭证TGT或者TGC，它只做两件事情：如果用户的请求里有ST，那么就向服务器验证ST的有效性；如果用户的请求里没有ST，那么就把用户重定向到cas server；

---

cas server全权负责管理用户的用户名和密码，如果发现用户的浏览器里面有有效的TGC，就生成ST把用户重定向到client端；如果用户浏览器里面没有TGC或者TGC无效，就让用户重新登录，然后在用户的浏览器里面设置新的TGC。而server和用户浏览器之间的交互是https安全协议，这样就保证了用户的用户名密码的安全性。