ASP.NET应用程序的安全方案

摘要：本文ASP.NET应用程序身份验证的概念，介绍了各种身份验证模式并进行了比较，阐述了选择身份验证模式的机制，并给出了一种基于窗体身份验证模式的实现方法。


关键字：身份验证 authentication ASP.NET WEB应用


1.身份验证概念
    任何成功的应用程序安全策略的基础都是稳固的身份验证和授权手段，以及提供机密数据的保密性和完整性的安全通讯。
    身份验证（authentication）是一个标识应用程序客户端的过程，这里的客户端可能包括终端用户、服务、进程或计算机，通过了身份验证的客户端被称为主体（principal）。身份验证可以跨越应用程序的多个层发生。终端用户起初由Web应用程序进行身份验证，通常根据用户名和密码进行；随后终端用户的请求由中间层应用程序服务器和数据库服务器进行处理，这过程中也将进行身份验证以便验证并处理这些请求。
    图1列出了各种安全技术以及每种技术所提供的主要验证方式。
 
2. 身份验证模式
    如图1所示，Windows 2000上的.NET框架上提供了以下几种身份验证：

ASP.NET身份验证模式 
Enterprise Services身份验证 
SQL Server身份验证 
2.1 ASP.NET身份验证模式
    ASP.NET身份验证模式包括Windows、Forms（窗体）、Passport（护照）和None（无）。

2.1.1 Windows身份验证
    使用这种身份验证模式时，ASP.NET依赖于IIS对用户进行验证，并创建一个Windows访问令牌来表示已通过验证的标识。IIS提供以下几种身份验证机制：

基本身份验证 
简要身份验证 
集成Windows身份验证 
证书身份验证 
匿名身份验证 
2.1.2 护照身份验证
    使用这种身份验证模式时，ASP.NET使用Microsoft Passport的集中式身份验证服务，ASP.NET为Microsoft Passport软件开发包（SDK）所提供的功能提供了一个方便的包装（Wrapper）。此SDK必须安装在WEB服务器上。

2.1.3 窗体身份验证
    这种验证方式使用客户端重定向功能，将未通过身份验证的用户转发到特定的登录窗体，要求用户输入其凭据信息（通常是用户名和密码）。这些凭据信息被验证后，系统生成一个身份验证票证（ticket）并将其返回客户端。身份验证票证可在用户的会话期间维护用户的身份标识信息，以及用户所属的角色列表（可选）。

2.1.4 None
    使用这种身份验证模式，表示你不希望对用户进行验证，或是采用自定义的身份验证协议。

2.2 Enterprise Services身份验证
     Enterprise Services身份验证通过使用底层的远程过程调用（RPC，Remote Procedure Call）传输结构来进行，而这种结构又使用了操作系统安全服务提供程序接口（SSPI，Security Service Provider Interface）。可以利用Kerberose或NTLM身份验证机制对Enterprise Services应用程序的客户端进行验证。

2.3 SQL Server身份验证
    SQL Server可以通过Windows身份验证机制（Kerberose或NTLM），也可以通过其内置的身份验证方案-SQL身份验证机制进行验证。通常有两种可用的验证方案。

2.3.1 SQL Server and Windows 
    客户端可用通过SQL Server身份验证或Windows身份验证机制来连接SQL Server的某个实例。这种方式有时也被称为混合模式的身份验证。

2.3.2 Windows Only
    客户端必须通过使用Windows身份验证机制来连接到SQL Server的一个实例。

3. 选择身份验证机制
    设计分布式应用程序的身份验证是一项具有挑战性的任务。在应用程序开发的早期阶段，进行适当的身份验证设计有助于降低许多安全风险。 
3.1 各种身份验证机制的比较
  用户是否需要在服务器域中拥有Windows帐户 是否支持委托 是否需要Windows 2000客户端和服务器 凭据是否明文传输（需要SSL） 是否支持非IE浏览器 
基本身份验证 是 是 否 是 是 
简要身份验证 是 否 是 否 否 
NTLM身份验证 是 否 否 否 否 
Kerberos身份验证 是 是 是 否 否 
证书身份验证 否 是 否 否 是 
窗体身份验证 否 是 否 是 是 
护照身份验证 否 是 否 否 是 

3.2 选择身份验证机制需要考虑的因素
    标识 只有当应用程序的用户具有的Windows帐户可以通过一个受信任的权威机构（它可以被应用程序Web服务器访问）来进行验证时，使用Windows身份验证机制才是合适的。
    凭据管理 Windows身份验证的一个关键优势在于它可以使用操作系统进行凭据管理。当使用非Windows身份验证方式，例如窗体身份验证时，必须仔细考虑在何处以及如何保存用户凭据。其中最常用的方式是使用SQL Server数据库或是使用位于Active Directory中的User对象。
    标识流动 是否需要实现一个模拟/委托模型，并将原始调用者的安全上下文在操作系统级进行跨层流动-例如，以便支持审核或针对每个用户的精细授权。
    浏览器类型 应用程序的所有用户是否都拥有IE浏览器？或是你是否需要支持一个具有混合型浏览器的用户群？ 我们选择身份验证时需要根据各种方式的特点，综合考虑以上因素。

3.3 Intranet系统的选择决策流程
    参见图2。
 
3.4 SQL Server用户验证 
    对SQL Server的客户端进行验证，一般说来Windows身份验证要比SQL Server身份验证更安全，原因主要有以下几点： 
前者负责管理用户的凭据信息，而且用户的凭据不会在网络上传输。 
可以避免在连接字符串中嵌入用户名和密码。 
可通过密码过期时限、最小密码长度、以及多次无效登录后请求的帐户锁定等措施改进登录安全性。这样可以见少词典攻击的威胁。 
    但是某些特定的应用程序方案中不允许使用Windows身份验证，例如： 
数据库客户端和数据库服务器由一个防火墙分隔开，从而导致无法使用Windows身份验证。 
应用程序需要使用多个标识连接到一个或多个数据库。 
连接到的数据库不是SQL Server。 
在ASP.NET中没有一种安全的方式以特定的Windows用户的身份运行代码。 
    在以上这些方案中，将必须使用SQL身份验证，或是数据库的本机身份验证机制。 

4. ASP.NET身份验证实现
4.1 方案特性
在这部分，仅提供了一种Intranet下交互式WEB应用程序的身份验证的实现，本方案假设具有以下特性： 
只有通过了身份验证的客户端才能访问应用程序。 
数据库相信应用程序对用户进行了相应的身份验证-即应用程序代表用户对数据库进行调用。 
WEB应用程序通过使用ASP.NET进程帐户连接到数据库。 
用户的凭据信息是根据SQL Server数据库进行验证的。 
使用窗体身份验证模式。 
    在WEB应用程序中，用户的凭据信息是根据SQL Server数据库，采用窗体身份验证模式，便于实现用户个性化设计。采用应用程序代表用户对数据库进行调用的方式，可采用受信任子系统模型，更好地利用数据库连接池，并且可以保证用户不能直接访问后端数据库，另外可以减少后端的ACL管理工作。

4.2 安全配置步骤
4.2.1 IIS配置步骤
    对Web服务的虚拟根目录启用匿名访问。
    主要方法是使用IIS MMC管理单元，右击应用程序的虚拟目录，然后单击属性---〉目录安全性--〉匿名访问和安全控制--〉编辑。

4.2.2 ASP.NET配置步骤
    1． 将ASPNET帐户（用于运行ASP.NET）的密码重新设置为一个更安全的密码。
    这样允许在数据库服务器上复制一个本地帐户（具有相同的用户名和密码）。为了使用Windows身份验证连接到数据库时，能够使ASPNET帐户对来自数据库的网络身份验证要求进行响应，这是必须的。
    具体方法是编辑位于%windr%/Microsoft.NET/Framework/v1.1.4322/CONFIG目录下的Machine.config文件，将<processModel>元素上的密码属性重新配置，将其默认值<!-UserName="machine" password="AutoGenerate" -->改为<!-UserName="machine" password="NewPassword" -->。
    2． 配置ASP.NET，使用窗体身份验证。
    编辑位于WEB服务的虚拟根目录下的Web.config文件，将<authentication>元素设置为：
<authentication mode="Forms" >
<forms name="MyAppFormAuth" loginUrl="login.aspx" protection="All" timeout="20" path="/">
</forms>
</authentication>

4.2.3 配置SQL Server
     1． 在SQL Server数据库上创建一个和ASP.NET进程帐户匹配的Windows帐户。
用户名和密码必须和ASP.NET应用程序帐号匹配。
     2． 配置SQL Server，使其使用Windows身份验证。
     3． 为自定义的ASP.NET应用程序帐户创建一个SQL Server登录，授予对SQL Server的访问权。
     4． 创建一个新的数据库用户，并将登录名映射为数据库用户。
     5． 创建一个用户定义的新数据库角色，并将数据库用户添加到该角色。
     6． 为数据库角色确定数据库权限。 

4.3 程序代码
4.3.1 身份验证事件序列
    当未通过身份验证的用户试图放一个受保护的文件或资源被拒绝时，触发的事件序列如图3所示。
 
4.3.2 代码实现步骤
    1． 建一个WEB登录窗体并验证用户提供的凭据信息
     根据SQL Server数据库来验证凭据信息。
     2． 从数据库里获取角色列表
     3． 创建窗体身份验证票证
     在票证中保存所获取的角色信息。示例代码如下：
private void btnLogin_Click(object sender, System.EventArgs e)
{
//根据SQL Server数据库进行验证（具体实现略）。
bool isAuthenticated = IsAuthenticated( txtUserName.Text, txtPassword.Text );
if (isAuthenticated == true )
{
//获取用户的角色
string roles = GetRoles( txtUserName.Text, txtPassword.Text );

// 创建身份验证票证
FormsAuthenticationTicket authTicket = new 
FormsAuthenticationTicket(1, // version
txtUserName.Text, // user name
DateTime.Now, // creation
DateTime.Now.AddMinutes(60),// Expiration
false, // Persistent
roles ); // User data

string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
// 创建Cookie
HttpCookie authCookie = 
new HttpCookie(FormsAuthentication.FormsCookieName,
encryptedTicket);

Response.Cookies.Add(authCookie); 

// 将用户重定向到最初请求页面。
Response.Redirect( FormsAuthentication.GetRedirectUrl(
txtUserName.Text, 
false ));
}
}

    4． 创建IPrincipal对象     可在Application_AuthenticateRequest事件中创建一个IPrincipal对象，一般使用GenericPrincipal类。
     5． 将IPrincipal对象置于当前的HTTP上下文

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
// 提去窗体身份验证cookie
string cookieName = FormsAuthentication.FormsCookieName;
HttpCookie authCookie = Context.Request.Cookies[cookieName];

if(null == authCookie)
{
return;
} 

FormsAuthenticationTicket authTicket = null;
try
{
authTicket = FormsAuthentication.Decrypt(authCookie.Value);
}
catch(Exception ex)
{
return;
}

if (null == authTicket)
{
return; 
} 

//提取角色
string[] roles = authTicket.UserData.Split(new char[]{'|'});

// 创建Identity object
FormsIdentity id = new FormsIdentity( authTicket ); 

GenericPrincipal principal = new GenericPrincipal(id, roles);
Context.User = principal;
}

    具体的代码读者可以自行补充完成。

5. 后记
与授权与安全通讯有关的内容将另外论述。


摘要：本文ASP.NET应用程序授权的概念，介绍了各种授权模式并进行了比较，阐述了选择授权模式的机制。


关键字：授权 authorization ASP.NET WEB应用


1.1. 授权概念
    任何成功的应用程序安全策略的基础都是稳固的身份验证和授权手段，以及提供机密数据的保密性和完整性的安全通讯。
    授权（authorization）过程负责控制通过了身份验证的客户端可以访问哪些资源，以及可以执行哪些操作。可访问的资源既包括文件、数据库等，还包括系统级的资源，如注册表，配置数据等。
    许多WEB程序不是直接授权客户访问底层的资源，而是通过方法（method）来授权客户端所能够执行的操作。这样做的主要原因是考虑到应用系统的可伸缩性和可管理性。     图1列出了各种安全技术以及每种技术所提供的主要授权方式。
 
2. 2. 授权方式
    如图1所示，Windows 2000上的.NET框架上提供了以下几种授权方式：

ASP.NET授权 
Enterprise Services授权 
SQL Server授权 
2.1 ASP.NET授权
2.1.1 URL授权
    这是一种通过计算机的设置和应用程序配置文件来配置的授权机制。URL授权允许限制用户访问位于应用程序URI命名空间中的特定文件和文件夹。

2.1.2 文件授权
    可以使用此方法来限制对某个WEB服务器上指定文件的访问。访问权限由与文件相关的Windows ACL所确定。

2.1.3 主体权限请求
    主体权限请求（Principal Permission Demand）可以通过声明方式或是编程方式作为一种额外的精确的访问控制机制。这种方式允许你根据单个用户的身份标识组成员关系，来限制对类、方法或单独代码的访问。

2.1.4 .NET角色
    .NET角色用于将应用程序中具有相同权限的用户分成一组。这种方式可以和基于票证的身份验证方案（如窗体身份验证）一起使用，可以通过声明方式或是编程方式来配置对资源和操作的访问。

2.2 Enterprise Services授权
    在Enterprise Services的应用程序中，由Enterprise Services 角色的成员关系来控制客户端访问包含于服务器组件的功能。这些角色和.NET角色不同，而且可以包含Windows组帐户或用户帐户。角色成员关系是在COM+目录中定义的，而且通过组件服务（Component Service）工具管理。

2.3 SQL Server授权
    SQL Server支持精确授权，这些权限可以应用于单独的数据库对象。权限既可以基于角色成员关系，也可以授予单独的Windows用户帐户或组帐户。

3. 选择授权策略
    ASP.NET应用程序有两种基本的权限策略：基于角色的授权和基于资源的授权。 
3.1 基于角色的授权
    对操作的访问通过调用者的角色成员关系，提供安全保护。角色可以将应用程序的用户群划分为具有相同安全权限的用户组。用户被映射到角色，而且如果某个用户被授权执行所请求的操作，则应用程序可以用固定的标识来访问资源。这些标识被各自的资源管理器（如数据库和文件系统）所信任。

3.23.2 基于资源
    单独的资源使用Windows ACL来提供安全保护。应用程序在访问资源之前模拟（impersonate）调用者，这样可以使操作系统执行标准的访问检查。所有对资源的访问都是使用原始调用者的安全上下文。这种模拟方式在应用程序的中间层连接池不能被有效使用，因而影响了应用程序的可伸缩性。

4. 角色的授权的模式
    在大多数可伸缩性至关重要的.NET WEB应用程序，使用基于角色的授权方式是最佳选择。常用的模式如下：

在前端Web应用程序中对用户进行验证 
将用户映射到角色 
根据角色成员关系来授权对操作（不是直接对资源）的访问 
使用固定的服务标识来访问必要的后端资源。 
    一个典型的具体实现步骤如下：： 
获取凭据信息 
验证凭据信息 
将用户添加到角色中 
创建一个IPrincipal对象 
将IPrincipal对象放置到当前的HTTP上下文中 
根据用户标识/角色成员关系进行授权 

摘要：本文ASP.NET应用程序安全的概念，介绍了各种安全通讯技术并进行了比较。


关键字：安全通讯 SSL IPSec RPC ASP.NET WEB应用


1. 前言
    任何成功的应用程序安全策略的基础都是稳固的身份验证和授权手段，以及提供机密数据的保密性和完整性的安全通讯。
    许多应用程序在应用程序的各层之间传输机密数据：从数据库到浏览器，或者相反。机密数据的例子包括银行账户的详细资料、信用卡号码和薪金数据等。另外，当登录凭据在网络上传输时，应用程序必须保证凭据信息的安全。

2. 安全通信的特性
2.1 .保密性（privacy）
    保密性用于确保数据的机密性，不能被那些可能安装有网络监视软件的窃听者看到。通常通过加密来提供保密性。

2.2 完整性（integrity）
    安全通信信道必须确保数据在传输过程中不会有意或无意被修改。通常通过消息验证码（MAC，Message Authentication Code）来提供完整性。

3. 安全通讯技术
3.1 安全套接层
    安全套接层（Secure Sockets Layer）技术最常用于保护浏览器和Web服务器之间的信道。不过也可以用于保护往返于运行了SQL Server 2000 的数据库服务器和WEB服务消息和通信。
    当应用SSL时，客户端使用HTTP协议并指定一个https://URL，而服务器在TCP端口443上侦听。

    使用SSL后，由于SSL使用复杂的加密功能来对数据进行加密和解密，因此对应用程序的性能会产生影响，所以应改优化使用SSL的页面。
     在使用基本身份验证和窗体身份验证时，因为是以明文的形式传递用户名和密码，因此应该使用SSL。一般说来，不但要在登录页面使用，在后续的页面上也应该使用SSL。

3.2 Internet 协议安全性
    Internet 协议安全性（IPSec， Internet Protocol Security）提供了一种传输层安全通讯解决方案，可以保护两个计算机之间-例如，一个应用程序服务器和一个数据库服务器之间-来回传递数据。
    IPSec 可以用于：

通过对两台计算机之间来回发送的所有数据进行加密来提供消息的保密性。 
在两台计算机之间提供消息完整性（不对数据进行加密）。 
在两台计算机之间（不是用户之间）提供相互的身份验证。 
限制哪些计算机可以相互进行通信。也可以将通信限制为使用特定的IP协议和TCP/UDP端口。 
3.3 远程过程调用加密
    远程过程调用（RPC，Remote Procedure Call）加密，由分布式COM（DCOM）使用的RPC协议提供的一种身份验证级别，这种级别将使得在客户端和服务器之间传送的每个数据包都被加密。

4. 角色的授权的模式