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：

https://www.360docs.net/doc/846217234.html,

https://www.360docs.net/doc/846217234.html,

https://www.360docs.net/doc/846217234.html,

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

https://www.360docs.net/doc/846217234.html,

https://www.360docs.net/doc/846217234.html,

https://www.360docs.net/doc/846217234.html,

因为是同一个域，所以每个站点都能够共享基于https://www.360docs.net/doc/846217234.html,的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应用可以代理用户去实现后端的认证，而无需前端用户的参与。

如下面的CAS Proxy图所示，CAS Client在基础协议之上，提供了一个额外的PGT URL给CAS Server,于是，CAS Server可以通过PGT URL提供一个PGT给CAS Client。

初学者可能会对上图的PGT URL感到迷惑，或者会问，为什么要这么麻烦，要通过一个额外的URL(而且是SSL的入口)去传递PGT？如果直接在Step6返回，则连用来做对应关系的PGTIOU都可以省掉。PGTIOU设计是从安全性考虑的，非常必要，CAS协议安全性问题我会在后面一节介绍。

于是，CAS Client拿到了PGT(PGTIOU-85…..ti2td)，这个PGT跟TGC同样地关键，CAS Client可以通过PGT向后端Web应用进行认证。如下图所示，Proxy认证与普通的认证其实差别不大，Step1,2与基础模式的Step1,2几乎一样，唯一不同的是，Proxy模式用的是PGT而不是TGC，是Proxy Ticket（PT）而不是Service Ticket。

最终的结果是，helloservice2明白helloservice所代理的客户是David.Turing同学，同时，根据本地策略，helloservice2有义务为PGTURL=http://helloservice/proxy服务(PGTURL用于表示一个Proxy服务)，于是它传递数据给helloservice。这样，helloservice便完成一个代理者的角色，协助User返回他想要的数据。

代理认证模式非常有用，它也是CAS协议v2的一个最大的变化，这种模式非常适合在复杂的业务领域中应用SSO。因为，以前我们实施SSO的时候，都是假定以IE User为SSO 的访问者，忽视了业务系统作为SSO的访问者角色。

2.3CAS安全性

CAS的安全性是一个非常重要的Topic。CAS从v1到v3，都很依赖于SSL，它假定了这样一个事实，用户在一个非常不安全的网络环境中使用SSO，Hacker的Sniffer 会很容易抓住所有的Http Traffic，包括通过Http传送的密码甚至Ticket票据。

2.3.1TGC/PGT安全性

对于一个CAS用户来说，最重要是要保护它的TGC，如果TGC不慎被CAS Server 以外的实体获得，Hacker能够找到该TGC，然后冒充CAS用户访问所有授权资源。

SSO的安全性问题比普通应用的安全性还要严重，因为SSO存在一种门槛效应。以前即使Hacker能够截获用户在Web应用A的密码，它也未必能知道用户在Web应用B

的密码，但SSO让Hacker只需要截获TGC(突破了门槛)，即能访问所有与该用户相关的所有应用系统。

PGT跟TGC的角色是一样的，如果被Hacker获得，后果可想而知。

从基础模式可以看出，TGC是CAS Server通过SSL方式发送给终端用户，因此，要截取TGC难度非常大，从而确保CAS的安全性。

因此，某些人认为CAS可以不使用SSL的想法需要更正一下，CAS的传输安全性仅仅依赖与SSL。

跟Kerberos一样TGT，TGC也有自己的存活周期。下面是CAS的web.xml中，通过grantingTimeout来设置CAS TGC存活周期的参数，参数默认是120分钟，在合适的范围内设置最小值，太短，会影响SSO体验，太长，会增加安全性风险。

SSO Server是基于CGI(Java Fans更多会选择CAS)，对C/C++的群体应该是一个不错的选择。CoSign协议的UseCase跟CAS很相似，CoSign的客户端虽然也支持

J2EE/Apache/MSAPI(IIS)，但它的Server端使用C来编写，影响了在Java群体中的使用。CoSign是一个不错的选择，可能是因为本人比较喜欢Kerberos Model的原因吧。

3.3WebAuth

WebAuth是一种早期的SSO方案，它的WebServer是用perl来编写的，客户端支持Apache，C++，Perl等，当然，WebAuth推出的时候，Java并不是很流行，现在，要让WebAuth跟众多的Java产品结合不是一件容易的事情。

WebAuth的协议适用了Share Secret，即SSO Server和SSO Client之间存在一个对称密钥(symmetric key)。SSO Server和SSO Client之间的信任关系通过这个Key来保障。

上图中展示了一个WebAuth的基本模式，Client就是浏览器用户，Generic Web Service是SSO Client，WebAuth Service和Auth Service可以看作是SSO Server。

当浏览器发起一个对Web应用的访问请求时，这个请求未授权，因此被重定向到WebAuth Service进行认证，认证的结果是获得一个经过symmetric key加密的token，而这个Token只有Generic Web Service能够解密，因此，Web应用能够知道浏览器用户的身份。使用对称加密来共享用户身份信息存在一定的安全隐患，首先是WebAuth Service 如何保护这些对称密钥(保护密钥安全本身是一件很困难的事情)，一旦这些对称密钥被泄漏了，Token就可以被随意篡改。另外，由于Token本身是基于Cookie方式发送，因此，只要Hacker能够复制这个Token，他同样可以访问其他应用。

如果不考虑安全性问题，WebAuth的效率应该比其他SSO方案要高，因为它的协议没有CAS/CoSign那么复杂，WebAuth中，SSO Server不需要跟SSO Client通讯以确认用户的身份，用户的身份就放在Token中。

4.SAML

SAML是OASIS制定的一种安全性断言标记语言，它用于在复杂的环境下交换用户的身份识别信息。在SAML诞生之前，如果想在Websphere、Weblogic和SunONE等之间

实现SSO，我们必须分别实现一个适配层，来达成一种相互理解的协议，在该协议上，产品能够共享各自的用户认证/授权信息。SAML诞生之后，我们免去了这种烦恼。可以预计，将来大部分产品都可以实现基于SAML的联邦服务。

事实伤，SAML已经在很多商业/开源产品中得到实现，包括：

l IBM Tivoli Access Manager

l BEA Weblogic

l Oblix NetPoint

l SunONE Identity Server

l Baltimore,SelectAccess

l Entegrity Solutions AssureAccess

l Internet2OpenSAML

l Yale CAS3

l Netegrity SiteMinder

l Sigaba Secure Messaging Solutions

l RSA Security ClearTrust

l VeriSign Trust Integration Toolkit

l Entrust GetAccess7

SAML背后是强大的商业联盟和开源联盟，尽管Microsoft迟迟未能在SAML2.0观点上达成一致，但它也正努力跟进SAML标准化过程，由此可见SAML协议已经是势在必行。4.1SAML的基本概念

理解SAML的概念很重要，个人认为SAML协议的原理跟CAS/Kerberos很类似，理解上不存在困难，但SAML引入了一些新的概念名词，因此要先把握清楚这些概念。

断言，这个在SAML的”A”，是整个SAML协议中出现的最多的字眼，我们可以将断言看作是一种判断，并且我们相信这种判断，因此，做出断言的一方必须被信赖。校验来自断言方的断言必须通过一些手段，比如数字签名，以确保断言的确实来自断言方。

SAML目标是让多个应用间实现联邦身份(Identity Federation)，提起联邦，大家可以想象一下欧盟，欧盟国家之间的公民都具有一个联邦身份，比如Peter是法国公民，John是比利时公民，这两个公民的身份都能够互相被共享，恰好，张三是一个中国公民，但他能像Peter 和Jhhn那样随意进入欧盟国家，显然不能，因为它不具有欧盟联邦身份。

理解了联邦的概念，我们就可以回到SAML上，SAML解决了联邦环境中如何识别身份信息共享的标准化问题，比如，法国的Peter进入比利时，他如何证明自己的身份呢？

SAML就是为了解决这个问题。

在联邦环境中，通常有下面的3种实体：

l Subject(主题)：Subject是SAML实体中的第一个重要的概念，Subject包括了User、Entity、Workstation等能够象征一个参与信息交换的实体。

l Relying Party(信任方)：SAML中的Service Provider角色，也就是提供服务的一方。

l Asserting Party(断言方)：SAML中的Identity Provider角色，用于提供对主题的身份信息的正确的断言，类似一个公证机构。

我们看看联邦环境的一个场景：

假设有一个Peter(Subject)的法国公民，他需要访问比利时(Service Provider)，他在比利时机场被要求提供身份信息，Peter提供了欧盟(Federation)的通行证件，随即，这个通行证件在比利时机场被审核，或通过计算机送到欧盟身份认证中心(Identity Provider)，

该中心有一个由所有欧盟国家共同建立的公民数据库，中心审核了Peter的身份信息，并断言“Yes，He is Peter From France”，于是，Peter得到礼貌的回应“欢迎光临比利时”。

如果你将欧盟看作是一个联邦环境，你会发现上面的场景跟在联邦环境应用SAML很相似。

在联邦环境下，任何需要授权访问的服务都需要知道服务请求方的身份主题信息(Who are you)，服务提供方(Service Provider)不负责审核用户的身份信息，但它依赖于1个甚至多个Identity Provider来完成此任务，见下图。

1个Idnetity Provider可以被多个Service Provider共享，当然，共享的前提是建立信任关系(即Service Provider要信任Idnetity Provider)，就好比如，如果比利时(Service Provider)需要开放对欧盟国家成员访问，它信任欧盟的Idnetity Provider，它信任欧盟的Idnetity Provider的任何判断，包括”He is Peter From France”。至于是否让Peter入境，那是受权限策略的控制(注意SAML同样对Authorization断言做了标准化，此处，我们仅仅关注Authentication)。

4.2SAML的2种典型模式

在协议的角度，SAML原理非常类似CAS和Kerberos，CAS协议依赖于CAS Server，Kerberos依赖于KDC，而SAML则依赖于Identity Provider。

根据Service Provider(以下简称SP)和Identity Provider(以下简称IDP)的交互方式，SAML可以分为以下几种模式：一种是SP拉方式，一种是IDP推方式。

在SAML中，最重要的环节是SP如何获取对Subject的断言，SP拉方式是SP主动到IDP去了解Subject的身份断言，而IDP推方式则是IDP主动把Subject的身份断言通过某种途径告诉SP。

2.2.1SAML的POST/Artifact Bindings方式（即SP拉方式）

该方式的主要特点是，SP获得客户端的凭证(是IDP对Subject的一种身份认可)之后，主动请求IDP对Subject的凭证的断言。如下图所示：Subject是根据凭证去访问SP的。凭证代表了Subject的身份，它类似于“来自IDP证明：我就是Peter，法国公民”。

现在，让我们看看SP拉方式是如何进行的：

Subject访问SP的受保护资源，SP发现Subject的请求中没有包含任何的授权信息，于是它重定向用户访问IDP.

协议执行：

1，Subject向IDP请求凭证(方式是提交用户名/密码)

2，IDP通过验证Subject提供的信息，来确定是否提供凭证给Subject

3，假如Subject的验证信息正确，他将获取IDP的凭证以及将服务请求同时提交给SP。4，SP接受到Subject的凭证，它是提供服务之前必须验证次凭证，于是，它产生了一个SAML 请求，要求IDP对凭证断言

5，凭证是IDP产生的，它当然知道凭证的内容，于是它回应一个SAML断言给SP

6，SP信任IDP的SAML断言，它会根据断言结果确定是否为Subject提供服务。

4.2.1SAML的Redirect/POST Bindings方式(即IDP推方式)

该方式的主要特点是，IDP交给Subject的不是凭证，而是断言。

过程如下图所示：

1，Subject访问SP的授权服务，SP重定向Subject到IDP获取断言。

2，IDP会要求Subject提供能够证明它自己身份的手段(Password，X.509证书等)

3，Subject向IDP提供了自己的帐号密码。

4，IDP验证密码之后，会重订向Subject到原来的SP。

5，SP校验IDP的断言(注意，IDP会对自己的断言签名，SP信任IDP的证书，因此，通过校验签名，能够确信从Subject过来的断言确实来自IDP的断言)。

6，如果签名正确，SP将向Subject提供该服务。

4.3SAML的优势所在

SAML协议仍在不断的发展，SAML1.0,SAML1.1到现在的SAML2.0，都是IT商业巨头协商后，由OASIS发布的产物，另外，OASIS SAML实验室得到拥有美国政府GSA 的大力资助。

SAML在SOA中扮演了一个关键角色，由于用户要求将企业资源从原有的面向数据/接口转变为面向服务，而建立在众多Vendor产品下的服务存在这种种鸿沟，最大的鸿沟是如何识别身份，如何能够让网易163邮件的VIP用户享受免费参加Dev2dev广州UserGroup 的活动？

读者可能已经听闻很多身份管理软件，IBM Tivoli，SiteMinder，RSA SecureID等，虽然身份管理软件都非常强，但成本同时也很高。身份管理并不适合于那种构建是B2B之上的商业环境（联邦环境）。

但对用户来说，根本问题是，网易和Dev2dev是两个不同的公司/组织，它们都严格保护自己的用户身份信息，一般极少可能会共享身份数据，因此，做法是双方都提供一个服务入口，对身份信息做断言，例如只告诉Dev2dev该用户确实是网易的VIP用户。

SAML提供了一个安全标记规范，并且给出了一些的UseCase，这些usecase足以满足我们绝大部分的SSO需求。

我喜欢这种规范，很大原因是因为以前用SSO实在很累，配置要花去大半天时间，SAML 让这一切变得非常灵活简单，因为厂商一旦在其产品中提供SAML支持，我们就可以将其产品作为联邦服务纳入SSO环境。

我喜欢SAML的另一个原因是因为，它跟SOAP一样，不考虑传输协议，事实上，SAML 可以跟HTTP/SSL/JMS等任何传输协议捆绑。在SOA环境中，这个特性非常重要，因为我们已有的许多服务（来自各个不同IT Vendors）都可能有各自的传输协议，即如果在这种复杂的环境下实现SSO，传统Yale CAS已经无能为力，因为CAS SSO实现在HTTP/SSL 之上，只有SAML能够完成这项任务，因为它与传输协议无关。

最后，应该提一下，SAML是一种SSO标准而CAS是一种SSO的实现，从CAS的Roadmap可以看出，CAS很快会提供对其他SAML的支持。