WS-Federation：活动请求方概要
版本 1.0
2003 年 7 月 8 日
作者
Siddharth Bajaj，VeriSign
Giovanni Della-Libera，Microsoft
Brendan Dixon，Microsoft
Maryann Hondo，IBM
Matt Hur，Microsoft
Chris Kaler (Editor)，Microsoft
Hal Lockhart，BEA
Hiroshi Maruyama，IBM
Anthony Nadalin (Editor)，IBM
Nataraj Nagaratnam，IBM
Andrew Nash，RSA Security
Hemma Prafullchandra，VeriSign
John Shewchuk，Microsoft
本页内容
版权声明
_ 2001-2003 International Business Machines Corporation, Microsoft Corporation, BEA Systems, Inc., RSA Security, Inc., VeriSign, Inc.保留所有权利。
如 果您在 WS-Federation：活动请求方规范的完整副本或您制作的部分副本中包含了以下内容，IBM、Microsoft、BEA Systems, Inc.、RSA Security, Inc. 和 VeriSign, Inc.（统称为“作者”）将据此授予您以任何媒介形式复制和公开 WS-Federation：活动请求方规范的权限，且不需要任何费用或特许权使用费：
| • | 指向此处规范的链接或 URL |
| • | WS-Federation：活动请求方规范中所注明的版权声明。 |
除了以上授予的版权许可证以外，作者没有明示或暗示地授予任何知识产权（包括他们拥有或控制的专利）的许可证。
WS -Federation：活动请求方规范是“按原件”提供的，作者不作以下任何明示或暗示的陈述或担保：包括（但不限于）对适销性、特殊用途的适用性、无 侵权或所有权的担保；及担保 WS-Federation：活动请求方规范内容适用于任何用途，且这些内容的实施将不会侵犯任何第三方的专利、版权、商标或其他权利。
作者将不对由于任何使用或分发 WS-Federation：活动请求方规范产生的（或与之相关的）任何直接、间接、特殊、偶然或必然的损失负责。
WS-Federation：活动请求方规范在最终发布以前可能会发生变化，因此用户在使用此规范的内容时必须注意。
在获得明确的书面授权以前，不得以任何方式使用作者的名称和商标，包括与该规范或其内容相关的广告或宣传。WS-Federation：活动请求方规范的版权所有权任何时候都由作者保留。
没有以暗示、禁止反言或其他方式授予其他权利。
摘要
此规范定义了活动请求方（如支持 SOAP 的应用程序）如何使用 WS-Federation 中定义的交叉信任领域身份、身份验证和授权联合机制。
模块结构
通 过使用 XML、SOAP 和 WSDL 可扩展模型，各种 WS* 规范旨在通过互相组合来提供丰富的 Web 服务环境。WS-Federation：活动请求方自身不为 Web 服务提供完整的安全解决方案。WS-Federation：活动请求方是一个用于与其他 Web 服务和应用程序特定的协议结合使用的构造块，以适应各种各样的安全模型。
状态
此 WS-Federation 活动请求方规范是最初公开的草拟版，仅作为查看和评估用。BEA、IBM、Microsoft、RSA Security 和 VeriSign 希望在不远的将来能征求您的稿件和建议。BEA、IBM、Microsoft、RSA Security 和 VeriSign 不以任何方式做出关于此规范的担保或陈述。
目录
1. 引言
WS-Federation 规范定义了一种联合不同信任领域间的身份、身份验证和授权的集成模型。该规范定义了如何将联合模型应用于活动请求方（如 SOAP 应用程序）。
1.1. 目标和需求
此规范的主要目标是定义对那些应用于活动请求方的身份、身份验证和授权信息进行联合的机制。
1.1.1 需求
以下列表指出了此规范的关键实施要求：
| • | 在活动请求方之间支持身份、身份验证和授权数据的共享 |
| • | 代理活动请求方环境中的信任和安全性令牌交换 |
| • | 活动请求方环境中身份信息和其他属性的可选隐藏或保护 |
1.1.2. 非目标
以下主题则不属本文档讨论的范围：
| • | 消息安全性或信任建立/验证协议的定义 |
| • | 新安全性令牌格式的规范 |
1.2. 标记约定
本 文档中的关键字“必须 (MUST)”、“绝不可以 (MUST NOT)”、“必需的 (REQUIRED)”、“将 (SHALL)”、“将不 (SHALL NOT)”、“应该 (SHOULD)”、“不应该 (SHOULD NOT)”、“推荐的 (RECOMMENDED)”、“可以 (MAY)”和“可选的 (OPTIONAL)”将按 RFC 2119 中说明的进行解释。
当描述抽象数据模型时，此规范使用 XML 信息集中使用的标记约定。具体来说，抽象属性名称始终出现在方括号中（如 [some property]）。
当 描述具体的 XML 架构时，此规范使用 WS-Security 的标记约定。具体来说，元素的 [children] 或 [attributes] 属性的每个成员都是使用类似于 XPath 的标记（如 /x:MyHeader/x:SomeProperty/@value1）描述的。使用 {any} 说明存在元素通配符 (
1.3. 命名空间
本文档使用到以下命名空间：
| 前缀 | 命名空间 |
S | |
wsse | |
wsu | |
wp |
1.4. 术语
以下定义概述了本规范中的术语及用法。
活动请求方 － 联合中的活动请求方是一个能发出（并接收）如 WS-Security 和 WS-Trust 中描述的 SOAP 消息的应用程序（可能是一个 Web 浏览器）。
声明 (Claim) － 声明 是实体所作的声明（如名称、标识、关键字、组、权限、功能、属性等）。
安全性令牌 (Security Token) － 安全性令牌 表示声明的集合。
已签名安全性令牌 (Signed Security Token) – 已签名安全性令牌 是由特定的权威机构断言并加密签名的安全性令牌（如 X.509 证书或 Kerberos 票证）。
所有权证明令牌 (Proof-of-Possession Token) － 所有权证明令牌 是一种包含发送方用来证明所有权证明数据的安全性令牌。一般情况下（但不是专有的），所有权证明信息是经过使用只有发送方和接收方才知道的密钥加密过的。
摘要 (Digest) – 摘要 是八进制流的加密校验和。
签名 (Signature) － 签名 是一个以某种方式使用加密算法计算并绑定到数据的值，且该数据的预期接收者可以使用此签名来验证数据在签名者签署它以后没有被修改。
安全性令牌服务 (STS) － 安全性令牌服务 是一种颁发安全性令牌的 Web 服务（请参看 WS-Security 和 WS-Trust）。也即 STS 基于证据对信任该 STS 的实体做出声明。若要传递信任，服务就需要证据，如某个安全性令牌或安全性令牌组，并且使用它自己的信任声明颁发一个安全性令牌（需要注意的是，对于某些 安全性令牌格式，这可能只需对原始令牌进行重颁发或共同签名）。这也形成了信任代理的基础。
信任 (Trust) － 信任 是一个实体希望依赖于第二方实体以预期的方式执行一组操作和/或对一组主题和/或范围做出一组断言的特性。
信任域/领域 (Trust Domain/Realm) － 信任域/领域 是一个安全性空间，其中的请求目标能够判断来自某个源的特定凭据集是否满足该目标的相关安全性策略。目标可以遵从对第三方的信任，这样，就可以将受信任的第三方包括到信任领域 (Trust Realm) 中。
直接信任 (Direct Trust) － 直接信任 是当依赖方将由请求方发送的令牌中的所有声明（或一些声明子集）作为 true 接受时的信任方式。
直接代理信任 (Direct Brokered Trust) － 直接代理信任 是当一方在信任第二方，第二方依次信任或担保第三方时的信任方式。
间接代理信任 (Indirect Brokered Trust) － 间接代理信任 是直接代理信任的变体，第二方与第三方（或其他方）在其中进行协商，用于评估对第三方的信任的信任方式。
签名验证 (Signature validation) － 签名验证 是验证接收的消息与发送的消息是否相同的过程。
发送方身份验证 (Sender Authentication) － 发送方身份验证 是 Web 服务主角/角色之间的加强的身份验证，以指示 Web 服务消息（及其相关数据）的发送方。需要注意的是，如果存在身份验证的中介体，消息可能会有多个发送方。还要注意的是，如何判断谁是消息的第一创建人是依 应用程序而定的（且不属本文范围），因为消息发信方可能独立于或隐藏在身份验证发送方的后面。
领域或域 (Realm or Domain) － 领域 或域 表示安全性管理或信任的单个单元。
联合 (Federation) － 联合 是由领域集合（至少两个）建立的受信任关系。信任的级别可能会变化，但通常包括身份验证，并可能包括授权。
标识提供商 (Identity Provider) － 标识提供商 是一个担当针对终端请求方的对等实体身份验证服务，以及针对服务提供商的数据源身份验证服务（一般是安全性令牌服务的扩展）的实体。
单一登录 (SSO) － 单一登录 是身份验证序列的优化，用以去除终端请求方面临的重复操作的负担。为了方便 SSO，被称作标识提供商 (Identity Provider) 的元素可以代表请求方担当一个代理，以向请求关于此请求方信息的第三方提供身份验证活动的证据。这些标识提供商是受信任的第三方，并且需要得到请求方（以 维护请求方身份信息，因为这些信息丢失可能会导致请求方身份的泄露）和 Web 服务双方的信任，Web 服务可能基于 IP 提供的身份信息的完整性授予对宝贵资源和信息的访问权限。
标识映射 (Identity Mapping) － 标识映射 是一种创建身份属性之间关系的方法。一些标识提供商可能会利用 id 映像。
注销 － 注销 是主体表明它们将不再使用其令牌且领域中的服务可能破坏此主体令牌缓存的过程。
2. 模型
WS-Federation 规范定义了一个模型和消息集合，用于在不同信任领域间代理信任并联合身份和身份验证信息。本章描述了如何将该模型应用于活动请求方（如 Web 服务请求方）。
WS-Federation 中描述的联合模型构建于 WS-Security 和 WS-Trust 建立的基础之上。因此，此概要定义了在活动请求方上下文内请求、交换及颁发安全性令牌的机制。
此规范中定义的模型允许支持不同（但兼容）的消息交换。例如，资源可以担当它自己的安全性令牌服务 (STS)，而并不使用一个单独的服务（或甚至 URI），从而减少一些步骤。后续的概要有望定义成具有特定交换模式的特性。
3.1. 单一登录
因为活动请求方 能够发出它们自己的消息，所以它们可以利用 WS-Security、WS-Trust 和 WS-Federation 内定义的机制。
在 高层次上，策略可以用来表明通信需求。请求方可以提前或通过错误响应从服务中获取策略。一般来说，在请求方对自身进行身份验证时，系统要求它们从其标识提 供商（或 STS）处获得安全性令牌（或令牌）。IP/STS 通过联合方生成一个供使用的安全性令牌。该过程是通过使用 WS-Trust 中定义的机制来完成的。有些情况下，目标服务担当它自己的 IP/STS，这使得无需与其他服务进行通信。否则，请求方可能需要从服务特定的或服务所需的标识提供商或安全性令牌服务处获得其他的安全性令牌。下图说 明了一种可能的流程。
然而，以上示例并没有说明这点，即用于安全性令牌的 WS-Trust 消息可能包括对请求方的质询。有关其他信息，请参考 WS-Trust。
3.2. 注销
就像针对某个活动请求方登录不具代表性一样，它对注销 也不具代表性。然而，对于那些需要注销的情况而言，则“可以”使用 WS-Federation 中定义的注销消息。
在 需要联合注销消息的情况中，请求方的 IP/STS“应该”保持对其颁发令牌领域 — 特别是这些领域的 IP/STS（或资源，如果不同）的跟踪。当在请求方的 IP/STS 上接收注销时，此请求方的 IP/STS 就负责向有关方和授权方发出联合注销消息。发生此操作采用的确切机制取决于 IP/STS，但强烈“建议”使用 WS-Federation 中定义的注销消息。
当在某个领域中接收到联合的注销消息时，该领域“应该”清除所有的缓冲信息，并删除下图中说明的所有相关状态：
3.3. 属性
对于活动请求方，属性服务是通过 WS-Federation 中描述的 WS-Policy 进行标识的。Web 服务和其他授权方可以使用由特定属性服务定义的消息获得或者甚至更新属性。
下 图说明了一个由请求方向 Web 服务发出请求的情况。请求可能包括请求方的策略，或者可能已被缓存在服务中，或者请求方可能使用 WS-PolicyExchange。Web 服务向请求方的属性服务发出请求，以获得一些属性的值，WS-Policy 可以用来描述属性服务的位置。该服务被授权，属性即被返回。请求得到处理，并向请求方返回响应。
3.4. 假名 (Pseudonym)
对于活动请求方而言，假名服务是通过 WS-Federation 中描述的 WS-Policy 来标识的。服务和其他授权方可以使用 WS-Federation 中定义的消息来获取或管理假名。
下 图说明了请求方向某个 Web 服务发出请求的情况。该请求可能包括请求方的策略和请求方假名服务的位置，或它可能已被缓存在 Web 服务中。Web 服务向请求方的假名服务发出请求，以获取由安全性令牌授权的假名。授权此 Web 服务，假名即被返回。请求得到处理，并向请求方返回响应。
如 WS-Federation 中所描述的，假名和 IP/STS 可以作为令牌颁发过程的一部分进行交互。下图说明了一种情况，其中，请求方先前已针对特定的领域关联了一个假名和安全性令牌。当请求方请求一个该域/领域 的安全性令牌时，系统就获得其假名和令牌，并返回给请求方。请求方就使用这些安全性令牌来访问 Web 服务。
4. 语法
此部分定义了以上模型中描述的联合机制的语法。
4.1. 请求安全性令牌
安全性令牌是使用 WS-Trust 规范中定义的
4.2. 返回安全性令牌
安全性令牌是使用 WS-Trust 规范中定义的
4.3. 注销语法
显式的注销通知是使用 WS-Federation 规范中定义的
同样地，联合的注销消息使用相同的消息元素。
4.4. 属性请求
属性是使用 WS-Federation 规范所描述的属性服务所特有的消息来进行请求和更新的。此规范并不强制使用特定的属性存储技术。
4.5. 假名请求
假名是使用 WS-Federation 规范中描述的消息和机制来进行请求和更新的。
5. 详解示例
此部分提供了一个本规范中定义的协议的详解示例。确切流程可能会有很大不同；但是，以下图表和说明描述了一个通用 的事件序列。
在此情况中，活动请求方试图访问一个要求安全性身份验证要经过资源的安全性令牌服务进行验证的服务。
步骤 1：获取策略
如果请求方还没有服务策略，就可使用 WS-MetadataExchange 中定义的机制获取该策略。
步骤 2：返回策略
请求的策略是使用 WS-MetadataExchange 中定义的机制返回的。
步骤 3：请求安全性令牌
请求方使用 WS-Trust (
步骤 4：颁发安全性令牌
IP/STS 使用 WS-Trust（
步骤 5：请求安全性令牌
请求方使用 WS-Trust (
步骤 6：颁发安全性令牌
Web 服务的 IP/STS 使用 WS-Trust (
步骤 7：发送安全的请求
请求方使用 WS-Security 中描述的颁发令牌向附加并保护此消息的服务发送请求。
步骤 8：返回结果
服务使用它的安全性令牌发出一个安全回复。
6. 其他示例
本部分描述了其他活动请求方情况的交互式图表。
6.1. 无资源 STS
下图说明了以上的资源访问情况，但没有资源 STS。也即 Web 服务担当它自己的 STS：
6.2. 第三方 STS
下图说明了以上的资源访问情况，但信任是通过第三方 STS 代理的：
需要注意的是，第三方 IP/STS 是通过策略或某个带外机制决定的。
6.3. 委派的资源访问
下图说明了某个资源代表第一方资源访问来自另一方资源的数据：
本示例中，请求方使用 WS-Trust 中定义的
7. 安全性令牌
当接受到安全性令牌时，接收者“应该”：
| • | 验证令牌是否经正确格式化 |
| • | 验证 STS 签名 |
| • | 验证令牌有效性时间间隔 |
| • | 验证策略请求的属性，如所需的身份验证类型、从身份验证时刻起的最大时间（如密码必须在 1 个小时以内提交），以及身份属性等。 |
本章描述了特定于令牌格式的需求，但并不强制特定令牌类型的用法。
7.1. X.509v3
此规范对 X.509 令牌设置了以下要求：
| • | 除使用安全通道来传递令牌之外，令牌“必须”在整个令牌期间包含颁发机构的名称和颁发机构的签名。也即通过各断言的签名元素。需要注意的是，“建议”使用签名，即使是使用安全通道也是如此。 |
| • | 令牌“必须”包含主题标识符，以唯一地标识出被授予此令牌的主题。X.509 并不指定 Principal 字段的规则。遵守此规范的 X.509 令牌“应该”确保颁发的主体在各领域中是唯一的，并且该领域“应该”从主体名称中派生出来。 |
| • | 令牌“可以”包含初始身份验证的时间、有效性时间间隔以及执行的身份验证类型。 |
| • | 令牌“可以”包含证书吊销信息 (Certificate Revocation Information)，如 CRL 分发点 |
| • | X.509 证书“必须”携带在 wsse:BinarySecurityToken 元素（它的 ValueType 是 wsse:X509v3）内。 |
7.2. Kerberos
此规范对 Kerberos 令牌设置了以下要求
| • | Kerberos 票证授权的票证“必须”携带在 wsse:BinarySecurityToken 元素（它的 ValueType 是 wsse:Kerberosv5TGT）内。 |
| • | Kerberos 服务票证“必须”携带在 wsse:BinarySecurityToken 元素（它的 ValueType 是 wsse:Kerberosv5ST）内。 |
| • | 使用的对称密钥“应该”从所需领域中派生出来。 |
7.3. XrML
此规范对 XrML 令牌设置了以下要求：
| • | 处理器“必须”支持带或不带包含的签名的 xrml:issuer 元素。除非 xrml:license 传送密钥（直接或间接），否则处理器“不应”包含所含的签名。 |
| • | 包含一个或多个 xrml:issuer 元素中签名的令牌“必须”声明 xrml:license 元素上的所有 XML 命名空间。 |
| • | 处理器“必须”包括一个用于标识 xrml:details 下颁发者的 xrml:issuer 元素。 |
| • | 当 xrml:license 令牌传送密钥（直接或间接）时，处理器“必须”在 xrml:issuer 元素内包含一个 xrml:validityInterval。xrml:validityInterval“必须”同时包含 xrml:notBefore 和 xrml:notAfter 元素。 |
| • | 令牌“应该”包含指示使用范围（如资源或领域）的接收者标识符 — 这是通过 grant resource 表示的，并且默认假定使用了此领域。 |
7.4. SAML
此规范对 SAML 令牌设置了以下要求：
| • | 除非是使用安全通道传递该令牌，否则令牌“必须”包含颁发机构在整个令牌期间的签名。也即通过 SAML 断言的签名元素。需要注意的是，“建议”使用签名，即使是使用安全通道也是如此。 |
| • | 令牌“必须”包含主题标识符，以唯一地标识出被授予此令牌的主题。SAML 并不指定 NameIdentifier 元素的规则。遵守此规范的 SAML 断言“应该”确保颁发的标识符在各领域中是唯一的，并且该领域“应该”从主题标识符中派生出来。 |
| • | 令牌“应该”包含指示使用范围（如资源或领域）的接收者标识符 — SAML 断言中的 AudienceRestriction 或 Recipient 元素。 |
| • | 令牌“必须”包含初始身份验证的时间、有效性时间间隔以及执行的身份验证类型。SAML 断言中的有效性时间间隔是通过 Conditions 元素的 NotBefore 和 NotOnOrAfter 属性来满足的。初始身份验证类型和时间是通过 AuthenticationStatement 元素的属性来包含的。 |
| • | 令牌“可以”包含其他的标识信息。如果包含了其他信息，则描述这些其他信息的架构“必须”能被接收者所理解，否则，该令牌“必须”被拒绝。 |
9. 安全考虑事项
本部分概述了未在 WS-Federation 和其他 Web 服务安全性规范中指出的安全考虑事项。
如果安全性令牌不是自我保护的，它就“应该”被包括在某种形式的消息完整性机制（如 WS-Security 中说明的机制）中。
如果涉及到隐私，则“可以”使用 WS-Security 中描述的机制，为授权的接收者加密安全性令牌。
10. 致谢
此规范的制订是许多个人和团体共同努力的结果，包括：
Tim Hahn，IBM
Heather Hinton，IBM
Bronislav Kavsan，RSA Security
Anthony Moran，IBM
Robert Philpott，RSA Security
Yordan Rouskov，Microsoft
Shane Weeden，IBM
Jeff Spelman，Microsoft
11. 参考资料
[关键字]
S. Bradner，Key Words for Use in RFCs to Indicate Requirement Levels， RFC 2119，Harvard University，1997 年 3 月。
[SOAP]
W3C 纪要， SOAP:Simple Object Access Protocol 1.1，2000 年 5 月 8 日。
SOAP 1.2，草案 http://www.w3.org/TR/soap12-part0/
SOAP 1.2，草案 http://www.w3.org/TR/soap12-part1/
SOAP 1.2，草案 http://www.w3.org/TR/soap12-part2/
[URI]
T. Berners-Lee、R. Fielding 和 L. Masinter，Uniform Resource Identifiers (URI):Generic Syntax， RFC 2396，MIT/LCS、U.C. Irvine、Xerox Corporation，1998 年 8 月。
[WS-Federation]
"Web Services Federation Language，BEA、IBM、Microsoft、RSA Security 和 VeriSign，2003 年 7 月。
[WS-Security]
"Web Services Security Language，IBM、Microsoft 和 VeriSign，2002 年 4 月。
"WS-Security Addendum，IBM、Microsoft 和 VeriSign，2002 年 8 月。
"WS-Security XML Tokens，IBM、Microsoft 和 VeriSign，2002 年 8 月。
[WS-Policy]
"Web Services Policy Framework，BEA、IBM、Microsoft 和 SAP，2002 年 12 月。
[WS-PolicyAttachment]
"Web Services Policy Attachment Language，BEA、IBM、Microsoft 和 SAP，2002 年 12 月。
[WS-PolicyAssertions]
"Web Services Policy Assertions Language，BEA、IBM、Microsoft 和 SAP，2002 年 12 月。
[WS-Trust]
"Web Services Trust Language，IBM、Microsoft、RSA 和 VeriSign，2002 年 12 月。
[WS-SecureConversation]
"Web Services Secure Conversation Language，IBM、Microsoft、RSA 和 VeriSign，2002 年 12 月。
[WS-SecurityPolicy]
"Web Services Security Policy Language，IBM、Microsoft、RSA 和 VeriSign，2002 年 12 月。
[XML-ns]
W3C 推荐，Namespaces in XML，1999 年 1 月 14 日。
No comments:
Post a Comment