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
实现模式千奇百怪，但万变不离其宗：

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.1 CAS
的结构体系

从结构体系看，
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.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 Ticket)
，通过
ST
来访问服务，而
CAS
也有对应
TGT
，
ST
的实体，而且他们在保护
TGT
的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。

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



基础协议




CAS
基础模式

上图是一个最基础的
CAS
协议，
CAS Client
以
Filter
方式保护
Web
应用的受保护资源，过滤从客户端过来的每一个
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
是不可以伪造的，最后，
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
和
CAS Server
相互间的
Service Ticket
核实
(Validation)
过程。当
CAS Server
告知
CAS Client
用户
Service Ticket
对应确凿身份，
CAS Client
才会对当前
Request
的用户进行服务。



CAS

如何实现

SSO



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

http://www.blogjava.net

http://www.matrix.org.cn

http://www.csdn.net

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

http://blogjava.cas.org

http://matrix.cas.org

http://csdn.cas.org

因为是同一个域，所以每个站点都能够共享基于
cas.org
的
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)
。



CAS

的代理模式


模式
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
？如果直接在
Step 6
返回，则连用来做对应关系的
PGTIOU
都可以省掉。
PGTIOU
设计是从安全性考虑的，非常必要，
CAS
协议安全性问题我会在后面一节介绍。

于是，
CAS Client
拿到了
PGT(
PGTIOU-85…..ti2td
)
，这个
PGT
跟
TGC
同样地关键，
CAS Client
可以通过
PGT
向后端
Web
应用进行认证。如下图所示，
Proxy
认证与普通的认证其实差别不大，
Step1, 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
便完成一个代理者的角色，协助
User
返回他想要的数据。



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

2.3 CAS
安全性

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



TGC/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
体验，太长，会增加安全性风险。

<context-param> <param-name>edu.yale.its.tp.cas.grantingTimeout</param-name> <param-value>7200</param-value> </context-param>

TGC
面临的风险主要并非传输窃取。比如你登陆了之后，没有
Logout
，离开了电脑，别人就可以打开你的浏览器，直接访问你授权访问的应用
)
，设置一个
TGC
的有效期，可以减少被别人盗用，或者被
Hacker
入侵你的电脑直接获取你系统目录下的
TGC Cookie
。



Service Ticket/Proxy Ticket

安全性


首要明白，
Service Ticket
是通过
Http
传送的，以为着所网络中的其他人可以
Sniffer
到其他人的
Ticket
。

CAS
协议从几个方面让
Service 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
只能存活一定的时间，然后
CAS Server
会让它失效。通过在
web.xml
中配置下面的参数，可以让
Service Ticket
在多少秒内失效。

<context-param> <param-name>edu.yale.its.tp.cas.serviceTimeout</param-name> <param-value>300</param-value> </context-param>

该参数在业务应用的条件范围内，越小越安全。

l

Service Ticket
是基于随机数生成的。

Service Ticket
必须足够随机，如果
Service Ticket
生成规则被猜出（如果你使用了
ST+Helloservice+
自增序列的方式，
Hacker
就可以构造下一个
Ticket
），
Hacker
就等于绕过
CAS
认证，直接访问所有服务。

3. CAS

以外的其他开源

SSO

方案

除了
CAS
之外，还有很多开源的
SSO
方案，采用何种方案跟用户的应用环境有比较大的关系。
SSO
的优劣一般要考虑易用性，安全性，性能，扩展性等因素。

3.1 JOSSO

经常听到别人讨论
JOSSO
，
JOSSO
（
www.josso.org
）是我很早就用过的
SSO
开源项目，我后来抛弃了它，因为它存在比较多缺点，下面我们来看看：

1，

没有将后台认证与
SSO
分离，过分强调
JAAS
，
Axis
等

JOSSO
官方网站发布了
JOSSO
三个基准：

Standard Based JOSSO security infrastructure is based on JAAS (Java Authentication and Authorization Service) JOSSO uses web services implementing Axis as the distributed infrastructure. JOSSO uses Struts and JSP standards

这些标准可以看到
JOSSO
的适应性存在较大的限制，因为
SSO
其实并不关心认证细节，作为一个开源项目，不应该引用过多的技术，如
Axis
，因为这个世界还有很多人用
Xfire
。

2，

没有描述
SSO
协议的
UseCase
图

从
JOSSO
的网站，似乎都看不到一个
SSO
的
UseCase
，容易让那些关注安全性的大型项目负责人感到忧虑。

3，

缺乏广泛的
SSO
客户端支持

JOSSO
的支持的客户端比较少，这个跟他的
Memember Team
、
Contributor Team
有比较大的关系。

4，

缺乏成功案例

读者使用任何
SSO
开源方案之前，有必要先了解次方案的成功案例，
CAS
全球有
50
多个大学在使用
(
大学对
SSO
的要求往往更复杂
)
成功案例，这方面，
JOSSO
跟
CAS
存在很大的差距。

5，

不支持跨域的落后设计

当然，
JOSSO
不支持跨域是因为它使用了共享
cookie
，下面的话截取于
JOSSO
的官方文档：

JOSSO uses 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.

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

3.2 CoSign

CoSign
原先是
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
群体中的使用。
CoSign
是一个不错的选择，可能是因为本人比较喜欢
Kerberos Model
的原因吧。

3.3 WebAuth

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

Internet2 OpenSAML

l

Yale CAS 3

l

Netegrity SiteMinder

l

Sigaba Secure Messaging Solutions

l

RSA Security ClearTrust

l

VeriSign Trust Integration Toolkit

l

Entrust GetAccess 7

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

4.1 SAML
的基本概念

理解
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.2 SAML
的
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
。



SAML

的

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
提供服务。



SAML

的

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.3 SAML
的优势所在

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
的支持。

转自：http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html