WCF 安全模式
来源：博客园
Windows Communication Foundation (WCF) 安全分为三个主要功能区域：传输安全、访问控制和审核。传输安全提供完整性、保密性和身份验证。传输安全由传送安全、消息安全或 TransportWithMessageCredential 实现。 有关 WCF 消息安全的概述，请参见 安全性概述 。有关 其他两种 WCF 安全的更多信息，请参见 授权 和 审核安全事件 。 传输安全方案 使用 WCF 传输安全的常见方案包括： 使用 Windows 确保传输安全。WCF 客户端和服务部署在 Windows 域（或 Windows 目录林）中。消息包含个人数据，因此要求客户端和服务相互进行身份验证，要求实现消息完整性和消息保密性。此外，还需要有已发生特定事务的证明，例如，消息的接收方应记录签名信息。 使用 UserName 和 HTTPS 确保传输安全。WCF 客户端和服务需要一些开发工作，以便通过 Internet 工作。客户端凭据根据数据库（其中的内容为用户名/密码对）进行身份验证。服务是用受信任的安全套接字层 (SSL) 证书部署在一个 HTTPS 地址的。由于消息是通过 Internet 传输的，因此，客户端和服务需要相互进行身份验证，并且必须在传输过程中保持消息的保密性和完整性。 使用证书确保传输安全。WCF 客户端和服务需要一些开发工作，以便通过公共 Internet 工作。客户端和服务都具有可用于确保消息安全的证书。客户端和服务通过 Internet 进行相互通信，执行要求消息完整性、保密性和相互身份验证的重要事务。 完整性、保密性和身份验证 三项功能 — 完整性、保密性和身份验证 — 合称为传输安全。传输安全提供的这些功能，有助于减轻对分布式应用程序的威胁。下表简要介绍构成传输安全的三项功能。 功能 说明 完整性 完整性 可以确保数据是完整、准确的，在数据从一点移动到另一点，并可能由多个操作者读取的情况下，尤其如此。完整性必须得到维护，以免数据被篡改，这通常是由消息的数字签名实现的。 保密性 保密性 可以确保消息不被目标读取者以外的任何人读取。例如，信用卡号在通过 Internet 发送时必须保密。保密性通常是用公钥/私钥方案进行数据加密实现的。 身份验证 身份验证 是对已声明标识进行的验证。例如，当使用银行帐户时，必须只允许帐户的实际所有者取款。有多种方式可以实现身份验证。一个常用方法是使用用户/密码系统。第二个方法是使用第三方提供的 X.509 证书。 安全模式 WCF 有多种传输安全模式，如下表所述。 模式 说明 None 传输层和消息层都不提供安全措施。默认情况下，预定义绑定都不使用此模式，只有
元素（使用代码时，则为 BasicHttpBinding 类）例外。 Transport 使用安全传送（如 HTTPS）实现完整性、保密性和相互身份验证。 Message 使用 SOAP 消息安全实现完整性、保密性和相互身份验证。SOAP 消息是按照 WS-Security 标准获得保护的。 混合模式 使用传送安全实现完整性、保密性和服务器身份验证。使用消息安全（WS-Security 和其他标准）实现客户端身份验证。 （此模式的枚举值是 TransportWithMessageCredential 。） 消息和传送 在传送级别和消息级别都执行保护和身份验证。此模式仅在
元素中可用。 凭据和传输安全 凭据 是一些数据，用于证实已声明标识或功能。出示凭据包括出示数据以及数据的所有权证明。WCF 在传输和消息安全级别支持多种凭据类型。您可以为 WCF 绑定指定凭据类型。 在许多国家和地区，驾驶执照就是凭据的一个示例。该执照中包含表示个人身份和能力的数据。它以持有人照片的形式包含所有权证明。该执照由受信任的颁发机构颁发，通常是获得许可的政府部门。该执照采用密封形式且包含一张全息图，表明它未经改动或伪造。 例如，考虑 WCF 中支持的两种凭据类型：用户名和 (X.509) 证书凭据。 对于用户名凭据，用户名表示已声明标识，密码表示所有权证明。这种情况下，受信任的颁发机构则是验证用户名和密码的系统。 在证书凭据中，主题名称、主题备用名称或证书中的特定字段可用于表示已声明标识和/或功能。凭据中的数据所有权证明的建立，是用关联私钥生成签名实现的。 有关 传输安全编程和指定凭据的更多信息，请参见 绑定与安全 和 WCF 中的安全行为 。 传送客户端凭据类型 下表列出了在创建使用传输安全的应用程序时可能使用的值。在代码或绑定设置中，可以使用这些值。 设置 说明 None 指定客户端不需要提供任何凭据。这相当于匿名客户端。 Basic 指定基本身份验证。有关其他信息，请参见 RFC2617“ HTTP 身份验证：基本和摘要式身份验证 （可能为英文网页）。” Digest 指定摘要式身份验证。有关其他信息，请参见 RFC2617“ HTTP 身份验证：基本和摘要式身份验证 （可能为英文网页）。” Ntlm 指定在 Windows 域中使用 SSPI 协商进行 Windows 身份验证。 要使用 SSPI 协商，就需要使用 Kerberos 协议或 NT LanMan (NTLM)。 Windows 指定在 Windows 域中使用 SSPI 进行 Windows 身份验证。SSPI 选择 Kerberos 协议或 NTLM 作为身份验证服务。 SSPI 首先尝试 Kerberos 协议；如果失败，则使用 NTLM。 Certificate 使用证书（通常是 X.509）执行客户端身份验证。 消息客户端凭据类型 下表列出了在创建使用消息安全的应用程序时可能使用的值。在代码或绑定设置中，可以使用这些值。 设置 说明 None 允许服务与匿名客户端交互。 Windows 允许在 Windows 凭据的已通过身份验证的上下文中执行 SOAP 消息交换。使用 SSPI 协商机制选择 Kerberos 协议或 NTLM 作为身份验证服务。 Username 允许服务可以要求使用用户名凭据对客户端进行身份验证。请注意，WCF 不允许对用户名进行任何加密操作，例如生成签名或加密数据。因此，WCF 强制要求在使用用户名凭据时确保传输的安全性。 证书 允许服务要求使用证书对客户端进行身份验证。 CardSpace 允许服务要求使用 CardSpace 对客户端进行身份验证。 凭据编程 对于每个客户端凭据类型，WCF 编程模型都允许通过服务行为和通道行为来指定凭据值和凭据验证程序。 WCF 安全有两种凭据类型：服务凭据行为和通道凭据行为。WCF 中的凭据行为指定实际数据，即用于满足安全要求（通过绑定表示）的凭据。在 WCF 中，客户端类是运行时组件，它在操作调用和消息之间进行转换。所有客户端都是从 ClientBase 类继承的。通过基类的 ClientCredentials 属性，可以指定不同的客户端凭据值。 在 WCF 中，服务行为是一些属性，它们在实现服务协定（接口）的类中应用，以编程方式对服务进行控制。使用 ServiceCredentials 类，可以为服务凭据指定证书，也可以为不同的客户端凭据类型指定客户端验证设置。 消息安全的协商模型 在消息安全模式中，通过执行传输安全，可以在客户端带外配置服务凭据。例如，如果使用的是存储在 Windows 证书存储区中的证书，则必须使用一个工具，如 Microsoft 管理控制台 (MMC) 单元。 在消息安全模式中，通过执行传输安全，还可以与客户端交换服务凭据，作为初始协商的一部分。若要启用协商，请将 NegotiateServiceCredential 属性设置为 true 。
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动WCF&安全模式
Windows Communication Foundation (WCF)
安全分为三个主要功能区域：传输安全、访问控制和审核。传输安全提供完整性、保密性和身份验证。传输安全由传送安全、消息安全或TransportWithMessageCredential&实现。
有关 WCF 消息安全的概述，请参见。有关 其他两种 WCF
安全的更多信息，请参见和。
传输安全方案
使用 WCF 传输安全的常见方案包括：
完整性、保密性和身份验证
三项功能 — 完整性、保密性和身份验证 —
合称为传输安全。传输安全提供的这些功能，有助于减轻对分布式应用程序的威胁。下表简要介绍构成传输安全的三项功能。
完整性可以确保数据是完整、准确的，在数据从一点移动到另一点，并可能由多个操作者读取的情况下，尤其如此。完整性必须得到维护，以免数据被篡改，这通常是由消息的数字签名实现的。
保密性可以确保消息不被目标读取者以外的任何人读取。例如，信用卡号在通过 Internet
发送时必须保密。保密性通常是用公钥/私钥方案进行数据加密实现的。
身份验证是对已声明标识进行的验证。例如，当使用银行帐户时，必须只允许帐户的实际所有者取款。有多种方式可以实现身份验证。一个常用方法是使用用户/密码系统。第二个方法是使用第三方提供的
X.509 证书。
WCF 有多种传输安全模式，如下表所述。
传输层和消息层都不提供安全措施。默认情况下，预定义绑定都不使用此模式，只有&&元素（使用代码时，则为&&类）例外。
使用安全传送（如 HTTPS）实现完整性、保密性和相互身份验证。
使用 SOAP 消息安全实现完整性、保密性和相互身份验证。SOAP 消息是按照 WS-Security 标准获得保护的。
使用传送安全实现完整性、保密性和服务器身份验证。使用消息安全（WS-Security 和其他标准）实现客户端身份验证。
（此模式的枚举值是&TransportWithMessageCredential。）
消息和传送
在传送级别和消息级别都执行保护和身份验证。此模式仅在&&元素中可用。
凭据和传输安全
凭据是一些数据，用于证实已声明标识或功能。出示凭据包括出示数据以及数据的所有权证明。WCF
在传输和消息安全级别支持多种凭据类型。您可以为 WCF 绑定指定凭据类型。
在许多国家和地区，驾驶执照就是凭据的一个示例。该执照中包含表示个人身份和能力的数据。它以持有人照片的形式包含所有权证明。该执照由受信任的颁发机构颁发，通常是获得许可的政府部门。该执照采用密封形式且包含一张全息图，表明它未经改动或伪造。
例如，考虑 WCF 中支持的两种凭据类型：用户名和 (X.509) 证书凭据。
对于用户名凭据，用户名表示已声明标识，密码表示所有权证明。这种情况下，受信任的颁发机构则是验证用户名和密码的系统。
在证书凭据中，主题名称、主题备用名称或证书中的特定字段可用于表示已声明标识和/或功能。凭据中的数据所有权证明的建立，是用关联私钥生成签名实现的。
有关 传输安全编程和指定凭据的更多信息，请参见和&。
传送客户端凭据类型
下表列出了在创建使用传输安全的应用程序时可能使用的值。在代码或绑定设置中，可以使用这些值。
指定客户端不需要提供任何凭据。这相当于匿名客户端。
指定基本身份验证。有关其他信息，请参见 RFC2617“（可能为英文网页）。”
指定摘要式身份验证。有关其他信息，请参见 RFC2617“（可能为英文网页）。”
指定在 Windows 域中使用 SSPI 协商进行 Windows 身份验证。
要使用 SSPI 协商，就需要使用 Kerberos 协议或 NT LanMan (NTLM)。
指定在 Windows 域中使用 SSPI 进行 Windows 身份验证。SSPI 选择 Kerberos 协议或 NTLM
作为身份验证服务。
SSPI 首先尝试 Kerberos 协议；如果失败，则使用 NTLM。
Certificate
使用证书（通常是 X.509）执行客户端身份验证。
消息客户端凭据类型
下表列出了在创建使用消息安全的应用程序时可能使用的值。在代码或绑定设置中，可以使用这些值。
允许服务与匿名客户端交互。
允许在 Windows 凭据的已通过身份验证的上下文中执行 SOAP 消息交换。使用 SSPI 协商机制选择 Kerberos 协议或
NTLM 作为身份验证服务。
允许服务可以要求使用用户名凭据对客户端进行身份验证。请注意，WCF
不允许对用户名进行任何加密操作，例如生成签名或加密数据。因此，WCF 强制要求在使用用户名凭据时确保传输的安全性。
允许服务要求使用证书对客户端进行身份验证。
允许服务要求使用 CardSpace 对客户端进行身份验证。
对于每个客户端凭据类型，WCF 编程模型都允许通过服务行为和通道行为来指定凭据值和凭据验证程序。
WCF 安全有两种凭据类型：服务凭据行为和通道凭据行为。WCF 中的凭据行为指定实际数据，即用于满足安全要求（通过绑定表示）的凭据。在
WCF 中，客户端类是运行时组件，它在操作调用和消息之间进行转换。所有客户端都是从&&类继承的。通过基类的&&属性，可以指定不同的客户端凭据值。
在 WCF 中，服务行为是一些属性，它们在实现服务协定（接口）的类中应用，以编程方式对服务进行控制。使用&&类，可以为服务凭据指定证书，也可以为不同的客户端凭据类型指定客户端验证设置。
消息安全的协商模型
在消息安全模式中，通过执行传输安全，可以在客户端带外配置服务凭据。例如，如果使用的是存储在 Windows
证书存储区中的证书，则必须使用一个工具，如 Microsoft 管理控制台 (MMC) 单元。
在消息安全模式中，通过执行传输安全，还可以与客户端交换服务凭据，作为初始协商的一部分。若要启用协商，请将&&属性设置为&true。
Transport安全模式
顾名思义，Transport安全模式就是利用基于传输层协议的安全机制解决传输安全涉及的三个问题，即认证、消息一致性和进行性。而TLS/SSL是实现Transport安全最常用（并非唯一）的方式。
我们以访问一个HTTPS站点为例。当客户端和这个HTTPS站点所在的Web服务器进行正式的访问请求之前，在它们之间必须建立了安全的HTTP连接。而这样一个安全的连接的创建通过客户端和Web站点之间的多次握手或者协商（Negotiation）来完成。如下图示，整个协商过程主要包括三个步骤。
步骤一：客户端向HTTPS站点发送协商请求，该请求中包括客户端所能够支持的加密算法列表；
步骤二：HTTPS站点从加密算法列表中选择自己支持的并且安全级别最高的算法（有时候站点也可能综合考虑性能和安全两者之间的平衡，从中选择一个“最佳”的加密算法），连同绑定到该站点的数字证书（所有HTTPS站点在部署的时候都会绑定一个X.509证书）一并发送给客户端；
步骤三：客户端接收到服务端发回的数字证书之后，通过验证证书进而确定服务身份。在验证成功的情况下，客户端会生成一个随机随机数，作为会话密钥（Session
Key），缓存在客户端。客户端随后并采用服务端发回的加密算法，利用从证书中提取的公钥进行加密。加密后的会话密钥被发送给服务端，服务端使用自己的私钥采用相对应的算法进行机密得到该会话密钥。至此，客户端和服务端具有一个只有它们彼此知晓的会话密钥，所有的请求和回复消息均通过该会化密钥进行加密和解密。
有人可能会说，客户端为何不直接用从数字证书提取的公钥对所有的请求消息进行加密，服务端采用私钥进行解密。之所以选择对称加密而不是非对称加密，主要有两方面的原因：
对称加密/解密比非对称加密/解密需要更少的计算，所以具有更好的性能；
上述的加密方式只能确保客户端向服务端请求消息的机密性，而不能保证服务端向客户端回复消息的机密性。
Transport安全模型的优缺点
较之我们后续介绍的Message安全模式，Transport安全模式具有一个最到的优点，那就是高性能。虽然TLS/SSL在正式进行消息交换之前需要通过协商建立一个安全的连接，但是这个协商过程完全通过传输层协议来完成。而且这种安全模式还可以充分利用网络适配器的硬件加速，这样就可以介绍CPU时间，进而提供性能。但是，受限于传输层安全协议的特点，Transport安全模式也具有一些不可避免的局限性：
Transport安全模式依赖于具体的传输协议；
它只能提供基于点对点（Point-to-Point）的安全传输保障，即客户端之间连接服务的场景。如果在客户端的服务端之间的网络需要一些用于消息路由的中间结点，Transport安全模式则没有了用武之地。
在Transport安全模式下，意味着我们不得不在传输层而不能在应用层解决对客户端的认证，这就决定了可供选择的认证方式不如Message模式多。
也正是由于上述的这些局限（主要还是只能提供点对点的安全传输保障），决定了Intranet是Transport安全模式主要的应用环境。为了克服这些局限，我们需要一种与传输协议无关的、能够提供端到端（End-to-End）安全传输保障的、具有多种认证解决方案的安全模式，那就是Message安全模式。
二、Message安全模式
Transport安全模式将安全传输策略应用到传输层的数据段，进而间接地实现基于消息的安全传输。而Message模式则直接将安全策略的目标对象对准消息本身，通过对消息进行签名、加密实现消息安全传输。所以Message安全模式不会因底层是HTTP或者TCP传输协议而采用不同的安全机制，并且能够提供从消息最初发送端到最终接收端之间的安全传输，即端到端（End-To-End）安全传输。Message模式下的安全协议是一种应用层协议，我们可以在应用层上实现对客户端的验证，因而具有更多的认证解决方案的选择。
WCF的Message安全模式并不是微软在Windows平台下的闭门造车，而是遵循一系列开放的标准或者规范，那就是围绕着WS-Security的四个WS-*规范，即WS-Trust、WS-Secure
Conversation和WS-Security
Policy。这就意味着WCF的Message安全具有很好的互操作性或平台无关性。
三、复合安全模式（Mixed
Security Mode）
由于WCF的两种安全模式，即Transport和Message安全模式，都具有各自的优缺点，我们通过两者的结合构成一种混合的安全传输解决方案。我们称之为混合（Mixed）的安全模式。那么，这种新的安全模式是如何对Transport和Message安全模式进行“混合”呢？
我们知道，安全传输旨在解决三个问题：认证、消息一致性和机密性，而认证既包括服务端对客户端的认证，也包括客户端对服务端的认证。对于混合安全模式，消息的一致性、机密性和客户端对服务端的认证通过Transport安全模式来实现，而采用Message安全模式实现服务端对客户端的认证。
混合（以下简称Mixed）安全模式充分利用了Transport安全模式硬件加速优势，以提供高性能和具有高吞吐量的服务。由于服务端对客户端的验证是通过Message安全模式来实现的，所以我们具有更多关于客户端安全凭证和认证方式的选择。此外，由于Transport安全模式不可回避的极限性，混合安全模式也只能提供点到点的安全。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。WCF传输安全机制相关内容详解
WCF传输安全机制相关内容详解
　　WCF是一个由微软开发的功能强大的开发插件，我们可以利用它来实现一个安全性极高的企业级解决方案。其中，WCF传输安全机制取决于使用的绑定和后续传输。例如，当使用WSHttpBinding类时，传输为HTTP，保证传输安全的主要机制为HTTP上的安全套接字层(SSL)（通常称为 HTTPS）。本主题讨论WCF系统提供的绑定中使用的主要传输安全机制。　　WCF IIS宿主基本应用技巧分享
　　WCF自宿主管理进程声明周期
　　WCF端点配置具体管理办法
　　WCF服务宿主程序正确实现方法解析
　　WCF创建WebService正确操作步骤详解
　　将SSL安全与 .NET Framework 3.5 和更高版本一起使用时，WCF 客户端将使用其证书存储区中的中间证书和 SSL 协商期间收到的中间证书，对服务的证书执行证书链验证。.NET Framework 3.0 仅使用本地证书存储区中安装的中间证书。
　　BasicHttpBinding
　　默认情况下，BasicHttpBinding 类不提供安全。此绑定旨在提供与不实现安全机制的 Web 服务提供程序的互操作性。但可以通过将 Mode 属性设置为 None 以外的值来启用安全。若要启用传输安全，请将该属性设置为 Transport。
　　BasicHttpBinding 类主要用于与现有的 Web 服务和由 Internet 信息服务 (IIS) 承载的许多服务进行互操作。因此，此绑定的传输安全旨在实现与 IIS 站点的无缝互操作。通过将安全模式设置为 Transport，然后设置客户端凭据类型可以实现这一目的。凭据类型值对应于 IIS 目录安全机制。下面的代码演示如何设置模式以及如何将凭据类型设置为 Windows。当客户端和服务器在同一个 Windows 域中时，您可以使用此配置。
　　或在配置中：
　　&bindings&&basicHttpBinding&　　&bindingname=&SecurityByTransport&&　　&securitymode=&Transport&&　　&transportclientCredentialType=&Windows&/&　　&&/security&&&/binding&&&/basicHttpBinding&&&/bindings&
　　这对应于 IIS 中的基本身份验证方法。使用此模式时，必须为 IIS 服务器配置 Windows 用户帐户和适当的 NTFS 文件系统权限。有关 IIS 6.0 的更多信息，请参见启用基本身份验证和配置领域名（可能为英文网页）。有关 IIS 7.0 的更多信息，请参见 IIS 7.0 测试版本：配置基本身份验证（可能为英文网页）。
　　IIS有一个要求客户端使用证书进行登录的选项。此功能还可以使 IIS 将客户端证书映射到 Windows 帐户。有关 IIS 6.0 的更多信息，请参见在 IIS 6.0 中启用客户端证书（可能为英文网页）。有关 IIS 7.0 的更多信息，请参见 IIS 7.0 测试版本：在 IIS 7.0 中配置服务器证书（可能为英文网页）。
　　摘要式
　　WCF传输安全机制中的摘要式身份验证类似于基本身份验证，但其具有以哈希形式而不是明文形式发送凭据的优点。有关 IIS 6.0 的更多信息，请参见 IIS 6.0 中的摘要式身份验证（可能为英文网页）。有关 IIS 7.0 的更多信息，请参见 IIS 7.0 测试版本：配置摘要式身份验证（可能为英文网页）。
　　Windows
　　这对应于 IIS 中的集成 Windows 身份验证。设置为此值时，还需要服务器位于使用 Kerberos 协议作为其域控制器的 Windows 域中。如果服务器不在支持 Kerberos 的域中，或者如果 Kerberos 系统失败，您可以使用下一节中说明的 NT LAN Manager (NTLM) 值。有关 IIS 6.0 的更多信息，请参见 IIS 6.0 中的集成 Windows 身份验证（可能为英文网页）。
　　这可使服务器在 Kerberos 协议失败时使用 NTLM 进行身份验证。
　　WSHttpBinding
　　WSHttpBinding 类专用于与实现 WS* 规范的服务进行互操作。此绑定的WCF传输安全机制安全为 HTTP 上的安全套接字层 (SSL)，即 HTTPS。若要创建使用 SSL 的 WCF 应用程序，请使用 IIS 承载该应用程序。或者，如果您要创建自承载的应用程序，请使用 HttpCfg.exe 工具将 X.509 证书绑定到计算机上的特定端口。端口号作为 WCF 应用程序的一部分以终结点地址的形式进行指定。使用传输模式时，终结点地址必须包括 HTTPS 协议，否则运行时将引发异常。有关更多信息，请参见 HTTP 传输安全。
　　对于客户端身份验证，请将 HttpTransportSecurity 类的 ClientCredentialType 属性设置为 HttpClientCredentialType 枚举值之一。枚举值与 BasicHttpBinding 的客户端凭据类型等同，并由 IIS 服务承载。
　　WSDualHttpBinding
　　此绑定只提供消息级别的安全，不提供传输级别的安全。
　　NetTcpBinding
　　NetTcpBinding 类使用 TCP 进行消息传输。通过实现 TCP 上的传输层安全性 (TLS) 为传输模式提供安全。由操作系统提供 TLS 实现。
　　也可以通过将 TcpTransportSecurity 类的 ClientCredentialType 属性设置为 TcpClientCredentialType 值之一来指定客户端的凭据类型。
　　客户端
　　在客户端，必须使用 X509CertificateInitiatorClientCredential 类的 SetCertificate 方法指定证书。
　　WCF传输安全机制 - Welcome - 思路注意: 如果您要使用 Windows 安全性，则不需要证书。
　　下面的代码使用唯一标识证书的证书指纹。
　　或者，在客户端配置中的 behaviors 部分使用 clientCredentials element 指定证书。
　　&behaviors&&behavior&&clientCredentials&　　&clientCertificatefindValue=&&000&&　　storeLocation=&LocalMachine&storeName=&My&　　X509FindType=&FindByThumbPrint&/&&&/clientCertificate&　　&&/clientCredentials&&&/behavior&&&/behaviors&
　　NetNamedPipeBinding
　　NetNamedPipeBinding 类用于进行有效的计算机内通信；也就是说，虽然可以在同一网络上的两台计算机之间创建命名管道通道，但进程是在同一台计算机上运行的。此绑定只提供传输级别的安全。在创建使用此绑定的应用程序时，终结点地址必须包括&net.pipe&作为终结点地址的协议。
　　WSFederationHttpBinding
　　使用传输安全时，此绑定与已颁发的令牌 (TransportWithMessageCredential) 一起使用 HTTP 上的 SSL（称为 HTTPS）。有关 联合身份验证应用程序的更多信息，请参见联合令牌与颁发的令牌。
　　NetPeerTcpBinding
　　NetPeerTcpBinding类是旨在使用对等网络功能进行有效通信的一种安全传输。TCP 是协议，这与类和绑定的名称相一致。当WCF传输安全机制设置为&传输&时，绑定将实现 TCP 上的 TLS。
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&