`
desert3
  • 浏览: 2139872 次
  • 性别: Icon_minigender_1
  • 来自: 合肥
社区版块
存档分类
最新评论

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 (公约和定义)
  • “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
  • 大小: 24.5 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics