做网站需要哪些知识,wordpress多页面统一头部,产品宣传网站模板,广州海珠区房价多少钱一平方1. 摘要 #xff08; 注意#xff1a;请仔细看下摘要#xff0c;留心此文是否是您的菜#xff0c;若浪费宝贵时间#xff0c;深感歉意#xff01;#xff01;#xff01;#xff09; SSO这一概念由来已久#xff0c;网络上对应不同场景的成熟SSO解决方案比比皆是 注意请仔细看下摘要留心此文是否是您的菜若浪费宝贵时间深感歉意 SSO这一概念由来已久网络上对应不同场景的成熟SSO解决方案比比皆是从简单到复杂各式各样应有尽有开源的有OpenSSO、CAS 微软的AD SSO及基于kerberos 的SSO等等……这些优秀的解决方案尽显开发及使用者的逼格当然需求所致无谓好坏高低满足实际之需才是王道 本文并不讨论上述提到的方案的整合使用、或者复杂场景如安全、防火墙、N 多个系统层叠调用这种巨型项目里SSO的实现与使用也并不涉及 C/S 、C/SB/S 的SSO解决方案仅关注B/S 上的SSO实现。虽是如此然而万变不离其宗这里我们将从一个简而小的登录场景去接触SSO的本质描述如何原生态地自实现一个轻量、微核的SSO本文不提供源码。 文章将由浅入深地探讨SSO单点登录涉及SSO的定义、表现、原理、实现细节等方面的阐述借助大家熟知的淘宝、天猫登录场景通过对阿里登录的模仿实现建立一个简单模型然后不断由该模型进行迭代并对每一个迭代版本进行详细描述最终得到一个支持跨域的SSO 力求条理清晰层层递进简单但有深度开始部分本着让即使从未听过SSO的同学也能够从抽象文字定义的概念印象过渡到具象的视觉认知这一宏zhuang伟bi理念入手将会有很多浅显的描述老司机 可以快速掠过 2. SSO简介 2.1 SSO定义 SSO Single Sign-On 中文意即单点登录翻译得比较精简个人觉得 Wiki 上的解释更细腻点—— SSO, is a property of access control of multiple related, but independent software systems. With this property a user logs with a single ID and password to gain access to connected system or systems without using different usernames or passwords, or in some configurations seamlessly sign on at each system. ( 单点登录是一种控制多个相关但彼此独立的系统的访问权限, 拥有这一权限的用户可以使用单一的ID和密码访问某个或多个系统从而避免使用不同的用户名或密码或者通过某种配置无缝地登录每个系统 ). 注系统在本文特指WEB 应用或者WEB 服务用户下文也会称之为UserID用户标识密码本文也称其为口令Password, Passcode 或者 Pin。 OK从上面的定义中我们总结出 与 SSO 交互的2个元素1. 用户2. 系统它的特点是一次登录全部访问。上面提到SSO是访问控制的一种控制用户能否登录即验证用户身份而且是所有其它系统的身份验证都在它这里进行那么我们是不是可以认为SSO还是一个验证中心。那么从整个系统层面来看SSO它的核心就是这3个元素了1. 用户2. 系统3. 验证中心。可能扯了那么多还是不足以形象地描述我们萌萌的SSO呐有图有真相 既然SSO这么棒应该如何实现呢 2.2 SSO示例——淘宝、天猫的登录场景 我们暂不考虑细节先从SSO需要解决的问题入手使用一个账户通过一次登录即可在多个相关的系统之间来回访问为了更加形像我们还是上图(多图预警) 登录页面网址login.taobao.com ….. 我将在 login.taobao.com 所指的系统进行登录 访问网站第一张网址buyertrade.taobao.com…. 访问 buyertrade.taobao.com所指的系统了然后访问另一张网页网址为favoriate.taobao.com 访问favoriate.taobao.com 所指系统两个系统的 Domain 是相同的请注意这点 接下来我再分别访问淘宝(www.taobao.com)和天猫(www.tmall.com)的首页 图中显示我仍旧是登录的( 注意这里是不同的Domain下系统之间的来回访问) 可以看到我除了在第一张网页图那里需要输入用户名ID和口令password进行登录再访问其它相关系统时从图2-5 中所有的访问操作无论域名相同还是不同我都不需要再登录了它们都知道我叫望向明天对没错这就是SSO的作用一次登录全部访问读者也可以尝试下看看是不是如此 3. SSO实现描述 好经过我上面一大段废话基本上对SSO要解决什么问题有一个清晰的认识。现在我们自行脑yi补yin下SSO 的原理是什么样的。 一个账户嗯规定所有系统统一使用相同账户就能保证一个账户了一次登录全部访问通过SSO登录后让其告知其它各个系统保存该用户的信息用户就不用重复多次的登录了嗯问题解决了没错就这样。 3.1 方案1 由上面的猜想可以得到第1个解决方案记为方案1。这里对这个猜想做一点小小的优化猜想中第2点 各个系统保存 好让人闹心同一份数据保存多份太浪费这里我们把每个已登录的用户信息保存到公共缓存中。好我们再来描述下这个方案 User 发送登录请求给SSO附上自己的 ID 和 passwordSSO验证成功将用户信息保存在公共缓存 Cache 中User每次发送请求给系统 Ai 时将 ID 作为请求参数系统 Aj 通过 请求中传过来的 User ID从公共缓存 Cache 中验证 User 是否登录完成后续动作 文字完了接下来看看方案1的架构图和时序图 嗯图文并茂的样子难道就这么大功告成了 我们先把方案1中完成的第一版 SSO 记为SSO_V1接下来我们来好好地捋一捋。 3.2 方案2 SSO_V1 貌似解决了问题但是深入思考细思极恐因为这个设计有Bug每次传 ID 给服务Ai但是这个ID 每次怎么获取来呢登录SSO的时候这倒没有问题可以让用户填但第2次请求是发给Ai中的某一个 Aj 时ID 要怎么来 假设百度和新浪是相关但彼此独立的系统登录百度后再访问新浪时怎么让新浪取到与登录百度时一样的ID吧总不至于每次发请求时都要求用户填一遍ID 吧 其实我们把 猜想 中最值得思考的问题之一忽略掉了 如何让SSO告知系统Ai当前登录的User 的ID和password 这问题可以这样来描述假设有W ( www.weidai.com )和 T( trade.weidai.com ) 两个系统W和T 都通过S (login.weidai.com) 系统登录当由U访问W再转向S 完成登录后怎样做才能使 U 访问T 时不需要再一次通过 S 进行登录验证 对如果你是WEB 开发的老司机很自然你会想到用cookie 即把用户信息 本文也会称之为UserInfo 保存在cookie 当中因为 无论W 、T 或者 S 它们的Domain是一样的——都是 weidai.com ——同一Domain这有何用用处就在于 W 、T 以及 S 可以共享此路径下的 cookie。这里让我们优化的心再一次燃烧起来——直接保存用户的 ID 和 口令 对于我们这么有逼格有追求的猿来说有点太不讲究——为什么呢不太安全cookie 中 最好保存一个 公共Session ID 请和WEB 自己生成的Seesion ID进行区分 而我们的公共缓存 Cache 中保存的 UserInfo 是一个由 公共Session ID为Key 以包含用户标识和口令的数据结构为Value的Map。最后附上这一流程的时序图及简要说明 U访问W W进行验证验证失败跳转至SSO要求U登录U通过SSO登录SSO进行验证成功并生成SessionID随后将UserInfo SessionID、ID和口令存储到公共缓存C 中跳转至W携带SessionID并允许U访问WU保存UserInfo SessionID 至 cookie ;这里请将 U 看成一个浏览器当下文有提到 U 保存XXX至Cookie时读者请自行切换U 再访问 T ( 并携带 在3 中保存至cookie 中的 UserInfo ) T从公共缓存中拉取UserInfo 进行验证成功则允许访问 嗯又是图文并茂的样子难道再一次大功告成 我们暂时把刚才的方案记为方案2并把方案2中完成的升级版SSO记为SSO_V2接下来我们再来好好地捋一捋 3.3 方案3 SSO_V2 能够在 Domain 相同的情况下完美解决问题但是在Domain不同的情况下怎么做到免登呢如上面图示淘宝 www.taobao.com 和天猫 www.tmall.com 若采用SSO_V2 肯定无法做到免登的因为我们知道当访问天猫时Domain 为tmall.com 淘宝 Domain 为 taobao.com 下的 cookie 是无法随访问请求一并传给与天猫相关的系统的。所以问题变成怎么让不同Domain下的系统也知晓用户已经登录的实事 在我们提出SSO_V3前我们先看看SSO 本质是什么通过这么多的文字描述、样图解释我们可以看到要让用户一次登录全部访问无非就是让所有的系统共享一份相同已验证的、安全可靠的验证信息。所以问题就可以转化为不同Domain下的系统如何共享一份的验证信息既然Domain无法做到交叉访问那我们可以让不同Domain下的WEB应用持有相同的验证信息这在效果上不就是一份吗所以最终要解决的问题就是SSO系统如何使不同的 Domain 拥有一份相同的cookie —— 让SSO在用户进行登录时再去访问其它域下的系统并让各个系统保存一样的验证信息这样不同域下就会有同一份cookie。 以下是SSO_V3的时序图和文字说明这里我们假设 SSO 的Domain 为 SDT 的 Domain 为 TD U第一次访问WW验证失败跳转至SSO要求U进行登录验证 登录并使各不同Domain下 U 给SSO发送登录请求SSO验证成功生成SessionID 并保存UserInfo返回给U的Response 将 UserInfo 存放至cookie中Domain为SD将 2 中 cookie 内容作为query parameter 重定向至TT验证后成功返回给U也在Response 中设置 cookieDomain为TDU自动访问SSOSSO将请求重定向至W完成U对W 的访问U 再访问 T验证成功并允许U进行访问 嗯还是图文并茂的样子这下是不是可以完事了呢我们还是把刚才的方案记为方案3并把方案3中完成的升级版SSO记为SSO_V3然后还是来好好地捋一捋 3.4 方案4 再细细的考虑下SSO_V3的实现方式有没有感觉它哪里有点不对劲 思维一直跟着我来走是不是被绕晕了想发现不对劲怎么可能 SSO_V3 使不同 Domain 获取相同的cookie 拷贝时表面是在U处主动发出向的请求其实是被动 但实际上是 SSO 返回给 U 的页面自动完成的通过 JS、通过页面自动跳转、iframe都可以实现。所以方案SSO_V3要求SSO 预先知道有哪些系统是跨域的而且它还有一个很严重的问题假如与SSO相关但相互独立的系统中有 20 需要跨域才能访问而SSO要在用户登录时完成20跳转……现在你是不是要呵呵了貌似完美解决跨域的SSO_V3 竟然如此有问题有没有心好塞 SSO_V3 解决的核心问题是针对跨域的系统各系统间如何保证获取到的 验证信息是一致的解决方法即是在用户第一次登录时把验证信息复制给所有跨域的系统。这种方案在跨域系统少的情况下倒是不需要有太多担心但是当跨域系统多、且验证步骤比较复杂时用户将会卡在登录界面最后不得不怒关页面所以当理清这些逻辑很自然就会想到接下来要如何对SSO_V3进行优化。核心思想就是既然一次性解决会有问题那就分多次解决简单的描述下我们将要看到的SSO_V4用户登录后当第一次访问跨域系统W 时跳到SSO复制一份至W的cookie中过程结束当访问T时重复该处理动作。 以下为SSO_V4的时序图及简要说明 用户U访问W W进行验证验证失败跳转至SSO要求U登录U通过SSO登录SSO进行验证成功并生成SessionID随后将UserInfo SessionID、ID和口令存储到公共缓存C 中跳转至W携带SessionID并允许U访问WU保存UserInfo SessionID 至 cookieU访问TT 进行验证失败跳转至SSOSSO将触发U请求SSO将验证信息随请求一并发给SSO经SSO验证成功跳转至允许U对T 的访问使U保存UserInfo SessionID至cookie 3.5 小结 其实我们通过上面的实用版SSO_V2SSO_V3SSO_V4SSO可以看到除了用户的第一次登录某个应用相对来说比较特殊其它处理都是一致的。所以当我们抛去细节之后不仿这样联想SSO的实现完成登录逻辑并使各系统共享验证信息和验证逻辑从这个层次去看SSO我们发现它其实只负责用户登录和身份验证这2、3个点。 下面是用户第一次登录及SSO与其它系统交互的简图 4. 设计与实现 4.1 验证信息的安全考虑 第3部分中的身份验证和验证信息方面都做得比较简单在实际项目中不可能如此使用在此提出一个方案以供参考这也是比较流行的一种。 使用 HTTPS 进行用户登录为每个用户生成一个对称密钥Ku验证信息由ID password SessionID 组成当然你可以按需设置比如再加个IP 地址……存储在cookie 中的验证信息ID 和口令部分经由用户密钥Ku和SSO公钥处理后在存放至客户端这样处理后相信能够满足大部分应用的需求了 4.2 SSO的概要设计 4.2.1 整体思路 SSO这一理念到目前为止已经非常成熟关于它的各种设计、设置都可以定制一套标准了。然而由于SSO与用户有强关联所以很多设计在最初时往往会把SSO设计成一个用户管理系统而使得SSO与业务耦合随着业务的不断变化和演进底层数据结构、接口不断的复杂化又反过来使得上层服务的架构设计变得尴尬。 若做更进一层的抽象和划分SSO只需负责登录这单一功能即可设计上满足单一职责原则[1]加上几乎所有网站的登录都大同小异(可能登录界面会变幻无常)且不与业务有过多牵连这又使得SSO与业务完全分离无论将来业务怎样演进产品如何迭代SSO作为底层应用可以以不变应万变。Really? All problem in computer science can be solved with another level of indirectionexcept of course for the problem of too many indirections.[2] 如何在设计中做到复杂与简洁的平衡需要根据实际情境深度地考量这可以扯出长篇大论了按下不表我们的SSO姑且就搞这几个功能登录、记录轨迹、登出以下是用例图 第3节第5部分有提到登录交由SSO完成各系统共享一套验证逻辑很自然的验证这一逻辑对SSO也是必须的在此就由SSO来完成其它系统只需将其配置到各自系统里即可。再加上SSO是用户做案的第一现场所以记录用户登录信息的事也很自然的就让SSO给干起来了而且这一功能不仅能够让用户感受到我们对客户的用心同时也为后期数据分析业务提供数据源 4.2.2 数据表设计 经过上面的讨论我们着手思考SSO的数据结构——数据表设计个人认为面向对象编程中数据结构的优劣基本决定整个应用的质量。从SSO 功能简单及其微服务的定位SSO的表应该简洁、单一上层服务若需要对其进行扩展只需要对基本表进行外键引用即可这里我们暂时只用3张表分别为User、Trace用户轨迹表和使用平台表图示与描述如下 用户表User uid 用户唯一标识 varchar 是否有更好name 账号可以唯一标识用户emailphone等都唯一标识用户status用户状态冻结已删除……key 用户密钥info扩展字段用以应变需求 用户轨迹表Trace type 轨迹类型删除登录登出修改……time 操作时间info同上uid 用户表外键pid 为Platform的外键 使用平台表Platform ip用户登录ipaddress用户登录地址可由IP 解析得到手机端可以使用GPSplatform使用平台的信息将在请求的head上得到info同上tid 表示Trace 表的外键 4.2.3 简要类设计 通过上面的整体思路及数据结构的定型我们可以继续铺开将SSO要涉及到的一些主体类及主要方法定义好仍旧上图 写到这里对于这个图示就不再做过多解释大家基本可以开始做各种各样的脑补了额仅说小小的一个点验证由Interceptor实现这样验证逻辑则可以以插件形式配置到其它系统实现所有系统共享一套验证逻辑当然你也可以根据具体情况做成Filter看个人爱好; 访问这方面交给第三方处理比如由Shiro、Spring Security等来完成……酱紫结束转载于:https://www.cnblogs.com/ruiati/p/6249361.html
