在接下来的系列文章中我们正是讨论关于身份认证的主题。在前面我们已经谈到了，WCF中的认证属于“双向认证”，既包括服务对客户端的认证（以下简称客户端认证），也包括客户端对服务的认证（以下简称服务认证）。客户端认证和服务认证从本质上并没有什么不同，无非都是被认证一方提供相应的用户凭证供对方对自己的身份进行验证。我们先来讨论服务认证，客户端认证放在后续的文章中。 在《从两种安全模式谈起》中，我们对TLS/SSL进行了简单的介绍。我们知道，客户端和服务在为建立安全上下文而进行的协商过程中会验证服务端的X.509证书
第1章 WCF简介 (WCF Overview) 1.1 SOA基本概念的和设计思想 1.2 WCF是对现有Windows平台下分布式通信技术的整合 1.3 构建一个简单的WCF应用 步骤一：构建整个解决方案 步骤二：创建服务契约 步骤三：创建服务 步骤四：通过自我寄宿的方式寄宿服务 步骤五：创建客户端调用服务 步骤
这部分主要涉及企业级应用的安全问题，一般来说安全框架主要提供3个典型的安全行为：认证、授权和审核。除了典型的安全问题，对于一个以消息作为通信手段的分布式应用，还需要考虑消息保护(Message Pro
第1章 WCF简介 （WCF Overview） 1.1 SOA的基本概念和设计思想 1.2 WCF是对现有Windows平台下分布式通信技术的整合 1.3 构建一个简单的WCF应用 1.3.1 步骤一 构建整个解决方案 1.3.2 步骤二 创建服务契约 1.3.3 步骤三 创建服务 1.3.4 步骤四 通过自我寄宿的方式寄宿服务 1.3.5 步骤五 创建客户端调用服务 1.3.6 步骤六 通过IIS寄宿服务（S104） 第2章 地址（Address） 2.1. 统一资源标识符（URI） 2.1.1. HT
客户端调用WCF服务的方式不外乎有两种：其一、通过代码生成工具（比如SvcUtil.exe）导入服务的元数据生成服务代理相关的类型；其二、通过ChannelFactory<TChannel>创建服务代理对象。对于前者，生成的服务代理是一个继承自ClientBase<TChannel>的类型。对于这样一个服务代理对象，其内部本质上还是借助于ChannelFactory<TChannel>创建真正用于进行服务调用的代理对象。对于WCF客户端应用编程接口来说，ChannelFactory<TChannel>是一个
第一次邂逅WCF是在微软举办的一场关于Windows Vista技术推广培训上，时间大概是2005年10月份，当时对WCF可谓是一见钟情。如果读者也像我一样，之前习惯了采用.NET Remoting、XML Web Service、WSE、MSMQ来架构你分布式应用的话，应该不难想象我第一次接触WCF时心中的那份震撼。WCF是Windows平台下所有分布式技术集大成者，它将这一系列独立的分布式技术整合，提供一个统一的应用编程接口，这本身就是一项创举。这些被整合的分布式技术不仅仅包含提到的这些，还包括DCOM
第1章 异常处理 （Exception Handling） 1.1. WCF基本异常处理模式 1.1.1. 当异常从服务端抛出（S101） 1.1.2. 异常细节的传播（S102） 1.1.3. 自定义异常信息 1.2. 错误消息与FaultException异常 1.2.1. 从SOAP Fault说起 1.2.2. 唯一可被传播的异常：FaultException 1.2.3. FaultException异常和错误消息之间的转换 1.3. WCF异常处理体系剖析 1.3.1. FaultFormatt
对于基于Internet的应用，基于用户名和密码的认证方式是最为常用的，而WCF为你提供了不同模式的用户名认证方式。首先还是从用户凭证的表示说起。 一、用户名/密码认证的三种模式 基于用户名/密码的用户凭证通过类型UserNamePasswordClientCredential表示。而在ClientCredentials中，只读属性UserName表示这样一个用户凭证。你可以按照Windows凭证的方式为ChannelFactory<TChannel>或者ClientBase<TChannel>基于用户名/
和传统的分布式远程调用一样，WCF的服务调用借助于服务代理（Service Proxy）。而ChannelFactory<T>则是服务代理的创建者。WCF采用基于终结点（Endpoint）服务消费方式：WCF服务通过一个或者多个终结点暴露给潜在的服务消费者，服务的消费中通过与之匹配的终结点与之交互。在客户端，我们具有两种典型的服务代理创建方式，其一是通过诸如SvcUtil.exe这样的工具导入服务的元数据生成相应的服务代理（一个继承自ClientBase<T>的类型）代码和相关配置；其二是直接通过相应的终结
整个可靠会话的机制是完全在信道层实现的，而整个信道层的最终缔造者就是绑定，所以可靠会话编程是围绕着绑定进行的。《上篇》对实现可靠会话的绑定元素已经如何使用系统绑定实现可靠会话进行了介绍，下篇将和你探讨WCF可靠会话编程模型余下两个主题：自定义绑定和对消息传递的强制约束。 一、为自定义绑定的可靠会话进行设置 绑定是一系列绑定元素的有序组合，但是系统绑定为我们提供适应了某种典型通信环境的绑定元素组合方式，可以看成是“套餐”。但是，如果套餐不符合您的胃口，你应该查看菜单点你喜欢的菜肴。自定义绑定给了你最大的自由度
昨天有人在微博上问我如下一个问题： 老蒋，客户端调用wcf的一个接口函数时，有没有什么办法可以先弹出一个确认框，确认后再执行调用。因为这个接口函数再很多地方都执行了调用，所以我想在某个入口进行统一地
本文仅提供通过设置SoapHeader来控制非法用户对WebService的调用，如果是WebService建议使用WSE3.0来保护Web服务，如果使用的是Viaual Studio 2008可以使用WCF，WCF里面提供了更多的服务认证方法。以下提供一种基于SoapHeader的自定义验证方式。
在采用TLS/SSL实现Transport安全的情况下，客户端对服务证书实施认证。但是在默认情况下，这种认证仅仅是确保服务证书的合法性（通过数字签名确保证书确实是由申明的CA颁发）和可信任性（证书或者CA证书存储于相应的可信赖存储区）。而WCF提供服务证书并不限于此，客户端对服务认证的模式应该是这样的：服务端预先知道了服务的身份，在进行服务调用之前，服务端需要提供相应的凭证用以辅助客户端确认调用的服务具有预先确定的身份。对于这样的服务认证模式，具有两个重要的概念，即服务凭证和服务身份。 目录：
近半年以来，一直忙于我的第一本WCF专著《WCF技术剖析（卷1）》的写作，一直无暇管理自己的Blog。在《WCF技术剖析（卷1）》写作期间，对WCF又有了新的感悟，为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充，会对书中的一些内容进行展开讲述，同时会囊括很多由于篇幅的原因忍痛割弃的内容。 [第1篇] 通过一个ASP.NET程序模拟WCF基础架构 本系列的第一篇，我将会对WCF的基本架构作一个大致的讲解。不过，一改传统对WCF的工作流程进行平铺直叙，我将另辟蹊径，借助于我
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。 在这个例子中，我们将实现一个简单的计算服务（CalculatorService），提供基本的加、减、乘、除的运算。和传统的分布式通信框架一样，WCF本质上提供一个跨进程、跨机器以致跨网络的服务调用。在本例中，客户端和服务通过运行在相同的同一台机器上不同进程模拟，图1体现了客户端
Windows® Communication Foundation (WCF) 提供了许多扩展点，供开发人员自定义运行时行为,从而实现服务调度和客户代理调用。您可以通过编写能以声明方式应用到服务中的自定义行为来使用这些扩展点。本月将为您介绍这一流程的工作原理。 WCF 可扩展性 在上期专栏中，我重点介绍了 WCF 绑定概念，您可以为 WCF 服务上的各个终结点指定绑定。绑定控制该终结点的消息传递详细信息（发生在网络上的情况）。这是 WCF 建立一个能够在字节流（网络上的消息）和 WCF 消息间转换的通道堆栈
最后一章将进行WCF扩展和新特性的学习，这部分内容有一定深度，有一个基本的了解即可，当需要自定义一个完整的SOA框架时，可以再进行细致的学习和实践。 服务端架构体系的构建主要包含接下来的几个要素：服
在《上篇》中，我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭。对于《WCF技术剖析（卷1）》的读者，应该会知道在第7章中我通过类似于AOP的方式解决了相似的问题，现
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。
在《通过一个模拟程序让你明白ASP.NET MVC是如何运行的》一文中我通过一个普通的ASP.NET Web程序模拟了ASP.NET MVC的执行流程，现在我们通过类似的原理创建一个用于模拟WCF服务端和客户端工作原理的模拟程序。[源代码从这里下载] 目录 一、基本的组件和执行流程 二、创建自定义HttpHandler实现对服务调用请求的处理 三、定义创建WCF组件的工厂 四、定义HttpModule映射WcfHandler 五、创建自定
任何一个程序都需要运行于一个确定的进程中，进程是一个容器，其中包含程序实例运行所需的资源。同理，一个WCF服务的监听与执行同样需要通过一个进程来承载。我们将为WCF服务创建或指定一个进程的方式称为服务寄宿（Service Hosting）。服务寄宿的本质通过某种方式，创建或者指定一个进程用以监听服务的请求和执行服务操作，为服务提供一个运行环境。 服务寄宿的方式大体分两种：一种是为一组WCF服务创建一个托管的应用程序，通过手工启动程序的方式对服务进行寄宿，所有的托管的应用程序均可作为WCF服务的宿主，比如C
在《上篇》中，我通过一个具体的实例演示了WCF服务宿主的同步上下文对并发的影响，并简单地介绍了同步上下文是什么东东，以及同步上下文在多线程中的应用。那么，同步上下文在WCF并发体系的内部是如何影响服务操作的执行的呢？这实际上涉及到WCF的一个话题，即线程的亲和性（Thread Affinity），本篇文章将为你剖析WCF线程亲和机制的本质。 一、WCF线程亲和性（Thread Affinity） 对于服务端来说，WCF消息监听和接收体系通过IO线程池并发的处理来自客户端的服务调用请求，所以并发抵达的服务
由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟。为此我们我们写了一个简单的方法，用于列出一个具体的绑定对象所有的绑定元素，在介绍一个个具体的系统绑定中，我会使用该方法： 1: static void ListAllBindingElements(Binding binding) 2: { 3: BindingElementC
通过上一篇了解了模块内基本的层次划分之后，接下来我们来聊聊PetShop中一些基本基础功能的实现，以及一些设计、架构上的应用如何同WCF进行集成。本篇讨论两个问题：实现分布式的Membership和客户端到服务端上下文（Context）的传递。 一、 如何实现用户验证 对登录用户的验证是大部分应用所必需的，对于ASP.NET来说，用户验证及帐号管理实现在成员资格（Membership）模块中。同ASP.NET的其他模块一样，微软在设计Membership的时候，为了实现更好地可扩展性，采用了策略（Strat
在[第2篇]中，我们深入剖析了单调（PerCall）模式下WCF对服务实例生命周期的控制，现在我们来讨轮另一种极端的服务实例上下文模式：单例（Single）模式。在单例模式下，WCF通过创建一个唯一的服务实例来处理所有的客户端服务调用请求。这是一个极端的服务实例激活方式，由于服务实例的唯一性，所有客户端每次调用的状态能够被保存下来，但是当前的状态是所有客户端作用于服务实例的结果，而不能反映出具体某个客户端多次调用后的状态。WCF是一个典型的多线程的通信框架，对并发的服务调用请求是最基本的能力和要求，但是服务
整个WCF框架由两个基本的层次构成，即服务模型层和信道层。对信道层的扩展主要通过针对绑定的扩展实现，具体来说就是自定义绑定元素，以及相关的信道管理器（信道监听器和信道工厂）、信道来改变对消息的处理和传输方式。 而对于服务模式型层的扩展则主要体现服务端和客户端运行时框架的定制，进而让WCF按照我们希望的方式进行运作。由于整个运行时框架由一系列的可扩展组件构成，并且大部分运行时属性也可以改写，所以针对服务模型层的扩展具体体现在：根据具体的需要定义相应的组件，并以某种情形将这些自定义的组件应用到运行时框架相应的地
在《原理篇》中我们谈到：如果采用自定义安全主体权限模式，我们可以通过自定义AuthorizationPolicy或者ServiceAuthorizationManager实现对基于当前认证用于相关的安全主体的提供，进而达到授权的目的。为了让大家对此有个更加深刻的认识，在这篇文章中我们会提供一个具体的例子。[源代码从这里下载] 目录： 一、创建自定义AuthorizationPolicy 二、创建自定义ServiceAuthorizationManager 三、通过自
本篇文章介绍可以算是WCF 4.0基于限流（Throttling）的新特性，是在修订《WCF技术剖析（卷1）》的时候编写演示实例的时候发现的。这个特性没有出现在官方文档上面，至少在MSDN上的相关介绍依然是错误的。 一、流量限制简介 WCF是一个基于多线程的消息监听、接收和处理框架体系，能够同时应付来自相同或者不同客户端的服务调用请求，并提供完善的同步机制确保状态的一致性。一方面，我们期望WCF服务端能够处理尽可能多的并发请求，但是资源的有限性决定了并发量有一个最大值。如果WCF不控制进入消息处理系统的并发
终结点分发器在自己的运行时中对请求消息的处理最终肯定体现在相应操作的执行。如果从服务描述的角度来看，操作是一个OperationDescription对象。而服务端分发运行时中的操作则代表的是一个DispatchOperation对象。作为服务描述的一部分，服务所有终结点的所有操作描述（OperationDescription）在ServiceHost创建过程中被创建。而当ServiceHost被正常开始时，这些操作描述最终转换成分发操作（DispatchOperation）。而DispatchRuntim
我们想对WCF具有一定了解的人都会知道：在客户端通过服务调用进行服务调用过程中，服务代理应该及时关闭。但是如果服务的代理不等得到及时的关闭，到底具有怎样的后果？什么要关闭服务代理？在任何时候都需要关闭服务代理吗？是否有一些例外呢？本篇文章将会围绕着这些问题展开。
本系列先后通过《实例篇》、《概念篇》、《协议篇》和《编程篇》对WCF的可靠会话进行了详细探讨。作为本系列的最后一片，我们将深入到WCF的可靠会话体系的最底层，对实现可靠会话的实现原理进行深入剖析。如果读者仔细阅读本系列博文，相信会使读者对可靠会话的理解提升到一定的高度。 从《编程篇》中，我们不难看出可靠会话的编程仅仅围绕着一个对象，那就是绑定。绑定在整个WCF架构模型具有重要的地位。WCF整个架构模型由两部分构成，即服务模型（Service Model）层和信道（Channel）层，而绑定是信道层的缔造者，
其实针对安全主体的授权实现的原理很简单，原则上讲，只要你能在服务操作执行之前能够根据本认证的用户正确设置当前的安全主体就可以了。如果你了解WCF的整个运行时框架结构，你会马上想到用于授权的安全主体初始化可以通过自定义CallContextInitializer来实现。[源代码从这里下载] 目录： CallContextInitializer简介 步骤一、自定义CallContextInitializer 步骤二、创建服务行为 步骤三、使用服务行为进行授权
作为WCF中一个核心概念，终结点在不同的语境中实际上指代不同的对象。站在服务描述的角度，我们所说的终结点实际上是指ServiceEndpoint对象。如果站在WCF服务端运行时框架来说，终结点实际上指代的是终结点分发器（EndpointDispatcher）。而ServiceEndpoint与EndpointDispatcher是一一匹配的，并且前者是创建后者的基础。而终结点分发器具有自己的运行，即分发运行时（DispatchRuntime）。 目录 一、终结点分发器（EndpointDisp
在设计和实现服务协定后，即可配置服务。在其中可以定义和自定义如何向客户端公开服务，包括指定可以找到服务的地址、服务用于发送和接收消息的传输和消息编码，以及服务需要的安全类型。
本系列适合新手，从0学起。共同学习，共同探讨。 基础概念 SOA：就是采用Web服务的架构 它有一些特性，需要了解： 1、自治的：不依赖于访问它的客户端和其他服务，可以独立的进行部署和实施版本策略和安全策略。 2、依赖于开放的标准：让不同的厂商开发的服务能够进行互操作。 3、支持跨平台 4、鼓励创建可组合的服务 5、鼓励服务的复用 6、强调松耦合：契约的实现 WCF应用实例，帮助理解WCF服务的基本结构 过程： 1、构建解决方案 Contracts：定义服务的契约（接口部分） Services：定义服务的实
信道管理器是信道的创建者，一般来说信道栈的中每个信道对应着一个信道管理器。基于不同的消息处理的功能，将我们需要将相应的信道按照一定的顺序能组织起来构成一个信道栈，由于信道本身是由信道管理器创建的，所以信道对应的信道管理器也构成一个信道管理器栈，栈中信道管理器的顺序决定由它所创建信道的顺序。 对于WCF的信道层来说，信道管理器在服务端和客户端扮演着不同的角色，服务端的信道管理器在于监听来自客户端的请求，而客户端的信道仅仅是单纯的创建用于消息发送的信道。因此，客户端的消息管理器又称为信道监听器（Channel
在上面一篇文章中，我们对不同版本的IIS，以及ASP.NET得的实现机制进行了详细而深入的分析。在介绍IIS7.0的时候，我们谈到，HTTP.SYS+W3SVC实现了基于HTTP的请求监听，在此基础上引入了以下三组网络监听器（Listener）和监听适配器（Adapter），实现了基于TCP、Named Pipes和MSMQ的网络监听，图1揭示了IIS7的总体结构。 TCPListener|TCP Listener Adapter NamedPipes Listener|Named Pipes Liste
双工（Duplex）模式的消息交换方式体现在消息交换过程中，参与的双方均可以向对方发送消息。基于双工MEP消息交换可以看成是多个基本模式下（比如请求-回复模式和单项模式）消息交换的组合。双工MEP又具有一些变体，比如典型的订阅-发布模式就可以看成是双工模式的一种表现形式。双工消息交换模式使服务端回调（Callback）客户端操作成为可能。本文测试Mono 3.0.2/.NET 4对双工（Duplex）模式的WCF支持。 演示基于双工通信的WCF应用是一个简单的计算服务CalculatorService，我们
WCF事务编程其实很简单，可以用三句话进行概括：通过服务契约决定事物流转（Transaction Flow）的策略；通过绑定实施事务的流转；通过服务行为控制事务的相关行为。本篇文章着重介绍如果通过TransactionFlowAttribute特性定义事务流转策略。 契约时是一种双边协定，是双方就某个关注点达成的一种共识。对于分布式事务的实现来讲，首先需要解决的是事务流转的问题，即事务将客户端的事务流向服务端。要解决事务流转的问题，需要在事务的发送方和接收方就流转问题达成共识，即双方采用相匹配的事务发送
对于任何一个企业级应用来说，安全（Security）都是一个不可回避的话题。如何识别用户的身份？如何将用户可执行的操作和可访问的资源限制在其允许的权限范围之内？如何记录用户行为，让相应的操作都有据可查？这些都是应用的安全机制或者安全框架需要考虑的典型问题，它们分别对应着三个安全行为：认证（Authentication）、授权（Authorization）和审核（Auditing）。 除了这些典型的安全问题，对于一个以消息作为通信手段的分布式应用，还需要考虑消息的保护（Message Protection）
WCF的安全体系主要包括三个方面：传输安全（Transfer Security）、授权或者访问控制（Authorization OR Access Control）以及审核（Auditing）。而传输安全又包括两个方面：认证（Authentication）和消息保护（Message Protection）。认证帮助客户端或者服务确认对方的真实身份，而消息保护则通过签名和加密实现消息的一致性和机密性。WCF采用两种不同的机制来解决这三个涉及到传输安全的问题，我们一般将它们称为不同的安全模式，即Transpor
在完成了对于WCF事务编程（《上篇》、《中篇》、《下篇》）的介绍后，本篇文章将提供一个完整的分布式事务的WCF服务应用，通过本例，读者不仅仅会了解到如何编程实现事务型服务，还会获得其他相关的知识，比如DTC和AS-AT的配置等。本例还是沿用贯通本章的应用场景：银行转帐。我们将会创建一个BankingService服务，并将其中的转帐操作定义成事务型操作。我们先从物理部署的角度来了解一下BankingService服务，以及需要实现怎样的分布式事务。 一、从部署的角度看分布式事务 既然是实现分布式事务，那
在一个典型的服务调用场景中，具有两个基本的角色，即服务的消费者和服务的提供者。从消息交换的角度讲前者一般是消息的最初发送者，而后者则是消息的最终接收者。在很多情况下，由于网络环境的局限，消息的最初发送者和最终接收者不能直接进行消息交换，这就需要一个辅助实现消息路由的中介服务，这就是我们接下来要介绍的路由服务。 目录 一、路由服务就是一个WCF服务 路由服务契约的定义 路由服务契约的定义 二、基于消息内容的路由策略
为什么要用x.509证书? WCF的服务端和客户端之间，如果不作任何安全处理(即服务端的<security mode="None">)，则所有传输的消息将以明文方式满天飞，在internet/intr
今天介绍WCF 4.0的另外两个新特性：标准终结点（Standard Endpoint）和无(.SVC)文件服务激活（File-Less Activation）。前者实现了针对典型通信场景对终结点的定制，后者让你在进行IIS/WAS的服务寄宿中无须定义.svc文件。 一、标准终结点 我们知道，绑定的本质就是一系列相关绑定元素的有序集合，而系统绑定就是基于若干典型的通信场景对相关绑定元素的整合。WCF通过系统绑定对绑定元素进行了定制，那么能否在终结点级别对组成该终结点的ABC（地址、绑定和契约）也进行相应的定
由于WCF采用.NET托管语言（C#和NET）作为其主要的编程语言，注定以了基于WCF的编程方式不可能很复杂。同时，WCF设计的一个目的就是提供基于非业务逻辑的通信实现，为编程人员提供一套简单易用的应用编程接口（API）。WCF编程模式的简单性同样体现在异常处理上面，本篇文章的主要目的就是对WCF基于异常处理的编程模式做一个简单的介绍。 一、当异常从服务端抛出 对于一个典型的WCF服务调用，我个人倾向于将潜在抛出的异常费为两种类型：应用异常（Application Exception）和基础结构（Infr
服务调用的目的体现在对某项服务功能的消费上，而功能的实现又定义在相应的服务类型中。不论WCF服务端框架处理服务调用请求的流程有多么复杂，最终都落实在服务实例的激活和操作方法的执行上面。WCF中的实例管理（Instance Management）旨在解决服务实例的激活和服务实例生命周期的控制。 会话（Session）的目的在于保持来自相同客户端（服务代理）多次服务调用之间的状态。从消息交换的角度来讲，会话通过消息识别机制判断调用某个服务的消息来源，从而将来自相同客户端的所有消息关联在一起。所以，会话实现了消息
REST服务采用面向资源的架构，而资源通过URI进行标识和定位，所以URI在REST中具有重要的地位。对于WCF来说，服务调用请求的URI映射为某个具体的操作，所以服务端需要解决的是如何根据请求URI选择出对应的操作。如果采用SOAP，操作的选择是根据消息的<Action>报头来实现的，那么REST服务又采用怎样的操作选择机制呢？ 目录 一、URI模板 二、UriTemplate 三、UriTemplateTable 四、WebHttpDispatchOper
今天看到WCF，说是整合了Net remoting，Web service。。。下面列一下概念。 一 WCF 概括地说，WCF具有如下的优势： 1、统一性 前面已经叙述，WCF是对于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技术的整合。由于WCF完全是由托管代码编写，因此开发WCF的应用程序与开发其它的.Net应用程序没有太大的区别，我们仍然可以像创建面向对象的应用程序那样，利用WCF来创建面向服务的应用程序。 2、互
结束了服务认证的介绍之后，我们接着介绍WCF双向认证的另一个方面，即服务对客户端的认证，简称客户端认证。客户端认证采用的方式决定于客户端凭证的类型，内容只要涉及基于以下三种典型客户凭证类型的认证：Windows、用户名和X.509证书。从编程的角度来讲，Windows认证是最为简单的认证方式。在这种认证方式下，客户端进程运行的Window帐号对应的Windows凭证被自动作为调用服务的客户端凭证，所以无需显示指定具体的Windiws凭证。 如果需要另一个Windows帐号的名义调用服务，客户端就需要通知指定
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
