单点登陆（SSO）工做原理

单点登陆（SSO）工做原理

1、单点登陆的介绍

单点登陆（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只须要登陆一次就能够访问全部相互信任的应用系统。

例如：百度旗下有不少的产品，好比百度贴吧、百度知道、百度文库等，只要登陆百度帐号，在任何一个地方都是已登陆状态，不须要从新登陆。

当用户第一次访问应用系统的时候，由于尚未登陆，会被引导到认证系统中进行登陆；根据用户提供的登陆信息，认证系统进行身份校验，若是经过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，做为本身认证的凭据，应用系统接受到请求以后会把ticket送到认证系统进行校验，检查ticket的合法性。若是经过校验，用户就能够在不用再次登陆的状况下访问应用系统2和应用系统3了。

 

 

 

要实现SSO，须要如下主要的功能：

全部应用系统共享一个身份认证系统。
统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登陆信息和用户信息库相比较，对用户进行登陆认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。
全部应用系统可以识别和提取ticket信息
要实现SSO的功能，让用户只登陆一次，就必须让应用系统可以识别已经登陆过的用户。应用系统应该能对ticket进行识别和提取，经过与认证系统的通信，能自动判断当前用户是否登陆过，从而完成单点登陆的功能。

2、单点登陆技术实现机制

在说单点登陆（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登陆呢？

这里有两个问题：

1，Cookie是不能跨域的，咱们Cookie的domain属性是sso.a.com，在给app1.a.com和app2.a.com发送请求是带不上的。
2，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流程了，这个流程是单点登陆的标准流程。

下面的是这篇文章的重点！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

下面的是这篇文章的重点！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

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是否有效，是有效的我才能让这个用户访问。

3、单点登陆优缺点

优势

1）提升用户的效率。

用户再也不被屡次登陆困扰，也不须要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的状况也会减小。

2）提升开发人员的效率。

SSO 为开发人员提供了一个通用的身份验证框架。实际上，若是 SSO 机制是独立的，那么开发人员就彻底不须要为身份验证操心。他们能够假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。

3）简化管理。

若是应用程序加入了单点登陆协议，管理用户账号的负担就会减轻。简化的程度取决于应用程序，由于 SSO 只处理身份验证。因此，应用程序可能仍然须要设置用户的属性（好比访问特权）。

缺点

1）不利于重构

由于涉及到的系统不少，要重构必需要兼容全部的系统，可能很耗时。

2） 无人看守桌面

由于只须要登陆一次，全部的受权的应用系统均可以访问，可能致使一些很重要的信息泄露。

 

 

原文地址：

https://www.toutiao.com/a6750917667814638091/?timestamp=1572360757&app=news_article_lite&group_id=6750917667814638091&req_id=201910292252360100140481410062922F