通过

Web 服务世界中的标识联合

版权声明

 

© 2001-2003 国际商务机器公司，Microsoft公司。 保留所有权利。

抽象

本文档介绍了联合标识管理方面的问题，并介绍了基于 WS-Security 路线图和其他相关 Web 服务规范中概述的 Web 服务规范的综合解决方案。

本白皮书中所述的方法将在 WS-Federation 规范中进一步定义，将标识提供者作为安全令牌服务的类引入。 因此，它使用 WS-Trust 和 WS-Federation 机制在联合和之间创建和代理信任。 此外，还定义了用于单一登录和注销的机制、基于授权和隐私策略的属性共享，以及对假名（在不同站点/联合中使用的别名）的集成处理。

在一起，本文中确定的规范提供了一组全面的集成协议，用于通过组合其他安全和 Web 服务规范在联合中和跨联合体提供安全可靠的事务处理消息。

摘要

在过去的几年里，Web 应用程序从简单的内容交付应用程序演变为复杂的业务生产力工具，以及企业内部和跨企业的应用程序集成机制。 Web 和 Web 服务的增长表明，需要对许多技术问题提供开放和可互操作的解决方案。

本文档重点介绍一组特定的安全问题。 其中包括：

如何确定正确的安全标识和位置 Web 服务：组织需要一种标准方法来让服务请求者（客户和合作伙伴）安全地 找到给定业务的正确 Web 服务，并为业务服务提供商安全地识别和公开正确的 Web 服务，以便仅向授权的请求者公开正确的 Web 服务。

如何确定用于启用 Web 服务安全调用的凭据集：业务服务请求者使用正确的身份验证、授权和权利集安全地调用 Web 服务的方法。

如何安全地联合 Web 服务：允许企业直接为在其他（合作伙伴）企业或机构注册的客户提供服务的标准方法。 在服务联合中，企业可以从用户的主组织（或信息提供服务）获取有关用户的信任信息。 业务不需要注册和维护该用户的标识，并且用户不必获取并记住新的登录名，以便与业务交互。

如何启用跨企业和跨域信任：建立和反映组织之间的信任的标准方法。 这是联合服务的一个关键问题。

如何启用联合标识和属性映射：用于将有关外国用户（例如业务合作伙伴中的用户）的受信任信息映射到企业现有服务可以使用的身份验证和授权信息的充分理解机制和过程。

如何启用安全、可靠事务：在安全、可靠和事务处理上下文中交换消息的标准方法。 以前的规范（例如 WS-ReliableMessaging 和 WS-Transaction）为可靠的消息交换和业务事务提供支持。 本文档讨论联合安全支持。

IBM、Microsoft和我们的合作伙伴打算与客户、合作伙伴和标准机构合作，改进此处所述的规范，并确保这些规范与 Web 服务体系结构的其他元素很好地组合。 为确保实现本文中所述的各种建议规范的互操作性和一致实施，IBM、Microsoft和我们的合作伙伴将与标准组织、开发人员社区和行业组织（如 WS-I.org）密切合作，以开发可向工具供应商提供指导的互操作性配置文件和测试。

由于术语因技术而异，本文档定义了多个术语，这些术语可以一致地应用于不同的安全格式和机制。 因此，此处使用的术语可能与其他规范不同，并且已定义，以便读者可以将术语映射到其首选词汇。 请参阅 术语 部分，其中汇总了这些术语及其定义和用法。

1 简介和动机

联合标识管理对个人和企业来说是一个重大挑战。 本章探讨该问题，然后确定受其影响各方，并得出可行的解决方案的关键目标。

联合标识管理问题是什么？

公司的价值网络跨越许多组织、系统、应用程序和业务流程。 多个不同的成分构成了此值网络，包括客户、员工、合作伙伴、供应商和分销商。 没有一家实体或公司可以声称在此端到端价值网络中集中管理或控制其构成的标识信息。 即使在单个公司内，也可能存在多个权威的标识数据源，这些数据源需要在业务部门内独立自主管理。

作为跨公司协作的基础原则，这种集中化方法在电子商务协作、集成和自动化方面带来了重大摩擦，导致标识管理和效率降低。 通过集中化，管理用户标识生命周期的成本非常高。 大多数企业必须管理员工、业务合作伙伴和客户标识。 此外，业务与这些个人之间的关系会相当频繁地更改，每个更改都需要执行管理操作。

在某些情况下，企业希望将一些安全功能外包给管理标识的各方（正如他们今天在交易环境中对信用卡公司所做的那样），但他们不能这样做有两个原因：第一，没有第三方标识提供者为除消费者金融交易以外的市场提供服务，其次，没有业务和责任模型可以安全地依赖第三方标识提供者的服务以外的服务消费者金融交易。

其他企业希望利用他们维护的标识来实现其他业务交互。 但是，建立允许跨业务边界联合实体的信任机制是困难的。 此外，如果标识管理操作以与个人隐私权利冲突的方式发布或使用信息，则管理标识的企业越来越面临信誉损害或监管责任的风险。 这大大增加了管理标识的风险。

从个人的角度来看，存在多个身份，无论是个人身份还是专业身份。 个人还存在标识管理问题，因为无法重复使用标识。

联合标识管理提供跨公司业务灵活性，同时使公司能够卸载和简化标识管理成本。 这使公司能够追求最符合其业务模型、IT 策略和安全以及治理目标和要求的业务集成目标。

谁有联合标识管理问题？

由于缺乏安全的通信模型，主要集成障碍在于跨公司业务集成。 此问题影响广泛的公司，包括：

  • 使用标识信息的中型和大型组织向消费者提供服务（例如，基于 Web 的旅游服务的提供商）。
  • 相互开展业务的中型和大型组织需要交换有关个人身份的信息（例如，航空公司和租赁汽车机构，或医院和医疗保险提供商）
  • 需要跨企业集成业务应用程序的组织以及客户和供应商的产业链（例如供应链），并需要授权其员工代表组织进行交易。
  • 将服务（如 HR 和福利）外包给第三方但将自己的品牌应用到这些外包服务（例如，一个通过自己的内部 HR 门户为其员工提供多个退休计划或医疗计划选项的组织），因此必须与服务提供商共享员工身份信息。
  • 组织（中介、经纪人、聚合器）的商业模式由“拥有客户体验”驱动，原因为无中介。
  • 通过跨多个第三方提供商聚合服务来提供集成的品牌全服务标识驱动业务门户（金融服务、保险服务、订阅等）的组织。

如前所述，从事基于 Web 的活动的个人也遇到了此问题，即他们通常拥有大量必须创建和管理的独立标识。

目标

联合标识服务的主要目标是：

  • 通过减少重复工作来降低标识管理的成本;每个人的身份几乎总是由受信任的组织（如个人银行、雇主或医生）管理。
  • 利用这些现有标识管理器已经完成的工作，即向其他方提供相关标识信息的访问权限（根据需要和适当的隐私保护）。
  • 保留各方的自主性 - 标识经理选择的身份验证技术不应将该技术强加给依赖其标识信息的各方。 标识管理器选择的操作系统或网络协议或数据库不应对其合作伙伴施加相同的选择。
  • 尊重企业的预先存在的信任结构和合同。 注册以从标识提供者接收标识信息不得要求组织与标识提供者以外的任何方建立信任关系，并且不得要求采用任何特定的用户身份验证技术。
  • 通过尊重和严格执行用户首选项来保护个人的隐私，控制个人身份信息的使用，观察政府和区域隐私规则，寻求用户对新用途的同意，并实施强大的记录记录和问责机制，以确保遵守隐私做法。
  • 构建开放标准，为企业和个人启用安全的可靠交易。

2. 联合单一登录和标识管理

联合 的吸引力在于，它们旨在允许用户在给定的联合中无缝遍历不同的站点。 本文档专门讨论联合标识管理的问题，而不是一般联合（不仅仅是安全性）的更大问题。 由于联合参与者之间建立信任关系，一个参与者能够对用户进行身份验证，然后充当该用户的 颁发方。 其他联合参与者 信赖方。 也就是说，他们依赖于发布方提供有关用户的信息，而无需直接参与该用户。 在某些情况下，用户可能匿名给信赖方，例如，由于不同的身份验证机制和使用第三方身份验证机制。

Web 服务模型的灵活性和吸引力是其构建基块基础，公司可以轻松构建新服务，以交付创新的业务模型，或通过与合作伙伴、供应商、客户和员工紧密的关系更有效地链接其产业链网络。 仅当此类模型允许客户、合作伙伴和最终用户轻松地在支持这些服务的网站之间导航，而无需不断向各种网站进行身份验证或识别自己，或者冗余地维护业务联盟中的每个成员的个人信息时，才能成功。

遗憾的是，当前用于对用户进行身份验证和获取用户属性信息（例如信用卡信息）的方案通常强制用户注册每个感兴趣的业务，不断要求用户识别和验证自己（通常使用用户名和密码），并强制企业管理不受公司控制的大量快速变化的标识基础。 这种模式是采用 Web 服务的巨大障碍，对用户和企业来说都是一个头痛的问题。

普遍模式的另一个缺点是，给定业务可能不愿意将其部分客户信息“提供给业务合作伙伴”，希望维护和控制客户关系。

联合身份验证提供一种简单的灵活机制，用于识别和验证来自合作伙伴组织的用户，并为他们提供对该受信任联合中的网站的无缝访问，而无需使用密码重新进行身份验证。 此外，联合标准还处理提供受信任的属性（例如 X509 证书、X509v3 属性证书、Kerberos 令牌、SAML 断言）有关用户（例如，包括角色和组信息）的问题，这些属性允许隐私和特定于业务的规则。

可以使用一个简单的示例演示联合单一登录和标识的概念：

用户 John Doe 为名为 Pharma456.com 的制药公司工作;John 有一个具有 Pharma456.com 的帐户，需要进行身份验证才能 Pharma456.com 访问其资源。 作为员工，John 与公司有一定的好处，例如合作伙伴公司的帐户和服务。 在此示例中，公司的储蓄服务由名为 RetireAccounts.com（服务提供商）的金融服务公司管理，投资服务由名为 InvestAccounts.com（服务提供商）的公司管理。 若要访问合作伙伴中的资源，例如由 RetireAccounts.com 托管的保存门户，用户必须进行身份验证才能 RetireAccounts.com。 对 RetireAccounts.com 进行身份验证要求用户提供她的社会保障号码（SSN）、员工标识符（雇主颁发的唯一标识符-在本例中为 Pharma456.com）和个人 PIN 号（特定于 RetireAccounts.com）。

如果没有联合身份验证，John Doe 必须显式向 RetireAccounts.com 网站进行身份验证，以访问他的储蓄帐户，即使他已经向 Pharma456.com 进行身份验证，并通过 Pharma456.com 员工门户访问了 RetireAcounts.com Web 服务。

但是，使用联合单一登录 John Doe 可以登录到其员工门户，单击门户链接以访问合作伙伴站点（RetireAccounts.com）中的储蓄帐户信息，无需在合作伙伴网站上重新进行身份验证或提供其他信息。

联合身份验证还确保跨公司同一用户的不同标识可以使用联合管理技术在两家公司之间安全地链接。 联合参与者可以交换标识信息，以便信赖公司可以独立验证其域中用户的标识。

颁发域（Pharma456.com）和信赖域（联合服务提供商 RetireAccounts.com）之间的联合单一登录有助于安全且受信任的传输用户标识符和其他属性相关信息（如授权角色和组成员身份）以及 EmployeeID、SSN 和 PIN #等用户权利）。 联合标识管理定义信赖方（RetireAccounts.com）能够根据从颁发方收到的（受信任）信息确定用户的本地有效标识符的过程。 传输的详细信息可能涉及业务与用户源企业（以及辅助服务的消息）之间的多个消息，但这些消息以透明方式处理给用户。

若要启用联合身份验证，我们引入了标识提供者、属性服务和假名服务，如上图所示。

标识提供者（如 Pharma456.com、InvestAccounts.com 和 RetireAccounts.com）提供用于本地映射/索引的标识（例如帐户信息）。 通过使用信任和联合机制以及信任策略，这些标识允许联合身份验证自动共享和映射标识。

属性服务提供了一种联合访问联合标识的授权属性的方法。 在上面的示例中，当 John Doe 访问每个合作伙伴的门户时，门户服务可以访问 John 的属性（授权者），以便获取所需的信息并个性化体验。 为了确保隐私，John Doe 可以完全控制哪些属性有权访问哪些服务。 可以监视和记录这些属性访问，以确保符合与 Pharma456.com 员工建立的既定隐私策略。 我们不强制使用特定类型的属性服务，而是允许使用不同的服务，例如 UDDI。

信任机制为信赖方提供了将信任级别与颁发机构或标识相关联以及将其用于本地映射的方法。 但是，在某些情况下，隐私问题希望此映射不透明地映射到目标服务。 也就是说，目标一直知道它是基于约翰的本地角色的“John Doe”，但不知道或不知道全局身份。 假名服务提供了一种映射机制，可用于促进跨联合身份验证的受信任标识的映射，以保护隐私和标识。

联合标识管理（包括联合单一登录）比 Web 单一登录解决方案更广的概念。 虽然此示例重点介绍了 B2C 方案的用例，其中 Web SSO 是一项重要功能，但联合单一登录是一个更广泛的概念，使企业能够构建安全 B2B 和 B2C 电子商务的完整框架。

3. 联合标识模型

联合标识模型 构建并集成 Web 服务基础结构和安全规范，形成一致且可扩展的安全模型。 联合模型扩展了 WS-Trust 模型，以描述标识提供者如何充当安全令牌服务，以及如何将属性和假名集成到令牌颁发机制中，以提供联合标识映射机制。

总之，主体登录和注销标识提供者（或安全令牌服务）。 这可以通过显式消息完成，也可以隐式作为主体请求令牌来完成。 主体请求资源/服务和颁发的令牌的令牌可能表示主体的主要标识或适用于范围的一些假名。 标识提供者（或 STS）向感兴趣的（和已授权）收件人发出消息。 主体注册到属性/假名服务，添加和使用属性和假名。 服务可以使用提供的标识（可能匿名）查询属性/假名服务，这意味着请求信息的方具有不透明令牌，并且不知道真实标识）来获取有关标识的授权信息。

Web 服务安全规范

本文中所述的模型和方法利用白皮书中所述的规范，Web Services World 中的安全性：建议的体系结构和路线图。 下面汇总了每个关键规范：

  • WS-Security 介绍如何将签名和加密标头附加到 SOAP 消息。 此外，它还介绍如何将安全令牌（包括 X.509 证书和 Kerberos 票证）等二进制安全令牌附加到消息。
  • WS-Policy 表示一组规范，这些规范描述了中介和终结点（例如所需的安全令牌、支持的加密算法、隐私规则）以及如何将策略与服务和终结点关联的安全（以及其他业务）策略的功能和约束。
  • WS-Trust 描述了信任模型的框架，该框架使 Web 服务能够通过请求、颁发和交换安全令牌来安全地互操作。
  • WS-Privacy 将介绍 Web 服务和请求者如何声明隐私首选项和组织隐私实践声明的模型。
  • WS-SecureConversation 介绍如何管理和验证双方之间的消息交换，包括安全上下文交换以及建立和派生会话密钥。
  • WS-Federation 介绍了如何在异类联合环境中管理和代理信任关系，包括对联合标识的支持、属性共享和管理假名。
  • WS-Authorization 将介绍如何管理授权数据和授权策略。

此外，其他几个关键 Web 服务规范完成了规范的基础层：

  • WS-Addressing 介绍如何指定消息的标识和寻址信息。
  • WS-MetadataExchange 介绍如何在服务和终结点之间交换元数据，例如 WS-Policy 信息和 WSDL。
  • WS-ReliableMessaging 介绍如何确保在存在不可靠的网络的情况下可靠传递消息。
  • WS-Transactions 和 WS-Coordination 介绍如何在 Web 服务消息交换过程中启用事务处理操作。

上述规范和互操作性配置文件的组合将使客户能够轻松地构建可互操作的安全可靠事务处理 Web 服务，这些服务通过组合联合和安全规范与其他 Web 服务规范来集成和跨联合体集成。

配置 文件

本文介绍可在不同环境中使用的常规模型。 具体而言，此模型可用于由被动请求程序（例如 Web 浏览器）或主动请求程序（如 SOAP 请求程序）组成的环境中。

联合规范提供一般模型和框架;配置文件描述如何在这些不同的环境中应用模型。 可以为将模型集成到其他环境指定其他配置文件。

每个配置文件规范都定义了如何将 WS-Federation 中的机制应用于给定环境（例如被动或主动请求程序）。

因此，本文中所述的机制（标识提供者、登录/注销、安全令牌、属性、假名等）适用于被动请求方（如 Web 浏览器）和主动请求者（如充当客户端和服务）以及将来可能定义的其他配置文件。

标识提供者

联合从标识的概念开始。 也就是说，请求者或请求者的委托（标识提供者是该标识数据的权威所有者）断言标识，标识提供者验证此断言。 然后，联合身份验证成为标识提供者与依赖提供者标识确定的人员之间的信任（直接、中转和委托）的功能。 有时，信赖方需要能够关联来自多个提供程序的标识，例如，在检查、信用卡和驾驶执照上关联标识。

安全令牌服务（STS）是一种通用服务，它使用通用模型和一组消息来颁发/交换安全令牌。 因此，任何 Web 服务本身都可以通过支持 WS-Trust 规范来成为 STS。 因此，有不同类型的安全令牌服务提供不同的补充服务。 标识提供者（IP） 是一种特殊类型的安全令牌服务，它至少执行对等实体身份验证，并且可以在颁发的安全令牌中发出标识或附属声明。 请注意，在许多情况下，IP 和 STS 可互换，本文档中的许多引用都标识这两者。

联合模型基于 WS-Trust 中定义的框架，利用令牌颁发和交换机制来包括颁发和联合标识。

以下示例演示了 IP 和 STS 访问服务的可能组合。 在此示例中，（1）请求者从其 IP（Business456.com）获取标识安全令牌，然后将断言（安全令牌）提供给 STS for Fabrikam123。 如果 Fabrikam123.com 信任 Business456.com 并批准授权，STS 会向请求者返回访问令牌。 然后，请求者 （3） 对请求使用访问令牌来 Fabrikam123.com。

在此示例中，步骤 1 中的响应由 Business456.com（受信任的 IP）签名，响应中返回的安全令牌相对于 Fabrikam123.com（例如颁发了该令牌）。

下面讨论的替代模型允许服务 Fabrikam123.com 向假名服务注册安全令牌，并在需要时提取此假名。 这允许服务管理映射，并且仍为请求者提供隐私级别。

单一登录和 Sign-Out

本文和 WS-Federation 规范中介绍的模型允许不同的 用户会话概念，如服务托管和请求者管理的。 服务管理的会话的一个示例是在 Web 浏览器会话中创建和管理 Cookie。 请求者管理的会话的一个示例是 Web 服务请求程序，该请求程序获取令牌并将其一段时间使用，然后在令牌过期前放弃令牌。 引入了 注销 的概念，以允许不同的配置文件指定这些转换如何应用于每个配置文件。

单一登录 的目的是建立访问联合域/领域 Web 中的资源所需的安全令牌。 同样，联合注销 用于清理联合中可能存在的任何缓存状态和安全令牌。 若要启用此功能，需要机制向已授权的登录和注销操作的授权方提供标识提供者颁发的联合登录和注销消息（从而允许他们执行任何必要的设置/清理操作）。

属性和假名

如前所述，希望能够获取有关标识（或任何联合资源）的信息（例如，提供“hello”问候或获取请求者的邮政编码来个性化体验），这可由属性服务提供。 此规范允许使用不同类型的属性服务，例如 UDDI。

这些信息必须受授权规则和隐私语义的约束。 同样，预计不同的属性将以不同的方式共享，并具有不同程度的隐私和保护（例如名字与姓氏）。 因此，每个属性表达式应能够表达其自己的访问控制策略，并且策略应考虑到可以为范围说话的关联范围（s）和主体。 例如，最终用户（人员）可能希望设置以下内容：“我的 Intranet 中的服务可能有权访问我的姓氏，而其他服务不能未经我明确权限”。

属性服务可以利用现有存储库，并提供某种级别的组织或上下文。 在组织命名空间中，将注册单个主体以及一组属性属性（实质上是名称/值对，其中名称是字符串属性名称，并且值是 XML 元素）与主体相关联。

请务必注意，每个属性可能都有自己的安全授权规则和隐私策略，允许主体控制向谁以及信息披露方式。

不同的属性服务具有不同的功能，这些功能在策略文档中表示。

除了属性服务外，还可能存在 假名服务。 假名服务允许主体在不同的资源/服务或不同域/领域具有不同的 别名。 某些标识提供者在其安全令牌中使用固定标识。 在某些情况下，需要确保令牌的匿名性;假名提供了一种机制来启用这种匿名性。 通常，必须由主体确定的可管理性权衡（即标识越多，管理问题的可能性就越大）。

应注意的是，在某些情况下，属性和假名服务将组合在一起，在某些情况下，它们将是单独的服务。

例如，请求者使用主要标识“Fred.Jones”向 Business456.com 进行身份验证。 然而，在 Fabrikam123.com，他被称为“弗雷多”。 为了保持匿名性，每当 Fred.Jones 登录时，Business456.com 都可以发出不同的标识，因此如下图所示的步骤 3 所示。 Fabrikam123.com 可以在 Fabrikam123.com（步骤 4）将“Freddo”设置为此请求者的本地名称，并具有可理解匿名名称的假名服务，从而提供到“Freddo”的映射。

下次请求者登录到 Business456.com IP（下面的步骤 1）时，可能会获得一个新的标识符，例如“XYZ321@Business456.com”（下面的步骤 2）。 由于 Business456.com IP 已讨论上述映射，因此 Fabrikam123.com 的 Web 服务现在可以请求 Fabrikam123.com（步骤 4 下面的步骤 4）的 XYZ321@Business456.com 假名，并返回他们之前设置的内容-在本例中为“Freddo@Fabrikam123.com”（下面的步骤 5）。

假名服务能够执行此操作，因为它能够将“XYZ321@Business456.com”回映射为 Business456.com 的已知标识，该标识与不同域/领域关联的假名。 此反向映射基于 IP 与假名服务之间的信任关系进行。 同样，资源与假名服务（可能由 IP 启动）之间存在信任关系，使资源能够获得和设置假名。

或者，标识提供者（或 STS）可以与假名服务一起操作。 也就是说，请求者向指定的信任域/领域或资源/服务请求其标识提供者（或 STS）提供令牌。 STS 查找假名，并颁发可在指定资源/服务中使用的令牌，如下所示：

如图所示，此联合标识模型中支持多种不同的方法，在此模型中，假名可用于帮助维护隐私。 每个提供商和主体都有不同的可管理性和隐私性特征，允许每个提供商和主体选择适当的解决方案来满足其特定要求。

4 摘要

在本文档中，我们提出了一种集成的 Web 服务联合模型，使各方能够发布和依赖来自其他成员的信息，并通过安全的方式跨联合身份验证代理信任和属性，以维护个人和商业隐私。

此模型与 Web 服务安全性和相关规范集成，以在请求程序与内部和跨联合的服务之间实现安全可靠的事务。

IBM 和Microsoft认为，这是定义全面的 Web 服务安全策略的重要一步。  它反映了我们迄今确定的挑战和解决方案。 随着我们继续与客户、合作伙伴和标准组织合作，确保 Web 服务的安全，我们预计，完成该策略需要更多想法和规范。 

术语

由于术语因技术而异，本文档定义了多个术语，这些术语可以一致地应用于不同的安全格式和机制。 因此，此处使用的术语可能与其他规范不同，并且已定义，以便读者可以将术语映射到其首选词汇。

被动浏览器 - 被动浏览器 是支持广泛支持的 HTTP 浏览器（例如 HTTP/1.1）。

活动请求程序 - 活动请求程序 是一个应用程序（可能是 Web 浏览器），能够发出 Web 服务消息，例如 WS-Security 和 WS 信任中所述的消息。

配置文件 - 配置文件 是一个文档，描述如何将此模型应用于特定类型的请求者（例如被动或主动）。

声明 - 声明 是由实体（例如名称、标识、密钥、组、特权、功能、属性等）做出的声明。

安全令牌 - 安全令牌 表示声明集合。

签名的安全令牌 - 签名的安全令牌 是由特定机构断言和加密签名的安全令牌（例如 X.509 证书或 Kerberos 票证）

所有权证明 - 所有权证明 是一条消息提供的身份验证数据，用于证明该消息是通过声明标识发送或创建的。

所有权证明令牌 - 所有权证明令牌 是一个安全令牌，其中包含发送方可用于证明所有权证明的数据。 通常，虽然不是独占的，但所有权证明信息使用仅向发送方和收件人方已知的密钥进行加密。

摘要 - 摘要 是八进制流的加密校验和。

签名 - 签名 是一个使用加密算法计算的值，并绑定到数据，以便预期数据接收者可以使用签名来验证数据自签名以来尚未更改数据。

安全令牌服务（STS） - 安全令牌服务 是颁发安全令牌的 Web 服务（请参阅 WS-Security 和 WS-Trust）。 也就是说，它根据它信任的证据对信任它的人做出断言。 为了传达信任，服务需要证明（例如安全令牌或安全令牌集），并使用自己的信任声明颁发安全令牌（请注意，对于某些安全令牌格式，这只能是重新颁发或共同签名）。 这构成了信任代理的基础。

属性服务 - 属性服务 是一种 Web 服务，用于维护有关信任领域或联合中的主体的信息（属性）。 在此上下文中，术语主体可以应用于任何系统实体，而不仅仅是一个人。

假名服务 - 假名服务 是一种 Web 服务，用于维护有关信任领域或联合身份验证中主体的备用标识信息。 在此上下文中，术语主体可以应用于任何系统实体，而不仅仅是一个人。

Trust - Trust 是 一个实体愿意依赖第二个实体来执行一组操作和/或对一组主题和/或范围进行断言的特征。

信任域 - 信任域 是一个受管理的安全空间，其中请求的源和目标可以确定并同意来自源的特定凭据集是否满足目标的相关安全策略。 目标可能会将信任决定推迟到第三方，从而在信任域中包括受信任的第三方。

验证服务 - 验证服务 是一种 Web 服务，它使用 WS-Trust 机制来验证提供的令牌并评估其信任级别（例如受信任的声明）。

直接信任 - 直接信任 是信赖方接受请求方发送的令牌中声明的真实全部（或部分子集）。

Direct Brokered Trust - Direct Brokered Trust 是一方信任第二方，而第三方则信任或担保第三方。

间接中转信托 - 间接中转信托 是直接中转信任的变体，第二方无法立即验证第三方向第一方提出的声明，并与第三方或其他方协商，以验证声明并评估第三方的信任。

消息身份验证 - 消息身份验证 是验证收到的消息是否与发送的消息相同的过程。

发送方身份验证 - 发送方身份验证 可以证实可能跨 Web 服务参与者/角色的身份验证证据，指示 Web 服务消息的发送方（及其关联数据）。 请注意，如果存在经过身份验证的中介，则消息可能有多个发件人。 另请注意，它是应用程序依赖的（和范围外）如何确定谁首先创建消息作为消息发起方可能独立于或隐藏在经过身份验证的发件人后面。

领域或域 - 领域 或 域 表示单个安全管理或信任单元。

联合 - 联合身份验证 是已建立信任的领域/域的集合。 信任级别可能会有所不同，但通常包括身份验证，并且可能包括授权。

标识提供者 - 标识提供者 是一个实体，充当对等实体身份验证服务的实体，向服务提供商提供数据源身份验证服务（这通常是安全令牌服务的扩展）。

单一登录（SSO） - 单一登录 是身份验证序列的优化，可消除对最终用户执行重复操作的负担。 为了方便 SSO，一个名为标识提供者的元素可以代表用户充当代理，向请求用户信息的第三方提供身份验证事件的证据。 这些标识提供者是受信任的第三方，需要由用户信任（为了维护用户的标识信息，因为此信息丢失可能会导致用户标识泄露）和 Web 服务，这些服务可能会根据 IP 提供的标识信息的完整性授予对宝贵资源和信息的访问权限。

标识映射 - 标识映射 是创建标识属性之间的关系的方法。 某些标识提供者可能会使用 ID 映射。

注销 - 注销 是安全令牌销毁领域/域或联合身份验证的过程。

协会 - 协会 是主体与信任领域或联盟关联或关联的过程。

贡献

本文档由 IBM 和 Microsoft 共同创作。

关键贡献包括（按字母顺序）：乔瓦尼·德拉-利贝拉，Microsoft;布兰登·迪克森，Microsoft;迈克公爵夫人， Microsoft;IBM唐·弗格森;普拉里特·加格，Microsoft;IBM蒂姆·哈恩;希瑟·辛顿，IBM;IBM 玛丽安·洪多;克里斯·卡勒，Microsoft;弗兰克·莱曼，IBM;布拉德·爱人，Microsoft;IBM马鲁山一郎;安东尼·纳达林，IBM;纳塔拉杰·纳加拉特南，IBM;维卡特·拉加万，IBM;约翰·舒克，Microsoft

引用

© 2001-2003 国际商务机器公司。 保留所有权利。

这是一份初步文件，可能会随着时间的推移而发生重大更改。 本文档中包含的信息代表国际商务机和Microsoft公司关于截至发布日期讨论的问题的当前视图。 由于 IBM 和Microsoft必须应对不断变化的市场状况，因此不应解释为 IBM 和Microsoft的承诺，IBM 和Microsoft不能保证发布日期后提供的任何信息的准确性。

本文档中包含的信息的呈现、分发或其他传播不是 IBM 拥有或控制的任何知识产权的许可，或者由 IBM 或Microsoft和\或其他任何第三方拥有或隐含的许可。  IBM、Microsoft和\或任何其他第三方可能拥有涉及本文档主题的专利、专利申请、商标、版权或其他知识产权。  本文档的提供不会向你授予 IBM 或Microsoft或任何其他第三方专利、商标、版权或其他知识产权的任何许可。 此处描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件都是虚构的。  与任何真正的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件没有关联，也不应推断。

本文档和本文中包含的信息以“AS IS”提供，在适用法律允许的最大范围内，IBM 和Microsoft提供文档 AS IS AND WITH ALL FAULTS，因此不公开、默示或法定的所有其他保证和条件，包括但不限于任何（如果有）默示担保， 适销性、针对特定用途的适用性、响应的准确性或完整性、结果、工作工作、缺乏病毒和缺乏疏忽等工作职责或条件，都涉及文件。 此外，没有关于文件的任何知识产权的说明或 NON-INFRINGEMENT 的担保或条件，没有保证或条件，安静享受，安静拥有，安静拥有。

任何情况下，IBM 或MICROSOFT对于购买替代商品或服务、利润损失、使用损失、数据丢失或任何附带的、后果性的、间接的或特殊损害，无论根据合同、侵权、担保或其他任何原因，无论根据合同、侵权、担保或其他任何原因，都不应承担任何费用，否则，与本文档相关的任何其他协议都无效， 此类当事人是否事先通知了此类损害的可能性。