利用ASP.NET访问共享网络资源

　　有几种方法可以用来访问网络资源：

　　·使用asp.net进程身份

　　·使用匿名用户帐户

　　·使用logonuser api

　　·使用服务性的组件（企业服务）

　　使用asp.net进程身份似乎有很明显的缺陷。缺省情况下，当应用程序试着访问资源时，asp.net进程身份提供一个身份（aspnet）。最简单的解决方案是创建一个具有与远程计算机上相匹配的用户名和密码的本地帐户。大多数企业都会有庞大的内联网，因此这一方法是不切实际的。另外，知道是谁在访问资源也是非常重要的。尽管该方法足以访问网络资源，但效率不够高；第二个方法是使用匿名帐户，例如iusr_machine。与上面的原因相同，这种方法的效率显然也不高；第三种方法是使用logonuser api，这种方法要求通过调用win32 logonuser api模仿一个特定的身份，还可以通过配置asp.net项目web.config文件中的＜identity＞元素进行模仿。据msdn上的一篇文章称，不建议用户使用以上这些方法，应当避免在windows 2000服务器上使用它们，因为它们要求向asp.net帐户进程授予“作为操作系统一部分运行”的权限，从而极大地降低了web应用程序的安全性。因此，该方法也不理想。最后，也是最可行的解决该问题的方法是使用配置为作为用于访问网络资源固定身份运行的服务性组件。这种方法听起来令人胆怯，但它是目前最好的解决方案，它的架构如下图所示：

　　梅耶在http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetch08.asp上发表的一一篇有关安全的文章中表示，在企业服务服务器应用程序中使用服务性组件有以下好处：

　　·在使用的身份方面的灵活性，不必只依赖于asp.net身份。

　　·受信任或权限较高的代码能够与主web应用程序隔离。

　　·增加的进程跃距提高了攻击难度，它使得黑客更难跨越进程的边界，使用具有较高权限的进程。

　　·如果需要手动处理logonuser api调用的模仿，我们可以在一个与主web应用程序隔离的进程中完成这一工作。



　　开发服务性组件

　　从com+中接受服务的组合体被称作服务性组件。为了开发服务性组件，开发人员必须具备丰富的com+技术经验。com+应用程序不是传统意义上的应用程序，它不包含用户界面。com+应用程序实际上是构成应用程序的组件、com和.net的容器，它不是新版的com，也不是com和dcom的组合，而是遗传自mts（微软事务服务）的一种技术。

　　下面是开发服务性组件所需要的步骤：

　　1、创建一个新类库项目，以开发作为web应用程序类库的中间层组件。

　　2、添加合适的类、方法和属性。由于需要访问文件和文件夹，我们需要引入system.io名字空间。

　　3、创建一个web窗体应用程序。

　　现在就可以对组件进行测试了。为了在企业服务应用程序中实现较高的安全性，必须使用windows认证实现模仿，这一工作可以在web应用程序的web.config文件中实现。它使得服务性组件能够认证调用者，并根据调用者的身份作出授权决策。在开发期间，尽管组件还不是服务性组件，它仍然能够为访问共享文件和文件夹提供足够的安全性。

＜authentication mode="window" /＞
＜identity impersonate="true" /＞

　　要进行测试，需要首先对类进行编译，然后将对象的引用添加到web应用程序中。对类进行如下所示的初始化：

dim objenterprise as new accessingsharedresources.dal_accessnetwork()

　　4、创建强命名组合体

　　·通过依次选择start menu --＞ programs --＞ microsoft visual studio .net --＞ visual studio .net tools --＞ visual studio .net command prompt运行visual studio .net command prompt。

　　·找到项目所在的目录，并输入下面的命令：sn -k keypair.snk。

　　·上面的命令会创建一个公/私钥对，visual studio .net ide可以用它们给我们的组件一个强命名。另外需要注意的是，在项目目录中创建了一个keypair.snk文件。

　　·打开assemblyinfo.vb文件代码窗口，并添加下面的assembly属性：

＜assembly: assemblykeyfile("keypair.snk")＞

　　·编译该项目。这将创建强命名的组合体。

　　5. add the object to the gac (global assembly cache)


　　6、在gac（全局组合体缓冲区）中添加对象

　　·通过点击start menu --＞ programs --＞ administrative tools --＞ microsoft .net framework configuration打开.net框架配置工具。

　　·点击select assembly cache --＞ select view list of assemblies in the assembly cache浏览gac中所有的组合体。

　　·右击assembly cache图标，从弹出菜单中选择add。

　　·找到该项目的bin目录中的accessingsharedresources.dll文件，并双击它。

　　注意：如果命令提示行窗口仍然在运行，输入gacutil /i accessingsharedresources.dll，也能够将对象添加到gac中。这是在gac中添加对象的第二种方法。

　　7、添加system.enterpiseservices.dll的引用

　　8、引入恰当的enterprise services名字空间

　　·imports system.enterpriseservices

　　·imports system.runtime.compilerservices

　　·imports system.reflection

　　9、在各个类中继承servicedcomponent类

public class dal_accessnetwork
inherits servicedcomponent

　　10、在支持服务性组件的assemblyinfo.vb文件中添加与服务性组件相关的组合体属性。

　　·引入system.enterpriseservices名字空间

　　·添加下面的代码：

'com+应用程序名字
＜ assembly: applicationname("accessingsharedresources")＞
'com+激活类型
＜assembly: applicationactivation(activationoption.server)＞

　　11、设置assemblyversion：

　　据msdn上的文章（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetch09.asp）称，当新项目创建时由microsoft visual studio(r) .net开发系统生成的缺省assemblyversion属性是＜assembly: assemblyversion("1.0.*")＞。每当项目重建时，就会产生新的组合体版本，这也会产生识别服务性组件类的新的类识别符（clsid）。如果使用regsvcs.exe重复向组合体注册组件服务，就会在components文件夹中看到具有不同clsid的复制的组件。

　　尽管这符合严格的com规则，能够阻止现有的可管理和不可管理的客户破坏它，在开发过程中仍然是非常烦人的。在测试和开发过程中，考虑通过使用如下所示的组合体级assemblyversion属性设置一个明确的版本：

＜assembly: assemblyversion("1.0.0.1")＞

　　这一设置将阻碍每次编译项目时产生新的clsid。

　　12、生成新的com+应用程序，在新的com+应用程序中注册该组合体

　　·运行visual studio .net command prompt。

　　·找到bin目录中dll文件的位置。

　　·输入regsvcs /c accessingsharedresources.dll，并键入回车。

　　13、修改web应用程序

　　·添加system.enterrpiseservices.dll的引用

　　·在web客户端软件中添加imports system.enterpriseservices语句

　　到这一步，服务性组件就全部完成了。我们可以将该组件看作一个com+应用软件。

　　·通过选择start --＞ programs --＞ administrative tools --＞ component services运行component services manager。

　　·扩展console root --＞ component services --＞ computers --＞ my computer --＞ com+ applications --＞ accessingsharedresources--＞ components。



　　优点和缺点

　　使用服务性组件的优点如下所示：

　　·使用身份的灵活性，我们无须只依赖asp.net身份。

　　·受信任或权限较高的代码可以与主web应用软件隔离。

　　·增加的进程跃距提高了系统的安全性，使得黑客更难跨过进程边界，接近权限较高的进程。

　　·如果需要处理带有logonuser api调用的模仿，我们可以在与主web应用软件隔离的进程中完成。
　
　　缺点如下所示：

　　·调用服务性组件的速度不如本地.net对象快，因此应用软件的性能会受到影响。

　　·要求多余的步骤和代码。

　　·与本地.net对象相比更难管理。

　　·需要在com+应用软件中安装dll。

　　结论

　　尽管没有利用对象集中、事物支持、同步、事件跟踪等com+的基本功能，我们已经完成了我们的对象。只在com+应用程序中安装本地.net类和添加数行特殊的com+代码就足以完成在网络上访问共享资源的任务。