CAS单点登陆的两个原理图
最近学习CAS单点登录,所以在网上找了两张比较清晰的原理图以供参考:
【CAS浏览器请求认证序列图】
其中:
* ST:Service Ticket,用于客户端应用持有,每个ST对应一个用户在一个客户端上
* TGT:Ticket Granting Ticket,存储在CAS服务器端和用户cookie两个地方
【CAS服务器端登陆流程图】
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。