CAS协议 - CAS URIs

http://desert3.iteye.com/blog/1703449

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验证成功：

Xml代码  

  1. yes<LF>
  2. username<LF>

ticket验证失败：

Xml代码  

  1. no<LF>
  2. <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。  凭证验证成功：

Xml代码  

  1. <cas:serviceResponse xmlns:cas=‘http://www.yale.edu/tp/cas‘>
  2. <cas:authenticationSuccess>
  3. <cas:user>username</cas:user>
  4. <cas:proxyGrantingTicket>PGTIOU-84678-8a9d...
  5. </cas:proxyGrantingTicket>
  6. </cas:authenticationSuccess>
  7. </cas:serviceResponse>

凭证验证失败：

Xml代码  

  1. <cas:serviceResponse xmlns:cas=‘http://www.yale.edu/tp/cas‘>
  2. <cas:authenticationFailure code="INVALID_TICKET">
  3. Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized
  4. </cas:authenticationFailure>
  5. </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验证成功：

Xml代码  

  1. <cas:serviceResponse xmlns:cas=‘http://www.yale.edu/tp/cas‘>
  2. <cas:authenticationSuccess>
  3. <cas:user>username</cas:user>
  4. <cas:proxyGrantingTicket>
  5. PGTIOU-84678-8a9d...
  6. </cas:proxyGrantingTicket>
  7. <cas:proxies>
  8. <cas:proxy>https://proxy2/pgtUrl</cas:proxy>
  9. <cas:proxy>https://proxy1/pgtUrl</cas:proxy>
  10. </cas:proxies>
  11. </cas:authenticationSuccess>
  12. </cas:serviceResponse>

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

Xml代码  

  1. <cas:serviceResponse xmlns:cas=‘http://www.yale.edu/tp/cas‘>
  2. <cas:authenticationFailure code="INVALID_TICKET">
  3. ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not recognized
  4. </cas:authenticationFailure>
  5. </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申请成功：

Xml代码  

  1. <cas:serviceResponse xmlns:cas=‘http://www.yale.edu/tp/cas‘>
  2. <cas:proxySuccess>
  3. <cas:proxyTicket>
  4. PT-1856392-b98xZrQN4p90ASrw96c8
  5. </cas:proxyTicket>
  6. </cas:proxySuccess>
  7. </cas:serviceResponse>

PT申请失败：

Xml代码  

  1. <cas:serviceResponse xmlns:cas=‘http://www.yale.edu/tp/cas‘>
  2. <cas:proxyFailure code="INVALID_REQUEST">
  3. ‘pgt‘ and ‘targetService‘ parameters are both required
  4. </cas:proxyFailure>
  5. </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

时间： 2024-11-10 00:07:27

CAS协议 - CAS URIs的相关文章

cas协议，以及tomcat搭建cas服务器

1.      CAS 简介 1.1.  What is CAS ? CAS ( Central Authentication Service ) 是 Yale 大学发起的一个企业级的.开源的项目,旨在为 Web 应用系统提供一种可靠的单点登录解决方法(属于 Web SSO ). CAS 开始于 2001 年, 并在 2004 年 12 月正式成为 JA-SIG 的一个项目. 1.2.  主要特性 1.   开源的.多协议的 SSO 解决方案: Protocols : Custom Protoc

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

作者:anmaler 本文转自:http://blog.zhaojunling.me/p/24 CAS中文文档甚少,这篇文章对CAS接口参数有比较清楚的说明,排版也不错查阅舒适 在当前互联网产品中使用单点登录的情况非常的常见,比如Google.百度.阿里云.京东.淘宝等.在用户中心登陆后再访问其他子系统时系统自动检测已登录状态,而不用重新登录. 说起单点登录就不得不说CAS,这个已经成为了单点登录的代名词. 什么是CAS? CAS是为了解决单点登录问题所设计的一套协议.协议地址http://ja

读取设置memcache的值（优先支持memcached扩展和cas协议）

最近在项目中因为要防止并发,需要使用php的memcached扩展,memcached扩展支持cas协议,而memcache扩展却不支持.安装memcached过程中发现windows下并没有该扩展,为了保持代码的一致,就写了一个既支持memcached又支持memcache的类,这样就不用担心生产和本地开发代码的不一致.(注:笔者平常工作在windows下开发,生产环境是Linux.如果你平常开发和生产环境都是linux或mac的话就不会有这个问题) 下面就直接贴出代码了: <?php cla

集成基于CAS协议的单点登陆

相信大家对单点登陆(SSO,Single Sign On)这个名词并不感到陌生吧?简单地说,单点登陆允许多个应用使用同一个登陆服务.一旦一个用户登陆了一个支持单点登陆的应用,那么在进入其它使用同一单点登陆服务的应用时就不再需要重新登陆了.而CAS协议则正是各单点登陆产品所需要实现的协议,其全称为Central Authentication Service. 那为什么要写这篇博客呢?这是因为在为公司的产品集成SSO的时候,我发现如果软件开发人员不了解CAS协议,那么他在集成出现错误的时候将完全没有

根据CAS协议写的简单的SSO框架

前言: 考虑到现在分布式应用都不可或缺的一个重要部分:单点登录,决定花点时间去学下.本来想直接上现成的CAS框架的,初步的了解了一下后,觉得这个太庞大了,而且不好定制,要完全深度用起来也没那么简单(虽然可能上手容易).于是脑袋一热,决定自己根据CAS协议自己实现一个(虽然不是很喜欢CAS,但CAS协议还是完全的SSO的标准),开始后前后各种被打断,工作啦,加班啦,花时间解决自己的终身大事啦,拖拖拉拉到现在终于初步得已实现.但是现在还仅仅是实现,尚有很多待优化的部分,由于个人工作还是比较忙的,所以

cas+tomcat+shiro实现单点登录-4-Apache Shiro 集成Cas作为cas client端实现

目录 1.tomcat添加https安全协议 2.下载cas server端部署到tomcat上 3.CAS服务器深入配置(连接MYSQL) 4.Apache Shiro 集成Cas作为cas client端实现 Apache Shiro 集成Cas作为cas client端实现 第一步.添加maven依赖 <!-- shiro依赖包 --> <!-- <dependency> <groupId>org.apache.shiro</groupId> &

cas系列-cas登出(四)

跟登陆一样,登出操作也很重要.由于是多应用间操作,状态保持也是一个要点,根据登出的影响范围,可以将登出操作分为两类: 单应用登出 单点登出(多应用登出) 顾名思义,单应用登出即登出只影响被操作的应用会话,其他应用和CAS会话状态不受影响.这也就需要你退出每一个应用,如果应用数量较多,每次退出可能都是件力气活.单点登出是结束SSO会话,所有建立在SSO会话上的的应用会话都会进行登出.使用户的状态保持一致.当应用间会话记录不一致时,登出操作可能会造成会话记录丢失; 登出操作: /logout?ser

（转）CAS (4) —— CAS浏览器SSO访问顺序图详解（CAS Web Flow Diagram by Example）

CAS (4) —— CAS浏览器SSO访问顺序图详解(CAS Web Flow Diagram by Example) tomcat版本: tomcat-8.0.29 jdk版本: jdk1.8.0_65 nginx版本: nginx-1.9.8 cas版本: cas4.1.2cas-client-3.4.1 参考来源: jasig.github.io:CAS protocol CAS (1) —— Mac下配置CAS到Tomcat(服务端) CAS (2) —— Mac下配置CAS到Tomc

cas sso单点登录系列2:cas客户端和cas服务端交互原理动画图解，cas协议终极分析

转:http://blog.csdn.net/ae6623/article/details/8848107 1)PPT流程图:ppt下载:http://pan.baidu.com/s/1o7KIlom 一.用户第一次访问web1应用. ps:上图少画了一条线,那一条线,应该再返回来一条,然后再到server端,画少了一步...谢谢提醒.而且,重定向肯定是从浏览器过去的.我写的不严谨,画的比较通俗了...因该像下面这张图一样就ok了!!PPT自己下载下来修改吧,我就不改了. 二.用户第一次访问we