07 2011 档案
摘要:终结点分发器在自己的运行时中对请求消息的处理最终肯定体现在相应操作的执行。如果从服务描述的角度来看,操作是一个OperationDescription对象。而服务端分发运行时中的操作则代表的是一个DispatchOperation对象。作为服务描述的一部分,服务所有终结点的所有操作描述(OperationDescription)在ServiceHost创建过程中被创建。而当ServiceHost被正常开始时,这些操作描述最终转换成分发操作(DispatchOperation)。而DispatchRuntime的Operations属性代表了对应终结点的所有分发操作。
阅读全文
摘要:作为WCF中一个核心概念,终结点在不同的语境中实际上指代不同的对象。站在服务描述的角度,我们所说的终结点实际上是指ServiceEndpoint对象。如果站在WCF服务端运行时框架来说,终结点实际上指代的是终结点分发器(EndpointDispatcher)。两者是一一匹配的,并且前者是创建后者的基础。而终结点分发器具有自己的运行,即分发运行时(DispatchRuntime)。
阅读全文
摘要:在这篇文章中,我们对信道分发器(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为我们提供了三种不同的方案。
阅读全文