WCF的安全体系主要包括三个方面：传输安全（Transfer Security）、授权或者访问控制（Authorization OR Access Control）以及审核（Auditing）。而传输安全又包括两个方面：认证（Authentication）和消息保护（Message Protection）。认证帮助客户端或者服务确认对方的真实身份，而消息保护则通过签名和加密实现消息的一致性和机密性。WCF采用两种不同的机制来解决这三个涉及到传输安全的问题，我们一般将它们称为不同的安全模式，即Transport安全模式和Message安全模式。

目录
一、Transport安全模式
             1.1 TLS、SSL和HTTPS
             1.2 Transport安全模型的优缺点
二、Message安全模式
          2.1 WS-Security
          2.2 WS-Trust
          2.3 WS-SecurreConversation
          2.4 WS-SecurityPolicy
          2.5 Message安全模式的优缺点
三、Mixed安全模式

注：由于英文中的Transfer Security和Transport Security都可以翻译成传输安全，以示区别，我用中文的“传输安全”表示涉及到认证、消息一致性和机密性的Transfer Security，而采用“Transport安全（模式）”表示基于某种网络协议的传输层安全（模式），与“Transport安全（模式）”相对的是“Message安全（模式）”。

一、Transport安全模式

顾名思义，Transport安全模式就是利用基于传输层协议的安全机制解决传输安全涉及的三个问题，即认证、消息一致性和进行性。而TLS/SSL是实现Transport安全最常用（并非唯一）的方式。

TLS、SSL和HTTPS

任何一本介绍WCF的书，在介绍Transport安全模式的时候，必然会提到SSL或者HTTPS，有时还会提到TLS。有一些人不太明白这三者到底有什么区别，尤其是不能很好的区分TLS和SSL的差别。在这里，我们就先来简单介绍一下这三个相关的概念。

SSL（Secure Sockets Layer）最初是由Netscape公司开发的一种安全协议，应用于Netscape浏览器以解决与Web服务器之间的安全传输问题。SSL先后经历了三个主要的版本，即1.0、2.0和3.0。之后SSL被IETF （Internet Engineering Task Force）接管，正是根名为TLS（Transport Layer Security）。可以这么说，SSL是TLS的前身，TLS 1.0相当于SSL 3.1。

TLS/SSL本身是和具体的网络传输协议无关的，既可以用于HTTP，也可以用于TCP。而HTTPS（Hypertext Transfer Protocol Secure）则是将HTTP和TLS/SSL两者结合起来。在一般情况下，HTTPS通常采用443端口进行通信。对于WCF来说，所以基于HTTP协议的绑定的Transport安全都是通过HTTPS来实现的。而NetTcpBinding和NetNamedPipeBinding也提供了对TLS/SSL的支持，一般我们将TLS/SSL在TCP上的应用称为SSL Over TCP。

TLS/SSL帮助我们解决两个问题：客户端对服务端的验证，以及通过对传输层传输的数据段（Segment）进行加密确保消息的机密性。出于性能的考虑，这里采用的是对称加密而不是非对称加密。接下来，我从消息交换的角度来说明上述的两个问题是如何通过TLS/SSL解决的。

我们以访问一个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安全具有很好的互操作性或平台无关性。

WS-Security

WS-Security由是由结构化信息标准促进组织（OASIS：Organization for the Advancement of Structured Information Standards）制定。对于本书的读者来说，我相信你应该不会对OASIS这个组织感到陌生了吧。不仅仅是WS-Security，包括我们接下来要介绍的WS-Trust、WS-Secure Conversation和WS-Security Policy，它们的制定者也是这个标准组织。

WS-Security，有时候又被简称为WSS，制定了一整套标准的基于SOAP（包括SOAP 1.1和SOAP 1.2）的扩展以帮助创建一个安全的Web服务。到目前为止，OASIS推出了两个版本，第一个正式的版本于2004年3月发布，即WS-Security 1.0，有时候被称为WS-Security 2004。2006年2月，OASIS发布了WS-Security 1.1。

定义在WS-Security中的SOAP的安全机制可以广泛地应用于现有的多种安全模式下，比如PKI、Kerberos和SSL等。WS-Security支持多种安全令牌（Security Token）格式（比如用户名/密码、SAML、X509证书和Kerberos票据等）、多种签名格式和加密技术。针对具体的安全令牌，WS-Security通过对应的Profile文档进行单独定义。

WS-Security提供了关于SOAP安全交换的三个主要机制：如何将安全令牌作为消息的一部分进行传输，如何检测接收到的消息是否和原始发送的一致，以及如何确保消息的真实内容仅对真正的接收者可见。安全令牌的传输主要解决身份认证的问题，所以这三个方面就是传输安全面对的三个问题：身份认证、消息一致性和消息机密性。WS-Security提供了一个抽象的消息安全模型。在这个安全模型中，通过安全令牌，结合数字签名和加密技术实现对消息交换实体的认证和对消息本身的保护。

WS-Trust

WS-Trust通过定义了一系列SOAP扩展，旨在消息交换相关方之间建立一个信任的关系（Trust Relationship）。在绝大部分场景下，这里所指的信任关系是双向而非单向的。站在消息交换的角度来讲，信任关系不仅仅包括消息接收者对请求者的信任，也包括请求者对接收者的信任。要建立起彼此之间的信任关系，一个前提能够互相验证对方的真实身份，所以这里也就涉及到一个双向验证的问题。

在Web服务的世界中，消息交换为通信的唯一手段，那么相关方之间的信任关系的建立也只能围绕着消息交换来实现。定义在WS-Trust中的Web服务的信任模型基于这样的处理机制：Web服务要求接收的消息中包含有能够证明所需申明（包括身份、权限或者能力等）。如果Web服务接收到的消息不具有这些申明证明信息，它可以选择忽略或者拒绝该消息。

在这里，这些证明信息通过安全令牌（Security Token）的方式存在。实际上WS-Trust为我们提供了一种大体上的消息交换机制以实现安全令牌的颁发（Issuance）、续订（Renewal）和终止（Cancel）等。至于具体采用的安全消息交换形式，则借助于WS-Security，所以WS-Trust实际上是建立在WS-Trust之上的。WS-Trust具有两个主要的版本，即WS-Trust 1.3和WS-Trust 1.4，它们发布的时间分别是2005年和2008年。这两个版本的WS-Trust对应的命名空间URI分别为http://docs.oasis-open.org/ws-sx/ws-trust/200512和http://docs.oasis-open.org/ws-sx/ws-trust/200802。以下的内容主要基于WS-Trust 1.4。

WS-SecurreConversation

通过上面的介绍，我们知道安全传输旨在解决两个方面的问题，即身份认证和消息保护（消息的一致性和机密性）。我们假设这样一个应用场景：客户端和服务分别采用用户名/密码和X.509证书作为各自的用户凭证，那么针对于每一个单一的消息交换，可以通过下面的方式解决上述两个问题：

• 客户端采用服务端证书的公钥对消息进行加密，服务端在接收到消息的时候通过自己的私钥进行解密；
• 客户端每次服务调用均附加一个基于用户名/密码的安全令牌，服务端提取它对用以验证访问者的身份。

这好像是一个“完美”的解决方案，但是不知道你是否考虑过这样一个问题：如果客户端和服务端在一段时间内需要进行频繁的通信，那么性能问题就产生了。影响性能的因素主要包括：服务端需要对客户端进行频繁的认证；频繁地进行非对称加密/解密。

我们更加希望的是实现这样的安全传输机制：客户端和服务端在进行正式的消息交换之前，在它们之间通过彼此的认证，并建立起一个安全的上下文环境，或者说一个安全的会话。在这个上下文中，服务端无需对客户端进行重复的认证。此外，一个仅在当前上下文中被双方共享的密钥被创建出来，采用对称加密技术对消息进行签名和加密。

这个机制基本类似于TLS/SSL,不过TLS/SSL只是在传输层针对于数据段提供安全传输保障，而我们现在介绍的则是针对于SOAP消息的安全传输。由于这个机制主要为交互双方在同一个上下文环境中的多次消息交换提供安全传输的保障，我们将其称为Secure Conversation，OASIS为此制定了相应的规范，也就是我们本节要介绍的WS-SecureConversation。而WCF通过Secure Session机制提供对WS-SecureConversation的实现。

WS-SecureConversation具有两个主要的版本，即1.3和1.4，分别在2007和2009年发布，以下的内容主要针对WS-SecureConversation 1.4。WS-SecureConversation建立在WS-Security和WS-Trust基础之上，旨在提供一种机制对实现对安全上下文的创建和整个生命周期的控制。

我们目前提到的安全上下文（Security Context）仅仅是一种概念上的描述，而在真正的消息交换中，它通过一个具体的安全上下文令牌（SCT：Security Context Token）来表示。安全上下文令牌属于一种特殊的安全令牌，而WS-Trust为我们定义了一套完整的安全令牌传播机制。所以WS-SecureConversation完全借助于定义在WS-Trust的消息交换方式来完成针对安全上下文令牌的颁发（Issurance）、修复（Amending）、续订（Renewal）和注销（Cancel）。

WS-SecurityPolicy

一个Web服务（这里指广义的、与技术平台无关的Web服务）除了实现通过服务契约定义的业务功能之外，为了实现一些额外的功能（比如安全、事务和可靠传输等），还需要具有一些与业务无关的行为（Behavior）和能力（Capability），我们可以将这些统称为Web服务的策略（Policy）。WS-Policy提供了一个基于XML的框架模型和语法用于描述Web服务的能力、要求和行为属性。关于WS-Policy，在本书第二章有相应的介绍。

而这里介绍的WS-SecurityPolicy则建立在WS-Policy基础上，定义了一系列关于安全传输的策略断言（Policy Assertion）。而这些策略断言最终被应用在WS-Security、WS-Trust和WS-SecureConversation中。WS-SecurityPolicy具有两个主要的版本，即WS-SecurityPolicy1.2和WS-SecurityPolicy1.3，发布时间分别为2007年和2009年。

到此为止，我们已经介绍了WS-*体系中关于安全的4个重要的规范，WS-Security、WS-Trust、WS-SecureConversation和WS-SecurityPolicy。而WCF的消息安全模式是这四个WS-*规范的实现者。如果你想深刻地理解WCF的安全体系，对这四个安全规范的了解是必须的，这也是我为何要花这么的篇幅来介绍它们的原因。

但是处于篇幅的限制，这里对仅仅提供对WS-Security、WS-Trust、WS-Secure Conversation和WS-Security Policy大体上的介绍。如果读者对此有兴趣，可以通过下面的提供的地址下载下载官方文档。

WS-Security 1.0：http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
WS-Security 1.1(核心规范)：http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
WS-Trust 1.3：http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf
WS-Trust 1.4：http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.pdf
WS-SecureConversation 1.3：http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.pdf
WS-SecureConversation 1.4：http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.pdf
WS-SecurityPolicy 1.2：http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf
WS-SecurityPolicy 1.3：http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf

Message安全模式的优缺点

关于WCF的Message安全模式的优点，实际上在前面已经有所提及，在这里做一个总结。总的来说，较之Transport安全模式，Message安全模式具有如下的优点：

• 由于Message安全模式是通过在应用层通过对消息实施加密、签名等安全机制实现的，所以这是一种于具体传输协议无关的安全机制，不会因底层采用的是TCP或者HTTP而有所不同。较之Transport安全，这种基于应用层实现的安全机制在认证方式上具有更多的选择；
• 由于Message安全模式下各种安全机制都是直接应用在消息（SOAP）级别的，无论消息路由的路径有多复杂，都能够保证消息的安全传输。所以，不同于Transport安全模式只能提供点对点（Point-to-Point）的安全，Message安全模式能够提供端到端（End-to-End）安全；
• 由于Message安全模式是对WS-Security、WS-Trust、WS-SecureConversation和WS-SecurityPolicy这四个WS-*规范的实现，所有具有很好的互操作性，能够提供跨平台的支持。

但是Transport安全模式有一点是Message安全模式不能比的，那就是性能。Transport安全模式能够借助于网络适配器硬件加速，降低CPU计算时间，从而提供高效的传输安全。Message模式在性能上稍逊一筹。

三、复合安全模式（Mixed Security Mode）

由于WCF的两种安全模式，即Transport和Message安全模式，都具有各自的优缺点，我们通过两者的结合构成一种混合的安全传输解决方案。我们称之为混合（Mixed）的安全模式。那么，这种新的安全模式是如何对Transport和Message安全模式进行“混合”呢？

我们知道，安全传输旨在解决三个问题：认证、消息一致性和机密性，而认证既包括服务端对客户端的认证，也包括客户端对服务端的认证。对于混合安全模式，消息的一致性、机密性和客户端对服务端的认证通过Transport安全模式来实现，而采用Message安全模式实现服务端对客户端的认证。

混合（以下简称Mixed）安全模式充分利用了Transport安全模式硬件加速优势，以提供高性能和具有高吞吐量的服务。由于服务端对客户端的验证是通过Message安全模式来实现的，所以我们具有更多关于客户端安全凭证和认证方式的选择。此外，由于Transport安全模式不可回避的极限性，混合安全模式也只能提供点到点的安全。

作者：蒋金楠
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

原文链接