更新：2007 年 11 月
角色管理使您能够通过创建的类别（称为“角色”）管理应用程序的授权。通过将用户分配给角色，可以基于角色控制对 Web 应用程序的不同部分或功能的访问，从而取代基于用户名的控制，或者作为对基于用户名的控制方式的补充。例如，雇员应用程序可能具有诸如“经理”(Managers)、“雇员”(Employees)、“主管”(Directors) 等角色，并为每种角色指定了不同的特权。
用户可以属于多种角色。例如，如果您的站点是个论坛，则有些用户可能同时属于“成员”(Members) 和“版主”(Moderators) 角色。您可能定义了每种角色在站点中拥有不同的特权，同时属于两种角色的用户将同时具有两组特权。
尽管遵循编码和配置最佳实践可以提高应用程序的安全性，还有一点也很重要，那就是使用 Microsoft Windows 和 Internet 信息服务 (IIS) 的最新安全修补程序，以及 Microsoft SQL Server、Active Directory 或其他角色数据源的修补程序，不断保持应用程序服务器为最新。
有关编写安全代码和保护应用程序安全的最佳实践的更多详细信息，请参见由 Michael Howard 和 David LeBlanc 编写的书籍 Writing Secure Code（《编写安全代码》）以及由 Microsoft Patterns and Practices（《Microsoft 模式和实践》）(https://www.microsoft.com/resources/practices/default.mspx) 提供的指导。
保护角色管理器配置
默认情况下，ASP.NET 应用程序是禁用角色管理器功能的，以提高那些不使用角色管理器的应用程序的安全性。如果启用角色管理器功能，则会将默认配置设置设为最安全的值。有关角色管理器配置设置及其默认值的信息，请参见 roleManager 元素（ASP.NET 设置架构）。
保证配置值的安全
当在应用程序的配置文件中存储敏感信息时，应使用受保护配置对敏感值进行加密。特别敏感的信息包括存储在 machineKey 配置元素中的加密密钥，以及存储在 connectionStrings 配置元素中的用来连接数据源的连接字符串。有关更多信息，请参见使用受保护的配置加密配置信息。
保证加密密钥和哈希算法的安全
强烈建议您将 roleManager 元素的 cookieProtection 属性设置为 All，以此来保护在 Cookie 中缓存的角色名称。指定加密算法的加密密钥值存储在 machineKey 配置元素中。对于强加密，应为选定的加密算法指定一个加密密钥，该密钥是一个随机生成的、具有适当长度的值。
在承载多个应用程序的服务器上，应为每个应用程序定义唯一的加密密钥。还有一种较不安全的做法，就是先定义一个加密密钥，然后用该密钥指定 IsolateApps 选项。
主机服务器还能通过拒绝重写权限来限制重写计算机配置中的配置设置的能力。这包括不让在应用程序的 Web.config 文件中重新定义加密密钥。
保护与角色数据源的连接
连接字符串
正如前面所提到的，保护用于访问 SQL Server、Active Directory 或其他数据源应用程序的连接字符串是非常重要的。若要保持与数据库服务器的连接的安全，应使用“Protected Configuration”对配置中的连接字符串信息进行加密。有关更多信息，请参见使用受保护的配置加密配置信息。
使用集成安全性连接到 SQL Server
若要连接到运行 SQL Server 的计算机，应使用 Integrated Security（集成安全性）以避免泄漏连接字符串以及公开用户 ID 和密码的可能。当指定使用“Integrated Security”的连接来连接到运行 SQL Server 的计算机时，角色管理器功能会恢复为进程的标识。应确保运行 ASP.NET 的进程（例如应用程序池）的标识是默认进程帐户或受限用户帐户。有关更多信息，请参见 ASP.NET 模拟。
SQL Server 数据库权限
用于存储角色的用户信息的 SQL Server 数据库包含数据库角色和视图，可以通过它们限制用户只能访问必需的功能和内容。应为用于连接 SQL Server 角色数据库的用户 ID 分配最少的特权。有关更多信息，请参见 SQL Server 应用程序服务数据库中的角色和视图。
SQL Server Express 辅助进程标识
SQL Server Express 2005 包括一种新的操作模式，允许 SQL Server 启动作为连接用户的标识运行的辅助进程。此功能称为“作为用户运行”模式。虽然在使用 IIS 时此操作模式适用于桌面开发，但在承载有多个不受信任的客户基本代码的 Web 服务器上，启动辅助进程并不适当。对于那些包含互不信任的应用程序的共享宿主服务器，应该显式禁用“作为用户运行”功能。通过连接到 SQL Express 实例（例如，osql –E –S .\sqlexpress）并发出以下 Transact-SQL 命令，可关闭此功能。
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
保护授权存储
若要提高使用 AuthorizationStoreRoleProvider 时数据源的安全性，请将角色信息存储在 Active Directory 服务器中，这与基于文件的授权存储相反。这使得在 Web 服务器的安全受到威胁时，策略存储文件不会被暴露。
当连接到 Active Directory 服务器时，角色管理器功能恢复为进程的标识。应确保运行 ASP.NET 的进程（例如应用程序池）的标识是默认进程帐户或受限用户帐户。有关更多信息，请参见 ASP.NET 模拟。另外，应该为 Active Directory 授权存储中的帐户分配权限，仅允许访问特定的授权管理器 (Authorization Manager) 应用程序或 ASP.NET 应用程序必需的范围。
应使用网络加密工具（如 Internet 协议安全 (IPSec)）来保护到 Active Directory 服务器的连接。
保护角色 Cookie
通过将 roleManager 元素的 cacheRolesInCookie 属性设置为 true，可以指定将用户的角色名称缓存到会话 Cookie 中，以此来提高性能。默认情况下，角色名以加密格式存储，但您应为角色 cookie 提供更多的安全性，方法是将 cookieRequireSSL 属性设置为 true，并只在启用了 SSL 时才将角色缓存到会话 cookie 中。这可以使角色 cookie 不会公开在网络上，也不会被用在针对应用程序的重播攻击。
防止在应用程序之间共享 Cookie
如果将 roleManager 元素的 cacheRolesInCookie 属性设置为 true，并将 cookiePath 属性设置为一个包括多个应用程序的路径，则将同一个角色 Cookie 发送给多个应用程序。通过在 machineKey 配置元素中为每个应用程序指定相同的加密信息，可以在多个应用程序之间共享角色 cookie。
若要避免在多个应用程序之间共享角色名 cookie，请在 machineKey 配置元素中为每个应用程序指定不同的加密密钥，将每个应用程序的 cookiePath 属性设置为特定的应用程序路径，并将每个应用程序的 ApplicationName 属性设置为唯一值。
保护使用角色的网页
处理敏感数据的应用程序页面（如登录页面）应使用标准 Web 安全机制进行保护。这些安全机制包括使用安全套接字层 (SSL)，以及要求用户登录之后才能执行诸如更新用户信息或删除用户之类的敏感操作。
此外，网页上不应以明文形式公开敏感数据，如密码（有时候还包括用户名）。请确保显示这种信息的页面使用了 SSL，并且仅可供已经过身份验证的用户使用。此外，请避免在 Cookie 中存储敏感数据或通过不安全的连接发送敏感数据。
防范拒绝服务攻击
对于那些执行更新或大量搜索操作的方法，如果许多客户端同时调用它们，则会使角色数据源的响应性下降。若要减少暴露在拒绝服务攻击下的机会，请将利用上述方法执行数据库更新或搜索的 ASP.NET 页面的访问权限限制在管理用户的范围内，而仅将提供角色成员资格验证的 ASP.NET 页面公开供所有用户使用。
错误消息和事件
异常
若要防止向不必要的源公开敏感信息，可对应用程序进行配置，从而做到不显示详细的错误消息，或者仅当客户端是 Web 服务器本身时才显示详细错误消息。有关更多信息，请参见 customErrors 元素（ASP.NET 设置架构）。
事件日志
如果服务器运行的是 Windows Server 2003，则可以通过下面的方法提高应用程序的安全性：保护事件日志，以及设置与事件日志的大小和保留时间等有关的参数来防止对它的间接的拒绝服务攻击。
跟踪信息
您的 Web 服务器可以配置为在发生有关角色管理器功能的特定操作时进行跟踪，并将跟踪信息存储在日志文件中。由于诸如用户名和角色名之类的敏感信息可以存储在跟踪日志文件中，因此您应将以下三种权限限制在管理员范围内：启用跟踪的权限、配置跟踪日志文件位置的权限和访问跟踪日志文件的权限。
自定义角色提供程序
创建自定义角色提供程序时，请确保遵循安全性最佳实践，以避免受到攻击（如在使用数据库时受到 SQL 注入式攻击）。利用自定义角色提供程序时，请确保已经就提供程序是否符合安全性最佳实践进行了检查。
使用区域敏感字符
使用 SQL Server 角色提供程序或自定义角色提供程序时，数据源可能被配置为以区域敏感格式存储角色数据。但是，ASP.NET 始终将 authorization 配置元素中指定的角色名称和数据源中的角色名称作为区域固定的值求出。因此，未经授权的用户可能被授予不必要的权限，因为如果将这些用户的未授权角色的名称视为区域固定的，则未授权角色的名称与授权角色的名称相同。要避免用户获得未经授权的访问权限，请确保角色名称在被作为区域固定值求出时是唯一的。