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 。

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

你可能感兴趣的:(简介)