今天学习角色访问控制（RBAC)

今天学习角色访问控制（RBAC
RBAC的基本思想
RBAC（角色访问控制）的基本思想可简单地用图1来表示，即把整个访问控制过程分成两步：访问权限与角色相关联，角色再与用户关联，从而实现了用户与访问权限的逻辑分离。    由于RBAC实现了用户与访问权限的逻辑分离，因此它极大的方便了权限管理。例如，如果一个用户的职位发生变化，只要将用户当前的角色去掉，加入代表新职务或新任务的角色即可，角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，并且委派用户到角色不需要很多技术，可以由行政管理人员来执行，而配置权限到角色的工作比较复杂，需要一定的技术，可以由专门的技术人员来承担，但是不给他们委派用户的权限，这与现实中情况正好一致。    用户权限在.NET中的设计与实现    利用.NET中的用户控件实现权限控制的基本思想是：根据角色访问控制（RBAC）的基本原理，给用户分配一个角色，每个角色对应一些权限，然后利用ASP.NET中的用户控件（UserControl）来判断该用户对应的角色是否对访问页面有访问的权力。    下面将从数据库设计、添加角色和用户控件的使用等三方面来阐述具体实现过程。1、数据库中表的设计    首先，在数据库中设计功能模块表、功能表和角色表等三个表。    （1） 功能模块表    为了管理好用户的权限，首先要组织好系统的模块，为此设计了一个功能模块表。见表1。    （2） 功能表    每个功能模块所具有的子功能称为功能，如商品管理模块goods（属于功能模块的范畴）包含商品信息查询、商品信息更新、商品信息删除、商品定价信息查询以及商品定价信息更新五种功能，功能表的设计见表2。    上面提到的例子可以作为这样几条记录分别插入功能模块表和功能表。 insert into TModule values(0，\'商品管理模块\'，\'goods\'，5);
insert into Tfunction values(0，\'商品信息查询\'，\'selectgoods\'，0);
insert into Tfunction values(1，\'商品信息更新\'，\'updategoods\'，0);
insert into Tfunction values(2，\'商品信息删除\'，\'deletegoods\'，0);
insert into Tfunction values(3，\'商品定价信息查询\'，\'selectgoodsprice\'，0);
insert into Tfunction values(4，\'商品定价信息更新\'，\'updategoodsprice\'，0);    （3） 角色表    角色表的设计关键在于角色值的定义，它是一个由0和1组成的类似二进制数的字符串。而功能表中的funcNo (功能编号)字段表示该功能在角色表的roleValue (角色值)字段中的位置，如果该位置对应的数值是0，表示该角色无此权限，如果值为1，则表示该角色拥有此权限。如角色普通会员的角色值为100100…00（共100位），如上所示，商品信息查询的功能编号为0，角色值100100…00的第0位为1，所以该普通会员角色拥有商品信息查询的功能；相反，该角色值的第1位为0，而功能编号为1 的功能为商品信息更新，所以该普通会员角色没有商品信息更新的权限。它们的关系可由图2来表示。
2、角色的添加    有了上面几个表，角色页面的功能模块以及其对应的功能都可以从功能模块表和功能表中读出，如图3所示。     在将新角色普通会员插入数据库时，先将角色值的所有位都置为0，然后利用.NET Framework 类库中的Replace函数将角色值中的打上勾的功能相应的功能编号位的值改为1。    例如，新添加一个角色名为普通会员的角色，它拥有的功能为商品信息查询（功能编号0）和商品定价信息查询（功能编号3）两项，则角色值应为1001000……00（100位），即角色值中第0位和第3位的值为1，其余为0。    3、利用用户控件实现访问权限    在定义好用户控件.ascx文件（head.ascx）及.ascx.cs（head.ascx，cs）文件时，接下去只要在.aspx文件中注册和声明它就可以了。    (1) 注册＜%@ Register TagPrefix="Acme" TagName="Head" Src="../UserControl/headinner.ascx" %＞    (2) 声明    经过实践，在.aspx文件中声明.ascx文件可分为几种情况：　　第一种情况：＜Acme:Head runat="server" /＞　　第二种情况：＜Acme:Head runat="server" flag=0 funcname1=selectgoods funcname2=updategoods /＞　　第三种情况：＜Acme: Head runat="server" flag=1 funcname1= selectgoods funcname2=updategoods /＞    字段flag是用来控制怎样进行权限检查的标志，funcname指功能表中的功能英文名。如果flag为空，则不执行权限检查（第一种情况）；否则如果flag=="0"，则表示同时具有selectgoods（商品信息查询）和 updategoods（商品信息更新）这两种权限的角色所对应的用户才有权利查看该页（第二种情况）；否则，如果flag=="1"，则认为，具有selectgoods（商品信息查询）或 updategoods（商品信息更新）这两种权限中任意一种权限的用户就有权利查看该页（第三种情况）。　　上面进行权限检查的过程全部由用户控件来实现，其全部方法都封装在.ascx.cs文件中，其中最主要的一个方法是检查某一角色是否拥有某一确定权限的checkAuth（string roleId，string funcEName）方法。这个方法的思想如图4所示。    图4中roleValue（角色值）的第0位（selectgoods的功能编号）值为1，表示该角色拥有selectgoods（商品信息查询）的权限。这样，我们把对权限检查的所有逻辑都封装在了用户控件中，因此，对WEB窗体页.aspx文件而言，只需在导入.ascx文件时确定用户在访问该页面时所应拥有的权限，而不需对aspx.cs进行任何改动。    由上所述，可以很清楚地看出，只要在用户控件中对用户权限进行控制，再把它包括在.aspx文件中（这件事作者本来就是要做的），那么在编程的时候就不必考虑复杂的权限问题了。
-------------------------------------------------------------------------------------------------------------------------------
角色访问控制（RBAC）引入了Role的概念,目的是为了隔离User(即动作主体，Subject)与Privilege(权限，表示对Resource的一个操作，即Operation+Resource)。
Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。RBAC基本概念：RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）What：权限针对的对象或资源（Resource、Class）。How：具体的权限（Privilege,正向授权与负向授权）。Operator：操作。表明对What的How操作。也就是Privilege+ResourceRole：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一或多个Session.在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念就具象到一个人。这里的Group和GBAC（Group-Based Access Control）中的Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization，都可以对应到Group。反之Group未必对应一个实际的机构。例如，可以有副经理这个Group，这是多人有相同职责。引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。Role作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
-------------------------------------------------------------------------------------------------------
简单点的理解：
基于角色的权限设计（一）
在任何系统中，权限设计是最基础的东西，本文给出一个基于角色的权限设计的循序渐进的设计方案。　　在权限系统中，功能（权限）是最小的单位，比如起草新闻、编辑新闻、审核新闻、删除新闻等，而角色是一类功能的集合，比如新闻编辑这个角色，他可能有起草新闻、编辑新闻等功能集合，而责任编辑他可能就有更多的权限，比如除了新闻编辑的功能，还有审核新闻、删除新闻等功能，给张三赋予新闻编辑的角色（其实我更愿意说把张三加入到新闻编辑这个角色中去），张三就可以起草新闻、编辑新闻了，给李四赋予责任编辑的角色，李四就可以起草新闻、编辑新闻、审核新闻、删除新闻了。 　　我们来模拟一下数据：　　用户信息表： UserID
UserName
U1
张三
U2
李四
角色表： RoleID
RoleName
R1
新闻编辑
R2
责任编辑
角色用户表： RoleID
UserID
R1
U1
R2
U2
功能表： FunctionID
FunctionName
F1
起草新闻
F2
编辑新闻
F3
审核新闻
F4
删除新闻
角色功能表： RoleID
FunctionID
R1
F1
R1
F2
R2
F1
R2
F2
R2
F3
R2
F4
我们来看看如何判断一个用户具有某个功能权限： 　　首先在用户张三登录的时候，获取张三的全部功能列表： Select FunctionID From 角色功能表 Where RoleID In (Select RoleID From 用户角色表 Where UserID=’U1’) 　　这样就可以得到张三的全部功能列表Functions，在起草新闻的页面我们就可以做如下判断： Functions.Contain(‘F1’);//当然你可以把这个’F1’定义成一个常量：NewsFunction.Draft 　　如果为true就说明张三有起草新闻的权限。 　　当然对于web应用，您可以把Functions 用session保存起来，以避免每打开一个页面都去数据库中获取。 　　似乎看起来是一个不错的解决方案。 　　还是新闻系统，最初新闻系统没有分类，但是随着新闻的增加，没有分类的新闻看起来总是乱的，于是张三和李四给新闻添加了分类A、分类B，还是由张三负责起草，李四负责审核，以后又添加了更多的分类，并且也增加了人手，这个时候就有新的要求出来了：希望张三只负责分类A的起草，分类B的起草交给其他人做，李四呢也只负责分类A的审核（就相当于是一个栏目的责任编辑）。
针对这样的需求，版本一就无能为力了（当然你也可以增加几个功能：比如分类A的新闻起草和分类B的新闻起草，再把这个功能添加到相应的角色里面去，但是这个应该不是我们要得解决方案吧，不过版本二也是基于这个思想来解决的）。
其实比新闻更好的例子是论坛板块的版主。
权限设计（二）
下面是版本二的解决方案：

在版本二的功能表中加入了一个ResourceType这个字段，这个字段用来表示对某个资源的分类（比如新闻），我们同样来模拟一下（新闻分类A的ResourceType为：NTA，分类B为：NTB）：
功能表：
FunctionID
ResourceType
FunctionName
F1
NTA
起草新闻：分类A
F2
NTA
编辑新闻：分类A
F3
NTA
审核新闻：分类A
F4
NTA
删除新闻：分类A
F1
NTB
起草新闻：分类B
F2
NTB
编辑新闻：分类B
F3
NTB
审核新闻：分类B
F4
NTB
删除新闻：分类B
然后在角色表添加相应的角色，在角色功能表中添加对应的功能。
获取Functions的语句也相应地做变化：
Select FunctionID  + ‘，’ + ResourceType From 角色功能表 Where RoleID In (Select RoleID From 用户角色表 Where UserID=’U1’)
权限的判断也就变成：
Functions.Contain(‘F1,NTA’);
在新添加一个分类的时候，同时也在功能表中增加相应的记录（当然不是在数据库里面直接添加，由和功能相关的函数来添加）。
使用这种解决方案可以简单地对有分类的应用（比如论坛系统）的每个分类实行不同的控制（比如VIP板块，就只能拥有VIP角色的用户才能浏览、发表等，而其他板块只要是注册用户就可以使用了）。
在实际应用中FunctionID并不是随便的一个字符串，而是进行了编码，其编码中包含了模块ID以及能够体现出父子关系，举个例子来说：对于论坛系统，我们给它一个模块ID为”30”，论坛的功能我们先分成2类，一类是管理类（比如删除帖子），一类是使用类（比如发帖、回帖、浏览帖子等），给管理类一个编码：01，使用类一个编码：02，我们就对FunctionID进行如下的编码：
300101：删除帖子
300201：发帖
300202：回帖
300203：浏览帖子
对于资源（比如某个板块1，板块的ID为：01），我们可以组合出如下的Functions（当然这个组合你也可以不用逗号分隔，用其他的组合方式也可以，不过不要产生歧义）：
300101,01：板块1删除帖子的功能
300201,01：板块1发帖的功能
……
对于RoleID也是采用的编码方式，也能体现角色的父子关系，也可以实现角色功能的继承等（当然获取角色功能列表的SQL语句就不是现在这么简单了）。在我现在的应用里面没有实现角色的继承（虽然角色的编码体现出了角色的父子关系）。