sso

一、说明 单点登录顾名思义就是在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统，免除多次登录的烦恼。本文主要介绍 同域 和 跨域 两种不同场景单点登录的实现原理，并使用 Spring Security 来实现一个最简单的 跨域 SSO客户端 。 二、原理说明 单点登录主流都是基于共享 cookie 来实现的，下面分别介绍 同域 和 跨域 下的两种场景具体怎样实现共享 cookie 的 2.1. 同域单点登录 适用场景 ：都是企业自己的系统，所有系统都使用同一个一级域名通过不同的二级域名来区分。 举个例子 ：公司有一个一级域名为 zlt.com ，我们有三个系统分别是： 门户系统(sso.zlt.com) 、 应用1(app1.zlt.com) 和 应用2(app2.zlt.com) ，需要实现系统之间的单点登录，实现架构如下： 核心原理： 门户系统 设置 Cookie 的 domain 为一级域名也就是 zlt.com ，这样就可以共享门户的 Cookie 给所有的使用该域名( xxx.zlt.com )的系统 使用 Spring Session 等技术让所有系统共享 Session 这样只要 门户系统 登录之后无论跳转 应用1 或者 应用2 ，都能通过门户 Cookie 中的 sessionId 读取到 Session 中的登录信息实现 单点登录 2.2.

一、单系统登录机制 1、http无状态协议 　　web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系 　　但这也同时意味着，任何用户都能通过浏览器访问服务器资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求，响应合法请求，忽略非法请求；要鉴别浏览器请求，必须清楚浏览器请求状态。既然http协议无状态，那就让服务器和浏览器共同维护一个状态吧！这就是会话机制 2、会话机制 　　浏览器第一次请求服务器，服务器创建一个会话，并将会话的id作为响应的一部分发送给浏览器，浏览器存储会话id，并在后续第二次和第三次请求中带上会话id，服务器取得请求中的会话id就知道是不是同一个用户了，这个过程用下图说明，后续请求与第一次请求产生了关联 　　服务器在内存中保存会话对象，浏览器怎么保存会话id呢？你可能会想到两种方式 1 2 请求参数 cookie 　　将会话id作为每一个请求的参数，服务器接收请求自然能解析参数获得会话id，并借此判断是否来自同一会话，很明显，这种方式不靠谱。那就浏览器自己来维护这个会话id吧，每次发送http请求时浏览器自动发送会话id，cookie机制正好用来做这件事

一、单系统登录机制 1、http无状态协议 web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系 但这也同时意味着，任何用户都能通过浏览器访问服务器资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求，响应合法请求，忽略非法请求；要鉴别浏览器请求，必须清楚浏览器请求状态。既然http协议无状态，那就让服务器和浏览器共同维护一个状态吧！这就是会话机制 2、会话机制 浏览器第一次请求服务器，服务器创建一个会话，并将会话的id作为响应的一部分发送给浏览器，浏览器存储会话id，并在后续第二次和第三次请求中带上会话id，服务器取得请求中的会话id就知道是不是同一个用户了，这个过程用下图说明，后续请求与第一次请求产生了关联 服务器在内存中保存会话对象，浏览器怎么保存会话id呢？你可能会想到两种方式： 请求参数 cookie 将会话id作为每一个请求的参数，服务器接收请求自然能解析参数获得会话id，并借此判断是否来自同一会话，很明显，这种方式不靠谱。那就浏览器自己来维护这个会话id吧，每次发送http请求时浏览器自动发送会话id，cookie机制正好用来做这件事

登录 1. 打开 A 网站进行登录； 2. 检测 Login 服务器是否可用； 3. 如果 Login 服务器可用，检测发现 Login 服务器 Session 未创建； 4. 重定向到 A 网站的页面，接受 Login 服务器传来的 Key 和 UID 组成的类序列化后的数据； 5. 得到的 Key 是 1 ，说明 Login 服务器 Session 未创建，在 A 网站创建 Session ，登录完成后使用 <script> 访问 Login 服务器上的页面创建 Session 并记录网站名和网站登出页面地址； 6. 打开 B 网站登录，发现没有登录，检测 Login 服务器是否可用； 7. 如果 Login 服务器可用，检测发现 Login 服务器 Session 已经创建并记录网站名和网站登出页面地址； 8. 重定向到 B 网站的页面，接受 Login 服务器传来的 Key 和 UID 组成的类序列化后的数据； 9. 得到的 Key 不是 1 ，说明 Login 服务器 Session 已经创建，根据 Key 到数据库进行验证，验证通过后在 B 网站创建 Session 。 登出 1. 每个网站都有登出按钮，点击按钮后先清空本地 Session ； 2. 然后检测 Login 服务器是否可用； 3. 可用的话跳转到 Login 服务器的登出页面； 4. 根据 Session

1 什么是单点登陆 单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和IT服务。例如财务系统为财务人员提供财务的管理、计算和报表服务；人事系统为人事部门提供全公司人员的维护服务；各种业务系统为公司内部不同的业务提供不同的服务等等。这些系统的目的都是让计算机来进行复杂繁琐的计算工作，来替代人力的手工劳动，提高工作效率和质量。这些不同的系统往往是在不同的时期建设起来的，运行在不同的平台上；也许是由不同厂商开发，使用了各种不同的技术和标准。如果举例说国内一著名的IT公司（名字隐去），内部共有60多个业务系统，这些系统包括两个不同版本的SAP的ERP系统，12个不同类型和版本的数据库系统，8个不同类型和版本的操作系统，以及使用了3种不同的防火墙技术，还有数十种互相不能兼容的协议和标准，你相信吗？不要怀疑，这种情况其实非常普遍。每一个应用系统在运行了数年以后，都会成为不可替换的企业IT架构的一部分，如下图所示。 随着企业的发展，业务系统的数量在不断的增加，老的系统却不能轻易的替换，这会带来很多的开销。其一是管理上的开销，需要维护的系统越来越多。很多系统的数据是相互冗余和重复的

转： https://www.cnblogs.com/ywlaker/p/6113927.html 单系统登录机制 1、http无状态协议 　　 web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系 　　但这也同时意味着，任何用户都能通过浏览器访问服务器资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求，响应合法请求，忽略非法请求；要鉴别浏览器请求，必须清楚浏览器请求状态。既然 http协议无状态，那就让服务器和浏览器共同维护一个状态吧！这就是会话机制 2、会话机制 　　浏览器第一次请求服务器，服务器创建一个会话，并将会话的 id作为响应的一部分发送给浏览器，浏览器存储会话id，并在后续第二次和第三次请求中带上会话id，服务器取得请求中的会话id就知道是不是同一个用户了，这个过程用下图说明，后续请求与第一次请求产生了关联 　　服务器在内存中保存会话对象，浏览器怎么保存会话 id呢？你可能会想到两种方式 请求参数 cookie 　　将会话 id作为每一个请求的参数，服务器接收请求自然能解析参数获得会话id，并借此判断是否来自同一会话，很明显，这种方式不靠谱

SSO，Single Sign On，也就是单点登录，保证一个账户在多个系统上实现单一用户的登录 现在随着网站的壮大，很多服务会进行拆分，会做SOA服务，会使用dubbo做微服务，或者简单的小型分布式， 这样在服务与服务之间，或者系统与系统之间都是通过HTTP或者restful来进行通信的， 在以往的单系统应用中，我们都是把user存入session中的，需要用到的时候随时取，如果取不到就跳转到登录注册页面，非常简单的原理 但是在现如今的分布式应用中，如何保证session同步呢？ 比如订单服务是在 order.jd.com 购物车服务在 cart.jd.com 那么这2个二级域名下的用户信息如何实现同步呢？ 解决方案： 1. tomcat有一个session同步方案，就是一个传播机制，打个比方有A B C 3台tomcat，这3台tomcat的user信息都在session中并且保持一致，如果其中一台的user信息变化了，那么就会传播至另外两台，则实现同步，这样做没问题，但是仅仅只是在做tomcat集群的时候tomcat很少的时候会用，一旦集群增大，有100台，那么就互相传播吧，传播是需要性能损耗的，那么整个网站的性能就会被拉低，你的网站在你的网络风暴中就会晕死 2. nginx 非粘性session，说穿了就是一个session绑定传播

单点登录SSO实现情景分析 单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下两个： 存储信任 验证信任 如果一个系统做到了开头所讲的效果，也就算单点登录，单点登录有不同的实现方式，本文就罗列我开发中所遇见过的实现方式。 1.以COOKIE作为凭证媒介 最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。 用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。 不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑： Cookie不安全 不能跨域实现免登 对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露

1、修改项目使其基于浏览器cookie的SSO 1.1、修改回调方法，获得到token后，由存放到session改为存放到cookie /** * 回调方法 * 接收认证服务器发来的授权码，并换取令牌 * * @param code 授权码 * @param state 请求授权服务器时发送的state */ @GetMapping("/oauth/callback") public void oauthCallback(@RequestParam String code, String state, HttpServletRequest request, HttpServletResponse response) throws IOException { String oauthTokenUrl = "http://gateway.caofanqi.cn:9010/token/oauth/token"; HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED); headers.setBasicAuth("webApp", "123456"); MultiValueMap<String, String> params = new

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