其他分享
首页 > 其他分享> > 单点登录

单点登录

作者:互联网

一、什么是单点登录

单点登录的英文名叫做:Single Sign On(简称SSO),指在同一帐号平台下的多个应用系统中,用户只需登录一次,即可访问所有相互信任的系统。简而言之,多个系统,统一登陆。

为什么需要做单点登录系统呢?在一些互联网公司中,公司旗下可能会有多个子系统,每个登陆实现统一管理,多个账户信息统一管理 SSO单点登陆认证授权系统。比如阿里系的淘宝和天猫,显而易见这是两个系统,但是在使用过程中,只要你登录了淘宝,同时也意味着登录了天猫,如果每个子系统都需要登录认证,用户早就疯了,所以我们要解决的问题就是,用户只需要登录一次就可以访问所有相互信任的应用系统。
二、单点登录原理

sso需要一个独立的认证中心,所有子系统都通过认证中心的登录入口进行登录,登录时带上自己的地址,子系统只接受认证中心的授权,授权通过令牌(token)实现,sso认证中心验证用户的用户名密码正确,创建全局会话和token,token作为参数发送给各个子系统,子系统拿到token,即得到了授权,可以借此创建局部会话,局部会话登录方式与单系统的登录方式相同。

 

 三、单点登录实现方式

单点登录的实现方案,一般就包含:Cookies,Session同步,分布式Session,目前的大型网站都是采用分布式Session的方式。
1.基于Cookie+Redis的单点登录

最简单的单点登录实现方式,用cookie作为媒介存放用户凭证。 用户登录系统之后,会返回一个加密的cookie,当用户访问子应用的时候会带上这个cookie,授权以解密cookie并进行校验,校验通过后即可登录当前用户。

redis:在key:生成唯一随机值(ip、用户id等等),在value:用户数据

cookie:把redis里面生成key值放到cookie里面

 

 下面对上图简要描述

    用户访问系统1的受保护资源,系统1发现用户未登录,跳转至sso认证中心,并将自己的地址作为参数
    sso认证中心发现用户未登录,将用户引导至登录页面
    用户输入用户名密码提交登录申请
    sso认证中心校验用户信息,创建用户与sso认证中心之间的会话,称为全局会话,同时创建授权令牌
    sso认证中心带着令牌跳转会最初的请求地址(系统1)
    系统1拿到令牌,去sso认证中心校验令牌是否有效
    sso认证中心校验令牌,返回有效,注册系统1
    系统1使用该令牌创建与用户的会话,称为局部会话,返回受保护资源
    用户访问系统2的受保护资源
    系统2发现用户未登录,跳转至sso认证中心,并将自己的地址作为参数
    sso认证中心发现用户已登录,跳转回系统2的地址,并附上令牌
    系统2拿到令牌,去sso认证中心校验令牌是否有效
    sso认证中心校验令牌,返回有效,注册系统2
    系统2使用该令牌创建与用户的局部会话,返回受保护资源

  用户登录成功之后,会与sso认证中心及各个子系统建立会话,用户与sso认证中心建立的会话称为全局会话,用户与各个子系统建立的会话称为局部会话,局部会话建立之后,用户访问子系统受保护资源将不再通过sso认证中心,全局会话与局部会话有如下约束关系

    局部会话存在,全局会话一定存在
    全局会话存在,局部会话不一定存在
    全局会话销毁,局部会话必须销毁

Cookie的作用在于充当一个信息载体在Server端和Browser端进行信息传递,而Cookie一般是以域名为分割的,例如a.xxx.com与b.xxx.com的Cookie是不能互相访问的,但是子域名是可以访问上级域名的Cookie的。 即a.xxx.com和b.xxx.com是可以访问xxx.com下的Cookie的,于是就能将顶级域名的Cookie作为OpenId的载体。

 

 验证步骤和上第二个方法非常相似:

    在提供验证服务的站点里登录;
    将OpenId写入顶级域名Cookie里;
    访问子系统(Cookie里带有OpenId)
    子系统取出OpenId通过并向验证服务发送OpenId
    返回用户认证信息
    返回授权后的内容

但使用该方式把信任存储在客户端的Cookie中会有两个问题:

    Cookie不安全
    不能跨域实现免登

对于第一个问题,通过加密Cookie可以保证安全性,当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露,攻击者可以通过伪造Cookie伪造成特定用户身份。 对于问题二更是硬伤,所以才有了以下的分布式session方案。
2.分布式session方式实现单点登录

流程运行:

(1) 用户第一次登录时,将会话信息(用户Id和用户信息),比如以用户Id为Key,写入分布式Session;

(2) 用户再次登录时,获取分布式Session,是否有会话信息,如果没有则调到登录页;

(3) 一般采用Cache中间件实现,建议使用Redis,因此它有持久化功能,方便分布式Session宕机后,可以从持久化存储中加载会话信息;

(4) 存入会话时,可以设置会话保持的时间,比如15分钟,超过后自动超时;

结合Cache中间件,实现的分布式Session,可以很好的模拟Session会话。
3.通过页面重定向的方式

最后一种介绍的方式,是通过父应用和子应用来回重定向中进行通信,实现信息的安全传递。 父应用提供一个GET方式的登录接口,用户通过子应用重定向连接的方式访问这个接口,如果用户还没有登录,则返回一个的登录页面,用户输入账号密码进行登录。如果用户已经登录了,则生成加密的Token,并且重定向到子应用提供的验证Token的接口,通过解密和校验之后,子应用登录当前用户。

这种方式较前面两种方式,接解决了上面两种方法暴露出来的安全性问题和跨域的问题,但是并没有前面两种方式方便。 安全与方便,本来就是一对矛盾。
4.使用token实现

1.在项目某个模块进行登录,登录之后,按照规则生成字符串,把登陆之后用户包含到生成字符串里面,把字符串返回

(1)可以把字符串通过cookie返回

(2)把字符串通过地址栏返回

2.再去访问项目其他模块,每次访问在地址栏带着生成的字符串,在访问模块里面获取地址字符串,根据字符串获取用户信息。如果可以获取到就能登录。

实现方式如下图:

 

标签:单点,登录,用户,认证,会话,sso,Cookie
来源: https://www.cnblogs.com/yx520zhao/p/16279333.html