IT之道-艾锑知道

您当前位置: 主页 > IT服务 > 服务器服务 >

单点登陆原理及实现


2020-02-06 16:09 作者:admin 浏览量:
 
        这次的肺炎疫情对中国的中小企业将会是沉重的打击,据钉钉和微信两个办公平台数据统计现有2亿左右的人在家远程办公,那么对于中小企业的员工来说不懂IT技术将会让他们面临的最大挑战和困难。
 
        电脑不亮了怎么办?系统蓝屏如何处理?办公室的电脑在家如何连接?网络应该如何设置?VPN如何搭建?数据如何对接?服务器如何登录?数据安全如何保证?数据如何存储?视频会议如何搭建?业务系统如何开启等等一系列的问题,都会困扰着并非技术出身的您

 
 
        好消息是当您看到这篇文章的时候,就不用再为上述的问题而苦恼,您只需拨打艾锑无限的全国免费热线电话:400 650 7820,就会有我们的远程工程师为您解决遇到的问题,他们可以远程帮您处理遇到的一些IT技术难题。
 
       如遇到免费热线占线,您还可以拨打我们的24小时值班经理电话:15601064618或技术经理的电话:13041036957,我们会在第一时间接听您的来电,为您提供适合的解决方案,让您无论在家还是在企业都能无忧办公。
 
那艾锑无限具体能为您的企业提供哪些服务呢?
       艾锑无限始创于2005年,历经15年服务了5000多家中小企业并保障了几十万台设备的正常运转,积累了丰富的企业IT紧急问题和特殊故障的解决经验,制定了相对应的解决方案。我们为您的企业提供的IT服务分为三大版块:
 
        第一版块是保障性IT外包服务:如电脑设备运维,办公设备运维,网络设备运维,服务器运维等综合性企业IT设备运维服务。
 
        第二版块是功能性互联网外包服务:如网站开发外包,小程序开发外包,APP开发外包,电商平台开发外包,业务系统的开发外包和后期的运维外包服务。
 
        第三版块是增值性云服务外包:如企业邮箱上云,企业网站上云,企业存储上云,企业APP小程序上云,企业业务系统上云,阿里云产品等后续的云运维外包服务。
 
        您要了解更多服务也可以登录艾锑无限的官网:www.bjitwx.com查看详细说明,在疫情期间,您企业遇到的任何困境只要找到艾锑无限,能免费为您提供服务的我们绝不收一分钱,我们全体艾锑人承诺此活动直到中国疫情结束,我们将这次活动称为——春雷行动。
 
       以下还有我们为您提供的一些技术资讯,以便可以帮助您更好的了解相关的IT知识,帮您渡过疫情中办公遇到的困难和挑战,艾锑无限愿和中国中小企业一起共进退,因为我们相信万物同体,能量合一,只要我们一起齐心协力,一定会成功。再一次祝福您和您的企业,战胜疫情,您和您的企业一定行。
北京艾锑无限告诉您:单点登陆原理及实现
 
单点登录(Single Sign On),简称为 SSO,是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

很早期的公司,一家公司可能只有一个Server,慢慢的Server开始变多了。每个Server都要进行注册登录,退出的时候又要一个个退出。用户体验很不好!你可以想象一下,上豆瓣 要登录豆瓣FM、豆瓣读书、豆瓣电影、豆瓣日记......真的会让人崩溃的。我们想要另一种登录体验:一家企业下的服务只要一次注册,登录的时候只要一次登录,退出的时候只要一次退出。怎么做?

一次注册。 一次注册不难,想一下是不是只要Server之间同步用户信息就行了?可以,但这样描述不太完整,后续讲用户注册的时候详细说。实际上用户信息的管理才是SSO真正的难点,只是作为初学者,我们的难点在于实现SSO的技术!我们先讨论实现手段。

一次登录与一次退出。 回头看看普通商场的故事,什么东西才是保持登录状态关键的东西?记录器(session)?那种叫做cookie的纸张?写在纸张上的ID? 是session里面记录的信息跟那个ID,cookie不只是记录ID的工具而已。客户端持有ID,服务端持有session,两者一起用来保持登录状态。客户端需要用ID来作为凭证,而服务端需要用session来验证ID的有效性(ID可能过期、可能根本就是伪造的找不到对应的信息、ID下对应的客户端还没有进行登录验证等)。但是session这东西一开始是每个server自己独有的,豆瓣FM有自己的session、豆瓣读书有自己的session,而记录ID的cookie又是不能跨域的。所以,我们要实现一次登录一次退出,只需要想办法让各个server的共用一个session的信息,让客户端在各个域名下都能持有这个ID就好了。再进一步讲,只要各个server拿到同一个ID,都能有办法检验出ID的有效性、并且能得到ID对应的用户信息就行了,也就是能检验ID

 

最简单的单点登录实现方式,是使用cookie作为媒介,存放用户凭证。

用户登录父应用之后,应用返回一个加密的cookie,当用户访问子应用的时候,携带上这个cookie,授权应用解密cookie并进行校验,校验通过则登录当前用户。

不难发现以上方式把信任存储在客户端的Cookie中,这种方式很容易令人质疑:

Cookie不安全

不能跨域实现免登

对于第一个问题,通过加密Cookie可以保证安全性,当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露,攻击者通过伪造Cookie则可以伪造特定用户身份,这是很危险的。

对于第二个问题,更是硬伤。

对于跨域问题,可以使用JSONP实现。 

用户在父应用中登录后,跟Session匹配的Cookie会存到客户端中,当用户需要登录子应用的时候,授权应用访问父应用提供的JSONP接口,并在请求中带上父应用域名下的Cookie,父应用接收到请求,验证用户的登录状态,返回加密的信息,子应用通过解析返回来的加密信息来验证用户,如果通过验证则登录用户。

 
这种方式虽然能解决跨域问题,但是安全性其实跟把信任存储到Cookie是差不多的。如果一旦加密算法泄露了,攻击者可以在本地建立一个实现了登录接口的假冒父应用,通过绑定Host来把子应用发起的请求指向本地的假冒父应用,并作出回应。 

因为攻击者完全可以按照加密算法来伪造响应请求,子应用接收到这个响应之后一样可以通过验证,并且登录特定用户。

最后一种介绍的方式,是通过父应用和子应用来回重定向中进行通信,实现信息的安全传递。 

父应用提供一个GET方式的登录接口,用户通过子应用重定向连接的方式访问这个接口,如果用户还没有登录,则返回一个的登录页面,用户输入账号密码进行登录。如果用户已经登录了,则生成加密的Token,并且重定向到子应用提供的验证Token的接口,通过解密和校验之后,子应用登录当前用户。
这种方式较前面两种方式,接解决了上面两种方法暴露出来的安全性问题和跨域的问题,但是并没有前面两种方式方便。 

安全与方便,本来就是一对矛盾。

使用独立登录系统 

一般说来,大型应用会把授权的逻辑与用户信息的相关逻辑独立成一个应用,称为用户中心。 

用户中心不处理业务逻辑,只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候,则把用户的登录请求转发给用户中心进行处理,用户处理完毕返回凭证,第三方应用验证凭证,通过后就登录用户。


相关文章

IT外包服务
二维码 关闭