JASIG CAS协议介绍 （2）-/login和/logout

3.           CAS URIs

CAS是一个基于HTTP的协议，这就要求其每一个组成部分可以通过特定的URIs访问到。本节将讨论每个的URIs。

3.1. /login as credential requestor

/login URI通过两种行为运转：一是作为一个凭证索取者，二是作为凭证接收者。根据它对凭证的反应来区分他是作为凭证索取者还是凭证接收者。

如果客户端已经与CAS建立了一个单点登录的session，Web浏览器给CAS一个安全的cookie，里面包含有一个以字符串形式存在的身份信息—TGT（Ticket-Granting Ticket），存储这个身份信息TGT的cookie就被称为票证授予的cookie（TGC- Ticket-Granting Cookie）。如果TGC里面有一个有效的TGT，CAS可以发出一个服务门票（Service Ticket，ST），这个ST可以在本规范内的其他任何情况下使用。本规范的要求。见第3.6节提供更多的资料，TGC。

3.1.1. parameters

下面的HTTP请求的参数可通过/login，这时它作为凭证索取者。他们都是区分大小写的，他们都必须处理/login。

·         service[可选] -客户端尝试访问的应用的标识符。在几乎所有情况下，这将是应用的URL。请注意，作为一个HTTP请求的参数，此URL的值必须是符合RFC 中URL编码的描述。（详情参见RFC 1738 [ 4 ]的第2.2节）。如果没有指定service并且单点登录session尚不存在，CAS应要求具有凭证的用户发起一个单点登录session。如果没有指定service但单点登录session已经存在，CAS应显示一条消息，通知客户，这是已经登录

·         Renew[可选] -如果此参数设置，单点登录将被绕过。在这种情况下，CAS将要求客户提交证书，不论是否存在一个CAS的单点登录session。这个参数与“gateway”参数不兼容。服务重定向到/login的URI和登录表单视图，张贴在/login的URI中的值不应同时出现在“renew”和“gateway”请求参数。两个参数都设置这种行为是未定义的。CAS推荐：在实施时，如果设置“renew”参数则忽略“gateway”参数。推荐：当设置“renew”参数时，其值应该为“true”。

注：也就是说：https://server/cas/login?service=serviceUrl&renew=true&gateway=true这种参数传递是错误的，不能同时出现两个参数。

注：CAS协议允许客户端选择是否跳出单点登录，这就是renew。它允许一个客户端通知CAS服务器总是验证一个用户，不管一个单点登录的session是否存在。这是一个非常有用的属性，当一个特定的使用CAS认证机制的服务允许访问敏感资料时，它能强迫CAS重新认证一个用户，确保登录的是一个正确的用户。这时，那个应经存在的单点登录session应该是被终止的。使用这个属性通知CAS重新验证凭证时，客户端应用应该中定向用户到以下的URL上：

https://server/cas/login?service=serviceUrl&renew=true

当请求验证这个票据时，客户端可以要求CAS确保这个票据是来自一个新的认证请求。

应用场景可参见：部署的客户端集成示例bookshop，改变该参数值，体验效果。

·         Gateway[可选] -如果这个参数设定，CAS将不会向客户端索要凭据。如果客户端有一个已存在的CAS单点登录的session，或者如果单点登录session可以通过非交互方式（i.e. trust authentication，信托认证）建立，CAS可以将客户端请求重定向到“service”参数指定的URL，而且还加上有效的服务票据（Service Ticket，ST）。 （CAS还可以插入一个通知页面，通知客户端一个CAS认证已经发生了。）

如果客户端没有CAS单点登录的session，并且也不可能通过非交互方式建立认证，CAS必须将客户端重定向到“service”参数指定的URL，并且不在URL后面附加“ticket”。如果“service”参数未指定但设置了“gateway”参数，CAS将认为这种行为未定义。在这种情况下推荐：如果两个参数都没有指定，CAS应要求凭据。同样这个参数与“renew”参数不兼容。如果要设置“gateway”参数，推荐设置为“true”。

注：

应用场景可参见：部署的客户端集成示例bookshop，改变该参数值，体验效果。

   总结：“renew”参数的作用：在存在SSO session的情况下client请求访问资源，是重新认证用户信息还是不用认证放这个请求过去。

“gateway”参数的作用：与“renew”参数相反，“gateway=true”时是指只要存在SSO session就不用重新认证了。

Renew始终要求用户进行主认证，所谓主认证就是借助于/login进行的认证操作，此时IE用户必须手工提供自身的帐号信息。基于TGC、PT的登录都不属于主认证。相比之下，gateway始终不会允许CAS服务器丢出/login登录页面给IE用户，从而不可能进行主认证。只要gateway=true则永远进不到/login登录页面，只有确认用户能从其他途径得到SSO session才可以设置true。

3.1.2. URL examples of /login

Simple login example:

https://server/cas/login?service=http%3A%2F%2Fwww.service.com

Don't prompt for username/password:

https://server/cas/login?service=http%3A%2F%2Fwww.service.com&gateway=true

Always prompt for username/password:

https://server/cas/login?service=http%3A%2F%2Fwww.service.com&renew=true

3.1.3. response for username/password authentication

当/login的行为作为凭证索取者时，根据请求的证书的类型响应会有所不同。在大多数情况下，CAS作出的回应是显示登录屏幕要求输入用户名和密码。此网页必须是包括“用户名”，“密码”参数的表单。该表单也可包括 “warn”参数 。如果“service”已被指定为从/login登录，那么“service”也成了登录表单的一个参数，包含着通过/login以后最初的地址。将在第2.2.1节对这些参数进行详细的讨论。该表单必须通过HTTP POST方法来提交到/login，然后/login就作为凭据接收人，将在第2.2节讨论。

3.1.4. response for trust authentication

信任认证作为一种基本的认证，对各种各样的请求都考虑了进去。信任认证的用户体验就是高度详尽的部署，考虑本地策略和特殊情况下认证机制的实现。

当/login行为作为信任认证的票据索取者时，其行为将取决于接收的证书的类型。如果证书是有效的，CAS会立即将用户重定向到请求的服务。另外，CAS可能会显示一个警告信息：证书是存在的，并允许客户端确认它是否想利用这些证书。推荐：CAS的实施允许部署者选择首选行为。如果证书是无效的或不存在，CAS推荐显示客户端验证失败的原因，以及可能替代目前的用户身份验证的其他方式（如用户名/密码身份验证）。

3.1.5. response for single sign-on authentication

如果客户已经建立了一个CAS的单点登录session，客户端将带着自己的HTTP会话cookie来/ Login ，并予以处理的行为将在第2.2.4节。但是，如果“renew”参数设置了，处理行为参见第2.1.3或2.1.4 。

2.2. /login as credential acceptor

当一组接收的证书通过了/login，/login将扮演凭证接收者的角色，具体行为将在本节定义。

3.2.1. parameters common to all types of authentication

当/login作为凭据接收人时，下面的HTTP请求参数可能被传递到/login。他们都是区分大小写的，它们都必须由/login控制。

 •service[可选] -客户端尝试访问的应用的URL。成功验证后CAS必须将客户端重定向到这个URL。这是详细讨论了第2.2.4节。

 •warn[可选] -如果此参数设置，单点登录将不能是透明。客户端必须被提示通过了验证正在转向请求的服务。

3.2.2. parameters for username/password authentication

除了在第2.2.1节指明的可选参数，当/login作为用户名/密码认证方式的接收人时，下列HTTP请求参数必须被传递到/login。他们都区分大小写。

 •username[需要] -正在试图登录的客户端的用户名。

•password[需要] -正在试图登录的客户端的密码。

•It[需要] -登入票证。这是的一部分在第2.1.3节的登录表单中讨论过了。登录门票将在第3.5节讨论。

3.2.3. parameters for trust authentication

There are no REQUIRED HTTP request parameters for trust authentication. Trust authentication may be based on any aspect of the HTTP request.

3.2.4. response

/login作为凭证接收者时，下列其中一个回复是它必须提供的。

 •成功登入：在不将客户端凭证传递到service的情况下，重定向客户端请求到“service”参数指定的网址。这种重定向的结果必须导致用户端向它所请求的服务发出一个GET请求。要求必须包括一个有效的服务票据（Service Ticket，ST），作为HTTP请求的参数通过，它就是“ticket” 。见附录B获取更多信息。如果“服务”未指定，CAS必须通知客户端，它已成功地开始了一个单点登录session。

 •未能登入：/login将再次作为凭证索取者返回。因此建议在这种情况下，CAS服务器向用户显示错误信息，说明为什么登入失败（例如密码错误，锁定帐户等） ，如果有必要的话，提供一个机会，让用户能够尝试再次登录。

3.3. /logout

/logout用于销毁客户端的CAS单点登录会话。TGC被摧毁（第3.6节），随后请求/login将不会取得服务门票（ST），直到用户再次交出主凭证（从而建立了一个新的单点登录session）。

3.3.1. parameters

以下HTTP请求参数为/logout指定的。这是区分大小写的，应由/logout来处理。

 •url[可选] -如果“url”是指定的，通过“url”参数指定的URL应该是登出页面并且带有描述性文字。例如， “您刚才的应用退出提供了一个链接，希望您的后续。请单击此处访问http://www.go-back.edu .”

3.3.2. response

/logout必须展示一个页面，向用户表明现在已经登出。如果“url”请求参数生效，/logout还应提供一个链接到以前登入的URL的链接 ，具体描述在第2.3.1 。