由于支持客戶端和服務在可能范圍內進行***程度的系列交互，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 提供程序模型的核心設計目標。