CAS实现单点登陆理解

CAS

　　是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登陆解决方法（属于 Web SSO ），CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。

SSO

　　单点登陆（ Single Sign-On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只须要 登陆一次 就能够访问全部相互信任的应用系统。

　　通常 SSO 体系主要角色有三种：

　　　　一、 User （多个）

　　　　二、 Web 应用（多个）

　　　　三、 SSO 认证中心（ 1 个 ）

　　SSO 实现模式通常包括如下三个原则：

　　　　一、   全部的认证登陆都在 SSO 认证中心进行；

　　　　二、   SSO 认证中心经过一些方法来告诉 Web 应用当前访问用户到底是不是已经过认证的用户；

　　　　三、   SSO 认证中心和全部的 Web 应用创建一种信任关系，也就是说 web 应用必须信任认证中心。（单点信任）

　　SSO 的主要实现方式有:　　

　　一、   共享 cookies

　　　　　　基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域           问题，虽然 cookies 自己不跨域，但能够利用它实现跨域的 SSO 。如：代理、暴露 SSO 令牌值等。

　　　　　　缺点：不灵活并且有很多安全隐患，已经被抛弃。

　　二、   Broker-based( 基于经纪人 )

　　　　　　这种技术的特色就是，有一个集中的认证和用户账号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减小了管理的代价，并为认证提供            一个公共和独立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （凭证库思想 ) 等。 Kerberos是由麻省理工大学发明的安全认证服务，已经                                     被 UNIX 和 Windows 做为默认的安全认证服务集成进操做系统。

　　三、   Agent-based （基于代理人）

                   在这种解决方案中，有一个自动地为不一样的应用程序认证用户身份的代理程序。这个代理程序须要设计有不一样的功能。好比，它可使用口令表或加密密钥来自动地将            认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个 " 翻译 " 。例如 SSH 等。

      四、   Token-based

                 例如 SecureID,WebID ，如今被普遍使用的口令认证，好比 FTP 、邮件服务器的登陆认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

      五、   基于网关

      六、   基于 SAML

               SAML(Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO ，并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现                        了 SAML 规范。

CAS的基本原理

　　从结构体系看， CAS 包括两部分： CAS Server 和 CAS Client 。

CAS Server

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

CAS Client

　　负责处理对客户端受保护资源的访问请求，须要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用再也不接受任何的用户名密码等 Credentials ）。

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

理解

CAS 的 SSO 实现方式可简化理解为： 1 个 Cookie 和 N 个 Session 。 CAS Server 建立 cookie，在全部应用认证时使用，各应用经过建立各自的 Session 来标识用户是否已登陆。

用户在一个应用验证经过后，之后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在 session 里读取到用户信息，因此就不会去 CAS Server 认证。若是在此浏览器里访问别的 web 应用时，客户端应用中的过滤器在 session 里读取不到用户信息，就会去 CAS Server 的 login 接口认证，但这时CAS Server 会读取到浏览器传来的 cookie （ TGC ），因此 CAS Server 不会要求用户去登陆页面登陆，只是会根据 service 参数生成一个 Ticket ，而后再和 web 应用作一个验证 ticket 的交互而已。

CAS搭建过程参考：http://www.cnblogs.com/lr393993507/p/5231432.html