1 设计思路
为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。
1.1 用户
用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。
用户通常具有以下属性:
编号,在系统中唯一。
ü 名称,在系统中唯一。
ü 用户口令。
ü 注释,描述用户或角色的信息。
1.2 角色
角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性:
ü 编号,在系统中唯一。
ü 名称,在系统中唯一。
ü 注释,描述角色信息
1.3 权限
权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、
修改和删除功能,通常具有以下属性:
ü 编号,在系统中唯一。
ü 名称,在系统中唯一。
ü 注释,描述权限信息
1.4 用户与角色的关系
一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如 l 用户(User):
UserID UserName UserPwd
1 张三 xxxxxx
2 李四 xxxxxx
??
l 角色(Role):
RoleID RoleName RoleNote
01 系统管理员 监控系统维护管理员
02 监控人员 在线监控人员
03 调度人员 调度工作人员
04 一般工作人员 工作人员 ??
从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。
1.5 权限与角色的关系
一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如: l 角色(Role):
RoleID RoleName RoleNote
01 系统管理员 监控系统维护管理员
02 监控人员 在线监控人员
03 调度人员 调度工作人员
04 一般工作人员 工作人员 ??
l 权限(Permission):
PermissionID PermissionName PermissionNote
0001 增加监控 允许增加监控对象
0002 修改监控 允许修改监控对象
0003 删除监控 允许删除监控对象
0004 察看监控信息 允许察看监控对象 ??
l 角色权限(Role_Permission):
RolePermissionID RoleID PermissionID RolePermissionNote
1 01 0001 角色“系统管理员”具有权限“增加监控”
2 01 0002 角色“系统管理员”具有权限“修改监控”
3 01 0003 角色“系统管理员”具有权限“删除监控”
4 01 0004 角色“系统管理员”具有权限“察看监控”
5 02 0001 角色“监控人员”具有权限“增加监控”
6 02 0004 角色“监控人员”具有权限“察看监控”
??
由以上例子中的角色权限关系可以看出,角色权限可以建立角色和权限之
间的对应关系。
1.6 建立用户权限
用户权限系统的核心由以下三部分构成:创造权限、分配权限和使用权限。 第一步由Creator创造权限(Permission),Creator在设计和实现系统时会划分。利用存储过程CreatePermissionInfo(@PermissionName,@PermissionNote)创建权限信息,指定系统模块具有哪些权限。
第二步由系统管理员(Administrator)创建用户和角色,并且指定用户角色(User-Role)和角色权限(Role-Permission)的关联关系。
1) 具有创建用户、修改用户和删除用户的功能: Administrator
l 存储过程CreateUserInfo(@UserName,@UserPwd)创建用户信息;
l 存储过程ModifyUserInfo(@UserName,@UserPwd)修改用户信息;
l 存储过程DeleteUserInfo(@UserID)删除用户信息;
2) 具有创建角色和删除角色
的功能: Administrator
l 存储过程CreateRoleInfo(@RoleName,@RoleNote)创建角色信息;
l 存储过程DeleteRoleInfo(@RoleID)删除角色信息;
3)Administrator具有建立用户和角色、角色和权限的关联关系功能:
l 存储过程GrantUserRole(@UserID,@RoleID,@UserRoleNote)建立用户和角色的关联关系; l 存储过程DeleteUserRole(@UserRoleID)删除用户和角色的关联关系;
l 存储过程GrantRolePermission(@RoleID,@PermissionID,@RolePermissionNote)建立角色和权限的关联关系;
l 存储过程DeleteRolePermission(@RolePermissionID)删除角色和权限的
关联关系;
第三步用户(User)使用Administrator分配给的权限去使用各个系统模块。利用存储过程GetUserRole(@UserID, @UserRoleID output),GetRolePermission
(@RoleID,@Role- -PermissinID output)获得用户对模块的使用权限。
1.7 用户认证实现
当用户通过验证后,由系统自动生成一个128位的TicketID保存到用户数据库表中,建立存储过程Login(@UserID,@UserPwd, @TicketID output)进行用户认证,认证通过得到一个TicketID,否则TicketID为null。其流程图如下:
图1 Login流程图
得到TicketID后,客户端在调用服务端方法时传递TicketID,通过存储过程
JudgeTicketPermission(@TicketID,@PermissionID)判断TicketID对应的用户所具有的权限,并根据其权限进行方法调用。
当用户退出系统时,建立存储过程Logout(@UserID)来退出系统。当用户异常退出系统时,根据最后的登陆时间(LastSignTime)确定用户的TickeID,建立存储过程ExceptionLogout(@UserID,@LastSignTime)处理用户的异常退出。
图2 Logout流程图
WebService可以采用SoapHeader中写入TicketID来使得TicketID从客户端传递给服务端。.Net Remoting可以采用CallContext类来实现TicketID从客户端传递给服务端。
2 数据库设计 2.1 数据库表
图3 数据库关系图
2.2 数据库表说明
2.2.1 用户表(Static_User) Static_User Static_User
字段名 详细解释 类型 备注
UserID 路线编号 varchar(20) PK
UserName 用户名称 varchar(20)
UserPwd 用户密码 varchar(20)
LastSignTime 最后登陆时间 datatime
SignState 用户登陆状态标记 int
TickeID 验证票记录编号 varchar(128)
2.2.2 角色表(Static_Role)
Static_Role Static_User
字段名 详细解释 类型 备注
RoleID 角色编号 varchar(20) PK
RoleName 角色名称 varchar(20)
RoleNote 角色信息描述 varchar(20)
2.2.3 用户-角色表(Static_User_Role)
Static_User_Role Static_User
字段名 详细解释 类型 备注
UserRoleID 用户角色编号 varchar(20) PK
UserID 用户编号 varchar(20) FK
RoleID 角色编号 varchar(20) FK
UserRoleNote 用户角色信息描述 varchar(20)
2.2.4 权限表(Static_Permission)
Static_Permission Static_User
字段名 详细解释 类型 备注
PermissionID 编号 varchar(20) PK
PermissionName 权限名称 varchar(20)
PermissionNote 全息信息描述 varchar(20)
2.2.5 角色-权限表(Static_Role_Permission)
Static_Role_Permission Static_User
字段名 详细解释 类型 备注
RolePermissionID 角色权限编号 varchar(20) PK
RoleID 角色编号 varchar(20) FK
PermissionID 权限编号 varchar(20) FK
RolePermissionNote 角色权限信息描述 varchar(20)
用“位”来存储、修改用户权限的方法
以前我用记录方式,如A用户有3个模块权限,则A有三条记录
看到别人的程序里有这种方法,感觉不错,给大家看看有没有优点可取。
用户权限用一个int字段表示,可以放32位,
如果有第1,3,4模块的权限则,值为1 4 8=13
___________________
_userId_____userQx___
A?????????????? |???? 13
_________|___________
增加权限具体实现
如
增加第四个模块的权限,4的二进制值8
update qxUser set userQx = userQx|8 where userId='A'
删除第四个模块的权限
update qxUser set userQx = userQx&~8 where userId='A'
如果删除第四个模块,则不加条件就可以了
update qxUser set userQx = userQx&~8
以上在SqlServer2000企业版通过。
欢迎大家讨论,有更好的方法大家共享呀~~~
在Java 里
34&2 !=0就行了。
通过二,三两步的理解,相信这篇文章就不会生涩了!~
首先上文权限设计拙见(1)中只是想记录下自己权限设计上的一点看法,以及将自己日常最常用的权限解决方案记录下来以供日后回顾,没想到有朋友关注此类的设计,那就只能先把代码拿出来献丑了,抛砖引玉,大家共同探讨学习
接着上文来说,上文所讨论的权限设计是一条思路,但既然是web应用,少不了数据库的支持,本文我们来讨论一下数据库的设计。(以下想法及思路仅仅代表本人拙见)
说到权限的数据库设计,必先理清权限中几种实体及其关系,此部分想必有过设计权限
经验的同仁都知道怎么设计了,网上摆渡一下也是一裤衩子一裤衩子的,我们就在最平凡直观的数据库关系的基础上来建立权限。下面是我的几个表(所有的表都带有一个pk_id,作为表的自动生成的唯一主键):
用户表(T_UserInfo):
1/*==============================================================*/
2/* Table: T_UserInfo */
3/*==============================================================*/
4create table T_UserInfo
5(
6 pk_id NUMBER not null,
7 name VARCHAR2(20),
8 sex BOOLEAN,
9 age int,
10 emp_num NUMBER,
11 polity int,
12 unit VARCHAR2(50),
13 department VARCHAR2(20),
14 specialty int,
15 position VARCHAR2(10),
16 offtel VARCHAR2(20),
17 famtel VARCHAR2(20),
18 post_state VARCHAR2(10),
19 remark VARCHAR2(100),
20 constraint PK_T_USERINFO primary key (pk_id)
21);
实战经验:用户表就不多说了,都是一些常用字段,年龄、电话、职位等,建议大家建立一个通用一些,字段多一些的一个用户表,便于以后扩展,以后如果有特殊需求,不用扩这个基本表,可以通过主外键关系来新建一个表,用于扩充字段
角色表(T_RoleInfo):
1/*==============================================================*/
2/* Table: T_RoleInfo */
3/*==============================================================*/
4create table T_RoleInfo
5(
6 pk_id number not null,
7 role_name VARCHAR2(20),
8 role_desc VARCHAR2(100),
9 parent_role_id NUMBER,
10 constraint PK_T_ROLEINFO primary key (pk_id)
11);
角色表中需要说明的就一个parent_role_id父角色id,此字段用来扩展角色的继承关系。
资源表(T_ResourceInfo):
1/*==============================================================*/
2/* Table: T_ResourceInfo */
3/*==============================================================*/
4create table T_ResourceInfo
5(
6 pk_id NUMBER not null,
7 module_name VARCHAR2(20),
8 module_code VARCHAR2(10),
9 module_desc VARCHAR2(100),
10 privilege_name VARCHAR2(10),
11 privilege_code CHAR,
12 privilege_desc VARCHAR2(100),
13 constraint PK_T_RESOURCEINFO primary key (pk_id)
14);
这个表需要说明的就比较多了,首先该表用来记录资源与资源权限,我这边所谓的资源就是实体,就是数据库表,角色需要对应到资源,有些角色对该资源有权限,有些角色则对该资源无权限,角色可对此资源操作的权限也不同。说白了,就是不同的角色对不同的数据库表的操作权限不同。因此我们这里的资源就是数据库表。
module_name:资源名;
module_code:资源代码(存放数据库表名);
privilege_name:权限名;
privilege_code:权限代码(代表权限的code,也就是我们上文所说的权值)
例如角色a对数据库表T_UserInfo有添加与删除的权限则该表应该按照如下配置: module_name:人员信息;
module_code:T_UserInfo privilege_name:添加与删除
privilege_code:6
这里我们假设的是2的0次方为添加权限,2的1次方为添加权限,2的2次方为删除权限,2的3次方为更新权限,则拥有添加与删除权限就应该为2的1次方+2 的2次方=6,其实2的几次方代表什么含义我们可以另外开个数据库表来配置(或者xml文件)此处我们忽略这些步骤。当然如果你的权限较多,譬如你还希望 a这个角色对人员信息表有上传得权限,我们可以将将上传权限定义为2的4次方,16,16的16进制数为10,记录在数据库里的形式应该为0x10如果a 角色拥有添加、删除、更新、上传权限,则a的权值应该为2的1次方+2的2次方+2的3次方+2的4次方=30,用16进制来表示就应该为0x1E,记录 16进制数据,你不用担心位数不够。 剩余的就是几张关系表了:
人员角色关系表(T_R_User_Role):
1/*==============================================================*/
2/* Table: T_R_user_role */
3/*==============================================================*/
4create table T_R_user_role
5(
6 pk_id NUMBER not null,
7 user_id NUMBER,
8 role_id NUMBER,
9 constraint PK_T_R_USER_ROLE primary key (pk_id)
10);
角色资源关系表(T_R_Role_Resource)
1/*==============================================================*/
2/* Table: T_R_role_resource */
3/*==============================================================*/
4create table T_R_role_resource
5(
6 pk_id NUMBER not null,
7 role_id NUMBER,
8 res_id NUMBER,
9 constraint PK_T_R_ROLE_RESOURCE primary key (pk_id)
10);
当然如果你不怕麻烦,可以添加进去组(group)、系统(system)、组织(organization),建立起一套属于你自己的完整的权限解决方案,作为系统无关的模块去套用到每个你所架构的应用中去,那是一件极爽的事情。