单点登录原理
2024-05-19
1. 单点登录原理
单点登录原理是让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。 用户第一次访问应用系统的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket。 用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。 扩展资料 优点： 1）提高用户的效率。 用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。 2）提高开发人员的效率。 SSO 为开发人员提供了一个通用的身份验证框架。实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。 3）简化管理。 如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。
2. 单点登录的三种方式
单点登录 ：简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 简单来说 ，一个公司有多个应用，都要进行注册登录，退出的时候又要一个个退出。用户体验很不好。单点登录可以实现：登录的时候只要一次登录，退出的时候只要一次退出。
采用LocalStorage存储token, 但localStorage不支持跨域，则需要登录一个网页时，需要在本网页在localStorage时，也需要为其他的页面写入相应的token.
扩充
3. 单点登陆的单点登录应用
OpenID说到单点登录，不得不提OpenID，OpenID 是最早提出的单点登录的协议，OpenID 是一个以用户为中心的数字身份识别框架，通过 URL 来标识身份，就是你有了一个 OpenID，到所有支持 OpenID 的网站就不需要重复注册了，这样就避免老是注册的问题。使用 OpenID，你需要你到 OpenID 提供商去注册一个 URL 来标识身份，虽然我们可以通过 OpenID 的委托机制来实现把自己的博客地址作为 OpenID，但是毕竟需要注册，而且很多人对 OpenID 的概念了解不够，使用 URL 作为身份标识相对于邮箱或者账号名来说也是不那么方便，所以 OpenID 这个概念虽然很好，但是实际用途却不广。让 WordPress 实现 OpenID 支持可以通过一个名字也叫做 OpenID 的插件实现，OpenID 和其 WordPress 插件 这篇文章有对 OpenID 和其 WordPress 插件有详细的介绍。但是随着很多大服务厂商对 OpenID 的支持，如 Google 账号支持 OpenID，并且 Yahoo，AOL，Facebook，微软Live 等等大型公司对 OpenID 的支持，使得 OpenID 开始流行，但是 OpenID 已经不仅仅是一个 URL，而是已经包括了邮箱地址。所以有服务把这些提供 OpenID 的厂家整合起来提供服务，如click pass就是其中的一家，它能够让你使用 Hotmail, Yahoo, Google, Facebook, AIM 账号实现单点登录。Friend Connect不过目前整合单点登录做的最好的还是 Google 的 Friend Connect，Google Friend Connect除了实现单点登陆（支持 OpenID, Gmail, Yahoo, AIM 账号）之外，还因支持 OpenSocial 而有更多社交属性，并且 Friend Connect 因开放 API，所以可以很容易把 Google Friend Conect 集成到别的系统中，作为登陆系统，如 Google Friend Connect 的 WordPress 插件。Facebook Connect最早提出 Connect 想法的是 Facebook， Facebook 通过 Facebook Connect 把开放从 Facebook 站内开放到站外，允许用户从外部网站访问 Facebook 数据，如用户在 Facebook 的身份、好友列表及隐私设定等，这使得普通网站也可以具有社交功能，这样同样使得 Facebook 应用更加广泛，而 Facebook Connect 的 WordPress 插件使得可以使用 Facebook 账号登陆你的博客，并且可以邀请朋友加入博客，并且同时同步留言到 Facebook，相比 Google Friend Connect 更有交互性，因为 Google Friend Connect 暂时还没有一个中心，但是Facebook 在国内的用户不是很多，访问也是相对较慢，所以我没有在博客上使用。
4. 浅谈单点登录
心血来潮，探讨一下cookie和session机制，以及单点登录的原理。不到之处欢迎指正。
要谈单点登录，还要从cookie机制说起。这块知识也是面试中的高频题，小马以前如有辅助也会喜欢聊。只是大部分同学不是概念模糊就是完全抛弃了这块知识点，经常被秒。
cookie机制是一种会话机制，源于HTTP协议是无状态的。当浏览器发起的http请求要和服务端保持会话状态的时候，需要借助中间介质，而cookie机制刚好合适。
我们来举个栗子，假设我现在访问王者农药官网。
1.打开浏览器输入xxx域名；
2.浏览器会在硬盘中查找关于xxx 的Cookie，一般登录态标识存储的是session_id，然后把Cookie 放到 HTTP Request 中，再把Request 发送给 Web 服务器；
3.服务端识别到cookie，会在服务端查询对应session_id的用户会话记录并校验，如果存在并且有效，则进行本次登录态数据操作（比如写基本的登录态session数据），处理用户为正常登录状态，此时浏览器看到的就是已登录的状态。如果没有相关信息，则用户处于未登录状态。
4.如果未登录，用户会在浏览器操作登录。登录成功后往浏览器写cookie（session_id），同时服务端会有相应的session_id会话记录（默认是文件存储）。当浏览器关闭或者用户操作注销（服务端删除登陆态session），则本次会话结束，本次会话信息（session_id）失效。当然，这也有例外，那就是如果设置了cookie的有效期，那么该会话消息将会保存到到期为止，客户端的cookie和服务端的session会话信息都会保持有效期 。想想我们平时登录时看到的“自动登录”勾选，下次访问就可以直接就是已登录状态，就是这个原理。
好了，以上就是cookie和session的会话机制了。
从上面可以看到cookie大致可分为两大类：会话Cookie和持久Cookie。
会话Cookie是一种临时的Cookie，它记录了用户访问站点，它记录了用户访问站点时的设置和偏好；关闭浏览器，会话Cookie 就被删除了。
持久 Cookie 存储在硬盘上，不管浏览器退出或计算机重启，持久Cookie 都继续存在。持久Cookie 有过期时间。
他们的共同点是，都是存储在客户端（浏览器）的，是存在硬盘上的，不同浏览器，不同操作系统存储 Cookie 的地方可能不一样。那么自然的session就是存储在服务端的（注意，敲黑板必考题）。session有哪几种存储方式呢？浏览器禁用cookie后session还能用吗？
session默认是存文件，当然也可以配置为DB存储或者cache存储，比如redis。浏览器禁用cookie后session还能用吗？能，将session_id放在url参数中，服务端也能识别session会话信息，但处理起来就不是那么优雅，说白了，cookie只是一种比较合适的客户端存储媒介。对于一些禁用了浏览器cookie的用户可以这样兼容，但少见，基本无视。
于是我们聊到正题，单点登录是什么？
单点登录（Single Sign On），简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个 应用 系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
先丢一个问题出来助助兴。假如我现在服务端是个集群，怎么处理登录态问题呢？比如我还是农药官网，我登录成功了网站xxx，但是第二次访问的时候又告诉我已经登录了，再刷一下，又显示已登录，这是什么鬼呢？原因是假如xxx域名下的服务端是分布式集群，并且同时又采用了默认的文件存储方式存储session会话信息。于是第一次处理请求的是机器A存储了文件会话信息，当第二次会话带着cookie去服务端，这时正好处理请求的是机器B，于是寻找不到会话信息文件，自然浏览器就认为未登录。
以上问题可以通过服务端共享登录态信息实现，修改session存储方式为DB或者redis等cache，来达到多机器共享，单域名下的分布式集群登录态共享即可解决。
如果是同一个域名下的几个server，把cookie的路径设置成顶级域名下（比如域名xxx下面有a.xxx，b.xxx子域名），这样所有子域都能读取cookie中的token(或者是session-id)即可。但这里有个问题，如果是跨域，那取不到cookie，要怎么办呢？
因为cookie没有跨域性质，如果不同域名xxx和ccc要共享登录态无法通过共享同一个cookie来解决。于是就有了令牌的机制，统一用一个令牌凭证来在各个系统之间保持登录态。
采用令牌验证机制
要实现SSO，需要以下主要的功能（本段描述参考自百科）：
所有应用系统共享一个身份认证系统。统一的认证系统是SSO的前提之一 。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。
所有应用系统能够识别和提取ticket信息。要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。
小马认为有点类似微信接口调用的access_token机制。
5. 单点登录的介绍
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
6. 不同系统之间如何实现单点登录？单点登录如何实现？
在“互联网+”时代，伴随着公司的业务发展和人员的增加以及“企业上云”的倡导下，企业会采购各种SaaS系统、OA、CRM、ERP、HR系统、财务系统等等以满足公司的高速发展；但时间久了，IT运维却开始吐槽“采购一时爽，维护方恨晚”。单一的系统对单一的业务或者需求确实起到了关键的作用。但是每个系统所需要的账号密码不统一性、人员入离职的变动需要开关权限、老旧业务系统无统一接口等问题让公司在享受着企业上云便捷的同时也带来了各自问题。 如何解决？单点登录SSO的概念应用而生，什么是单点登录？单点登录SSO说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。 那多系统环境指的是哪些？其实就是我们日常提到的SaaS、ERP、OA等各种软件，通过单点登录实现统一认证，一次登录就可全部查看操作，省去了一个个系统登录的繁杂，同时也给IT运维人员提高了工作效率，节约人力成本。 目前市场上主流的做单点登录的公司比如玉符科技，深耕单点登录SSO领域，可以满足客户遇到的如何实现单点登录？企业如何实现统一认证？的难题，通过玉符单点登录可以快速的帮助企业实现云认证，像SAML、OIDC、CAS、Ouath等主流协议全部支持，可以实现快速部署，交付周期短，适合各行业企业。
7. 单点登录能够实现多系统登录?
可以实现，玉符科技的单点登录系统完全可以实现，通过玉符科技单点登录SSO实现统一认证，一次登录就可全部查看操作，省去了一个个系统登录的繁杂，同时也给IT运维人员提高了工作效率，节约人力成本。
8. 两个系统之间怎么实现单点登录?
主要实现方式有： 1、 共享 cookies 基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然 cookies本身不跨域，但可以利用它实现跨域的 SSO 。如：代理、暴露 SSO 令牌值等。 缺点：不灵活而且有不少安全隐患，已经被抛弃。 2、 Broker-based( 基于经纪人 ) 这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （凭证库思想 ) 等。 Kerberos是由麻省理工大学发明的安全认证服务，已经被 UNIX 和 Windows 作为默认的安全认证服务集成进操作系统。 3、 Agent-based （基于代理人） 在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个 " 翻译 "。例如 SSH 等。 4、 Token-based 例如 SecureID,WebID ，现在被广泛使用的口令认证，比如 FTP 、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。 5、 基于网关 6、 基于 SAML SAML(Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO ，并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现了 SAML 规范。
最新文章
热门文章
推荐阅读