摘要： 在这篇文章中，我们对信道分发器（ChannelDispatcher）本身作一个深入的了解，首先来看看它具有哪些可供扩展的组件，以及我们可以针对信道分发器对WCF实现哪些可能的扩展。 阅读全文

摘要： WCF的服务端架构体系又可以成为服务寄宿端架构体系。我们知道，对于一个基于某种类型的服务进行寄宿只需要使用到一个唯一的对象，那就是ServiceHost。甚至在某种语境下，我们所说的服务实际上就是指的对应的ServiceHost对象。整个服务寄宿过程包括两个阶段，即服务描述的创建和服务端运行框架的建立。而第一个阶段创建的服务描述是为了第二个阶段对服务端运行时框架建立服务的。 阅读全文

摘要： 对于WCF服务来说，一个服务具有若干操作，而这些操作由于提供的功能或者内部访问的资源不同，需要进行不同的权限设置。借助于.NET安全相关的应用编程接口，我们可以通过声明的方式将某个服务操作与调用该操作应当具有的权限集进行关联。在运行时，当调用某个服务操作的用户被成功认证后，它具有的权限集被获取出来并绑定到当前安全上下文。WCF框架本身在试图执行目标操作之前可以根据当前安全上下文确定该用户是否有权限执行该服务操作。 阅读全文

摘要： 在《模拟（Impersonation）与委托（Delegation）》一文中，我们对模拟和委托这两个概念以及相关编程实现进行了详细说明。如果将模拟使用在WCF上面，就意味着WCF可以模拟客户端身份（而不是启动寄宿进程的Windows帐号）执行服务操作。这篇文章主要介绍WCF关于模拟的编程。 阅读全文

摘要： 在《原理篇》中，我们谈到WCF自定义授权体系具有两个核心的组件：AuthorizationPolicy和ServiceAuthorizationManager，已经它们是如何写作最终提供一种基于声明的授权实现。为了让自定义授权有深刻的理解，我们来进行一个简单实例来演示如何通过自定义这两个组件实现“非角色授权策略”。 阅读全文

摘要： 到目前为止，我么介绍的授权策略都是围绕着安全主体进行的，基本上都是基于角色的授权。虽然角色是定义权限最为常用的形式，但是它解决不了授权的所有问题。有时候授权需要通过一个复杂的表达式来表示，而且其中会涉及诸多元素，比如身份、角色和组织等。一句话，如果简单的基于角色的授权不能解决我们的问题，我们需要自定义授权策略。 阅读全文

摘要： 在《原理篇》中我们谈到：如果采用自定义安全主体权限模式，我们可以通过自定义AuthorizationPolicy或者ServiceAuthorizationManager实现对基于当前认证用于相关的安全主体的提供，进而达到授权的目的。为了让大家对此有个更加深刻的认识，在这篇文章中我们会提供一个具体的例子。 阅读全文

摘要： 在《通过扩展自行实现服务授权》一文中，我通过自定义CallContextInitializer的方式在操作方法之前之前根据认证用户设置了当前线程的安全主体，从而实现授权的目的。实际上，WCF的安全体系本就提供相应的扩展，使你能够自由地实现安全主体的提供方式。具体来说，安全主体的提供可以通过自定AuthorizationPolicy或者ServiceAuthorizationManager来实现。 阅读全文

摘要： 其实针对安全主体的授权实现的原理很简单，原则上讲，只要你能在服务操作执行之前能够根据本认证的用户正确设置当前的安全主体就可以了。如果你了解WCF的整个运行时框架结构，你会马上想到用于授权的安全主体初始化可以通过自定义CallContextInitializer来实现。 阅读全文

摘要： 为了让读者对基于ASP.ENT Roles授权方式有一个全面的认识，我们现在来做一个实例演示。在这个实例中，我们将采用不同的认证方式，包括Windows认证和证书认证（ASP.NET Membership + Roles为常见的组合方式，在这里就不多作演示）。 阅读全文

摘要： 在采用Windows认证的情况下，使用基于Windows用户组安全主体权限模式是一个不错的选择,但是采用ASP.NET Roles却可以使用与任何类型的客户端凭证和认证模式。甚至可以这么说，绝大部分基于角色的授权都可以通过ASP.NET Roles来实现。 阅读全文

摘要： 由于服务操作是在寄宿进程中执行，在默认的情况下，服务操作是否具有足够的权限访问某个资源（比如文件）决定于执行寄宿进程Windows帐号的权限设置，而与作为客户端的Windows帐号无关。在有多情况下，我们希望服务操作执行在基于客户端的安全上下文中执行，以解决执行服务进行的帐号权限不足的问题。这就涉及到一个重要的话题——模拟与委托。 阅读全文

摘要： 为了让读者对基于Windows用户组的授权具有深刻的认识，接下来我们通过一个简单的事例来讲解在真正的应用中该授权模式如何使用。对于接下来演示的事例，我们将采用Windows认证和授权。至于授权的最终实现，我们采用的是在服务方法上面应用PrincipalPermissionAttribute特性方式的声明式授权。 阅读全文

摘要： Windows用户组安全主体权限模式，顾名思义，就是将利用Windows安全系统将对应的Windows帐号所在的用户组作为该用户权限集的授权方式。认证和授权密不可分，但是对于认证和授权在WCF安全体系中的实现来说，它们则是相对独立的。认证属于安全传输的范畴，是在信道层实现的，而授权则是在服务模型层实现的。但是对于基于Windows用户组的授权来说，最终体现出来的授权行为却和采用何种认证具有密切的关系。 阅读全文

摘要： 前面的两篇文章主要探讨基于安全主体的授权。通过这些介绍我们知道：如果我们在实施授权的时候，当前线程的安全主体能够被正确设置，我们就可以正确地完成授权。安全主体具有两个基本的要素：身份与权限。身份在客户端经过认证之后已经确立下来，现在需要解决的问题就是如何获取被认证用户的权限。为了解决这个问题，WCF为我们提供了三种不同的方案。 阅读全文

摘要： 毫不夸张地说，安全主体（Principal）是整个授权机制的核心。我们可以简单地将将安全主体定义成能够被成功实施授权的主体。一个安全主体具有两个基本的要素：基于某个用户的安全身份和该用户具有的权限。绝大部分的授权都是围绕着“角色”进行的，我们将一组相关的权限集和一个角色绑定，然后分配给某个用户。所以在基于角色授权环境下，我们可以简单地将安全主体表示成：身份 + 角色。 阅读全文

摘要： 我们为应用建立安全保障体系的一个重要的目的在于：通过权限控制让用户只能执行被允许的功能，访问被许可的资源。这就是本系列文章讨论的主题授权。对于WCF服务来说，一个服务具有若干操作，而这些操作由于提供的功能或者内部访问的资源不同，需要进行相应的授权。在正式介绍WCF授权之前，先来谈谈两个重要的概念：身份与安全主体。 阅读全文

摘要： 多年之前，我写了一篇通过WCF扩展实现上下文信息从客户端自动传递到服务端的文章，其实现机制很简单：将上下文信息存放到SOAP Header进行传递。那么对于非SOAP消息的RESTful服务就不使用了。为了解决这个问题，我们可以将存放上下文信息的地方从SOAP Header替换成HTTP Header。这篇为你消息讲述具体的实现[源代码从这里下载]。 阅读全文

摘要： 对消息进行签名和加密分别解决了消息的一致性和机密性问题。而最终是仅仅采用签名还是签名与加密共用取决于契约中对消息保护级别的设置。但是具体的签名和加密在整个WCF框架体系中如何实现？是采用对称加密还是非对称加密？密钥如何而来？相信这些问题在本篇文章中你会找到答案 阅读全文

摘要： 在《上篇》中，我们着重讨论了消息的保护等级如果在契约中定义，定义在不同契约（服务契约、错误契约和消息契约）中的消息保护等级具有怎样的层级关系，以及在默认情况下各种绑定采用怎样的保护等级。在下篇中，我们进一步来探讨消息保护等级和绑定的关系。 阅读全文

摘要： 到目前为止，对于WCF安全传输的三个方面，我们已经对认证进行了详细的介绍，现在我们来关注另外两个话题：消息的一致性和机密性，两者又统称为消息保护（Message Protection）。消息安全等级指的是对整个消息或者消息的某个部分实施安全保护采用的等级。按照级别由低到高，WCF支持三种不同的安全等级 阅读全文

摘要： 前面介绍Windows认证和用户名/密码认证这两种典型的客户端认证模式，我们最后来介绍最后一种客户端认证方式，即客户端凭证类型为X.509证书时服务端采用的认证，简称为证书认证。本篇文章主要涉及两个主题：在客户端如何设置X.509证书作为客户端凭证；在服务端如何设置不同的模式来对客户端的证书凭证进行认证 阅读全文

摘要： 对于基于Internet的应用，基于用户名和密码的认证方式是最为常用的，而WCF为你提供了不同模式的用户名认证方式:Windows、MembershipProvider和Custom 阅读全文

摘要： 结束了服务认证的介绍之后，我们接着介绍WCF双向认证的另一个方面，即服务对客户端的认证，简称客户端认证。客户端认证采用的方式决定于客户端凭证的类型，内容只要涉及基于以下三种典型客户凭证类型的认证：Windows、用户名和X.509证书。先来谈谈Windows认证 阅读全文

摘要： 在采用TLS/SSL实现Transport安全的情况下，客户端对服务证书实施认证。但是在默认情况下，这种认证仅仅是确保服务证书的合法性（通过数字签名确保证书确实是由申明的CA颁发）和可信任性（证书或者CA证书存储于相应的可信赖存储区）。而WCF提供服务证书并不限于此，客户端对服务认证的模式应该是这样的：服务端预先知道了服务的身份，在进行服务调用之前，服务端需要提供相应的凭证用以辅助客户端确认调用的服务具有预先确定的身份。对于这样的服务认证模式，具有两个重要的概念，即服务凭证和服务身份。 阅读全文

摘要： 上一篇演示的是绑定类型为NetTcpBinding情况下基于TLS/SSL的Transport安全模式的实现，接下来我们改用另外一种绑定：WS2007HttpBinding。对于基于HTTP的绑定，Transport安全模式的实现方式又根据寄宿方式的不同而具有一定的差异 阅读全文

摘要： 在接下来的系列文章中我们正是讨论关于身份认证的主题。在前面我们已经谈到了，WCF中的认证属于“双向认证”，既包括服务对客户端的认证（以下简称客户端认证），也包括客户端对服务的认证（以下简称服务认证）。对于TLS/SSL来说，客户端和服务在为建立安全上下文而进行的协商过程中会验证服务端的X.509证书如否值得信任。对于服务证书的验证实际上可以看成是一种服务认证，或者说TLS/SSL对证书的验证可以看成是WCF服务认证的一个环节。 阅读全文

摘要： 对于常用的几种绑定类型，它们都支持怎样的安全模式，以及针对各种安全模式可以采用怎样的认证方式（通过客户端凭证类型决定），这些都在前面的一系列文章中进行了详细的介绍。接下来我们通过表格的形式对不同类型的系统预定义对不同的安全模式进行一下总结。 阅读全文

摘要： 在前面两篇中，我们详细地介绍了四种基于HTTP的绑定分别支持的安全模式，已经在相应的安全模式下可以采用怎样的客户端凭证。在本篇文章中，我们安全线相同的方式来介绍三种基于局域网的绑定，即NetNamedPipeBinding、NetTcpBinding与 NetMsmqBinding。 阅读全文

摘要： 在上一篇文章中，我们详细地介绍了BasicHttpBinding具有怎样的安全模式的支持，已经在各种安全模式下分别可以采用怎样的客户端凭证。接下来我们来进一步分析另外三个基于HTTP的绑定，即WSHttpBinding、WS2007HttpBinding和WSDualHttpBinding。 阅读全文

摘要： 整个安全传输是在WCF的信道层进行的，而绑定是信道层的缔造者，所以终结点采用哪种类型的绑定以及对绑定的属性进行怎样的设置决定了信道层最终采用何种机制实现消息的安全传输。具体来说，我们可以通过绑定设置最终采用的安全模式，以及基于相应安全模式下进行认证和消息保护的行为。至于认证，最终采用怎样的认证方式是由客户端凭证决定的。 阅读全文

摘要： 在《上篇》中，我们谈到了常用的认证方式：用户名/密码认证和Windows认证。在下篇中，我们着重来介绍另外一种重要的凭证类型：X.509证书，以及针对X.509证书的认证方式。不过为了让读者能够真正地全面地了解X.509证书，本篇文章还提供一些基本的关于非对称加密的背景知识。 阅读全文

摘要： 如果要给认证下一个定义，我个人的倾向这样的定义：认证是确定被认证方的真实身份和他或她申明（Claim）的身份是否相符的行为。认证方需要被认证方提供相应的身份证明材料，以鉴定本身的身份是否与声称的身份相符。在计算机的语言中，这里的身份证明有一个专有的名称，即“凭证”，或者用户凭证、认证凭证。 阅读全文

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

摘要： 当我们在设计一个框架的时候，必然会涉及一系列的配置。为了让使用者更好地使用你提供的框架，让他们能够容易地维护这些配置是一项基本的要求。对于一些配置过于复杂的框架，比如EnterLib，比如WCF，往往会提供一个配置的工具。但是，不过这样的配置工具是否提供，手工编译配置文件是在所难免的。如果在通过VS编辑配置的时候，能够提供智能感知和提示性描述的支持，这无疑会使配置的编辑变得非常的容易。这里是一个简单的例子。 阅读全文

摘要： 大家都知道，我们具有三种定义可序列化类型的方式：在类型上应用SerializableAttribute特性；应用DataContractAttribute/DataMemberAttribute特性和实现ISerializable接口。当你通过继承一个现有的类来定义你需要被序列化的类，如果这个父类实现了ISerializable接口，如果定义不当，就会出现反序列化的问题。而且这个我们可能经常都不注意。 阅读全文

摘要： 条件编译，顾名思义，就是根据在编译时指定的条件决定最后需要编译的代码。条件编译是我们可以针对某些特性的环境编写相应的代码，比如有写的代码只需要在Debug模式下才需要执行，有些代码仅仅是为了在SIT或者UAT环境下有效地进行Troubleshooting，而在Production环境下则不应该执行。通过条件编译机制，我们可以针对某中特定的“条件编译符（Conditional Compilation Symbol）”编写相应的代码。在进行最终编译的时候，通过指定的条件编译符，编译器判断这些特殊的代码是否应该被编译。 阅读全文

摘要： 《上篇》主要介绍如何通过DataBinder实现批量的数据绑定，以及如何解决常见的数据绑定问题，比如数据的格式化。接下来，我们主要来谈谈DataBinder的设计，看看它是如何做到将作为数据源实体的属性值绑定到界面对应的控件上的。 阅读全文

摘要： 昨天写了《三种属性操作性能比较》，有个网友写信问我一个问题：从性能上看，Expression Tree和IL Emit孰优孰劣?虽然我在回信中作了简单的回答，但不知道这个网友是否懂我的意思。反正今天呆在家里也没事儿，干脆再就这个话题再写一篇文章。 阅读全文

摘要： 在《上篇》中，我比较了三种属性操作的性能：直接操作，单纯通过PropertyInfo反射和IL Emit。本篇继续讨论这个话题，我们再引入另外两种额外的属性操作方式：Expression Tree和通过Delegate的静态方法CreateDelegate创建相应的委托进行属性的赋值和取值 阅读全文