单点登陆（SSO）详解

背景

在企业发展初期，企业使用的系统不多，一般一个或者两个，每一个系统都有本身的登陆模块，运营人员天天用本身的帐号登陆，很方便。
但随着企业的发展，用到的系统随之增多，运营人员在操做不一样的系统时，须要屡次登陆，并且每一个系统的帐号都不同，这对于运营人员
来讲，很不方便。因而，就想到是否是能够在一个系统登陆，其余系统就不用登陆了呢？这就是单点登陆要解决的问题。

单点登陆英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只须要登陆一次，就能够访问其余相互信任的应用系统。

如图所示，图中有4个系统，分别是Application一、Application二、Application三、和SSO。Application一、Application二、Application3没有登陆模块，而SSO只有登陆模块，没有其余的业务模块，当Application一、Application二、Application3须要登陆时，将跳到SSO系统，SSO系统完成登陆，其余的应用系统也就随之登陆了。这彻底符合咱们对单点登陆（SSO）的定义。

技术实现

在说单点登陆（SSO）的技术实现以前，咱们先说一说普通的登陆认证机制。

如上图所示，咱们在浏览器（Browser）中访问一个应用，这个应用须要登陆，咱们填写完用户名和密码后，完成登陆认证。这时，咱们在这个用户的session中标记登陆状态为yes（已登陆），同时在浏览器（Browser）中写入Cookie，这个Cookie是这个用户的惟一标识。下次咱们再访问这个应用的时候，请求中会带上这个Cookie，服务端会根据这个Cookie找到对应的session，经过session来判断这个用户是否登陆。若是不作特殊配置，这个Cookie的名字叫作jsessionid，值在服务端（server）是惟一的。

同域下的单点登陆

一个企业通常状况下只有一个域名，经过二级域名区分不一样的系统。好比咱们有个域名叫作：a.com，同时有两个业务系统分别为：app1.a.com和app2.a.com。咱们要作单点登陆（SSO），须要一个登陆系统，叫作：sso.a.com。

咱们只要在sso.a.com登陆，app1.a.com和app2.a.com就也登陆了。经过上面的登录认证机制，咱们能够知道，在sso.a.com中登陆了，实际上是在sso.a.com的服务端的session中记录了登陆状态，同时在浏览器端（Browser）的sso.a.com下写入了Cookie。那么咱们怎么才能让app1.a.com和app2.a.com登陆呢？这里有两个问题：

• Cookie是不能跨域的，咱们Cookie的domain属性是sso.a.com，在给app1.a.com和app2.a.com发送请求是带不上的。
• sso、app1和app2是不一样的应用，它们的session存在本身的应用内，是不共享的。

那么咱们如何解决这两个问题呢？针对第一个问题，sso登陆之后，能够将Cookie的域设置为顶域，即.a.com，这样全部子域的系统均可以访问到顶域的Cookie。咱们在设置Cookie时，只能设置顶域和本身的域，不能设置其余的域。好比：咱们不能在本身的系统中给baidu.com的域设置Cookie。

Cookie的问题解决了，咱们再来看看session的问题。咱们在sso系统登陆了，这时再访问app1，Cookie也带到了app1的服务端（Server），app1的服务端怎么找到这个Cookie对应的Session呢？这里就要把3个系统的Session共享，如图所示。共享Session的解决方案有不少，例如：Spring-Session。这样第2个问题也解决了。

同域下的单点登陆就实现了，但这还不是真正的单点登陆。

不一样域下的单点登陆

同域下的单点登陆是巧用了Cookie顶域的特性。若是是不一样域呢？不一样域之间Cookie是不共享的，怎么办？

这里咱们就要说一说CAS流程了，这个流程是单点登陆的标准流程。

上图是CAS官网上的标准流程，具体流程以下：

1. 用户访问app系统，app系统是须要登陆的，但用户如今没有登陆。
2. 跳转到CAS server，即SSO登陆系统，之后图中的CAS Server咱们统一叫作SSO系统。 SSO系统也没有登陆，弹出用户登陆页。
3. 用户填写用户名、密码，SSO系统进行认证后，将登陆状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。
4. SSO系统登陆完成后会生成一个ST（Service Ticket），而后跳转到app系统，同时将ST做为参数传递给app系统。
5. app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。
6. 验证经过后，app系统将登陆状态写入session并设置app域下的Cookie。

至此，跨域单点登陆就完成了。之后咱们再访问app系统时，app就是登陆的。接下来，咱们再看看访问app2系统时的流程。

1. 用户访问app2系统，app2系统没有登陆，跳转到SSO。
2. 因为SSO已经登陆了，不须要从新登陆认证。
3. SSO生成ST，浏览器跳转到app2系统，并将ST做为参数传递给app2。
4. app2拿到ST，后台访问SSO，验证ST是否有效。
5. 验证成功后，app2将登陆状态写入session，并在app2域下写入Cookie。

这样，app2系统不须要走登陆流程，就已是登陆了。SSO，app和app2在不一样的域，它们之间的session不共享也是没问题的。

有的同窗问我，SSO系统登陆后，跳回原业务系统时，带了个参数ST，业务系统还要拿ST再次访问SSO进行验证，以为这个步骤有点多余。他想SSO登陆认证经过后，经过回调地址将用户信息返回给原业务系统，原业务系统直接设置登陆状态，这样流程简单，也完成了登陆，不是很好吗？

其实这样问题时很严重的，若是我在SSO没有登陆，而是直接在浏览器中敲入回调的地址，并带上伪造的用户信息，是否是业务系统也认为登陆了呢？这是很可怕的。

总结

单点登陆（SSO）的全部流程都介绍完了，原理你们都清楚了。总结一下单点登陆要作的事情：

• 单点登陆（SSO系统）是保障各业务系统的用户资源的安全 。
• 各个业务系统得到的信息是，这个用户能不能访问个人资源。
• 单点登陆，资源都在各个业务系统这边，不在SSO那一方。 用户在给SSO服务器提供了用户名密码后，做为业务系统并不知道这件事。 SSO随便给业务系统一个ST，那么业务系统是不能肯定这个ST是用户伪造的，仍是真的有效，因此要拿着这个ST去SSO服务器再问一下，这个用户给个人ST是否有效，是有效的我才能让这个用户访问。