在客户端进程内承载的,因此,它们采用客户端的标识。服务器应用程序在单独的服务器进程内运行,它们有自己的标识。有关标识的详细信息,请参阅本章内下文中的“标识和主体”一节。
传入的对服务组件的调用可以在以下级别进行身份验证:
•
默认:使用安全包的默认身份验证级别。
•
无:不执行身份验证。
•
连接:仅在连接时进行身份验证。
•
调用:每次开始远程过程调用时进行身份验证。
•
数据包:鉴定并验证是否已收到所有调用数据。
•
数据包完整性:验证数据在传输过程中是否被修改过。
•
数据包保密性:验证并加密数据包,包括数据和发送者的标识及签名。
更多信息
有关 Enterprise Services 身份验证的详细信息,请参阅“企业服务安全性”。
SQL Server 身份验证
SQL Server 既可以使用 Windows 身份验证(NTLM 或 Kerberos)对用户进行身份验证,也可以使用其内置的身份验证方案(称为 SQL 身份验证)对用户进行身份验证。共有以下两个可用选项:
•
SQL Server 和 Windows.客户端可以使用 SQL Server 身份验证或 Windows 身份验证连接到 Microsoft SQL Server 的实例。有时,这也称为混合模式的身份验证。
•
仅使用 Windows。用户必须使用 Windows 身份验证连接到 Microsoft SQL Server 的实例。
更多信息
关于每种方法的优点,请参阅“数据访问安全性”。
授权
Windows 2000上 的 .NET Framework 提供了下列授权选项:
•
ASP.NET 授权选项
•
Enterprise Services 授权
•
SQL Server 授权
ASP.NET 授权选项
ASP.NET授权选项可供 ASP.NET Web 应用程序、Web服务和远程组件使用。 ASP.NET 提供下面的授权选项:
•
URL 授权.这是通过计算机配置文件和应用程序配置文件中的设置来配置的授权机制。 URL 授权使您可以限制对应用程序的“统一资源标识符”(URI) 名称空间中的特定文件和文件夹的访问。例如,您可以选择拒绝或允许指定的用户对特定文件或文件夹(通过 URL 寻址)的访问。您还可以根据用户的角色成员身份和用于发出请求(GET、POST 等等)的 HTTP 谓词类型来限制访问。
URL 授权需要经过身份验证的标识。它可以通过 Windows 或基于身份验证票的身份验证方案来获得。
•
文件授权.只有在使用 IIS 提供的一种 Windows 身份验证机制对调用方进行身份验证并且ASP.NET已配置为使用 Windows 身份验证时,文件授权才适用。
您可以使用它限制对 Web 服务器上的指定文件的访问。访问权限由与文件相关的 Windows ACL 确定。
•
主体权限需求.主体权限需求可以作为一种(以声明方式或编程方式)更加细化的访问控制机制来使用。这种权限需求使您可以根据单个用户的标识和组成员身份控制对类、方法或单个代码块的访问。
•
.NET 角色..NET角色用于将应用程序内具有相同权限的用户集合在一起。它们在概念上与以前基于角色的实现手段(例如,Windows 组和 COM+ 角色)类似。不过,与这些方法不同,.NET 角色不需要经过身份验证的 Windows 标识,可在基于身份验证票的身份验证方案(如窗体身份验证)中使用。
.NET 角色可用于控制对资源和操作的访问,并且,这类角色既可以用声明方式配置,也可以用编程方式配置。
更多信息
有关ASP.NET授权的详细信息,请参阅“ASP.NET 安全性”。
Enterprise Services 授权
对企业服务应用程序内服务组件中所含功能的访问受企业服务角色成员身份制约。与.NET角色不同,它们可以包含 Windows 组或用户帐户。角色成员身份在 COM+ 目录内定义并通过使用“组件服务”工具管理。
更多信息
有关 Enterprise Services 授权的详细信息,请参阅“企业服务安全性”。
SQL Server 授权
SQL Server 允许设置细化的权限,这些权限可应用于单个数据库对象。可以让权限基于角色成员身份(SQL Server 提供固定的数据库角色、用户定义的角色和应用程序角色),也可以将权限授予单个的 Windows 用户或组帐户。
更多信息
有关 SQL Server 授权的详细信息,请参阅“数据访问安全性”。
网关守卫和关口
在本文档的其余部分,术语网关守卫 用来指负责关口 的技术。关口表示应用程序内的访问控制点(保护资源)。例如,资源可以是某个操作(由对象的方法表示)或数据库或文件系统资源。
前面所列的每种核心技术都为访问授权提供了网关守卫。请求必须先通过一系列的关口,然后才被允许访问所请求的资源或操作。下面说明请求必须通过的各个关口:
•
IIS 在您对用户进行身份验证(即您禁用匿名身份验证)时提供关口。 IIS Web 权限可用作访问控制机制,该机制限制 Web 用户对特定文件和文件夹的访问能力。与 NTFS 文件权限不同,Web 权限应用于所有 Web 用户,而不是单个的用户或组。 NTFS 文件权限对 Web 资源(如 Web 页、图像文件,等等)提供进一步的限制。这些限制适用于单个的用户或组。
IIS 检查 Web 权限,接着检查 NTFS 文件权限。用户必须获得两种机制的授权后才能访问文件或文件夹。如果 Web 权限检查失败,IIS 将返回HTTP 403 — 访问拒绝响应,如果 NTFS 权限检查失败,IIS 将返回HTTP 401 — 拒绝访问。
•
ASP.NET 提供了各种可配置的编程关口。其中包括 URL 授权、文件授权、主体权限需求和 .NET 角色。
•
Enterprise Services 网关守卫使用 Enterprise Services 角色来授予对业务功能的访问权限。
•
SQL Server 2000 包括一系列关口,包括服务器登录、数据库登录和数据库对象权限。
•
Windows 2000 使用与安全资源相关的 ACL 提供关口。
底线是:网关守卫根据调用到关口并尝试访问特定资源的用户或服务的标识来授权。多个关口的好处是通过多条防御线提供纵深防御安全机制。表 2.2 摘要说明各种网关守卫及其负责的关口。
表 2. 网关守卫的责任及其提供的关口
网关守卫
关口
Windows 操作系统
登录权限(肯定和否定,例如“拒绝本地登录”)
其他权限(例如“充当操作系统的一部分”)
对保护的资源(如注册表和文件系统)进行访问检查。访问检查使用与安全资源相关的ACL,这些ACL指定允许谁访问资源和不允许谁访问资源,并指定允许执行的操作类型。
TCP/IP 筛选
IP安全性
IIS
身份验证(匿名、基本、摘要式、集成、证书)
IP 地址和域名限制(它们可用来加强安全防御,但不应依靠它们,因为使用欺骗性的 IP 地址是比较容易的事情)。
Web 权限
NTFS 权限
ASP.NET
URL授权
文件授权
主体权限需求
.NET角色
企业服务
Windows (NTLM / Kerberos) 身份验证
Enterprise Services (COM+)角色
模拟级别
Web 服务
使用 IIS 和ASP.NET提供的关口
远程处理
使用主机提供的关口。如果是在 ASP.NET中承载的,它使用 IIS 和 ASP.NET 提供的关口。如果是在 Windows 服务中承载的,则必须开发自定义的解决方案 。
ADO.NET
连接字符串可以使用显式证书,也可以使用 Windows 身份验证(例如,连接到 SQL Server 时)
SQL Server
服务器登录
数据库登录
数据库对象权限
通过在应用程序各层上使用各种关口,您可以筛选出应允许哪些用户访问您的后端资源。请求在通过应用程序到达后端资源的过程中,一系列相连的关口的控制越来越细化,使得访问范围逐步缩小。
请考虑使用 IIS 的基于 Internet 的应用程序示例,如图 4 所示。
图 4 用网关守卫筛选用户
图 4 说明以下几点:
•
您可以在 IIS 中禁用匿名身份验证。这样,将只允许经过 IIS 身份验证的帐户进行访问。这可将潜在用户数减到 10,000。
•
接着,您可以在 ASP.NET中使用 URL 授权,这可将用户数减到 1,000。
•
文件授权可能会将访问范围进一步缩小,将用户数减少到 100。
•
最后,根据特定的角色成员身份,Web 应用程序代码可能只允许 10 个用户访问受限制的资源。
介绍 .NET Framework 安全性
.NET Framework 安全性在 Windows 安全性之上;它没有取代Windows安全性,而是提供附加的安全特性。.NET 应用程序对所有资源访问的成功或者失败最终由操作系统的安全性决定。
例如,如果一个 ASP.NET Web 应用程序要打开一个文件,能否打开文件取决于和此文件相关的Windows ACL。用于资源访问的标识要么是 ASP.NET 应用程序进程标识,要么是使用个性化处理的应用程序的个性化标识。
代码访问安全性
.NET Framework提供一个被称为代码访问安全性 (CAS) 的附加的安全性机制。传统的安全性(例如 Windows 提供的安全性)是以主体为中心的,并且授权基于一个验证的主体,例如用户运行代码,或者用户登录一个 Web 应用程序。
CAS 通过支持基于代码标识(而不是运行代码的用户)的授权为安全性添加了一项内容。这对于使用 Internet Explorer 从 Internet 上下载的移动代码(例如控件和应用程序)尤为重要。这是因为您可能以管理员的身份登录您的计算机,但是您真的想让这种代码具有管理员权限吗?如果您考虑到计算机的安全性,您可能不会允许的。
证据和安全策略
代码被验证并且其标识使用代码的属性来决定,这种代码被称作为证据。证据可以包含一个汇编的公共钥匙(是其强名称的一部分)、下载 URL、安装应用程序目录和其它内容。一旦建立了代码标志,收集的证据通过安全性策略传递,安全性策略最终管理代码的功能以及给予何种许可访问安全资源。
缺省策略确保安装到本地机器上的所有代码都是完全可信的,并且可以不受限制地访问安全资源。因此所有资源访问只受操作系统安全性管理。由于在安装软件时首先要求管理员作出谨慎的决定,所以安装到本地机器上的代码是完全可信的。
CAS 和 ASP.NET Web 应用程序
ASP.NET应用程序安装到本地 Web 服务器上,因此在服务器上缺省策略给予 Web 应用程序完全的信任。这意味着 CAS 对服务器端 Web 应用程序开发人员来说使用范围有限。实际上,建立于 .NET Framework 版本 1之上的 ASP.NET Web 应用程序必须作为完全信任的应用程序运行。
注.NET Framework 的 1.1 版本添加了对部分信任 Web 应用程序的支持,这样就可以使 CAS 有效的使用于服务器端 Web 应用程序。引入 CAS 主要的好处是易于将应用程序之间分离开,以及将应用程序和关键的系统资源分离开;这对于由不同公司开发的可以承载多个 Web 应用程序的 Internet Service Providers (ISPs) 和 Application Service Provides (ASPs) 是一个重要的考虑因素。
主体和标识
尽管 CAS 以代码为中心,但是 .NET Framework 安全性的其它方面以主体为中心。 .NET Framework 安全性以主体为中心对 ASP.NET 应用程序安全性起着支配作用。
Windows 安全性的用户中心概念基于登录会话提供的安全上下文,而 .NET 安全性基于 IPrincipal 和 IIdentity 对象。
在 Windows 编程中,如果要了解运行的代码所依赖的安全上下文,应查询进程所有者的标识或当前所执行线程的标识。在 .NET 编程中,如果要查询当前用户的安全上下文,应从 Thread.CurrentPrincipal 检索当前的 IPrincipal 对象。
运行 .NET 代码时。NET Framework 使用标识对象和主体对象来表示用户,这两个对象共同构成基于 .NET 角色的授权的主干部分。对 ASP.NET Web 应用程序来讲,通过附加到当前线程和 Web 请求的主体和标志对象来表征验证的用户。
IPrincipal 和 IIdentity 接口
标识和主体对象必须分别实现IIdentity 和 IPrincipal 接口。这些接口在 System.Security.Principal 名称空间内定义。公共接口使 .NET Framework 能以多态方式处理标识和主体对象,而不管基础实现的详细情况如何。
IPrincipal 接口使您可以通过 IsInRole 方法测试角色的成员身份,同时也提供了对关联的 IIdentity 对象的访问。 public interface IPrincipal
{
bool IsInRole( string role );
IIdentity Identity {get;}
}
IIdentity 接口提供有关身份验证的更多详细信息,如名称和验证类型。 public interface IIdentity
{
string authenticationType {get;}
bool IsAuthenticated {get;}
string Name {get;}
}
.NET Framework 提供了 IPrincipal 和IIdentity 的多个具体实现,如图 5 所示,后面几节对这些实现分别进行详细说明。
图 5. IPrincipal 和 IIdentity 实现类
WindowsPrincipal 和 WindowsIdentity
Windows 安全上下文的 .NET 版本分为两个类:
•
WindowsPrincipal.该类存储与当前的 Windows 用户相关的角色。WindowsPrincipal实现将 Windows 组视为角色。IPrncipal.IsInRole方法根据用户的 Windows 组成员身份返回 true 或 false。
•
WindowsIdentity该类存储当前用户安全上下文的标识部分,它可以从静态的 WindowsIdentity.GetCurrent() 方法获得。它返回具有 Token 属性的 WindowsIdentity 对象,该属性将一个表示 Windows 句柄的 IntPtr 返回给与当前执行线程关联的访问令牌。该令牌接着可被传递到本机 Win32® 应用程序编程接口 (API) 函数,如 GetTokenInformation、SetTokenInformation 和 CheckTokenMembership 等等,用于检索与令牌有关的安全信息。
注:静态 WindowsIdentity.GetCurrent() 方法返回当前所执行线程的标识,它可能是(也可能不是)模拟的。这与 Win32 GetUserName API类似。
GenericPrincipal 和 Associated Identity 对象
这些实现非常简单,供不使用 Windows 身份验证的应用程序在应用程序不需要主体的复杂表示时使用。您可以在代码中非常容易地创建这些实现,因此,在应用程序处理 GenericPrincipal 时,必须存在某种程度的信任。
如果依靠GenericPrincipal 上的 IsInRole 方法作出授权决定,必须信任向您发送GenericPrincipal的应用程序。这与使用 WindowsPrincipal 对象形成对比:使用 WindowsPrincipal 对象时,必须委托操作系统提供有效的 WindowsPrincipal 对象,和一个授权表示符以及有效的组/角色名。
以下类型的标识对象可以与 GenericPrincipal 类相关联:
•
FormsIdentity该类表示已经过窗体身份验证的标识。它包含的 FormsAuthenticationTicket 中存储了与用户的身份验证会话有关的信息。
•
PassportIdentity该类表示已经过 Passport 身份验证的标识,它包含 Passport 配置文件信息。
•
GenericIdentity该类表示一个不与任何特定操作系统技术相关的逻辑用户,通常用在自定义的身份验证和授权机制中。
ASP.NET 和HttpContext.User
通常,作出任何授权决定之前,先要在 .NET 代码中检查 Thread.CurrentPrincipal。不过,ASP.NET 使用HttpContext.User提供经过身份验证的用户的安全上下文。
该属性接受并返回 IPrincipal 接口。,该属性包含一个与当前的请求相关的经过身份验证的用户。ASP.NET 在作出授权决定时将检索 HttpContext.User 。
使用 Windows 身份验证时,Windows 身份验证模块自动构造 WindowsPrincipal 对象并将它存储在 HttpContext.User。如果 上一页 [1] [2] [3] 下一页 [C语言系列]NET 中C#的switch语句的语法 [系统软件]托拽Explore中的文件到VB.net的窗口 [系统软件]Boost库在XP+Visual C++.net中的安装 [常用软件]新配色面板:Paint.Net3.0RC1官方下载 [常用软件]用内建的“Net Meeting”聊天 [VB.NET程序]Henry的VB.NET之旅(三)—共享成员 [VB.NET程序]Henry的VB.NET之旅(二)—构造与析构 [VB.NET程序]Henry的VB.NET之旅(一)—失踪的窗体 [VB.NET程序]在托盘上显示Balloon Tooltip(VB.NET) [VB.NET程序]Henry手记-VB.NET中动态加载Treeview节点(二)
|