ASP.NET 提供了一个现成的架构来管理和使用角色。和成员资格 API 类似，这个架构含有内置的功能，比如管理角色、给用户指派角色、从代码中访问所有的角色信息。这个架构也可以通过提供程序完全扩展。
详细来讲，角色架构包含如下内容：
- 一个基于提供程序的扩展机制，用来包含不同类型的角色数据存储
- 一个现成的 SQL Server 提供程序和必需的数据库表
- 预置的 RolePrincipal 类，它可以通过 RoleManagerModual 模块为已验证的用户自动初始化
- 使用 Roles 类，完全可以通过编程访问角色
1. 激活架构
首先，必须激活它。你可以在 ASP.NET 网站管理工具中的安全设置向导或者安全标签页为这个网站启用角色。这个工具会在程序的 web.config 文件中添加一些配置项，当然，你也可以手动完成这些。
同时，启用表单验证模式，此时的 web.config 文件内容如下：
<configuration>
<system.web>
<authentication mode="Forms" />
<roleManager enabled="true" />
</system.web>
</configuration>
只要有这个配置文件，ASP.NET 会自动创建一个基于文件的数据库 ASPNETDB.MDF。
如果要使用一个自定义的数据存储，就必须完成下面两个步骤：
- 通过 aspnet_regsql.exe 或 通过执行位于 .NET Framework 目录下的 TSQL 命令脚本创建数据存储
- 配置角色提供程序以使用前面的自定义存储
通过 <roleManager> 可以配置角色提供程序，你可以使用一个不同的数据库，也可以使用完全不同的存储机制。通过 <roleManager> 还可以配置一些特殊属性，即 WAT 中无法配置的属性：
<configuration>
<connectionStrings>
<add name="MySqlStore"
connectionString="data source=(local);Intergrated Security=SSPI;initial catalog=MySqlDB"/>
</connectionStrings>
<system.web>
<roleManager enabled="true"
defaultProvider="CustomSqlProvider"
cacheRolesInCookie="true"
cookieName=".MyRolesCookie"
cookieTimeout="30"
cookieSlidingExpiration="true"
cookieProtection="All">
<providers>
<add name="CustomSqlProvider"
type="System.Web.Security.SqlRoleProvider"
connectionStringName="MySqlStore"
applicationName="Authorization"/>
</providers>
</roleManager>
<authentication mode="Forms" />
<compilation debug="true" />
</system.web>
</configuration>
一旦在 web.config 文件中添加了这些配置项后，就可以通过 WAT 选择提供程序了。只需要切换到提供程序标签页签即可：
<roleManager> 节可配置的选项
| enabled | 是否激活角色 API |
| defaultProvider | 可选特性。指定当前活动的提供程序来存储角色信息 |
| cacheRoleInCookie | 不必每次都从后台存储读取角色，可将角色信息存放到 cookie 中 |
| cookieName | 如果角色信息缓存在 cookie 中，可通过这个特性指定 cookie 的名字 |
| cookiePath | 指定 cookie 的路径，这是应用程序缓存角色的地方，默认值是 / |
| cookieProtection | 角色 cookie 可以被加密并签名。这个特性指定 cookie 的保护级别。有效值为：All（加密并签名）、Encryption、Validation、None |
| cookieRequireSSL | 指定是否只有 SSL 被激活时（true）或在其他任何情况（false）下，由 ASP.NET 返回 cookie。 |
| cookieTimeout | 获取或设置角色 cookie 的超时时间，单位是分钟，默认值 30 |
| cookieSlidingExpiration | 指定在用户对 ASP.NET 请求时，是否延长 cookie 的超时时间。默认 true |
| createPersistentCookie | 设为 true，cookie 在客户端永久保存。否则，关闭浏览器之后被删除 |
| domain | 指定角色 cookie 有效域 |
| maxCachedResults | 指定 cookie 中可以保存的角色名称的最大数量 |
在之前的例子中，配置使用了 SqlRoleProvider，这个提供程序包含一些额外的设置。
SqlRoleProvider 的额外属性
| name | 提供程序的名字，可以用在 defaultProvider 特性中 |
| applicationName | 管理角色的应用程序的名字 |
| decription | 提供程序的简短且友好的描述 |
| connectionStringName | 在 web.config 文件中 <connectionString> 节中指定连接字符串的名字 |
基础角色 API 类
|
类 |
描述 |
| RoleManagerModule | 这个模块保证在每一次请求时，相应角色会被赋给当前登录的用户。它附着在 Application_AuthenticateRequest 事件上，并创建一个 RolePrincipal 实例 |
| RoleProvider | 所有角色提供程序的基类。每一个自定义提供程序必须继承它 |
| RoleProviderCollection | 角色提供程序的集合。允许你迭代配置的角色提供程序。当编写管理应用程序或页面时很方便 |
| SqlRoleProvider | 一个基于 SQL Server 数据库的角色提供程序的实现 |
| WindowsTokenRoleProvider | 获得一个基于 Windows 用户组经过验证的 Windows 用户的信息 |
| AuthorizationStoreRoleProvider | 角色提供程序的实现，用来在一个基于授权管理器的数据存储中存储角色信息。Windows Server 2003 内置了授权管理器，它允许你定义程序的角色以及这个角色的权限。你的程序可以使用授权管理器通过编程对用户授权 |
| Roles | 可以使用这个类作为你和角色存储的主要接口，这个类包含管理角色的编程接口 |
| RolePrincipal | 一个 IPrincipal 的实现。把一个已验证用户连接到已配置的角色。只要角色 API 被激活，它就由 RoleManagerModule 自动创建 |
只要配置了角色 API，就可以创建用户和角色，并可以通过 WAT 或者程序中的 Roles 类把用户分配给这些角色。在“安全”页签上单击“创建或管理角色”链接，然后就可以创建角色并将用户添加到这个角色了。如下图：
配置了用户和角色之后，就要为程序配置授权规则。除了在程序不同目录配置合适的 <authorization> 之外，也可以在安全页签添加新的访问规则：
当激活了角色 API 之后，RoleManagerModule 会自动创建一个 RolePrincipal 实例。它包含这个经过验证的用户的身份信息以及他所属的角色。你可以使用下面代码中的属性从实例中提取信息，并调用 IsInRole() 方法来执行授权检查：
protected void Page_Load(object sender, EventArgs e)
{
// IsAuthenticated: 获取一个值，该值指示是否验证了用户
if (User.Identity.IsAuthenticated)
{
// RolePrincipal: 表示当前 HTTP 请求的安全信息，包括角色成员资格
RolePrincipal rp = User as RolePrincipal;
StringBuilder roleInfo = new StringBuilder();
// Identity: 为当前 HTTP 请求获取安全标识
roleInfo.AppendFormat("<h2>Welcome {0}</h2>", rp.Identity.Name);
// ProviderName: 获取存储和检索用户角色信息的角色提供程序的名称
roleInfo.AppendFormat("<b>Provider:</b> {0}<br />", rp.ProviderName);
// Version: 获取角色 Cookie 的版本号
roleInfo.AppendFormat("<b>Version:</b> {0}<br />", rp.Version);
// ExpireDate: 获取角色 Cookie 将过期的日期和时间
roleInfo.AppendFormat("<b>Expires at:</b> {0}<br />", rp.ExpireDate);
roleInfo.Append("<b>Roles:</b> ");
// GetRoles(): 获取 System.Web.Security.RolePrincipal 是其成员的角色的列表
string[] roles = rp.GetRoles();
for (int i = 0; i < roles.Length; i++)
{
if (i>0)
{
roleInfo.Append(", ");
}
roleInfo.Append(roles[i]);
}
lblRoleInfo.Text = roleInfo.ToString();
}
}
2. 和角色一起使用 LoginView 控件
之前的文章介绍过，LoginView 控件可根据是否为匿名用户显示不同的内容，使用 <LoggedInTemplate> 模板和 <AnonymousTemplate> 模板实现这个功能。这个控件还提供另一个模板 <RoleGroup> 来基于用户不同的角色显示不同的内容。
仔细观察下面的页面代码即可明白：
<asp:LoginView ID="LoginView1" runat="server">
<LoggedInTemplate>
<h2>This is the logged in template.</h2>
</LoggedInTemplate>
<RoleGroups>
<asp:RoleGroup Roles="Admin">
<ContentTemplate>
<h2>Only Admins will see this.</h2>
</ContentTemplate>
</asp:RoleGroup>
<asp:RoleGroup Roles="Others">
<ContentTemplate>
<h2>This is for others!</h2>
</ContentTemplate>
</asp:RoleGroup>
</RoleGroups>
</asp:LoginView>
注意：任何时候，这些角色模板只会显示能够匹配已登录用户角色的第一个模板！另外，LoggedInTemplate 模板只会为已登录且 RoleGroups 中没有任何模板被匹配的用户显示！
3. 通过编程访问角色
角色 API 允许你通过编程完成所有的任务。你可以通过编程添加新角色、读取角色信息、删除角色。还可以将用户分配给角色或者获得属于某个角色的用户。
通过 Roles 类的方法可实现这些功能。Roles 类大多属性是 <roleManager> 标签特性的映射。因此，下表只包含了一些额外的属性和 Roles 类的方法：
Roles 类的成员
| Provider | 返回当前使用的提供程序 |
| Providers | 返回系统上所有可用的提供程序。它会返回 machine.config 和 web.config 中定义的所有提供程序 |
| AddUserToRole | 赋予一个用户一个角色 |
| AddUserToRoles | 赋予一个用户一组角色 |
| AddUsersToRole | 赋予一组用户一个角色 |
| AddUsersToRoles | 赋予一组用户一组角色 |
| CreateRole | 创建角色 |
| DeleteRole | 删除角色 |
| FindUsersInRole | 返回关联此角色的所有用户 |
| GetAllRoles | 返回当前已配置的提供程序的角色存储中所有的角色 |
| GetRolesForUser | 返回指定用户的所有角色 |
| GetUsersInRole | 返回属于角色参数所指定的角色的所有用户列表 |
| IsUserInRole | 指定用户是否属于指定角色 |
| RemoveUserFromRole | 将一个用户从指定角色中移除 |
| RemoveUserFromRoles | 将一个用户从所有指定角色中移除 |
| RemoveUsersFromRole | 从一个角色中移除所有指定用户 |
| RemoveUsersFromRoles | 从所有指定角色中移除所有指定用户 |
| RoleExists | 是否存在指定的角色 |
编程访问角色的一个非常好的应用是，当用户注册时，可以自动将用户分配到相应的角色中。例如，如果程序提供了一个类似 Everyone 的角色，那么每一个单独的用户都应该是这个角色的一员。那么如何做到呢？
可以捕获 CreateUserWizard 控件的 CreatedUser 事件，但这还不够。因为 WAT 也可以创建用户，因此有必要再寻找一个补救的措施。可在全局程序 Global.asax 的 Application_AuthenticateRequest 事件中确认用户是否属于 Everyone 角色的成员之一来进行处理：