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

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

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

什么是CAS?

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

逻辑流程图

借用官网的图片:

1429610842275.png

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

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字符串
/proxy2.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_SERVICEticket有效,但是相关联的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-作为字符串开头。

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

提交评论