做网站的流程图,临汾网站建设价格,常州的网站建设,做海报的话网站点击上方“Java知音”#xff0c;选择“置顶公众号”技术文章第一时间送达#xff01;作者#xff1a;流云诸葛http://cnblogs.com/lyzg/p/6132801.html推荐阅读(点击即可跳转阅读)1. 淘宝服务端高并发分布式架构演进之路2. IntelliJ IDEA 从入门到上瘾教程#xff0c;2019…点击上方“Java知音”选择“置顶公众号”技术文章第一时间送达作者流云诸葛http://cnblogs.com/lyzg/p/6132801.html推荐阅读(点击即可跳转阅读)1. 淘宝服务端高并发分布式架构演进之路2. IntelliJ IDEA 从入门到上瘾教程2019图文版3. 高并发场景下缓存处理的一些思路4. 权限设计的一些想法和思考单点登录是我比较喜欢的一个技术解决方案一方面他能够提高产品使用的便利性另一方面他分离了各个应用都需要的登录服务对性能以及工作量都有好处。自从上次研究过JWT如何应用于会话管理加之以前的项目中也一直在使用CAS这个比较流行的单点登录框架所以就一直在琢磨如何能够把JWT跟单点登录结合起来一起使用尽量能把两种技术的优势都集成到项目中来。本文介绍我从CAS思考得出的SSO的实现方案。前言其实CAS这个方案很好非常强大它最新的版本已经集成JWT了所以要是不想自己开发单点登录的服务的话完全可以考虑使用CAS。但是我认为我们在做项目的时候也许一开始并不需要这么强大的产品CAS提供的登录形式有很多而我们只需要应用其中的一种而且它这个框架正是因为强大所以也会比较复杂简单上手容易但是遇到一些特殊的需求比如我们想在CAS里面加入微信登录那就需要对它的原理以及API有比较深入的了解才行。综合考虑还是弄清楚CAS的原理自己来实现一个基本的SSO服务比较放心。本文的内容需要对JWT和SSO有一个基本的了解你可以从这两篇文章来了解JWT的用途http://www.cnblogs.com/lyzg/p/6067766.htmlhttp://www.cnblogs.com/lyzg/p/6028341.html还可以从下面的资料来了解SSO的内容https://baike.baidu.com/item/SSO/3451380?fraladdin方案介绍本文主要是通过时序图的方式来介绍JWT SSO的实现原理具体的技术实现暂时还没有不过当你理解了这个方案的原理后你会觉得最终的实现并不会特别复杂你可以用任意的平台语言来实现它。下面的时序图模拟了三个服务分别是CAS、系统A、系统B它们分别部署在http://cas.comhttp://systemA.com和http://systemB.comCAS这个服务用来管理SSO的会话系统A和系统B代表着实际的业务系统。我从五个场景分别来说明这个SSO方案的实现细节。下面先来看第一个。场景一用户发起对业务系统的第一次访问假设他第一次访问的是系统A的some/page这个页面它最终成功访问到这个页面的过程是图片点击放大看下同在这个过程里面我认为理解的关键点在于它用到了两个cookie(jwt和sid)和三次重定向来完成会话的创建和会话的传递jwt的cookie是写在http://systemA.com这个域下的所以每次重定向到http://systemA.com的时候jwt这个cookie只要有就会带过去sid的cookie是写在http://cas.com这个域下的所以每次重定向到http://cas.com的时候sid这个cookie只要有就会带过去在验证jwt的时候如何知道当前用户已经创建了sso的会话因为jwt的payload里面存储了之前创建的sso 会话的session id所以当cas拿到jwt就相当于拿到了session id然后用这个session id去判断有没有的对应的session对象即可。还要注意的是CAS服务里面的session属于服务端创建的对象所以要考虑session id唯一性以及session共享假如CAS采用集群部署的话的问题。session id的唯一性可以通过用户名密码加随机数然后用hash算法如md5简单处理session共享可以用memcached或者redis这种专门的支持集群部署的缓存服务器管理session来处理。由于服务端session具有生命周期的特点到期需自动销毁所以不要自己去写session的管理免得引发其它问题到github里找开源的缓存管理中间件来处理即可。存储session对象的时候只要用session id作为keysession对象本身作为value存入缓存即可。session对象里面除了session id还可以存放登录之后获取的用户信息等业务数据方便业务系统调用的时候从session里面返回会话数据。场景二用户登录之后继续访问系统A的其它页面如some/page2它的处理过程是从这一步可以看出即使登录之后也要每次跟CAS校验jwt的有效性以及会话的有效性其实jwt的有效性也可以放在业务系统里面处理的但是会话的有效性就必须到CAS那边才能完成了。当CAS拿到jwt里面的session id之后就能到session 缓存服务器里面去验证该session id对应的session对象是否存在不存在就说明会话已经销毁了退出。场景三用户登录了系统A之后再去访问其他系统如系统B的资源比如系统B的some/page它最终能访问到系统B的some/page的流程是这个过程的关键在于第一次重定向的时候它会把sid这个cookie带回给CAS服务器所以CAS服务器能够判断出会话是否已经建立如果已经建立就跳过登录页的逻辑。场景四用户继续访问系统B的其它资源如系统B的some/page2这个场景的逻辑跟场景二完全一致。场景五退出登录假如它从系统B发起退出最终的流程是最重要的是要清除sid的cookiejwt的cookie可能业务系统都有创建所以不可能在退出的时候还挨个去清除那些系统的cookie只要sid一清除那么即使那些jwt的cookie在下次访问的时候还会被传递到业务系统的服务端由于jwt里面的sid已经无效所以最后还是会被重定向到CAS登录页进行处理。方案总结以上方案两个关键的前提整个会话管理其实还是基于服务端的session来做的只不过这个session只存在于CAS服务里面CAS之所以信任业务系统的jwt是因为这个jwt是CAS签发的理论上只要认证通过就可以认为这个jwt是合法的。jwt本身是不可伪造不可篡改的但是不代表非法用户冒充正常用法发起请求所以常规的几个安全策略在实际项目中都应该使用使用https使用http-only的cookie针对sid和jwt管理好密钥防范CSRF攻击。尤其是CSRF攻击形式很多都是钻代码的漏洞发生的所以一旦出现CSRF漏洞并且被人利用那么别人就能用获得的jwt冒充正常用户访问所有业务系统这个安全问题的后果还是很严重的。考虑到这一点为了在即使有漏洞的情况将损害减至最小可以在jwt里面加入一个系统标识添加一个验证只有传过来的jwt内的系统标识与发起jwt验证请求的服务一致的情况下才允许验证通过。这样的话一个非法用户拿到某个系统的jwt就不能用来访问其它业务系统了。在业务系统跟CAS发起attach/validate请求的时候也可以在CAS端做些处理因为这个请求在一次SSO过程中一个系统只应该发一次所以只要之前已经给这个系统签发过jwt了那么后续 同一系统的attach/validate请求都可以忽略掉。总的来说这个方案的好处有完全分布式跨平台CAS以及业务系统均可采用不同的语言来开发业务系统如系统A和系统B可实现服务端无状态假如是自己来实现那么可以轻易的在CAS里面集成用户注册服务以及第三方登录服务如微信登录等。它的缺陷是第一次登录某个系统需要三次重定向不过可以优化成两次登录后的后续请求每次都需要跟CAS进行会话验证所以CAS的性能负载会比较大登陆后的后续请求每次都跟CAS交互也会增加请求响应时间影响用户体验。本文小结本文从理论层面介绍了结合jwt来实现SSO的方案原理希望它能帮助一些朋友更好的理解SSO以及它的实现方法。本文方案参考自CAS的实现流程你可以从下面这个资料了解CAS的单点登录实现过程https://apereo.github.io/cas/4.1.x/protocol/CAS-Protocol.html它的流程跟我这个差别不是特别大但是从清晰层面来说我写的还是要更明了一些所以对比起来阅读可能理解会更透彻些。另外这个方案考虑地不一定很全面所以要是您发现了其中的问题还请您帮忙指正非常感谢。
