JASIG CAS协议介绍 （1）-CAS Entities

1.           Introduction

以下是 CAS1.0 和 2.0 协议的官方规范。

注： CAS1.0 和 2.0 协议大体包含两个方面的内容：各种票根（ Ticket ）和暴露给 CAS 客户的 HTTP （ S ） URL 。这些 UPL （ /login 、 /logout 、 /validate 、 /serviceValidate 、 /proxy 、 /proxyValidate 等 ）围绕着这些票根（ ST 、 TGC 、 PGT 、 PT 等）进行活动。在此期间服务和终端服务之间会进行多次 HTTPS 交互。

Conventions & Definitions （公约和定义）

l  “ Client ” 指的是终端用户或者是 WEB 浏览器。

l  “ Server ”指的是统一认证服务所在的服务器。

l  “ Service ” 指的是终端用户或者 WEB 浏览器试图访问的应用 .

l  “ Back-end service ”是指一个服务试图代表一个 client 去访问一个应用，这个应用就被称为终端服务（ Back-end service ） 。它也被称作“ target service ”目标服务。

注：这里的 service 可以包含两部分，一是应用程序本身提供的 service ；二是应用程序本身还可提供代理服务，使 Client 能够通过它的代理功能访问终端服务。

按照翻译，不容易理解“终端服务”，通过下面的图可以很容易看清楚它的作用。

黄色区域指 Client ；绿色区域指 Server ；紫色区域指 Service ；蓝色区域指终端服务。其中 CAS1.0 中没有终端服务这一块，也没有 Service 的 proxy ，也即不能进行代理认证。

 

2. CAS Entities

2.1. service ticket

ST 是一串繁杂的字符串，客户端用来作为凭证以获取访问的服务。ST 是CAS 根据客户端递交的证书和服务标识符产生的。参见/login 第2.2 节。

证书+ 所要访问的service ，由CAS 生成。

2.1.1 . service ticket properties

• 只有/login 追加了service 标识符，CAS 才会生成ST 。服务标识符应不属于ST 。

  • ST 只能被尝试验证一次。无论验证是否成功，CAS 必须使该ST 无效，并且要使得今后拒绝再验证同一个ST 。

  • CAS 应该能在一段合理的时间内终止一个没有验证通过的ST 。如果一个服务使用了过期的ST ，CAS 必须作出反应，返回必须是验证失败。

推荐：验证的响应应该包括一个描述消息，解释为什么验证失败。

It is RECOMMENDED that the duration a service ticket is valid before it expires be no longer than five minutes.

推荐：其长度不能超过5 分钟。要结合本地安全和CAS 的使用情况来考虑确定验证失败的ST 的生命周期。

• 服务车票必须包含足够的安全随机数据。

  • 服务票，首字符必须是 “ ST- ” 。

  • 必须超过32 个字符的长度。推荐：256 个字符的长度。

2.2. proxy ticket

PT 是一串繁杂的字符串，代理服务代表客户端，用它来作为凭证以获取客户端要访问的终端服务。 PT 是根据CAS 提供的一个有效的PGT （第3.3 节），以及一个可连接的终端服务标识符产生的。

2.2.1 . proxy ticket properties

• 只有在终端服务的URL 传入/proxy 时，才是有效的PT 。服务标识符应不属于PT 。

      • PT 只能被尝试验证一次。无论验证是否成功，CAS 必须使该PT 无效，并且要使得今后拒绝再验证同一个PT 。

• CAS 应该能在一段合理的时间内终止一个没有验证通过的PT 。如果一个服务使用了过期的PT ，CAS 必须作出反应，返回必须是验证失败。

推荐：验证的响应应该包括一个描述消息，解释为什么验证失败。

It is RECOMMENDED that the duration a service ticket is valid before it expires be no longer than five minutes.

推荐：其长度不能超过5 分钟。要结合本地安全和CAS 的使用情况来考虑确定验证失败的ST 的生命周期。

• 服务车票必须包含足够的安全随机数据。

    • 服务票，首字符必须是“ ST- ” 。

• 必须超过32 个字符的长度。推荐：256 个字符的长度。

2.3. proxy-granting ticket

PGT 是一串繁杂的字符串，某个服务使用它获取PT ，用PT 代表客户端去访问后端服务。PGT 的获取必须来自验证ST 或PT 通过后才行。PGT 的发放在第2.5.4 节已经详细描述过。

2.3.1 . proxy-granting ticket properties

• PGT 可以用来多次获取PT ，PGT 不是一次性使用的票据。

• 被代理的认证客户端如果登出了CAS ，PGT 必须被终止。

• PGT 必须包含足够的安全随机数据，使它在一段合理的时间内不被外力攻击得到。

• PGT 首字符应该是 “ PGT- ” 。

• 必须超过64 个字符的长度。推荐：256 个字符的长度。

2.4. proxy-granting ticket IOU

PGTIOU 是一个繁杂的字符串，放置在/serviceValidate 和/proxyValidate 访问时的XML 回复里，使用它可以获得同它绑定在一起的PGT ，继而得出PT 或者ST 。参阅第2.5.4 节。

2.4.1 . proxy-granting ticket IOU properties

• PGTIOU 中不应该包含与PGT 相关的任何痕迹，给你一个PGTIOU ，不应该在一个合理的时间段内，按照一定的算法得出与之绑定的PGT 。这是为了保证系统的安全。

• PGT 必须包含足够的安全随机数据，使它在一段合理的时间内不被外力攻击得到。

  • PGTIOU 的首字符是 “ PGTIOU - ” 。

  • 服务必须能够处理最多64 个字符长度的PGTIOUs 。建议支持最多256 个字符的长度。

2.5. login ticket

LT 是一个字符串，是由/login 作为凭证索取者提供的，并且通过作为凭证接收者的/login 做用户名/ 密码验证。其目的是为了防止因为Web 浏览器的BUG 导致证书被重用。

2.5.1 . login ticket properties

• 由/login 传出的LT 必须是唯一的。

  • LT 的有效期只能在一次认证尝试期间。无论是否认证成功，CAS 必须使该LT 立即失效，并且要使得今后拒绝再验证同一个LT 。

  • LT 首字符必须是 “ LT- ”。

2.6. ticket-granting cookie

TGC 是由CAS 建立在SSO 会话上的一个HTTP 的cookie 。此Cookie 保持客户端的登录状态，当它是有效的时候，客户端可以把它提交给CAS 以代替主认证证书。通过设置“renew ”参数，服务可以选择退出SSO ，说明见2.1.1 ，2.4.1 和2.5.1 。

2.6.1 . ticket-granting cookie properties

• TGC 必须在客户端浏览器的session 结束时终止。

  • CAS 设置cookie 的路径是有局限性的。例如，如果CAS 服务器的路径设置为/cas ，则Cookie 的路径必须设置为/cas 。

  • TGC 都必须包含足够的安全随机数据，以保证它在一个合理的时间内不被推测出来。

  • TGC 开始字符应该是 “ TGC- ” 。

2.7. ticket and ticket-granting cookie character set

上面所说的CAS 的所有凭证还有TGC 都必须遵循如下的字符集。

{A-Z, a-z, 0-9, and the hyphen character ?-'}.