8226; 您可以在 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该类存储当前用户安全上下文的标识部
• 接着，您可以在 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该类存储当前用户安全上下文的标识部
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
