大中型企业有相当大部分都在使用Windows Server以及.Net架构来构建企业Web服务和应用，因此Web服务和Web应用程序通常被ASP.NET和IIS主管。保护Web服务和Web应用程序是一个配置环境的问题而不是编程问题。例如，使用SSL/TLS通过加密来确保保密性是最好的实现方式。为你的应用程序激活它，简单的方式是对IIS进行恰当的配置，然后使用前缀为https的URL进行访问。
ASP.NET安全性的配置主要涉及到编辑一个分级的XML文档集合。在这棵树的顶部是machine.config，其中运行在这台机器上的用于所有ASP.NET应用程序的全局设置被制定好。在全局配置文件的下面是web.config文件，它包含了每个单独的ASP.NET应用程序的设置。本文将讨论如何在这些文件中配置CAS、身份认证、假冒以及授权等方面，来保证Web服务安全运行。
1、为ASP.NET配置CAS
尽管CAS主要作为保护系统客户端免受恶意移动代码侵扰的一种方式，但它与Web服务和Web应用程序在服务器端的部署仍有一些关联。例如，一台服务器可能主管不止一个的个体，团体和组织授权的ASP.NET应用程序;在这种情况下，CAS有助于减少由一个实体拥有的应用程序被另外一个实体拥有的应用程序干扰的风险，也有助于被服务器操作系统干扰的风险。
但是，你应该注意到：在默认情况下，CAS策略授予ASP.NET应用程序一套完整的程序集。因为他们从本地机器上运行。很显然，当配置你的应用程序时，你应该修正这一点。.NET框架定义了许多不同的信任级别：Full, High, Medium, Low和 Minimal，你可以用他们来确定ASP.NET应用程序的特权授予。除了这些策略中的第一种在配置文件 web_hightrust.config, web_mediumtrust.config等中被指定，其他所有策略位于.NET框架根目录下的配置子目录。为了给一个特殊的ASP.NET应用程序授权一个medium信任等级，你必须给它的web.config文件如下的结构：
<configuration>
<system.web>
<trust level="Medium"/>
</system.web>
</configuration>
2、以最小特权运行
处理单个ASP.NET请求的“工作进程”运行在账户为ASPNET的Windows环境中。这个特殊的账户有一个受限的Windows 特权集，为了控制这种损害，应该让给ASP.NET应用程序。但是，对于工作进程来说，在与IIS相同的账户——SYSTEM账户下执行是可能的。如果你想要这种情况发生，你编写的machine.config文件应该像这样：
<configuration>
<processModel userName="System" password="AutoGenerate"/>
</configuration>
为了让这样的更改生效，必须重启IIS管理服务和WWW发布服务。
这样做的一个原因可能是：为了获得Windows用户用于假冒目的的访问令牌，允许你的ASP.NET代码从Win32 API中调用LogonUser。但是，这违反了最低权限(least privilege)的基本安全原则，以及显著增加了成功攻击所引起的损害。因此在那样做之前你应该仔细斟酌。
3、身份认证
ASP.NET提供了四中典型的身份认证：None,Windows,Forms以及Passport。每一种认证都是在应用程序的根文件web.config中配置的。例如，为了完全禁用ASP.NET身份认证——适合于不需要用户登录的公共网站，那么你需要这样的一个配置文件：
<configuration>
<system.web>
<authentication mode="None"/>
</system.web>
</configuration>
你应该牢记IIS身份认证和ASP.NET身份认证之间的相互作用。两者都将需要被正确地配置，以达到预期的效果。通常情况下，你会在IIS和ASP.NET两者之中中使用Windows身份认证模式;或者在IIS中以及在ASP.NET中的None,Forms,Passport的某一种使用匿名模式。
在IIS和ASP.NET两者中使用Windows身份认证的优点是：密码不用通过网络发送，而是客户端应用程序向IIS提供了当前登录用户身份的相关信息，那使得这些信息转发到你的ASP.NET应用程序上。这种方法的缺点是：它依赖于客户端和服务器端的Windows操作系统。Forms式的身份认证对于基于互联网的系统是一种更合适的方法，但是在这种情况下，使用SSL/TLS来确保用户提供的凭证是加密的，这非常有必要。
4、假冒
不管Windows身份认证是否已经选择，ASP.NET身份认证没有指明ASP.NET应用程序运行下的用户环境。如果你想要你的应用程序在任意账号，而不仅仅是ASPNET账号的环境中运行，你必须要假冒身份。
假设请求的用户已经被IIS许可为有效的Windows用户，这是由以下web.config中的内容完成的：
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>
这将导致ASP.NET应用程序假冒发出请求的用户。然而，如果IIS设置为匿名身份认证，那么在IIS中，ASP.NET应用程序假冒任意一个用户账号，这些账号已经被配置为匿名访问。
如果你想要你的ASP.NET应用程序假冒特定的用户，这是很简单的：
<configuration>
<system.web>
<identity impersonate="true" userName="Foo\bar" password="baz"/>
</system.web>
</configuration>
在此很明显的危险就是：在web.config中用户凭证以明文形式存在。避免该危险是可能的，我们通过在注册表中存储加密的用户凭证，并且从web.config的元素来引用他们。
<identity impersonate="true"
userName="registry:HKLM\Software\MyApp\AspNet,Name",
password="registry:HKLM\Software\MyApp\AspNet,Password"/>
这个实用的aspnet_setreg.exe必须被用于加密用户凭证以及在注册表中存储加密的用户凭证。
5、授权
当你在ASP.NET中应用Windows授权时，为了访问一个给定的资源，被授权的用户必须有必要的NTFS权限。这被称为文件授权(file authorization)。ASP.NET支持其他的更具灵活性的授权类型，这被称为URL授权(URL authorization)。不像文件授权，这是通过应用程序的web.config文件来配置的。它主要是基于通过对ASP.NET身份认证来对应用程序进行分配;而不是基于一个经过许可的Windows账户的权限上。一个简单URL授权配置的例子如下：
<configuration>
<authorization>
<allow verbs="GET" users="Fred,Joe"/>
<deny verbs="POST" users="Fred,Joe"/>
<allow roles="Developers"/>
<deny users="*"/>
</authorization>
</configuration>
这个例子允许用户Fred和Joe将HTTP GET请求提交到应用程序，以求得由web.config文件管理的网站中的任意资源。但是若通过HTTP POST请求，就会拒绝他们访问这些资源。担任开发者角色的任意人(除了Fred或 Joe)是允许无限制的访问该网站的，但是其他所有用户被拒绝访问任何资源。这些元素的顺序非常重要，因为第一个匹配将是ASP.NET会使用到的。最后明确通常需要锁定网站，因为默认情况下，machine.config文件包括了这样的配置：
<authorization>
<allow users="*"/>
</authorization>
