如何进行权限控制？

公司要编一个较简单的管理信息系统/MIS，先从某一个模块开始做起，一步步的扩充，所以权限控制也要具有可扩展性。具体说来，就是当增加一个模块时，能较简单的扩充相应的一些权限，最好不要修改数据库表结构和原有业务模块的源代码）。查询以前的帖子，感觉都不大满意。可以通过建立用户类来实现吗？还是有更好的办法？
请大家教教我，我在权限控制这一块没有什么经验的。

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

权限问题非常复杂
如果系统比较小的话用session吧
Asp.net的身份验证有有三种，分别是"Windows | Forms | Passport"，其中又以Forms验证用的最多，也最灵活。
Forms 验证方式对基于用户的验证授权提供了很好的支持，可以通过一个登录页面验证用户的身份，将此用户的身份发回到客户端的Cookie，之后此用户再访问这个web应用就会连同这个身份Cookie一起发送到服务端。服务端上的授权设置就可以根据不同目录对不同用户的访问授权进行控制了。下面大概的看一下Forms的过程。Forms身份验证基本原理：一身份验证要采用Forms身份验证，先要在应用程序根目录中的Web.config中做相应的设置:<authentication mode="forms">
    <forms name=".ASPXAUTH " loginUrl="/login.aspx" timeout="30" path= "/">
    </forms>
</authentication>其中<authentication mode= "forms"> 表示本应用程序采用Forms验证方式。
1. <forms>标签中的name表示指定要用于身份验证的 HTTP Cookie。默认情况下，name 的值是 .ASPXAUTH。采用此种方式验证用户后,以此用户的信息建立一个FormsAuthenticationTicket类型的身份验证票,再加密序列化为一个字符串,最后将这个字符串写到客户端的name指定名字的Cookie中.一旦这个Cookie写到客户端后,此用户再次访问这个web应用时会将连同Cookie一起发送到服务端,服务端将会知道此用户是已经验证过的. 再看一下身份验证票都包含哪些信息呢,我们看一下FormsAuthenticationTicket类:
CookiePath：返回发出 Cookie 的路径。注意，窗体的路径设置为 /。由于窗体区分大小写，这是为了防止站点中的 URL 的大小写不一致而采取的一种保护措施。这在刷新 Cookie 时使用
Expiration：获取 Cookie 过期的日期/时间。
IsPersistent：如果已发出持久的 Cookie，则返回 true。否则，身份验证 Cookie 将限制在浏览器生命周期范围内。
IssueDate：获取最初发出 Cookie 的日期/时间。
Name：获取与身份验证 Cookie 关联的用户名。
UserData ：获取存储在 Cookie 中的应用程序定义字符串。
Version：返回字节版本号供将来使用。
2. <forms>标签中的loginUrl指定如果没有找到任何有效的身份验证 Cookie，为登录将请求重定向到的 URL。默认值为 default.aspx。loginUrl指定的页面就是用来验证用户身份的,一般此页面提供用户输入用户名和密码,用户提交后由程序来根据自己的需要来验证用户的合法性(大多情况是将用户输入信息同数据库中的用户表进行比较),如果验证用户有效,则生成同此用户对应的身份验证票,写到客户端的Cookie,最后将浏览器重定向到用户初试请求的页面.一般是用FormsAuthentication.RedirectFromLoginPage 方法来完成生成身份验证票,写回客户端,浏览器重定向等一系列的动作.public static void RedirectFromLoginPage( string userName, bool createPersistentCookie, string strCookiePath );其中:
userName：就是此用户的标示,用来标志此用户的唯一标示,不一定要映射到用户账户名称.
createPersistentCookie：标示是否发出持久的 Cookie。
若不是持久Cookie，Cookie的有效期Expiration属性有当前时间加上web.config中timeout的时间，每次请求页面时，在验证身份过程中，会判断是否过了有效期的一半，要是的话更新一次cookie的有效期；若是持久cookie，Expiration属性无意义，这时身份验证票的有效期有cookie的Expires决定，RedirectFromLoginPage方法给Expires属性设定的是50年有效期。
strCookiePath：标示将生成的Cookie的写到客户端的路径，身份验证票中保存这个路径是在刷新身份验证票Cookie时使用（这也是生成Cookie的Path），若没有strCookiePath 参数，则使用web.config中 path属性的设置。这里可以看到,此方法参数只有三个,而身份验证票的属性有七个,不足的四个参数是这么来的:
IssueDate： Cookie发出时间由当前时间得出,
Expiration：过期时间由当前时间和下面要说的<forms>标签中timeout参数算出。此参数对非持久性cookie有意义。
UserData：这个属性可以用应用程序写入一些用户定义的数据,此方法没有用到这个属性,只是简单的将此属性置为空字符串,请注意此属性,在后面我们将要使用到这个属性。
Version：版本号由系统自动提供.RedirectFromLoginPage方法生成生成身份验证票后，会调用FormsAuthentication.Encrypt 方法，将身份验证票加密为字符串，这个字符串将会是以.ASPXAUTH为名字的一个Cookie的值。这个Cookie的其它属性的生成：Domain，Path属性为确省值，Expires视createPersistentCookie参数而定，若是持久cookie，Expires设为50年以后过期；若是非持久cookie，Expires属性不设置。
生成身份验证Cookie后，将此Cookie加入到Response.Cookies中，等待发送到客户端。
最后RedirectFromLoginPage方法调用FormsAuthentication.GetRedirectUrl 方法获取到用户原先请求的页面，重定向到这个页面。3. <forms>标签中的timeout和path,是提供了身份验证票写入到Cookie过期时间和默认路径。以上就是基于Forms身份验证的过程，它完成了对用户身份的确认。下面介绍基于Forms身份验证的访问授权。二访问授权验证了身份，是要使用这个身份，根据不同的身份我们可以进行不同的操作，处理，最常见的就是对不同的身份进行不同的授权，Forms验证就提供这样的功能。Forms授权是基于目录的，可以针对某个目录来设置访问权限，比如，这些用户可以访问这个目录，那些用户不能访问这个目录。
同样，授权设置是在你要控制的那个目录下的web.config文件中来设置：
<authorization>
    <allow users="comma-separated list of users"
        roles="comma-separated list of roles"
        verbs="comma-separated list of verbs" />
     <deny users="comma-separated list of users"
        roles="comma-separated list of roles"
        verbs="comma-separated list of verbs" />
</authorization><allow>标签表示允许访问，其中的属性
1. users：一个逗号分隔的用户名列表，这些用户名已被授予对资源的访问权限。问号 (?) 允许匿名用户；星号 (*) 允许所有用户。
2. roles：一个逗号分隔的角色列表，这些角色已被授予对资源的访问权限。
3. verbs：一个逗号分隔的 HTTP 传输方法列表，这些 HTTP 传输方法已被授予对资源的访问权限。注册到 ASP.NET 的谓词为 GET、HEAD、POST 和 DEBUG。<deny>标签表示不允许访问。其中的属性同上面的。在运行时，授权模块迭代通过 <allow> 和 <deny> 标记，直到它找到适合特定用户的第一个访问规则。然后，它根据找到的第一项访问规则是 <allow> 还是 <deny> 规则来允许或拒绝对 URL 资源的访问。Machine.config 文件中的默认身份验证规则是 <allow users="*"/>，因此除非另行配置，否则在默认情况下会允许访问。
Forms身份验证基于角色的授权一身份验证在web.config的<authentication>的设置还是一样：<authentication mode="forms">
    <forms name=".ASPXAUTH " loginUrl="/login.aspx" timeout="30" path= "/">
    </forms>
</authentication>/login.aspx验证用户合法性页面中，在验证了用户的合法性后，还要有个取得此用户属于哪些role的过程，这个看各个应用的本身如何设计的了，一般是在数据库中会有个use_role表，可以从数据库中获得此用户属于哪些role，在此不深究如何去获取用户对应的role，最后肯定能够获得的此用户对应的所有的role用逗号分割的一个字符串。
在上面的非基于角色的方法中，我们用了FormsAuthentication.RedirectFromLoginPage 方法来完成生成身份验证票,写回客户端,浏览器重定向等一系列的动作。这个方法会用一些确省的设置来完成一系列的动作，在基于角色的验证中我们不能用这一个方法来实现，要分步的做，以便将一些定制的设置加进来：1. 首先要根据用户标示，和用户属于的角色的字符串来创建身份验证票
public FormsAuthenticationTicket(
int version, //设为1
string name, //用户标示
DateTime issueDate, //Cookie 的发出时间, 设置为 DateTime.Now
DateTime expiration, //过期时间
bool isPersistent, //是否持久性(根据需要设置,若是设置为持久性,在发出
cookie时,cookie的Expires设置一定要设置)
string userData, //这里用上面准备好的用逗号分割的role字符串
string cookiePath // 设为"/",这要同发出cookie的路径一致,因为刷新cookie
要用这个路径
);FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket (1,"kent",DateTime.Now, DateTime.Now.AddMinutes(30), false,UserRoles,"/") ;2. 生成身份验证票的Cookie
2.1 将身份验证票加密序列化成一个字符串
string HashTicket = FormsAuthentication.Encrypt (Ticket) ;
2.2 生成cookie
HttpCookie UserCookie = new HttpCookie(FormsAuthentication.FormsCookieName, HashTicket) ;
FormsAuthentication.FormsCookieName 是用来获取web.config中设置的身份验证cookie的名字,缺省为" .ASPXAUTH".
若身份验证票中的isPersistent属性设置为持久类,则这个cookie的Expires属性一定要设置,这样这个cookie才会被做为持久cookie保存到客户端的cookie文件中.
3. 将身份验证票Cookie输出到客户端
通过Response.Cookies.Add(UserCookie) 将身份验证票Cookie附加到输出的cookie集合中,发送到客户端.
4. 重定向到用户申请的初试页面.验证部分代码(这部分代码是在login.aspx页面上点击了登录按钮事件处理代码):private void Buttonlogin_Click(object sender, System.EventArgs e)
{
     string user = TextBoxUser.Text; //读取用户名
     string password = TextBoxPassword.Text; //读取密码
     if(Confirm(user,password) == true) //confirm方法用来验证用户合法性的
    {
         string userRoles = UserToRole(user); //调用UserToRole方法来获取role字符串
         FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket (1,user,DateTime.Now,          DateTime.Now.AddMinutes(30), false,userRoles,"/") ; //建立身份验证票对象
         string HashTicket = FormsAuthentication.Encrypt (Ticket) ; //加密序列化验证票为字符串
         HttpCookie UserCookie = new HttpCookie(FormsAuthentication.FormsCookieName, HashTicket) ;
//生成Cookie
          Context.Response.Cookies.Add (UserCookie) ; //输出Cookie
         Context.Response.Redirect (Context.Request["ReturnUrl"]) ; // 重定向到用户申请的初始页面
     }
    else
    {
        // 用户身份未被确认时的代码
    }
}
//此方法用来验证用户合法性的
private bool Confirm(string user,string password)
{
    //相应的代码
}
//此方法用来获得的用户对应的所有的role用逗号分割的一个字符串
private string UserToRole(string user)
{
    //相应的代码
}二基于角色访问授权这里我们要做的是,将客户端保存的身份验证票中UserData中保存的表示角色的信息恢复到在服务端表示用户身份的GenericPrincipal对象中(记住,原来的验证过程中, GenericPrincipal对象只包含了用户信息,没有包含role信息)
一个Http请求的过程中,HttpApplication.AuthenticateRequest事件表示安全模块已建立用户标识，就是此用户的身份在web端已经建立起来, 在这个事件之后我们就可以获取用户身份信息了.
在HttpApplication.ResolveRequestCache事件之前，asp.net开始取得用户请求的页面，建立HttpHandler控制点,这时就已经要验证用户的权限了,所以恢复用户角色的工作只能在HttpApplication.AuthenticateRequest事件和HttpApplication.ResolveRequestCache事件之间的过程中做.
我们选择Application_AuthorizeRequest事件中做这个工作,可以在global.asax文件中处理HttpApplication的所有的事件,代码如下:protected void Application_AuthorizeRequest(object sender, System.EventArgs e)
{
    HttpApplication App = (HttpApplication) sender;
     HttpContext Ctx = App.Context ; //获取本次Http请求相关的HttpContext对象
    if (Ctx.Request.IsAuthenticated == true) //验证过的用户才进行role的处理
    {
        FormsIdentity Id = (FormsIdentity)Ctx.User.Identity ;
        FormsAuthenticationTicket Ticket = Id.Ticket ; //取得身份验证票
        string[] Roles = Ticket.UserData.Split (',') ; //将身份验证票中的role数据转成字符串数组
        Ctx.User = new GenericPrincipal (Id, Roles) ; //将原有的Identity加上角色信息新建一个GenericPrincipal表示当前用户,这样当前用户就拥有了role信息
    }
}
进行角色管理呀，系统能够增删角色，对于每个系统按角色进行授权，
对每个用户进行角色分配
可以参照windows2000的用户管理嘛
摘自：J道iceant 1. 对"有的目录文件显示，有的不显示的"疑问
具体到一个目录下的文件是可以控制显示与不显示，但是对目录而言不适合做这样的控制。为什么？假如用户只对 1.1.1 目录有访问权限，那么 1.1 的目录级别要不要体现出来？如果只列用户有权限的目录，那怎么能看得出是 1.1.1 的那个目录？2.组与用户
你的应用实际上是动态责任确定的应用，在程序规划与实施阶段没有办法获知有哪些角色能操作哪些对象;
另外，权限设计不可过于复杂，否则管理员也会弄不清自己分配的权限是什么样的，最少我自己加个两三层的东东就会头晕。
因此我建议你做基于 ACL 的控制。你提到了想使用组的概念，但是你想为一个人也定义一个组，我认为没有必要，完全可以是用户(User)与 Subject(Folder|Documents)直接对应。如果只能有一个人操作一个目录的文件修改，那你直接授权给某个人，和修改 Role-User Map 关系的维护量没有多大的差别。但是如果对一个目录同一种 Permission 的操作分别授权给不同的用户，维护起来肯定没有建个组或一个角色来得简单。因此，我的选择是直接使用 Subject,Group,User 的三级关系。
这里先解释几个名词:
Subject: 各种目录，文件等对象
Group: 用户集合
User:用户
Operation: 对 Subject 的某种具体操作，如 Visit,Modify,Delete 等
Permission: 是 Subject 与 Operation 的组合，如：指对某个目录的Visit操作OK, 那让我们来建几个表吧:
Permissions_Table(
subject varchar(20),--对应目录或文件的ID
user_name varchar(10), -- USER-Subject ACL
group_name varchar(10), -- Group -Subject ACL
operation_type int, --1:visit,2:modify 4:delete,3:visit+modify,5:delete+visit,6:delete+modify,7:visit+modify+delete
subject_type int, --1:dir,2:document
)user_group_table(
user_name varchar(10),
group_name varchar(10),
primary key(user_name,group_name)
)再下面....
我相信你有能力做完的.... 我想理一理思路，看看 ACL 与 RBAC 的区别:还是以部门新闻来讨论，对于静态授权，在系统设计做需求分析的时候，往往就可以
确定一个系统角色的种类，像新闻系统中，根据需求，可能会有新闻发布者(Publisher)，
新闻审核者(Reviewer)，新闻浏览者(Visitor)，管理员(Manager)以及超级管理员(Administrator)。在设计的时候我们也已经把这些角色与相应的一些 Operation 绑定在一起。
如：Publisher 拥有 Publish_Operation + Modify_Operation
Reviewer 拥有 Review_Operation + Modify_Operation + Delete_Operation
Visitor 拥有 Visit_Operation,
Manager 拥有 Create_News_System_Instance_Operation +
Modify_News_System_Instance_Operation +
Delete_News_System_Instance_Operation
Administrator 负责 Create_User_Operation+
Delete_User_Operation+
Assign_Permission_Operation+
Deassign_Permission_Operation +
Assign_Role_Operation+
Deassign_Role_Operation在授权时，往往先为一个用户(USER)，赋予一个角色，如: Manager. 这样，USER 就
拥有了对所有 News_Instance(也就是部门新闻) 操作的权限。
现在假设用户(UserA)访问 Create_News_System_Instance 功能来创建一个新的新闻实例，
叫做采购部门新闻. 因为我们在设计的时候就确定，该功能只能由 Manager 来访问，
于是，系统中权限的判断部分会首先判断当前用户(UserA)是否 Manager 角色，是的话就允许
访问，否则显示没有授权的错误信息。所以，对于 Manager 这样的应用:
[1] 在设计的时候，我们就将这样的角色与相应的 Permissions(A list of Subject-Operation pairs)
关联在一起了，这里的 Subject 是所有的新闻实例(News_Instance),Operation
就是 Create,Modify以及 Delete.
[2] 在授权的时候，超级管理员(Administrator)可以利用 Assign_Role_Operation 将用户(User)
与 Manager 这个角色关联起来。这样，User 就拥有了对所有新闻实例的 Create, Modify 以及 Delete
操作的权限。
[3] 在权限判断的时候，RBAC 系统首先判断当前用户是否是设计时确定的角色(这里是Manager),
如果是，就允许用户访问，否则就拒绝访问，并显示错误信息。
对于 Publisher 这样的角色有些不同，Publisher 这个角色只与 Operation 绑定在一起，并没有与
具体的 Subject 相关联，因此，在授权的时候，还需要指定相应的 Subject.所以，对 Publisher 这样只能事先确定 Operation 的应用来说:
[1] 在设计的时候，我们只能确定该角色能进行哪些操作，而不能确定这些操作实施的对象。
[2] 在授权的时候:
[2.1] 首先将 Publisher 与 Subject 关联,如将 Publisher 与采购部门新闻关联产生:
采购部门新闻_News_Publisher 的角色
[2.2] Administrator 为用户(User)授于采购部门新闻_News_Publisher 角色。从而 User
拥有了对"采购部门新闻"的发布权限
[3] 在权限判断的时候，用户访问采购部门新闻_News_Publish_Operation, 系统首先判断
该用户是否采购部门新闻_News_Publisher?如果是，就允许用户访问，否则就拒绝访问，
并显示错误信息。
这里用到的方法可能是这个样子:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
List publishers = RBAC.findRole(new Permission(采购部门新闻,Publish_Operation));
if(publishers==null) return false;
for(Iterator it = publishers.iterator; it.hasNext();){
Role publisher = (Publisher)it.next();
if(publisher.isAssignedWithUser(User)){
return ture;
}
}
return false;
}假如说，不采用 RBAC 的做法，考虑一下，使用 ACL，那又会是什么样子呢?
对于 Manager 那样能在设计时就确定 Subject 与 Operation 的角色，我认为没有必要考虑 ACL 了.
对于 Publisher 这样，只能事先确定 Operation 的角色，我们来做个对比.
权限系统要灵活，但是也要简洁，要不然就很可能导至失控。因为嵌套的层次太多，有可能发生不可
预知的情况. 有一天管理员可能会莫明的发现，怎么这个人会有这个权限的?
所以，我认为在 RBAC 里不支持 Role 的层级关系为妙。好了，现在来看看 ACL 对 Publisher 应用
这里指的 ACL 是直接将 User 或 Group 与 Subject 关联的做法。
User 与 Subject 是多对多的情况，
Group 与 Subject 也是多对多的情况，
同样的，User 与 Group 也是多对多的情况。现在，还是以采购部门新闻为例:
[1] 在授权的时候，可以有以下操作:
[1.1] 将 User 与 Subject 关联在一起,但是要指定相应的 Operation.
如: assignPermission(采购部门新闻,Publish_Operation,User)
[1.2] 将 Group 与 Subject 关联在一起:
如: assignPermission(采购部门新闻,Publish_Operation,Group)
[1.3] 将 User 与 Group 关联
如:
assignUserGroup(User,Group)[2] 在权限判断的时候，用户访问采购部门新闻_News_Publish_Operation，系统做如下检查:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
boolean hasPermission = false;
// users include:
// 1. Permission direct assigned Users
// 2. The user assigned with the groups that assigned with permission
List users = getAssignedUsers(new Permission(采购部门新闻,Publish_Operation));
hasPermission=users.contains(User)?true:false;
}
呵呵，你可以看看微软的STARTKITS中IBUYSPY的权限控制，非常不错的
在操作的每个功能的时候，根据用户的角色和权限判断。
参照notes得方法。