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)

 

   saml_protocol_1.jpg

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.

      saml_protocol_2.jpg
       

 

       协议执行:

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 的不是凭证,而是断言。

       过程如下图所示:

 

         saml_protocol_3.jpg
       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

 

 

 

 

 

 

 

 

 

猜你喜欢

转载自oywl2008.iteye.com/blog/2327997