当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

基于 XML 的令牌的 WS-Security 概要文件

IBM, 作者

IBM has authored this article

简介：

标记本文！

发布日期： 2002 年 8 月 01 日
级别： 中级
访问情况： 1212 次浏览
评论：

本版本：: http://www.ibm.com/developerworks/library/ws-sectoken.html
作者：: Phillip Hallam-Baker，VeriSign <pbaker@verisign.com>
Maryann Hondo，IBM <mhondo@us.ibm.com>
Chris Kaler，Microsoft <ckaler@microsoft.com>
Hiroshi Maruyama，IBM <MARUYAMA@jp.ibm.com>
Anthony Nadalin，IBM <drsecure@us.ibm.com>
Nataraj Nagaratnam，IBM <natarajn@us.ibm.com>
Hemma Prafullchandra，VeriSign <hprafullchandra@verisign.com>
John Shewchuk，Microsoft <johnshew@microsoft.com>
编辑：: Chris Kaler，Microsoft <ckaler@microsoft.com>

Copyright©&#160提供、分发或以其它方式传播本规范所包含的信息并未授予您使用 IBM 或 Microsoft 或 VeriSign 和／或任何其它第三方所拥有或控制的知识产权的许可证（无论是明示的还是默示的）。IBM、Microsoft、VeriSign 和／或任何其它第三方可能拥有与本文档内容有关的各项专利权、专利应用权、商标权、版权或其它知识产权。提供本文档并未授予用户使用 IBM 或 Microsoft 或 VeriSign 或任何其它第三方的专利、商标、版权或其它知识产权的任何许可证。此处举例所用的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件均属虚构。无意也不应推测为与任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件有任何关联。

Copyright©&#160此处包含的规范和信息以“按现状”的基础提供，并在适用法律许可的最大范围内被允许，IBM 和 Microsoft 和 VeriSign 以“按现状并可能存在各种错误”的基础提供本文档，特此声明免除所有（无论是明示的、默示的，还是法定的）其它保证和条件，包括（但不限于）对与本文档有关的适销性、适用于某特定用途、响应的准确性或完整性、结果、技艺精湛的成果、无病毒和无疏忽的默示保证、责任或条件（如果有的话）。此外，对所有权、平静享用、平静占有、与描述相符或与本文档有关的知识产权的非侵权性不提供任何保证或条件。

摘要

本文档描述了一个使基于 XML 的安全性令牌能与 [WS-Security ] 一起使用的通用框架。提供了使用这个通用框架的两个概要文件：一个是针对安全性断言标记语言（Security Assertion Markup Language，SAML）的，另一个是针对可扩展权限标记语言（eXtensible rights Markup Language，XrML）的。

本文档的状态

本文档以“按现状”的基础提供，仅供评论与评估。IBM、Microsoft 以及 VeriSign 都希望在不远的将来征集您的稿件，征求您的意见。IBM、Microsoft 和 VeriSign 都不以任何方式对这些规范做出什么保证或表示。

1. 引言
1.1. 词语约定
1.2. 名称空间
2. 一般原则
2.1. 附加安全性令牌
2.2. 标识和引用安全性令牌
2.3. 主体确认
2.4. 处理规则
3. 安全性断言标记语言（Security Assertion Markup Language，SAML）的用法
3.1. 处理模型
3.2. 附加安全性令牌
3.3. 标识和引用安全性令牌
3.4. 主体确认
3.5. 错误代码
3.6. 威胁模型与对策
4. 可扩展权限标记语言（eXtensible rights Markup Language，XrML）的用法
4.1. 处理模型
4.2. 附加安全性令牌
4.3. 标识和引用安全性令牌
4.4. 主体确认
4.5. 错误代码
4.6. 威胁模型与对策
5. 安全性注意事项
6. 参考资料

回页首

1. 引言

基于 XML 的安全性令牌正日渐流行。两种著名的格式是安全性断言标记语言 [SAML] 和可扩展权限标记语言 [XrML]。由于这些格式都有单独的规范进行描述，与 X.509 和 Kerberos 也没什么不同，所以本文档描述它们与 WS-Security 规范有关的用法。

本文档描述了一个使基于 XML 的安全性令牌能与 WS-Security 一起使用的通用框架。提供了使用这个通用框架的两个概要文件：一个是针对安全性断言性标识语言的，另一个是针对可扩展权限标记语言的。请注意，本规范并未认可任何特殊的 XML 安全性令牌标准 ― 给出对 SAML 和 XrML 的描述是为了说明执行绑定所应遵循的机制。其余的 XML 令牌格式可能会根据需要被添加到本规范将来的修订版中。

1.1.词语约定

本文档中的关键字“必须（MUST）”、“绝不可以（MUST NOT）”、“需要的（REQUIRED）”、“将（SHALL）”、“将不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“可以（MAY）”和“可选的（OPTIONAL）”的解释应依照 RFC2119 [关键字] 中的描述。

[WS-Security] 旨在处理一般的 [SOAP] 消息结构和消息处理模型，而且 WS-Security 应该适用于 [SOAP] 的任何版本。这里使用当前的 SOAP 1.2 名称空间 URI 来提供详细的示例，但我们并无意将此规范的适用范围限制为 [SOAP] 的某一个版本。

1.2. 名称空间

本文档中使用了以下名称空间：

前缀	名称空间
S	http://www.w3.org/2002/06/soap-envelope
ds	http://www.w3.org/2000/09/xmldsig#
saml	urn:oasis:names:tc:SAML:1.0:assertion
xenc	http://www.w3.org/2001/04/xmlenc#
wsse	http://schemas.xmlsoap.org/ws/2002/07/secext
xmltok	http://schemas.xmlsoap.org/ws/2002/08/xmltok
wsu	http://schemas.xmlsoap.org/ws/2002/07/utility
xrml	http://www.xrml.org/schema/2001/11/xrml2core

回页首

2. 一般原则

本节给出关于将 [WS-Security] 和安全性令牌一起使用的基本原则。后面几节描述了特定于某些基于 XML 的安全性令牌格式的一些规则与过程。

2.1. 附加安全性令牌

[WS-Security] 规范把 <wsse:Security> 头定义为一种传送附带 [SOAP] 消息的或与 [SOAP] 消息有关的安全性信息的机制。按照设计，该头可以扩展到支持多种类型的安全性信息。

本规范把 <wsse:BinarySecurityToken> 元素定义为一种附加安全性令牌的机制，这些安全性令牌是用二进制八位字节流表示的，因此它们不能自然地将它们自己提供给 XML。

对于基于 XML 的安全性令牌来说，<wsse:Security> 头的可扩展性考虑到了这些安全性令牌能直接地被插入到头中。

2.2. 标识和引用安全性令牌

[WS-Security] 规范定义了使用 wsu:Id 属性和 <wsse:SecurityTokenReference> 元素来标识和引用安全性令牌的多种机制（同时定义了一些额外的机制）。

2.3. 主体确认

[WS-Security] 规范没有强制规定必须如何执行所有权证明（proof-of-possession）（亦称主体确认（subject confirmation））。然而，它确实定义了为了上述目标可以如何使用签名以及如何将签名与安全性令牌关联起来（通过在签名中引用安全性令牌）。

2.4. 处理规则

[WS-Security] 规范描述了使用与处理 [XML Signature] 和 [XML-Encrypt] 的处理规则。当使用任何类型的安全性令牌（包括基于 XML 的令牌在内）时都必须遵循这些规则。请注意，这并不意味着基于 XML 的令牌都必须被签名或加密 ― 只是说如果与基于 XML 的令牌一起使用签名和加密，那么在使用签名和加密时就必须遵循 [WS-Security] 规范定义的处理规则。

回页首

3. 安全性断言标记语言的用法

本节描述了针对 SAML 的 [WS-Security] 概要文件的概要分析（特定的机制与过程）。

标识：urn:oasis:names:tc:WSS:1.0:bindings:WSS-SAML-binding

联系信息：待定

描述：下面给出。

更新：无。

3.1. 处理模型

带有 SAML 断言令牌的 [WS-Security] 处理模型与 [WS-Security] 中所描述的带有其它令牌格式的 [WS-Security] 处理模型没有什么不同。

3.2. 附加安全性令牌

通过把断言元素放置在 <wsse:Security> 头中，SAML 断言就被附加到使用 [WS-Security] 的 SOAP 消息中。下面的示例说明了一个带有 SAML 断言令牌的 SOAP 消息。

<S:Envelope xmlns:S="...">
    <S:Header>
        <wsse:Security xmlns:wsse="...">
            <saml:Assertion 
                      MajorVersion="1" 
                      MinorVersion="0" 
                      AssertionID="SecurityToken-ef375268" 
                      Issuer="elliotw1" 
                      IssueInstant="2002-07-23T11:32:05.6228146-07:00"              
                    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
                ...
            </saml:Assertion>
            ...
        </wsse:Security>
    </S:Header>
    <S:Body>
        ...
    </S:Body>
</S:Envelope>

3.3. 标识和引用安全性令牌

[WS-Security] 规范把 wsu:Id 属性定义为通过“Id”引用安全性令牌（该规范描述了这样做的理由）的一种公共机制。由于 SAML 规范不允许在 <saml:Assertion> 元素上进行属性扩展，所以本规范允许将 <saml:AssertionIDReference> 元素放置于 <wsse:SecurityTokenReference> 元素之中。当在引用内碰到这个 <saml:AssertionIDReference> 元素时，如果接收方支持 SAML 断言令牌，那么它就必须知道要反引用 SAML 断言标识引用，以标识用作安全性令牌的正确的 SAML 断言。

下面的示例说明了一个带有 [XML Signature] 的消息，它引用了一个 SAML 断言令牌。

<S:Envelope xmlns:S="...">
    <S:Header>
        <wsse:Security xmlns:wsse="...">
            <saml:Assertion 
                      MajorVersion="1" 
                      MinorVersion="0" 
                      AssertionID="SecurityToken-ef375268" 
                      Issuer="elliotw1" 
                      IssueInstant="2002-07-23T11:32:05.6228146-07:00"              
                    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
                ...
            </saml:Assertion>
            <ds:Signature xmlns:ds="...">
                ...
                <ds:KeyInfo>
                    <wsse:SecurityTokenReference>
                        <saml:AssertionIDReference>
                            SecurityToken-ef375268
                        </saml:AssertionIDReference>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
            ...
        </wsse:Security>
    </S:Header>
    <S:Body>
        ...
    </S:Body>
</S:Envelope>

3.4. 主体确认

如前所述，[WS-Security] 规范没有强制规定必须如何进行主体确认。而且，SAML 规范还考虑到了多种类型的确认。如果不使用安全的传输，那么强烈推荐使用基于密钥的确认机制。

SAML 安全性令牌的任何处理器都必须遵循在 SAML 规范中定义的所要求的验证和处理规则。

下表说明了几种不同的确认机制是怎样被处理的：

机制	“推荐”处理规则
urn:oasis:names:tc:SAML:1.0:cm:holder-of-key	请求方（主体）包含一个 XML Signature，可以用被引用的安全性令牌中的密钥信息对该 XML Signature 进行验证。
urn:ietf:rfc:3075	请求方（主体）包含一个 XML Signature，可以用被引用的安全性令牌中的密钥信息对该 XML Signature 进行验证。
Urn:oasis:names:tc:SAML:1.0:cm:sender-vouches	请求方（这里是发送方，与主体不同）保证对主体的验证。要接受主体验证，接收方与请求方必须有一个已经存在的信任关系。推荐请求方对令牌和消息进行签名或者使用安全的传输。

3.5. 错误代码

当使用 SAML 断言令牌时，推荐使用在 [WS-Security] 规范中定义的错误代码。不过，如果愿意的话，实现可以使用私有名称空间中定义的定制的错误。应注意不要在返回的错误中引入安全性薄弱环节。

3.6. 威胁模型与对策

除了那些已经标识出的对 SAML 或带有其它类型安全性令牌的 WS-Security 的威胁之外，将 SAML 断言令牌与 [WS-Security] 一起使用并不会引入新的威胁。

使用 WS-Security 中所描述的完整性和机密性机制可以防止消息被篡改和窃听。重播攻击可以通过使用消息时间戳记与高速缓存来解决，也可以通过使用其它特定于应用程序的跟踪机制来解决。对于其所有权是通过使用密钥进行验证的 SAML 断言令牌来说，一般可以通过使用主体确认来缓和中间人（man-in-the-middle ）攻击。

强烈推荐对所有相关的和不可改变的消息数据进行签名。

应该注意到，可以利用传输层的安全性来保护消息与安全性令牌。

回页首

4. 可扩展权限标记语言的用法

本节描述了针对 XrML 的 WS-Security 概要文件的概要文件（特定的机制与过程）。

标识： urn:oasis:names:tc:WSS:1.0:bindings:WSS-XrML-binding

联系信息：待定

描述：下面给出。

更新：无。

4.1. 处理模型

带有 XrML 令牌的 [WS-Security] 处理模型与 [WS-Security] 中所描述的带有其它令牌格式的 [WS-Security] 处理模型没有什么不同。

4.2. 附加安全性令牌

通过把许可证元素放置在 <wsse:Security> 头中，XrML 许可证就被附加到使用 [WS-Security] 的 SOAP 消息中。下面的示例说明了一个带有 XrML 许可证令牌的 SOAP 消息。

<S:Envelope xmlns:S="...">
    <S:Header>
        <wsse:Security xmlns:wsse="...">
            <xrml:license xmlns:xrml="...">
                ...
            </xrml:license>
            ...
        </wsse:Security>
    </S:Header>
    <S:Body>
        ...
    </S:Body>
</S:Envelope>

4.3. 标识与引用安全性令牌

[WS-Security] 规范把 wsu:Id 属性定义为通过“Id”引用安全性令牌（该规范描述了这样做的理由）的一种公共机制。由于 XrML 规范不允许在 <xrml:license> 元素上进行属性扩展，所以本规范为引用许可证定义了一个独立的机制。XrML 规范允许通过使用具有 licenseId 属性的 URI 命名许可证。因此，该规范定义了全局名称空间限定符的属性 xmltok:RefType ，这样是为了与 <wsse:Reference> 元素一起使用（用在一个 <wsse:SecurityTokenReference> 元素内）。使用这个属性，引用可以指定期望的令牌类型，从而允许处理特定令牌的匹配规则。具体说来就是，如果 xmktok:RefType 的属性值为“xrml:license”，则 URI 属性指的是 <xrml:license> 元素，该元素的 licenseId 属性是由 URI 属性指定的。

下面的示例说明了一个带有 [XML Signature] 的消息，它引用了一个 XrML 令牌。

<S:Envelope xmlns:S="...">
    <S:Header>
        <wsse:Security xmlns:wsse="...">
            <xrml:license xmlns:xrml="..."
                          licenseId="urn:SecurityToken-ef375268"/>

                ...
            </xrml:license>
            <ds:Signature xmlns:ds="...">
                ...
                <ds:KeyInfo>
                   <wsse:SecurityTokenReference>
                     <wsse:Reference URI="urn:SecurityToken-ef375268"
                                     xmltok:RefType="xrml:license"
                                     xmlns:xmltok="..."/>
                   </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
            ...
        </wsse:Security>
    </S:Header>
    <S:Body>
        ...
    </S:Body>
</S:Envelope>

4.4. 主体确认

如前所述，[WS-Security] 规范没有强制规定必须如何进行主体确认。而且，XrML 规范还考虑到了多种类型的确认。如果没有使用安全的传输，那么强烈推荐使用基于密钥的确认机制。

XrML 断言令牌的任何处理器都必须遵循在 XrML 规范中定义的所要求的验证和处理规则。

下表说明了几种不同的确认机制是怎样被处理的：

机制	“推荐”处理规则
<xrml:keyHolder>	发送方（主体）包含一个 XML Signature，该 XML Signature 可以用被引用的安全性令牌中的密钥信息进行验证。
<xrml:allPrincipals>	发送方（主体）包含一个可以被验证的 XML Signature 。实现可以选择不需要主体来认证。

4.5. 错误代码

当使用 XrML 令牌时，推荐使用在 [WS-Security] 规范中定义的错误代码。不过，如果愿意的话，实现可以使用私有名称空间中定义的定制的错误。应注意不要在返回的错误中引入安全性薄弱环节。

4.6. 威胁模型与对策

除了那些已经识别出的对 XrML 或带有其它安全性令牌的 WS-Security 的威胁之外，将 XrML 断言令牌与 [WS-Security] 一起使用并不会引入新的威胁。

使用 WS-Security 中所描述的完整性和机密性机制可以防止消息被篡改和窃听。重播攻击可以通过使用消息时间戳记与高速缓存来解决，也可能通过使用其它特定于应用程序的跟踪机制来解决。对于其所有权是通过使用密钥进行验证的 XrML 断言令牌来说，一般可以缓和中间人攻击。

强烈推荐对所有相关的和不可改变的消息数据进行签名。

应该注意到，可以利用传输层的安全性来保护消息与安全性令牌。

回页首

安全性注意事项

为了使信任者有信心认为它们能够信任基于 XML 的令牌，令牌的发出者应该使用 [WS-Security] 这个文档所概述的机制来对那些令牌进行签名。对这些令牌进行签名使信任这些令牌的各方有信心相信这些令牌没有被伪造或篡改。强烈推荐将 WS-Security 头字段中所使用的 <saml:Assertion> 元素和 <xrml:license> 元素进行签名（或者使用在 SAML 规范或 XrML 规范中定义的令牌签名机制，或者使用 WS-Security 规范中定义的头元素签名机制，或者两种机制都用也可）。

应该注意到，引用未签名的或不安全的令牌意味着会有潜在的安全性隐患，从而使遭受攻击的可能性增大。

参考资料