CSDN博客

img vibration

扩展.net安全机制

发表于2004/6/24 10:00:00  1071人阅读

分类: .net

.net安全机制涉及很多方面,这里只讲基本的基于角色的安全机制。.net提供了PrincipalPermission类,PrincipalPermissionAttribute类以及IPrincipal派生类支持基于角色的安全控制。内建的支持使用很方便,但灵活性却不高。举个例子吧:

     class SomeClass

     {

         [PrincipalPermission(SecurityAction.Demand, Role="admin"]

         public void SomeMethod()

         {

         }

     }

上面的代码表明只有拥有admin角色的用户才能访问SomeMethod方法,上面采用了声名式的方式,也是最方便的,当然也可以在代码中显示调用Demand检查权限或者调用IsInRoll更灵活的控制。在运行时,CLR会自动检查当前用户的Principal,检查admin是否是Principal的一个角色,关于如何为Principal对象设置角色,这里就略去了。
这样的方式虽然简单,却往往不能直接使用,因为在实际的项目中,我们往往不能在编码时确定特定角色所能执行的功能。也就是说,我们需要在运行时改变一个角色所能访问的功能。这时候,使用PrincipalPermission属性就不能解决问题了,.net似乎没有提供这样的解决方案,幸运的是,.net确实提供了扩展机制,使我们可以编写自己的权限控制机制。
为了实现上述可在运行时修改权限的机制,我们的目标是编写一个类似于PrincipalPermission的属性,让我们可以这样写:

[CustomSecurity(SecurityAction.Demand, FuncID=Func1]

public void SomeMethod()

{

}

 
然后在运行时我们可以截获用户的调用,得到用户的角色,并检查数据库中Func1功能是否可以被该用户使用(至于维护数据库管理角色和功能关系的部分,就不在这里说了)。是不是想到AOP了,是有点象,可能这也算一种AOP的实现吧。刚开始看一些AOP的东西,还不太清楚 
回到正题,至少对于权限控制的主题,.net实际上提供了截获调用的方法,而且非常简单。要做到这一点,首先是编写一个CodeAccessSecurityAttribute的继承类,也就是我们的CustomSecurityAttribute类。在这个Attribute类中加入属性FuncID,并在构造函数中调用CodeAccessSecurityAttribute的构造函数。如果对Attribute不熟悉,可以参考这篇文章:
http://www.codeproject.com/csharp/dotnetattributes.asp
CodeAccessSecurityAttribute定义了一个抽象方法CreatePermission,我们必须在继承类中实现这个方法,CreatePermission方法要求返回一个IPermission接口,这个接口也是我们要实现的,在实现IPermission接口之前,我们先看一下CustomSecurityAttribute的完整代码:

[AttributeUsage(AttributeTargets.All, AllowMultiple=false, Inherited=true)]

[Serializable]

public sealed class CustomSecurityAttribute : CodeAccessSecurityAttribute

{

     public CustomSecurityAttribute(SecurityAction action) : base(action)

     {

     }

 

     private string _funcID;

 

     public string FuncID 

     {

         get

         {

              return _funcID;

         }

         set

         {

              _funcID = value;

         }

     }

 

     public override IPermission CreatePermission()

     {

         return new CustomPermission(_actionDomain);

     }

}

 

 

很简单吧,上面代码里的CustomPermission类是实现了IPermission接口的类,我们接下来要实现它。

 

我们已经实现了CustomSecurityAttribute类,这个比较简单,但是,为了让这个Attribute类正常工作,我们必须写一个IPermission接口的实现。既然CustomSecurityAttribute类从CodeAccessSecurityAttribute继承,似乎IPermission的实现类应该从CodeAccessPermission继承,但是我尝试了很久一直存在问题,要么编译不通过,要么执行时没有任何效果。想来应该是自己的代码有问题,不过咱有土办法,既然只是要求一个IPermission接口,那我们就直接写IPermission接口的实现好了,谁知道CodeAccessPermission类里面都写了写什么。对了,可以用反编译工具看,等以后再研究吧,现在先把直接实现IPermission接口的东东贴出来,至少这个是可以工作的
IPermission有5个接口方法,分别是Copy, Union, IsSubsetOf, Intersect, Demand,这里面最重要的方法是Demand,这里我们已经可以看到.net安全机制如何处理的了。
当调用代码访问带有SecurityAttribute基础属性的安全对象时,SecurityAttribute的CreatePermission方法被调用,创建出IPermission接口对象,然后,IPermission接口的Demand方法被调用以检查权限,如果通过,则继续,否则,Demand方法抛出安全异常,用户无法访问安全对象。
对于Demand方法的实现并没有限制,那么我们当然可以实现诸如从数据库读取角色/功能对应信息,从而判断用户是否具有访问权限。角色信息可以从当前上下问的IPrincipal基础类中得到,功能信息么,也很简单,CustomSecurityAttribute记录有FuncID,而IPermission对象是由CustomSecurityAttribute创建的,在创建的时候通过构造函数传递过来就可以了,下面给出IPermission继承类的部分实现代码:

     public sealed class CustomPermission : IPermission

     {

         public CustomPermission()

         {

         }

 

         public CustomPermission(string funcID)

         {

              _funcID = funcID;

         }

 

         public CustomPermission(PermissionState state) //据MSDN文档称必须实现这个构造函数

         {

         }


        
private string _funcID;


         public void Demand()

         {

              if (!CustomPermission.CheckPermission(_funcID))

                   throw new SecurityException("Access deny");

         }

         static private bool CheckPermission(string funcID)

         {

              if (funcID == "Func1")//在这里检查用户权限

                   return true;

 

              return false;

         }

         //其他方法略

     }


上面用一个静态方法CheckPermission实现具体检查权限的功能,实际的代码需要读取用户上下文的IPrincipal对象,通过其他对象从数据库中得到Func1功能对应的角色,然后检查IPrincipal是否包含这些角色,这些代码这里就略过了

大功告成了吗?没有。IPermission的其他方法还需要一一实现,当然可以先写一个空函数体在那里。更重要的是,IPermission接口继承自ISecurityEncodable接口,而这个接口的两个方法重要性不亚于Demand方法,它们是FromXml和ToXml。其中ToXml方法用来在编译期间为assembly注入metadata数据,又看到AOP的影子了,回头得好好研究研究这个。废话不说了,下面给出这两个方法的实现代码:

         public void FromXml(SecurityElement e)

         {

              String name = e.Attribute("class");

 

              // Make sure we are not converting something else:

              if (name != typeof(CustomPermission).AssemblyQualifiedName)

                   throw new ArgumentException("Wrong SecurityElement");

 

              String version = e.Attribute("version");

 

              if (version != "1.0")

                   throw new ArgumentException("Version " + version + " does not match current version of the permission");

 

              String funcid = e.Attribute("funcid");

 

              _funcID = funcid;   

         }

 

         public SecurityElement ToXml()

         {

              SecurityElement Ret = new SecurityElement("IPermission");

              String name = typeof(CustomPermission).AssemblyQualifiedName;

 

              Ret.AddAttribute("class", name);

 

              Ret.AddAttribute("version", "1.0");

 

              Ret.AddAttribute("funcid", _funcid);

 

              return Ret;

         }

 


好了,现在我们的定制安全机制框架代码算是完成了,最后要注意的一点是:CustomSecurityAttribute和CustomPermission必须在强名字的dll中实现,并且必须注册到GAC,否则,使用它们的assembly将无法正常编译。强名字不说了,注册GAC这里介绍个技巧,就是可以在Project Property的Pre-Build Event和Post-Build Event中加入从GAC删除和加入GAC的命令行,这样,每次编译是会自动更新GAC,否则调试的时候有的烦了

写了那么多,其实有些东西也是一知半解,请精通此道的大拿指正


 

0 0

相关博文

我的热门文章

img
取 消
img