CAS协议 - Introduction、Conventions & Definitions、CAS Entities
1.Introduction:以下是
CAS1.0 和 2.0 协议的官方规范。
注： CAS1.0 和 2.0 协议大体包含两个方面的内容： 各种票根（Ticket）和暴露给 CAS 客户的 HTTP（S）URL 。这些 URL（/login、/logout、/validate、/serviceValidate、/proxy、/proxyValidate等）围绕着这些票根（ST、TGC、PGT、PT等）进行活动。在此期间服务和目标服务之间会进行多次 HTTPS交互。
Conventions & Definitions （公约和定义）
注：这里的 service 可以包含两部分：
按照翻译，不容易理解“目标服务”，通过下面的图可以很容易看清楚它的作用。
黄色区域指 Client ；
绿色区域指 Server ；
紫色区域指 Service 和 Proxy；
蓝色区域指 目标服务。
其中 CAS1.0 中没有目标服务这一块，也没有 Service 的 proxy ，也即不能进行代理认证。
3. CAS Entities
3.1. service ticket： ST 是一串繁杂的字符串，客户端用来作为凭证以获取访问的服务。ST 是CAS 根据客户端递交的凭证和服务标识符产生的。参见/login 第2.2 节。
3.1.1 . service ticket properties
3.2. proxy ticket： PT 是一串繁杂的字符串，代理服务器以PT为凭证代表客户端访问目标服务。 PT 是CAS 根据一个有效的PGT （第3.3 节），以及一个可连接的目标服务标识符产生的。
3.2.1 . proxy ticket properties
3.3. proxy-granting ticket: PGT 是一串繁杂的字符串，某个服务使用它获取PT ， 用PT 代表客户端去访问目标服务。PGT 的获取必须来自验证ST 或PT 通过后才行。PGT 的发放在第2.5.4 节已经详细描述过。
3.3.1 . proxy-granting ticket properties
3.4. proxy-granting ticket IOU: PGTIOU 是一个繁杂的字符串，放置在/serviceValidate 和/proxyValidate 访问时的XML 回复里， 使用它可以获得同它绑定在一起的PGT， 继而得出PT 或者ST 。参阅第2.5.4 节。
3.4.1 . proxy-granting ticket IOU properties
3.5. login ticket: LT 是一个字符串，是由/login 作为凭证索取者提供的，并且通过作为凭证接收者的/login 做用户名/ 密码验证。其目的是为了防止因为Web 浏览器的BUG 导致用户输入的用户名、密码被重用。
3.5.1 . login ticket properties
3.6. ticket-granting cookie: TGC 是由CAS 建立在SSO 会话上的一个HTTP 的cookie 。此Cookie 保持客户端的登录状态，当它是有效的时候，客户端可以把它提交给CAS 以代替主认证证书。通过设置“renew ”参数，服务可以选择退出SSO ，说明见2.1.1 ，2.4.1 和2.5.1 。
3.6.1 . ticket-granting cookie properties
3.7. ticket and ticket-granting cookie character set: 上面所说的CAS 的所有凭证还有TGC 都必须遵循如下的字符集。
{A-Z, a-z, 0-9, and the hyphen character ?-'}.
转自：
CAS Protocol - 官网
CAS协议介绍中文版 - 百度文库
CAS协议分析 - 百度文库
JASIG CAS协议介绍 （1）-CAS Entities
JASIG CAS协议介绍 （2）-/login和/logout
JASIG CAS协议介绍 （3）--/validate和/serviceValidate
JASIG CAS协议介绍 （4）- /proxyValidate 和 /proxy
注： CAS1.0 和 2.0 协议大体包含两个方面的内容： 各种票根（Ticket）和暴露给 CAS 客户的 HTTP（S）URL 。这些 URL（/login、/logout、/validate、/serviceValidate、/proxy、/proxyValidate等）围绕着这些票根（ST、TGC、PGT、PT等）进行活动。在此期间服务和目标服务之间会进行多次 HTTPS交互。
Conventions & Definitions （公约和定义）
- “Client” 指的是终端用户或者是 WEB 浏览器。
- “Server”指的是统一认证服务所在的服务器。
- “Service” 指的是终端用户或者 WEB 浏览器试图访问的应用 .
- “Proxy” 指的是作为代理的服务，用户通过该服务（代理）访问Back-end service（后端应用）
- “Back-end service” 是指用户通过代理访问的应用，这个应用就被称为后端服务（Back-end service） 。它也被称作“target service”目标服务。
注：这里的 service 可以包含两部分：
- 一是应用程序本身提供的 service
- 二是应用程序本身还可提供代理服务，使 Client 能够通过它（代理）访问目标服务。
按照翻译，不容易理解“目标服务”，通过下面的图可以很容易看清楚它的作用。
黄色区域指 Client ；
绿色区域指 Server ；
紫色区域指 Service 和 Proxy；
蓝色区域指 目标服务。
其中 CAS1.0 中没有目标服务这一块，也没有 Service 的 proxy ，也即不能进行代理认证。
- 1， Step1：用户通过浏览器请求登陆【CAS认证中心】
- 2， Step1-Response：【CAS认证中心】返回TGC或者ST
- 3， Step2：用户使用TGC或者ST登陆【门户网站】
- 4， Step3：【门户网站】向【CAS认证中心】请求验证TGC或者ST，同时传递pgtUrl并申请PGT
- 5， Step3-A Callback：【CAS认证中心】通过https访问代理回调接口pgtUrl，并通过参数的形式传递pgt和pgtIou给Proxy
- 6， Step3-Response：返回验证结果及PGTIOU
- 7， Step4：Step3-A Callback和Step3-Response返回的pgtIou一致，由此【门户网站】获得PGT,【门户网站】通过PGT向【CAS认证中心】请求PT
- 8， Step4-Response：【CAS认证中心】返回用户对Mail IMAP服务的PT
- 9， Step5：【门户网站】以作为代理角色，传递参数PT并申请访问Mail服务
- 10， Step5-A：Mail服务向【CAS认证中心】请求使用PT验证Proxy的身份
- 11， Step5-A-Response：【CAS认证中心】返回验证结果：用户ID和PGTIOU
- 12， Step5-B Callback：【CAS认证中心】生成PGT，回调链接向Mail服务提交PGT使其拥有二级代理的权限？？？？
- 13， Step5-Response：返回用户的Mail信息
3. CAS Entities
3.1. service ticket： ST 是一串繁杂的字符串，客户端用来作为凭证以获取访问的服务。ST 是CAS 根据客户端递交的凭证和服务标识符产生的。参见/login 第2.2 节。
3.1.1 . service ticket properties
- 只有/login 追加了service 标识符，CAS 才会生成ST 。服务标识符应不属于ST 。
- ST 只能被尝试验证一次。无论验证是否成功，CAS 必须使该ST 无效，并且要使得今后拒绝再验证同一个ST 。
- CAS 应该能在一段合理的时间内终止一个没有验证通过的ST 。如果一个服务使用了过期的ST ，CAS 必须作出反应，返回必须是验证失败。
- 推荐：验证的响应应该包括一个描述消息，解释为什么验证失败。
- 推荐：其长度不能超过5 分钟。要结合本地安全和CAS 的使用情况来考虑确定验证失败的ST 的生命周期。
- 服务车票必须包含足够的安全随机数据。
- 服务票，首字符必须是 “ ST- ” 。
- 必须超过32 个字符的长度。推荐：256 个字符的长度。
3.2. proxy ticket： PT 是一串繁杂的字符串，代理服务器以PT为凭证代表客户端访问目标服务。 PT 是CAS 根据一个有效的PGT （第3.3 节），以及一个可连接的目标服务标识符产生的。
3.2.1 . proxy ticket properties
- 只有在目标服务的URL 传入/proxy 时，才是有效的PT 。服务标识符应不属于PT 。
- PT 只能被尝试验证一次。无论验证是否成功，CAS 必须使该PT 无效，并且要使得今后拒绝再验证同一个PT 。
- CAS 应该能在一段合理的时间内终止一个没有验证通过的PT 。如果一个服务使用了过期的PT ，CAS 必须作出反应，返回必须是验证失败。
- 推荐：验证的响应应该包括一个描述消息，解释为什么验证失败。
- 推荐：其长度不能超过5 分钟。要结合本地安全和CAS 的使用情况来考虑确定验证失败的ST 的生命周期。
- proxy ticket必须包含足够的安全随机数据。
- proxy ticket首字符应该是“ PT- ”。proxy ticket首字母可以是PT 或者 ST
- 必须超过32 个字符的长度。推荐：256 个字符的长度。
3.3. proxy-granting ticket: PGT 是一串繁杂的字符串，某个服务使用它获取PT ， 用PT 代表客户端去访问目标服务。PGT 的获取必须来自验证ST 或PT 通过后才行。PGT 的发放在第2.5.4 节已经详细描述过。
3.3.1 . proxy-granting ticket properties
- PGT 可以用来多次获取PT ，PGT 不是一次性使用的票据。
- 被代理的认证客户端如果登出了CAS ，PGT 必须被终止。
- PGT 必须包含足够的安全随机数据，使它在一段合理的时间内不被外力攻击得到。
- PGT 首字符应该是 “ PGT- ” 。
- 必须超过64 个字符的长度。推荐：256 个字符的长度。
3.4. proxy-granting ticket IOU: PGTIOU 是一个繁杂的字符串，放置在/serviceValidate 和/proxyValidate 访问时的XML 回复里， 使用它可以获得同它绑定在一起的PGT， 继而得出PT 或者ST 。参阅第2.5.4 节。
3.4.1 . proxy-granting ticket IOU properties
- PGTIOU 中不应该包含与PGT 相关的任何痕迹，给你一个PGTIOU ，不应该在一个合理的时间段内，按照一定的算法得出与之绑定的PGT 。这是为了保证系统的安全。
- PGT 必须包含足够的安全随机数据，使它在一段合理的时间内不被外力攻击得到。
- PGTIOU 的首字符是 “ PGTIOU - ” 。
- 服务必须能够处理最多64 个字符长度的PGTIOUs 。建议支持最多256 个字符的长度。
3.5. login ticket: LT 是一个字符串，是由/login 作为凭证索取者提供的，并且通过作为凭证接收者的/login 做用户名/ 密码验证。其目的是为了防止因为Web 浏览器的BUG 导致用户输入的用户名、密码被重用。
3.5.1 . login ticket properties
- 由/login 传出的LT 必须是唯一的。
- LT 的有效期只能在一次认证尝试期间。无论是否认证成功，CAS 必须使该LT 立即失效，并且要使得今后拒绝再验证同一个LT 。
- LT 首字符必须是 “ LT- ”。
3.6. ticket-granting cookie: TGC 是由CAS 建立在SSO 会话上的一个HTTP 的cookie 。此Cookie 保持客户端的登录状态，当它是有效的时候，客户端可以把它提交给CAS 以代替主认证证书。通过设置“renew ”参数，服务可以选择退出SSO ，说明见2.1.1 ，2.4.1 和2.5.1 。
3.6.1 . ticket-granting cookie properties
- TGC 必须在客户端浏览器的session 结束时终止。
- CAS 设置cookie 的路径是有局限性的。例如，如果CAS 服务器的路径设置为/cas ，则Cookie 的路径必须设置为/cas 。
- TGC 都必须包含足够的安全随机数据，以保证它在一个合理的时间内不被推测出来。
- TGC 开始字符应该是 “ TGC- ” 。
3.7. ticket and ticket-granting cookie character set: 上面所说的CAS 的所有凭证还有TGC 都必须遵循如下的字符集。
{A-Z, a-z, 0-9, and the hyphen character ?-'}.
转自：
CAS Protocol - 官网
CAS协议介绍中文版 - 百度文库
CAS协议分析 - 百度文库
JASIG CAS协议介绍 （1）-CAS Entities
JASIG CAS协议介绍 （2）-/login和/logout
JASIG CAS协议介绍 （3）--/validate和/serviceValidate
JASIG CAS协议介绍 （4）- /proxyValidate 和 /proxy