代码改变世界

WCF在安全性方面的支持(1):一些概念

2007-07-25 02:32 Jeffrey Zhao 阅读(...) 评论(...) 编辑 收藏

前言

对于一个应用程序来说,最重要的特性之一就是安全性。例如,安全方面的需求往往会最早被提出,安全方面Bug的优先级和危害程度往往都被定为最高。有时候为了提高安全性,还需要牺牲一定的性能或者其他因素。因为性能,往往可以通过一些别的方式,例如添加一台服务器作负载均衡来解决(顺便插一句,我现在觉得对于企业来说,能够用钱解决的往往就不是问题了),或者在之后的版本中进行优化;但是如果出了安全性方面的漏洞,很可能就已经造成了无法弥补的损失。试想,如果Windows Live Passport出现了安全上的漏洞导致用户信息泄露,这将会引出多大的风波,对于微软来说会造成多少名誉上的损害。但是如果性能上出现了问题——这方面例如Windows Live Space或Hotmail的早期版本都不怎么样,但是在优化之后还是吸引了大量的用户群体。

安全性是如此的重要,自然WCF也会为它提供了良好的支持,否则也无法称之为一个成熟的模型了(我认为,微软希望,也正在把WCF变成.NET或者说Windows平台下分布式通信的事实标准)。但是虽然WCF提出了丰富而强大的安全性支持,但是如果使用不当,依旧会产生安全方面的问题(同样的例子还有Sql注入,要保证安全型还是必须通过良好的编程实践来达成),甚至还不如不依赖WCF的功能,直接使用传统的方式,例如使用硬件或软件防火墙来阻止非法的连接。反过来说,选择什么样的安全实践也是要考虑到项目的实际情况。例如有的时候我们的确可以使用传统的方式来保证安全性,再今后的版本中再采用高级的实践——尤其我们现在有了WCF提供的模型,我们的优化可能只是部署一个新的程序集,然后更新一下配置而已。

近期因为项目原因重新阅读了各种资料,主要围绕着WCF在安全方面所提供的支持,同时准备在公司内部进行一些培训和交流。这一系列文章也就算是对于最近一段时间研究内容的总结吧。

Service Model和Channel Layer

WCF提出的通信模型主要可以分为两大部分:Service Model和Channel Layer。它们各司其职,“互不干涉内政”,因此能够自由地组合与扩展,使开发人员能够利用WCF提出的模型来轻松实现强大的通信功能。不过事实上,按照官方的说法,Channel Layer是Service Model的组成部分(而且官方的说法的确还是有道理啊),但是我在了解了这些内容之后还是认为将两者概念分开为好,希望能够就这方面的概念问题和大家讨论一下。

WSDL是描述一个服务的XML格式的语言。通过一个服务的WSDL我们可以得知这个服务的地址、服务使用的协议、以及服务中的各种具体定义(例如定义了哪些消息等等)。显然,如果每次生成服务时都要自己编写代码输出大段复杂的WSDL,或者在使用服务时都要解析WSDL并且在请求时还需要自己生成SOAP内容,这样的开发效率就实在是太低了。因此,成熟的框架会提供一种“抽象”机制,使开发人员能够轻松的定义服务,尽可能的将注意力集中在业务逻辑的实现上。例如使用ASP.NET释放Web Services,或者利用.NET Framework中的wsdl.exe根据某个服务的WSDL描述来生成代理。这些框架和工具都能够大大提高我们的开发效率。

WCF中的Service Model就是这样的一种抽象。简单地说,它可以被认作是一个与WSDL产生映射的模型。在Service Model中,与WSDL各部分相对应的概念被称作为address、binding和contract,这就是被各种资料中所提到的“A、B、C”。除了提供了“定义”这样的模型(用来与WSDL对应)之外,Service Model还负责了上述模型与外部请求或者回复信息的转化。

例如,我们的Host一旦接受到了一个请求,那么它会把这个请求内容反序列化成为一个Message类型的对象,并交给Service Model处理。此时Service Model开始工作,例如它会构造出处理这个请求的环境,识别出该用哪个类型来处理请求,选择或者创建一个类型的实例,确定应该调用的方法,随后调用方法,得到一个结果对象。然后Service Model同样负责将这个结果对象转化为一个Message类型的对象,最终将其序列化并输出(整个过程有十多个步骤,我这里只是提到了一些最重要并且最容易理解的环节。由此可见WCF的可扩展性是多么的强大)。如果使用WCF生成调用服务的代理,那么Service Model工作性质还是差不多,只是方向相反而已。

那么是由什么组件负责将一个外部的请求反序列化成为一个Message对象,待方法调用完成之后,又将表示结果的Message序列化成为输出的内容呢(如果使用WCF作为客户端代理,那么就变成将Message序列化为请求的内容,并且将收到的回复内容反序列化成Message对象)?这就是Channel Layer的作用。

Channel Layer定义个一个由一系列Channel组成的Stack,Message对象在穿越这个Channel Stack的时候会经过每个Channel的处理,一步步地“形变”,最终成为了我们需要“数据形态”。例如服务返回的Message对象在经过了功能为SOAP XML转化的Channel之后便成了SOAP XML的形式,然后再经由一个负责加密的Channel则成为了Encrypted数据(当然实际的步骤也没有那么简单),最终经由一个负责TCP/IP信道传送的Channel输送出去。试想,如果我们自定义一个Channel将Message转化为JSON格式,然后再使用一个Channel通过一个HTTP通道返回数据,那么不就能够支持ASP.NET AJAX的Web Service请求功能了吗?没错,的确可以这样。事实上在新的ASP.NET Futures类库中就提供了这样的组件,它们是学习如何扩展WCF的优秀范例。不过这已经是题外话了,有机会我们可以另起一个话题再说。

不过这里又要谈一下我个人的观点了,因为我对于Channel Stack的理解和官方说法有一定出入。无论从目前的官方文档,亦或是各类技术会议上谈到的Channel Layer,都是由一个一个Channel,“并列”地组合成一个Channel Stack。然后Message就像一个原材料通过生产线一样,最终得到了一个成品。

但是在我看来,Channel之间的关系不是并列的,而是使用了类似于“装饰模式”的嵌套的做法来实现的。在我看来,Channel与Channel之间是包含关系,Service Model将Message交给了最外层的Channel处理,而最外层的Channel根据它定义的某种逻辑,配合它邻近的那个下层的Channel处理的结果来操作这个Message对象,而不是简单地将处理的结果交给下一个Channel。这一点从自定义Channel的方式上就可以看出,基本上每个Channel内部都会用一个名为innerChannel的私有Field来保存下一个Channel,并且在自己的某些方法中使用innerChannel的方法。

根据我的理解可以得到一些推论,例如关闭一个Channel时,该Channel必须负责将它的innerChannel对象关闭;我们可以实现一个最简单同时无用的Channel,将所有的方法都直接委托给innerChannel,等等。而这些推论都是扩展Channel Layer的正确做法或结论,因此,我还是觉得自己的理解更加合理一些。当然,如果您在这方面有什么看法,也希望能够和您进行交流。

为什么要理解Service Model和Channel Layer?

似乎说了半天,我还没有涉及到WCF在安全方面的支持,却在大谈特谈一些“概念”。但是我认为,了解WCF的一些模型是掌握WCF的基础(我个人非常注重模型,也就是一个框架是如何抽象外部事物的,例如ASP.NET如何将HTTP请求抽象成WebForm)。只有了解了Service Model和Channel Layer的设计目的和功能,才能正确理解一些安全方面的做法是如何与这些模型结合的。例如,Channel Layer可以提供哪些安全上的保证,为什么Authentication操作是在Channel Layer中进行,而Authorization却是Service Model提供的呢?

WCF框架的设计并非随性而为,其中有着充分的理由,是那些世界顶级架构师们智慧和经验的结晶。当从“模型”的角度理解到这些内容之后,对于框架的使用往往就可以更上一层楼了。就拿我自己的经验来说,一开始必须“死记硬背”或者对照着Sample Code才能写出代码。而理解了模型之后,似乎代码或配置该怎么写,写在什么地方都是顺理成章的事情,在一些细节方面翻阅一下MSDN就能够解决开发中的大部分的问题。