此文是根据cas的原始文档翻译补充

1、此文是根据cas的原始文档翻译补充。其中，“约定和定义”中的单词在译文中没有翻译，导致译文在这些地方不太通顺。请参照原文理解。原文地址如下： HYPERLINK /cas/protocol /cas/protocol 。在这篇文档后面附上英文原文，供参考。注意：不影响对协议理解的部分没有翻译。Author: HYPERLINK mailto:drew.mazurek Drew MazurekContributors: HYPERLINK mailto:susan.bramhall Susan Bramhall HYPERLINK mailto:howard.gilbert Howard Gil

2、bert HYPERLINK mailto:newman-andy Andy Newman HYPERLINK mailto:andrew.petro Andrew PetroVersion: 1.0Release Date: May 4, 2005Copyright 2005, Yale University1. 简介This is the official specification of the CAS 1.0 and 2.0 protocols. It is subject to change.1.1. 约定和定义这篇文档中的关键字 MUST, MUST NOT, REQUIRED,

3、SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, 和 OPTIONAL参照 RFC 2119 HYPERLINK /products/cas/protocol.html l 1 1的解释.Client 指终端用户，或者浏览器.Server 指 Central Authentication Service 的服务器.Service 指“client”尝试访问的应用程序.Back-end service指“service”以”client”身份访问的应用程序. 或者称之为target service. 指换行符(ASCII 码为 0 x

4、0a).2. CAS URIsCAS 是基于 HTTP HYPERLINK /products/cas/protocol.html l 2 2, HYPERLINK /products/cas/protocol.html l 3 3协议的，要求每个组件都能够通过特定的URI访问。这一节将讨论每一个URI。2.1. /login 作为凭证请求者时/login URI 扮演两个角色：凭证请求者以及凭证接收者。如果Client已经与CAS建立了一个单点登录的session，浏览器将向CAS服务器提供一个安全cookie，包含确定ticket-granting ticket(TGT)的字符串。这个co

5、okie被称为ticket-granting cookie(TGC)。如果ticket-granting cookie对应一个合法的ticket-granting ticket，CAS会给出一个service ticket(ST)，当其他条件都满足的时候。关于service-granting cookies的更多信息，参见Section 3.6。2.1.1. 参数当作为凭证请求者时，下面这些参数可以传递给/login URI，而且他们”MUST”被/login处理。service Optional client正在访问的应用的标识。几乎所有情况下，这会是应用的URL.请注意，当作为HTTP的请

6、求参数时，这个URL” MUST”被 URL-encoded，按照 Section 2.2 中提到的RFC 1738 HYPERLINK /products/cas/protocol.html l 4 4的规则. 如果没有指定service，并且单点登录的session不存在， CAS “SHOULD”要求用户提供凭证上，建立单点登录session. 如果没有指定service并且单点登录service已经存在，CAS “SHOULD”显示一个信息，提醒用户已经登录了。renew Optional 如果指定了这个参数，单点登录会被忽略。这种情况下，不论是否已经存在单点登录session，CAS

7、 都会要求client提供凭证。这个参数与gateway参数不兼容。访问/login URI时，“SHOULD NOT”同时设置renew和gateway参数。同时设置这两个参数时的行为没有定义。“RECOMMENDED” 当指定了renew参数时，CAS 在执行时忽略gateway参数。“RECOMMENDED”当指定renew参数时，指定其值为“true”.gateway Optional 如果指定了这个参数, CAS不会要求client提供凭证.如果 client 已经建立了单点登录session, 或者如果单点登录session可以通过非互动的方式建立(比如trust authenti

8、cation), CAS “MAY”重定向client到service参数指定的URL，并附带上合法的service ticket。(CAS 同时“MAY”给client提供一个建议页面，通知client CAS认证已经完成.) 如果client没有建立单点登录session，同时非互动认证不能建立, CAS “MUST”重定向client到service参数指定的URL，但不会附带ticket参数. 如果没有指定“service”参数，但是指定了gateway参数，CAS的动作未定义“RECOMMENDED” 这种情况下， 如果没有指定其他参数，CAS要求credentials.这个参数和r

9、enew参数不兼容，两者都指定时的动作未定义。“RECOMMENDED”当指定gateway参数时，设置其值为“true”.2.1.2. 调用 /login 的URL实例简单的登录URL: HYPERLINK /cas/login?service=http%3A%2F%2F o /cas/login?service=http%3A%2F%2F https:/server/cas/login?service=http%3A%2F%2F不向用户要求用户名和密码： HYPERLINK /cas/login?service=http%3A%2F%2F&gateway=true o /cas/login

10、?service=http%3A%2F%2F&gateway=true https:/server/cas/login?service=http%3A%2F%2F&gateway=true总是要求用户提供用户名和密码： HYPERLINK /cas/login?service=http%3A%2F%2F&renew=true o /cas/login?service=http%3A%2F%2F&renew=true https:/server/cas/login?service=http%3A%2F%2F&renew=true2.1.3. 用户名/密码方式认证时的服务器回应当 /login 作

11、为凭证请求者时，服务器回应根据请求的凭证类型的不同，差别比较大。多数情况下，CAS 会显示出一个登录界面，要求输入用户名和密码。这个页面“MUST”包含一个表单，单单中有参数： username, password, 和 lt。这个表单“MAY”包含warn参数. 如果指定了service参数，则service MUST出现在表单中，其值应该是最初传递给/login的值。 这些参数会在Section 2.2.1中详细说明. 表单MUST通过HTTP POST的方式提交到/login，此时/login作为凭证接收者，将在Section 2.2中详细讨论。2.1.4. “trust”认证时的服务器

12、回应“Trust”认证采用客户端浏览器的request作为认证的基础。考虑到本地策略以及执行的特定认证机制的逻辑，“Trust”认证的用户体验与特定的部署高度相关，当 /login 作为凭证请求者时，它的行为取决于它收到的凭证类型。如果凭证是合法的， CAS MAY 直接重定向用户到应用。或者CAS MAY显示一条信息，说明凭证已提供，并让client确认它愿意使用这些凭证。RECOMMENDED CAS 执行时允许部署者选择最佳的行为。如果凭证不合法或不存在，“RECOMMENDED” CAS显示给client认证失败的原因，或者让用户选择另一种认证方式(例如用户名/密码认证).2.1.5.

13、 单点登录认证时的回应如果client已经建立单点登录session，client会向 /login提供 TGC，服务器的行为如Section 2.2.4所述。可是如果设置了renew参数，服务器的行为将如Section 2.1.3或2.1.4所述。2.2. /login作为凭证接收者当可接受的凭证提供给/login，/login将作为凭证接收者，它的行为将在下面讨论。2.2.1. 所有类型的认证都适用的参数下列HTTP请求参数“MAY”传递给 /login，当它作为凭证接收者时。 他们都是大小写敏感的，而且“MUST”被/login处理。service Optional client的URL

14、。认证成功后，CAS MUST 重定向client到这个URL。在Section 2.2.4中将详细讨论。warn Optional 如果设置了这个参数，单点MUST NOT是透明的。当认证到另一个服务的时候，client MUST被显式提示，。2.2.2. 用户名/密码认证时的参数除了Section 2.2.1中介绍的Optional参数,当作为用户名/密码方式认证的凭证接收者时，下面的这些HTTP请求参数MUST传递给/login。都是大小写敏感的。username REQUIRED 用户名password REQUIRED 密码lt REQUIRED a login ticket. 这要

15、作为login表单的一部分，在Section 2.1.3中讨论过。关于login ticket，将在Section 3.5中讨论。2.2.3. trust方式认证的参数Trust认证方式下，没有REQUIRED HTTP 请求参数. Trust 认证可以基于HTTP请求的任何方面。2.2.4. 回应当作为凭证接收者时，/login提供的回应必须是下列之一：.成功登录: 重定向client到service参数指定的 URL但是client的凭证不能转发给service。重定向 MUST让client执行一个GET请求到service,这个请求MUST包含一个合法的service ticket,作

16、为HTTP请求参数ticket传递过去. 更多信息参阅 Appendix B。如果service参数没有指定, CAS MUST显示一条信息，提醒client已经建立了单点登录session。登录失败:返回 /login，这里/login成为凭证请求者。RECOMMENDED 这种情况下，CAS显示一条错误信息，告诉用户失败的原因(比如：错误的密码，账号被锁定等)，如果允许，同时提给用户再次尝试登录的机会。2.3. /logout/logout 销毁client的单点登录session. ticket-granting cookie (Section 3.6)被销毁,后续的对/login的请求

17、不再获得service ticket，除非用户重新登录成功并建立了新的单点登录session。2.3.1. 参数下面的HTTP请求参数MAY传递给/logout，他们是大小写敏感的，SHOULD 被/logout处理。url OPTIONAL 如果指定了url, url 指定的URL SHOULD显示在logout页面上，并且要有文字说明。例如：The application you just logged out of has provided a link it would like you to follow. Please click here to access HYPERLINK

18、o 2.3.2. 回应/logout MUST 显示一个页面，告诉用户已经登出了。如果指定了请求参数url。 /logout SHOULD 提供一个链接，指向Section 2.3.1中提到的URL.2.4. /validate CAS 1.0/validate 检查service ticket的合法性。/validate是 CAS 1.0协议的一部分，因此不会处理代理认证。 当proxy ticket传递给/validate时，CAS MUST 给出验证失败的回应。2.4.1. 参数下面这些HTTP请求参数MAY指定给/validate. 他们是大小写敏感的，而且MUST被/validate

19、处理。service REQUIRED 应用服务的标识，在Section 2.2.1中讨论过.ticket REQUIRED - /login提供的service ticket.在Section 3.1中详细讨论.renew OPTIONAL 如果指定这个参数，只有在提供用户主凭证的情况下，ticket验证才会成功。如果ticket是从一个单点登录session提供的，验证会失败。(注：也就是说这次验证的service ticket是用户提供凭证产生的，例如输入了用户名和密码。如果用户以前已经单点登录，这样产生的service ticket无效)2.4.2. 回应/validate 将返回下列

20、两个回应之一：Ticket验证成功时:yesusername验证失败时:no2.4.3. /validate的例子简单验证尝试: HYPERLINK /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 o /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 https:/server/cas/validate?service=http%3A%2F%2F&ticket=.确保ticket是用户提供主凭证

21、产生的: HYPERLINK /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true o /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true https:/server/cas/validate?service=http%3A%2F%2F&ticket=.2.5. /serviceValidate CAS 2.0/serviceValidate 检查servic

22、e ticket的合法性，返回XML格式的回应。在必要的情况下，/serviceValidate MUST 产生和执行proxy-granting tickets. 当收到proxy ticket时，/serviceValidate MUST NOT 返回成功验证。 RECOMMENDED 当/serviceValidate收到proxy ticket时, XML回应里的错误信息SHOULD 说明验证失败是因为提供了一个proxy ticket到/serviceValidate.2.5.1. 参数下面这些HTTP请求参数MAY指定给/serviceValidate. 他们都是大小写敏感的而且

23、MUST被/serviceValidate处理。service REQUIRED 提供ticket的service的标识，在Section 2.2.1中讨论过.ticket REQUIRED - /login提供的service ticket. Service tickets在Section 3.1中详细讨论.pgtUrl OPTIONAL 代理的callback(回调)的URL. 在Section 2.5.4中讨论.renew OPTIONAL -如果指定这个参数，只有在提供用户主凭证的情况下，ticket验证才会成功。如果ticket是从一个单点登录session提供的，验证会失败。(注：

24、也就是说这次验证的service ticket是用户提供凭证产生的，例如输入了用户名和密码。如果用户以前已经单点登录，这样产生的service ticket无效)。2.5.2. 回应/serviceValidate 将返回 XML格式的CAS serviceResponse，在附录A的XML schema中详细说明.下面是一些例子:Ticket验证成功时: username PGTIOU-84678-8a9d. Ticket验证失败时: Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized 2.5.3. 错误代码认证失败的回应中MAY包括下

25、面这些代码。下面是所有CAS服务器MUST实现的最小错误代码集合，实际实现中MAY包括更多其他代码。INVALID_REQUEST 没有提供所有必须参数INVALID_TICKET ticket不合法，或者当验证时指定了”renew”时，ticket不是由用户提供登录凭证生成(比如来自于已有的session)。回应的XML 消息的部分SHOULD说明细节。INVALID_SERVICE 提供的ticket是正确的，但是指定的service与ticket关系的service不一致。CAS MUST 判断ticket不合法，并且不允许进一步的验证这个ticket。INTERNAL_ERROR 在验

26、证ticket时发生内部错误。所有错误代码， it is RECOMMENDED that CAS 在XML回应消息的部分提供详细信息。2.5.4. proxy callback如果一个service希望代理客户端认证到另一个后端service，它必须获取一个proxy-granting ticket。这个ticket的获取是通知一个proxy callback URL实现的。这个URL唯一并安全地标识正在代理登录的后端service.后端service 必须通过后端服务识别callback URL决定是否接受凭证。 proxy callback 机制工作原理如下：申请proxy-granti

27、ng ticket的service，在验证service ticket或proxy ticket时，传递给/serviceValidate或/proxyValidate的HTTP请求是加上参数”pgtUrl”。这是一个callback URL，CAS将连接这个URL确认service的身份。这个URL MUST be HTTPS, CAS MUST验证SSL证书的合法性，并且证书的名称与service匹配。 如果证书验证失败，就不会有proxy-granting ticket 生成，并且 CAS service 回应Section 2.5.2中描述的消息，MUST NOT包含节.这时， pro

28、xy-granting ticket 被中止， service ticket 验证会继续,返回成功或失败。如果证书验证成功，确保如如第2步中那样处理proxy-granting ticket。CAS使用HTTP GET 请求，传递 HTTP请求参数pgtId和pgtIou到pgtUrl.它们在Sections 3.3 and 3.4中讨论过.如果HTTP GET 返回HTTP 状态代码200(OK), CAS MUST对/serviceValidate (or /proxyValidate)的请求作出回应 (Section 2.5.2) ，在节中包含proxy-granting ticket

29、IOU (Section 3.4). 如果HTTP GET 返回其他状态代码，除了HTTP 3xx重客向，CAS MUST对/serviceValidate (or /proxyValidate) 的请求作出回应， MUST NOT包含 节. CAS MAY 跟踪任何pgtUrl给出的HTTP 重定向. 可是,在验证时节中的标识callback URL MUST和最初作为”pgtUrl提供给/serviceValidate (or /proxyValidate)相同.申请proxy-granting ticket的service，在CAS的回应中收到proxy-granting ticket

30、IOU，在proxy callback的URL中接收到proxy-granting ticket和a proxy-granting ticket IOU，然后用proxy-granting ticket IOU关联proxy-granting ticket。接下来service 使用proxy-granting ticket 获取proxy ticket，在Section 2.7中有详细讨论.2.5.5. /serviceValidate 的例子简单认证尝试: HYPERLINK /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856

31、339-aA5Yuvrxzpv8Tau1cYQ7 o /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 https:/server/cas/serviceValidate?service=http%3A%2F%2F&.确保service ticket是用户提供主凭证获取(如通过输入用户名和密码，而非通过ticket granting cookie)的: HYPERLINK /cas/serviceValidate?service=http%3A%2F%2F&ticket= o /c

32、as/serviceValidate?service=http%3A%2F%2F&ticket= https:/server/cas/serviceValidate?service=http%3A%2F%2F&. ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true传入callback URL，获取proxy-granting ticket: HYPERLINK /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https:/my-se

33、rver/myProxyCallback o /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https:/my-server/myProxyCallback https:/server/cas/serviceValidate?service=http%3A%2F%2F&.2.6. /proxyValidate CAS 2.0/proxyValidate MUST 执行与/serviceValidate相同的验证任务，并且要增加对proxy tickets的验证。/

34、proxyValidate MUST 有能力处理service ticket和proxy ticket。2.6.1. 参数/proxyValidate 与/serviceValidate对参数的要求相同. 见Section .6.2. 回应/proxyValidate会返回一个XML格式的CAS serviceResponse，在附录A的 XML schema 中有详细说明.下面是一些例子:Ticket验证成功时: username PGTIOU-84678-8a9d. https:/proxy2/pgtUrl https:/proxy1/pgtUrl 注意，当认证是通过多个代理

35、完成的，这些代理的顺序MUST在 节中反映.最近的代理MUST是列表中的第一条,所有其他代理MUST按顺序列出。在上面的例子中， HYPERLINK /pgtUrl o /pgtUrl https:/proxy1/pgtUrl 是最早的代理，它代理了 HYPERLINK /pgtUrl o /pgtUrl https:/proxy2/pgtUrl.Ticket验证失败时： ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not recognized 2.6.3 /proxyValidate的例子/proxyValidate 接收与 /serviceValidate

36、相同的参数. 见 Section 2.5.5 中的例子，用 proxyValidate 代替 serviceValidate。2.7. /proxy CAS 2.0已经获取proxy-granting ticket的service在代理后端service登录时，/proxy为它提供proxy ticket。2.7.1. 参数下面这里HTTP请求参数MUST指定给/proxy，他们都是大小写敏感的。pgt REQUIRED service 在service ticket或proxy ticket验证期间获取的proxy-granting ticket.targetService REQUIRED

37、 后端服务的标识。注意，并非所有后端服务都是基于web的，所以这里的服务标识并非都是URL。可是，这里的服务标识MUST与后面进行proxy ticket的验证时传递给/proxyValidate的service参数一致。2.7.2. 回应/proxy会返回一个XML格式的CAS serviceResponse，在附录A的 XML schema 中有详细说明.下面是一些例子:请求成功: PT-1856392-b98xZrQN4p90ASrw96c8 请求失败: pgt and targetService parameters are both required 2.7.3. 错误代码认证失败的

38、回应消息中，下面这些值MAY出现在code属性里。下面是所有CAS服务器MUST实现的最小代码集合。实际实现中MAY包含其他代码。INVALID_REQUEST - 没有提供所有必须的请求参数BAD_PGT 提供的pgt不合法INTERNAL_ERROR ticket验证过程中出现内部错误对所有错误代码, it is RECOMMENDED that CAS在XML回应消息的节中提供更加详细的说明。2.7.4. /proxy的例子简单的proxy请求: HYPERLINK /cas/proxy?targetService=http%3A%2F%2F&pgt=PGT-490649-W81Y9Sa

39、2vTM7hda7xNTkezTbVge4CUsybAr o /cas/proxy?targetService=http%3A%2F%2F&pgt=PGT-490649-W81Y9Sa2vTM7hda7xNTkezTbVge4CUsybAr https:/server/cas/proxy?targetService=http%3A%2F%2F&pgt=.3. CAS 对象3.1. service ticketService ticket是一个字符串，client使用这个字符串作为访问service的凭证。Service ticket，是client通过提供身份凭证和服务标识到CAS的/logi

40、n(Section 2.2中有说明)，从CAS获取的。3.1.1. service ticket的特性Service tickets仅对生成它时在/login中指定的service标识有效。Service标识SHOULD NOT是service ticket的一部分。Service ticketss MUST仅对一次验证尝试有效，不论验证成功与否。CAS MUST注销ticket，让所有后续对同一个ticket的尝试失效。CAS SHOULD 在生成service ticket，经过一段合适的时间过后，让service ticket过期。如果service申请验证过期的service tick

41、et， CAS MUST给出验证失败的回应。It is RECOMMENDED that 验证回应消息包含为什么验证失败的说明信息。It is RECOMMENDED that service ticket过期之前的有效时间不超过5分钟。本地安全策略和CAS应用的综合考虑MAY决定未验证的service ticket的最优生命周期。Service tickets MUST 包含充足的安全的随机数据，以使它不能被猜出。Service tickets MUST 以字符串 ST-开始.Services MUST 接受多至32个字符的service ticket. It is RECOMMENDED

42、that services支持多至256个字符长度的service tickets.3.2. proxy ticketProxy ticket是一个字符串，services用它作为访问后端service的凭证。Service向CAS提供合法的proxy-granting ticket(Section 3.3)和它希望连接的后端服务的服务标识，从CAS获取proxy tickets。3.2.1. proxy ticket 特性Proxy tickets 仅对生成它时在/proxy中指定的service标识有效。Service标识SHOULD NOT是proxy ticket的一部分。Proxy

43、tickets MUST 仅对一次验证尝试有效，不论验证是否成功。然后，CAS MUST注销这个ticket，使后来对同一个ticket的验证尝试失效。CAS SHOULD 在生成proxy tickets，经过一段合适的时间以后，让proxy tockets过期。如果service提供了过期的proxy ticket，CAS MUST给出验证失败的回应消息。It is RECOMMENDED that 验证回应消息中包含验证失败的说明。It is RECOMMENDED that proxy ticket过期之前的有效时间不超过5分钟。本地安全策略和CAS使用的综合考虑， MAY 决定未验证

44、的proxy tickets最优的生命周期。Proxy tickets MUST 包含足够安全的随机数据，以使它不能被猜出。Proxy tickets SHOULD 以字符串PT-开头. Proxy tickets MUST 以字符串ST-或PT-开头。后端services MUST能够接受多至32个字符长度的proxy tickets。 It is RECOMMENDED that 后端services支持多至256个字符长度的proxy tickets。3.3. proxy-granting ticketproxy-granting ticket是一个字符串，service用它获取prox

45、y tickets，然后用proxy tickets访问后端服务。Proxy-granting tickets 从CAS获取，获取时需通过service ticket或proxy ticket的验证。Proxy-granting ticket 在Section 2.5.4中充分说明.3.3.1. proxy-granting ticket 特性Proxy-granting tickets MAY 被services用于获取多个proxy tickets。Proxy-granting tickets不是一次性的tickets.Proxy-granting tickets MUST 失效，在被代理

46、的client登出CAS时。Proxy-granting tickets MUST 包含足够安全的随机数据，使ticket在遭遇暴力破解时，在合理的一段时间内不被猜出。Proxy-granting tickets SHOULD 以字符串PGT-开头.Services MUST有能力接受多至64个字符长度的proxy-granting tickets。It is RECOMMENDED that services 支持多至256个字符长度的proxy-granting tickets。3.4. proxy-granting ticket IOUA proxy-granting ticket IO

47、U 是一个字符串，出现在/serviceValidate和/proxyValidate的回应消息里，通过它把service ticket或proxy ticket的验证与某个特定的proxy-granting ticket关联起来。这个过程的详细说明见 Section .1. proxy-granting ticket IOU特性Proxy-granting ticket IOUs SHOULD NOT 包含与他们关联的proxy-granting ticket相关的任何内容。给出一个PGTIOU, 通过一定算法在一段合适的时间内，it MUST NOT 可能计算出它相关的PG

48、T，Proxy-granting ticket IOUs MUST 包含足够安全的随机数据，使ticket在合适的时间段内通过暴力破解的方法不能猜出。Proxy-granting ticket IOUs SHOULD以字符串PGTIOU-开头.Services MUST 有能力处理多至64个字符长度的PGTIOUs。It is RECOMMENDED that services 支持多至256个字符长度的PGTIOUs.3.5. login ticketlogin ticket是一个字符串，在用户名/密码形式的认证中，由/login作为凭证请求者时提供，传递给作为凭证接收者的/login. 它

49、的目的是保护因为浏览器的BUG引起的重复提交。3.5.1. login ticket 特性Login tickets 由/login生成， MUST在概率上是唯一的。Login tickets MUST 仅对一次认证尝试有效，不论认证是否成功，然后CAS MUST 使login ticket失效，让后来的使用这个login ticket的认证尝试失败。Login tickets SHOULD 以字符串 LT-开头.3.6. ticket-granting cookieticket-granting cookie 是一个HTTP cookie HYPERLINK /products/cas/pr

50、otocol.html l 5 5 ，由CAS在建立起单点登录session时设置。在它生效期间，这个cookie为client维持登录状态, client可以把它提供给CAS 代替主凭证。Services退出单点登录，通过设置”renew”参数(在 Sections 2.1.1, 2.4.1,和 2.5.1中有说明)。3.6.1. ticket-granting cookie 特性Ticket-granting cookies MUST 在client的浏览器session结束时失效。CAS MUST尽可能严格地设置cookie的路径。例如：如果CAS server设置在/cas路径, co

51、okie的路径 MUST设置为/cas.ticket-granting cookies的值 MUST包含足够安全的随机数据，使ticket-granting cookie在一段合理的时间内不被猜出。ticket-granting cookies SHOULD以字符串TGC-开头.3.7. ticket and ticket-granting cookie 字符集除上面的要求以外，所有CAS tickets以及ticket-granting cookie 的值MUST仅包含这些字符：A-Z, a-z, 0-9, and the hyphen character ?-.Appendix A: CA

52、S response XML schema Appendix B: Safe redirectionAfter a successful login, safely redirecting the client from CAS to its final destination must be handled with care. In most cases, the client has sent credentials to the CAS server over a POST request. By this specification, the CAS server must then

53、 forward the user to the application with a GET request.The HTTP/1.1 RFC HYPERLINK /products/cas/protocol.html l 3 3 provides a response code of 303: See Other, which provides for the desired behavior: a script that receives data through a POST request can, through a 303 redirection, forward the bro

54、wser to another URL through a GET request. However, not all browsers have implemented this behavior correctly.The recommended method of redirection is thus JavaScript. A page containing a window.location.href in the following manner performs adequately: Yale Central Authentication Service window.loc

55、ation.href=/Login?ticket=ST-. mce_href=/Login?ticket=ST-.; CAS login successful. Click here to access the service you requested. Additionally, CAS should disable browser caching by setting all of the various cache-related headers:Pragma: no-cacheCache-Control: no-storeExpires: RFC 1123 HYPERLINK /pr

56、oducts/cas/protocol.html l 6 6 date equal to or before nowThe introduction of the login ticket removed the possibility of CAS accepting credentials that were cached and replayed by a browser. However, early versions of Apples Safari browser contained a bug where through usage of the Back button, Saf

57、ari could be coerced into presenting the clients credentials to the service it is trying to access. CAS can prevent this behavior by not automatically redirecting if it detects that the remote browser is one of these early versions of Safari. Instead, CAS should display a page that states login was

58、successful, and provide a link to the requested service. The client must then manually click to proceed.Appendix C: References1 Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, Harvard University, March 1997.2 Berners-Lee, T., Fielding, R., Frystyk, H., Hypertext Tran

59、sfer Protocol - HTTP/1.0, RFC 1945, MIT/LCS, UC Irvine, MIT/LCS, May 1996.3 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Hypertext Transfer Protocol - HTTP/1.1, RFC 2068, UC Irvine, Compaq/W3C, Compaq, W3C/MIT, Xerox, Microsoft, W3C/MIT, June 1999.4 Ber

60、ners-Lee, T., Masinter, L., and MaCahill, M., Uniform Resource Locators (URL), RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994.5 Kristol, D., Montulli, L., HTTP State Management Mechanism, RFC 2965, Bell Laboratories/Lucent Technologies, E, Inc., October 2000.6 Braden, R.,