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 。