asp.net身份验证和授权上篇
Admin | 2007-11-26 21:37:39 | 被阅次数 | 7897
本文ASP.NET应用程序身份验证的概念，介绍了各种身份验证模式并进行了比较，阐述了选择身份验证模式的机制，并给出了一种基于窗体身份验证模式的实现方法。
关键字：身份验证 authentication ASP.NET WEB应用
1.身份验证概念
任何成功的应用程序安全策略的基础都是稳固的身份验证和授权手段，以及提供机密数据的保密性和完整性的安全通讯。
身份验证（authentication）是一个标识应用程序客户端的过程，这里的客户端可能包括终端用户、服务、进程或计算机，通过了身份验证的客户端被称为主体（principal）。身份验证可以跨越应用程序的多个层发生。终端用户起初由Web应用程序进行身份验证，通常根据用户名和密码进行；随后终端用户的请求由中间层应用程序服务器和数据库服务器进行处理，这过程中也将进行身份验证以便验证并处理这些请求。
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系统的选择决策流程
3.4 SQL Server用户验证
对SQL Server的客户端进行验证，一般说来Windows身份验证要比SQL Server身份验证更安全，原因主要有以下几点：
- 前者负责管理用户的凭据信息，而且用户的凭据不会在网络上传输。
- 可以避免在连接字符串中嵌入用户名和密码。
- 可通过密码过期时限、最小密码长度、以及多次无效登录后请求的帐户锁定等措施改进登录安全性。这样可以见少词典攻击的威胁。
但是某些特定的应用程序方案中不允许使用Windows身份验证，例如：
- 数据库客户端和数据库服务器由一个防火墙分隔开，从而导致无法使用Windows身份验证。
- 应用程序需要使用多个标识连接到一个或多个数据库。
- 连接到的数据库不是SQL Server。
- 在ASP.NET中没有一种安全的方式以特定的Windows用户的身份运行代码。
在以上这些方案中，将必须使用SQL身份验证，或是数据库的本机身份验证机制。