Break N .net技术/生活BLOG

给业务和数据层添加安全授权规则

当你在一个ASP.NET应用中认证一个用户之后，通过认证的用户的身份(identity)将在服务器端处理用户请求的整个过程中自动流动(flow)。这意味着，你不需要从一个方法到另一个方法，或从一个类到另一个类，手工传递用户的身份(identity)。这使得在你整个应用中实现安全授权规则极其容易。

.NET中一个少为人知的特性是，在生成一个类的实例对象，或者访问一个对象的方法或属性(property)之前，能够让CLR自动根据这个身份信息来给用户授权的能力。这使得给你的业务和数据层添加安全授权规则极其容易，不必写太多编码。

你要做的就是使用System.Security.Permission命名空间下的PrincipalPermissionAttribute，在适当的类或类的成员上标记这个属性即可。譬如：

using System;
using System.Security.Permissions;

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public class EmployeeManager
{
 [PrincipalPermission(SecurityAction.Demand, Role = "Manager")]
 public Employee LookupEmployee(int employeeID)
 {
 // todo
 }

 [PrincipalPermission(SecurityAction.Demand, Role = "HR")]
 public void AddEmployee(Employee e)
 {
 // todo
 }
} 

在上面的例子中，我给EmployeeManager类添加了一个PrincipalPermission属性。这么做的效果是，我要求在处理一个用户的web请求时，在实例化这个类之前，这个用户必须先通过认证(即先登录)，Authenticated=true这要求强迫系统这么做。然后，我在LookupEmployee和AddEmployee方法上另加了2个安全要求。对于 LookupEmployee 方法，我要求通过认证的用户要调用这个方法的话，必须属于“经理(Manager)”这个角色。对于 AddEmploye 方法，我要求通过认证的用户要调用这个方法来给系统添加一个新的雇员的话，必须属于“人事部(HR)”这个角色。

这样，假如我偶然地在UI层引人了安全漏洞，有一些编码路径允许一个不是经理或不属于人事部的雇员导致这些方法被调用，那么我的业务层会自动防范这样的事情发生，并且抛出一个安全异常来。

并不局囿于任何特定的认证模式。它可以与表单认证，Windows认证，Passport认证，或者你想发明的任何定制的认证模式一起合作使用。它也可以和我想用的任何角色机制一起使用，这样，如果你建立或接入你自己的ASP.NET角色提供器的话，它自动会工作的。

PrincipalPermissionAttribute类是在标准的CLR mscorlib 程序集中实现的，这个程序集是所有的 .NET项目编译时都需要引用的。所以它不是特定于ASP.NET的，它可以在任何应用类型下使用，包括Windows和控制台程序。这个事实，除了使它更加有用外，也使得单元测试使用它的业务/数据层库项目更加容易。

在页面和控件里使用PrincipalPermissionAttribute

PrincipalPermissionAttribute可用在一个应用的任何类上。所以，除了在你的业务和数据层使用该属性外，你也可以在ASP.NET页面或者用户控件里使用该属性。譬如，想限制你的“MyPage”页面只能被拥有Manager角色的用户访问的话，你可以在该页的后台编码( code-behind)添加一个 PrincipalPermission属性(下面以VB编码为例)：

Imports System.Security.Permissions

<PrincipalPermission(SecurityAction.Demand, Authenticated:=True, Role:="Manager")> _
Partial Class MyPage
 Inherits System.Web.UI.Page

End Class