sso

摘要 ：单点登录（ SSO ）的技术被越来越广泛地运用到各个领域的软件系统当中。本文从业务的角度分析了单点登录的需求和应用领域；从技术本身的角度分析了单点登录技术的内部机制和实现手段，并且给出 Web-SSO 和桌面 SSO 的实现、源代码和详细讲解；还从安全和性能的角度对现有的实现技术进行进一步分析，指出相应的风险和需要改进的方面。本文除了从多个方面和角度给出了对单点登录（ SSO ）的全面分析，还并且讨论了如何将现有的应用和 SSO 服务结合起来，能够帮助应用架构师和系统分析人员从本质上认识单点登录，从而更好地设计出符合需要的安全架构。 关键字 ： SSO, Java, J2EE, JAAS 1 什么是单点登陆 单点登录（ Single Sign On ），简称为 SSO ，是目前比较流行的企业业务整合的解决方案之一。 SSO 的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和 IT 服 务。例如财务系统为财务人员提供财务的管理、计算和报表服务；人事系统为人事部门提供全公司人员的维护服务；各种业务系统为公司内部不同的业务提供不同的 服务等等。这些系统的目的都是让计算机来进行复杂繁琐的计算工作，来替代人力的手工劳动，提高工作效率和质量。这些不同的系统往往是在不同的时期建设起来 的

看到好的文章分享一下，我就不多写了，都是简单易懂的 博客地址1： https://www.cnblogs.com/libinhyq/p/9561582.html 博客地址2： https://blog.csdn.net/weixin_42686388/article/details/81299609 来源： CSDN 作者： 慕云枫 链接： https://blog.csdn.net/weixin_43992507/article/details/96987507

什么是单点登录SSO？ 今天介绍下什么是单点登录，这个曾经的使用场景是国网电力的PMS2.0系统中，为了仅一次登录就可以同时访问多个系统，采用单点登录的模式。 单点登录在现在的系统架构中广泛存在，他将多个子系统的认证体系打通，实现了一个入口多处使用，而在架构单点登录时，也会遇到一些小问题，在不同的应用环境中可以采用不同的单点登录实现方案来满足需求。我将以我所遇到的应用环境以及在其中所经历的各个阶段与大家分享，若有不足，希望各位不吝赐教。 一、共享Session 共享Session可谓是实现单点登录最直接、最简单的方式。将用户认证信息保存于Session中，即以Session内存储的值为用户凭证，这在单个站点内使用是很正常也很容易实现的，而在用户验证、用户信息管理与业务应用分离的场景下即会遇到单点登录的问题，在应用体系简单，子系统很少的情况下，可以考虑采用Session共享的方法来处理这个问题。 这个架构我使用了基于Redis的Session共享方案。将Session存储于Redis上，然后将整个系统的全局Cookie Domain设置于顶级域名上，这样SessionID就能在各个子系统间共享。 这个方案存在着严重的扩展性问题，首先，ASP.NET的Session存储必须为SessionStateItemCollection对象，而存储的结构是经过序列化后经过加密存储的

SSO（ Single Sign On ），即单点登录，是一种控制多个相关但彼此独立的系统的访问权限, 拥有这一权限的用户可以使用单一的ID和密码访问某个或多个系统从而避免使用不同的用户名或密码，或者通过某种配置无缝地登录每个系统 。 对于大型系统来说使用单点登录可以减少用户很多的麻烦。就拿百度来说吧，百度下面有很多的子系统——百度经验、百度知道、百度文库等等，如果我们使用这些系统的时候，每一个系统都需要我们输入用户名和密码登录一次的话，我相信用户体验肯定会直线下降。 与 SSO 交互的2个元素：1. 用户，2. 系统，它的特点是： 一次登录，全部访问 。SSO 是访问控制的一种，控制用户能否登录，即验证用户身份，而且是所有其它系统的身份验证都在它这里进行，从整个系统层面来看 SSO ，它的核心就是这3个元素了：1. 用户，2. 系统，3. 验证中心。 1、同一个域但不同的子域如何进行单点登录 假如我们的站点是按照下面的域名进行部署的： sub1.onmpw.com sub2.onmpw.com 这两个站点共享同一域 onmpw.com 。 默认情况下，浏览器会发送 cookie 所属的域对应的主机。也就是说，来自于 sub1.onmpw.com 的 cookie 默认所属的域是 .sub1.onmpw.com 。因此， sub2.onmpw.com 不会得到任何的属于 sub1

这个文章我们来讨论一下单点登录SSO的一些实现方式，其中包括对session和cookie的一些讨论。 一、 我们知道http协议是无状态的协议，也就是说一次请求对应一次响应，不和这次请求的上一次和下一次请求产生关联。那么这样就有一个问题，比如说，我们想实现一个购物车，我们往购物车中添加商品，每次刷新发现上一次添加的商品不见了，每次购物车里都是这次添加的商品，前面添加的不见了。为什么？就是因为http是无状态协议，它压根不知道你上一次往购物车里添加了什么商品。那么我们要怎么做才能让购物车保存我们前面添加的商品？那么，我们首先要让服务器知道”你就是你“。 举个例子，比如说现在有两个人user1，user2在往购物车里添加东西。user1添加了A，B商品，user2添加了C，D商品，此时user1想看看自己到底往购物车里放了什么商品，于是user1点了一下购物车的图标，服务器收到请求，有个用户要查看购物车的商品，要把购物车的商品返回给用户。那么到底是返回user1的还是user2的呢？也就是说服务器凭什么知道这次请求来自user1（把user1的购物商品返回）呢？ 那么是不是说我们让我们的浏览器和服务器之间通过一个凭证来通信就可以解决。还是那上面的例子来说。比如user1登录了这个购物网站，服务器收到了这个请求，然后告诉user1说我给你一个凭证（card1）

一、sso单点登录原理 单点登录全称Single Sign On（简称SSO），是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分 结合本项目案例，画了下SSO单点登录原理图，如下： 二、sso单点登录实现 1.sso-server单点登录服务端 1.sso-server服务端包含三个模块： sso-common通用模块 sso-entity实体类模块 sso-web核心web模块 其中sso-common和sso-entity作为sso-client的依赖 2.核心代码 /** * Created by wly on 2018/11/19. */ @Controller @RequestMapping("/sso") public class SsoController extends BaseController{ @Autowired private UserService userService; @Autowired private RedisTemplate redisTemplate; @Autowired private SpringSsoAutoConfig ssoAutoConfig; @RequestMapping("/login") public String login(@RequestParam

单点登录 SSO 一、单点登录概述 1.什么是单点登录 2.SSO体系结构 重要构成： 2.1认证中心 2.2 用户与账号系统、用户数据获取接口 2.3 客户端模块 2.4 令牌（token） 3.SSO认证流程 重点：token存在？Token有效？用户授权？生成token 二、SSO相关核心技术 三、同域下单点登录系统分析与设计 四、同域下单点登录系统服务端实现 五、同域下单点登录系统客户端实现 六、跨域单点登录系统面临的问题与解决 来源： CSDN 作者： 心灵技艺 链接： https://blog.csdn.net/qq_43330631/article/details/101283696

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下几个： 存储信任 验证信任 只要解决了以上的问题，达到了开头讲得效果就可以说是SSO。最简单实现SSO的方法就是用Cookie，实现流程如下所示： 不然发现以上的方案是把信任存储在客户端的Cookie里，这种方法虽然实现方便但立马会让人质疑两个问题： Cookie不安全 不能跨域免登 对于第一个问题一般都是通过加密Cookie来处理，第二个问题是硬伤，其实这种方案的思路的就是要把这个信任关系存储在客户端，要实现这个也不一定只能用Cookie，用flash也能解决，flash的Shared Object API就提供了存储能力。 一般说来，大型系统会采取在服务端存储信任关系的做法，实现流程如下所示： 以上方案就是要把信任关系存储在单独的SSO系统（暂且这么称呼它）里

文章目录 问题提出 登录信息共享机制设计 简单实现 淘宝天猫登录信息共享（简化版） 登录流程 问题提出 多个系统中，如何做到其中一个系统登录了，在浏览器中打开其他系统也会成登录状态？比如在淘宝登陆了，打开天猫网页，也会显示已登录 网上有一种设计方案是通过二级域名来共享登录状态，本设计是针对不同域名下登录状态的信息共享。 登录信息共享机制设计 简单实现 实现原理： 通过在sso系统域名下存储信息，其他系统通过获取sso域下的cookie信息来获取登录信息 不过有个问题：出于安全的原因，当前域不能获取其他域的cookie信息，所以只能通过跨域访问sso系统，然后返回登录信息 在开始前我们设定两个变量： t_token 这个浏览器的一个标志， 在同一个浏览器中 ，所有相关系统内的网站共享同一个t_token access_token 用户真正的token 要实现上述功能，我们可以使用跨域机制来实现共享token。这里我们设置三个系统，两个客户端系统，一个sso系统。如图： 流程如下： 以上就是通过跨域来同步token的流程。 在上面的流程中，会存在一个跨域访问的问题，一般来说有两种解决方法： 使用jsonp来获取 使用CORS机制跨域获取数据 具体的可以看这两篇文章： CORS详解 跨域访问数据 淘宝天猫登录信息共享（简化版） 淘宝天猫token的获取原理是一样的，但是流程要稍复杂一些

基于CAS的单点登录SSO[1]: 搭建CAS单点登录demo 作者：家辉，日期：2017-08-08 CSDN博客： http://blog.csdn.net/gobitan 摘要： 经过对大量第三方单点登录系统的调研，发现Apereo的CAS是做得最好的，因此，本系列文章将分析CAS。由于CAS涉及的东西较多，直接从CAS源码编译较为复杂。CAS提供了现成的部署包模板，本文以此为例快速搭建初步的CAS demo，环境适用于Mac OS或者Linux环境。 第一步：获取CAS部署包模板CAS Overlay Template git clone https://github.com/apereo/cas-overlay-template 备注：由于官方代码在持续更新，这里我将这个版本的代码在CSDN存了一份。链接为： http://download.csdn.net/download/gobitan/9947498 在获取下来的cas-overlay-template包中，查看README.md可以找到部署方法。 CAS的版本为5.1.x，要求JDK1.8+。 注意：由于maven官方库 https://mvnrepository.com/artifact/org.apereo.cas/cas-server-support-jdbc-drivers 中没有5.1.3版本