Atitit. 单点登录sso 的解决方案 总结

Atitit.  单点登录sso 的解决方案 总结

1. 系统应用场景and SSO模式选型 2

2. 系统应用的原则与要求 2

2.1. 开发快速简单::绝大部分系统来说，开发快速简单为主 2

2.2. 支持token交换，这样有利于集成先有的系统模块无需大改动，仅仅需要改动登陆模块。。 2

2.3. 支持用户名映射.当多个子系统username不同时候儿 2

3. 脱机验证sso （分散认证，类似护照的识别方式） 2

3.1. 适合场景:: 高性能场景，支持单方面改造 3

3.2. 缺点::  需要对各个子系统的token格式较为了解。。 3

4. 分散式联机认证+Token交换 3

4.1. 原理:: 3

4.2. 适合场景:: 绝大部分场景..需要双向改造 3

4.3. 主要的流程 3

4.3.1. ---A系统建立token检验API(   web系统通常是session,cookie等, )  , 就是把检验登录login.jsp那个代码复制过来,稍微修改一哈... 例如建立 loginValidApi.jsp
4

4.3.2. 访问B系统某个模块 4

4.3.3. B会检测是否在本系统登录，如登录，正常的访问...。。。。如未有登录,B系统在没修改的情形哈,会跳转到login.php..我们修改这个跳转,,先跳转到loginX.php(这个页面是需要我们建立的)
4

4.3.4. 在loginX.php中,把token转交给A验证(使用redirect转发 )...   跳转到 loginValidApi.jsp
4

4.3.5. --A的loginValidApi.jsp检测是否在本系统登录,如登录,把userA的信息返回B的loginX.php页面。。如没有登录，也是返回loginX.php（当然这种情况用户信息就为空了）。。
4

4.3.6. B系统loginX.php检测用户信息，如果没有用户信息，说明在A系统也没有登录。。
4

4.3.7. 如果有其他的多个系统C,DE等，依次访问其api接口 4

4.3.8. 如果都没有登录，就转向login.php,进入普通登录。。。如有返回用户信息，说明已经在A系统登录了..  此时，如果A，B系统同一用户的username各不相同，需要做用户名映射 ,,userA>>userB .....。
5

4.3.9. 查询UserB信息,生成B系统的token  ( 这个代码通常可以从B系统的登录代码中copy过来稍微修改哈)..
5

4.3.10. 跳转到B的那个模块,就会做为登录状态访问了.
5

4.3.11. 访问A系统模块的流程可以参照这个，增加LoginX.jsp跟。loginValidApi.php就可以了。
5

4.4. Token交换 5

4.5. 用户名映射 5

5. CAS开源单点登录SSO组件（统一的认证中心） 5

5.1. Cas原理  ：：所有应用系统共享一个身份认证系统。 5

5.2. 适合场景:: 新的开发子系统 6

5.3. 缺点::   要是在已有子系统引进,修改开发工作量大的(三方修改),,回归测试量大的..就算是使用了cas框架.
6

6. 参考 6

1. 系统应用场景and SSO模式选型

要是多个已经存在的系统,做sso, 做好使用”分散式联机认证模式”,开发量测试最少

已经存在的多系统,,需要高性能,使用”分散认证脱机验证sso “模式

新的开发的系统,可以使用cas 等的统一的认证中心  方式...

2. 系统应用的原则与要求

2.1. 开发快速简单::绝大部分系统来说，开发快速简单为主

2.2. 支持token交换，这样有利于集成先有的系统模块无需大改动，仅仅需要改动登陆模块。。

2.3. 支持用户名映射.当多个子系统username不同时候儿

作者:: 老哇的爪子 Attilax 艾龙，  EMAIL:[e-mail]

转载请注明来源： http://blog.csdn.net/attilax

3. 脱机验证sso （分散认证，类似护照的识别方式）

用一个现实中的例子做比较。 著名的旅游景点， 内部有许多独立的景点，例如“苏州 街”、“佛香阁”和“德和园”，都可以在各个景点门口单独买票。很多游客需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票，钱包拿 进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门 口出示一下刚才买的套票就能够被允许进入每个独立的景点。

3.1. 适合场景:: 高性能场景，支持单方面改造

还有个优点是，可以单个子系统实现，无需俩边系统都改。。特别适合只能修改一方系统的情形...

3.2. 缺点::  需要对各个子系统的token格式较为了解。。

4. 分散式联机认证+Token交换

4.1. 原理::

例如银行验证身份证，，除了验证身份证本身的物理防伪。。更需要连接（身份验证机构的）远程身份验证接口来验证身份信息。

4.2. 适合场景:: 绝大部分场景..需要双向改造

4.3. 主要的流程

例如::A系统(java系统） 互相集成 B系统（php论坛）,,现今开始使用b的某一模块

4.3.1. ---A系统建立token检验API(   web系统通常是session,cookie等, )  , 就是把检验登录login.jsp那个代码复制过来,稍微修改一哈... 例如建立 loginValidApi.jsp

4.3.2. 访问B系统某个模块

4.3.3. B会检测是否在本系统登录，如登录，正常的访问...。。。。如未有登录,B系统在没修改的情形哈,会跳转到login.php..我们修改这个跳转,,先跳转到loginX.php(这个页面是需要我们建立的)

4.3.4. 在loginX.php中,把token转交给A验证(使用redirect转发 )...   跳转到 loginValidApi.jsp

4.3.5. --A的loginValidApi.jsp检测是否在本系统登录,如登录,把userA的信息返回B的loginX.php页面。。如没有登录，也是返回loginX.php（当然这种情况用户信息就为空了）。。

4.3.6. B系统loginX.php检测用户信息，如果没有用户信息，说明在A系统也没有登录。。

4.3.7. 如果有其他的多个系统C,DE等，依次访问其api接口

4.3.8. 如果都没有登录，就转向login.php,进入普通登录。。。如有返回用户信息，说明已经在A系统登录了..  此时，如果A，B系统同一用户的username各不相同，需要做用户名映射 ,,userA>>userB .....。

4.3.9. 查询UserB信息,生成B系统的token  ( 这个代码通常可以从B系统的登录代码中copy过来稍微修改哈)..

4.3.10. 跳转到B的那个模块,就会做为登录状态访问了.

4.3.11. 访问A系统模块的流程可以参照这个，增加LoginX.jsp跟。loginValidApi.php就可以了。

4.4. Token交换

4.5. 用户名映射

5. CAS开源单点登录SSO组件（统一的认证中心）

5.1. Cas原理  ：：所有应用系统共享一个身份认证系统。

们提供的CAS开源单点登录SSO组件，它部署节点主要有2个：SSO服务器(部署内容为一个web应用)、应用系统客户端(部署内容为cas客户端 casclient.jar包和相关配置文件)。因此我们根据SSO机制分析一下什么情况下会出现超时。多个应用系统进行SSO集成后，SSO单点登录过 程中，登录成功后，应用系统客户端（以下用浏览器客户端为例）的session会保存认证后的用户上下文，SSO服务器会生成一个用户凭证票据(TGT) 并缓存起来，浏览器客户端会保存TGC（浏览器cookie中存储的TGT），TGT是作为发放SSO访问服务的票据（ST）的一个凭证票据，发放ST票 据后才能正常访问

CAS开源单点登录SSO组件就提供了这个机制。我研究了CAS源码，基本明白了jsessionid的处理机制。大致原理如下：用户访问业务系 统，SSO客户端拦截，重定向到SSO服务器认证时，就将请求路径uri中写入";jsessionid=具体的session值"，SSO服务器可以分 辨出这个标识值与其他客户端请求不同，进行认证处理，返回的响应给客户端cookie同时也设置了jsessionid的值，之所以在uri和 cookie中都设置了jsessionid，是为了双重保障能设置jsessionid值。最后单点登录成功后，返回业务系统访问地址也带有 jsessionid参数，这个在uri地址中看起来很别扭。

5.2. 适合场景:: 新的开发子系统

5.3. 缺点::   要是在已有子系统引进,修改开发工作量大的(三方修改),,回归测试量大的..就算是使用了cas框架.

6. 参考

SSO之CAS单点登录实例演示 _ micmiu - 软件开发+生活点滴.htm

SSO(单点登录)实施中遇到的几个问题 - yan_dk的专栏 - 博客频道 - CSDN.NET.htm

SSO单点登录解决方案[转载] - 走在架构师的大道上 Jack.Wang's home - BlogJava.htm

( 离线检验 )单点登录SSO的实现原理 - 走向架构师之路 - 博客频道 - CSDN.NET.htm