CAS协议 - CAS URIs

2.CAS URIs:
CAS是一个 基于HTTP的协议，这就要求其每一个组成部分可以通过特定的URIs访问到。所有相关的URIs如下：

• 2.1. /login as credential requestor
• 2.2. /login as credential acceptor
• 2.3. /logout
• 2.4. /validate [CAS 1.0]
• 2.5. /serviceValidate [CAS 2.0]
• 2.6. /proxyValidate [CAS 2.0]
• 2.7. /proxy [CAS 2.0]

2.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。

2.1.1. parameters
当/login作为凭证索取者时，包含下面的HTTP请求参数。它们都是 区分大小写的，他们都必须能被/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 （get方式访问/login）和提交到/login URI的登录表单视图 （post方式访问/login）中不应同时出现“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确保这个票据是来自一个新的认证请求。

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”。
• 总结：“renew”参数的作用：在存在SSO session的情况下，当client请求访问资源，renew参数控制CAS认证服务器重新认证用户信息、还是不用认证放这个请求过去。
• 总结：“gateway”参数的作用：与“renew”参数相反，“gateway=true”时是指只要存在SSO session就不用重新认证了。
• 总结：Renew始终要求用户进行主认证，所谓主认证就是借助于/login进行的认证操作，此时IE用户必须手工提供自身的帐号信息。基于TGC、PT的登录都不属于主认证。
• 相比之下，gateway始终不会允许CAS服务器丢出/login登录页面给IE用户，从而不可能进行主认证。只要gateway=true则永远进不到/login登录页面，只有确认用户能从其他途径得到SSO session才可以设置true。

2.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

2.1.3. response for username/password authentication
当/login的行为作为凭证索取者时，根据请求的证书的类型响应会有所不同。

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

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

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

2.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将扮演凭证接收者的角色，具体行为将在本节定义。

2.2.1. parameters common to all types of authentication
当/login作为凭据接收人时，下面的HTTP请求参数可能被传递到/login。他们都是区分大小写的，它们都必须能被/login处理。
service[可选] -客户端尝试访问的应用的URL。成功验证后CAS必须将客户端重定向到这个URL。这是详细讨论了第2.2.4节。
warn[可选] -如果此参数设置 ，单点登录将不能是透明。客户端必须被提示通过了验证正在转向请求的服务。

2.2.2. parameters for username/password authentication
除了在第2.2.1节指明的可选参数，当/login作为用户名/密码认证方式的接收人时，下列HTTP请求参数必须被传递到/login。他们都区分大小写。
username[需要] -正在试图登录的客户端的用户名。
password[需要] -正在试图登录的客户端的用户密码。
lt[需要] - a login ticket登入票证。为什么需要Login ticket参考： CAS - FAQ(Login ticket 、pgtIou)。登录门票将在第3.5节讨论。

2.2.3. parameters for trust authentication
Trust authentication没有其他额外的HTTP参数。它可能基于HTTP请求的任何方面。

2.2.4. response
/login作为凭证接收者时，必须返回下面其中一个响应。
成功登入：在不将客户端凭证传递给service的情况下，重定向客户端请求到“service”参数指定的网址。这种重定向的结果必须导致客户端向它所请求的服务发出一个GET请求。要求 必须包括一个有效的服务票据（Service Ticket，ST），作为HTTP请求的参数通过，它就是“ticket” 。见附录B获取更多信息。如果“服务”未指定，CAS必须通知客户端，它已成功地开始了一个单点登录session。
登入失败：以凭证索取者的身份重新迁移到/login。因此建议在这种情况下，CAS服务器向用户显示错误信息，说明为什么登入失败（例如密码错误，锁定帐户等） ，如果有必要的话，提供一个机会，让用户能够尝试再次登录。

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

2.3.1. parameters
以下是/logout的HTTP请求参数。这是区分大小写的，应由/logout来处理。
url[可选] -如果“url”被指定的，那么在登出页面上需要有一个link到url并带有描述性文字的链接。例如，登出页面上：“您刚登出的财务系统提供了一个链接，如果你想访问，请单击此处（ 此处代表一个link到http://www.go-back.edu的超级链接）.”

2.3.2. response
/logout 必须展示一个页面，向用户表明现在已经登出。如果“url”请求参数被指定，登出页面还应提供一个链接到url的链接，具体描述在第2.3.1 。

2.4. /validate [CAS 1.0]
/validate检查ST的有效性，/validate是CAS1.0协议的一部分，因此它不能处理代理认证。当一个代理凭证被传递给/validate时，CAS必须发出一个服务凭证验证失败的响应。

2.4.1. parameters
下面的HTTP请求参数可以被传递给/validate。它们是区分大小写的，必须全部能被/validate处理。
service[需要] –服务的标识符，是需要带着ticket访问的服务。
ticket[需要] -/login发出的服务凭证（ST）。服务凭证的描述见3.1节。
renew[可选] -如果这个参数设定，凭证验证将只在ST是来自用户的主证书时才会通过验证，如果ticket是来自SSO session，则验证失败。即，只有通过主登录页面过来的附带着ST的请求，才能被验证。

2.4.2. response
/validate 将返回下面的2个响应之一。
ticket验证成功：

yes<LF>
username<LF>

ticket验证失败：

no<LF>
<LF>

2.4.3. URL examples of /validate

• Simple validation attempt: https://server/cas/validate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7
• Ensure service ticket was issued by presentation of primary credentials: https://server/cas/validate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true

2.5. /serviceValidate [CAS 2.0]
/serviceValidate检查ST的有效性，并且返回一个XML片段。 当被请求时，/serviceValidate还必须创造和传出 PGT（proxy-granting ticket，代理准许凭证）。如果/serviceValidate收到一个PT（proxy ticket，代理凭证），它不能返回一个成功的验证响应。CAS推荐：如果/serviceValidate收到PT，应该在返回的XML响应的错误信息里说明失败的原因，原因是由于PT传递到了/serviceValidate。也即： /serviceValidate不能用来验证PT。

2.5.1. parameters
下面的HTTP请求参数可以被传递给/serviceValidate。它们是区分大小写的，必须全部能被/serviceValidate处理。
service[需要] -服务的标识符，是需要带着ticket访问的服务。第2.2.1节。
ticket[需要] - /login发出的服务凭证（ST）。ST将在3.1节详解。
pgtUrl [可选] - 代理回调的URL，CAS通过该回调接口给申请作为代理的服务传递pgt和pgtIou。将在2.5.4节讨论。
renew[可选] -如果这个参数设定，凭证验证将只有在ST是来自用户的主认证时才会通过验证，如果ticket是来自SSO session，则验证失败。

2.5.2. response
/serviceValidate将返回一个格式化的CASserviceResponse XML，详细描述参加附录A。
凭证验证成功：

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:user>username</cas:user>
            <cas:proxyGrantingTicket>PGTIOU-84678-8a9d...
        </cas:proxyGrantingTicket>
    </cas:authenticationSuccess>
</cas:serviceResponse>

凭证验证失败：

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationFailure code="INVALID_TICKET">
        Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized
    </cas:authenticationFailure>
</cas:serviceResponse>

2.5.3. error codes
下面的值可能被用来作为验证失败时“code”属性的值。以下是最低限度的错误代码，所有CAS服务器都必须实现的，当然还可以包括一些其他实现。
INVALID_REQUEST -请求参数不全。上面讲到至少必须有“service”和“ticket”两个参数。
INVALID_TICKET -提供的ticket无效，或者你的“renew”属性设置为true，而不是从主认证（/login）过来的。返回的XML中的消息体中的<cas:authenticationFailure>块应说明具体细节。
INVALID_SERVICE -提供ticket是有效的，但是和ticket关联的service并不匹配。此时：CAS必须使这张ticket失效，并禁止今后再验证该ticket。
INTERNAL_ERROR –在ticket验证时发生内部错误。
对于所有的错误代码，CAS推荐在<cas:authenticationFailure>的内容区域提供更详细的错误原因描述。

2.5.4. proxy callback
如果一个服务想代理一个客户端到终端服务（Back-end service）的认证，他必须获得一个PGT（proxy-granting ticket，代理授予凭证）。通过传递参数pgtUrl（代理回调URL）来控制CAS在验证时是否同时返回PGT。 这个URL将唯一的和安全的识别终端服务，并且代理客户端的认证请求。终端服务然后基于自身的识别回调URL来决定是否接受这个证书。

代理回调机制的工作流程如下：

• 1.当ST或者PT通过/serviceValidate（或/ proxyValidate）进行验证时，如果设置了参数“pgturl”，service才会向CAS认证服务器请求产生PGT(proxy-granting ticket)。pgturl是一个服务的回调URL，CAS服务器将用pgturl来验证服务的身份信息。这个URL必须是HTTPS的，并且CAS必须确认SSL证书是有效的，并且它的名字与它请求的服务相匹配。如果证书验证失败，将不发放PGT，并且就像第2.5.2节中描述的，必须使CAS服务返回的XML中不包含<proxyGrantingTicket>这个xml块。此时，将停止发布PGT，但ST验证仍将继续，还要根据具体情况返回成功或失败状态。如果证书验证成功，发行PGT的过程见如下第2步。
• 2.CAS将使用HTTPS GET方式传递参数“pgt”和“pgtIou”给pgtUrl。这些实体将在第3.3和3.4中讨论。即通过访问代理服务器上的https回调接口，传递pgt和pgtIou给代理服务器
• 3.如果HTTP GET返回的HTTP状态码是200 （正常），CAS必须在/serviceValidate （或/proxyValidate ）的请求（第2.5.2节）响应结果中包含有PGTIOU（Proxy-granting ticket IOU）（第3.4节）的<cas:proxyGrantingTicket>节点。
• 如果HTTP GET返回的是其他状态码（除了HTTP 3xx重定向外），CAS必须在/serviceValidate （或/proxyValidate ）的请求（第2.5.2节）响应结果中不包含PGTIOU（Proxy-granting ticket IOU）和<cas:proxyGrantingTicket>节点。CAS可跟踪pgturl发出的任何HTTP重定向连接。但不管怎样，在<proxy>节点中提供验证的回调URL，必须与最初通过/serviceValidate （或/proxyValidate ）的“pgturl”参数相同。
• 4.service会从CAS响应中收到一个PGTIOU，同时会从proxy callback中收到一个PTG和PGTIOU。然后service会使用PGTIOU与PGT进行匹配（CAS响应的PGTIOU和回调url返回的PGTIOU一致的话，回调接口返回的pgt才正式生效）。这样就能找到需要的PGT，利用这个PGT就可以得到PT（proxy-ticket）。参见第2.7节。

2.5.5. URL examples of /serviceValidate
Simple validation attempt: https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7
Ensure service ticket was issued by presentation of primary credentials: https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true
Pass in a callback URL for proxying: https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https://my-server/myProxyCallback

2.6. /proxyValidate [CAS 2.0]
/proxyValidate必须执行与/serviceValidate相同的验证任务，并且额外地还要能验证PT。 /proxyValidate必须能够验证ST和PT。

2.6.1. parameters
/proxyValidate与/serviceValidate所使用的参数完全相同，请参见2.5.1。

2.6.2. response
/proxyValidate能够返回一个格式化的CAS服务响应XML，此XML的结构参见附录一。
ticket验证成功：

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:user>username</cas:user>
        <cas:proxyGrantingTicket>
PGTIOU-84678-8a9d...
</cas:proxyGrantingTicket>
        <cas:proxies>
            <cas:proxy>https://proxy2/pgtUrl</cas:proxy>
            <cas:proxy>https://proxy1/pgtUrl</cas:proxy>
        </cas:proxies>
    </cas:authenticationSuccess>
</cas:serviceResponse>

请注意，当认证已开始通过多重代理进行时，一组代理的顺序要反映在<cas:proxies>块中。最近访问代理必须首先出现在代理链上，然后按照代理的新旧顺序依次添加到代理链上。在上面的例子中，服务确定的第一个访问代理的网址是：https：//proxy1/pgtUrl，并且服务的代理认证是依靠第二个URL-https：//proxy2/pgtUrl辨别出来的。
注： 代理链<cas:proxies>里面放的是一组代理，是指获取PT的路径。它的顺序代表着同被代理者的远近关系，同被代理者更近的代理者出现在更前面。
ticket验证失败：

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationFailure code="INVALID_TICKET">
        ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not recognized
    </cas:authenticationFailure>
</cas:serviceResponse>

2.6.3 URL examples of /proxyValidate
/proxyValidate与/serviceValidate一样接受相同的参数。参阅第2.5.5使用范例。

2.7. /proxy [CAS 2.0]
/proxy为已经获取PGT的服务提供PT，并且可以为后端服务做代理认证。

2.7.1. parameters
下面的HTTP请求的参数是/proxy必须指定的。他们都区分大小写。
pgt [需要] –代理服务在验证ST和PT后所获取的PGT。
targetService [需要] -后端服务的标识符。请 注意，并非所有的后端服务都是web服务，因此这一标识符不会永远是URL。但是不管怎样，这里指定的服务标识符必须匹配/proxyValidate验证时的“service”参数。

2.7.2. response
/proxy能够返回一个格式化的CAS服务响应XML，此XML的结构参见附录一。
PT申请成功：

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:proxySuccess>
        <cas:proxyTicket>
PT-1856392-b98xZrQN4p90ASrw96c8
</cas:proxyTicket>
    </cas:proxySuccess>
</cas:serviceResponse>

PT申请失败：

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:proxyFailure code="INVALID_REQUEST">
        'pgt' and 'targetService' parameters are both required
    </cas:proxyFailure>
</cas:serviceResponse>

2.7.3. error codes
下面的值可能被用来作为验证失败时“code”属性的值。以下是最低限度的错误代码，所有CAS服务器必须实现的，当然还可以包括一些其他实现。
INVALID_REQUEST -请求参数不全。上面讲到至少必须有“service”和“ticket”两个参数。
BAD_PGT -提供的PGT无效。
INTERNAL_ERROR –在ticket验证时发生内部错误。
对于所有的错误代码，CAS推荐在<cas:authenticationFailure>节点的内容区域提供更详细的错误原因描述。

2.7.4. URL example of /proxy
Simple proxy request: https://server/cas/proxy?targetService=http%3A%2F%2Fwww.service.com&pgt=PGT-490649-W81Y9Sa2vTM7hda7xNTkezTbVge4CUsybAr...

转自：
CAS Protocol - 官网
CAS协议介绍中文版 - 百度文库
JASIG CAS协议介绍 （1）-CAS Entities
JASIG CAS协议介绍 （2）-/login和/logout
JASIG CAS协议介绍 （3）--/validate和/serviceValidate
JASIG CAS协议介绍 （4）- /proxyValidate 和 /proxy