打印本文 打印本文 关闭窗口 关闭窗口
ASP.NET应用程序的安全模型
作者:武汉SEO闵涛  文章来源:敏韬网  点击数2713  更新时间:2009/4/23 10:45:22  文章录入:mintao  责任编辑:mintao
使用其他身份验证机制(如窗体或 Passport),必须构造 GenericPrincipal 对象并将它存储在 HttpContext.User 中。

ASP.NET 标识

在 ASP.NET 应用程序执行过程中的任何给定时间内,单个请求中可能存在多个标识。它们包括:

HttpContext.User返回IPrincipal对象,该对象包含当前 Web 请求的安全信息。这是经过身份验证的 Web 客户端。

WindowsIdentity.GetCurrent()返回当前所执行的 Win32 线程的安全上下文标识。默认情况下,该标识为 ASPNET;这是用于运行 ASP.NET Web 应用程序的默认帐户。.但是,如果已配置 Web 应用程序进行模拟,该标识则表示经过身份验证的用户(如果 IIS 匿名身份验证有效,该标识为 IUSR_MACHINE)。

Thread.CurrentPrincipal返回当前所执行的 .NET 线程(它位于 Win32 线程之上)的主体。

更多信息

有关 Web 应用程序配置组合(包括使用模拟和不使用模拟)的ASP.NET标识的详细分析,请参阅“ASP.NET Identity Matrix”。

有关创建您自己的IPrincipal实现的详细信息,请参阅“ASP.NET 安全性”和“How to implement IPrincipal”。

Remoting 与 Web 服务

在.NET Framework, 的最新版本中,Remoting 与 Web 服务没有自己的安全模型。它们都继承 IIS 和 ASP.NET 的安全功能。

虽然远程处理体系结构中没有内置的安全功能,但在设计时考虑到了安全性。开发人员和/或管理员可以自行决定在远程处理应用程序中集成一定程度的安全性。是否在远程处理边界之间传递主体对象取决于客户端和远程对象的位置,例如:

同一进程内的远程处理。在同一应用程序域或不同的应用程序域内的对象之间使用远程处理时,远程处理基础结构将与调用方上下文相关的 IPrincipal 对象的引用复制到接收方的上下文中。

进程之间的远程处理。在这种情况下,不在进程之间传送 IPrincipal 对象。用于构造原始 IPrincipal 的证书必须传送到远程进程,该进程可能位于另一台计算机上。这就使得远程计算机能够根据提供的证书来构造相应的 IPrincipal 对象。

返回页首

小结

本章介绍了与 .NET 相关的各种技术提供的所有身份验证和授权选项。也介绍了 .NET Framework 安全性,以及主体和标识对象,这些是 ASP.NET 验证的核心内容。.

通过在整个 .NET 应用程序中使用多个网关守卫,您将能够实现纵深防御安全策略。概括起来,有以下几点:

ASP.NET 应用程序可以使用 Windows 和 IIS 提供的现有安全功能。

SSL 和 IPSec 可用来在 .NET 应用程序的各层上(例如,从浏览器到数据库)联合提供安全通信。

使用基本或窗体身份验证时,可使用 SSL 保护通过网络传递的明文证书。

建立在 .NET Framework 版本1之上的 ASP.NET 应用程序必须作为完全可信的应用程序运行,这意味着代码访问安全性对服务器端Web应用程序开发人员来说使用范围有限。.NET Framework 1.1 版本将提供部分信任的 Web 应用程序,在此 CAS 变得更为重要。

.NET 使用WindowsPrincipalWindowsIdentity 类的组合来表示已经过 Windows 身份验证的用户。

GenericPrincipalGenericIdentityFormsIdentity 类用于表示已由非 Windows 身份验证方案(如窗体身份验证)验证过的用户。

您可以通过创建实现 IPrincipalIIdentity 的类来创建自己的主体和标识实现。

在ASP.NET应用程序内,表示经过身份验证的用户的 IPrincipal 对象使用 HttpContext.User 属性与当前的 HTTP Web 请求关联。

关口是应用程序内的访问控制点,获得授权的用户可以通过这些访问控制点访问资源或服务。网关守卫负责控制对关口的访问。

使用多个网关守卫可以提供纵深防御安全策略。

Web 服务和依靠 ASP.NET 及 IIS 提供底层安全性服务的.NET remoting。

上一页  [1] [2] [3] 

打印本文 打印本文 关闭窗口 关闭窗口