单点登录

优点： 提高用户的效率 用户不再被多次登录困扰，也不需要记住多个 ID 和 密码。 提高开发人员的效率 SSO 为开发人员提供了一个通用的身份验证框架。 实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。 简化管理 如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。 缺点： CPU开销较大 在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。 安全隐患 因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。 不利于重构 因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时 来源： CSDN 作者： 进击的小名 链接： https://blog.csdn.net/Tianc666/article/details/104416071

简介 单点登录是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的保护资源，若用户在某个应用系统中进行注销登录，所有的应用系统都不能再直接访问保护资源，像一些知名的大型网站，如：淘宝与天猫、新浪微博与新浪博客等都用到了这个技术。 原理 单点登录 有一个独立的认证中心，只有认证中心才能接受用户的用户名和密码等信息进行认证，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，当用户提供的用户名和密码通过认证中心认证后，认证中心会创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌即得到了授权，然后创建局部会话。 示例： 下面对上图进行解释： 当用户还没进行用户登录的时候 用户去访问系统1的保护资源 ，系统1检测到用户还没登录，跳转至SSO认证中心，SSO认证中心也发现用户没有登录，就跳转到用户至认证中心的登录页面 用户在登录页面提交用户相应信息后，认证中心会校验用户信息，如果用户信息正确的话认证中心就会创建与该用户的全局会话（全局会话过期的时候，用户就需要重新登录了。全局会话中存的信息可能有令牌，用户信息，及该在各个系统的一些情况），同时创建授权令牌，然后进行下一步，否则认证中心给出提示（用户信息有误），待用户再次点击登录的时候，再一次进行校验用户信息 认证中心带着令牌跳转到用户最初请求的地址（系统1）

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

轻量级单点登录系统解决方案包括以下项目： l 公共组件 SSOLab.SSOServer.Components l 单点登录系统 SSOLab.SSOServer.WebApp l 企业门户系统系统演示 SSOLab.Portal.WebApp l 人力资源管理系统演示 SSOLab. APP1. WebApp l 财务管理系统演示 SSOLab. APP2. WebApp l 网上办公系统演示 App3 （ Java ） Visual Studio 2008解决方案图 Eclipse项目图 整个解决方案运行过程如下： 1、访问企业门户系统 http://localhost:7772/Portal /Default.aspx。 由于用户还没有在单点登录系统上登录过，所以跳转到单点登录系统用户登录页面http://localhost:7771/SSOSite/SignIn.aspx 2、输入正确的用户名和密码，跳转到企业门户系统首页面 http://localhost:7772/Portal/Default.aspx ，显示当前登陆用户的用户名和应用系统地址 3.选择人力资源管理系统，打开人力资源管理系统首页面 http://localhost:7773/App1/Default.aspx ，显示当前登陆用户的用户名。 4.选择财务管理系统，打开财务管理系统首页面 http:/

要实现企业应用集成，就不能不解决单点登录问题。单点登录（ SSO ， Single Sign On ） 也可称统一认证服务，就是用户只登录一次就可以访问多个应用系统而不需要重新登录。怎么解决单点登录问题，用任何一个搜索引擎，都可以找到各种解决方法，可谓是八仙过海、各显神通。本文的目的不是提供一个功能齐全、安全可靠的解决方法，而是提供一个只使用原始 Web 技术、与软件平台无关、与用户验证形式无关、只有用户验证功能、可以在安全性不过强求的情况下使用的方法——轻量级单点登录系统。虽然本文是使用 .NET 框架、 C# 实现的，但完全可以按照同样方法使用其它平台、其它语言来实现；虽然本文是使用用户名和密码写在代码中这种最烂的用户验证形式，但完全可以使用数据库、 Active Directory 等形式来验证用户。 很多单点登录解决方法，不论是技术、还是思想，都非常复杂，不管是商业的、有代码的，方方面面都考虑到了。想必很多程序员和我一样，学习 Web 程序开发的第一步，就是解决用户登录问题，在互联网不发达的情况下，都颇费周折，实现单点登录也和这差不多，不过绕了个圈子罢了。复杂的单点登录方法，往往都附加了很多与单点登录无关的职责，刨去这些无关的职责，就只是在一个地方进行用户登录的很小的应用系统。 轻量级单点登录系统的特性： l 轻量级； l 基于 Web-SSO 方案； l

转： 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)概述 概念：简单点说就是，用户只需要登录一次就可以访问所有相互信任的应用系统。 SSO体系结构： 1.认证中心 2.用户与账号系统、用户数据获取接口 3.客户端模块即授权验证（用户请求系统时，首先要对请求进行拦截） 4.令牌（token） 可以看作钥匙 SSO认证流程：工作原理和工作过程 1.浏览器发起访问系统的请求 2.客户端模块对用户请求进行拦截 3.验证token是否存在（不存在时重定向到登陆界面） 4.token存在时验证token是否有效（有效时可以访问系统） 5.token无效时重定向到登陆界面 6.进入登录界面，登录成功后进行授权（授权失败时提示授权失败） 7.授权成功则生成token令牌 8.生成token之后，再次返回到资源请求后重新再次进行验证 SSO相关核心技术： 1.HTTP协议的基础知识（无状态的协议） HTTP处理的一般分为三个步骤：接收请求、处理请求、返回结果。 因为HTTP是无状态的，所以无法判断第二个问题中问的是什么多少钱一支。 由于以前浏览器的请求都是用于请求的静态的资源，为了保持请求的高效，所以将HTTP设为了无状态，但随着不断的发展，HTTP无状态的已经无法处理更多的问题了，所以就需要对会话的维持： cookie：每次网络请求中，服务端返回给每个请求的唯一标识，每次发请求时会被传送【客户端】 session

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的加密算法泄露

统一用户身份管理系统的研究与实现 see also: http://www.tech-ex.com/broadcast/tvgroup/szmg/essay_003.html 刘助翔 本文作者刘助翔先生，深圳广播电影电视集团技术管理中心工程师。 关键词：用户身份　访问控制　TIM　TAM 在企业发展的过程中，一方面，随着企业信息化的推进和发展，各种应用系统之间存在着独立的用户管理系统，不仅造成系统管理的难度增大，而且由于用户信息的不同步，可能给企业管理带来不利的影响。同时，随着应用系统的增多，各系统之间的集成，单点登录的实现也越来越成为IT管理部门面临的问题；另一方面，随着部门和人员关系调整的增加，各部门和人员对应于应用系统的不同角色，拥有不同的权限，如果不能及时对各应用系统的用户信息进行调整，也必将使企业的效率受到影响。而对于用户来说，由于要面对不同的应用系统，各系统的认证信息的不同，也使得其必须掌握大量的密码和口令，容易造成泄漏。深圳广播电影电视集团(SZMG)以新的内部办公门户系统的开发为契机，采用统一的用户身份管理设计思想，对集团的组织机构、部门、用户、角色和权限等进行规范设计，构建了一个清晰、规范、安全、易管理和可扩展的统一用户身份管理系统。 统一用户身份管理概述 SZMG统一用户身份管理系统以IBM公司的TIM和TAM产品为基础，主要解决目前企业内部办公门户、邮件、考勤