权限往往可以限制我们的一些操作，在一个应用程序中你可能只有可读的权限，这里我们就ADO.NET访问权限来谈谈。.NET Framework 提供基于角色的安全性和代码访问安全性 (CAS)，这两种安全性都可以通过公共语言运行库 (CLR) 提供的公共基础结构实现。 对于非托管代码，大多数应用程序都可以使用用户或主体权限执行。因此，当拥有提升权限的用户运行恶意软件或包含错误的软件时，计算机系统可能会受到损坏并危及私有数据。
相对而言，.NET Framework 中执行的托管代码包括单独应用于代码的代码访问安全性。 是否允许运行代码取决于代码的来源或代码标识的其他方面，而不仅仅是主体标识。 这样可以减小滥用托管代码的可能性。
代码ADO.NET访问权限
在执行代码时，代码会提供通过 CLR 安全系统计算的证据。 通常，此证据由代码的来源（包括 URL、站点和区域）以及确保程序集标识的数字签名组成。CLR 仅允许代码执行代码具有执行权限的那些操作。 代码可以请求权限，而这些请求需要基于管理员设置的安全策略。
#T#在 CLR 中指定的代码不能为自身授予权限。 例如，代码可以请求并获得比安全策略允许的权限少的权限，但决不会获得比安全策略允许的权限多的权限。在授予权限时，应该从无权限开始，然后为要执行的特定任务添加最少的权限。一开始就使用所有权限，然后拒绝各个权限会导致应用程序不安全，应用程序可能会授予不必要的权限，从而使应用程序无意中包含安全漏洞。有关更多信息，请参见配置安全策略和安全策略管理。
代码ADO.NET访问权限有三种类型：
◆Code access permissions从 CodeAccessPermission 类派生。 需要具有权限才能访问受保护的资源（如文件和环境变量）和执行受保护的操作（如访问托管代码）。
◆Identity permissions表示标识程序集的特征。 对程序集授予权限需要基于证据，而证据可以包括如数字签名或代码来源等项。 标识权限也从 CodeAccessPermission 基类派生。
◆Role-based security permissions基于主体是否具有指定标识或是否是指定角色的成员。 PrincipalPermission 类允许对活动主体进行声明性和强制性权限检查。
为了确定代码是否获得了访问某一资源或执行某一操作的授权，运行库的安全系统将遍历调用堆栈，将每个调用方已获得的权限与要求的权限进行比较。 如果调用堆栈中的任何调用方没有要求的权限，则会引发 SecurityException 并拒绝访问。
ADO.NET访问权限之请求权限
请求权限的目的是通知运行库您的应用程序要求哪些权限才能运行，并确保应用程序只接收到实际需要的权限。 例如，如果您的应用程序需要将数据写入本地磁盘，则需要 FileIOPermission。 如果尚未授予该权限，则在应用程序尝试写入磁盘时将失败。 不过，如果应用程序请求 FileIOPermission 并且尚未授予该权限，则应用程序一开始即会生成异常，因此将不会加载。
在应用程序只需从磁盘读取数据的情况下，您可以请求永远不为应用程序授予任何写入权限。 在出现 Bug 或受到恶意攻击时，您的代码将不会损坏它所操作的数据。
基于角色的安全性和 CAS
同时实现基于角色的安全性和代码访问安全性 (CAS) 可增强应用程序的整体安全性。 基于角色的安全性可以基于 Windows 帐户或自定义标识，使有关安全主体的信息可用于当前线程。此外，通常还要求应用程序基于用户提供的凭据提供对数据或资源的访问。 通常情况下，这种应用程序会检查用户的角色，并根据这些角色提供对资源的访问。基于角色的安全性使组件能够在运行时标识当前用户及其关联的角色。 然后使用 CAS 策略映射此信息以确定运行时授予的一组权限。 对于指定的应用程序域，主机可以更改基于角色的默认安全策略并设置表示用户的默认安全主体和与该用户关联的角色。
CLR 使用权限来实现其用于对托管代码实施限制的机制。 基于角色的安全权限提供一种机制，用于发现用户（或代表该用户的代理）是否具有特定标识或者是否是指定角色的成员。根据要生成的应用程序类型，还应考虑在数据库中实现基于角色的权限。 有关 SQL Server 中基于角色的安全性的更多信息，请参见 SQL Server 安全性 (ADO.NET)。
