JAVA和PHP版CAS客户端集成
一、背景
随着公司的不断的发展壮大和公司信息的建设逐步完善，公司内部系统也在不断的增加，为避免公司员工因系统过多造成账号密码混乱或忘记密码情况。公司决定将公司内部系统进行统一登录管理。通过CAS实现公司内部业务系统，用户只需登录一次就可以访问公司所有内部系统的单点登录。
二、使用范围
公司内部系统所有开发人员、产品部产品设计人员、测试部测试人员。
三、CAS简介
CAS （ Central Authentication Service ） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。
四、CAS特性
1、 开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支持多种认证机制： ActiveDirectory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
3、 安全策略：使用票据（ Ticket ）来实现支持的认证协议；
4、 支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）；
5、 提供高可用性：通过把认证过的状态数据存储在TicketRegistry 组件中，这些组件有很多支持分布式环境的实现， 如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。
五、CAS原理和协议
（一）基础模式
基础模式 SSO 访问流程主要有以下步骤：
1. 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
2. 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
3. 用户认证：用户身份认证。
4. 发放票据： SSO 服务器会产生一个随机的 Service Ticket 。
5. 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
6. 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。
下面是 CAS 最基本的协议过程：
如 上图： CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同 时， CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 ServiceTicket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） , 并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向 的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的（使用 HttpsURLConnection ）。
CAS请求认证时序图如下：
（二）代理模式
该模式形式为用户访问 App1 ， App1 又依赖于 App2 来获取一些信息，如： User -->App1 -->App2。 这 种情况下，假设 App2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 IE 窗口不停地 闪动 ) ， CAS引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。 代 理的前提是需要 CAS Client 拥有用户的身份信息 ( 类似凭据 ) 。之前我们提到的TGC 是用户持有对自己身份信息的一种凭据，这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借TGC ， User 可以免去输入密码以获取访问其它服务的 Service Ticket ，所以，这里凭借 PGT ， Web应用可以代理用户去实现后端的认证，而 无需前端用户的参与。 下面为代理应用（ helloService ）获取 PGT 的过程：（注： PGTURL 用于表示一个 Proxy 服务，是一个回调链接； PGT 相当于代理证； PGTIOU 为取代理证的钥匙，用来与 PGT 做关联关系；）
如上面的 CAS Proxy 图所示， CAS Client 在基础协议之上，在验证 ST 时提供了一个额外的PGT URL( 而且是 SSL 的入口) 给 CAS Server ，使得 CAS Server 可以通过 PGT URL 提供一个 PGT 给CAS Client 。 CAS Client 拿到了PGT(PGTIOU-85 … ..ti2td) ，就可以通过 PGT 向后端 Web 应用进行认证。
下面是代理认证和提供服务的过程：
如 上图所示， Proxy 认证与普通的认证其实差别不大， Step1 ， 2 与基础模式的Step1,2 几乎一样，唯一不同的 是， Proxy 模式用的是 PGT 而不是 TGC ，是Proxy Ticket （ PT ）而不是 ServiceTicket 。
六、CAS客户端JAVA版本实现配置
（一）引入CAS客户端核心JAR包cas-client-core-3.3.3.jar。
（二）在项目的WEB.xml文件中添加
org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter
org.jasig.cas.client.util.HttpServletRequestWrapperFilter
（三）单点登录配置完后客户端接收单点登录成功后的数据代码
AttributePrincipalprincipal = (AttributePrincipal) request.getUserPrincipal();
loginname=principal.getName();
七、CAS客户端PHP版本实现配置
（一） 引入CAS客户端文件phpCASClient文件夹下的CAS文件夹和cas.php文件。
下载地址：http://download.csdn.net/download/xiangyuanhong08/10044448
（二） 参考phpCASClient文件夹下的login.php页面修改系统登录处理页面。
通过phpCAS::getUser();获取CAS登录成功后的登录用户的账号，然后根据账号验证是否可以登录子系统。