• 设为首页
  • 点击收藏
  • 手机版
    手机扫一扫访问
    迪恩网络手机版
  • 关注官方公众号
    微信扫一扫关注
    迪恩网络公众号

earth-mist: 单点登录服务 —— 基于 Vert.x 的统一认证中心

原作者: [db:作者] 来自: 网络 收藏 邀请

开源软件名称:

earth-mist

开源软件地址:

https://gitee.com/justlive1/earth-mist

开源软件介绍:

统一认证中心

介绍

  • 基于Vert.x的统一认证中心
  • gradle

特性

  • 基于properties配置进行项目定制
  • 极简xml
  • 自动装载 依赖jar配置properties无需额外配置

原理

  • 登录信息传递

    • 用户首次登录时流程如下

      • 用户浏览器访问系统A需登录受限资源,此时进行登录检查,发现未登录,然后进行获取票据操作,发现没有票据。
      • 系统A发现该请求需要登录,将请求重定向到认证中心,获取全局票据操作,没有,进行登录。
      • 认证中心呈现登录页面,用户登录,登录成功后,认证中心重定向请求到系统A,并附上认证通过令牌,此时认证中心同时生成了全局票据。
      • 此时再次进行登录检查,发现未登录,然后再次获取票据操作,此时可以获得票据(令牌),系统A与认证中心通信,验证令牌有效,证明用户已登录。
      • 系统A将受限资源返给用户。
    • 已登录用户首次访问应用群中系统B时

      • 浏览器访问另一应用B需登录受限资源,此时进行登录检查,发现未登录,然后进行获取票据操作,发现没有票据。
      • 系统B发现该请求需要登录,将请求重定向到认证中心,获取全局票据操作,获取全局票据,可以获得,认证中心发现已经登录。
      • 认证中心发放临时票据(令牌),并携带该令牌重定向到系统B。
      • 此时再次进行登录检查,发现未登录,然后再次获取票据操作,此时可以获得票据(令牌),系统B与认证中心通信,验证令牌有效,证明用户已登录。
      • 系统B将受限资源返回给客户端。
  • 登录状态判断

    • 用户到认证中心登录后,用户和认证中心之间建立起了会话,我们把这个会话称为全局会话。当用户后续访问系统应用时,我们不可能每次应用请求都到认证中心去判定是否登录,这样效率非常低下,这也是单Web应用不需要考虑的。
    • 我们可以在系统应用和用户浏览器之间建立起局部会话,局部会话保持了客户端与该系统应用的登录状态,局部会话依附于全局会话存在,全局会话消失,局部会话必须消失。
    • 用户访问应用时,首先判断局部会话是否存在,如存在,即认为是登录状态,无需再到认证中心去判断。如不存在,就重定向到认证中心判断全局会话是否存在,如存在,按1提到的方式通知该应用,该应用与客户端就建立起它们之间局部会话,下次请求该应用,就不去认证中心验证了。
  • 登出

    • 用户在一个系统登出了,访问其它子系统,也应该是登出状态。要想做到这一点,应用除结束本地局部会话外,还应该通知认证中心该用户登出。
    • 认证中心接到登出通知,即可结束全局会话,同时需要通知所有已建立局部会话的子系统,将它们的局部会话销毁。这样,用户访问其它应用时,都显示已登出状态。
    • 整个登出流程如下
      • 客户端向应用A发送登出Logout请求。
      • 应用A取消本地会话,同时通知认证中心,用户已登出。
      • 应用A返回客户端登出请求。
      • 认证中心通知所有用户登录访问的应用,用户已登出。
  • 流程

    • 用户通过浏览器地址栏访问系统A,系统A去Cookie中拿JSESSION,即在Cookie中维护的当前会话session的id,如果拿到了,说明用户已经登录,如果未拿到,说明用户未登录
    • 假如系统A的地址为http://a:8080/,认证中心的服务地址为http://server:8080/,那么重点向前后地址变化为:http://a:8080/————>http://server:8080/?service=http://a:8080/,由此可知,重点向到认证中心,认证中心拿到了当前访问客户端的地址
    • 重定向之后的地址栏变成:http://a:8080/?ticket=ST-XXXX-XXX,将票据以ticket为参数名的方式通过地址栏发送给系统A
    • 系统A通过地址栏获取ticket的参数值ST票据,然后从后台将ST发送给认证中心验证,验证ST有效后,server返回当前用户登录的相关信息,系统A接收到返回的用户信息,并为该用户创建session会话,会话id由cookie维护,来证明其已登录
    • 在系统A登录成功后,用户和认证中心之间建立起了全局会话,这个全局会话就是TGT(Ticket Granting Ticket),TGT位于服务器端,TGT并没有放在Session中,也就是说,全局会话的实现并没有直接使用Session机制,而是利用了Cookie自己实现的,这个Cookie叫做TGC,它存放了TGT的id,保存在用户浏览器上
    • 用户发送登录系统B的请求,首先会去Cookie中拿JSESSION,因为系统B并未登录过,session会话还未创建,JSESSION的值是拿不到的,然后将请求重定向到认证中心,认证中心先去用户浏览器中拿TGC的值,也就是全局会话id,如果存在则代表用户在认证中心已经登录,附带上认证令牌重定向到系统B。
    • 认证中心清除当前用户的全局会话TGT,同时清掉cookie中TGT的id:TGC;然后是各个客户端系统,比如系统A、系统B,清除局部会话session,同时清掉cookie中session会话id:jsession

开发

mist-auth    认证相关,定义统一认证接口服务    mist-valid    校验相关,包含ticket校验等    mist-client    认证中心客户端            

部署

Release


鲜花

握手

雷人

路过

鸡蛋
该文章已有0人参与评论

请发表评论

全部评论

专题导读
热门推荐
阅读排行榜

扫描微信二维码

查看手机版网站

随时了解更新最新资讯

139-2527-9053

在线客服(服务时间 9:00~18:00)

在线QQ客服
地址:深圳市南山区西丽大学城创智工业园
电邮:jeky_zhao#qq.com
移动电话:139-2527-9053

Powered by 互联科技 X3.4© 2001-2213 极客世界.|Sitemap