SSO单点登录的研究

一、单点登录的概述

      单点登录（Single Sign On），简称为 SSO，SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 用以解决同一公司不同子产品之间身份认证问题，不同系统之间只需要登录一次即可。

二、单点登录的要求

　　（1）统一的登录入口

　　（2）唯一的用户名和密码

　　（3）安全的密码管理

　　（4）对原有的系统影响小

　　（5）不降低原有系统的安全等级

三、单点登录的几种实现方式  

   （1）Session共享方式

    1、共享Cookie方式

      实现方式：

　　　　Ø 设置Cookie的路径为setPath("/").即Tomcat的目录下都有效

　　　　Ø 设置Cookie的域setDomain(“.itcast.com”);即bbs.itcast.com,mail.itcast.com有效。

　　　　Ø 设置Cookie的时间。

　　　　Ø 使用Filter自动登录。

      缺点：1、存储在客户端cookie不安全，2、cookie不能跨域

 

    2、服务器间Session同步

       实现方式：使用主-从服务器的架构，当用户在主服务器上登录后，通过脚本或者守护进程的方式，将session信息传递到各个从服务器中，这样，用户访问其它的从服务器时，就可以读session信息。

       缺点：速度慢、不稳定等，另外，如果session信息传递是主->从单向的，会有一些风险，比如主服务器down了，其它服务器无法获得session信息。

 

    3、使用集群统一管理Session

        提供一个群集保存session共享信息。其他应用统统把自己的session信息存放到session集群服务器组。当应用系统需要session信息的时候直接到session群集服务器上读取。

        实现方式：以Memcache来实现Session共享的方式目前比较流行的有两种实现方案。

                    Ø 使用Filter方式

                    Ø memcached-session-manager（MSM）

        优点：开发者不用考虑session共享的问题了,可以专注于程序开发，像正常使用session那样使用就完事了。不用显示编写代码，只需要对服务器进行配置即可使用。

        缺点：如果你想改变session策略的话，必须重新部署每个服务器的servlet容器

 

    4、Session持久化到数据库

      这种共享session的方式即将session信息存入数据库中，其它应用可以从数据库中查出session信息。目前采用这种方案时所使用的数据库一般为mysql。

      缺点：

                （1）session的并发读写在数据库中完成，对mysql的性能要求比较高。

                （2）需要定时从数据库表中更新和删除session 信息， 增加了工作量

   （2）基于OpenID的单点登录

    (3)  独立的单点登录系统的设计

    (4) CAS（Central Authentication Service）

　 CAS（Central Authentication Service） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。  

    支持多种协议 Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。  

    支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates等。

    支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

   

    CAS原理：

            

　　1、CAS-Client（客户端）

     　　CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

　   2、CAS-Server（服务端）

 　　    CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 。

  相关概念：

      TGT（Ticket Grangting Ticket）

          TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie（叫TGC）， 写入浏览器，同时生成一个TGT对象，放入自己的缓  　　　　  存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查 询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。

      ST（Service Ticket）

          ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在 

          TGT， 则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

     TGC （Ticket-granting cookie）

         存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CAS Server用来明确用户身份的凭证。

   思考：

         1、 CAS如何告诉 Web Application当前访问用户究竟是不是已通过认证的用户？

         参考答案：根据TGC中的ID去判断TGT是否存在。如果存在则不用再次登录。

         2、 CAS如何和所有的 Web  Application应用建立一种信任关系（单点信任）？

        参考答案：根据TGT的令牌ST去和cas服务建立信任。

         3、如何维护各个应用的Session过期时间的一致性？

        参考答案：根据TGT的过期时间统一处理。CAS上的TGT过期了。会主动推送给注册上来的WEb APPLICATION。使得Web退出。

         4、如何实时的更新TGT的过期时间？

        参考答案：客户端收到WEB请求后。会每隔一段时间去刷新CAS上的TGT时间。使得TGT的过期时间得到更新。