CAS协议 - Introduction、Conventions & Definitions、CAS Entities

[b]1.Introduction[/b]:以下是 [color=red]CAS1.0 和 2.0 协议[/color]的官方规范。
注： CAS1.0 和 2.0 协议大体包含两个方面的内容：[color=red]各种票根（Ticket）和暴露给 CAS 客户的 HTTP（S）URL[/color] 。这些 URL（/login、/logout、/validate、/serviceValidate、/proxy、/proxyValidate等）围绕着这些票根（ST、TGC、PGT、PT等）进行活动。在此期间服务和目标服务之间会进行多次[color=red]HTTPS[/color]交互。

[b]Conventions & Definitions （公约和定义）[/b]
[list]
[*]“Client” 指的是终端用户或者是 WEB 浏览器。
[*]“Server”指的是统一认证服务所在的服务器。
[*]“Service” 指的是终端用户或者 WEB 浏览器试图访问的应用 .
[*]“Proxy” 指的是作为代理的服务，用户通过该服务（代理）访问Back-end service（后端应用）
[*]“Back-end service” 是指用户通过代理访问的应用，这个应用就被称为后端服务（Back-end service） 。它也被称作“target service”目标服务。
[/list]
注：这里的 service 可以包含两部分：
[list]
[*]一是应用程序本身提供的 service
[*]二是应用程序本身[color=red]还可提供代理服务[/color]，使 Client 能够通过它（代理）访问目标服务。
[/list]
按照翻译，不容易理解“目标服务”，通过下面的图可以很容易看清楚它的作用。
黄色区域指 Client ；
绿色区域指 Server ；
紫色区域指 Service 和 Proxy；
蓝色区域指 目标服务。
其中 [color=red]CAS1.0 中没有目标服务这一块，也没有 Service 的 proxy ，也即不能进行代理认证[/color]。
[list]
[*]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使其拥有二级代理的权限[color=red]？？？？[/color]
[*]13， Step5-Response：返回用户的Mail信息
[/list]
[img]http://dl.iteye.com/upload/attachment/0075/4786/84ad91ca-091c-3f13-9615-8f5b7734da42.png[/img]
[b]3. CAS Entities[/b]
3.1. service ticket： ST 是一串繁杂的字符串，客户端用来作为凭证以获取访问的服务。ST 是CAS 根据客户端递交的凭证和服务标识符产生的。参见/login 第2.2 节。
3.1.1 . service ticket properties
[list]
[*]只有/login 追加了service 标识符，CAS 才会生成ST 。服务标识符应不属于ST 。
[*][color=red]ST 只能被尝试验证一次。无论验证是否成功[/color]，CAS 必须使该ST 无效，并且要使得今后拒绝再验证同一个ST 。
[*]CAS 应该能在一段合理的时间内终止一个没有验证通过的ST 。如果一个服务使用了过期的ST ，CAS 必须作出反应，返回必须是验证失败。
[*]推荐：验证的响应应该包括一个描述消息，解释为什么验证失败。
[*][color=red]推荐：其长度不能超过5 分钟[/color]。要结合本地安全和CAS 的使用情况来考虑确定验证失败的ST 的生命周期。
[*]服务车票必须包含足够的安全随机数据。
[*]服务票，首字符必须是 “ ST- ” 。
[*]必须超过32 个字符的长度。推荐：256 个字符的长度。
[/list]
3.2. proxy ticket： PT 是一串繁杂的字符串，代理服务器以PT为凭证代表客户端访问目标服务。 PT 是CAS 根据一个有效的PGT （第3.3 节），以及一个可连接的目标服务标识符产生的。
3.2.1 . proxy ticket properties
[list]
[*]只有在目标服务的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 个字符的长度。
[/list]
3.3. proxy-granting ticket: PGT 是一串繁杂的字符串，某个服务使用它获取PT ，[color=red]用PT 代表客户端去访问目标服务[/color]。PGT 的获取必须来自验证ST 或PT 通过后才行。PGT 的发放在第2.5.4 节已经详细描述过。
3.3.1 . proxy-granting ticket properties
[list]
[*][color=red]PGT 可以用来多次获取PT ，PGT 不是一次性使用的票据[/color]。
[*]被代理的认证客户端如果登出了CAS ，PGT 必须被终止。
[*]PGT 必须包含足够的安全随机数据，使它在一段合理的时间内不被外力攻击得到。
[*]PGT 首字符应该是 “ PGT- ” 。
[*]必须超过64 个字符的长度。推荐：256 个字符的长度。
[/list]
3.4. proxy-granting ticket IOU: PGTIOU 是一个繁杂的字符串，放置在/serviceValidate 和/proxyValidate 访问时的XML 回复里，[color=red]使用它可以获得同它绑定在一起的PGT， 继而得出PT 或者ST[/color] 。参阅第2.5.4 节。
3.4.1 . proxy-granting ticket IOU properties
[list]
[*]PGTIOU 中不应该包含与PGT 相关的任何痕迹，给你一个PGTIOU ，不应该在一个合理的时间段内，按照一定的算法得出与之绑定的PGT 。这是为了保证系统的安全。
[*]PGT 必须包含足够的安全随机数据，使它在一段合理的时间内不被外力攻击得到。
[*]PGTIOU 的首字符是 “ PGTIOU - ” 。
[*]服务必须能够处理最多64 个字符长度的PGTIOUs 。建议支持最多256 个字符的长度。
[/list]
3.5. login ticket: LT 是一个字符串，是由/login 作为凭证索取者提供的，并且通过作为凭证接收者的/login 做用户名/ 密码验证。其目的是为了防止因为Web 浏览器的BUG 导致用户输入的用户名、密码被重用。
3.5.1 . login ticket properties
[list]
[*]由/login 传出的LT 必须是唯一的。
[*]LT 的有效期只能在一次认证尝试期间。无论是否认证成功，CAS 必须使该LT 立即失效，并且要使得今后拒绝再验证同一个LT 。
[*]LT 首字符必须是 “ LT- ”。
[/list]
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
[list]
[*]TGC 必须在客户端浏览器的session 结束时终止。
[*]CAS 设置cookie 的路径是有局限性的。例如，如果CAS 服务器的路径设置为/cas ，则Cookie 的路径必须设置为/cas 。
[*]TGC 都必须包含足够的安全随机数据，以保证它在一个合理的时间内不被推测出来。
[*]TGC 开始字符应该是 “ TGC- ” 。
[/list]
3.7. ticket and ticket-granting cookie character set: 上面所说的CAS 的所有凭证还有TGC 都必须遵循如下的字符集。
{A-Z, a-z, 0-9, and the hyphen character ?-'}.

转自：
[url=http://www.jasig.org/cas/protocol]CAS Protocol - 官网[/url]
[url=http://wenku.baidu.com/view/f0b268d084254b35eefd34b8.html]CAS协议介绍中文版 - 百度文库[/url]
[url=http://wenku.baidu.com/view/9af2efe29b89680203d82575.html]CAS协议分析 - 百度文库[/url]
[url=http://blog.csdn.net/tienway/article/details/5464516]JASIG CAS协议介绍 （1）-CAS Entities [/url]
[url=http://blog.csdn.net/tienway/article/details/5465522]JASIG CAS协议介绍 （2）-/login和/logout [/url]
[url=http://blog.csdn.net/tienway/article/details/5465524]JASIG CAS协议介绍 （3）--/validate和/serviceValidate [/url]
[url=http://blog.csdn.net/tienway/article/details/5465525]JASIG CAS协议介绍 （4）- /proxyValidate 和 /proxy [/url]