Atitit. 单点登录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地址中看起来很别扭。