单点登录技术(Single Sign On简称SSO)主要用于应用系统集成，实现所谓的“一次登录，多次漫游”，即用户只需要登录一次就可以无缝的切换访问其被授权允许访问的多个应用系统或者资源。
1.实现单点登录基本条件
单点登录技术主要基于Web。基于Web的SSO的实现机制是一个涉及用户浏览器、SSO客户端(Web应用)和SSO服务器3个角色相互交互的过程。要实现一个基于Web的SSO，至少要满足以下两个条件：
1)统一的用户身份认证系统。统一安全的用户认证系统是SS0的前提之一，用户认证系统通过安全信任机制实现各种环境下用户身份的认证。
2)应用系统与认证系统相互信任。用户认证系统对用户身份的认证能够传递给应用系统，应用系统信任该身份认证，完成用户请求调用。
2.用户认证策略
根据实现用户认证策略的不同，SSO认证技术一般分为以下三种：基于访问票据，基于Web请求代理以及基于密码代理。
1）基于访问票据的认证策略。其核心思想是在认证服务器和应用系统之间建立信任关系，主要采用访问票据（简称Ticket）模型维持这种信任关系。用户成功登录统一认证服务器后，便获得一个ticket凭证，该凭证是用户访问服务器所辖所有应用系统的通行证。目前比较流行的SSO解决方案如Kerberos、Liberty Alliance、Microsoft Passport都是基于访问票据的认证策略。
Kerberos由美国麻省理工大学于20世纪80年提出，是一种基于可信赖的第三方认证机制。Kerberos包含两个独立的逻辑部分：认证服务器和令牌服务器，它们构成了一个可信赖的第三方（即密钥分发中心，简称KDC)。KDC拥有一个密钥数据库，密钥用于证明实体的身份。KDC通过会话密钥保证通信的信息安全性。
Liberty Alliance协议基于SAML 标准，并与平台无关，具有开放性。其核心思想应用系统可以保留各自的用户认证机制，通过用户身份的对应关系实现单点登录。
Microsoft Passport是微软公司．Net技术的一个重要的组成部分，属于一种基于访问票据的集中式单点登录模式。用户账户信息集中存储于一个数据库中，当用户在任何一个微软授权的应用系统通过了身份认证，就获得所有应用系统的通行证。集中式的用户账户管理和认证为管理和应用方面代理便利，但是其安全性和稳定性成为此架构的敏感点，一旦认证服务器被攻击或宕机，势必会给用户带来极大的损失。
2）基于Web请求代理的认证策略。其基本思路通过统一的门户服务器来代理用户的Web请求，门户服务器统一处理用户的身份认证。基于此策略，当用户访问应用系统时，所有的Web请求首先被定向到门户服务器，门户服务器完成用户身份认证，然后把Web请求转向应用系统，并附加上用户身份信息。网页过滤器技术是Web请求重定向主要实现方式。
与基于访问票据的认证思想类似，基于Web请求代理的认证策略也必须建立门户服务器与应用系统之间的信任关系。但基于Web请求代理的认证策略实现机制简洁，结构灵活，对原有Web应用的改造较少。
3）基于密码代理的认证策略。门户服务器并不控制应用系统的用户认证，只是保管应用系统的用户账户信息，即代理保管用户在应用系统中的用户名和密码，用户在门户服务器通过认证之后，进入应用系统时，门户服务器自动完成应用系统登录。这种策略不用改变原有应用系统，适合于基于界面的集成方式，其实现机制更加灵活简易，成本更低。
综上所述，从实现SSO的角度来看，这三种认证策略基本一样，都是以一定的手段完成用户认证，让用户自由访问所需资源。从安全性、稳定性、灵活性、扩展性和成本来分析，这三种认证策略各有优缺点。在实际项目开发中，一般综合应用这三种认证策略。
3.CAS单点登录解决方案
CAS（Central Authentication Service，集中认证服务）认证协议是一个开源、基于Java、企业级的Web单点登录模型。CAS的优点很多：设计理念先进、体系结构合理、配置简单、客户端支持广泛、技术成熟等。
CAS模型的体系结构包括CAS服务器，CAS客户端和用户浏览器。CAS服务器是一个独立和集中的认证中心。
CAS服务器负责完成对用户的认证工作,需要独立部署,用于处理用户名/密码等凭证和应用系统电子票据的校验；CAS客户端负责处理对Web应用的访问请求，需要对用户进行身份认证时，将请求重定向到 CAS服务器进行认证。CAS 客户端与受保护的Web应用部署在一起，以Filter（过滤器）方式实现资源的访问保护；用户浏览器是用户访问Web应用系统的工具，是访问Web服务的客户端。
根据CAS认证模型，其认证过程涉及以下三种认证凭证（即所谓票据）。
一是服务票据ST（Service Ticket）。ST是用户访问某一个应用系统的凭证，ST是由CAS服务器在用户通过认证后生成，为保证安全性，ST具有使用一次即自动销毁的特点；
二是票据授权票据TGT（Ticket Granting Ticket）。用户通过CAS的身份认证，CAS服务器便给用户颁发一个TGT,代表用户具有门户的通行证；
三是票据授权Cookie TGC（Ticket Granting Cookie）。它是TGT的容器，用于在用户浏览器端存放TGT信息。TGC是实现单点登录的关键所在，通过传递TGC，CAS服务器能够直接判断用户身份的合法性，避免用户重复登录。用户浏览器关闭TGC即失效。
CAS基础协议过程如图1-1所示。
根据CAS基础协议图，CAS认证流程如下：
1)用户浏览器请求访问CAS客户端的Web应用，CAS客户端过滤从用户浏览器传来的每一个Web请求并分析请求中是否包含ST，如果没有包含，则说明该用户没有经过认证。
2) CAS客户端把Web请求重定向到CAS认证中心请求ST，并把Web请求的地址作为参数传递。
3)用户通过CAS服务器的认证，CAS服务器给该用户分发一个服务票据ST，然后重定向CAS客户端在步骤2中通过参数传递的地址，其中ST作为参数进行传递。同时，CAS服务器向经过认证的用户浏览器发送一个票据授权Cookie (TGC)，TGC相当于用户的通行证，避免重复认证。
4) CAS客户端把所持有的ST发到CAS服务器进行认证，认证过程对于用户浏览器是透明的。CAS服务器确认后返回该用户的身份信息；如果ST不正确，则返回错误信息并提示用户重新进行认证。
CAS 请求认证时序图如图1-2所示。
当用户浏览器再次访问同一个应用系统时，CAS客户端的过滤器会在Session里读取到用户信息（如果Session还没有失效），所以不会去CAS服务器认证。
当用户浏览器访问另一个应用系统时，CAS客户端的过滤器在session里读取不到用户信息，就会去CAS 服务器认证，这时CAS 服务器会主动获到TGC，如果用户浏览器持有TGC且其还未失效或者错误，那么不用要求用户去登录页面登录，只是会根据service参数生成一个ST，并直接发送ST并重定向，达到了 SSO 的效果；如果TGC失效，那么用户需要重新认证。
由此可见，CAS的SSO实现方式可简化理解为：1个Cookie和N个Session。CAS 服务器创建cookie，提供所有应用系统认证时使用，各应用系统通过创建各自的Session来标识用户是否已登录。
在CAS协议中，所有与CAS服务器的交互采用安全套接字 (SSL)协议，这保证了ST和TGC的信息安全。CAS协议工作过程中会有两次重定向的过程，CAS客户端与CAS服务器之间进行Ticket验证的过程对于用户是透明的。