mysqsl--用户-角色-权限表的设计

设计一个灵活、通用、方便的权限管理系统。

在这个系统中,我们需要对系统的所有资源进行权限控制,那么系统中的资源包括哪些呢?我们可以把这些资源简单概括为静态资源(功能操作、数据列)和动态资源(数据),也分别称为对象资源和数据资源,后者是我们在系统设计与实现中的叫法。

系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。

三.相关对象及其关系

大概理清了一下权限系统的相关概念,如下所示:

1.       权限

系统的所有权限信息。权限具有上下级关系,是一个树状的结构。下面来看一个例子

系统管理

用户管理

查看用户

新增用户

修改用户

删除用户

对于上面的每个权限,又存在两种情况,一个是只是可访问,另一种是可授权,例如对于“查看用户”这个权限,如果用户只被授予“可访问”,那么他就不能将他所具有的这个权限分配给其他人。

2.       用户

应用系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。

3.       角色

为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系,可以形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。

4.       组

为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际情况中,我们知道,组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群,一个群可以有多个用户,一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息,例如普通群、高级群等。

针对上面提出的四种类型的对象,让我们通过图来看看他们之间的关系。

有上图中可以看出,这四者的关系很复杂,而实际的情况比这个图还要复杂,权限、角色、组都具有上下级关系,权限管理是应用系统中比较棘手的问题,要设计一个通用的权限管理系统,工作量也着实不小。

当然对于有些项目,权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象,只需要给用户分配权限即可。

在另一些情况中,引入了角色对象,例如基于角色的权限系统,只需要给角色分配权限,用户都隶属于角色,不需要单独为用户分配角色信息。

通用权限管理设计篇(二)——数据库设计

国庆前整的通用权限设计的数据库初步设计部分,现在贴上来。

理清了对象关系之后,让我们接着来进行数据库的设计。在数据库建模时,对于N对N的

关系,一般需要加入一个关联表来表示关联的两者的关系。初步估计一下,本系统至少需要十张表,分别为:权限表、用户表、角色表、组表、用户权限关联表、用

户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。

各表及其关系如下:

1.       用户表


用户表(TUser)


字段名称


字段


类型


备注


记录标识


tu_id


bigint


pk, not null


所属组织


to_id


bigint


fk, not null


登录帐号


login_name


varchar(64)


not null


用户密码


password


varchar(64)


not null


用户姓名


vsername


varchar(64)


not null


手机号


mobile


varchar(20)

 

电子邮箱


email


varchar(64)

 

创建时间


gen_time


datetime


not null


登录时间


login_time


datetime

 

上次登录时间


last_login_time


datetime

 

登录次数


count


bigint


not null

2.       角色表


角色表(TRole)


字段名称


字段


类型


备注


角色ID


tr_id


bigint


pk, not null


父级角色ID


parent_tr_id


bigint


not null


角色名称


role_name


varchar(64)


not null


创建时间


gen_time


datetime


not null


角色描述


description


varchar(200)

 

3.       权限表


权限表(TRight)


字段名称


字段


类型


备注


权限ID


tr_id


bigint


pk, not null


父权限


parent_tr_id


bigint


not null


权限名称


right_name


varchar(64)


not null


权限描述


description


varchar(200)

 

4.       组表


组表(TGroup)


字段名称


字段


类型


备注


组ID


tg_id


bigint


pk, not null


组名称


group_name


varchar(64)


not null


父组


parent_tg_id


bigint


not null


创建时间


gen_time


datetime


not null


组描述


description


varchar(200)

 

5.       角色权限表


角色权限表(TRoleRightRelation)


字段名称


字段


类型


备注


记录标识


trr_id


bigint


pk, not null


角色


Role_id


bigint


fk, not null


权限


right_id


bigint


fk, not null


权限类型


right_type


int


not null(0:可访问,1:可授权)

6.       组权限表


组权限表(TGroupRightRelation)


字段名称


字段


类型


备注


记录标识


tgr_id


bigint


pk, not null



tg_id


bigint


fk, not null


权限


tr_id


bigint


fk, not null


权限类型


right_type


int


not null(0:可访问,1:可授权)

7.       组角色表


组角色表(TGroupRoleRelation)


字段名称


字段


类型


备注


记录标识


tgr_id


bigint


pk, not null



tg_id


bigint


fk, not null


角色


tr_id


bigint


pk, not null

8.       用户权限表


用户权限表(TUserRightRelation)


字段名称


字段


类型


备注


记录标识


tur_id


bigint


pk, not null


用户


tu_id


bigint


fk, not null


权限


tr_id


bigint


fk, not null


权限类型


right_type


int


not null(0:可访问,1:可授权)

9.       用户角色表


用户角色表(TUserRoleRelation)


字段名称


字段


类型


备注


记录标识


tur_id


bigint


pk, not null


用户


tu_id


bigint


fk, not null


角色


tr_id


bigint


fk, not null

10.   用户组表


用户组表(TUserGroupRelation)


字段名称


字段


类型


备注


记录标识


tug_id


bigint


pk, not null


用户


tu_id


bigint


fk, not null



tg_id


bigint


fk, not null

11.   组织表


组织表(TOrganization)


字段名称


字段


类型


备注


组织id


to_id


bigint


pk, not null


父组


parent_to_id


bigint


not null


组织名称


org_name


varchar(64)


not null


创建时间


gen_time


datetime


not null


组织描述


description


varchar(200)

 

12.   操作日志表


操作日志表(TLog)


字段名称


字段


类型


备注


日志ID


log_id


bigint


pk, not null


操作类型


op_type


int


not null


操作内容


content


varchar(200)


not null


操作人


tu_id


bigint


fk, not null


操作时间


gen_time


datetime


not null

1. 权限资源

系统的所有权限信息。权限具有上下级关系,是一个树状的结构。下面来看一个例子

系统管理

用户管理

查看用户

新增用户

修改用户

删除用户

对于上面的每个权限,又存在两种情况,一个是只是可访问,另一种是可授权,例如对于“查看用户”这个权限,如果用户只被授予“可访问”,那么他就不能将他所具有的这个权限分配给其他人。

2. 用户

应用系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。

3. 角色

为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系,可以形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。

4. 组

了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际情况中,我们知道,组也可以具有自己的角色信息、

权限信息。这让我想到我们的QQ用户群,一个群可以有多个用户,一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有

自己的角色信息,例如普通群、高级群等。

针对如上提出的四种对象,我们可以整理得出它们之间的关系图,如下所示:

总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。

其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分,某个组的权限信息可用公式表示:组权限 = 所属角色的权限合集 + 组自身的权限。

角色权限管理包括包含用户、包含组和角色权限三部分,某个角色的权限的计算公式为:角色权限 = 角色自身权限。

用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式:用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。

组织管理即对用户所属的组织进行管理,组织以树形结构展示,组织管理具有组织的增、删、改、查功能。

操作日志管理用于管理本系统的操作日志。

注意:因为组和角色都具有上下级关系,所以下级的组或角色的权限只能在自己的直属上级的权限中选择,下级的组或者角色的总的权限都不能大于直属上级的总权限。

2.5 模块结构设计

本系统的具有的功能模块结构如下图所示:

2.6 尚未解决的问题

无。

3.      接口设计(暂略)

3.1 用户接口(暂略)

3.2 外部接口(暂略)

3.3 内部接口(暂略)

4.      界面总体设计

本节将阐述用户界面的实现,在此之前对页面元素做如下约定:


序号


页面元素


约定


1


按钮


未选中时:[按钮名称]

选中时:[按钮名称]


2


单选框


○ 选项


3


复选框


□ 选项


4


下拉框


[选项,…,] ▽


5


文本框


|________|


6


TextArea


|…………|


7


页签


未选中时:选项名称

选中时:选项名称


8


未选中链接


链接文字


9


选中链接


链接文字


10


说明信息


说明信息

4.1 组权限管理

4.1.1包含用户


组信息

组1

组11

组12

组…

组2

组21

组22

组…


所选择组:组1

[包含用户] [所属角色] [组权限] [总权限]

[修改]

用户名   姓名     手机号   最近登录时间 登录次数

阿蜜果 谢星星 13666666666 2007-10-8    66

sterning xxx    13555555555 2007-10-8    10

……

当用户选择“修改”按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该组所包含的用户。

4.1.2所属角色


组信息

组1

组11

组12

组…

组2

组21

组22

组…


所选择组:组1

[包含用户] [所属角色] [组权限] [总权限]

[修改]

角色ID   角色名称   角色描述

1          访客       --

2         初级用户    --

当用户选择“修改”按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该组所属的角色。

4.1.3组权限


组信息

组1

组11

组12

组…

组2

组21

组22

组…


所选择组:组1

[包含用户] [所属角色] [组权限] [总权限]

[保存] [取消]

4.1.4总权限


组信息

组1

组11

组12

组…

组2

组21

组22

组…


所选择组:组1

[包含用户] [所属角色] [组权限] [总权限]

[保存] [取消]

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改组的权限信息,点击“保存”按钮保存修改信息。

4.1.5组管理

在下图中,选中组1的时候,右键点击可弹出组的操作列表,包括添加、删除和修改按钮,从而完成在该组下添加子组,删除该组以及修改该组的功能。


组信息

组1

组11

组12

组…

组2

组21

组22

组…


所选择组:组1

[包含用户] [所属角色] [组权限] [总权限]

[修改]

用户名   姓名     手机号   最近登录时间 登录次数

阿蜜果 谢星星 13666666666 2007-10-8    66

sterning xxx    13555555555 2007-10-8    10

……

4.2 角色权限管理

4.2.1包含用户


角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…


所选择角色:角色1

[包含用户] [包含组] [角色权限]

[修改]

用户名   姓名     手机号   最近登录时间 登录次数

阿蜜果 谢星星 13666666666 2007-10-8    66

sterning xxx    13555555555 2007-10-8    10

……

当用户选择“修改”按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该角色所包含的用户。

4.2.2包含组


角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…


所选择角色:角色1

[包含用户] [包含组] [角色权限]

[修改]

组ID   组名称     组描述

1      xxx1       --

2       xxx2        --

……

当用户选择“修改”按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该角色所包含的组。

4.2.3角色权限


角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…


所选择角色:角色1

[包含用户] [包含组] [角色权限]

[保存] [取消]

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改角色的权限信息,点击“保存”按钮保存修改信息。

4.2.4管理角色

在下图中,选中组1的时候,右键点击可弹出组的操作列表,包括添加、删除和修改按钮,从而完成在该组下添加子组,删除该组以及修改该组的功能。


角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…


所选择角色:角色1

[包含用户] [包含组] [角色权限]

[修改]

用户名   姓名     手机号   最近登录时间 登录次数

阿蜜果 谢星星 13666666666 2007-10-8    66

sterning xxx    13555555555 2007-10-8    10

……

4.3 用户权限管理

4.3.1所属角色


用户权限信息

xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…


所选择用户:阿蜜果

[所属角色] [所属组] [用户权限] [总权限]

[修改]

角色ID   角色名称   角色描述

1          访客       --

2         初级用户    --

当用户选择“修改”按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的角色。

4.3.2所属组


用户信息

xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…


所选择用户:阿蜜果

[所属角色] [所属组] [用户权限] [总权限]

[修改]

组ID   组名称     组描述

1       组1         --

2       组2         --

当用户选择“修改”按钮时,弹出组的树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的组。

4.3.3用户权限


用户信息

xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…


所选择用户:阿蜜果

[所属角色] [所属组] [用户权限] [总权限]

[保存] [取消]

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击“保存”按钮保存修改信息。

4.3.4总权限


用户信息

xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…


所选择用户:阿蜜果

[所属角色] [所属组] [用户权限] [总权限]

[保存] [取消]

通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击“保存”按钮保存修改信息。

4.3.5用户管理

当选择了某用户时,点击右键,弹出菜单列表:修改、删除、取消,点击修改和删除按钮可以实现用户的删除和修改功能。

选择某个组织,例如下表中的“广州分公司”,弹出菜单列表:添加子组织、删除组织、修改组织、添加用户、取消,点击添加用户按钮可以实现用户的添加功能。


用户权限信息

xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…


所选择用户:阿蜜果

[所属角色] [所属组] [用户权限] [总权限]

[修改]

角色ID   角色名称   角色描述

1          访客       --

2         初级用户    --

4.3.6组织管理

选择某个组织,例如下表中的“广州分公司”,弹出菜单列表:添加子组织、删除组织、修改组织、添加用户、取消,点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。


用户权限信息

xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…


所选择用户:阿蜜果

[所属角色] [所属组] [用户权限] [总权限]

[修改]

角色ID   角色名称   角色描述

1          访客       --

2         初级用户    --

4.4 操作日志管理

4.4.1查询操作日志


操作名称:|________|  操作人:|________|

操作时间从 |________| 到 |________| [查询] [重置] [删除]

编号    操作名称    操作内容    操作人    操作时间

1        xx1         --        Amigo    2007-10-8

2        xx2         --        xxyy     2007-10-8

输入上图表单中的查询信息后,点击“查询”按钮,可查询出符合条件的信息。

4.4.2删除操作日志


操作名称:|________| 操作人:|________|

操作时间从 |________| 到 |________| [查询] [重置] [删除]

编号    操作名称    操作内容    操作人    操作时间

1        xx1       --           Amigo      2007-10-8

2        xx2       --           xxyy       2007-10-8

输入上图表单中的查询信息后,点击“查询”按钮,可查询出符合条件的信息。而后点击“删除”按钮,可删除符合查询条件的操作日志。

5.      数据结构设计

数据库设计的模型请参见《通用权限管理系统_数据库模型.pdm》。表的说明请参见《通用权限管理系统数据库设计说明书》。

5.1 设计原则

5.1.1命名的规范

数据库中表、主键、外键、索引的命名都以统一的规则,采用大小写敏感的形式,各种对象命名长度不要超过30个字符,这样便于应用系统适应不同的数据库平台。

5.1.2数据的一致性和完整性

为了保证数据库的一致性和完整性,往往通过表间关联的方式来尽可能的降低数据的冗余。表间关联是一种强制性措施,建立后,对父表(Parent Table)和子表(Child Table)的插入、更新、删除操作均要占用系统的开销。如果数据冗余低,数据的完整性容易得到保证,但增加了表间连接查询的操作,为了提高系统的响应时间,合理的数据冗余也是必要的。使用规则(Rule)和约束(Check)来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段,但是,不必要的规则和约束也会占用系统的不必要开销,需要注意的是,约束对数据的有效性验证要比规则快。所有这些,需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。

5.2 数据库环境说明

数据库:MySql5.0

设计库建模工具:PowerDesigner12.0

5.3 数据库命名规则

表名以T开头,外键以FK开头,索引以INDEX开头。

5.4 逻辑结构

pdm文件的名称为:《通用权限管理系统_数据库模型》。

5.5 物理存储

通过数据库建模工具PowerDesigner12可以将pdm导出为文本文件,将数据库脚本放入文本文件中保存。

5.6 数据备份和恢复

数据库需定期备份(每天备份一次),备份文件格式为backup_yyyyMMdd,数据库被破坏时,利用最新的备份文件进行恢复。

6.      系统出错处理设计

6.1 出错信息


错误分类


子项及其编码


错误名称


错误代码


备注


数据库错误


连接


连接超时


100001001

 

连接断开


100001002

 

数据库本身错误代码


数据库本身错误代码


100002+数据库错误代码

 

TCP连接错误


连接


连接超时


101001001

 

连接断开


101001002

 

其它TCP连接错误(socket自身错误代码)

 
101002+ socket错误代码

 

配置信息错误


未配置输入参数

 
102001

 

未配置输出参数

 
102002

 

组管理部分自定义错误

   
103001——103999

 

角色管理部分自定义错误

   
104001——104999

 

用户管理部分自定义错误

   
105001——105999

 

操作日志管理

   
106001——106999

 

6.2 补救措施

为了当某些故障发生时,对系统进行及时的补救,提供如下补救措施:

a.后备技术   定期对数据库信息进行备份(每天一次),当数据库因某种原因被破坏时,以最新的数据库脚本进行恢复;。

7.      系统安全设计

7.1 数据传输安全性设计

SSH可以通过将联机的封包加密的技术进行资料的传递; 使用SSH可以把传输的所有数据进行加密,即使有人截获到数据也无法得到有用的信息。同时数据经过压缩,大大地加快了传输的速度。通过SSH的使用,可以确保资料传输比较安全并且传输效率较高。

7.2 应用系统安全性设计

操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录,已备以后查看。只有授权用户才能登录系统,对于某个操作,需要具有相应权限才能进行操作。

7.3 数据存储安全性设计

对于用户的密码等敏感信息采用MD5进行加密。

原文地址:https://www.cnblogs.com/ningwuyu/p/12382208.html

时间: 2024-12-28 15:50:24

mysqsl--用户-角色-权限表的设计的相关文章

用户角色权限表

user_info.sql(用户表) DROP TABLE IF EXISTS `user_info`; CREATE TABLE `user_info` ( `uid` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(50) DEFAULT '' COMMENT '用户名', `password` varchar(256) DEFAULT NULL COMMENT '登录密码', `name` varchar(256) DEFAULT N

学习RBAC 用户·角色·权限·表

设计OA系统的用户-角色-权限分配

转载:http://www.cnblogs.com/jsping/archive/2013/01/23/2872972.html 设计OA系统的用户-角色-权限分配 一,前言  本文主要讲述在OA系统设计时用户——角色——权限的数据库设计,以便实现权限分配. 二,初步分析 用户通过UI登录系统时,把用户的用户名.密码传递给后台判断用户表中是否存在可用的用户信息,如果存在那么允许页面的跳转,并设置一些Session信息,当页面跳转时根据用户的Session信息获取用户的角色,进一步根据角色获取用户

java用户角色权限设计

实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个"非法用户"很可能就能通过浏览器轻易访问到B/S系统中的所有功能.因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的"非法用户"将会将他

RBAC用户角色权限设计

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,“超级管理员”.“版主”都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权限.要给某个用户授予这些权限,不需要直接将

java权限管理与用户角色权限设计

java权限管理与用户角色权限设计 实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能.因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将

RBAC用户角色权限设计方案

转自http://www.cnblogs.com/zwq194/archive/2011/03/07/1974821.html RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统

Asp.Net MVC+BootStrap+EF6.0实现简单的用户角色权限管理

这是本人第一次写,写的不好的地方还忘包含.写这个的主要原因是翔通过这个来学习下EF的CodeFirst模式,本来也想用AngularJs来玩玩的,但是自己只会普通的绑定,对指令这些不是很熟悉,所以就基本不用了.还有最主要的原因就是锻炼下自己的能力.好了其他就不多说了,下面来看下我对这个项目的整体概述吧: 目录: 目录我以后会在这边添加上去的 一.Asp.Net MVC+BootStrap+EF6.0实现简单的用户角色权限管理 基本设计 项目中使用到的工具: Visual Studio 2013,

扩展RBAC用户角色权限设计方案

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,“超级管理员”.“版主”都是角色.版主可管理版内的帖子.可管理版内的用户等,这些是权限.要给某个用户授予这些权限,不需要直接将