单点登录 SSO（Single Sign-On）的实现原理
迁移到：http://www.bdata-cap.com/newsinfo/1741388.html
为什么要 SSO？
企业的信息化过程是一个循序渐进的过程，这就造成在企业的不同时期，根据业务和发展需要，构建了多个应用程序，而这些应用程序在功能、设计和技术可能都有所不同，就形成了各自独立的用户库和用户认证体系。于是，在访问不同的应用系统时，需要记录/输入的用户名和密码（不同时期建立的系统，用户名和密码的规则可能还不一样；要是忘了，还得让人重置；如果人员发生变动，那所有的系统都要改）。这太麻烦了。
如果引入单一用户登录的解决方案，建立一套统一的、完善的、科学的单点登录系统，每个用户只需记录一个用户名和密码，登录一个平台后即可实现各应用系统的透明跳转，而且实行统一的用户信息管理系统（系统管理员可以通过平台接口同步更新至各个应用系统，实现单次维护全公司同步变更），就可以大幅度提高工作效率。
单点登录在现在的软件系统已经很常见，比如，阿里集团，有很多应用系统，有淘宝、有天猫、有支付宝、有阿里旺旺，只要登录一次，其他的所有系统都可以使用，再比如，像有道云笔记、Evernote，它们有网页版，还有客户端，只要登录一个，另一个就能自动登录~
什么是 SSO?
单点登录，Single Sign-On，简写为 SSO，是一个用户认证的过程，允许用户一次性进行认证后，就可访问系统中不同的应用；而无需要访问每个应用时，都重新输入用户和密码。IBM 对 SSO 有一个形象的解释“单点登录、全网漫游”。
SSO 的好处？
SSO 将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO 的好处显而易见：
-
减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性
-
实现安全的同时避免了处理和保存多套系统用户的认证信息
-
减少了系统管理员增加、删除用户和修改用户权限的时间
-
增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限
对于内部有多种应用系统的企业来说，单点登录的效果是十分明显的。很多国际上的企业已经将单点登录作为系统设计的基本功能之一。
解决方案
单点登录，简单说，在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是，在一个系统登录一次，其他所有系统都信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，用户不仅会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下几个：
- 存储信任
- 验证信任
只要解决了以上的问题，达到了开头讲得效果就可以说是 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的验证就可以辨别信息是否被改过。
对最后一个问题，可以通过白名单来处理，说简单点只有在白名单上的系统才能请求生产信任关系，同理只有在白名单上的系统才能被免登录。
