Atitit. 单点登录sso 的解决方案 总结
2.1. 开发快速简单::绝大部分系统来说,开发快速简单为主 2
2.2. 支持token交换,这样有利于集成先有的系统模块无需大改动,仅仅需要改动登陆模块。。 2
2.3. 支持用户名映射.当多个子系统username不同时候儿 2
3.2. 缺点:: 需要对各个子系统的token格式较为了解。。 3
4.3.4. 在loginX.php中,把token转交给A验证(使用redirect转发 )... 跳转到 loginValidApi.jsp 4
4.3.6. B系统loginX.php检测用户信息,如果没有用户信息,说明在A系统也没有登录。。 4
4.3.7. 如果有其他的多个系统C,DE等,依次访问其api接口 4
4.3.9. 查询UserB信息,生成B系统的token ( 这个代码通常可以从B系统的登录代码中copy过来稍微修改哈).. 5
4.3.10. 跳转到B的那个模块,就会做为登录状态访问了. 5
4.3.11. 访问A系统模块的流程可以参照这个,增加LoginX.jsp跟。loginValidApi.php就可以了。 5
5.1. Cas原理 ::所有应用系统共享一个身份认证系统。 5
5.3. 缺点:: 要是在已有子系统引进,修改开发工作量大的(三方修改),,回归测试量大的..就算是使用了cas框架. 6
1. 系统应用场景and SSO模式选型要是多个已经存在的系统,做sso, 做好使用”分散式联机认证模式”,开发量测试最少
已经存在的多系统,,需要高性能,使用”分散认证脱机验证sso “模式
新的开发的系统,可以使用cas 等的统一的认证中心 方式...
2. 系统应用的原则与要求2.1. 开发快速简单::绝大部分系统来说,开发快速简单为主
2.2. 支持token交换,这样有利于集成先有的系统模块无需大改动,仅仅需要改动登陆模块。。
2.3. 支持用户名映射.当多个子系统username不同时候儿
作者:: 老哇的爪子 Attilax 艾龙, EMAIL:1466519819@qq.com
转载请注明来源: 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