身份验证和授权_com+身份验证 启用身份验证

应该在什么情况下执行授权，使用什么机制？

应该使用什么身份验证机制？

应该用 Active Directory 目录服务来进行身份验证，还是应该对照自定义数据存储来验证凭证？

使用异类和同类平台分别意味着什么？在设计上有哪些需要注意的地方？

在应用程序中应该如何表示没有使用 Windows 操作系统的用户？

应该如何在应用程序的各层之间传递用户身份？ 在什么情况下应该使用操作系统级模拟／委派？

首先，任何有意义的授权策略都要求已验证身份的用户。

其次，验证用户身份的方式（具体说，就是如何在应用程序中表示已通过验证的用户身份）将决定您可支配的网关守卫。

某某些网关守卫，（如， ASP.NET 文件授权、Enterprise Services (COM+) 角色和 Windows ACL） 都需要一个通过身份验证的 Windows 身份（以 WindowsIdentity 对象的形式存在，它封装了一个定义调用者安全上下文的 Windows 访问令牌。） 而其他网关守卫，（如 ASP.NET URL 授权和 .NET 角色）则没有这一要求。它们只要求身份通过验证即可，并不需要一定是由 Windows 访问令牌来表示。

标识资源。

选择授权策略。

选择用于资源访问的身份。

考虑身份传递。

选择身份验证方法。

决定如何传递身份。

Web Server 资源，例如 Web 页面、Web 服务、静态资源（HTML 页面和图像）。

数据库资源，例如每用户数据或应用程序范围的数据。

网络资源，例如远程文件系统资源和来自目录存储（如 Active Directory）的数据。

基于角色。对操作（通常是方法）的访问是基于调用者的角色成员保护的。 使用角色将应用程序的用户群分成在应用程序内共享相同安全特权的用户组；例如“高级经理”、“经理”和“职员”。用户被映射到角色，如果用户有权所请求的操作，则应用程序就会使用固定的身份访问资源。这些身份受各自的资源管理器（例如数据库、文件系统等）所信任。

基于资源。使用 Windows ACL 分别保护各个资源。应用程序在调用者访问资源前先对其进行模拟，这样使操作系统可以执行标准的访问检查。所有资源访问都是通过原调用者的安全上下文执行的。 此模拟方法严重影响应用程序的可扩展性，因为这意味着在应用程序的中间层无法有效地使用连接池。

在前端 Web 应用程序中验证用户身份。

将用户映射到角色。

基于角色成员授权对操作（而不是直接对资源）进行访问。

使用固定的服务身份访问必要的后端资源（用来支持所请求的和授权的操作）。后端资源管理器（例如，数据库） 信任 应用程序可以授权调用者，并且愿意授予权限给受信任的服务身份。

例如，数据库管理员可能只授予访问特定人力资源应用程序（而不是个别用户）的访问权限。

注 应用程序级别的基于角色授权方式仍然需要使用基于资源的授权来保护系统级资源，例如配置文件、注册表项等。

有关这两种截然不同的授权方式的更多信息，请参考本章后面的“授权方式”。

有关基于角色授权和各种可以使用的角色类型的更多信息，请参考本章后面的“基于角色授权”。

原调用者的身份。它采用一种模拟／委派模式，即可以获得原调用方身份，然后将此身份在系统的每一层之间传递。委派因素是用于确定身份验证机制的重要标准。

进程身份。这是默认情况（没有具体的模拟）。使用当前进程身份可以访问本地资源并进行下游调用。这一方法是否可靠取决于所跨越的界限，因为进程身份必须被目标系统识别。

这意味着要用以下方式之一进行调用：

服务帐户。本方法使用一个（固定的）服务帐户。例如：

自定义身份。当没有可用的 Windows 帐户时，您可以构造自己的身份（使用 IPrincipal 和 IIdentity 模拟），它将包含您指定的安全上下文的具体内容。例如，它可以包含角色列表、惟一标识符或任何其他类型的自定义信息。

通过用 IPrincipal 和 IIdentity 类型实现自定义身份并将它们放置在当前 Web 上下文（使用 HttpContext.User），您可以直接从内置的网关守卫（如 .NET 角色和 PrincipalPermission 命令）中获益。

使用受信任的查询参数检索每用户数据

    SELECT x,y FROM SomeTable WHERE username="bob" 

在任何应用程序层中自定义审核

平台级审核（例如，Windows 审核和 SQL Server 审核）

基于 Windows 身份的每用户授权

基于角色。用户被划分为由应用程序定义的逻辑角色。在应用程序中，某一特定角色的成员将共享相同的特权。对操作的访问（通常由方法调用表示）是根据调用者的角色成员授权的。

可以用固定身份（例如 Web 应用程序身份或 Web 服务进程身份）访问资源。资源管理器信任应用程序可以正确授权用户，并且它们将权限授予 受信任 的身份。

基于资源。各个资源是通过 Windows ACL 保护的。ACL 将决定哪些用户允许访问资源，还决定允许每个用户执行哪类操作（读、写、删除等）。

可以使用原调用者的身份（使用模拟）访问资源。

在一种极端情况下，可以在后端资源管理器（例如数据库）中映射角色。它要求原调用者的安全上下文通过应用程序的各层传递到后端数据库。

另一种极端情况是在前端 Web 应用程序中映射角色。在这种方法中，下游资源管理器是通过由每个资源管理器授权并受其信任的固定身份访问的。

第三种情况是在前端和后端层之间的某个位置进行角色映射；例如，在中间层 Enterprise Services 应用程序中。

受信任的子系统模式

模拟／委派模式

验证用户身份

将用户映射到角色

基于角色成员授权

使用固定的受信任身份访问下游资源管理器

创建两个 Windows 帐户，一个用于读操作，另一个用于读／写操作。

更通常的情况是，用不同的帐户映射应用程序特定的角色。例如，您可能要让 Internet 用户使用一个帐户，让内部操作员和／或管理员使用另一个帐户。

将每个帐户映射为由 SQL Server 用户定义的数据库角色，并为每个角色建立必要的数据库权限。

将用户映射到应用程序中的角色，并使用角色成员身份确定连接到数据库之前模拟的帐户。

它允许下游服务通过原调用者的身份执行每调用者授权。

它允许下游服务使用操作系统级审核功能。

技术挑战。大多数安全服务提供商不支持委派，Kerberos 是有名的例外。

执行模拟的进程要求有更高的特权（具体来说就是 作为操作系统的一部分 的执行特权）。（这限制适用于 Windows 2000，而不适用于 Windows .NET Server）。

可扩展性。模拟／委派模式意味着您不能有效地使用数据库连接池，因为执行数据库访问的连接依赖于原调用者的不同安全上下文。这严重限制了应用程序扩展至大量用户的能力。

更多的管理工作。在后端资源中维护 ACL 需要授予每个用户恰当的访问级别。当后端资源的数量增加（且用户数增加）时，就需要在管理 ACL 上投入大量的管理精力。

可扩展性。受信任的子系统模式支持连接池，这是应用程序可扩展性的基本要求。连接池允许多个客户端重复使用可用的池连接。它非常适用此模式，因为无论调用者的身份是什么，所有后端资源访问都使用服务帐户的安全上下文。

后端 ACL 管理工作减到最少。只有服务帐户访问后端资源（例如，数据库）。ACL 只针对这个身份进行配置。

用户无法直接访问数据。在受信任的子系统模式中，只有中间层服务帐户被授权访问后端资源。因此，如果不通过应用程序（并且以应用程序授权为准），用户无法直接访问后端数据。

审核。为了在后端执行审核，可以显式地（在应用程序级别）将原调用者的身份传递到后端，并在那执行审核。必须信任中间层，而且确实有潜在的拒绝风险。另一种选择是，在中间层生成审核纪录，然后将它与后端审核纪录相关联（为此，必须确保服务器时钟是同步的）。

增加服务器攻击危险。在受信任的子系统模式中，中间层服务被授权对后端资源的广泛访问。因此，安全受威胁的中间层服务就可能使攻击者更加容易地获得对后端资源的广泛访问权。

为了在应用程序级传递身份，一般使用方法参数或存储过程参数传递凭证（或票证）。

注：携带经过身份验证的调用者身份的GenericPrincipal 对象并不会在进程间自动传递。这需要自定义代码。

可以向存储过程传递允许您检索和处理用户特定数据的参数。例如：

SELECT CreditLimit From Table Where UserName="Bob" 

这种方法有时也称为 受信任的查询参数 方法。

操作系统身份传递需要一种扩展形式的模拟（称为委派）。

.NET 角色

Enterprise Services (COM+) 角色

SQL Server 用户定义的数据库角色

SQL Server 应用程序角色

有关基于 .NET 角色的授权的更多信息，请参考“ASP.NET 安全性”一章。

有关创建 GenericPrincipal 对象的更多信息，请参考“How To Create GenericPrincipal Objects with 表单 Authentication”一章。

文件

文件夹

Web 页面（.aspx 文件）

Web 服务（.asmx 文件）

对象

方法和属性

方法中的代码块

捕获用户凭证。

检验用户访问自定义数据存储（比如 SQL Server 数据库）的凭证。

检索角色列表，构建 GenericPrincipal 对象并将它与当前 Web 请求相关联。

GenericPrincipal 对象代表通过身份验证的用户，并用于后续的 .NET 角色检查，例如声明性的PrincipalPermission 命令和编程方式的IPrincipal.IsInRole 检查。

手动角色检查。对于细分授权，您可以调用 IPrincipal.IsInRole 方法，根据调用者的角色成员授权对特定代码块的访问。在检查角色成员时，AND 和 OR 逻辑均可使用。

声明性角色检查（方法入口）。您可以使用 PrincipalPermissionAttribute 类（可以简写为 PrincipalPermission）对方法进行注释，以声明方式请求角色成员。这些检查只支持 OR 逻辑。例如，您可以要求调用者至少属于一个特定的角色（例如，调用者必须是出纳员或一个经理）。不能用声明性检查指定调用者必须既是经理，又是出纳员。

命令性角色检查（在方法中检查）。可以在代码中调用 PrincipalPermission.Demand 执行细分授权逻辑。支持逻辑 AND 和 OR 操作。

直接用户名检查

    GenericIdentity userIdentity = new GenericIdentity("Bob"); 
    if (userIdentity.Name=="Bob") 
    { 
    } 

声明性检查

    [PrincipalPermissionAttribute(SecurityAction.Demand, User="Bob")] 
    public void DoPrivilegedMethod() 
    { 
    } 

命令性检查

    PrincipalPermission permCheckUser = new PrincipalPermission( 
                                                   "Bob", null); 
    permCheckUser.Demand(); 

直接角色名检查

    GenericIdentity userIdentity = new GenericIdentity("Bob"); 
    // Role names would be retrieved from a custom data store 
    string[] roles = new String[]{"Manager", "Teller"}; 
    GenericPrincipal userPrincipal = new GenericPrincipal(userIdentity,  
                                                          roles); 
    if (userPrincipal.IsInRole("Teller")) 
    { 
    } 

声明性检查

    [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller")] 
    void SomeTellerOnlyMethod() 
    { 
    } 

命令性检查

    public SomeMethod() 
    { 
      PrincipalPermission permCheck = new PrincipalPermission( 
                                                   null,"Teller"); 
      permCheck.Demand(); 
      // Only Tellers can execute the following code 
      // •ñn members of the Teller role result in a security exception 
      . . . 
    } 

直接角色名检查

    if (Thread.CurrentPrincipal.IsInRole("Teller") || 
        Thread.CurrentPrincipal.IsInRole("Manager")) 
    { 
      // Perform privileged operations 
    } 

声明性检查

    [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Teller"), 
     PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")] 
    public void DoPrivilegedMethod() 
    { 
    } 

命令性检查

    PrincipalPermission permCheckTellers = new PrincipalPermission(  
                                                       null,"Teller"); 
    PrincipalPermission permCheckManagers = new PrincipalPermission( 
                                                       null,"Manager"); 
   (permCheckTellers.Union(permCheckManagers)).Demand(); 

直接角色名检查

    if (Thread.CurrentPrincipal.IsInRole("Teller") && 
        Thread.CurrentPrincipal.IsInRole("Manager")) 
    { 
      // Perform privileged operation 
    } 

声明性检查

不可以利用 .NET 角色以声明方式执行 AND 检查。将 PrincipalPermission 命令叠加在一起使用会产生逻辑 OR。

命令性检查

    PrincipalPermission permCheckTellers = new PrincipalPermission( 
                                                     null,"Teller"); 
    permCheckTellers.Demand();   
    PrincipalPermission permCheckManagers = new PrincipalPermission( 
                                                     null, "Manager"); 
    permCheckManagers.Demand(); 

身份。仅当应用程序用户的 Windows 帐户可由受信任的机构进行身份验证，并且应用程序的 Web 服务器可以访问该机构时，才适合使用 Windows 身份验证机制。

凭证管理。Windows 身份验证的一个主要优点是它使您可以将凭证管理交给操作系统去做。采用非 Windows 方法（如表单身份验证），您就必须仔细考虑用户凭证的存储位置和方式。两种最常见的方法是使用：

有关将 SQL Server 用作凭证存储的安全考虑事项的更多信息，请参考“数据访问安全性”一章。

有关在自定义数据存储（包括 Active Directory）中使用表单身份验证的更多信息，请参考“ASP.NET 安全性”一章。

身份传递。您需要实现模拟／委派模式，并在操作系统级的各层间传递原调用者的安全上下文吗？例如，为了支持审核或每用户（粒度）授权。如果需要，您就需要能够模拟调用者，并将它们的安全上下文委派到下一个下游子系统，如本章前面的“传递身份”部分中的“委派”主题所描述的。

浏览器类型。您的用户都有 Internet Explorer 吗？或者您需要支持使用混合浏览器类型的用户群？表 3 阐述了哪些身份验证机制需要 Internet Explorer 浏览器，而哪些支持各种常见的浏览器类型。

用户在服务器域或该服务器可达的受信任域中没有 Windows 帐户。

用户没有客户端证书。

支持对照自定义数据存储（通常为 SQL Server 数据库或 Active Directory）的身份验证。

支持基于角色授权（包括从数据存储中查找角色）。

与 Web 用户界面平稳集成。

ASP.NET 提供结构的大部分。与传统 ASP 相比，需要的自定义代码相对较少。

Passport 是一种集中式解决方案。

它不需要应用程序进行凭证管理。

能与基于角色授权方案一起使用。

非常安全，因为它建立在加密技术之上。

有关 Web 服务身份验证方法的更多信息，请参考“Web Services Security”一章。

有关在 SQL Server 中使用表单身份验证的更多信息，请参考“How To Use 表单 Authentication with SQL Server 2000”一章。

使用受信任子系统资源访问模式可获得使用数据库连接池的益处。

如果您的应用程序没有使用 Windows 身份验证，请使用 .NET 角色检查提供授权。对照自定义数据存储检验凭证，检索角色列表并创建 GenericPrincipal 对象。将它与当前 Web 请求 (HttpContext.User) 相关联。

如果您的应用程序使用 Windows 身份验证，但不使用 Enterprise Services，请使用 .NET 角色。请记住，对于 Windows 身份验证，.NET 角色为 Windows 组。

如果您的应用程序使用 Windows 身份验证和 Enterprise Services，请考虑使用 Enterprise Services (COM+) 角色。

对于使用 Enterprise Services (COM+) 角色的有意义的基于角色授权，原调用者的身份必须传递到 Enterprise Services 应用程序。如果从 ASP.NET Web 应用程序中调用 Enterprise Services 应用程序，则意味着 Web 应用程序必须使用 Windows 身份验证，并配置为使用模拟。

以 PrincipalPermission 属性对方法进行注释，以声明方式请求角色成员。如果调用者不在指定的角色中，则不调用该方法，并且产生一个安全异常。

在方法代码中调用 PrincipalPermission.Demand （或使用 IPrincipal.IsInRole）以获得细分授权决策。

考虑实现自定义 IPrincipal 对象以获得其他角色检查语义。