「javacas单点登录」JAVA单点登录

今天给各位分享javacas单点登录的知识，其中也会对JAVA单点登录进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、java web应用如何实现单点登录
• 2、jdk1.7可以实现cas单点登陆吗
• 3、java cas 单点登录 servername什么时候使用
• 4、CAS单点登录原理分析(一)
• 5、从http验证流程解析CAS单点登录
• 6、什么是cas单点登录?

java web应用如何实现单点登录

实现方式一：父域 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版权协议，转载请附上原文出处链接及本声明。

原文链接：

前端通过 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 为二级域名。

jdk1.7可以实现cas单点登陆吗

可以。

JDK环境1.7，操作系统windows，用户权限级别Adminstratorweb服务器：Tomcat7生成证书CAS通过证书来实现客户端与服务端的信息交互，所以第一步当然是生成证书了通过JDK自带的工具keytool来生成证书，密码由自己创建，输入完输入的是域名，注意这个域名需要修改。

jdk1.7是为java开发员提供的工具，可以帮助用户一键安装java环境，附带jdk1.7安装教程，包括Java运行环境、Java工具和Java基础类库，提供了泛型等非常实用的功能。

java cas 单点登录 servername什么时候使用

要使用单点登录，需要部署CAS系统， CAS服务端可以直接部署在tomcat下运行， 对于CAS服务端来说，所有要集成单点登录的web应用都是它的一个客户端， CAS有客户端jar包， 客户端web应用需要引入CAS客户端的jar包，这样CAS系统的服务端和客户端web应用程序端才能通信。

CAS单点登录原理分析(一)

一，业务分析

在分布式系统架构中，假设把上述的三个子系统部署在三个不同的服务器上。前提是用户登录之后才能访问这些子系统。那么使用传统方式，可能会存在这样的问题：

1.当访问用户中心，需要用户登录帐号

2.当访问购物车，还需要用户登录帐号

3.当访问商品结算，又一次需要用户登录帐号

访问每一个子系统都需要用户登录帐号，这样的体验对于用户来说是极差。而使用单点登录就可以很好地解决上述的问题。

二，单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

我们目前的系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，那么使用传统方式的 session 是无法解决的，我们需要使用相关的单点登录技术来解决。

第一步 ：用户访问应用系统1。过滤器判断用户是否登录，没有登录，则重定向（302）到认证系统去进行认证操作。

第二步 ：重定向到认证系统，显示登录界面，用户输入用户名密码。认证系统将用户登录的信息记录到服务器的session中。

第三步 ：认证系统给浏览器发送一个特殊的凭证ticket，浏览器将凭证交给应用系统1，应用系统1则拿着浏览器交给他的凭证ticket去认证系统验证凭证ticket是否有效。凭证ticket若是有效，将用户信息保存到应用系统1的session中一份，并告知应用系统1，用户通过认证。

第四步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第五步 ：当用户再次访问应用系统1，由于应用系统1的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问应用系统1了。

第六步 ：当用户再去访问其他应用系统时，浏览器会带着凭证ticket过去，其他应用系统到认证系统验证凭证，凭证ticket若是有效，将用户信息保存到其他应用系统的session中一份，并告知其他应用系统，用户通过认证。

第七步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第八步 ：当用户再次访问其他应用系统，由于其他应用系统的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问其他应用系统了。

三、Yelu大学研发的CAS(Central Authentication Server)

1.什么是CAS？

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

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

【2】CAS Server 为需要独立部署的 Web 应用。这个CAS框架已经提供

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

从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。下图是 CAS 最基本的协议过程：

2.CAS的详细登录流程

该图主要描述

1.第一次访问

2.在登录状态下第二次访问

3.在登录状态下第一次访问

下面对图中序号代表的操作进行说明

当用户第一次访问

序号1: 用户请求，会经过AuthenticationFilter认证过滤器(在cas client 的web.xml中配置)

主要作用：判断是否登录，如果没有登录则重定向到认证中心。

大概知道这个就行，CAS的具体实现会在以后的博客中写道

序号2:  AuthenticationFilter发现用户没有登录，则返回浏览器重定向地址。

重定向的地址就是认证服务器CAS Server的地址，后面的参数是我们请求的客户端地址，这个参数目的就是为了认证成功以后，根据这个参数的地址重定向回请求的客户端

序号3:  浏览器根据响应回来的重定向地址，向cas.xiaogui.com认证系统发出请求

序号4:  认证系统cas.xiaogui.com接收请求，响应登陆页面

序号5: ：用户登陆页面输入用户名密码，提交请求

序号6: ：CAS Server 认证服务器接收用户名和密码，就行验证，验证逻辑CAS Server 已经实现，并响应给浏览器信息

这里的用户名，密码不需要关心，后续会讲到

图中1，2部分表示序号5 输入的用户名，密码，以及发出的请求。当认证服务器验证通过之后，根据请求参数service的值，进行重定向，其实就是回到了请求的客户端，同时会携带一个ticket令牌参数。同时会在Cookie中设置一个TGC，该cookie是网站认证系统cas.xiaogui.com的cookie，只有访问这个网站才会携带这个cookie过去。

*****注意：这个携带TGC的Cookie是实现CAS单点登录的关键所在！

Cookie中的TGC：向cookie中添加该值的目的是当下次访问cas.xiaogui.com认证系统时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。

TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）

TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。

ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。

序号7:  客户端拿到请求中的ticket信息，也就是图中1的位置

然后经过一个ticket过滤器Cas20ProxyReceivingTicketValidationFilter，去认证系统CAS Server判断ticket是否有效

这个过滤器的主要工作就是校验客户端传过来的ticket是否有效

CAS Client 客户端  shopping.xiaogui.com  中web.xml的配置

序号8:  向CAS Server认证系统发出验证ticket的请求，也就是图中2的位置，然后执行ticket验证

序号9:  通过校验之后，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中，同时告知客户端ticket有效。当用户再次访问该客户端，就可以根据Cookie 中的SessionID找到客户端的Session，获取用户信息，就不用再次进行验证了。也就是图中响应给浏览器的部分。

序号10:  shopping.xiaogui.com客户端接收到cas-server的返回，知道了用户已经登录，ticket有效，告知浏览器可以进行访问。

至此，用户第一次访问流程结束。

当用户第二次访问

序号11: 当用户第二次访问，仍然会经过AuthenticationFilter过滤器，但与第一次访问不同的是此时客户端session中已经存在用户的信息，浏览器中的Cookie会根据SessionID找到Session，获取用户信息，所以不需要进行验证，可以直接访问。

序号12:  客户端告知浏览器可以进行访问。

当用户第一次访问

序号13:   用户向pay.xiaogui.com  CAS Client客户端发出请求

序号14:  ：pay.xiaogui.com接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。

序号15: 浏览器根据上面响应的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。

序号16:  认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ticket，并且返回给浏览器，让他重定向到pay.xiaogui.comCAS Client客户端。

序号17: 根据上面响应回来的地址，进行重定向到pay.xiaogui.comCAS Client客户端

序号18:  pay.xiaogui.comCAS Client客户端带着ticket去认证中心验证是否有效。

序号19:  认证成功，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中。当用户下次访问pay.xiaogui.comCAS Client客户端，直接登录，无需验证。

序号20:  告知浏览器可以进行访问

CAS单点登录的原理分析大致就是上述的这些，至于CAS单点登录的具体实现，将在下篇博客中写道。

从http验证流程解析CAS单点登录

JAVA单点登录有好多种方式，譬如用cookie的domain做，用中间代理做等等，但都需要自行做许多开发工作。而其中耶鲁大学的开源项目CAS提供了一个一站式解决方案，只需很少的扩展即可轻松实现企业级单点登录。基础知识网上其他挺多的，这里我就不详述了。本文通过分析http请求过程中http header，cookie等数据剖析了cas（ 非代理模式，默认验证逻辑。其他如restletAPI等可扩展逻辑本文不会覆盖 ）的验证流程，在开发调试中提供了另一种方便的方式掌控整个流程的关键点 。

TGT:  cas服务端生成的每个用户唯一的ticket。

TGC:  cas服务端根据TGT生成的每个用户的cookie,其value是TGT。

ST:    cas服务端根据每个应用，每个用户生成的一个ticket,验证一次就销毁。

Shiro: JAVA权限管理框架

下面将通过两个客户端应用A、B分别跟cas server端交互来详述整个交互流程。本文基于CAS 4.x。 CAS 5.X默认逻辑一致，只不过通过spring boot进行了重新模块划分。

Cas client拦截请求发现session中无cas assertion(其实就是用户名和ticket)并且没有ST则跳转CAS server(本项目由于用了shiro重写拦截逻辑所以是判断shiro中有没有保存验证后的用户信息), server端发现无TGC跳转配置的CAS登陆URL

Response返回302指示重定向。同时可见response返回两个cookie: CASPRIVACY=和CASTGC= TGT-1-MRebCegmlpucavmxcPqCUMVc496IiJgl06BGyJ736D7c4UPkCw-cas01.example.org

也就是说：cas server端验证通过后产生ST并在location URL后面赋给ticket。此时往客户端浏览器写入TGC,并且指示浏览器重定向到location位置，其正是客户端应用验证ST的路径。

此步骤产生2个ticket: TGT,ST;产生一个cookie:TGC,此cookie是通过用户私密信息与TGT加密生成。

此时客户端应用由于受到shiro的保护，request cookie中就不是JSESSIONID而是shiro的SessionId：sid，uuid模式，其与第一步中的sid一致。

Response返回302指示重定向到另一个页面(第一次访问的页面或者shiro配置的successful url)，同时可见生成了新的session和sessionID。同时可见response返回2个cookie:  JSESSIONID,为servlet容器产生的session id，其为location中的jsessionid；rememberMe,为shiro为自动登录配置的。

此步骤验证ST后（通过url connection去cas server验证ST）如果通过则重定向到新页面(第一次访问的页面或者shiro配置的successful url)产生一个新的容器session id。（为何要重新创建session，因为其会在新的session中保存登陆了客户端应用的凭证CAS Assertion,其为客户端验证ST后返回的）到了这步骤以后属于客户端自身的逻辑。CAS作用到此为止。

可以看到这次直接就访问了，也没有经过验证ticket和与cas服务端交互。此是因为session中已经保存了cas assertion，所以算作登陆了。

可见产生了新的shiro session，并提示跳转CAS服务端登陆URL。

可见并没有要求登陆而是直接就提示跳转到location的URL做验证并产生了一个新的ST。这是因为CAS服务端读取了A应用登陆后在浏览器生成的TGC, request cookie中带入了（下图可以看到），从而认为用户已经登陆，所以直接生成ST，并要求重定向到客户端应用B去验证。

步骤同A应用。

如图

如下图：

可见登出时发生四次请求。

直接访问CAS server端的登出url。Cookie中有CASTGC和server端的JSESSIONID。

返回中CASTGC清空，CASPRIVACY清空。 此时说明server端已经清除了A应用的ST和浏览器的CASTGC

跳转到了客户端应用，发现新创建了shiro session（sid）和servlet容器session（JSESSIONID）

并且发现rememberMe和SID的cookie都被换成deleteMe啦。 此为shiro的loginout拦截器干的好事。

正常访问首页，但是因为没登陆所以提示要重定向到CAS服务端去登陆。（如果有了首页就改为跳转到首页）

同原来步骤。

总的来说，cas （非代理模式，默认验证逻辑） 是用一个cookie(TGC), N个session(N个子系统session，其中存储了cas receipt)来保证各应用的统一登录。

什么是cas单点登录?

CAS是一个单点登录框架，开始是由耶鲁大学的一个组织开发，后来归到apereo去管。 同时CAS也是开源，遵循着apache 2.0协议，代码目前是在github上管理。单点登录：Single Sign On,简称SSO，SSO使得在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。cas单点登录目前国内玉符科技技术实力可以，可以考察，望采纳！

javacas单点登录的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于JAVA单点登录、javacas单点登录的信息别忘了在本站进行查找喔。