SSO单点登陆技术总结

1、SSOSingle Sign On - sso单点登陆技术总结 作者：温德亮修订历史记录：*A - 增加 M - 修订 D - 删除变更版本号日期变更类型 （A*M*D）修改人摘要备注V0.12011-08-22A温德亮1 SSO解析SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录机制。它是目前比较流行的企业业务整合的解决方案之一。在市面流传深广并且技术非常流行，是重要门户网站、服务网站解决综合性客户验证，是一套非常成熟的解决方案。2 SSO实现机制

2、2.1 机制解释现今提起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 认证中心对用户身

3、份正确性的判断会通过某种方法告之 Web 应用，而且判断结果必须被 Web 应用信任。当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录。根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据ticket；用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。 要实现SSO，需要以下主要的功能：2.2 所有应用型系统共享身份认证 统一的认证系统是SSO的前

4、提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。而与SSO联合开发的这里的是Ldap进行开发。Ldap以后会介绍到。2.3 所有应用系统能够识别与提取Ticket信息要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。 另外： 1、单一的用户信息数据库并不是必须的，有许多系统不能将所有

5、的用户信息都集中存储，应该允许用户信息放置在不同的存储中，事实上，只要统一认证系统，统一ticket的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。 2、统一的认证系统并不是说只有单个的认证服务器 认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别3 WEB系统SSO实现原理用户在访问页面1的时候进行了登录，但是客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串，并且可以保存在浏览器中。当浏览

6、器访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。 为了完成一个简单的SSO的功能，需要两个部分的合作： 1、统一的身份认证服务。 2、修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。 很多

7、的网站都有用到SSO技术, 新浪的用户登录也是用到的SSO技术.4 总结SSO优点4.1 减少用户在不同系统中登陆耗费时间4.2 减少用户登陆出错的可能性4.3 实现安全的同时避免了处理和保存多套系统用户的认证信息4.4 减少了系统管理员工作量，减少增加、删除用户和修改用户权限时间4.5 增加用户安全性，避免用户帐号遗失4.6 系统管理员可以更好管理用户，包括可以通过直接诶禁止和删除用户来取消该用户对所有系统资源的访问权限与对系统资源的消耗5 实现SSO通用几种方式5.1 COOKIES实现基于cookies实现,需要注意如下几点:如果是基于两个域名之间传递sessionid的方法可能在win

8、dows中成立,在unix&linux中可能会出现问题;可以基于数据库实现;在安全性方面可能会作更多的考虑。另外,关于跨域问题,虽然cookies本身不跨域,但可以利用它实现跨域的SSO。 5.2 Kerberos实现 Broker-based(基于经纪人),例如Kerberos等;这种技术的特点就是,有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价,并为认证提供一个公共和独立的第三方。例如Kerberos,Sesame,IBM KryptoKnight(凭证库思想)等。Kerberos是由麻省理工大学发明的安全认证服务,当前版

9、本V5,已经被UNIX和Windows作为默认的安全认证服务集成进操作系统。 5.3 Agent-based实现 Agent-based(基于代理人)在这种解决方案中,有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如, 它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面,在服务器的认证系统和客户端认证方法之间充当一个翻译。例如SSH等。 5.4 Token-based实现Token-based,例如SecurID,WebID,现在被广泛使用的口令认证,比如FTP,邮件服务器的登录认证,这是一种简单易用的方式,实现一个口令在

10、多种应用当中使用。 5.5 AGENT AND BROKER-BASED实现 基于网关Agent and Broker-based,这里不作介绍。 5.6 CAS实现 基于安全断言标记语言(SAML)实现,SAML(Security Assertion Markup Language,安全断言标记语言)的出现大大简化了SSO,并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范。 CAS由耶鲁大学开发的单点登录系统(SSO,single sign-on),应用广泛,具有独立于平台的,易于理解,支持代理功能。现如今实现SSO技术都采用CAS技术的单点登录。如：当

11、用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统2的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。6 CAS 实现SSO单点登陆 6.1 CAS来源 CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目，据统计，大概每 10 个采用开源构建 Web SSO 的 Java 项目，就有 8 个使用 CAS 。对这些统计，我虽然不以为然，但有一点可以肯定的是， CAS 是我认为最简单

12、实效，而且足够安全的 SSO 选择。比起其他实现更适合。6.2 CAS 两种架构6.2.1 CAS SERVERCAS Server 负责完成对用户的认证工作， CAS Server 需要独立部署，有不止一种 CAS Server 的实现， Yale CAS Server 和 ESUP CAS Server 都是很不错的选择。CAS Server 会处理用户名 / 密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，对这种方式， CAS 均提供一种灵活但同一的接口 / 实现分离的方式， CAS 究竟是用何种认证方式，跟 CAS

13、协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。6.2.2 CAS ClientCAS Client 负责部署在客户端（注意，我是指 Web 应用），原则上， CAS Client 的部署意味着，当有对本地 Web 应用的受保护资源的访问请求，并且需要对请求方进行身份认证， Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。 目前， CAS Client 支持（某些在完善中）非常多的客户端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、

14、VBScript 等客户端，几乎可以这样说， CAS 协议能够适合任何语言编写的客户端应用。6.3 CAS 协议与实现剖析协议就像剖析设计模式，有些时候，协议让人摸不着头脑。 CAS 的代理模式要相对复杂一些，它引入了一些新的概念，我希望能够在这里描述一下其原理，有助于读者在配置和调试 CAS SSO 有更清晰的思路。CAS 协议应该是由 Drew Mazurek 负责可开发的从 CAS v1 到现在的 CAS v3 ，整个协议的基础思想都是基于 Kerberos 的票据方式。CAS v1 非常原始，传送一个用户名居然是 ”yesndavid.turing” 的方式， CAS v2 开始使用了

15、 XML 规范，大大增强了可扩展性， CAS v3 开始使用 AOP 技术，让 Spring 爱好者可以轻松配置 CAS Server 到现有的应用环境中。CAS 是通过 TGT(Ticket Granting Ticket) 来获取 ST(Service Ticket) ，通过 ST 来访问服务，而 CAS 也有对应 TGT ， ST 的实体，而且他们在保护 TGT 的方法上虽然有所区别，但是，最终都可以实现这样一个目的免去多次登录的麻烦。6.3.1 基础协议 上图是一个最基础的 CAS 协议， CAS Client 以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每

16、一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的，于是， CAS Client 会重定向用户请求到 CAS Server （ Step 2 ）。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 会产生一个随机的 Service Ticket ，然后，缓存该 Ticket ，并且重定向用户到 CAS Client （附带刚才产生的 Service Ticket ）， Service Ticket 是不可以伪造

17、的，最后， Step 5 和 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

18、 和 CAS Server 相互间的 Service Ticket 核实 (Validation) 过程。当 CAS Server 告知 CAS Client 用户 Service Ticket 对应确凿身份， CAS Client 才会对当前 Request 的用户进行服务。6.3.2 CAS 如何实现 SSO 当我们的 Web 时代还处于初级阶段的时候， SSO 是通过共享 cookies 来实现，比如，下面三个域名要做 SSO ： 如果通过 CAS 来集成这

19、三个应用，那么，这三个域名都要做一些域名映射， 因为是同一个域，所以每个站点都能够共享基于 的 cookies 。这种方法原始，不灵活而且有不少安全隐患，已经被抛弃了。CAS 可以很简单的实现跨域的 SSO ，因为，单点被控制在 CAS Server ，用户最有价值的 TGC-Cookie 只是跟 CAS Server 相关， CAS Server 就只有一个，因此，解决了 cookies 不能跨域的问题。回到 CAS 的基础协议图，当 Step3 完成之

20、后， 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) 。 6.3.3 基CAS的代理模式

21、模式 1 已经能够满足大部分简单的 SSO 应用，现在，我们探讨一种更复杂的情况，即用户访问 helloservice ， helloservice 又依赖于 helloservice2 来获取一些信息，如同： User helloservice helloservice2这种情况下，假设 helloservice2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 IE 窗口不停地 闪动 ) ， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。代理的前提是需要 CAS Client

22、拥有用户的身份信息 ( 类似凭据 ) 。 与其说之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据，则这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借 TGC ， User 可以免去输入密码以获取访问其它服务的 Service Ticket ，所以，这里，凭借 PGT ， Web 应用可以代理用户去实现后端的认证，而无需前端用户的参与。如下面的 CAS Proxy 图所示， CAS Client 在基础协议之上，提供了一个额外的 PGT URL 给 CAS Server, 于是， CAS Server 可以通过 PGT URL 提供一个 PGT 给 C

23、AS Client 。有人可能会对上图的 PGT URL 感到迷惑，或者会问，为什么要这么麻烦，要通过一个额外的 URL( 而且是 SSL 的入口 ) 去传递 PGT ？如果直接在 Step 6 返回，则连用来做对应关系的 PGTIOU 都可以省掉。 PGTIOU 设计是从安全性考虑的，非常必要， CAS 协议安全性问题（稍后解决）。于是， CAS Client 拿到了 PGT( PGTIOU-85.ti2td ) ，这个 PGT 跟 TGC 同样地关键， CAS Client 可以通过 PGT 向后端 Web 应用进行认证。如下图所示， Proxy 认证与普通的认证其实差别不大， Step1

24、, 2 与基础模式的 Step 1,2 几乎一样，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。最终的结果是， helloservice2 明白 helloservice 所代理的客户是 David. Turing 同学，同时，根据本地策略， helloservice2 有义务为 PGTURL=http:/helloservice/proxy 服务 (PGTURL 用于表示一个 Proxy 服务 ) ，于是它传递数据给 helloservice 。这样， helloservice 便完成一个代

25、理者的角色，协助 User 返回他想要的数据。代理认证模式非常有用，它也是 CAS 协议 v2 的一个最大的变化，这种模式非常适合在复杂的业务领域中应用 SSO 。因为，以前我们实施 SSO 的时候，都是假定以 IE User 为 SSO 的访问者，忽视了业务系统作为 SSO 的访问者角色。6.4 CAS 安全性 CAS 的安全性是一个非常重要的 Topic 。 CAS 从 v1 到 v3 ，都很依赖于 SSL ，它假定了这样一个事实，用户在一个非常不安全的网络环境中使用 SSO ， Hacker 的 Sniffer 会很容易抓住所有的 Http Traffic ，包括通过 Http 传送的密

26、码甚至 Ticket 票据。6.4.1 TGC/PGT 安全性对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。 SSO 的安全性问题比普通应用的安全性还要严重，因为 SSO 存在一种门槛效应。以前即使 Hacker 能够截获用户在 Web 应用 A 的密码，它也未必能知道用户在 Web 应用 B 的密码，但 SSO 让 Hacker 只需要截获 TGC( 突破了门槛 ) ，即能访问所有与该用户相关的所有应用系统。PGT 跟 TGC 的角色是一样的，

27、如果被 Hacker 获得，后果可想而知。从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。因此，某些人认为 CAS 可以不使用 SSL 的想法需要更正一下， CAS 的传输安全性仅仅依赖与 SSL 。跟 Kerberos 一样 TGT ， TGC 也有自己的存活周期。下面是 CAS 的 web.xml 中，通过 grantingTimeout 来设置 CAS TGC 存活周期的参数，参数默认是 120 分钟，在合适的范围内设置最小值，太短，会影响 SSO 体验，太长，会增加安全性风险 edu

28、.yale.its.tp.cas.grantingTimeout 7200 TGC 面临的风险主要并非传输窃取。比如你登陆了之后，没有 Logout ，离开了电脑，别人就可以打开你的浏览器，直接访问你授权访问的应用 ) ，设置一个 TGC 的有效期，可以减少被别人盗用，或者被 Hacker 入侵你的电脑直接获取你系统目录下的 TGC Cookie 。6.4.2 Service Ticket/Proxy Ticket 安全性首要明白， Service Ticket 是通过 Http 传送的，以为着所网络中的其他人可以 Sniffer 到其他人的 Ticket 。CAS 协议从几个方面让 Serv

29、ice Ticket 变得更加安全。L、 Service Ticket 只能使用一次。CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会将服务端的缓存中清除该 Ticket ，从而可以确保一个 Service Ticket 被使用两次。L、 Service Ticket 在一段时间内失效。假设用户拿到 Service Ticket 之后，他请求 helloservice 的过程又被中断了， Service Ticket 就被空置了，事实上，此时， Service Ticket 仍然有效。 CAS 规定 Service Ticket 只能存活一定的时

30、间，然后 CAS Server 会让它失效。通过在 web.xml 中配置下面的参数，可以让 Service Ticket 在多少秒内失效。 edu.yale.its.tp.cas.serviceTimeout 300 该参数在业务应用的条件范围内，越小越安全。L、 Service Ticket 是基于随机数生成的。Service Ticket 必须足够随机，如果 Service Ticket 生成规则被猜出（如果你使用了 ST+Helloservice+ 自增序列的方式， Hacker 就可以构造下一个 Ticket ）， Hacker 就等于绕过 CAS 认证，直接访问所有服务。7 其他开

31、源技术实现SSO 除了 CAS 之外，还有很多开源的 SSO 方案，采用何种方案跟用户的应用环境有比较大的关系。 SSO 的优劣一般要考虑易用性，安全性，性能，扩展性等因素。 7.1 JOSSO 经常听到别人讨论 JOSSO ， JOSSO （ ）是我很早就用过的 SSO 开源项目，我后来抛弃了它，因为它存在比较多缺点，下面我们来看看：1， 没有将后台认证与 SSO 分离，过分强调 JAAS ， Axis 等JOSSO 官方网站发布了 JOSSO 三个基准：Standard Based JOSSO security infrastructure is based o

32、n JAAS (Java Authentication and Authorization Service) JOSSO uses web services implementing Axis as the distributed infrastructure. JOSSO uses Struts 这些标准可以看到 JOSSO 的适应性存在较大的限制，因为 SSO 其实并不关心认证细节，作为一个开源项目，不应该引用过多的技术，如 Axis ，因为这个世界还有很多人用 Xfire 。2， 没有描述 SSO 协议的 UseCase 图 从 JOSSO 的网站，似乎都看不到一个 SSO 的 UseC

33、ase ，容易让那些关注安全性的大型项目负责人感到忧虑。3， 缺乏广泛的 SSO 客户端支持 JOSSO 的支持的客户端比较少，这个跟他的 Memember Team 、 Contributor Team 有比较大的关系。4， 缺乏成功案例 读者使用任何 SSO 开源方案之前，有必要先了解次方案的成功案例， CAS 全球有 50 多个大学在使用 ( 大学对 SSO 的要求往往更复杂 ) 成功案例，这方面， JOSSO 跟 CAS 存在很大的差距。5， 不支持跨域的落后设计 当然， JOSSO 不支持跨域是因为它使用了共享 cookie ，下面的话截取于 JOSSO 的官方文档：JOSSO us

34、es a session HTTP cookie to keep track of the SSO session identifier. This cookie lives as long as the browser window is open, being sent only in requests associated with the domain that generated it. This means that all JOSSO partner applications must be accessed using the same domain. 这段话给我们一个提示，如

35、果设计 SSO 的时候，使用了 cookie 来在 SSO Server 和 SSO Agent( 相当于 CAS 的 CAS Client) 之间共享用户信息，那么这个协议是无法突破跨域限制的。因为当多个 SSO Agent 如果不使用同一个域名，也就是 M 和 IBM.com 无法共享同一个 cookie ， JOSSO 采用了一种 DNS 技巧，即使用 M 和 来共享 cookie ，但这带来的问题同样很多，尤其是业务系统本身存在一些对域名限制的业务逻辑的时候，需要改动原来业务系统，这不是一件好受的事情。7.

36、2 COSIGNCoSign 原先是 Michigan 大学的一个 SSO 项目， CoSign 是一个很不错的设计，但是它跟 CAS 比较相似，都是基于 Kerberos 方式的协议，一个最大的不同是 CoSign 的 SSO Server 是基于 CGI(Java Fans 更多会选择 CAS) ，对 C/C+ 的群体应该是一个不错的选择。 CoSign 协议的 UseCase 跟 CAS 很相似， CoSign 的客户端虽然也支持 J2EE/Apache/MSAPI(IIS) ，但它的 Server 端使用 C 来编写，影响了在 Java 群体中的使用。7.3 WebAuthWebAut

37、h 是一种早期的 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

38、就是浏览器用户， Generic Web Service 是 SSO Client ， WebAuth Service 和 Auth Service 可以看作是 SSO Server 。 当浏览器发起一个对 Web 应用的访问请求时，这个请求未授权，因此被重定向到 WebAuth Service 进行认证，认证的结果是获得一个经过 symmetric key 加密的 token ，而这个 Token 只有 Generic Web Service 能够解密，因此， Web 应用能够知道浏览器用户的身份。使用对称加密来共享用户身份信息存在一定的安全隐患，首先是 WebAuth Service 如何

39、保护这些对称密钥 ( 保护密钥安全本身是一件很困难的事情 ) ，一旦这些对称密钥被泄漏了， Token 就可以被随意篡改。另外，由于 Token 本身是基于 Cookie 方式发送，因此，只要 Hacker 能够复制这个 Token ，他同样可以访问其他应用。 如果不考虑安全性问题， WebAuth 的效率应该比其他 SSO 方案要高，因为它的协议没有 CAS/CoSign 那么复杂， WebAuth 中， SSO Server 不需要跟 SSO Client 通讯以确认用户的身份，用户的身份就放在 Token 中。 8 SSO的标准SAML8.1 SAML 解释 SAML 是 OASIS 制

40、定的一种安全性断言标记语言，它用于在复杂的环境下交换用户的身份识别信息。在 SAML 诞生之前，如果想在 Websphere 、 Weblogic 和 SunONE 等之间实现 SSO ，我们必须分别实现一个适配层，来达成一种相互理解的协议，在该协议上，产品能够共享各自的用户认证 / 授权信息。 SAML 诞生之后，我们免去了这种烦恼。可以预计，将来大部分产品都可以实现基于 SAML 的联邦服务。 事实伤， SAML 已经在很多商业 / 开源产品中得到实现，包括： IBM Tivoli Access Manager BEA Weblogic Oblix NetPoint SunONE Iden

41、tity Server Baltimore, SelectAccess Entegrity Solutions AssureAccess Internet2 OpenSAML Yale CAS 3 Netegrity SiteMinder Sigaba Secure Messaging Solutions RSA Security ClearTrust VeriSign Trust Integration Toolkit Entrust GetAccess 7 SAML 背后是强大的商业联盟和开源联盟，尽管 Microsoft 迟迟未能在 SAML 2.0 观点上达成一致，但它也正努力跟进SA

42、ML标准化过程，由此可见SAML协议已经是势在必行。8.2 SAML 的基本概念理解 SAML 的概念很重要，个人认为 SAML 协议的原理跟 CAS/Kerberos 很类似，理解上不存在困难，但 SAML 引入了一些新的概念名词，因此要先把握清楚这些概念。 断言，这个在 SAML 的 ”A” ，是整个 SAML 协议中出现的最多的字眼，我们可以将断言看作是一种判断，并且我们相信这种判断，因此，做出断言的一方必须被信赖。校验来自断言方的断言必须通过一些手段，比如数字签名，以确保断言的确实来自断言方。 SAML 目标是让多个应用间实现联邦身份 (Identity Federation) ，提起

43、联邦，大家可以想象一下欧盟，欧盟国家之间的公民都具有一个联邦身份，比如 Peter 是法国公民， John 是比利时公民，这两个公民的身份都能够互相被共享，恰好，张三是一个中国公民，但他能像 Peter 和 Jhhn 那样随意进入欧盟国家，显然不能，因为它不具有欧盟联邦身份。 理解了联邦的概念，我们就可以回到 SAML 上， SAML 解决了联邦环境中如何识别身份信息共享的标准化问题，比如，法国的 Peter 进入比利时，他如何证明自己的身份呢？ SAML 就是为了解决这个问题。 在联邦环境中，通常有下面的 3 种实体： Subject ( 主题 ) ： Subject 是 SAML 实体中的

44、第一个重要的概念， Subject 包括了 User 、 Entity 、 Workstation 等能够象征一个参与信息交换的实体。 Relying Party ( 信任方 ) ： SAML 中的 Service Provider 角色，也就是提供服务的一方。 Asserting Party ( 断言方 ) ： SAML 中的 Identity Provider 角色，用于提供对主题的身份信息的正确的断言，类似一个公证机构。 例如我们看看一个场景： 假设有一个 Peter(Subject) 的法国公民，他需要访问比利时 (Service Provider) ，他在比利时机场被要求提供身份信息

45、， Peter 提供了欧盟 (Federation) 的通行证件，随即，这个通行证件在比利时机场被审核，或通过计算机送到欧盟身份认证中心 (Identity Provider) ，该中心有一个由所有欧盟国家共同建立的公民数据库，中心审核了 Peter 的身份信息，并断言“ Yes ， He is Peter From France ”，于是， Peter 得到礼貌的回应“欢迎光临比利时”。 如果你将欧盟看作是一个联邦环境，你会发现上面的场景跟在联邦环境应用 SAML 很相似。 在联邦环境下，任何需要授权访问的服务都需要知道服务请求方的身份主题信息 (Who are you) ，服务提供方 (S

46、ervice Provider) 不负责审核用户的身份信息，但它依赖于 1 个甚至多个 Identity Provider 来完成此任务，见下图。 1 个 Idnetity Provider 可以被多个 Service Provider 共享，当然，共享的前提是建立信任关系 ( 即 Service Provider 要信任 Idnetity Provider) ，就好比如，如果比利时 (Service Provider) 需要开放对欧盟国家成员访问，它信任欧盟的 Idnetity Provider ，它信任欧盟的 Idnetity Provider 的任何判断，包括 ”He is Peter

47、From France” 。至于是否让 Peter 入境，那是受权限策略的控制 ( 注意 SAML 同样对 Authorization 断言做了标准化，此处，我们仅仅关注 Authentication)8.3 SAML的两种典型模式 在协议的角度， SAML 原理非常类似 CAS 和 Kerberos ， CAS 协议依赖于 CAS Server ， Kerberos 依赖于 KDC ，而 SAML 则依赖于 Identity Provider 。 根据 Service Provider( 以下简称 SP) 和 Identity Provider( 以下简称 IDP) 的交互方式， SAML

48、可以分为以下几种模式：一种是 SP 拉方式，一种是 IDP 推方式。 在 SAML 中，最重要的环节是 SP 如何获取对 Subject 的断言， SP 拉方式是 SP 主动到 IDP 去了解 Subject 的身份断言，而 IDP 推方式则是 IDP 主动把 Subject 的身份断言通过某种途径告诉 SP 。 8.3.1 POST/Artifact Bindings 方式该方式的主要特点是， SP 获得客户端的凭证 ( 是 IDP 对 Subject 的一种身份认可 ) 之后，主动请求 IDP 对 Subject 的凭证的断言。如下图所示： Subject 是根据凭证去访问 SP 的。凭证

49、代表了 Subject 的身份，它类似于“来自 IDP 证明：我就是 Peter ，法国公民”。 现在，让我们看看 SP 拉方式是如何进行的： Subject 访问 SP 的受保护资源， SP 发现 Subject 的请求中没有包含任何的授权信息，于是它重定向用户访问 IDP. 协议执行： 1， Subject 向 IDP 请求凭证 ( 方式是提交用户名 / 密码 ) 2， IDP 通过验证 Subject 提供的信息，来确定是否提供凭证给 Subject 3， 假如 Subject 的验证信息正确，他将获取 IDP 的凭证以及将服务请求同时提交给 SP 。4， SP 接受到 Subject

50、的凭证，它是提供服务之前必须验证次凭证，于是，它产生了一个 SAML 请求，要求 IDP 对凭证断言 5， 凭证是 IDP 产生的，它当然知道凭证的内容，于是它回应一个 SAML 断言给 SP 6， SP 信任 IDP 的 SAML 断言，它会根据断言结果确定是否为 Subject 提供服务。 8.3.2 Redirect/POST Bindings 方式该方式的主要特点是， IDP 交给 Subject 的不是凭证，而是断言。 过程如下图所示： 1 ， Subject 访问 SP 的授权服务， SP 重定向 Subject 到 IDP 获取断言。 2 ， IDP 会要求 Subject 提供

51、能够证明它自己身份的手段 (Password ， X.509 证书等 ) 3 ， Subject 向 IDP 提供了自己的帐号密码。 4 ， IDP 验证密码之后，会重订向 Subject 到原来的 SP 。 5 ， SP 校验 IDP 的断言 ( 注意， IDP 会对自己的断言签名， SP 信任 IDP 的证书，因此，通过校验签名，能够确信从 Subject 过来的断言确实来自 IDP 的断言 ) 。 6 ，如果签名正确， SP 将向 Subject 提供该服务。 8.4 SAML 的优势SAML 协议仍在不断的发展， SAML1.0, SAML1.1 到现在的 SAML2.0 ，都是 IT

52、 商业巨头协商后，由 OASIS 发布的产物，另外， OASIS SAML 实验室得到拥有美国政府 GSA 的大力资助。 SAML 在 SOA 中扮演了一个关键角色，由于用户要求将企业资源从原有的面向数据 / 接口转变为面向服务，而建立在众多 Vendor 产品下的服务存在这种种鸿沟，最大的鸿沟是如何识别身份，如何能够让网易 163 邮件的 VIP 用户享受免费参加 Dev2dev 广州 UserGroup 的活动？ 读者可能已经听闻很多身份管理软件， IBM Tivoli ， SiteMinder ， RSA SecureID 等，虽然身份管理软件都非常强，但成本同时也很高。身份管理并不适合于那种构建是 B2B 之上的商业环境（联邦环境）。 但对用户来说，根本问题是，网易和 Dev2dev 是两个不同的公司 / 组织，它们都严格保护自己的用户身份信息，一般极少可能会共享身份数据，因此，做法是双方都提供一个服务入口，对身份信息做断言，例如只告诉 Dev2dev 该用户确实是网易的 VIP 用户。 SAML 提供了一个安全标记规范，并且给出了一些的 UseCase ，这些 usecase 足以满足我们绝大部分的