由于支持客户端和服务在可能范围内进行***程度的系列交互，WCF安全性也带来了难以掌控的复杂性，但您可以将我的框架用作支持声明性安全的起点，然后再将其自定义为您的特定方案。

客户端不使用 Windows 帐户或用户名，而是使用 X509 证书向服务标识自身，X509 证书通常是服务已知的。客户端或服务可能不使用 WCF，甚至不使用 Windows。客户端调用来自防火墙外部，您需要依靠 HTTP 进行传输，并可能有多个中介。#t#

对于企业对企业方案，我的框架允许使用 BasicHttpBinding、WSHttpBinding 或者 WSDualHttpBinding。您必须为传输安全使用消息安全以跨所有中介提供安全性。在此方案中，使用服务端证书保护消息，就像在 Internet 方案中一样。

但是，与 Internet 方案不同，此方案中的客户端提供证书形式的凭据。客户端将配置文件中的（或编程方式的）证书提供给代理，WCF安全性代理将证书捆绑在消息中，并将其发送到服务。WCF安全性为服务管理员提供了多种方式来验证客户端发送的证书。

如果证书通过验证，则认为客户端经过了身份验证。我的框架使用服务端上的同等信任验证，因此，服务管理员应安装被允许与在服务的本地机器上的 Trusted People 存储中的服务进行交互的客户端的所有证书。

当客户端的证书被服务接收后，如果在受信任的存储中可以找到该证书，则表明客户端已通过身份验证。默认情况下，服务无法使用基于原则、基于角色的安全。这是因为提供的凭据（即客户端的证书）未映射到 Windows 或者 ASP.NET 用户帐户。

由于企业对企业端点往往专用于客户端的较小集合乃至特定的客户端，因此缺乏身份验证支持可能不会导致问题。另一方面，如果您仍希望授权客户端，那么即使成员身份提供程序未用于身份验证，我的框架也可以利用 ASP.NET 角色提供程序进行授权。在 WCF安全性中，能够单独使用提供程序是 ASP.NET 提供程序模型的核心设计目标。