SSO 原理浅谈

SSO原理浅谈

SSO是一个非常大的主题，我对这个主题有着深深的感受，自从广州UserGroup的论坛成立以来，无数网友都在尝试使用开源的CAS，Kerberos也提供另外一种方式的SSO，即基于Windows域的SSO，还有就是从2005年开始一直兴旺不衰的SAML。

如果将这些免费的SSO解决方案与商业的Tivoli或Siteminder或RSA Secure SSO产品做对比，差距是存在的。毕竟，商业产品的安全性和用户体验都是无与伦比的，我们现在提到的SSO，仅仅是Web SSO，即Web-SSO是体现在客户端；另外一种SSO是桌面SSO，例如，只需要作为Administrator登录一次windows2000，我便能够在使用MSN/QQ的时候免去登录的环节(注意，这不是用客户端软件的密码记忆功能)，是一种代理用户输入密码的功能。因此，桌面SSO是体现在OS级别上。

今天，当我们提起SSO的时候，我们通常是指Web SSO，它的主要特点是，SSO应用之间走Web协议(如HTTP/SSL)，并且SSO都只有一个登录入口。

简单的SSO的体系中，会有下面三种角色：

1，User（多个）

2，Web应用（多个）

3，SSO认证中心（1个）

虽然SSO实现模式千奇百怪，但万变不离其宗：

l Web应用不处理User的登录，否则就是多点登陆了，所有的登录都在SSO认证中心进行。l SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是张三/李四。

l SSO认证中心和所有的Web应用建立一种信任关系，SSO认证中心对用户身份正确性的判断会通过某种方法告之Web应用，而且判断结果必须被Web应用信任。

2.CAS的基本原理

CAS(Central Authentication Service)是Yale大学发起的一个开源项目，据统计，大概每10个采用开源构建Web SSO的Java项目，就有8个使用CAS。对这些统计，我虽然不以为然，但有一点可以肯定的是，CAS是我认为最简单实效，而且足够安全的SSO 选择。

本节主要分析CAS的安全性，以及为什么CAS被这样设计，带着少许密码学的基础知识，我希望有助于读者对CAS的协议有更深层次的理解。

2.1CAS的结构体系

从结构体系看，CAS包含两部分：

l CAS Server

CAS Server负责完成对用户的认证工作，CAS Server需要独立部署，有不止一种CAS Server的实现，Yale CAS Server和ESUP CAS Server都是很不错的选择。

CAS Server会处理用户名/密码等凭证(Credentials)，它可能会到数据库检索一条用户帐号信息，也可能在XML文件中检索用户密码，对这种方式，CAS均提供一种灵活但同一的接口/实现分离的方式，CAS究竟是用何种认证方式，跟CAS协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。

l 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.2CAS协议

剖析协议就像剖析设计模式，有些时候，协议让人摸不着头脑。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 Ticket)，通过ST来访问服务，而CAS也有对应TGT，ST的实体，而且他们在保护TGT的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。

下面，我们看看CAS的基本协议框架：

2.1.1基础协议

CAS基础模式

上图是一个最基础的CAS协议，CAS Client以Filter方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求，同时，CAS Client会分析HTTP请求中是否包请求Service Ticket(上图中的Ticket)，如果没有，则说明该用户是没有经过认证的，于是，CAS Client会重定向用户请求到CAS Server（Step2）。Step3是用户认证

过程，如果用户提供了正确的Credentials，CAS Server会产生一个随机的Service

Ticket，然后，缓存该Ticket，并且重定向用户到CAS Client（附带刚才产生的Service Ticket），Service Ticket是不可以伪造的，最后，Step5和Step6是CAS Client和CAS Server之间完成了一个对用户的身份核实，用Ticket查到Username，因为Ticket 是CAS Server产生的，因此，所以CAS Server的判断是毋庸置疑的。

该协议完成了一个很简单的任务，就是User(david.turing)打开IE，直接访问helloservice应用，它被立即重定向到CAS Server进行认证，User可能感觉到浏览器在helloservcie和casserver之间重定向，但User是看不到，CAS Client和CAS Server 相互间的Service Ticket核实(Validation)过程。当CAS Server告知CAS Client用户Service Ticket对应确凿身份，CAS Client才会对当前Request的用户进行服务。

2.2.2CAS如何实现SSO

当我们的Web时代还处于初级阶段的时候，SSO是通过共享cookies来实现，比如，下面三个域名要做SSO：

如果通过CAS来集成这三个应用，那么，这三个域名都要做一些域名映射，

因为是同一个域，所以每个站点都能够共享基于的cookies。这种方法原始，不灵活而且有不少安全隐患，已经被抛弃了。

CAS可以很简单的实现跨域的SSO，因为，单点被控制在CAS Server，用户最有价值的TGC-Cookie只是跟CAS Server相关，CAS Server就只有一个，因此，解决了

cookies不能跨域的问题。

回到CAS的基础协议图，当Step3完成之后，CAS Server会向User发送一个Ticket granting cookie(TGC)给User的浏览器，这个Cookie就类似Kerberos的

TGT，下次当用户被Helloservice2重定向到CAS Server的时候，CAS Server会主动Get到这个TGC cookie，然后做下面的事情：

1，如果User的持有TGC且其还没失效，那么就走基础协议图的Step4，达到了SSO的效果。

2，如果TGC失效，那么用户还是要重新认证(走基础协议图的Step3)。

2.2.2CAS的代理模式

模式1已经能够满足大部分简单的SSO应用，现在，我们探讨一种更复杂的情况，即用户访问helloservice，helloservice又依赖于helloservice2来获取一些信息，如同：Useràhelloserviceàhelloservice2

这种情况下，假设helloservice2也是需要对User进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致User的IE窗口不停地闪动)，CAS引入了一种

Proxy认证机制，即CAS Client可以代理用户去访问其它Web应用。

代理的前提是需要CAS Client拥有用户的身份信息(类似凭据)。与其说之前我们提到的TGC是用户持有对自己身份信息的一种凭据，则这里的PGT就是CAS Client端持有的对用户身份信息的一种凭据。凭借TGC，User可以免去输入密码以获取访问其它服务的Service Ticket，所以，这里，凭借PGT，Web应用可以代理用户去实现后端的认证，而无需前端用户的参与。