WCF安全机制是个非常复杂的问题，因为涉及的知识点较多，所以今天这个文章，会分析进行WCF安全开发应该了解的哪些知识点。如何查看资料。为了更好地理解WCF安全相关知识，我把WCF安全机制主要知识点整理为图表。本章以介绍WCF安全机制的基础概念为主。
要学习WCF安全编程，你应该学习什么首先掌握什么基础知识？很多时候会因为缺乏系统的安全概念，在进行WCF安全编程开发的时候，遇到很多问题，比如所证书，这个概念相信很多初学者第一次接触的时候花费了很多时间。我当时在做WSE安全开发的时候就查阅了很多资料。那么哪些是WCF安全开发应该掌握的知识点呢？今天我们就在这里做详细的介绍：
Windows Communication Foundation (WCF) 是一个基于 SOAP 消息的分布式编程平台，我们可以使用现有技术（如 HTTPS）、Windows 集成安全性或对用户进行身份验证的用户名和密码生成安全的分布式应用程序。WCF 基于现有安全性基础结构和 SOAP 消息的经验证的安全标准提供可互操作的安全消息交换通用平台。 通过使用 WCF的安全机制，我们可以可以在Internet 范围内跨多个 Windows 域进行服务和客户端的数据交互。下面会一次介绍WCF安全相关的一些知识点：
【0】安全开发必备知识点：
（1）对称加密算法DES，也叫密钥算法。
（2）非对称加密算法，也叫公钥算法。使用一对密钥，配合使用。如RSA算法；
（3）哈希算法：MD5（Message Digest5消息摘要算法），SHA1，SHA256等概念。签名，也是在是哈希算法的应用。
（4）WS-Security安全规范。这个是重要的安全规范，从Web Service ，WSE3.0 到现在的WCF服务都提供了支持。
（5）证书。这个是非对称加密的一个应用。CA证书管理机构。如何创建证书和管理证书。等概念有所了解。
算法这里主要讨论的是如何应用，即如何进行加密、解密、消息签名等问题。你对这些概念了解以后才会更好的理解WCF安全。
其实早在《WSE3.0构建Web服务安全(4) 》系列里已经详细讨论过这个问题。如果你看过这个系列的文章，这个些相关概念理解起来会容易许多。安全的相关知识点都有介绍，这个也是当初为什么花时间来学习WSE3.0的原因。你可以参考WSE3.0构建Web服务安全(1):WSE3.0安全机制与实例开发 和WSE3.0构建Web服务安全(2):非对称加密、公钥、密钥、证书、签名的区别和联系以及X.509 证书的获得和管理。后面的讨论又对文章进行了补充。几乎涵盖了所有的WCF安全需要的所有的基本知识点。
【1】WCF身份验证机制：
WCF与现有的Windows平台上的身份验证机制很好地结合以外，还支持WS-Security安全规范，以及用户定制扩展验证模式，安全令牌方式。如果你关注过WSE3.0相关的技术文章，一定感觉不会陌生，这些安全机制在WSE3.0中已经完全支持。这些都是WCF声称继承WSE安全机制的最好证明。延续微软平台的的一贯做法。优秀模型的复用与扩展。关于安全的概念可以再参考WSE3.0构建Web服务安全(1):WSE3.0安全机制与实例开发 。WCF支持的身份验证机制可以参考下图：
一下是对各种客户端身份验证方式的说明：
(1)None:客户端为匿名客户端。在这种情况下，每个客户端拥有一个自己的证书，比如身份证。服务会使用证书来确保服务客户端的标识。我们经常使用HTTPS 访问网站，比如登陆一些安全级别较高的网站情况类似，或者使用网上银行时候，你的客户端证书就会起到鉴别客户端的作用。
(2)UserName:客户端将提供用户名和密码。在这种情况下，服务会使用证书向客户端验证其标识。另外就是证书还将用加密客户端的用户名和密码，保证消息在传输过程中的安全。这个方式也是常见的加密方式。我会在后续文章里给出实现代码。
(3)Windows:需要Windows AD支持。一般使用在企业局域网内部。客户端和服务都会使用 Windows 帐户进行身份验证。Windows Communication Foundation 将会就 Kerberos 或 NTLM 进行协商，如果存在域，则优先选择 Kerberos（NTLM 实际上不会向客户端验证服务的身份，而只会向服务验证客户端的身份）。如果您想要使用 Kerberos，则必须让客户端根据配置中的服务主体名称验证服务的身份。如果您要在域环境中为客户端构建服务，您应明确地为其提供发送 Windows 账号的选项。
(4)Certificate:服务将具有一个证书（客户端的公钥），客户端也具有一个其自己的证书（服务端的公钥）。当客户端向服务端发送消息时，使用证书加密消息，服务端使用私钥解密。反之亦然。证书就是包含公钥，证书标识，主题，指纹，签名算法等的一个文件。
(5)IssuedToken:安全令牌的概念在WSE3.0里曾经涉及到。它允许您的服务从安全性令牌服务 (STS) 接受一组签名的声明。因为它可以启用联合标识方案和 InfoCard。当您与某个合作伙伴组织联合时，您将允许该合作伙伴通过任何合适的技术对其自己的用户进行身份验证。在最理想的情况下，这将允许该合作伙伴组织中的用户通过单一登录使用您的服务，即便他们并不与您使用同一个 Active Directory 域，或不受您的信任。该合作伙伴组织中的用户需要使用 STS 进行身份验证，而 STS 可以发出一个签名的安全声明标记语言 (Security Assertion Markup Language, SAML) 令牌。您既可以直接接受该令牌，也可以要求将该令牌呈送给您组织中的 STS，以便让其评估该合作伙伴的声明，并发出第二个您可以使用的 SAML 令牌。理解起来有点复杂。实际也是一个标识，鉴别客户端的一个标识。就是一种更加灵活的身份验证方式。
好比你现在使用中国护照，有一天突然联合国实现了一种新的护照，全球统一护照，你可以进入任何一个国家，即使你在中国办理，但是其他国家可以再你落地的时候验证你的护照的有效性。然后告诉其他国家，共享着这次验证的结果。你的护照就是令牌。需要后续鉴别的身份证明。Issued这个单词的作用就在这里。需要鉴别的令牌。
UserName方式容易实现，但是在WCF框架下需要使用服务证书，这个是相对WSE3.0改变的地方。如果结合证书使用的话，会使的这种方式适合在Internet中使用。安全性较高。适合对发布到Internet的WCF服务常见的身份验证方式。X.509证书验证方式相对严谨，要求客户端提供有效的证书凭证，也就是每个客户端都要维护一个自己的证书，调用服务前，通过SOAP消息传递到WCF服务，WCF进行身份验证。这个需要CA支持。或者需要申请第三方商业证书。
定制方式也比较常见，用户根据需要定制自己的身份验证机制，如指纹，基因等技术。来代替现有的身份验证方式。
【2】WCF传输安全模式：
WCF transfer Security mode包含5种方式：None,Transport,Message,Mixed,Both.这里的翻译直接翻译会导致奇异，因为这里还有一个概念就是Transport安全。选择不翻译更好，两者的中文直译反而难以理解。记住transfer Security 包含Transport,Message等5中安全模式，Transport,Message也是最长使用的安全模式。如下图：
传输安全模式使用传输级协议（如 HTTPS）获取传输安全性。传输模式的优点是可以被广泛采用、可用于多个平台以及计算较为简单。但是，它的缺点是只能保证点到点的消息安全。
消息安全模式使用 WS-Security（和其他规范）实现传输安全性。因为消息安全性直接应用于 SOAP 消息并与应用程序数据一起包含在 SOAP 消息内，它的优点是独立于传输协议、可扩展性更强以及可确保端到端安全性（与点到点相对），实现在整个Internet网络中的消息传播安全；它的缺点是比传输安全性模式慢很多倍，因为它必须处理 SOAP 消息，对消息加密，解密和签名等操作。
【3】WCF安全模式与绑定协议：
Net相关的绑定协议默认支持transport安全模式，而WS相关绑定默认支持消息安全模式。 BasicHttpBinding 绑定可支持基本安全配置文件，而 WSHttpBinding 绑定则支持最新的安全标准，例如 WS-Security 1.1 和 WS-SecureConversation。通过对这些标准的支持，WCF 安全性可与除 Microsoft Windows 之外的操作系统和平台上承载的 Web 服务进行互操作和集成。具体关系可以参考下表：
| 绑定/安全模式 |
None |
Transport |
Message |
Mixed |
Both |
|---|---|---|---|---|---|
|
BasicHttpBinding |
Yes (Default) |
Yes |
Yes |
Yes |
No |
|
NetTcpBinding |
Yes |
Yes (Default) |
Yes |
Yes |
No |
|
NetPeerTcpBinding |
Yes |
Yes (Default) |
Yes |
Yes |
No |
|
NetNamedPipeBinding |
Yes |
Yes (Default) |
No |
No |
No |
|
WSHttpBinding |
Yes |
Yes |
Yes (Default) |
Yes |
No |
|
WSFederationHttpBinding |
Yes |
No |
Yes (Default) |
Yes |
No |
|
WSDualHttpBinding |
Yes |
No |
Yes (Default) |
No |
No |
|
NetMsmqBinding |
Yes |
Yes (Default) |
Yes |
No |
Yes |
【4】Transport安全模式与客户端凭据：
Transport安全模式与客户端验证方式包括以下4种：None,Windows,UserName，Certificate也就是证书（非对称加密算法里，包含公钥等信息的一种文件形式）。客户端凭据中文翻译别扭，不好理解。clientCredential。通俗来说：就是用什么样的方式来验证客户端。即客户端提供的证件。具体由服务端决定使用哪种方式。下面是绑定协议和客户端验证方式在transport模式下的对应关系：
|
绑定/客户端凭据 |
None |
Windows |
Username |
Certificate |
|---|---|---|---|---|
|
BasicHttpBinding |
Yes (Default) |
Yes |
Yes |
Yes |
|
NetTcpBinding |
Yes |
Yes (Default) |
No |
Yes |
|
NetPeerTcpBinding |
No |
No |
Yes (Default) |
Yes |
|
NetNamedPipeBinding |
No |
Yes (Default) |
No |
No |
|
WSHttpBinding |
Yes |
Yes (Default) |
Yes |
Yes |
|
WSFederationHttpBinding |
N/A |
N/A |
N/A |
N/A |
|
WSDualHttpBinding |
N/A |
N/A |
N/A |
N/A |
|
NetMsmqBinding |
Yes |
Yes (Default) |
No |
Yes |
【5】 消息安全模式与客户端凭据：
相对tansport安全模式来说，消息安全模式下我们可以多使用一种客户端验证方式：Issued token令牌。消息安全模式增加支持的安全令牌机制。
IssuedToken:安全令牌的概念在WSE3.0里曾经涉及到。它允许您的服务从安全性令牌服务 (STS) 接受一组签名的声明。因为它可以启用联合标识方案和 InfoCard。当您与某个合作伙伴组织联合时，您将允许该合作伙伴通过任何合适的技术对其自己的用户进行身份验证。在最理想的情况下，这将允许该合作伙伴组织中的用户通过单一登录使用您的服务，即便他们并不与您使用同一个 Active Directory 域，或不受您的信任。该合作伙伴组织中的用户需要使用 STS 进行身份验证，而 STS 可以发出一个签名的安全声明标记语言 (Security Assertion Markup Language, SAML) 令牌。您既可以直接接受该令牌，也可以要求将该令牌呈送给您组织中的 STS，以便让其评估该合作伙伴的声明，并发出第二个您可以使用的 SAML 令牌。理解起来有点复杂。实际也是一个标识，鉴别客户端的一个标识。就是一种更加灵活的身份验证方式。
这里主要是为什么transport模式不支持，而消息模式支持，因为安全令牌，需要后续组织中的一个成员进行后续的身份鉴别，然后进行验证结果的共享。Transportat模式只限制点对点传输安全，因而不适合这种验证方式。
|
绑定/客户端凭据 |
None |
Windows |
Username |
Certificate |
Issued token |
|---|---|---|---|---|---|
|
BasicHttpBinding |
No |
No |
No |
Yes |
No |
|
NetTcpBinding |
Yes |
Yes (Default) |
Yes |
Yes |
Yes |
|
NetPeerTcpBinding |
N/A |
N/A |
N/A |
N/A |
N/A |
|
NetNamedPipeBinding |
N/A |
N/A |
N/A |
N/A |
N/A |
|
WSHttpBinding |
Yes |
Yes (Default) |
Yes |
Yes |
Yes |
|
WSFederationHttpBinding |
N/A |
N/A |
N/A |
N/A |
N/A |
|
WSDualHttpBinding |
Yes |
Yes (Default) |
Yes |
Yes |
Yes |
|
NetMsmqBinding |
Yes |
Yes (Default) |
Yes |
Yes |
Yes |
【6】总结：
WCF 安全性与现有传输安全模型集成，并且可对基于 SOAP 消息安全的新传输安全模型使用现有基础结构。支持IIS结合的所有安全性解决方案。安全套接字层 (SSL) 或 Kerberos 协议。也支持Windows身份验证方式，使用 Active Directory 的 Windows 域。而对WS-Security安全规范的支持又使其可以在互联网中实现安全的消息传输。 这些基础知识，基本是WCF安全机制要使用的主要的知识点。这里之所以单独整理出来，主要是因为：
（1）安全的概念由来已久，而与安全相关的算法或者相关概念，如加密、解密、证书、签名等概念大家必须有所了解。这个是进行安全编程的基础。如果对此基本概念不了解，在后续的学习中会寸步难行。
（2）WS-Security相关知识点，在WSE3.0里已经提供了很好的支持，WCF集成过来以后，也是对WCF宣称支持早期WSE优势的重要证据。
也使得WCF具有可以实现向Web Service一样跨平台的安全的重要特性。例如许多自定义安全验证方式使用就是重写积累的Validate方法。这个和WSE3.0非常相似，用户自定义实现用户名和密码的验证，重写以后，WCF框架会自动调用这个方法。验证失败会抛出异常。
（3）WCF安全更加复杂，除了支持先有的安全框架，还有结合自身的要求实现与绑定等协议的结合，为此，WCF提供了自己的安全通道，来实现对安全机制的支持。消息的加密、签名和解密都是在这里完成。来适用不同的安全验证场景。
（4）安全级别的提升，除了显示配置安全模式为None意外，WCF大部分消息安全模式在使用WS绑定都要求提供证书支持。比如UserName的消息安全模式，服务器必须提供证书，而且要是可信任的证书。这个和早期的Web Service直接在Soap 消息Header里写明文的用户名和密码。WSE3.0安全只启用UserName验证不同。
在了解完这些基础概念以后，我会在后续文章里给出更多讲解。因为涉及的知识点太多。如果只讲一个问题，或者简单给出实现，难以系统掌握WCF安全开发。所以为了更好的学习WCF安全编程,这里现从安全的总体概念入手，系统介绍安全的主要知识点以后，再来进行下面的学习。
我在下一篇会介绍USerName方式的客户单身份验证的实现原理和过程。包括实现代码。
谢谢~
参考资料：
1.programming WCF Services
2.http://msdn.microsoft.com/en-us/library/ms735093.aspx
3.WSE3.0构建Web服务安全(1):WSE3.0安全机制与实例开发
4.WSE3.0构建Web服务安全(2):非对称加密、公钥、密钥、证书、签名的区别和联系以及X.509 证书的获得和管理
5.http://msdn.microsoft.com/zh-cn/library/ms731069.aspx
6.http://technet.microsoft.com/zh-cn/library/cc768063(en-us).aspx
7.http://www.microsoft.com/msj/0899/kerberos/kerberos.aspx