用户权限设计.docx
- 文档编号:8760979
- 上传时间:2023-05-14
- 格式:DOCX
- 页数:30
- 大小:271.81KB
用户权限设计.docx
《用户权限设计.docx》由会员分享,可在线阅读,更多相关《用户权限设计.docx(30页珍藏版)》请在冰点文库上搜索。
用户权限设计
用户权限设计(三)——通用数据权限管理系统设计【转】
分类:
软件技术2006-11-2111:
115312人阅读评论(0)收藏举报
通用数据权限管理系统设计
(一)
作者:
逸云
前言:
本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。
本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。
解释:
功能权限:
能做什么的问题,如增加销售订单;
数据权限:
能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单;
术语:
资源:
系统中的资源,主要是各种业务对象,如销售单、付款单等;
操作类型:
对资源可能的访问方法,如增加、删除、修改等;
功能:
对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等;
数据类型:
业务系统中常用的数据权限类型,如公司、部门、项目、个人等;
数据对象:
具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;
权限:
角色可使用的功能,分角色的功能权限和角色的数据权限;
角色:
特定权限的集合;
用户:
参与系统活动的主体,如人,系统等。
通用数据权限管理系统设计
(二)
方法说明:
在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。
本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。
本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。
如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。
这段话比较绕口,下面举个例子实际例子。
某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:
销售总监 -- 能察看所有销售部的销售订单;
北京销售经理 -- 只能察看北京销售部的所有销售订单;
上海销售经理 -- 只能察看上海销售部的所有销售订单;
广州销售经理 -- 只能察看广州销售部的所有销售订单;
上述角色的定义如下:
-------------------------------------------------------------------
角色名称 功能 数据类型 数据对象
-------------------------------------------------------------------
销售总监 察看销售订单
北京销售经理 察看销售订单 部门 北京
上海销售经理 察看销售订单 部门 上海
广州销售经理 察看销售订单 部门 广州
-------------------------------------------------------------------
上述定义中,销售总监只定义了功能权限,而没有定义数据权限,所以销售总监能够察看所有的销售订单;而其他几位销售经理分别定义了这一功能的数据权限,所以只能察看指定部门的销售订单。
在实际应用中,往往会出现部门分组,组长能够察看本组所有人员处理的销售订单的情况,以及某些情况下,某些人只能察看本人的销售订单的情况,这些特殊情况在上述的说明中无法解决,需要在设计和实现中进行处理。
北京销售代表 -- 只能察看北京销售部的本人的所有销售订单;
北京销售代表 察看销售订单 部门 北京
个人
通用数据权限管理系统设计(三)--数据库设计
我们先来看看传统的基于角色的权限管理系统,如下图所示,最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。
图一:
基于角色的数据库结构
为实现数据权限控制,在设计上对基于角色的权限管理进行扩充,如下图所示:
图二:
通用数据权限管理系统数据库设计
对比两张图,我们可以看到,他们之间的主要变化为:
1、 增加系统资源信息和操作类型信息,系统资源为树形结构、如销售模块、销售订单等;操作类型记录可能的操作,如增加、删除、修改、查看、查询等,系统功能是资源与操作类型的组合,对资源的操作就是系统功能。
2、 增加数据对象类型和数据对象两张表,数据对象类型记录系统中需要控制的对象类型,如部门、库房、员工、客户、供应商等;数据对象记录各对象类型的对象实例,如北京销售部、上海销售部、张三、李四等等。
(独立保存的好处后面会说到)
3、 增加系统资源与数据对象类型的关联表(多对多),本表为配置表,说明某种资源可能需要的控制点,如销售订单与部门类型的关联可能涉及到分部门分配权限;销售订单与客户的关联可能涉及到按客户分配权限等等。
4、 增加数据对象与角色权限的关联,这张表是真正最终实现数据权限管理的所在地。
通过这种设计,能够最小化地减少对原有权限系统的更改,并且可以很灵活地增加数据的控制点。
在产品化软件的设计中使用,能够灵活满足客户的需要。
用户权限设计(四)——基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展【转】
分类:
软件技术2006-11-2210:
413511人阅读评论(0)收藏举报
1 RBAC模型
访问控制是针对越权使用资源的防御措施。
基本目标是为了限制访问主体(用户、进程、服务等)对访问客体(文件、系统等)的访问权限,从而使计算机系统在合法范围内使用;决定用户能做什么,也决定代表一定用户利益的程序能做什么[1]。
企业环境中的访问控制策略一般有三种:
自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法(RBAC)。
其中,自主式太弱,强制式太强,二者工作量大,不便于管理[1]。
基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。
其显著的两大特征是:
1.减小授权管理的复杂性,降低管理开销;2.灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性。
NIST(TheNationalInstituteofStandardsandTechnology,美国国家标准与技术研究院)标准RBAC模型由4个部件模型组成,这4个部件模型分别是基本模型RBAC0(CoreRBAC)、角色分级模型RBAC1(HierarchalRBAC)、角色限制模型RBAC2(ConstraintRBAC)和统一模型RBAC3(CombinesRBAC)[1]。
RBAC0模型如图1所示。
a.RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。
在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素,权限被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的权限。
会话sessions是用户与激活的角色集合之间的映射。
RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
b.RBAC1引入角色间的继承关系,角色间的继承关系可分为一般继承关系和受限继承关系。
一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。
而受限继承关系则进一步要求角色继承关系是一个树结构。
c.RBAC2模型中添加了责任分离关系。
RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。
约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
d.RBAC3包含了RBAC1和RBAC2,既提供了角色间的继承关系,又提供了责任分离关系。
2核心对象模型设计
根据RBAC模型的权限设计思想,建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有:
用户(Users)、用户组(Group)、角色(Role)、目标(Objects)、访问模式(AccessMode)、操作(Operator)。
主要的关系有:
分配角色权限PA(PermissionAssignment)、分配用户角色UA(UsersAssignmen描述如下:
a.控制对象:
是系统所要保护的资源(Resource),可以被访问的对象。
资源的定义需要注意以下两个问题:
1.资源具有层次关系和包含关系。
例如,网页是资源,网页上的按钮、文本框等对象也是资源,是网页节点的子节点,如可以访问按钮,则必须能够访问页面。
2.这里提及的资源概念是指资源的类别(ResourceClass),不是某个特定资源的实例(ResourceInstance)。
资源的类别和资源的实例的区分,以及资源的粒度的细分,有利于确定权限管理系统和应用系统之间的管理边界,权限管理系统需要对于资源的类别进行权限管理,而应用系统需要对特定资源的实例进行权限管理。
两者的区分主要是基于以下两点考虑:
一方面,资源实例的权限常具有资源的相关性。
即根据资源实例和访问资源的主体之间的关联关系,才可能进行资源的实例权限判断。
例如,在管理信息系统中,需要按照营业区域划分不同部门的客户,A区和B区都具有修改客户资料这一受控的资源,这里“客户档案资料”是属于资源的类别的范畴。
如果规定A区只能修改A区管理的客户资料,就必须要区分出资料的归属,这里的资源是属于资源实例的范畴。
客户档案(资源)本身应该有其使用者的信息(客户资料可能就含有营业区域这一属性),才能区分特定资源的实例操作,可以修改属于自己管辖的信息内容。
另一方面,资源的实例权限常具有相当大的业务逻辑相关性。
对不同的业务逻辑,常常意味着完全不同的权限判定原则和策略。
b.权限:
对受保护的资源操作的访问许可(AccessPermission),是绑定在特定的资源实例上的。
对应地,访问策略(AccessStrategy)和资源类别相关,不同的资源类别可能采用不同的访问模式(AccessMode)。
例如,页面具有能打开、不能打开的访问模式,按钮具有可用、不可用的访问模式,文本编辑框具有可编辑、不可编辑的访问模式。
同一资源的访问策略可能存在排斥和包含关系。
例如,某个数据集的可修改访问模式就包含了可查询访问模式。
c.用户:
是权限的拥有者或主体。
用户和权限实现分离,通过授权管理进行绑定。
d.用户组:
一组用户的集合。
在业务逻辑的判断中,可以实现基于个人身份或组的身份进行判断。
系统弱化了用户组的概念,主要实现用户(个人的身份)的方式。
e.角色:
权限分配的单位与载体。
角色通过继承关系支持分级的权限实现。
例如,科长角色同时具有科长角色、科内不同业务人员角色。
f.操作:
完成资源的类别和访问策略之间的绑定。
g.分配角色权限PA:
实现操作和角色之间的关联关系映射。
h.分配用户角色UA:
实现用户和角色之间的关联关系映射。
该对象模型最终将访问控制模型转化为访问矩阵形式。
访问矩阵中的行对应于用户,列对应于操作,每个矩阵元素规定了相应的角色,对应于相应的目标被准予的访问许可、实施行为。
按访问矩阵中的行看,是访问能力表CL(AccessCapabilities)的内容;按访问矩阵中的列看,是访问控制表ACL(AccessControlLists)的内容。
数据模型图如下:
用户权限设计
(二)——用户认证管理设计方案【转】
用户认证管理设计方案
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 一般工作人员 工作人员
……
l 用户角色(User_Role):
UserRoleID UserID RoleID UserRoleNote
1 1 01 用户“张三”被分配到角色“系统管理员”
2 2 02 用户“李四”被分配到角色“监控人员”
3 2 03 用户“李四”被分配到角色“调度人员”
……
从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。
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,@UserRoleIDoutput),GetRolePermission(@RoleID,@Role-
-PermissinIDoutput)获得用户对模块的使用权限。
1.7用户认证实现
当用户通过验证后,由系统自动生成一个128位的TicketID保存到用户数据库表中,建立存储过程Login(@UserID,@UserPwd,@TicketIDoutput)进行用户认证,认证通过得到一个TicketID,否则TicketID为null。
其流程图如下:
图1Login流程图
得到TicketID后,客户端在调用服务端方法时传递TicketID,通过存储过程JudgeTicketPermission(@TicketID,@PermissionID)判断TicketID对应的用户所具有的权限,并根据其权限进行方法调用。
当用户退出系统时,建立存储过程Logout(@UserID)来退出系统。
当用户异常退出系统时,根据最后的登陆时间(LastSignTime)确定用户的TickeID,建立存储过程ExceptionLogout(@UserID,@LastSignTime)处理用户的异常退出。
图2Logout流程图
WebService可以采用SoapHeader中写入TicketID来使得TicketID从客户端传递给服务端。
.NetRemoting可以采用CallContext类来实现TicketID从客户端传递给服务端。
2数据库设计
2.1数据库表
图3数据库关系图
2.2数据库表说明
2.2.1用户表(Static_User)
Static_User
Static_User字段名
详细解释
类型
备注
UserID
路线编号
varchar(20)
PK
UserName
用户名称
varchar(20)
UserP
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 用户权限 设计