docs/protocols/cas.md

<h2>1 CAS简介</h2>

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：

CAS的目标是允许用户访问多个应用程序只提供一次用户凭据（如用户名和密码）。它还允许Web应用程序对用户进行身份验证，而不必获取用户的安全凭证，比如密码。

 <ol>
  <li>一个开放的，文档齐全的协议。</li>
  <li>开源的JAVA服务器组件。</li>
  <li>CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。</li>
  <li>与uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle等等能很好集成。</li>
  <li>文档社区化和实现的支持。</li>
  <li>具有广泛的客户群的支持。</li>
</ol>

扩展阅读参看：官方技术说明<a href="https://www.apereo.org/cas"  title="https://www.apereo.org/cas" target="_blank" rel="nofollow">CAS官方网站（en） </a> | <a href="http://en.wikipedia.org/wiki/Central_Authentication_Service"  title="http://en.wikipedia.org/wiki/Central_Authentication_Service" target="_blank" rel="nofollow">CAS维基百科（en）</a> 

<h2>2 CAS体系结构</h2>
CAS 体系包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。

<img src="{{ "/images/cas/1.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>

<h2>3 CAS原理</h2>
CAS 最基本的协议过程：

<img src="{{ "/images/cas/2.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
SSO单点登录访问流程主要有以下步骤：

1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。

2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。

3. 用户认证：用户身份认证。

4. 发放票据：SSO服务器会产生一个随机的Service Ticket。

5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。

6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适，以确保 Service Ticket 的合法性。

在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。

<h2>4 CAS中3个术语</h2>

Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在Server端

Ticket-granting cookie (TGC) ：其实就是一个Cookie，存放用户身份信息，由Server发给Client端

Service ticket (ST) ：由TGT生成的一次性票据，用于验证，只能用一次。相当于Server发给Client一张票，然后Client拿着这个票再来找Server验证，看看是不是Server签发的。
-												u

											
										
										
											2020-03-08 08:50:58 +08:00
+								<h2>1 CAS简介</h2>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
 								CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：
-												Update cas.md

											
										
										
											2020-03-07 23:43:37 +08:00
+								CAS的目标是允许用户访问多个应用程序只提供一次用户凭据（如用户名和密码）。它还允许Web应用程序对用户进行身份验证，而不必获取用户的安全凭证，比如密码。
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
-												Update cas.md

											
										
										
											2020-03-07 23:43:37 +08:00
+								 <ol>
 								  <li>一个开放的，文档齐全的协议。</li>
 								  <li>开源的JAVA服务器组件。</li>
 								  <li>CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。</li>
 								  <li>与uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle等等能很好集成。</li>
 								  <li>文档社区化和实现的支持。</li>
 								  <li>具有广泛的客户群的支持。</li>
 								</ol>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
-												U

											
										
										
											2020-03-08 09:00:25 +08:00
+								扩展阅读参看：官方技术说明<a href="https://www.apereo.org/cas"  title="https://www.apereo.org/cas" target="_blank" rel="nofollow">CAS官方网站（en） </a> | <a href="http://en.wikipedia.org/wiki/Central_Authentication_Service"  title="http://en.wikipedia.org/wiki/Central_Authentication_Service" target="_blank" rel="nofollow">CAS维基百科（en）</a>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
-												u

											
										
										
											2020-03-08 08:50:58 +08:00
+								<h2>2 CAS体系结构</h2>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
+								CAS 体系包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
-												Update cas.md

											
										
										
											2020-03-07 23:46:32 +08:00
-												Update cas.md

											
										
										
											2020-03-07 23:45:13 +08:00
+								<img src="{{ "/images/cas/1.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
-												u

											
										
										
											2020-03-08 08:50:58 +08:00
+								<h2>3 CAS原理</h2>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
+								CAS 最基本的协议过程：
-												Update cas.md

											
										
										
											2020-03-07 23:46:32 +08:00
-												Update cas.md

											
										
										
											2020-03-07 23:45:13 +08:00
+								<img src="{{ "/images/cas/2.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
 								SSO单点登录访问流程主要有以下步骤：
 . 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
 . 定向认证：SSO客户端会重定向用户请求到SSO服务器。
 . 用户认证：用户身份认证。
 . 发放票据：SSO服务器会产生一个随机的Service Ticket。
 . 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
 . 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。
-												Update cas.md

											
										
										
											2020-03-07 23:43:37 +08:00
+								CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份合适，以确保 Service Ticket 的合法性。
 								在该协议中，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程，但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
 								另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
-												u

											
										
										
											2020-03-08 08:50:58 +08:00
+								<h2>4 CAS中3个术语</h2>
-												cas

											
										
										
											2020-03-07 22:30:02 +08:00
 								Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在Server端
 								Ticket-granting cookie (TGC) ：其实就是一个Cookie，存放用户身份信息，由Server发给Client端
 								Service ticket (ST) ：由TGT生成的一次性票据，用于验证，只能用一次。相当于Server发给Client一张票，然后Client拿着这个票再来找Server验证，看看是不是Server签发的。