(SSO解决方案和技术路线.docVIP

CAS配置手册 SSO原理浅谈 SSO?是一个非常大的主题，无数网友都在尝试使用开源的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应用信任。 CAS基本原理 CAS(Central Authentication Service)是Yale大学发起的一个开源项目，据统计，大概每10个采用开源构建Web SSO的Java项目，就有8个使用CAS?。对这些统计，我虽然不以为然，但有一点可以肯定的是，CAS是我认为最简单实效，而且足够安全的SSO选择。 本节主要分析?CAS?的安全性，以及为什么?CAS?被这样设计，带着少许密码学的基础知识，我希望有助于读者对?CAS?的协议有更深层次的理解。 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?协议能够适合任何语言编写的客户端应用。 CAS协议 剖析协议就像剖析设计模式，有些时候，协议让人摸不着头脑。?CAS?的代理模式要相对复杂一些，它引入了一些新的概念，我希望能够在这里描述一下其原理，有助于读者在配置和调试CAS SSO有更清晰的思路。 如果没记错，CAS协议应该是由Drew Mazurek负责可开发的，从CAS v1到现在的CAS v3，整个协议的基础思想都是基于Kerberos的票据方式。 ??CAS v1非常原始，传送一个用户名居然是 ”yesndavid.turing” 的方式，CAS v2开始使用了XML规范，大大增强了可扩展性，CAS v3开始使用AOP技术，让?Spring?爱好者可以轻松配置CAS Server到现有的应用环境中。 CAS是通过TGT(Ticket Granting Ticket)来获取ST(Service Ticket)?，通过ST来访问服务，而CAS也有对应TGT，ST的实体，而且他们在保护TGT的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。 ??下面，我们看看?CAS?的基本协议