由于支持客戶端和服務(wù)在可能范圍內(nèi)進行***程度的系列交互，WCF安全性也帶來了難以掌控的復雜性，但您可以將我的框架用作支持聲明性安全的起點，然后再將其自定義為您的特定方案。

客戶端不使用 Windows 帳戶或用戶名，而是使用 X509 證書向服務(wù)標識自身，X509 證書通常是服務(wù)已知的。客戶端或服務(wù)可能不使用 WCF，甚至不使用 Windows?？蛻舳苏{(diào)用來自防火墻外部，您需要依靠 HTTP 進行傳輸，并可能有多個中介。#t#

對于企業(yè)對企業(yè)方案，我的框架允許使用 BasicHttpBinding、WSHttpBinding 或者 WSDualHttpBinding。您必須為傳輸安全使用消息安全以跨所有中介提供安全性。在此方案中，使用服務(wù)端證書保護消息，就像在 Internet 方案中一樣。

但是，與 Internet 方案不同，此方案中的客戶端提供證書形式的憑據(jù)。客戶端將配置文件中的（或編程方式的）證書提供給代理，WCF安全性代理將證書捆綁在消息中，并將其發(fā)送到服務(wù)。WCF安全性為服務(wù)管理員提供了多種方式來驗證客戶端發(fā)送的證書。

如果證書通過驗證，則認為客戶端經(jīng)過了身份驗證。我的框架使用服務(wù)端上的同等信任驗證，因此，服務(wù)管理員應(yīng)安裝被允許與在服務(wù)的本地機器上的 Trusted People 存儲中的服務(wù)進行交互的客戶端的所有證書。

當客戶端的證書被服務(wù)接收后，如果在受信任的存儲中可以找到該證書，則表明客戶端已通過身份驗證。默認情況下，服務(wù)無法使用基于原則、基于角色的安全。這是因為提供的憑據(jù)（即客戶端的證書）未映射到 Windows 或者 ASP.NET 用戶帳戶。

由于企業(yè)對企業(yè)端點往往專用于客戶端的較小集合乃至特定的客戶端，因此缺乏身份驗證支持可能不會導致問題。另一方面，如果您仍希望授權(quán)客戶端，那么即使成員身份提供程序未用于身份驗證，我的框架也可以利用 ASP.NET 角色提供程序進行授權(quán)。在 WCF安全性中，能夠單獨使用提供程序是 ASP.NET 提供程序模型的核心設(shè)計目標。