统一身份认证(CAS)简单说明与设计方案

统一身份认证 统一身份认证 CAS 简单说明与设计方案 转 简单说明与设计方案 转 1 单点登录概述单点登录概述 所谓单点登录 SSO 只当企业用户同时访问多个不同 类型的 应用时 他们只需要提供自身的用户凭证信息 比如用户名 密码 一次 仅仅一次 SSO 解决方案 比如 CAS 负责统一认证用户 如果需要 SSO 也可以完成用户的授权处理 可以看出 当企业用户在不同的应用间切换时 他们不用再 重复地输入自身的用户凭证了 在实施 SSO 后 所用的认证操作都将交给 SSO 认证中心 现有的 SSO 解决方案非常多 比如微软的 MSN Passport 便是典 型的 SSO 解决方案 各 Java EE 容器都提供了自身的专有 SSO 能力 2 CAS 的总体架构的总体架构 1 CAS 简介简介 CAS 中央认证服务 是建立在非常开放的协议之上的企业级 SSO 解决方案 诞生于 2001 年 在 2002 年发布了 CAS2 0 协议 这一新的协议提供了 Proxy 代理 能力 此时的 CAS2 0 支持多层 SSO 能力 到 2005 年 CAS 成为了 JA SIG 旗下的重要子项目 由于 CAS2 0 版本的可扩展能力不是非常完 美 而且他的架构设计也不是很卓越 为了使得 CAS 能够适用于更多场合 JA SIG 打算开发出同时遵循 CAS1 0 和 CAS2 0 协议的 CAS3 X 版本 现在的 CAS3 全面拥抱 Spring 技术 比如 Spring DI 容器和 AOP 技术 Spring Web MVC Spring Web Flow Spring Ldap Template 等 通常 CAS3 由两部分内容构成 CAS3 服务器和 CAS 客户端 由于 CAS2 0 协议借助于 XML 数据结构与客户进行交互 因此开发者可以使用各种语言编写 的 CAS3 客户与服务器进行通信 CAS3 服务器采用纯 Java 开发而成 它要求目标运行环境实现了 Servlet2 4 规范 提供 Java SE 1 4 支持 如果宿主 CAS3 服务器的目标 Java EE 容器仅仅实现了 Servlet2 3 规范 则在对 CAS3 服务器进行少量的改造后 CAS3 也能运行其中 运行时 CAS3 服务器仅仅是一个简单的 Web 应用 使用者只需要将 cas war 直接丢到目标 Java EE 容器后 即完成了 CAS3 的部署 2 CAS 词汇概念词汇概念 TGC ticket granting cookie 受权的票据证明 KDC Key Distribution Center 密钥发放中心 Service ticket ST 服务票据 由 KDC 的 TGS 发放 任何一台 Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用 Applications 如果能正确接收 Service Ticket 说明在 CASClient CASServer 之间的信任关系已经被正确建立起来 通常为一张数字加密的证书 Ticket Granting tieckt TGT 票据授权票据 由 KDC 的 AS 发放 即获取这样一张票据后 以后申请各种其他服务票据 ST 便不必再向 KDC 提 交身份认证信息 准确术语是 Credentials authentication service AS 认证用服务 索取 Crendential 发放 TGT ticket granting service TGS 票据授权服务 索取 TGT 发放 ST 3 CAS 工作原理工作原理 CAS 的单点登录的认证过程 所用应用服务器受到应用请求后 检查 ST 和 TGT 如果没有或不对 转到 CAS 认证服务器登录页面 通过安全认证后得到 ST 和 TGT 再重新定向到相关应用服务器 在回话生命周期之内如果再定向到别的应用 将出示 ST 和 TGT 进行认证 注意 取得 TGT 的过程是通过 SSL 安全协议的 如果通俗形象地说就是 相当于用户要去游乐场 首先要在门口检查用户的身份 即 CHECK 用户的 ID 和 PASS 如果用户通过验证 游乐场的门卫 AS 即提供给用户一张门卡 TGT 这张卡片的用处就是告诉游乐场的各个场所 用户是通过正门进来 而不是后门偷爬进来的 并且也是获取进入场所一把钥匙 现在用户有张卡 但是这对用户来不重要 因为用户来游乐场不是为了拿这张卡的而是为了游览游乐项目 这时用户摩天楼 并想游玩 这时摩天轮的服务员 client 拦下用户 向用户要求摩天轮的 ST 票据 用户说用户只有一个门卡 TGT 那用户只要把 TGT 放在一旁的票据授权机 TGS 上刷一下 票据授权机 TGS 就根据用户现在所在的摩天轮 给用户一张摩天轮的票据 ST 这样用户有了摩天轮的票据 现在用户可以畅通无阻的进入摩天轮里游玩 了 当然如果用户玩完摩天轮后 想去游乐园的咖啡厅休息下 那用户一样只要带着那张门卡 TGT 到相应的咖啡厅的票据授权机 TGS 刷一下 得到咖啡厅 的票据 ST 就可以进入咖啡厅 当用户离开游乐场后 想用这张 TGT 去刷打的回家的费用 对不起 用户的 TGT 已经过期了 在用户离开游乐场那刻开始 用户的 TGT 就已经销毁了 3 CAS 的实现原理的实现原理 由于 CAS 是基于 Cookie 的服务 所以它使用了 Spring CookieGenerator 来生成相应 Cookie 下面的代码段摘自与 CAS 服务器的 WEB INF 中的 cas server xml 配置文件 一旦用户登录到 CAS 服务器后 可以借助于 URL 为 cas logout 的地址退出 并且这种 logout 结果将导致浏览器中已存储的 Cookie 被销毁掉 即销毁 CAS 与当前用户间已建立的信任关系 Web SSO 会话 1 AuthenticationHandler 认证处理器认证处理器 浏览项目的 web xml 可以发现如下内容 contextConfigLocation WEB INF applicationContext xml WEB INF deployerConfigContext acegi xml org jasig cas web init SafeContextLoaderListener SafeContextLoaderListener 实现了 SafeContextListener 它借助于 ContextLoader Listener 装载 Spring DI 容器 这样做的原因是因为 Spring 在通过 ContextLoaderLitener 启动时可能出现异常 造成整个 CAS 不能正常启动 经过 SafeContextLoaderListener 则在异常发生时 CAS 服务器也可以启动 在 deployerConfigContext xml 中 可以看到只定义了一个 Bean SimpleTestUsernamePasswordAuthenticationHandler 的作用是如果用户名与密码输入一样 则通过系统认证 这个是开发过程中常用的一个 handler 但是 在开发完毕后应该除去 AuthenticationManagerImpl 负责认证用户 比如一个 admin admin 用户是否合法就是它来验证的 AuthenticationManagerImpl 对象会借助于他引用的 credentialsToPr incipalResolvers 和 authenticationHandlers 集合完成用户的认证工作 Authentication Handlers 负责完成用户认证 而 credentialsToPrincipalResolvers 负责构建认证结果 其中 并不是 authenticationHa