cas号是什么意思

①前端vue项目判断如果有token,则说明用户已登录，可以访问客户端A的服务。否则未登陆，未登陆有两种状态：在单点登录服务端已经登录和未在单点登录服务端登陆

    判断如果有ticket，则说明已在单点登录服务端登录。调用/cas/client/validateLogin接口验证该ticket是否有效。转②

    判断如果无ticket,则说明未在单点登录服务端登录。则定向到单点登录服务端。转③

②/cas/client/validateLogin接口方法，发起http请求到单点登录服务端进行ticket验证，如果验证通过，则登录成功。单点登录客户端A生成token返回给前端，之后前端通过携带token访问客户端A的服务。

③单点登录服务端返回登录表单，用户输入用户名密码确定登录后，单点登录服务端调用用户信息验证端/auth/user/login接口，传递用户名密码参数，将验证委托给用户信息验证端

④登录成功验证通过后，携带ticket返回浏览器，重定向地址如下:

http://localhost:8000/?ticket=ST-6-NqvtyjRhezstXiyyzNNN-C-DiTw-DESKTOP-CVVQ0QK

接入用户信息验证端参考

实现方式一：父域 Cookie

实现方式二：认证中心

实现方式三：LocalStorage 跨域

补充：域名分级

在 B/S 系统中，登录功能通常都是基于 Cookie 来实现的。当用户登录成功后，一般会将登录状态记录到 Session 中，或者是给用户签发一个 Token，无论哪一种方式，都需要在客户端保存一些信息（Session ID 或 Token ），并要求客户端在之后的每次请求中携带它们。在这样的场景下，使用 Cookie 无疑是最方便的，因此我们一般都会将 Session 的 ID 或 Token 保存到 Cookie 中，当服务端收到请求后，通过验证 Cookie 中的信息来判断用户是否登录 。

单点登录（Single Sign On, SSO）是指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的应用系统。举例来说，百度贴吧和百度地图是百度公司旗下的两个不同的应用系统，如果用户在百度贴吧登录过之后，当他访问百度地图时无需再次登录，那么就说明百度贴吧和百度地图之间实现了单点登录。

单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。

当然仅此是不够的，因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 app1.com 中登录后，Session ID 仅在浏览器访问 app1.com 时才会自动在请求头中携带，而当浏览器访问 app2.com 时，Session ID 是不会被带过去的。实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

实现方式一：父域 Cookie

在将具体实现之前，我们先来聊一聊 Cookie 的作用域。

Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名/IP地址，在 Tomcat 中，domain 属性默认为当前域的域名/IP地址。path 属性的有效值是以“/”开头的路径，在 Tomcat 中，path 属性默认为当前 Web 应用的上下文路径。

如果将 Cookie 的 domain 属性设置为当前域的父域，那么就认为它是父域 Cookie。Cookie 有一个特点，即父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的Cookie。

利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。

总结：此种实现方式比较简单，但不支持跨主域名。

实现方式二：认证中心

我们可以部署一个认证中心，认证中心就是一个专门负责处理登录请求的独立的 Web 服务。

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。

应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。

这里顺便介绍两款认证中心的开源实现：

Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了Apereo 基金会，项目也随之更名为 Apereo CAS。

XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。

总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。

实现方式三：LocalStorage 跨域

前面，我们说实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

父域 Cookie 确实是一种不错的解决方案，但是不支持跨域。那么有没有什么奇淫技巧能够让 Cookie 跨域传递呢？

很遗憾，浏览器对 Cookie 的跨域限制越来越严格。Chrome 浏览器还给 Cookie 新增了一个 SameSite 属性，此举几乎禁止了一切跨域请求的 Cookie 传递（超链接除外），并且只有当使用 HTTPs 协议时，才有可能被允许在 AJAX 跨域请求中接受服务器传来的 Cookie。

不过，在前后端分离的情况下，完全可以不使用 Cookie，我们可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端。

在这样的场景下，单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。

————————————————

版权声明：本文为CSDN博主「风水道人」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/jcmj123456/article/details/114296482

前端通过 iframe+postMessage() 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取 Token 并在请求中携带，这样就实现了同一份 Token 被多个域所共享。

总结：此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。

补充：域名分级

从专业的角度来说（根据《计算机网络》中的定义），.com、.cn 为一级域名（也称顶级域名），.com.cn、baidu.com 为二级域名，sina.com.cn、tieba.baidu.com 为三级域名，以此类推，N 级域名就是 N-1 级域名的直接子域名。

从使用者的角度来说，一般把可支持独立备案的主域名称作一级域名，如 baidu.com、sina.com.cn 皆可称作一级域名，在主域名下建立的直接子域名称作二级域名，如 tieba.baidu.com 为二级域名。

CAS是CentralAuthenticationService的缩写，中央认证服务，一种独立开放指令协议。

CAS是 Yale 大学发起的一个开源项目，旨在为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为JA-SIG的一个项目。

特点

1、开源的企业级单点登录解决方案。

2、CASServer为需要独立部署的Web应用。

3、CASClient支持非常多的客户端(这里指单点登录系统中的各个Web应用)，包括Java,.Net,PHP,Perl,Apache,uPortal,Ruby等。

原理和协议

从结构上看，CAS包含两个部分：CASServer和CASClient。CASServer需要独立部署，主要负责对用户的认证工作；

CASClient负责处理对客户端受保护资源的访问请求，需要登录时，重定向到CASServer。图是CAS最基本的协议过程：

CASClient与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。对于访问受保护资源的每个Web请求，CASClient会分析该请求的Http请求中是否包含ServiceTicket，

如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的CASServer登录地址，并传递Service（也就是要访问的目的资源地址），以便登录成功过后转回该地址。

用户在第3步中输入认证信息，如果登录成功，CASServer随机产生一个相当长度、唯一、不可伪造的ServiceTicket，并缓存以待将来验证，

之后系统自动重定向到Service所在地址，并为客户端浏览器设置一个TicketGrantedCookie（TGC），

CASClient在拿到Service和新产生的Ticket过后，在第5，6步中与CASServer进行身份核实，以确保ServiceTicket的合法性。

在该协议中，所有与CAS的交互均采用SSL协议，确保，ST和TGC的安全性。协议工作过程中会有2次重定向的过程，但是CASClient与CASServer之间进行Ticket验证的过程对于用户是透明的。

另外，CAS协议中还提供了Proxy（代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考CAS官方网站上的相关文档。

扩展资料

使用CAS在Tomcat中实现单点登录中部署客户端应用

单点登录的目的是为了让多个相关联的应用使用相同的登录过程，本文在讲解过程中构造2个简单的应用，分别以casTest1和casTest2来作为示例，它们均只有一个页面，显示欢迎信息和当前登录用户名。

这2个应用使用同一套登录信息，并且只有登录过的用户才能访问，通过本文的配置，实现单点登录，即只需登录一次就可以访问这两个应用。

与CASServer建立信任关系

假设CASServer单独部署在一台机器A，而客户端应用部署在机器B上，由于客户端应用与CASServer的通信采用SSL，因此，需要在A与B的JRE之间建立信任关系。

首先与A机器一样，要生成B机器上的证书，配置Tomcat的SSL协议。

其次，下载http://blogs.sun.com/andreas/entry/no_more_unable_to_find 的InstallCert.java，运行“javaInstallCertcompA:8443”命令，

并且在接下来出现的询问中输入1。

这样，就将A添加到了B的truststore中。如果多个客户端应用分别部署在不同机器上，那么每个机器都需要与CASServer所在机器建立信任关系。

配置CASFilter

准备好应用casTest1和casTest2过后，分别部署在B和C机器上，由于casTest1和casTest2，B和C完全等同，我们以casTest1在B机器上的配置做介绍，

假设A和B的域名分别为domainA和domainB。

将cas-client-java-2.1.1.zip改名为cas-client-java-2.1.1.jar并拷贝到casTest1/WEB-INF/lib目录下，修改web.xml文件，添加CASFilter，如清单10所示：

清单10.添加CASFilter

<web-app>  ...  <filter>

<filter-name>CASFilter</filter-name>

    <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>

<init-param>

      <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>

<param-value>https://domainA:8443/cas/login</param-value>

    </init-param>

<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>

      <param-value>https://domainA:8443/cas/serviceValidate</param-value>

</init-param>

    <init-param>

<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>

      <param-value>domainB:8080</param-value>

</init-param>

  </filter>

<filter-mapping>

<filter-name>CASFilter</filter-name>

    <url-pattern>/protected-pattern/*</url-pattern>

</filter-mapping>

  ...

</web-app>

对于所有访问满足casTest1/protected-pattern/路径的资源时，都要求到CASServer登录，如果需要整个casTest1均受保护，可以将url-pattern指定为“/*”。

从清单10可以看到，我们可以为CASFilter指定一些参数，并且有些是必须的，表格1 和表格2 中分别是必需和可选的参数：

表格1.CASFilter必需的参数

表格2.CASFilter可选参数

传递登录用户名

CAS在登录成功过后，会给浏览器回传Cookie，设置新的到的ServiceTicket。但客户端应用拥有各自的Session，我们要怎么在各个应用中获取当前登录用户的用户名呢？

CASClient的Filter已经做好了处理，在登录成功后，就可以直接从Session的属性中获取，如清单11所示：

清单11.在Java中通过Session获取登录用户名

1  //以下两者都可以

2  session.getAttribute(CASFilter.CAS_FILTER_USER)

3  session.getAttribute("edu.yale.its.tp.cas.client.filter.user")

在JSTL中获取用户名的方法如清单12所示：

清单12.通过JSTL获取登录用户名

1  <c:outvalue="${sessionScope[CAS:'edu.yale.its.tp.cas.client.filter.user']}"/>

另外，CAS提供了一个CASFilterRequestWrapper类，该类继承自HttpServletRequestWrapper，主要是重写了getRemoteUser()方法，

只要在前面配置CASFilter的时候为其设置“edu.yale.its.tp.cas.client.filter.wrapRequest”参数为true，就可以通过getRemoteUser（）方法来获取登录用户名，具体方法如清单13所示：

清单13.通过CASFilterRequestWrapper获取登录用户名

1 CASFilterRequestWrapper reqWrapper=newCASFilterRequestWrapper(request)

2 out.println("Thelogonuser:"+reqWrapper.getRemoteUser())

参考资料来源：百度百科-CAS

参考资料来源：IBM中国-使用CAS在Tomcat中实现单点登录