.NET框架中基于角色的安全性(3)
类别: ASP.NET教程 
Permissions对象
作为.NET安全性两个重要的分支，基于角色的安全性和代码访问安全都离不开一个重要的概念--权限（permissions）。在基于角色的安全性中，PrincipalPermission类用来检查调用线程的用户身份；而在代码访问安全中，从CodeAccessPermission派生的类则用来检查执行当前方法的所有线程各自的权限。
权限对象通过已有的安全策略来说明操作是否被允许或拒绝。对于代码访问安全权限（不过这不适用于用户权限），.NET CLR提供了堆栈遍历机制来确定所有的调用堆栈帧是否具有应有的权限。需要注意的一点是，如果permission对象为null，那么我们可以将它和PermissionState.None视为等同的，说明没有提供任何权限。权限常用于下面这些场合：
1、定义执行代码所需要的权限。
2、系统的安全策略可以承认或拒绝代码请求的权限。
3、代码通过Demand方法来保证（要求）它调用的代码具有所需的权限。
4、代码还可以使用Assert，Deny或PermitOnly方法来跳过安全堆栈检查机制。
另外，我们还可以使用成组的权限，在PermissionSet类中我们就可以使用各种不同权限组集合。
下面我们还是先来看看最常用到的PrincipalPermission类，至于另外一个常用的CodeAccessPermission类，稍后将会在代码访问安全的内容中详细介绍。
作为PrincipalPermission类实现的三个接口之一，IPermission接口在PrincipalPermission类中有了举足轻重的作用。IPermission接口提供了以下方法：
1、Copy 创建并返回当前权限的相同副本。
2、Demand 如果调用堆栈上的内容不满足权限对象所指定的权限内容，则会在运行时引发SecurityException。该方法可以让当前代码不会被其他的恶意代码所利用。
3、Intersect 创建并返回一个权限，该权限是当前权限和指定权限的交集。
4、IsSubsetOf 确定当前权限是否为指定权限的子集。
5、Union 创建一个权限，该权限是当前权限与指定权限的并集。
在上面列出的方法中，Demand方法是最常用也是最重要的方法。Demand方法会对当前方法的所有调用者进行检查以确定它们是否有足够的权限访问以指定的方式访问特定的资源（通常的检查方式是从调用堆栈上最新的调用方法开始通过执行完全的堆栈遍历来满足安全条件，但堆栈遍历不是必须的，PrincipalPermission.Demand就没有进行堆栈遍历），如果检查失败的话，Demand方法会抛出SecurityException异常，只有没有任何异常抛出的情况下，Demand方法才成功返回。
下图显示的是IPermission接口的继承层次：
[imghttp://myarticle.enet.com.cn/images/200407/1090981312024.gif[/img]
接着我们来讨论PrincipalPermission类，这里就需要我们前面所谈到principal对象了，在PrincipalPermission类的实例执行Demand方法时，实际上是在判断当前的principal对象是否匹配给定PrincipalPermission对象，如果不匹配的话，就抛出SecurityException。另外，Demand方法还可以用来强行让principal对象的identity验证通过，以便能不抛出异常，进行正常的操作。
下面的代码片断简要地说明了如何使用principalpermission对象：
String user1 = \"Abbott\";
String role1 = \"StraightMan\";
PrincipalPermission PrincipalPerm1 =
new PrincipalPermission(user1, role1);
String user2 = \"Costello\";
String role2 = \"FunnyMan\";
PrincipalPermission pp =
new PrincipalPermission(user2, role2);
PrincipalPerm1.Union(pp).Demand();
上面的代码说明了如何使用合并两个principalpermission对象，在合并之后，如果用户是StraightMan角色的Abbott或是FunnyMan角色的Costello，那么Demand将会成功返回。
以上就是基于角色的安全性中所需要用到的基础类和一些示例代码，希望大家能够从上面的内容中粗窥.NET安全性的门堂，能更好的应用.NET安全性来开发安全的程序。
作为.NET安全性两个重要的分支，基于角色的安全性和代码访问安全都离不开一个重要的概念--权限（permissions）。在基于角色的安全性中，PrincipalPermission类用来检查调用线程的用户身份；而在代码访问安全中，从CodeAccessPermission派生的类则用来检查执行当前方法的所有线程各自的权限。
权限对象通过已有的安全策略来说明操作是否被允许或拒绝。对于代码访问安全权限（不过这不适用于用户权限），.NET CLR提供了堆栈遍历机制来确定所有的调用堆栈帧是否具有应有的权限。需要注意的一点是，如果permission对象为null，那么我们可以将它和PermissionState.None视为等同的，说明没有提供任何权限。权限常用于下面这些场合：
1、定义执行代码所需要的权限。
2、系统的安全策略可以承认或拒绝代码请求的权限。
3、代码通过Demand方法来保证（要求）它调用的代码具有所需的权限。
4、代码还可以使用Assert，Deny或PermitOnly方法来跳过安全堆栈检查机制。
另外，我们还可以使用成组的权限，在PermissionSet类中我们就可以使用各种不同权限组集合。
下面我们还是先来看看最常用到的PrincipalPermission类，至于另外一个常用的CodeAccessPermission类，稍后将会在代码访问安全的内容中详细介绍。
作为PrincipalPermission类实现的三个接口之一，IPermission接口在PrincipalPermission类中有了举足轻重的作用。IPermission接口提供了以下方法：
1、Copy 创建并返回当前权限的相同副本。
2、Demand 如果调用堆栈上的内容不满足权限对象所指定的权限内容，则会在运行时引发SecurityException。该方法可以让当前代码不会被其他的恶意代码所利用。
3、Intersect 创建并返回一个权限，该权限是当前权限和指定权限的交集。
4、IsSubsetOf 确定当前权限是否为指定权限的子集。
5、Union 创建一个权限，该权限是当前权限与指定权限的并集。
在上面列出的方法中，Demand方法是最常用也是最重要的方法。Demand方法会对当前方法的所有调用者进行检查以确定它们是否有足够的权限访问以指定的方式访问特定的资源（通常的检查方式是从调用堆栈上最新的调用方法开始通过执行完全的堆栈遍历来满足安全条件，但堆栈遍历不是必须的，PrincipalPermission.Demand就没有进行堆栈遍历），如果检查失败的话，Demand方法会抛出SecurityException异常，只有没有任何异常抛出的情况下，Demand方法才成功返回。
下图显示的是IPermission接口的继承层次：
[imghttp://myarticle.enet.com.cn/images/200407/1090981312024.gif[/img]
接着我们来讨论PrincipalPermission类，这里就需要我们前面所谈到principal对象了，在PrincipalPermission类的实例执行Demand方法时，实际上是在判断当前的principal对象是否匹配给定PrincipalPermission对象，如果不匹配的话，就抛出SecurityException。另外，Demand方法还可以用来强行让principal对象的identity验证通过，以便能不抛出异常，进行正常的操作。
下面的代码片断简要地说明了如何使用principalpermission对象：
String user1 = \"Abbott\";
String role1 = \"StraightMan\";
PrincipalPermission PrincipalPerm1 =
new PrincipalPermission(user1, role1);
String user2 = \"Costello\";
String role2 = \"FunnyMan\";
PrincipalPermission pp =
new PrincipalPermission(user2, role2);
PrincipalPerm1.Union(pp).Demand();
上面的代码说明了如何使用合并两个principalpermission对象，在合并之后，如果用户是StraightMan角色的Abbott或是FunnyMan角色的Costello，那么Demand将会成功返回。
以上就是基于角色的安全性中所需要用到的基础类和一些示例代码，希望大家能够从上面的内容中粗窥.NET安全性的门堂，能更好的应用.NET安全性来开发安全的程序。
- 上一篇: .NET框架中基于角色的安全性(2)
- 下一篇: .NET框架中基于角色的安全性(3)
