单点登陆 SSO（Single Sign-On）的实现原理

时间 2019-11-06

原文原文链接

迁移到：http://www.bdata-cap.com/newsinfo/1741388.html

为何要 SSO？

企业的信息化过程是一个按部就班的过程，这就形成在企业的不一样时期，根据业务和发展须要，构建了多个应用程序，而这些应用程序在功能、设计和技术可能都有所不一样，就造成了各自独立的用户库和用户认证体系。因而，在访问不一样的应用系统时，须要记录/输入的用户名和密码（不一样时期创建的系统，用户名和密码的规则可能还不同；要是忘了，还得让人重置；若是人员发生变更，那全部的系统都要改）。这太麻烦了。html

若是引入单一用户登陆的解决方案，创建一套统一的、完善的、科学的单点登陆系统，每一个用户只需记录一个用户名和密码，登陆一个平台后便可实现各应用系统的透明跳转，并且实行统一的用户信息管理系统（系统管理员能够经过平台接口同步更新至各个应用系统，实现单次维护全公司同步变动），就能够大幅度提升工做效率。数据库

单点登陆在如今的软件系统已经很常见，好比，阿里集团，有不少应用系统，有淘宝、有天猫、有支付宝、有阿里旺旺，只要登陆一次，其余的全部系统均可以使用，再好比，像有道云笔记、Evernote，它们有网页版，还有客户端，只要登陆一个，另外一个就能自动登陆~跨域

什么是 SSO?

单点登陆，Single Sign-On，简写为 SSO，是一个用户认证的过程，容许用户一次性进行认证后，就可访问系统中不一样的应用；而无须要访问每一个应用时，都从新输入用户和密码。IBM 对 SSO 有一个形象的解释“单点登陆、全网漫游”。浏览器

SSO 的好处？

SSO 将一个企业内部全部域中的用户登陆和用户账号管理集中到一块儿，SSO 的好处显而易见：缓存

减小用户在不一样系统中登陆耗费的时间，减小用户登陆出错的可能性安全
实现安全的同时避免了处理和保存多套系统用户的认证信息服务器
减小了系统管理员增长、删除用户和修改用户权限的时间cookie
增长了安全性：系统管理员有了更好的方法管理用户，包括能够经过直接禁止和删除用户来取消该用户对全部系统资源的访问权限网络

对于内部有多种应用系统的企业来讲，单点登陆的效果是十分明显的。不少国际上的企业已经将单点登陆做为系统设计的基本功能之一。分布式

解决方案

单点登陆，简单说，在一个多系统共存的环境下，用户在一处登陆后，就不用在其余系统中登陆，也就是，在一个系统登陆一次，其余全部系统都信任。单点登陆在大型网站里使用得很是频繁，例如像阿里巴巴这样的网站，背后是成百上千的子系统，用户一次操做或交易可能涉及到几十个子系统的协做，若是每一个子系统都须要用户认证，用户不只会疯掉，各子系统也会为这种重复认证受权的逻辑搞疯。实现单点登陆说到底就是要解决如何产生和存储那个信任，再就是其余系统如何验证这个信任的有效性，所以要点也就如下几个：

存储信任
验证信任

只要解决了以上的问题，达到了开头讲得效果就能够说是 SSO。SSO 的实现机制大致分为 Cookie 机制和 Session 机制两大类。

Cookie 机制

最简单实现 SSO 的方法就是用 Cookie，实现流程以下所示：

图 1 Cookie 机制

上面方案是把信任存储在客户端的 Cookie 里，这种方法虽然实现方便但立马会让人质疑两个问题：

Cookie 不安全
不能跨域免登

对于第一个问题通常都是经过加密 Cookie 来处理；第二个问题是硬伤，其实这种方案的思路是把这个信任关系存储在客户端，要实现这个也不必定只能用 Cookie，用 flash 也能解决，flash 的 Shared Object API 就提供了存储能力。

目前好点的开源单点登陆产品 CAS（Central Authentication Service）就是采用 Cookie 机制。CAS 最先由耶鲁大学开发。2004年12月，CAS 成为 JA-SIG 中的一个项目。JA-SIG 全称是 Java Architectures Special Interest Group。CAS 的优势，如配置简单、客户端支持普遍、技术成熟等。

图 2 CAS

CAS 涉及 5 种票据： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。Ticket-granting cookie（TGC），是存放用户身份认证凭证的 cookie ，在浏览器和 CAS Server 间通信时使用，而且只能基于 Https，是 CAS Server 用来明确用户身份的凭证；Service ticket（ST），是服务票据，服务的唯一标识码 , 由 CAS Server 经过 HTTP 发出，经过客户端浏览器到达业务服务器端。一个特定的服务只能有一个唯一的 ST； Proxy-Granting ticket（PGT），是由 CAS Server 颁发给拥有 ST 凭证的服务， PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，得到 PT 的能力； Proxy-Granting Ticket I Owe You（PGTIOU），是将经过凭证校验时的应答信息由 CAS Server 返回给 CAS Client ，同时，与该 PGTIOU 对应的 PGT 将经过回调连接传给 Web 应用。Web 应用负责维护 PGTIOU 与 PGT 之间映射关系的内容表； Proxy Ticket（PT），是应用程序代理用户身份对目标程序进行访问的凭证。

CAS 验证过程：

应用程序一开始，一般进入原来的登录界面，直接转向 CAS 自带的登陆界面（固然也能够在原来登陆界面增长登陆按钮，来跳转）。若是用户但愿，也能够直接进入 CAS 的登陆界面登陆，再启动其余应用程序。不过这种方式主要用于测试环境）。
CAS 的登陆界面处理所谓的“主体认证”。它要求用户输入用户名和密码，就像普通的登陆界面同样。
主体认证时，CAS 获取用户名和密码，而后经过某种认证机制进行认证。一般认证机制是 LDAP（Lightweight Directory Access Protocol）。
为了进行之后的单点登陆，CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并非真的保存在内存中，而只是浏览器一关闭，cookie就自动过时。这个cookie称为“ticket-granting cookie”，用来代表用户已经成功地登陆。
认证成功后，CAS 服务器建立一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登陆的用户，以及服务联系在一块儿。这个ticket是一次性使用的一种凭证，它只对登陆成功的用户及其服务使用一次。使用过之后马上失效。
主体认证完成后，CAS将用户的浏览器重定向，回到原来的应用。CAS客户端，在从应用转向CAS 时，同时也会记录原始的URL，所以 CAS 知道谁在调用本身。CAS 重定向的时候，将ticket 做为一个参数传递回去。
例如，原始应用的地址是 http://www.itil.com/，转向 CAS 服务器的单点登陆页面 https://secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx；
CAS 完成主体认证后，会使用 http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20 这个 URL 进行重定向。
收到 ticket 后，应用程序须要验证 ticket。这是经过将 ticket 传递给一个校验 URL 来实现的。校验 URL 也是 CAS 服务器提供的。
CAS 经过校验路径得到了 ticket 后，经过内部的数据库对其进行判断。若是是有效性，则返回一个 NetID 给应用程序。
随后 CAS 将 ticket做废，而且在客户端留下一个 cookie。
之后，其余应用程序就使用这个 cookie 进行认证（固然经过 CAS 的客户端），而再也不须要输入用户名和密码。

这种方式，之前见的比较多，如今大都用 Session 机制，别的不说，Cookie 在客户端始终是个安全隐患，不涉及钱，还能容忍，要是涉及转帐之类的，出问题怎么算呢，不能简单一句：你电脑中毒了，被黑了，你本身的问题，这么简单吧，并且，用 CAS 时，会重定向，若是网络很差，能看到明显的延迟和卡顿~

Session 机制

通常大型系统会采起在服务端存储信任关系的作法，也就是 Session 机制实现单点登陆（毕竟像上面客户端的 Cookie 方式，安全性实在是差了点），实现流程以下所示：

图 3 Session 机制

上面方案是把信任关系存储在单独的 SSO 系统（暂且这么称呼它）里，提及来只是简单地从客户端移到了服务端，但其中几个问题须要重点解决：

如何高效存储大量临时性的信任数据
如何防止信息传递过程被篡改
如何让SSO系统信任登陆系统和免登系统

对于第一个问题，通常能够采用相似与 memcached 分布式缓存的方案，既能提供可扩展数据量的机制，也能提供高效访问。

而对第二个问题，通常采起数字签名的方法，要么经过数字证书签名，要么经过像 md5 方式，这就须要SSO系统返回免登URL的时候对需验证的参数进行md5加密，并带上 token一块儿返回，最后需免登的系统进行验证信任关系的时候，需把这个token传给SSO系统，SSO系统经过对token的验证就能够辨别信息是否被改过。

对最后一个问题，能够经过白名单来处理，说简单点只有在白名单上的系统才能请求生产信任关系，同理只有在白名单上的系统才能被免登陆。