SSO(单点登录) in Action.doc

SSO(Single Sign-on) in Action 1. SSO 原理浅谈 SSO 是一个非常大的主题，我对这个主题有着深深的感受，自从广州 UserGroup 的论坛成立以来，无数网友都在尝试使用开源的 CAS ， Kerberos 也提供另外一种方式的 SSO ，即基于 Windows 域的 SSO ，还有就是从 2005 年开始一直兴旺不衰的 SAML 。 如果将这些免费的 SSO 解决方案与商业的 Tivoli 或 Siteminder 或 RSA Secure SSO 产品做对比，差距是存在的。毕竟，商业产品的安全性和用户体验都是无与伦比的，我们现在提到的 SSO ，仅仅是 Web SSO ，即 Web-SSO 是体现在客户端；另外一种 SSO 是桌面 SSO ，例如，只需要作为 Administrator 登录一次 windows 2000 ，我便能够在使用 MSN/QQ 的时候免去登录的环节 ( 注意，这不是用客户端软件的密码记忆功能 ) ，是一种代理用户输入密码的功能。因此，桌面 SSO 是体现在 OS 级别上。 今天，当我们提起 SSO 的时候，我们通常是指 Web SSO ，它的主要特点是， SSO 应用之间走 Web 协议 ( 如 HTTP/SSL) ，并且 SSO 都只有一个登录入口。 简单的 SSO 的体系中，会有下面三种角色： 1、User（多个） 2、Web应用（多个） 3、SSO认证中心（1个） 虽然 SSO 实现模式千奇百怪，但万变不离其宗： Web应用不处理 User 的登录，否则就是多点登陆了，所有的登录都在 SSO 认证中心进行。 SSO 认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是张三 / 李四。 SSO 认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确性的判断会通过某种方法告之Web应用，而且判断结果必须被 Web 应用信任。 2. CAS 的基本原理 CAS(Central Authentication Service) 是Yale大学发起的一个开源项目，据统计，大概每 10 个采用开源构建Web SSO的Java项目，就有8个使用CAS。对这些统计，我虽然不以为然，但有一点可以肯定的是，CAS是我认为最简单实效，而且足够安全的SSO选择。 本节主要分析CAS的安全性，以及为什么CAS被这样设计，带着少许密码学的基础知识，我希望有助于读者对CAS的协议有更深层次的理解。 2.1 CAS 的结构体系 从结构体系看，CAS 包含两部分： CAS Server CAS Server负责完成对用户的认证工作，CAS Server需要独立部署，有不止一种CAS Server的实现，Yale CAS Server和ESUP CAS Server都是很不错的选择。 CAS Server会处理用户名/密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式，CAS均提供一种灵活但同一的接口/实现分离的方式，CAS究竟是用何种认证方式，跟CAS协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。 CAS Client CAS Client负责部署在客户端（注意，我是指 Web 应用），原则上，CAS Client的部署意味着，当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的Credentials，而是重定向到CAS Server进行认证。 目前，CAS Client支持（某些在完善中）非常多的客户端，包括Java、.Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBScript等客户端，几乎可以这样说，CAS协议能够适合任何语言编写的客户端应用。 2.2 CAS 协议 剖析协议就像剖析设计模式，有些时候，协议让人摸不着头脑。CAS的代理模式要相对复杂一些，它引入了一些新的概念，我希望能够在这里描述一下其原理，有助于读者在配置和调试CAS SSO有更清晰的思路。 如果没记错，CAS协议应该是由 Drew Mazurek 负责可开发的，从CAS v1到现在的 CAS v3，整个协议的基础思想都是基于 Kerberos 的票据方式。 CAS v1非常原始，传送一个用户名居然是”yes\ndavid.turing”的方式，CAS v2开始使用了XML规范，大大增强了可扩展性，CAS v3开始使用AOP技术，让Spring爱好者可以轻松配置CAS Server到现有的应用环境中。 CAS是通过TGT(Ticket Granting Ticket)来获取ST(Service Ti