单点登陆全方位学习

写做提纲

 

1. http协议的无链接、无状态特性

2. 单点登陆、登出的交互是如何进行的：client，application A，application B，认证中心

3. 全局会话与局部会话

4. 单点登陆的实现：联系代码

5. 单点登陆的企业级实现：框架是如何来实现的

6. 单点登陆的安全性

7. 单点登陆中的其余问题：好比令牌如何生成

 

1、http协议的无链接无状态特性

如今大多数web应用采用的是browser/server架构，http做为通讯协议。http是无链接、无状态的协议，这两个特性都后来web应用的架构和设计点产生了很大的影响。

 

无链接的含义是限制每次链接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开链接。采用这种方式能够节省传输时间。

 

无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即咱们给服务器发送 HTTP 请求以后，服务器根据请求，会给咱们发送数据过来。再次访问发送HTTP请求以后，服务器会把咱们当成从未服务过的新人同样，只会根据咱们的请求来响应，和上次以及后来的HTTP请求没有任何的关联。

 

图1 http请求的无链接无状态特性

 

HTTP 协议这种特性有优势也有缺点，优势在于解放了服务器，每一次请求"点到为止"不会形成没必要要链接占用，缺点在于每次请求会传输大量重复的内容信息。
客户端与服务器进行动态交互的 Web 应用程序出现以后，HTTP 无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是须要承前启后的，简单的购物车程序也要知道用户到底在以前选择了什么商品。

 

再好比，在一个须要登陆的系统（目前大多数企业级应用都有登陆功能），我第一次登陆的时候须要输入帐号密码。若是没有其余任何机制的话，对于这个系统咱们只能登陆，其余的什么都干不了，想一下为何。

 

因而，两种用于保持 HTTP 链接状态的技术就应运而生了，一个是 cookie，而另外一个则是 session。

2、Web应用的会话机制：cookie和session

cookie和session均可以用来解决http协议无状态的特性，简单回顾一下它们的区别。

cookie是由网景公司的前雇员Lou Montulli在1993年发明的，现今cookie已经普遍使用了。

cookie 和session 的区别回顾：

1. cookie数据存放在客户的浏览器上，session数据放在服务器上。

2. cookie不是很安全，别人能够分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。

3. session会在必定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。

4. 浏览器对每一个站点的cookie数，以及每一个cookie的大小都是有限制的。

各浏览器中cookie个数和大小限制汇总(转)

服了这些人了，为啥转载不附上原做的地址！！！

 

Cookie的属性和跨域问题中有以下描述

个域名下面可能存在着不少个cookie对象，cookie具备多个属性：

name字段为一个cookie的名称

value字段为一个cookie的值

domain字段为能够访问此cookie的域名，Servlet中经过setDomain()设置

非顶级域名，如二级域名或者三级域名，设置的cookie的domain只能为顶级域名或者二级域名或者三级域名自己，不能设置其余二级域名的cookie，不然cookie没法生成。

顶级域名只能设置domain为顶级域名，不能设置为二级域名或者三级域名，不然cookie没法生成。

二级域名能读取设置了domain为顶级域名或者自身的cookie，不能读取其余二级域名domain的cookie。因此要想cookie在多个二级域名中共享，须要设置domain为顶级域名，这样就能够在全部二级域名里面或者到这个cookie的值了。
顶级域名只能获取到domain设置为顶级域名的cookie，其余domain设置为二级域名的没法获取。

而后又发现了一个淘宝、天猫跨域请求实现分析的技术文章：Cookie跨域问题

其实大体原理如此，经过在www.taobao.com 的server端提供一个获取当前域下全部cookie的 php的请求地址，而后该php获取到cookie以后将期并成 js 代码，也就是以上第二个截图所看到的。而后再在 tmall 采用 jsonp 的方式跨域加载该 js 代码，从而实现 cookie 的跨域访问。

3、单系统登陆

单系统的会话机制是如何实现的呢？

 

上面说到过cookie是存储客户端的（浏览器），而session是保存在服务器端的。同时咱们也看到，因为采用服务器端保持状态的方案在客户端也须要保存一个标识，因此session机制可能须要借助于cookie机制来达到保存标识的目的，但实际上它还有其余选择。

保存这个session id的方式能够采用cookie，这样在交互过程当中浏览器能够自动的按照规则把这个标识发挥给服务器。通常这个cookie的名字都是相似于SEEESIONID。

 

但cookie能够被人为的禁止，则必须有其余机制以便在cookie被禁止时仍然可以把session id传递回服务器。常常被使用的一种技术叫作URL重写，就是把session id直接附加在URL路径的后面。还有一种技术叫作表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时可以把session id传递回服务器。

 

4、多系统登陆

 

上面讲到了，单系统登陆中关键的部分是要经过cookie来传递会话标识来维护会话状态。可是cookie是有限制的，域名、大小。既然这样，为何不将web应用群中全部子系统的域名统一在一个顶级域名下，例如“*.baidu.com”，而后将它们的cookie域设置为“baidu.com”，这种作法理论上是能够的，甚至早期不少多系统登陆就采用这种同域名共享cookie的方式。然而，可行并不表明好，共享cookie的方式存在众多局限。首先，应用群域名得统一；其次，应用群各系统使用的技术（至少是web服务器）要相同，否则cookie的key值（tomcat为JSESSIONID）不一样，没法维持会话，共享cookie的方式是没法实现跨语言技术平台登陆的，好比java、php、.net系统之间；第三，cookie自己不安全。所以，咱们须要一种全新的登陆方式来实现多系统应用群的登陆，这就是单点登陆。

 

5、单点登陆

 

单点登陆（Single Sign On）解决的问题是登陆一个系统以后就能够在多个系统之间能够免登录访问。

单点登陆不只仅是登陆还有注销。

 

为了在多个系统之间可以登陆，单点登陆须要一个独立的认证中心。

 

在博客单点登陆原理与简单实现中有一个图讲的很清楚

 

 

这里分两个部分来描述单点登陆的过程

 

第一部分是第一次登录，第一次登陆咱们确定是要输入帐号、密码进行登陆的，上图中也描绘的很清楚

 

1. 用户访问系统1的受保护资源，系统1发现用户未登陆，跳转至sso认证中心，并将本身的地址做为参数
   sso认证中心发现用户未登陆，将用户引导至登陆页面
2. 用户输入用户名密码提交登陆申请
3. sso认证中心校验用户信息，建立用户与sso认证中心之间的会话，称为全局会话，同时建立受权令牌
4. sso认证中心带着令牌跳转会最初的请求地址（系统1）
5. 系统1拿到令牌，去sso认证中心校验令牌是否有效
6. sso认证中心校验令牌，返回有效，注册系统1
7. 系统1使用该令牌建立与用户的会话，称为局部会话，返回受保护资源

 

第二部分是已登陆的帐号免登录到另外一个系统。

1. 用户访问系统2的受保护资源
2. 系统2发现用户未登陆，跳转至sso认证中心，并将本身的地址做为参数
3. sso认证中心发现用户已登陆，跳转回系统2的地址，并附上令牌
4. 系统2拿到令牌，去sso认证中心校验令牌是否有效
5. sso认证中心校验令牌，返回有效，注册系统2
6. 系统2使用该令牌建立与用户的局部会话，返回受保护资源

 

cnblogs上还有个专门作单点登陆的，我也是服气，单点登陆SSO：图示和讲解

6.1  用户未登陆时访问子站一，子站一服务器检测到用户没登陆（没有本站session，由于没传过来session对应cookie），因而通知浏览器跳转到SSO服务站点，并在跳转的URL参数中带上当前页面地址，以便登陆后自动跳转回本页。

6.2  SSO服务站点检测到用户没有登陆，因而显示登陆界面。

用户提交登陆请求到服务端，服务端验证经过，建立和帐号对应的用户登陆凭据（token）。

而后，服务端通知浏览器把该token做为SSO服务站点的cookie存储起来，并跳转回子站一，跳回子站一的URL参数中会带上这个token。

6.3  浏览器在写SSO服务站点cookie后，跳转回子站一。

子站一服务端检测到浏览器请求的URL中带了单点登陆的token，因而把这个token发到SSO服务站点验证。

SSO服务端站点拿token解密出用户帐号，把帐号信息中容许子站一访问的部分返回给子站一。

子站一根据返回的信息生成用户在本站的会话，把会话对应cookie写入浏览器，从而完成在本站的登入以及会话保持。以后用户访问再子站一时，都会带上这个cookie，从而保持在本站的登陆状态。

6.4  用户再访问子站二。子站二服务器检测到用户没登陆，因而通知浏览器跳转到SSO服务站点。

6.5  浏览器访问SSO服务站点时会带上上述6.2环节建立的token这个cookie。SSO服务站点根据该token能找到对应用户，因而通知浏览器跳转回子站二，并在跳转回去的URL参数中带上这个token。

6.6  子站二服务端检测到浏览器请求的URL中带上了单点登陆的token，因而又会走上述6.3对应步骤，完成用户在本站的自动登陆。

 

这里有个问题是在登陆系统2的时候是要进行验证的，这个时候没有帐号信息，拿头作验证？

在本文讲cookie的时候提到过一篇文章讲taobao与tmall作跨域的cookie的方法能够用，假如cookie被禁用了咋办，我仍是想实现单点登陆怎么办呢？不跨域的cookie使用只能在同一个二级域名下了。

 

京东的跨域sso

js遍历sso，经过jQuery.ajax()方法对其中的每条数据发起跨域的jsonp请求；

能够看到返回一个重定向的Response，并且是跨域的重定向，因为发起的是跨域的jsonp请求，因此浏览器会根据返回的重定向url发起一次请求，也就是最后的跨域设置Cookie的请求

 

SSO实施和业务系统开发不一样，它是技术点密集但工做量少的业务。若是你的开发人员还要为“如何跨域传token”、“如何读写AD”之类现学摸索，那实施结果每每存在较大安全漏洞，也会致使工期不可预测。这一块的不少现成产品都有特定的实施要求和局限性（本人曾填坑Oracle的OIM 和 ESSO），加之实施人员对产品熟悉程度不一，致使企业稍有自身特定的状况，就会要花费大量工时研究调整，甚至最终没法按需交付。

 

个人实现中，认证系统和应用系统是经过url参数来传递ticket，可能存在一些不稳定因素。应用系统的每次请求都会经过HTTP远程到认证系统进行验证ticket，速度上应该会慢一些，这里能够改进一步，在每一个应用系统中也维护一份tickets，验证时，首先到本系统中验证，若是不存在，再远程到认证系统进行验证，但这也增长了应用系统的代码量。

 

在登陆的过程当中起始出现了两种级别的会话

6、单点登陆代码示例和部署

 

若是用SOA来作单点登陆的话还挺简单的

 

 

7、单点登陆的企业级实现：框架是如何来实现的

spring + shiro + cas 实现sso单点登陆

sso-shiro-cas
spring下使用shiro+cas配置单点登陆，多个系统之间的访问，每次只须要登陆一次，项目源码

系统模块说明
cas： 单点登陆模块，这里直接拿的是cas的项目改了点样式而已
doc： 文档目录，里面有数据库生成语句，采用的是MySQL5.0，数据库名为db_test
spring-node-1： 应用1
spring-node-2： 应用2
其中node1跟node2都是采用spring + springMVC + mybatis 框架，使用maven作项目管理

 

shiro多系统单点登陆

最近作项目遇到了多个系统权限用的是shiro框架，须要作成单点登陆，虽然shiro为单点登陆提供了shiro-cas的方案，可是不太符合咱们现有项目的框架，如今和你们分享一下我是如何实现单点登陆。总体思路是参考cas。

框架图：

流程介绍

• 用户第一次访问系统A
• 系统A的ssoFilter发现当前session没有用户信息就重定向到登陆服务器http://loginservice/login?redirecturl=url
• 登陆服务器判断当前用户是否登陆若是该用户登陆则重定向到用户访问http://redirecturl?sessionid=sessionidg不然调到登陆页面
• 系统A的ssoFilter发现当前session没有用户信息可是有参数sessionid，说明该请求是从单点登陆服务器跳转过来的而且该用户是已经登陆。在ssoFilter中为response添加addcookie（sessionid），且为response写入输出流，该输出流为一个html页面其中有一段js代码是访问系统A中用户访问的url
• 浏览器执行步骤4中返回js，此时访问系统A时携带的cookie中的sessionid是在单点登陆系统登陆的sessionid，A系统ssoFilter发现该用户已登陆容许访问本系统资源。

 

也就是说在单点登陆实现的时候仍是要依靠连接重定向与cookie。

 

若是不用cookie该怎么办呢？

此前使用过cas作单点登陆，作了一半发现这个不可行，由于应用场景的限制不能基于cookie来识别用户经过验证与否。
在sof上面也提过问，就是说让在url里面加入token，不过不太理解。
请问你们是否有作过相关的东西，若是有的话，能帮我解惑吗？

 

其实 Cookie 在用户登陆里的做用也只是存一个 Session ID 而已，你能够本身实现一套 Session 机制把 Session ID 经过 URL 来传递。

在好久好久之前那些手机版网站（那时候手机广泛不支持 Cookie）就是这么作的。

其实与其在网站上面作这么恶心的 workaround，不如在客户机上面处理。好比说用具有回话隔离功能的浏览器（好比说 Google Chrome 登陆不一样的 Google 帐户后相互之间的 Cookie 就是不互通的）。

 

上面说过cookie是不能跨域的，经过特殊设置setDomain()能够作到跨同一个大域下的两个子域。

 

CAS框架：CAS（Central Authentication Service）是实现SSO单点登陆的框架。

 

Spring Security + CAS实现单点登陆

 

8、单点登陆的安全性

门户系统单点登陆安全性分析

 

应该说单点登陆是门户系统的核心组件之一．也是门户系统的安全屏障。经过单点登陆验证成功后，用户能够访问门户下全部应用系统，因此保证单点登陆的安全是保证门户系统安全的前提。可是，现有的产品在单点登陆的安全性还有一些不足：
(1)安全性考虑不全面
各个解决方案在安全性考虑不是很全面，没有针对门户的复杂性，采用多种技术结合保证门户的安全，例如微软的Passport采用Kerberos认证机制来完成身份认证工做，服务器与用户共事的秘密是用户的票据，服务器在回应时不验证用户的真实性，假设只有合法用户拥有口令字。若是攻击者记录申请回答报文，就易造成重发攻击。
(2)安全兼容性不高
不少解决方案的安全性是创建在对本身产品标准的兼容基础上的，对异构的系统安全性支持很差，例如IBM的WebSphere则过于依赖于WebSphere Domino环境，对其它异构系统的安全兼容性很差。
(3)信息传输缺少安全保证
在门户服务器与应用服务器通讯过程当中大多数方案采用明文形式传送敏感信息，这些信息很容易被窃取，导致重要信息泄露。另外，在通讯过程当中大多数方案也没有对关键信息进行签名，容易遭到假装攻击。
(4)Web服务的安全缺陷
因为单点登陆基本上是基于Web服务实现的，因此单点登陆天生就继承了Web服务的安全缺陷，这也每每被各个解决方案所忽略。

 

首先应该避免用户凭证的COOKIE泄露，在用户端，由于内存COOKIE比文件COOKIE更难被截取，特别是通过特殊处理的浏览器，要截取内存COOKIE几乎不可能，并且当浏览器关闭时，内存COOKIE失效，因此应该使用内存COOKIE而非文件COOKIE，这也是不少使用文件COOKIE的论坛账号常常被盗的缘由。

 

为进一步减小风险，不该该在COOKIE中直接保存用户凭证，而是使用一个无心义的标识符如UUID来表示，而登录服务能够经过这个UUID查找到真正的用户凭证，这个标志符随机生成，即便同一用户登录，获得的UUID也不同，因此不能重复使用，这样即便偶尔泄露一次，也不会形成长期影响。为了提升COOKIE的截取难度，能够设置一个有效时间，只有在有效期内的COOKIE是合法的，超过有效期的COOKIE将被忽略，使用超过有效期的用户依然须要从新输入验证信息。这样也带来一个不便的地方，就是用户若是两次业务逻辑之间的切换时间超过了COOKIE的有效期，那么用户还得从新输入验证信息，达不到单点登录的效果，因此如何取舍，要根据业务逻辑而定。

 

其次由于http使用明文传输，经过网络侦听的方式很容易获取COOKIE，因此用户到登录服务间的链接应该采用https

 

登录代理中使用COOKIE来保存SESSION的状况，这是大多数Web应用服务器采用的方法。这种状况相似登录服务使用COOKIE来保存用户凭证，典型的欺骗是黑客B截获了正经常使用户A的SESSION COOKIE，而后B访问业务逻辑时附带这个COOKIE，Web应用服务器会认为B就是A，因而A能获得的用户凭证，B也能获得，B就成了A的影子，与A具备相同的操做权限。因此关键问题仍是如何避免SESSION COOKIE的泄露，由于这个COOKIE由Web应用服务器控制，因此除了在网络传输时使用https，基本上没有其余办法能够下降风险。除了使用COOKIE做为SESSION标记，不少Web应用服务器也支持隐式域的方式，就是Web应用服务器在页面自动建立一个隐藏的表单项做为SESSION标记，页面提交时该表单自动被提交，Web应用服务器经过这个表单项来肯定用户SESSION。这个是更不安全的作法，由于不少很简单的方法就能够获取页面表单项的数据，比获取内存COOKIE容易不少。

 

业务逻辑、登录代理、登录服务间存在消息传递，业务逻辑和登录代理部署在一个Web应用服务器中，消息传递比较安全。登录代理和登录服务一般处在不一样的Web应用服务器中，而且一般在地域上也不一致，登录代理和登录服务间的安全隐患除了消息泄露，还有相互信任的问题。

 

9、单点登陆中的其余问题：好比令牌如何生成

 

目前已实现单点登陆的典型模型有经纪人模型、代理模型、代理和经纪人模型、网管模型和令牌模型等，比较成熟的解决方案有微软的 Passport、IBM的WebSphere Portal Server、CAS，这些产品虽能较好的实现单点登陆，但存在系统复杂、使用成本和学习曲线高、不能知足小型应用系统集成等缺点。

 

小型系统的令牌用UUID？