SAML

SAML是OASIS制定的一种安全性断言标记语言，它用于在复杂的环境下交换用户的身份识别信息。在SAML诞生之前，如果想在Websphere、Weblogic和SunONE等之间实现SSO，我们必须分别实现一个适配层，来达成一种相互理解的协议，在该协议上，产品能够共享各自的用户认证/授权信息。SAML诞生之后，我们免去了这种烦恼。可以预计，将来大部分产品都可以实现基于SAML的联邦服务。

　　事实上，SAML已经在很多商业/开源产品中得到实现，包括：

　　IBM Tivoli Access Manager
　　Weblogic
　　Oblix NetPoint
　　SunONE Identity 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迟迟未能在SAML2.0观点上达成一致，但它也正努力跟进SAML标准化过程，由此可见SAML协议已经是势在必行。

　　1 SAML的基本概念

　　理解SAML的概念很重要，个人认为SAML协议的原理跟CAS/Kerberos很类似，理解上不存在困难，但SAML引入了一些新的概念名词，因此要先把握清楚这些概念。

　　断言，这个在SAML的”A”，是整个SAML协议中出现的最多的字眼，我们可以将断言看作是一种判断，并且我们相信这种判断，因此，做出断言的一方必须被信赖。校验来自断言方的断言必须通过一些手段，比如数字签名，以确保断言的确实来自断言方。

　　SAML目标是让多个应用间实现联邦身份(IdentityFederation)，提起联邦，大家可以想象一下欧盟，欧盟国家之间的公民都具有一个联邦身份，比如Peter是法国公民，John是比利时公民，这两个公民的身份都能够互相被共享，恰好，张三是一个中国公民，但他能像Peter和Jhhn那样随意进入欧盟国家，显然不能，因为它不具有欧盟联邦身份。

　　理解了联邦的概念，我们就可以回到SAML上，SAML解决了联邦环境中如何识别身份信息共享的标准化问题，比如，法国的Peter进入比利时，他如何证明自己的身份呢？

　　SAML就是为了解决这个问题。

　　在联邦环境中，通常有下面的3种实体：

　　Subject主题)：Subject是SAML实体中的第一个重要的概念，Subject包括了User、Entity、Workstation等能够象征一个参与信息交换的实体。

　　RelyingParty信任方)：SAML中的ServiceProvider角色，也就是提供服务的一方。

　　AssertingParty断言方)：SAML中的IdentityProvider角色，用于提供对主题的身份信息的正确的断言，类似一个公证机构。

　　我们看看联邦环境的一个场景：

　　假设有一个Peter(Subject)的法国公民，他需要访问比利时(ServiceProvider)，他在比利时机场被要求提供身份信息，Peter提供了欧盟(Federation)的通行证件，随即，这个通行证件在比利时机场被审核，或通过计算机送到欧盟身份认证中心(IdentityProvider)，该中心有一个由所有欧盟国家共同建立的公民数据库，中心审核了Peter的身份信息，并断言“Yes，HeisPeterFromFrance”，于是，Peter得到礼貌的回应“欢迎光临比利时”。

　　如果你将欧盟看作是一个联邦环境，你会发现上面的场景跟在联邦环境应用SAML很相似。

　　在联邦环境下，任何需要授权访问的服务都需要知道服务请求方的身份主题信息(Whoareyou)，服务提供方(ServiceProvider)不负责审核用户的身份信息，但它依赖于1个甚至多个IdentityProvider来完成此任务，见下图。

　　1个IdnetityProvider可以被多个ServiceProvider共享，当然，共享的前提是建立信任关系(即ServiceProvider要信任IdnetityProvider)，就好比如，如果比利时(ServiceProvider)需要开放对欧盟国家成员访问，它信任欧盟的IdnetityProvider，它信任欧盟的IdnetityProvider的任何判断，包括”HeisPeterFromFrance”。至于是否让Peter入境，那是受权限策略的控制(注意SAML同样对Authorization断言做了标准化，此处，我们仅仅关注Authentication)。

 

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

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

出处: http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html