Windows Communication Foundation （WCF） 服务的安全性由两个主要要求组成：传输安全性和授权。 （审核中介绍了第三项要求，即安全事件的 审核。简言之，传输安全性包括身份验证（验证服务和客户端的身份）、机密性（消息加密）和完整性（用于检测篡改的数字签名）。 授权是对资源的访问的控制，例如，仅允许特权用户读取文件。 使用 WCF 的功能，可以轻松实现这两个主要要求。
除了 BasicHttpBinding 类（或 <配置中的 basicHttpBinding> 元素），默认情况下为所有预定义绑定启用传输安全性。 本节中的主题包括两种基本方案：在 Internet Information Services （IIS）上托管的 Intranet 服务上实现传输安全性和授权，以及对 IIS 上托管的服务实现传输安全性和授权。
安全基础知识
安全性依赖于 凭据。 凭据证明实体是它声称的实体。 （实体可以是人员、软件流程、公司或可授权的任何内容）。例如，服务的客户发出身份声明，凭据以某种方式证明该声明。 在典型方案中，会发生凭据交换。 首先，服务对其标识进行声明，并使用凭据向客户端证明它。 同样，客户端也将对某标识发出声明，并向该服务出具凭据。 如果双方都信任对方的凭据，则可以建立一个 安全上下文 ，在该上下文中，所有消息都以保密方式交换，并且所有消息都已签名以保护其完整性。 服务建立客户端标识后，可以将凭据中的声明与组中 的角色 或 成员身份 匹配。 在任一情况下，服务根据客户端所属的角色或组，授权 客户端执行有限的一组操作，取决于角色或组的权限。
Windows 安全机制
如果客户端和服务计算机都位于需要两者登录网络的 Windows 域中，则凭据由 Windows 基础结构提供。 在这种情况下，当计算机用户登录到网络时，会建立凭据。 网络上的每个用户和每台计算机都必须验证为属于受信任的用户和计算机集。 在 Windows 系统上，每个此类用户和计算机也称为 安全主体。
在 Kerberos 控制器支持的 Windows 域中，Kerberos 控制器使用基于向每个安全主体授予票证的方案。 控制器授予的票证由系统中的其他票证授权者信任。 每当实体尝试执行某些作或访问 某个资源 （例如计算机上的文件或目录）时，都会检查票证的有效性，如果通过，则向主体授予该作的另一个票证。 这种授予票证的方法比尝试对每项操作的主体都进行验证的备选方法更为高效。
Windows 域上使用的较旧、不太安全的机制是 NT LAN 管理器（NTLM）。 如果不能使用 Kerberos（通常在 Windows 域之外（例如工作组中），NTLM 可用作替代方法。 NTLM 也可用作 IIS 的安全选项。
在 Windows 系统上，授权的工作原理是将每台计算机和用户分配到一组角色和组。 例如，每个 Windows 计算机都必须由 管理员角色中的人员（或一组人员）设置和控制。 另一个角色是 用户的角色，该用户拥有一组更受限的权限。 除了该角色以外，还可将用户分配到组中。 组允许多个用户扮演同一角色。 因此，实际上，通过将用户分配到组来管理 Windows 计算机。 例如，可以将多个用户分配到计算机的用户组，并且可以将更多受限的用户集分配给管理员组。 在本地计算机上，管理员还可以创建新组，并将其他用户（甚至其他组）分配给组。
在运行 Windows 的计算机上，可以保护目录中的每个文件夹。 也就是说，可以选择一个文件夹并控制谁可以访问这些文件，以及他们是否可以复制文件，或者（在最特权的情况下）更改文件、删除文件或将文件添加到文件夹。 这称为访问控制，其机制称为访问控制列表（ACL）。 创建 ACL 时，可以将访问权限分配给任何组或组以及域的各个成员。
WCF 基础结构旨在使用这些 Windows 安全机制。 因此，如果要创建一个在 Intranet 上部署的服务，并且其客户端仅限于 Windows 域的成员，则可以轻松实现安全性。 只有有效的用户可以登录到域。 登录用户后，Kerberos 控制器使每个用户能够与任何其他计算机或应用程序建立安全上下文。 在本地计算机上，可以轻松创建组，在保护特定文件夹时，这些组可用于在计算机上分配访问权限。
在 Intranet 服务上实现 Windows 安全性
若要保护仅在 Windows 域上运行的应用程序，可以使用 WSHttpBinding 或 NetTcpBinding 绑定的默认安全设置。 默认情况下，同一 Windows 域上的任何人都可以访问 WCF 服务。 由于这些用户已登录到网络，因此它们受信任。 服务与客户端之间的消息经过加密，以保密性进行签名，以保持完整性。 有关如何创建使用 Windows 安全性的服务的详细信息，请参阅 如何：使用 Windows 凭据保护服务。
使用 PrincipalPermissionAttribute 类的授权
如果需要限制计算机上资源的访问，最简单的方法是使用 PrincipalPermissionAttribute 类。 此属性允许您通过要求用户属于指定的 Windows 组或角色，或者是一名特定的用户，从而限制服务操作的调用。 有关详细信息，请参阅 如何：使用 PrincipalPermissionAttribute 类限制访问。
模仿
模拟是可用于控制对资源的访问的另一种机制。 默认情况下，IIS 托管的服务将在 ASPNET 帐户的标识下运行。 ASPNET 帐户只能访问其具有权限的资源。 但是，可以设置文件夹的 ACL 以排除 ASPNET 服务帐户，但允许某些其他标识访问该文件夹。 然后，如果不允许 ASPNET 帐户这样做，则问题将变成如何允许这些用户访问该文件夹。 答案是使用模拟，允许服务使用客户端的凭据访问特定资源。 另一个示例是访问只有特定用户有权访问的 SQL Server 数据库。 有关使用模拟的详细信息，请参阅如何：在服务上模拟客户端和委派和模拟。
Internet 上的安全性
Internet 上的安全性与 Intranet 上的安全要求相同。 服务需要提供其凭据来证明其真实性，客户端需要向服务证明其身份。 证明客户端的标识后，服务可以控制客户端对资源的访问权限。 但是，由于 Internet 的异类性质，提供的凭据不同于在 Windows 域中使用的凭据。 Kerberos 控制器通过凭证票处理域内用户的身份验证，而在 Internet 上，服务和客户端通过多种方式展示凭证。 但是，本主题的目的是提供一种通用方法，使你能够创建可在 Internet 上访问的 WCF 服务。
使用 IIS 和 ASP.NET
Internet 安全性的要求和解决这些问题的机制并不新。 IIS 是Microsoft的 Internet Web 服务器，具有许多解决这些问题的安全功能;此外，ASP.NET 还包括 WCF 服务可以使用的安全功能。 若要利用这些安全功能，在 IIS 上托管 WCF 服务。
使用 ASP.NET 会员管理和角色管理提供程序
ASP.NET 包括成员资格和角色提供程序。 提供程序是一个用于对调用方进行身份验证的用户名/密码对数据库，该数据库还允许您指定每个调用方的访问特权。 使用 WCF，可以通过配置轻松使用预先存在的成员资格和角色提供程序。 有关演示此情况的示例应用程序，请参阅 成员资格和角色提供程序 示例。
IIS 使用的凭据
与 Kerberos 控制器支持的 Windows 域不同，Internet 是一个环境，无需单个控制器即可随时管理数百万用户登录。 相反，Internet 上的凭据通常采用 X.509 证书（也称为安全套接字层或 SSL 证书）的形式。 这些证书通常由 证书颁发机构颁发，它可以是保证证书真实性的第三方公司以及颁发证书的人员。 若要在 Internet 上公开服务，还必须提供此类受信任的证书来对服务进行身份验证。
此时会出现此问题，如何获取此类证书？ 一种方法是转到第三方证书颁发机构（例如 Authenticode 或 VeriSign），当你准备好部署服务时，并为服务购买证书。 如果您正处于使用 WCF 的开发阶段且尚未准备好承诺购买证书，可以使用一些工具和技术手段来创建可用于模拟生产部署的 X.509 证书。 有关详细信息，请参阅 “使用证书”。
安全模式
编程 WCF 安全性需要几个关键决策点。 最基本的一种是 安全模式的选择。 这两种主要安全模式是 传输模式 和 消息模式。
合并这两种主要模式的语义的第三种模式是 使用消息凭据模式传输。
安全模式确定消息的安全方式，每个选择都有优点和缺点，如下所述。 有关设置安全模式的详细信息，请参阅 “如何：设置安全模式”。
传输模式
网络和应用程序之间存在多个层。 其中一个是 传输 层*，用于管理终结点之间的消息传输。 出于目前的目的，你只需了解 WCF 使用多个传输协议，每个协议都可以保护消息的传输。 （有关传输的详细信息，请参阅传输。）
常用的协议是 HTTP;另一个是 TCP。 其中每个协议都可以通过特定于协议的机制（或机制）保护消息传输。 例如，HTTP 协议通过 HTTP 使用 SSL 进行保护，通常缩写为“HTTPS”。因此，选择传输模式以确保安全性时，会选择使用协议规定的机制。 例如，如果选择该 WSHttpBinding 类并将其安全模式设置为传输，则选择 SSL over HTTP （HTTPS）作为安全机制。 传输模式的优点是，它比消息模式更高效，因为安全性在相对较低的级别集成。 使用传输模式时，安全机制必须按照传输规范来实现，因此消息只能从点到点安全地流经传输。
消息模式
相比之下，消息模式通过将安全数据作为每个消息的一部分来提供安全性。 使用 XML 和 SOAP 安全标头，将确保消息完整性和机密性所需的凭据和其他数据包含在每条消息中。 每个消息都包含安全数据，因此会导致性能损失，因为必须单独处理每条消息。 （在传输模式下，一旦传输层受到保护，所有消息就会自由流动。但是，消息安全性在传输安全性上具有一个优势：它更灵活。 也就是说，安全要求不是由传输决定的。 可以使用任何类型的客户端凭据来保护消息。 （在传输模式下，传输协议确定可以使用的客户端凭据的类型。
带有消息凭据的传输
第三种模式结合了传输和消息安全性的最佳方法。 在此模式下，传输安全性用于有效确保每条消息的机密性和完整性。 同时，每个消息都包含其凭据数据，允许对消息进行身份验证。 通过身份验证，还可以实现授权。 通过对发送方进行身份验证，可以根据发件人的身份授予对资源的访问权限（或拒绝）。
指定客户端凭据类型和凭据值
选择安全模式后，可能还需要指定客户端凭据类型。 客户端凭据类型指定客户端必须用来向服务器进行身份验证的类型。
但是，并非所有方案都需要客户端凭据类型。 使用基于 HTTP 的 SSL（HTTPS），服务向客户端进行身份验证。 作为此身份验证的一部分，服务证书在称为 协商的过程中发送到客户端。 SSL 保护的传输可确保所有消息都是机密的。
如果要创建需要对客户端进行身份验证的服务，则选择客户端凭据类型取决于所选的传输和模式。 例如，使用 HTTP 传输和选择传输模式可提供多种选择，例如基本、摘要和其他选项。 （有关这些凭据类型的详细信息，请参阅 了解 HTTP 身份验证。）
如果要在仅对网络的其他用户可用的 Windows 域中创建服务，最简单的方法是 Windows 客户端凭据类型。 但是，您可能还需要提供带有证书的服务。 具体请参见 如何：指定客户端凭据值。
凭证价值
凭据值是服务使用的实际凭据。 指定凭据类型后，您可能还需要为您的服务配置实际的凭据。 如果选择了 Windows（并且服务将在 Windows 域中运行），则不会指定实际的凭据值。
身份
在 WCF 中，术语 标识 对服务器和客户端具有不同的含义。 简言之，在运行服务时，标识将在通过身份验证后分配到安全上下文。 要查看实际身份，请检查WindowsIdentity类的PrimaryIdentity和ServiceSecurityContext属性。 有关详细信息，请参阅 “如何：检查安全上下文”。
相比之下，在客户端上，标识用于验证服务。 在设计时，客户端开发人员可以将标识<元素设置为>从服务获取的值。 在运行时，客户端根据服务的实际标识检查元素的值。 如果检查失败，客户端将终止通信。 如果服务在特定用户的标识下运行，则该值可以是用户主体名称（UPN），如果服务在计算机帐户下运行，则为服务主体名称（SPN）。 有关详细信息，请参阅 服务标识和身份验证。 凭据也可以是证书，也可以是标识证书的证书上的字段。
保护级别
该 ProtectionLevel 属性发生在多个属性类（如 ServiceContractAttribute 类和 OperationContractAttribute 类） 上。 保护级别是一个值，该值指定支持服务的消息（或消息部件）是签名、签名和加密的，还是不使用签名或加密发送的。 有关属性的详细信息，请参阅 “了解保护级别”，有关编程示例，请参阅 “如何：设置 ProtectionLevel 属性”。 有关使用 ProtectionLevel 上下文设计服务协定的详细信息，请参阅 设计服务协定。