SAML文档详细介绍

什么是 SAMLSAMLSAMLSAML 安全断言标记语言（SAML，Security Assertion Markup Language）是一种可扩展标识语言 （XML） 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 ，它允许用户登录一次相关但单独的网站。SAML 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 用于商户对商户（B2B） 以及商户对顾客（B2C）的事务处理。 SAML定义三种元件：断言、协议以及约束。存在验证、标志、授权三种断言。验证断 言确认用户的身份，标志断言包含特定的用户信息，授权断言确认用户得到授权。 协议定义 SAML如何请求和接收断言。约束定义如何将 SAML消息交换映射成简单对 象访问协议（SOAP）交换。SAML与多个协议一起工作，包括超文本传输协议（HTTP）、 简单邮件传输协议（SMTP）、文件传输协议（FTP），它还支持 SOAP、BizTalk以及电子商 务 XML（ebXML）。结构化信息标准促进组织（OASIS）是 SAML的标准组织。 SAMLSAMLSAMLSAML标准&&&&协议 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协议已经是势在必行。 1111 SAMLSAMLSAMLSAML的基本概念 理解 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)。 2222 SAMLSAMLSAMLSAML 的 2222 种典型模式 在协议的角度， 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 提供该服务。 SAML2.0SAML2.0SAML2.0SAML2.0特性 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 IdP和 SP错误的有效解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 在 Oracle WebLogic或者任何其他应用服务器中，中间件的错误检测和解决方案，允许 同时为 IdP和 SP进行 SAML安全调试和/或直接“跟踪”日志是一个标准测试过程。为Web 应用浏览器认证使用 SAML时，另一种工具是 tcpmon。tcpmon是一个在 TCP连接上监视 数据流动的开源工具，在客户端和服务器之内与两者之间通过配置来使用。 如果使用 Firefox为 Live HTTP头进行单元测试，tcpmon是一个很好的插件，用来测试 要求的 SAML身份验证的网站重定向。在 HTTP协议层，为了调试 SP和 Idp如何在验证和 断言处理期间重定向浏览器，Live HTTP标题是很有用的。 建立伙伴信任关系 如参考文章所言，关键配置要求不只配置一个仅有的私钥。这种处理类型只对开发模式 有好处。我们强烈推荐从一个如 VeriSign这样有效的证书颁发机构获得一个完全可信的证 书。 为可信任伙伴的 SAML集成，至少需要两条关键因素： 用于 SP网站上的断言消费服务的私钥为 IdP(见图一)提供了 SSL客户端身份验证功能 （见图一）。 从断言方来的断言用来验证签名公钥或可信任的证书。这个证书必须在 SAML身份断 言器的证书注册表中注册过，必须为浏览器/POST 注册信息所配置。 生产环境与独立 需要 SSO或跨域集成的中间件应用通常要求中间件环境下的高度可扩展性或容错复 制。就中间件 SAML安全模型而言，除了要求源站点和目标网站 URLs的模型不受到影响， 还要反映虚拟地址的负载均衡。 启示：SAML2.0特性 对很多组织来说，最有可能是根据新特性是否具有足够的吸引力迫使软件组织决定转向 SAML2.0： 升级访问管理器的应用； 重新设计 SP配置，并且； 重写应用逻辑。 SAML2.0包含一个单点退出协议，它几乎同时支持Web SSO参与者会话的注销。对于 SAML1.1，这种“普遍注销”功能必须结合 IdP内在的 Cookie管理行为来设计。例如，在验 证和实现单点登陆到多个服务的提供者后，用户可以依照身份提供者的要求自动退出所有服 务提供者。元素已更名为。元 素现在支持了会话的概念，以便支持单点注销和其他会话管理要求。 SAML模式的可扩展性机制已经更新了。因为有利于类型扩展，XSD元素的替代者已 被封掉。已经选择性地将 通配符添加进结构中，就是被视为有价值的地方， 因为可以添加任意属性而无需创建一个模式扩展，如，对象确认数据和 SAML属性。这是 一个有用的修改，因为现实世界的实现有时是要求瞬变的，传输中的信息需要包含在断言中， 就像传入用户登陆的上下文。例如，一个通过了身份验证用户可能有能力从多个位置验证应 用，并且该应用可能对非常有兴趣了解这个信息。 这篇文章曾是基于浏览器/POST配置文件。在 SAML1.1中这两个原始的浏览器配置文 件（Browser/Artifact 和 Browser/POST）已经合并到了单一的浏览器 SSO的配置文件中了。 虽然增强的用户和代理 SSO配置已经加入了，但又产生了两种不同的配置。 建议越过 SAML 1.1而使用 SAML 2.0不只是跟上当前技术问题，SAML 2提供了一个 完整的分布式 SSO体验，然而，SAML1.1有一些严重的缺陷。最后，送给持有反对意见的 采纳人一句话，改变既不见得是好事，也不一定是坏事，如此而已。 Frank Teti是 Ironworks的一位架构师，以前属于 Oracle/BEA Systems SOA/BPM的实施。 你可以用 fteti@ironworks.com和他联系。 SAMLSAMLSAMLSAML：集中身份管理的秘诀 身份管理是个复杂问题。它包括口令维护、用户配置和访问控制管理。本文着重介绍了 身份管理中被 SAML大大简化了的一部分，即基于角色的访问控制（RBAC）。越来越多的 厂商在支持 RBAC，因为它可以让管理员简化访问控制列表。 曾经调查过一个数据：内部用户和外部伙伴同时在使用的口令有多少？回答居然超过 15个。当然，他们可以把这 15个口令全记在脑子里，每次需要访问新的资源、新的应用或 者新的数据库时，找到相应的管理员。管理员会随叫随到，永不休假，而且始终会有后备管 理员。当用户离开公司、被解雇或伙伴转眼间变成对手后，管理员总是会被告知要迅速取消 他们的访问权限。在这种理想情况下，我们知道，CIO们总是会因为得到了用户反映的能非 常容易地访问数据的夸奖而开心不已。 解决这些问题的一个方法是身份管理。身份管理是指对用户配置、口令和访问控制的管 理。访问权限通常存放在不同的位置，不同的应用和资源有着不同的访问控制列表。身份管 理必须控制分布在不同位置上的数据、人员和资源的使用情况。过去，身份管理功能由许多 不同的系统完成，比如，某一个程序处理用户的配置，另一个程序管理口令，轻型目录访问 协议（LDAP）可保存验证信息，而每个应用程序（或管理员）则维持不同的用户访问控制 列表。那时，维护、同步及更新这些不同功能是一件费力又费钱的事。 为此，有人开发了结合身份管理等多项功能的验证/授权（AA）Web服务，向整个企业 推行联合的单次登录方案，向加强身份管理这一目标迈出了第一步。这种 AA Web服务是一 种系列的多级服务，可以让用户登录一次，然后就可以调用 Web服务、访问很多应用系统 和数据资源。这种方法有两大好处：首先，它有助于简化身份管理，因为它把对访问控制的 管理从本地的多个应用系统转移到了管理中心，如 LDAP。其次，它提供了让 Web服务可 以访问数据的一般的方法。 集中是关键 使用 LDAP作为管理中心的办法可采用 Jericho Systems公司提供的规则集。这家软件 公司开发的 EnterSpace产品将 SAML服务和规则引擎作为安全包的一个部分。之所以选择 Jericho Systems，是因为这家公司提供的产品物美价廉，而且愿意迁就各种限制。利用 EnterSpace，你可以结合使用 SAML、规则集以及定制的规则，把身份管理的所有部分与作 为管理中心的 LDAP联系起来。 集中及联系配置、口令管理和访问控制让生活更简单。把身份管理流程与作为参考点和 管理中心的 LDAP联系起来是很自然的事。不过，LDAP通常用于验证，而不是用于授权。 SAML便于把 LDAP验证和访问授权联系起来。 SAMLSAMLSAMLSAML的作用 2002年 11月，结构化信息标准促进组织（OASIS）批准了 SAML作为商业合作伙伴之 间交换验证和授权信息的可扩展标记语言（XML）框架，尤其是借助Web服务交换的信息。 有了 SAML，多家公司管理的站点之间就可以实现基于Web的安全兼容，如单次登录。 SAML利用基本的Web服务标准，如 XML、简单对象访问协议（SOAP）和传输层安 全（TLS），支持安全交换验证和授权信息。RSA、Netegrity、IBM、Oracle、BEA、Oblix 和 Jericho等厂商已承诺支持 SAML，并正在把这项规范实施到各自的产品中去。 “SAML断言”（SAML Assertion）使用 SOAP消息里面的标题通过 HTTP进行传输， 在断言管理方和转发方之间传输安全信息。比如，用户在某一站点登录后，SAML断言会传 输用户验证令牌，其中提供了通过验证登录远程站点验证的手段。SAML封包包括验证令牌 和用户属性，可以对照用于验证和访问控制的规则引擎进行检验。 值得一提的是，SAML不负责验证，它只负责传输被验证的信息。另外，SAML可使 用不同的验证管理机构，比如 LDAP、活动目录和 RADIUS，允许使用不同的识别方法，如 口令、生物检测术、公钥基础设施（PKI）、安全套接层（SSL）和 Kerberos等等。随后，作 为传输机制，SAML传输用户已通过验证的断言信息。相比之下，SAML既不进行授权， 也不传输访问控制信息。 不妨把 SAML想像成电影里由彪形大汉看守的一道门。如果某个可疑的人过来说：“是 Joe让我来的”，这意味着 Joe验证了该人身份，门卫会把他引到玩扑克牌的地方。如果一位 光彩照人的女演员过来说：“是 Rudolph让我来的”，门卫会先检查 Rudolph的贵宾访问列表， 找到她的名字后，一路护送她观看赌场。最后，如果詹姆斯·邦德亮一下卡，看一眼扫描装 置，就可能通过了身份卡和虹膜扫描的验证。然后，验证系统会与识别哪些特工有权进入的 授权列表作一个对照。 SAMLSAMLSAMLSAML的安全风险 SAML可能会受到三种广为人知的安全攻击： 重放攻击（replay attack）:如果恶意黑客劫持 SAML令牌后进行重放，获得非法访问权， 就会发生这种攻击； DNS欺骗：如果黑客截获 SAML令牌后，发送虚假的 DNS地址，就会发生这种攻击; HTTP链接攻击（HTTP Referrer Attack）：如果黑客重新使用 HTTP链接标记，就会发 生这种攻击。 利用定时会话可以减小或者消除这三种攻击的威胁。可以采用以下办法来消除攻击：令 牌只用一次，并且把令牌使用情况记入日志，这样重新使用就会被标出来；使用 IP地址避 免 DNS欺骗；使用安全超文本传输协议（HTTPS）和 SSL/TLS，消除 HTTP攻击。专家和 分析师一致认为，这些风险是可以缓解的；SAML为断言提供了一种安全标准。 过程简介 AA Web服务按顺序执行安全操作。使用用户名和口令对与 LDAP服务器上的信息进行 对照，就可以识别及验证用户的独特身份。每次登录会话都会创建携有验证信息和用户信息 的 SAML令牌。用户通过使用定义访问控制的规则，获得访问数据资源的授权，而 Jericho Systems的 EnterSpace规则引擎负责评估。 这个大体上的流程如图 1所示。评估工作包括解析来自 SAML令牌的信息，规则基于 策略创建而成。因为规则控制访问，并体现策略，所以引擎通过实施规则来执行策略管理。 非常笼统地说，用户基于 LDAP信息、用户信息和访问规则获得访问权限。此外，用户离 开公司后，他们的由 LDAP管理的所有账户会被注销，所有访问权同时被取消。这样，你 就可以基于作为管理中心的 LDAP来集中管理身份。 图 1 安全作业顺序 为了加以说明，不妨看看图 2所示的几个步骤。用户登录到桌面机上的客户端后，客户 端通过本地 LDAP（图中没有显示）对其进行验证。然后，客户端向 SAML服务方发送包 括返回验证信息的请求，SAML服务方对信息打包处理后供Web服务使用。Web服务就会 通过发送查询给 LDAP服务器（图中没有显示）核实 SAML令牌里的验证信息。一旦通过 了核实，Web服务就根据规则引擎中的规则，允许访问数据资源。然后，Web服务返回响 应给客户端，从而完成用户的请求过程。 图 2 验证/授权Web服务过程的重要参与者 工作原理 AA服务是一种复杂的Web服务，遵守面向服务架构（SOA）的原则。它基于 HTTPS 上的 SOAP，两者都是非专利性的开放标准，独立于软件语言或者厂商系统。它们不需要使 用、许可或维护的费用。利用 SOA原则进行设计意味着，你可用模块化方式构建这项Web 服务，为了使用和维护的方便性，必要时可以删除或者更换它。因此，你不必改动其他部分， 就可以改动架构的任何部分。 AA服务使用本地域 LDAP进行验证及随后基于 SAML的安全断言。SAML令牌用来 把断言传输到可信资源，再由可信资源允许或拒绝对数据资源的访问。 这种功能类似驾驶执照：机动车辆管理局（DMV）就是管理方（好比 LDAP），负责核 实你的身份及驾驶资格。交警充当可信资源，负责向 DMV复核身份，然后根据目前的驾驶 资格或者道路规则，批准或者禁止某驾驶员是否有权驾驶。 AA服务在使用规则引擎评估授权规则时，以允许或拒绝访问数据资源限定条件的安全 策略为基础。引擎规则对加强策略管理来说是核心所在。 使用 LDAP作为管理方还有助于实现身份集中管理。不是在单个资源处管理资源访问， 而是使用 LDAP和定义用户角色及相应数据参数（如部门和管理级别）的相应策略，来管 理用户访问列表。 以下是这个过程的几个重要步骤： 第 1步：用户登录。用户需要访问数据资源，于是使用 SOAP客户端利用用户名和口 令对进行登录。客户端把用户名和口令对（还有可能是其他安全因素）传送给 LDAP进行 验证。LDAP核实用户后，把信息返回给客户端。 第 2步：SAML令牌。SOAP客户端把返回的 LDAP信息及其他用户信息传送给 SAML 客户端。该服务方会按正确格式把信息打包成 SAML 令牌，SAML 客户端把令牌返回给 SOAP客户端，然后 SOAP客户端把 SAML令牌和用户请求打包成 SOAP请求。 第 3步：SAML会话开始。SOAP客户端开启定时的 SAML会话，并发送 SOAP请求 给相应的Web服务，以满足用户需求。Web服务解析 SAML令牌后，通过 LDAP核实验证 信息。这样，用户只要登录一次：每个Web服务都可以充当用户代理，并获得数据资源的 信任，因为Web服务核实了请求信息。 第 4步: 授权。经验证后，Web服务发送请求给运行规则引擎的 SAML服务器。SAML 在这一步并不是绝对必要的，但对我们来说很方便。规则引擎评估用户参数后，确定授权用 户的访问级别。评估工作基于体现一组预定访问策略的规则进行。访问级别核实信息返回给 Web服务。 第 5步: 请求完成。Web服务请求数据源提供数据，把请求结果打包成 SOAP响应，然 后发回给 SOAP客户端。SOAP客户端再把数据提供给用户，同时终止 SAML会话。SAML 令牌期满，不能重复使用。 集中就是统一 总的说来，我们建立的基于SAML的AA Web服务依靠LDAP作为管理中心。使用LDAP 和执行安全策略的授权规则引擎可以实现集中身份管理。集中身份管理的一个好处是，可以 获得简化和统一的访问控制管理。 集中身份管理意味着，你可以在某一个点管理访问控制列表。比如，终止某个员工的账 户就可以终止与中央账户（这里是 LDAP）相关的所有访问。这种 Web服务为断言、认证 和服务提供了通用服务。开发人员可以调用这种Web服务，允许Web服务访问所需的应用 和数据资源。 所汲取经验 SAML传输的是令牌，它不是验证或者授权机制。为了缓解风险，SAML系统使用定 时会话、IP地址、HTTPS和 SSL/TLS。安全Web服务非常复杂，涉及法律、安全和政治等 方面。 使用 LDAP作为管理中心可以实现集中身份管理。规则引擎为访问控制和策略管理提 供了有效而灵活的方案（它同时支持基于角色和基于属性的访问控制）。 可以简化身份管理，首先是因为可以在 LDAP处激活或者禁用账户。其次，可以避免 费用，因为可以集中及减少验证应用，减少审查风险。最后，可以简化身份管理，是因为账 户管理使用现有的 LDAP服务，从而减少了开销、加强了同步。 SAMLSAMLSAMLSAML：企业级的 IdPIdPIdPIdP 虽然使用 Oracle WebLogic作为 IdP是显然可行的，但它没有一个真实访问管理环境的特征， 诸如 Sun访问管理器，Tivoli访问管理器，Oracle访问管理器等。作为 IdP的 Oracle WebLogic 服务器不提供，类似像 Sun访问管理器所提供的会话管理功能。众多厂商支持的 SAML提 供了一个优于企业内部网的 SSO解决方案。图一描述了一个使用以下技术的参考架构： 作为 IdP的 Sun访问管理器 7.1； 作为 SP的WebLogic服务器 10.3。 图一 理论上 SAML架构 在此之上包含了一个 LDAP存储库 虽然很多 IdP厂商同时支持格式和协议，但因为不同厂商实现方式各不相同，并且都包 含了他们自身内部的构造，导致配置 SAML变得有点像映射工作。随着 Oracle收购了 Sun， Sun访问管理器是否会退役而有利于 Oracle访问管理器还有待观察，而 Oracle访问管理器 本身就是 Oracle以前从 Oblix收购的。虽然通过许多了解 SAML的技术专家在 Sun访问管 理器中实现作为 Idp的 SAML，类似于在 WebLogic中实现作为 IdP的 SAML，但我可以保 证配置并不是对称的，可以这么说，正如我所料。 图 2 Sun访问管理器 7.1控制台的 SAML可信任伙伴配置视图 Sun 访问管理器的源 ID 是一个难以理解的数据类型，它就是以 SP 站点 “protocol://hostname:port”字符串的 Base64编码来表示 SHA1，尽管 SP不需要知道这个 ID。 更具体地说，可信任伙伴的配置窗口捕捉了以下信息： SAMLSAMLSAMLSAML：IdPIdPIdPIdP和 SPSPSPSP用户存储库 在 SAML的身份验证模型里，IdP需要一个作为身份验证用户的“记录系统”的本地存储库。 通常，用户存在于本地 LDAP库中。反过来说，当在 SP上调用受保护的资源时，SP可以 使用同一个本地 LDAP库来验证用户。不过，虽然这种模式可能适用于 Intranet应用，但跨 站点的网络应用上是不可行的，并且实际上没有利用 SAML SSO断言模型。 另外，通过配置 SP就可以“虚拟用户”。图 3窗口描述了在 WebLogic控制台上创建一 个声明方来授权虚拟用户。基于传入的断言，SP中这个可配置的选项允许 SAML身份断言 器实例化用户和组的 Principal(s)。这个配置也要求 SAML验证提供者为安全界限做一些配 置。这个配置使用户以虚拟用户身份登录这个虚拟用户，和任何本地的已知用户都没有对应 关系。 图 3 在WebLogic服务器 10.3控制台上创建一个断言方的视图 确切地说，创建断言方窗口捕获了下述信息： XMLXMLXMLXML安全：使用 SAMLSAMLSAMLSAML确保可移植 的信任 长期以来，人们认识到需要提供一种机制在不同的协作域之间传递关于实体的信息，同 时域又不失去对这些信息的所有权，安全性断言标记语言或者 SAML满足了这种要求。交 换的信息可以是关于主题或者验证信息的断言。这种方式也称为单点登录。 在 XML安全系列文章的上一篇中，我谈及了与安全有关的两个很重要的主题： ·易于管理。 ·可移植的信任。 在那篇文章中，我讨论了使用 XKMS实现安全基础设施的易管理性。本文中将探讨第 二个主题，可移植的信任。安全断言标记语言或者 SAML是一种保证可移植信任的机制。 我将从 SAML背后的目标谈起，然后介绍 SAML的体系结构，最后解释 SAML的概念。 信任不可移植的问题 您经常会遇到需要提供个人信息的Web站点，原因基本上是验证或者通过个人首选项 定制站点。最终，您会发现在许多不同的地方有多个帐户。如果每个站点都为此设立自己的 用户资料库，结果就会造成： ·对所有这些单独的站点都要考虑您的信息的安全。 ·多个站点不能协同为您提供所感兴趣的更精细的服务。 为了进一步说明上述第二点，我提供一个很典型的例子：旅游预约。其中包括机票、旅 馆和出租车的预定。您可能希望向某家航空公司、某个旅馆以及某个汽车出租商预订，但是 不存在一种机制使您能够在三个独立的站点之间无缝移植——可能需要提交证明进行三次 验证（假设这三家您都有帐户）。 SAML被设计成解决这一问题，它允许只有少数经过选择的团体保留您的信息，并且如 果需要，在得到您的明确批准之后这些团体可以与其他有关的团体共享这些信息。这意味着， 您的信息安全的掌握在您所信任的团体手中，并且可以访问一些供应商通过组织多种低层次 服务所提供的高级服务。 本文将说明 SAML如何实现这一目标。 SAMLSAMLSAMLSAML的目标 SAML的主要目标包括： ·建立一种独立于协议和平台的验证和授权交换机制（也称为单点登录，或者 SSO）。 ·应该独立部署环境，能够用于集中式的、分散式的以及联合式的部署场景。 ·SAML框架应该是基于 XML的。 SAMLSAMLSAMLSAML的体系结构 SAML是一种控制对已验证主体的资源进行访问的机制。对资源的访问基于特定的策略 管理。这种机制需要两种关键性的活动： ·基于策略的访问控制决策。 ·强制实施这些决策。 SAML提供了两种角色处理这些活动：策略决策点（Policy Decision Points，PDPs）和 策略实施点（Policy Enforcement Points，PEPs）。 场景：主体希望从目标Web站点访问一些受保护的内容。主体前往能够识别或者已经 验证该主体的源Web站点。用户从源站点出发尝试访问目标Web站点上的受保护内容，步 骤如下： ·主体向源站点验证并请求到目标站点受保护资源的链接。 ·源站点使用验证标志重定向主体。 ·主体使用该标志向目标站点请求受保护的资源。 ·目标站点 PEP检查该 PDP的权限。 ·PDP可能内部请求源站点使用该标志进行 SAML验证断言。 ·源站点根据标志向目标站点提供 SAML验证断言。 ·目标站点向主体提供受保护的资源。 总之，在源站点验证的主体从 SAML权威获得一个标志并将其提供给目标站点。目标 站点使用该标志从源站点请求所需要的信息而不需要明确地从主体获取。 SAMLSAMLSAMLSAML综述 SAML规范由以下部分组成： ·断言与协议：该规范处理定义 XML编码的断言的语法和语义，以及请求和响应协议。 ·绑定与配置文件：该规范处理 SAML请求/响应消息到底层通信协议如 SOAP和 SMTP 的映射。控制在底层通信协议中嵌入和提取 SAML信息的一组规则称为一个配置文件。 ·一致性规范：不同的 SAML实现可能只实现这些规范的一部分。一致性规范设置了一 种基本标准，SAML规范的实现在能够称为一致性实现之前必须满足这一标准。这样有助于 提高互操作性和兼容性。 ·安全和保密的问题：该规范涉及 SAML体系结构中的安全风险，具体而言就是 SAML 如何应对这些风险以及无法解决的风险。 我将采用问答的形式介绍和 SAML有关的概念。我将逐个回答以下问题以澄清这些基 本概念： ·什么是断言？ ·谁生产和消费断言？ ·如何请求断言，如何发送响应？基本上而言，请求和响应协议是什么？ ·SAML请求响应协议可以绑定到哪些底层的通信传输 协议？ ·如何向 SOAP这样的底层通信传输协议中插入 SAML断言？ ·什么是一致性规范，为何需要它？ ·如果只实现了标准的子集，也能说该实现是兼容的么？ ·定义一致性的粒度级别是什么？ ·基于 SAML的系统的安全风险是什么？ 什么是断言？ 断言提供主体所执行的验证、主体属性、是否允许主体访问特定资源的授权决策等信息。 一组断言组成一个主体的配置文件。配置文件中的断言可能来自不同的组织。 断言有三种类型： ·验证：验证断言处理主体在特定时刻、特定机制下的身份验证。 ·属性：属性断言提供联系特定属性与给定主体的一种机制。 ·授权决策：授权决策断言管理给定主体访问资源的权限。 谁生产和消费断言？ SAML权威生产断言。SAML权威可进一步划分为验证权威、属性权威或者 PDP。断 言的消费者是客户或者 SAML权威本身。 如何请求断言，如何发出响应？基本上而言，请求和响应协议是什么？ SAML请求响应协议为发送断言请求和获取响应定义了一种标准消息格式。SAML请 求协议定义的消息格式采用下面的请求类型： ·SubjectQuery：允许使用模式定义新的查询类型，指定一个 SAML主体。 ·AuthenticationQuery：请求一个主体的验证信息。返回验证断言作为响应。 ·AttributeQuery：请求主体的属性信息。响应中包括请求者拥有权限的那些属性的属性 断言。 ·AuthorizationDecisionQuery：进行授权决策。根据请求者提交的证据，该查询决定是否 授权该请求者访问受保护的资源。 ·AssertionIDReference：根据唯一标识符检索特定的断言。 ·AssertionArtifact：根据代表断言的助诊文件检索一个断言。 响应消息格式分别对应请求的类型。 SAMLSAMLSAMLSAML请求响应协议可以绑定到哪些底层的通信传输协议？ SAML定义了 SAML请求和响应消息在标准通信传输协议上的映射。目前只定义了一 种绑定，SOAP上的 SAML。SAML SOAP绑定描述了 SAML请求和响应消息交换如何映射 到 SOAP消息交换上。SAML规范规定任何遵循 SAML规范的实现必须实现基于 HTTP的 SOAP上的 SAML。实现也可以选择实现基于其他传输协议系如 SMTP或 FTP的 SOAP上 的 SAML。 如何向 SOAPSOAPSOAPSOAP这样的底层通信传输协议中插入 SAMLSAMLSAMLSAML断言？ SAML规范定义了一组称为配置文件的规则，描述了实现应该如何在底层协议消息中插 入、提取和集成断言。比如，SAML的 SOAP配置文件描述了如何将 SAML断言添加到 SOAP 消息、SOAP头会受到 SAML断言的什么影响，以及如何在 SOAP消息中处理 SAML错误。 SAMLSAMLSAMLSAML规范中定义了两个配置文件： ·浏览器发送配置文件或推式配置文件：SAML断言在 HTML表单中上传到浏览器，当 用户提交表单时作为 HTTP POST有效负载传递给目标站点。这种情况下，源站点从目标 Web站点请求一个标志，后者返回一个授权决策标志。使用这个标志将主体重定向到目标 Web站点。 ·浏览器助诊文件（artifact）配置文件或者拉式配置文件：一个 SAML助诊文件作为 URL 查询字符串的一部分带给目标站点，在返回给源站点时明确地引用一个断言。对目标站点的 一些保护内容感兴趣的主体从源站点发送一个标志（SAML助诊文件），目标站点使用这个 标志取得验证/授权信息并决定是否允许访问。 什么是一致性规范，为何需要它？ 一致性规范有助于客观地评价 SAML实现或应用程序对 SAML规范的一致程度。以下 原因使一致性规范很有必要： ·确保对一致性和一致性需求有共同的理解。 ·促进验证和授权信息交换的互操作性。 ·促进一致性测试开发中的统一性。 如果只实现了标准的子集，也能说该实现是兼容的么？ 是的。对于遵循整个规范或者规范子集的 SAML实现来说，可以说是兼容的。 定义一致性的粒度级别是什么？ SAML一致性根据应用程序或实现所支持的 SAML绑定和配置文件来定义。对于支持 的每种绑定和配置文件，必须从以下几个方面规定一致性： ·应用程序或实现是作为 SAML消息的生产者、消费者还是兼具两种作用。 ·应用程序或实现支持哪些断言和陈述。 基于 SAMLSAMLSAMLSAML的系统的安全风险是什么？ SAML允许就验证和授权进行陈述，但是没有规定如何进行验证和建立授权。 SAML 陈述的消费者必须在信任 SAML陈述之前确信底层的基础设施。底层的基础设施也必须包 括作为客户请求和服务器响应来回传递的有效负载的安全性和机密性。 既然 SAML是一种多方验证和授权系统，一个 SAML事务中的合法参与者就有可能是 用对其他事务有威胁的信息。 和 SAML断言有关的风险：断言一旦发出就不在发出者的控制之内了。比如，消费者 可能在未定的时期内持续使用断言，或者选择与最初的发出者不知道的第三方共享这些信 息。 与 SAML协议有关的风险：通过要求较低层次上的客户验证、客户发出的请求需要签 名，或者限制 SAML请求只能发给有限的已知方，可以防止拒绝服务攻击（DOS）。 与 SAML协议绑定（目前只有 SOAP绑定）有关的风险： ·窃听 ·重放 ·消息插入 ·消息删除 ·消息篡改 ·中间人 与基于 TLS/SSL的 HTTP上的 SOAP有关的风险：这种方法只针对单跳提供安全性、 机密性和授权。对于多次中转，HTTP和 TLS/SSL没有提供足够的安全性。 和 SAML配置文件（浏览器/助诊文件配置文件和浏览器/POST配置文件）有关的风险： ·窃听 ·偷窃用户验证信息 ·偷窃持票人的标志 ·重放 ·消息插入 ·消息删除 ·消息篡改 ·中间人 SAMLSAMLSAMLSAML过程 清单 1示范了如何使用 SAML检索关于一个主体的断言。这段代码来自 Verisign所提 供的 SAML示例实现。 清单 1. 检索属性断言 Public class SAMLAssertions { // SAML service provider // Change it to the SAML service provider url that you are // trying to connect to static final String SERVICE_URL = "https://pilotpts.verisign.com/vspts/SamlResponder"; // Email of the subject that uniquely identifies it static final String SUBJECT_EMAIL = "jdoe@tpms.verisign.com"; // Subject password to authenticate the user static final String SUBJECT_PASSWORD = "password"; // The keystore to be used for getting the private key and // the public key static final String KEYSTORE_FILE = "saml_sample_keystore"; // Keystore password static final String STORE_PASS = "changeit"; static final String SIGNER_ALIAS = "pilot_saml_signer"; // VeriSign attribute naming constants static final String V_NAME_QUALIFIER = "verisign.com/ams"; static final String V_ATTR_NAMESPACE = "verisign.com/ams/namespace/common"; static final String V_ATTR_EMAIL = "//verisign.com/core/attr/email"; static final String V_ATTR_FIRSTNAME = "//verisign.com/core/attr/first_name"; public static void main(String arg[]) { NameIdentifier nameId = new NameIdentifier(SUBJECT_EMAIL, V_NAME_QUALIFIER, ""); String[] confMethods = { Identifiers.AUTHN_METHOD_PASSWORD }; SubjectConfirmation sconf = new SubjectConfirmation(confMethods, SUBJECT_PASSWORD); Subject subject = new Subject(nameId, sconf); AttributeDesignator[] reqAttrs = null; AttributeQuery query = new AttributeQuery(subject, reqAttrs); AttributeStatementProvider provider = null; try { provider = getAttributeStatementProvider(); } catch (Exception e) { // XXX Auto-generated catch block e.printStackTrace(); } AttributeStatement[] statements = null; try { statements = provider.processAttributeQuery(query); } catch (Exception e1) { // XXX Auto-generated catch block e1.printStackTrace(); } if (statements.length == 0) { System.out.println("No statements returned"); } for (int i = 0; i < statements.length; i += 1) { AttributeStatement statement = statements[i]; Authenticity authenticity = statement.getAuthenticity(); System.out.println( "Statement "+ (i + 1)+ " authenticity: " + authenticity.isAuthentic()); // Print attribute statement System.out.println("--- Attribute Statement ---"); System.out.println( " Subject: " + statement.getSubject().getNameIdentifier().getValue()) // Print attribute values Attribute[] attrs = statement.getAttributes(); for (int k = 0; k < attrs.length; k += 1) { Attribute attr = attrs[k]; System.out.println( "Namespace: " + attr.getAttributeNamespace()); System.out.println(" Name: " + attr.getAttributeName()); Object[] values = attr.getAttributeValues(); for (int m = 0; m < values.length; m += 1) { System.out.println( " Value: " + values[m].toString()); } } } } private static AttributeStatementProvider getAttributeStatementProvider() throws Exception { // Read the keystore and get the signing cert/key. InputStream fileInput = new FileInputStream(KEYSTORE_FILE); KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType()); keystore.load(fileInput,STORE_PASS.toCharArray()); PrivateKey key = (PrivateKey) keystore.getKey( SIGNER_ALIAS,STORE_PASS.toCharArray()); if (key == null) { throw new Exception(SIGNER_ALIAS + " key not found in keystore " + KEYSTORE_FILE); } Certificate[] certArray = keystore.getCertificateChain(SIGNER_ALIAS); if (certArray == null) { throw new Exception(SIGNER_ALIAS + " cert not found in keystore " + KEYSTORE_FILE); } X509Certificate[] certs = new X509Certificate[certArray.length]; System.arraycopy(certArray, 0, certs, 0, certs.length); // Create SOAP assertion provider factory with signing information SOAPAssertionProviderFactory factory = new SOAPAssertionProviderFactory(new URL(SERVICE_URL)); factory.setSigningKey(new RSASigningKey(key)); factory.setVerifyingKey(new RSAVerifyi