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

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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版权协议,转载请附上原文出处链接及本声明。

原文链接: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 为二级域名。

参考技术A 
风水道人
关注
javaweb单点登录的三种实现方式 原创
2021-03-02 22:39:35

风水道人 

码龄6年

关注
前言

实现方式一:父域 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 中。
参考技术B Java Web应用可以使用单点登录(SSO)技术来实现。具体步骤如下:
1. 集成认证中心
首先,需要集成一个统一认证中心,例如Shiro、Spring Security或者CAS等。认证中心负责用户的身份验证和授权,并生成用于标识用户身份的令牌。
2. 实现单点登录
当用户在任何一个已登录的应用程序中访问另一个应用程序时,应用程序会向认证中心发出验证请求,以验证用户是否已经进行了身份验证。如果用户已经完成了身份验证,则认证中心将颁发一个令牌,该令牌可用于其他应用程序进行身份验证。
3. 共享Session
为了实现单点登录,不同的应用程序需要共享Session。可以使用Session共享技术,例如Apache Shiro提供的Session Clustering,或者使用共享数据库等方式实现Session共享。
4. 用户退出
当用户在一个应用程序中注销时,应用程序应该通知认证中心撤销令牌。这样用户就不能再访问已登录的其他应用程序。
总之,Java Web应用要实现单点登录,需要集成认证中心,实现单点登录,共享Session和正确处理用户注销操作。
参考技术C 单点登录(Single Sign-On,简称SSO)是指用户在一次登录后,即可访问多个相互信任的Web应用系统,而不需要重新输入用户名和密码。实现单点登录可以提高用户体验和安全性,减少用户重复登录的次数,降低密码被盗风险。
在Java Web应用中,实现单点登录通常采用以下几种方法:
1.基于Cookie的实现方式
基于Cookie的实现方式是最常见的一种方法。当用户在第一个Web应用系统中进行登录时,该系统会生成一个包含用户身份信息的Cookie,并在其他Web应用系统中将该Cookie发送给服务器进行验证。如果该Cookie有效,则用户无需再次登录即可访问其他系统。
2.基于Session的实现方式
基于Session的实现方式与基于Cookie的实现方式类似,不同之处在于用户身份信息是存储在Session中而不是Cookie中。当用户进行登录时,第一个Web应用系统会创建一个Session,并将该Session ID发送给其他Web应用系统进行验证。
3.基于统一认证平台的实现方式
基于统一认证平台的实现方式是一种更加完整的解决方案。在该方案中,所有Web应用系统都集成到一个统一的认证平台中,用户在进行登录时,只需要登录一次即可访问所有应用系统。该方案需要实现一个认证中心,用于管理用户身份信息、提供认证服务、处理单点登录等相关功能。
需要注意的是,在实现单点登录的过程中,要考虑到安全性问题,如跨站点请求伪造(CSRF)、会话劫持等。因此,建议在实现单点登录时,采用HTTPS协议、加密传输数据,使用Token等验证机制,以增强系统的安全性。
参考技术D

Java Web 应用实现单点登录(Single Sign-On, SSO)的方法有很多,以下是常见的几种方法:

    基于 Cookie 的 SSO:在登录成功后,在客户端生成一个 Token(通常是一个加密的字符串),并将其存储在客户端的 Cookie 中,在请求其他应用时,通过检查这个 Token 判断用户是否已登录。

    基于 Session 的 SSO:登录成功后,在服务器端生成一个 Session,并将其存储在服务器端,在请求其他应用时,通过检查这个 Session 判断用户是否已登录。

    基于 OAuth2 的 SSO:通过使用 OAuth2 协议实现用户认证和授权,从而实现单点登录。

    基于 SAML 的 SSO:使用 SAML(Security Assertion Markup Language)协议实现单点登录。

如何基于JAAS(Authorization)实现多个Web应用的单点登录

【中文标题】如何基于JAAS(Authorization)实现多个Web应用的单点登录【英文标题】:how to implement single sign-on for multiple Web applications based on JAAS(Authorization) 【发布时间】:2012-05-05 08:46:47 【问题描述】:

我开始使用 SSO 开发 JAAS,我对 JAAS 有一些疑问。 JAAS(Java Authentication and Authorization Service)框架,以迎合多种身份验证机制。 SSO 服务器根据自己的数据库或外部目录服务器验证登录信息,并返回登录用户可以执行的会话上下文和应用程序列表。在这里,我想再实现一个 Web 应用程序。据我所知, SSO JAAS 将返回会话上下文。在我的客户端 Web 应用程序中,我已经拥有用于身份验证的 acegi 安全性,使用我的 acegi 安全性如何从我的 SSO JAAS 获取会话上下文进行授权。我正在尝试找出任何配置示例,但我仍然没有得到任何解决示例。

【问题讨论】:

【参考方案1】:

看看这个spring security configuration。这不是你想要的,但它会告诉你方法

关键点

检查身份验证管理器是如何定义的 PreAuthenticatedAuthenticationProvider。 preAuthenticatedUserDetailsS​​ervice 属性定义了一个 bean,它允许您从 JAAS Authentication 对象创建 Spring Security UserDetails 对象 j2eePreAuthFilter 过滤器是将 JAAS 的安全性委托给 spring 安全性的过滤器。

剩下的是标准的spring安全配置

希望对你有所帮助

【讨论】:

enterlezi ,我理解了这个概念,你能给我更多用于第三方Web应用程序JAAS实现的cmets

以上是关于java web应用如何实现单点登录的主要内容,如果未能解决你的问题,请参考以下文章

cas单点登录怎么在服务器端获得用户信息

java实现的单点登录

java实现简单的单点登录

java实现简单的单点登录 (转)

如何基于JAAS(Authorization)实现多个Web应用的单点登录

求解!单点登录怎么实现的?