[转]单点登录SSO学习——CAS协议内容

作者：anmaler

本文转自：http://blog.zhaojunling.me/p/24

CAS中文文档甚少，这篇文章对CAS接口参数有比较清楚的说明，排版也不错查阅舒适

 

在当前互联网产品中使用单点登录的情况非常的常见，比如Google、百度、阿里云、京东、淘宝等。在用户中心登陆后再访问其他子系统时系统自动检测已登录状态，而不用重新登录。

说起单点登录就不得不说CAS，这个已经成为了单点登录的代名词。

什么是CAS?

CAS是为了解决单点登录问题所设计的一套协议。协议地址http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html

逻辑流程图

借用官网的图片：

上面是通常使用的单点登录逻辑图，代理模式的逻辑图点这里查看。

CAS相关URI

/login	负责凭证管理，即用户统一登录入口，1.0版本提供
/logout	退出的统一入口，1.0版本提供
/validate	服务凭证验证，1.0版本提供，不支持proxy，返回文本字符串yes or no
/serviceValidate	同/validate，2.0版本提供，proxy tickets不能返回验证成功的结果，返回xml字符串
/proxyValidate	同/serviceValidate，2.0版本提供，并提供对proxy tickets的验证，返回xml字符串
/proxy	2.0版本提供，负责提供proxy tickets
/p3/serviceValidate	同/serviceValidate，3.0版本提供，返回的xml结果添加了用户属性字段
/p3/proxyValidate	同/p3/serviceValidate，3.0版本提供，增加对proxy tickets的验证

可以看出，从2.0开始验证结果改成了xml的格式方便扩展，在3.0中增加了用户属性。

/login

功能描述： 负责显示登录页、处理用户登录、生成登录凭据。

参数说明：

service    ：可选，访问受保护地址的标识符，基本都是一个web的URL，需要做URLEncode编码。如果不提供则登录成功后CAS服务器应该显示一个信息告诉用户已登录。

renew     ：可选，忽略已经存在的已登录凭证，要求用户进行登录。不能和gateway同时使用。

gateway ：可选，如果未登录，则不显示登录页面，直接跳转到service的地址，并添加noticket参数在URL的末尾。不能和renew同时使用。

method  ：可选，3.0新增，使用POST的方式发送相应的请求，默认使用302跳转。

请求例子

https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice

Don’t prompt for username/password:

https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice&gateway=true

Always prompt for username/password:

https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice&renew=true

Use POST responses instead of redirects:

https://cas.example.org/cas/login?method=POST&service=http%3A%2F%2Fwww.example.org%2Fservice

后台逻辑

登录成功：重定向用户到service所提供的URL，并添加参数名为ticket的的service ticket。

登录失败：在登录页显示登录失败的原因。

/logout

功能描述： 销毁以保存的已登录凭据。

参数说明：

service    ：可选，登出成功后跳转的URL地址。

后台逻辑

如果cas server支持SLO，则发送一个POST请求的logout格式xml到所有的cas client，如果cas client不支持则直接忽略这个请求。cas server应该忽略所有发送给cas client的异常情况，以保证cas server的稳定性和可用性。如果cas client支持基于service ticket的SLO，则应该返回一个success的HTTP状态码。

/validate

功能描述：验证service ticket的有效性，返回文本格式。

参数说明：

service    ：必选，验证成功后跳转的URL地址。

ticket      ：必选，已获取到的service ticket值。

renew     ：可选，如果设置则只有当service ticket是用户直接登录获取时才返回成功，对之前已经存在的凭据无效。

接口响应内容

验证成功：yes

验证结果：no

/serviceValidate

功能描述：验证service ticket的有效性，返回xml格式的结果。

参数说明：

service    ：必选，验证成功后跳转的URL地址。

ticket      ：必选，已获取到的service ticket值。

renew     ：可选，如果设置则只有当service ticket是用户直接登录获取时才返回成功，对之前已经存在的凭据无效。

pgtUrl    ：可选，proxy callback时的URL，在代理流程时候使用。

接口响应内容

验证成功：

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

错误代码：

INVALID_REQUEST	缺少必须参数。
INVALID_TICKET_SPEC	不满足验证规范的要求。
UNAUTHORIZED_SERVICE_PROXY	未被授权的service。
INVALID_PROXY_CALLBACK	无效的proxy callback。
INVALID_TICKET	无效的ticket，如果设置了renew且ticket不是来自初始登录则也会被标识为无效。
INVALID_SERVICE	ticket有效，但是相关联的service和当前提供的不匹配，CAS Server需要是销毁当前的ticket并保证一个ticket只会使用一次。
INTERNAL_ERROR	CAS server的内部服务器错误。

 另：如果此接口收到的ticket是一个proxy ticket，则不能返回成功的验证结果，应该在验证失败的文本消息中明确提示，如“验证失败，收到的是proxy ticket”。            

/proxyValidate 

功能描述： 参考/serviceValidate，添加了对proxy tickets的验证支持。

接口相应内容

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

/proxy 

功能描述： 根据之前产生的PGT，获取prox service ticker供/proxyValidate接口交互使用。                          

参数说明：

pgt                 ：必选，在/serviceValidate接口中cas server生成的PGT。

targetService ：必选，后端server的地址，需要和下一步验证的/proxyValidate中service相同。

接口相应内容

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">

      <cas:proxySuccess>

          <cas:proxyTicket>PT-1856392-b98xZrQN4p90ASrw96c8</cas:proxyTicket>

      </cas:proxySuccess>

</cas:serviceResponse>

/p3/serviceValidate 

功能描述： 同/serviceValidate，返回xml中增加了user信息的属性。

/p3/proxyValidate

功能描述： 同/p3/serviceValidate，增加了对proxy tickets验证的支持。

CAS中涉及的实体说明

service ticket：一个不易被预测的字符串，可作为用户访问service的凭证。

相关要注意的地方

• 在登录的接口逻辑中生成，提供的service值不要出现在ticket中。

• 使用一次后应该立即失效不管是否验证成功，再此使用相同的ticket验证时必须返回验证失败。

• 应该设置一个合理的有效期，使用过期的ticket验证必须返回验证失败。

• 建议验证失败时返回验证失败的具体原因信息。

• 建议设置的有效期时间不超过5分钟。

• 必须包含一段随机字符串，以保证不会被猜测到。

• 必须使用ST-为字符串开头。

• 必须支持保护32个以上的字符，建议支持到256个字符串的长度。

   

proxy ticket：一个不易被预测的字符串，可作为访问后端service的凭证。

相关要注意的地方

• 在/proxy接口中生成，提供的service值不要出现在proxy ticket中。

• 使用一次后应该立即失效不管是否验证成功，再此使用相同的ticket验证时必须返回验证失败。

• 应该设置一个合理的有效期，使用过期的ticket验证必须返回验证失败。

• 建议验证失败时返回验证失败的具体原因信息。

• 建议设置的有效期时间不超过5分钟。

• 必须包含一段随机字符串，以保证不会被猜测到。

• 必须使用PT-为字符串开头。

• 后台service必须能接收至少32位长度的字符串的ticket。

• 建议支持到256个长度字符串的ticket。

   

proxy-granting ticket：一个不易被预测的字符串，验证service ticket后生成，可用于获取proxy ticket。

相关要注意的地方

• 可用于获取多个proxy ticket，可多次数使用而不失效。

• 当用户从CAS退出时，此ticket必须失效。

• 必须包含一段随机字符串，以保证在一段时间不会被穷举法所破解。

• 应该使用PGT-为字符串开头。

• 需要可以处理超过64位长度的数据。

• 建议支持到256个长度字符串的数据。

 

proxy-granting ticket IOU：在/serviceValidate和/proxyValidate接口中返回的一段字符串，用来关联service ticket (或proxy ticket)和proxy-granting ticket。

相关要注意的地方

• 不应该包含任何与之有关联的PGT信息，必须确认不能从给定的PGTIOU字符串推算出PGT。

• 必须包含一段随机字符串，以保证在一段时间不会被穷举法所破解。

• 应该使用PGTIOU-为字符串开头。

• 必须支持保护32个以上的字符，建议支持到256个字符串的长度。

   

login ticket：和用户名密码一起提交到后台，为了防止浏览器重复提交而造成的重复生成已登录凭证。

相关要注意的地方

• 必须尽可能的唯一

• 必须是一次性有效的，不管登录成功或者失败。

• 应该使用LT-为字符串开头。

   

ticket-granting cookie: 用于确认已登录状态的标识，保存在用户的浏览器cookie中。

相关要注意的地方

• 如果未设置Long-Term支持，则过期时间应该设置为当前浏览器的回话时间。

• 最好设置尽可能严格的路径，比如cas server部署到/cas则cookie的path应最好设置为/cas。

• 尽量包含一段随机字符串，以保证在一段时间不会被穷举法所破解。

• 应该使用TGC-作为cookie名称开头。

• cookie的值应该和ticket-granting ticket使用相同的规则生成，通常直接使用ticket-granting ticket的值。

   

ticket and ticket-granting cookie 内容格式

所有的ticket以及ticket-granting cookie仅能包含如下字符：a-z、A-Z、0-9、-(连字符号)。

 

ticket-granting ticket: 在cas server成功登陆后生成的字符串，可以和标识单点登录状态的ticket-granting cookie绑定，在一定时间内作为基础生成service tickets, proxy-granting tickets 等。

相关要注意的地方

• 可以用于获取多个service tickets，不是一次性失效的，有过期时间和安全策略。

• 登出cas的时候必须过期失效。

• 必须包含一段随机字符串，以保证在一段时间不会被穷举法所破解。

• 应该使用TGT-作为字符串开头。

• 当分享给外部资源使用时推荐进行加密，以减少安全漏洞避免泄漏与之关联了的身份认证回话。