SAML 基本概念

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 。

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

4.2.1 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

 

http://wenku.baidu.com/link?url=VjxSgR1zBf01_GFkfJLhVVsOLkWzvNiirKWdoLZCwdNjhxQC76ZUDtjL_Ln_it6Z9gT89Jyfhz3hK9MVcgdm7YtbLDuMpzoeJszGv9zYqxC