- 浏览: 310454 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
fanlei77:
很有用,谢谢
git branch -
han1051:
123123
Spring框架下PropertyPlaceholderConfigurer类 -
wangbing9577:
言简意赅。
代理模式 适配器模式 与 外观模式 区别 比较 特点 -
azheng270:
用户和权限为什么会有直接连线
通用权限管理系统设计篇(一) -
cectsky:
nice,i know ,thank you ~
Spring框架下PropertyPlaceholderConfigurer类
权限系统(1)--基本模式
在系统中发生的事情,抽象的说都是某个主体(subject)在某个资源(resource)上执行了某个操作(operation)。
subject --[operation]--> resource
所谓权限管理,就是在这条信息传递路径中加上一些限制性控制。
主体试图去做的 limited by 系统允许主体去做的 = 主体实际做的。
可以看到,权限控制基本对应于filter模式。subject试图去做的事情应该由业务逻辑决定,因而应该编码在业务系统中。
先考虑最粗粒度的控制策略,控制点加在subject处,即无论从事何种操作,针对何种资源,我们首先需要确认subject是受控的。只有通过认证的用户才能使用系统功能,这就是authentication。boolean isAllowed subject)
稍微复杂一些,控制可以施加在subject和operation的边界处(此时并不知道具体进行何种操作),称为模块访问控制,即只有某些用户才能访问特定模块。isAllowed(subject, operation set)
第三级控制直接施加在operation上,即操作访问控制。operation知道resource和subject(但它尚没有关于resource的细节知识),我们能够采取的权限机制是bool isAllowed(subject, operation, resource), 返回true允许操作,返回false则不允许操作。
最简单的情况下,subject与resource之间的访问控制关系是静态的,可以直接写成一个权限控制矩阵
for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1
isAllowed(subjectA, resourceA)恒等于true
如果多个operation的权限控制都可以通过这种方式来表示,则多个权限控制矩阵可以叠加在一起
for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11
当subject和resource的种类很多时,权限控制矩阵急剧膨胀,它的条目数是N*M。很显然,我们需要进行矩阵分解。这也是最基本的控制手段之一: 在系统中增加一个瓶颈,或者说寻找到隐含的结构。
subject_resource = subject_role * role_resource
这样系统权限配置条目的数量为 N*R + R*M, 如果R的数目远小于subject和resource,则实现简化。这称为RBAC(role based access control),它的一个额外好处是权限系统的部分描述可以独立于subject存在,即在系统中没有任何用户的时候,通过角色仍然可以表达部分权限信息。可以说角色是subject在权限系统中的代理(分解)。
有时候引入一个瓶颈还不过瘾,有人引入组的概念,与role串联,
subject_resource = subject_group_role * role_resource
或着group与role并联,
subject_resource = subject_group * group_resource
与role稍有不同,一般情况下group的业务含义更加明显,可能对应于组织结构等。将组织机构明确引入权限体系,有的时候比较方便,但对于权限系统自身的稳定性而言,未见得有什么太大的好处。并联模式有些多余,串联模式又过于复杂,细节调整困难,特别是多条控制路径造成的冲突情况。一般情况下,我不提倡将group引入权限控制中。
比操作控制更加深入的控制就是数据控制了,此时需要对于resource的比较全面的知识。虽然表面上,仍然是
boolean isAllowed(subject, operation, resource),但控制函数需要知道resource的细节。例如行级控制(row-level)或者列级控制(column-level)的实现。因为我们一般情况下不可能将每一个条目都建模为独立的resource,而只能是存在一个整体描述,例如所有密级为绝密的文档。在witrix平台中,数据控制主要通过数据源的filter来实现,因为查询条件(数据的定位条件)已经被对象化为Query类,所以我们可以在合适的地方自由的追加权限控制条件。
以上的讨论中,权限控制都是根据某些静态描述信息来进行的,但现实世界是多变的。最简单的,当subject从事不同业务时,对应于同一组资源,也可能对应的权限控制并不同(在witrix平台中,对应于IDataSource的模式切换)。更复杂一些, 在不同的时刻, 我们需要根据其他附加信息来作出是否允许操作的判断, 即此时我们权限设置的不仅仅是一些静态的描述信息, 而是一个完整的控制函数, 这就是所谓的工作流权限控制,一种动态权限控制.
权限系统(2)--operation
权限控制可以看作一个filter模式的应用, 这也符合AOP思想的应用条件。在一个简化的图象中,我们只需要将一个判别函数 isAllowed(subject, operation, resource)插入到所有安全敏感的函数调用之前就可以了。虽然概念上很完美,具体实现的时候仍然有一些细节上的问题。基本的困难在于很难在最细的粒度上指定权限控制规则(连续的?动态的?可扩展的?),因而我们只能在一些关键处指定权限规则,或者设置一些整体性的权限策略,然后通过特定的推理来推导出细粒度的权限规则,这就引出结构的问题。我们需要能够对权限控制策略进行有效的描述(控制策略的结构),并且决定如何与程序结构相结合。subject, operation和resource为了支持推理,都可能需要分化出复杂的结构,而不再是简单的原子性的概念。而在与程序结构结合这一方面,虽然AOP使得我们可以扩展任何函数,但这种扩展需要依赖于cutpoint处所能得到的信息,因而权限控制的有效实施也非常依赖于功能函数本身良好的设计。有的时候因为需要对结构有过于明确的假定,权限控制的实现不得不牺牲一定的通用性。
下面我们将分别讨论一下operation, subject和resource的结构分解的问题。首先是operation。
说到推理结构,让人最先想起的就是决策树,树形结构,在面向对象语言中可以对应于继承。金字塔式的树形结构也正是在现实世界中我们应用最多的控制结构。通过层层分解,operation的结构可以组织为一棵树,
应用程序 ==> 各个子系统 ==> 每个子系统的功能模块 ==> 子功能模块
==> 每个模块的功能点(具有明确的业务含义) ==> 每个功能点对应的访问函数(程序实现中的结构)
一个常见的需求是根据权限配置决定系统菜单树的显示,一般控制用户只能看到自己有权操作的功能模块和功能按钮。这种需求的解决方法是非常直接的。首先,在后台建立子系统到功能模块,功能模块到功能点以及功能点到实现函数之间的映射表(如果程序组织具有严格规范,这甚至可以通过自动搜集得到)。然后,在权限配置时建立用户与功能点之间的关联。此时,通过一个视图,我们就可以搜集到用户对哪些功能模块具有访问权限的信息。
为了控制菜单树的显示,witrix平台中的SiteMap采用如下策略:
1. 如果用户对某个子功能具有操作权限,则所有父菜单项都缺省可用
2. 如果用户对某个功能具有操作权限,并且标记为cascade,则所有子菜单项都自动缺省可用
3. 如果明确指定功能不可用,则该菜单及子菜单都强制不可用
4. 如果明确指定功能对所有人可用,则不验证权限,所有子菜单自动缺省可用
4. 强制设定覆盖缺省值
5. 不可用的菜单缺省不可见
6. 明确标记为可见的菜单即使不可用也可见
7. 父菜单可见子菜单才可见
我们通过预计算来综合考虑这些相互影响的控制策略。尽量将推导运算预先完成也是解决性能问题的不二法门。
在witrix平台中,每一次网络访问的url都符合jsplet框架所要求的对象调用格式,需要指定objectName和objectEvent参数,这就对应于功能点的访问函数。访问控制点集中在objectManager并且访问格式是标准的。使用spring等AOP方式实现细粒度访问控制,困难似乎在于不容易引入外部配置信息(例如功能点信息等),而且控制点所对应的对象函数格式也不统一,因而多数需要在细粒度上一一指定。
权限系统(3)-- subject
权限控制中,subject可能不会简单的对应于userId, 而是包含一系列的security token或certificate, 例如用户登陆地址,登陆时间等。一般情况下,这些信息在权限系统中的使用都是很直接的,不会造成什么问题。
subject域中最重要的结构是user和role的分离,可以在不存在user的情况下,为role指定权限。有人进一步定义了userGroup的概念,可以为userGroup指定role,而user从其所属的group继承role的设置。一般情况下,我不提倡在权限系统中引入userGroup的概念。这其中最重要的原因就是它会造成多条权限信息传递途径,从而产生一种路径依赖, 并可能出现信息冲突的情况。一般user与group的关联具有明确的业务含义,因而不能随意取消。如果我们希望对user拥有的权限进行细调,除去user从group继承的某个不应该拥有的权限,解决的方法很有可能是所谓的负权限,即某个权限条目描述的是不能做某某事。负权限会造成各个权限设置之间的互相影响,造成必须尝试所有权限规则才能作出判断的困境,引出对额外的消歧策略的需求,这些都极大的限制了系统的可扩展性。在允许负权限的环境中,管理员将无法直接断定某个权限设置的最终影响,他必须在头脑中完成所有的权限运算之后才能理解某用户最终拥有的实际权限,如果发现权限设置冲突,管理员可能需要多次尝试才能找到合适方案。这种配置时的推理需求可能会增加配置管理的难度,造成微妙的安全漏洞,而且负权限导致的全局关联也降低了权限系统的稳定性。我更倾向于将group作为权限设置时的一种辅助标记手段,系统中只记录用户最终拥有的角色,即相当于记录用户通过group拥有权限的推导完成的结果, 如果需要权限细调,我们直接在用户拥有的角色列表上直接进行。当然,如果实现的复杂一些,权限系统对外暴露的接口仍然可以模拟为能够指定userGroup的权限。
推理在面向对象语言中最明显的表现是继承,所以有些人将subject域中的推理直接等价于role之间的继承问题,这未必是最好的选择。继承可以形成非常复杂的推理关系,但是可能过于复杂了(特别是直接使用sql语句无法实现树形推理查询)。按照级列理论,从不相关发展到下一阶段是出现简单的序关系,即我们可以说subject出现级别上的差异,高级别subject将自动具有低级别的权限。一种选择是定义roleRank,规定高级别role自动具有低级别role的权限,但考虑到user与role的两分结构,我们也可以同时定义userRank和roleRank,规定高级别user自动具有低级别的role,而role之间不具有推理关系。在面向对象领域中,我们已经证实了完全采用继承来组织对象关系会导致系统的不稳定,所以我倾向于第二种选择,即将role看作某种类似于interface的东西,一种权限的切片。为了进一步限制这种推导关系,我们可以定义所谓的安全域的概念. security domain, 规定推导只能在一定的域中才能进行。
select user.userId, role.roleId
from user, role
where user.userRank > role.roleRank
and user.domain = role.domain
将权限控制一般需要施加在最细的粒度上,这在复杂的系统中可能过于理想化了。复杂的情况下我们需要进行局部化设计,即进行某些敏感操作之前进行一系列复杂的权限校验工作。当完成这些工作之后,进入某个security zone, 在其中进行操作就不再需要校验了。
总的来说,权限系统采用非常复杂的结构效果未必理想。很多时候只是个管理模式的问题,应该尽量通过重新设计权限空间的结构来加以规避。不过在一些非常复杂的权限控制环境下,也许简单的描述信息确实很难有效的表达权限策略(虽然我从未遇到过),此时尝试一下规则引擎可能比在权限系统中强行塞入越来越多的约束要好的多
权限系统(4)--resource
权限管理中进行数据访问控制,其基本模式如下
operation target = selector(resource)
selector = user selector + auth filter
这里需要对resource的结构,以及选择算子的显式建模。selector必须允许权限系统追加filter,例如
IDataSource包中所使用的Query对象。
sql语言的表达能力有限, 作为选择算子来使用有时需要resource作一些结构上的调整,增加一些冗余的字段。例如表达一段时间内的利率,我们需要使用from_date和to_date两个字段来进行描述,其中to_date的值与下一条记录的from_date相同。
value from_date to_date
0.01 2003-01-01 2003-05-01
0.012 2003-05-01 2004-01-01
如果表达一条航线中的多个阶段,我们可能会在每条记录中增加起始站和终点站两个字段。
更重要的一个常见需求是树形结构在关系数据库中的表达。为了能够直接操纵一个分支下的所有记录,在层次固定的情况下,我们可能会增加多个分类字段,例如数据仓库中的层次维度。在层次数目不确定的情况下,我们将不得不使用层次码或者类似于url的其他方案,通过layer_code like '01.01.%' 之类的语句实现分支选择。为了限制选择的深度,我们可能还需要layer_level字段。基于层次码和层次数,我们可以建立多种选择算子,例如包含所有直接子节点,包含自身及所有父节点等等。
http://www.dbazine.com/oracle/or-articles/tropashko4
权限系统(5)--动态性
动态权限最简单的一个表现是时限性,subject只在某个时间段内具有某种权限。这只需要在user和role的映射中,或者role自身的属性中增加startTime和expireTime即可。
更复杂的动态性一般与流程控制相关,此时权限控制应该由工作流系统完成,而不是在数据上增加越来越多的权限标记。在witrix平台中,使用tpl模板技术来定制权限设置。
http://canonical.blogdriver.com/canonical/658364.html
对象模型中包含的基本元素主要有:用户(Users)、用户组(Group)、角色(Role)、目标(Objects)、访问模式(Access Mode)、操作(Operator)。主要的关系有:分配角色权限PA(Permission Assignment)、分配用户角色UA(Users Assignmen描述如下:
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1353322
发表评论
-
性能监控与性能问题定位之:Java篇
2012-04-09 15:50 1115http://hi.baidu.com/higkoo/ ... -
BeanUtils.copyProperties 日期转字符 日期转Long
2012-03-15 11:05 2433建立自己的日期转换类 import org.apache.c ... -
java 正则
2011-11-18 13:27 797http://edu.yesky.com/edupxpt/18 ... -
apache common 工具
2011-11-03 16:24 1280common-lang (2.1) ... -
git branch
2011-10-26 16:04 1176http://f2e.us/wiki/git-branch ... -
TortoiseSVN svn:external 设置外部svn目录的属性
2011-02-17 14:57 6045项目开发时,各个人员之间都会使用公共项目中的文件。可 ... -
synergy quicksynergy 共享ubuntu 和 windows 7
2011-01-21 19:27 26721. 在windows 7 下 安装 synergy 2. ... -
浅析VO、DTO、DO、PO的概念、区别和用处
2010-10-18 16:03 1233概念: VO ( View Obje ... -
详细解析Java中抽象类和接口的区别
2010-10-12 15:25 941抽象类和接口 抽象类仅提供一个类的部分实现 ... -
文件操作
2010-09-25 20:56 997File File 类 只操作文件,不对文件中的内容进行操作 ... -
中文乱码问题解决,过滤器配置,get post提交乱码,filter,struts乱码,jsp乱码
2010-09-14 15:19 1220Xml代码 <filter> ... -
PO/VO/DAO/BO/POJO是什么(JAVA几种对象的解释)
2010-08-31 00:17 1452java的几种对象(PO,VO,DAO,B ... -
svn 中tag branch trunk 的用法
2010-05-19 15:54 2050在SVN中Branch/tag在一个功能选项中,在使用中也往往 ... -
interview
2010-05-04 09:44 0以下题有些经过测试,修改之后,大多能运行。 1.现在输入 ... -
Sting字符串交集并集差集
2010-04-29 13:31 0package com.thomas.test; imp ... -
jsp的url中文参数解决办法
2009-06-23 18:38 10331.页面头部添加 <%@ page contentTy ... -
getAttribute和getParameter的区别
2008-07-18 10:00 1189getAttribute和getParameter的区别 JS ... -
JSP编程进度条设计
2008-07-14 10:42 1044许多Web应用、企业应用涉及到长时间的操作,例如复杂的数据库 ... -
[zt]JDBC DAO设计
2008-07-08 13:48 1391Connection的含义 Connection表示了一 ... -
Linux下内存释放问题相关知识
2008-07-03 15:20 1391细心的朋友会注意到,当 ...
相关推荐
总之,基于角色的用户权限系统设计是现代企业信息系统中不可或缺的一部分,它有效地实现了权限管理和安全性控制。通过对角色、用户和权限的合理配置,可以构建出高效且安全的业务操作环境。在实际应用中,开发者需要...
权限系统设计是软件开发中的关键组成部分,主要用于控制不同用户对系统资源的访问和操作。本文主要探讨基于用户、角色、权限的设计思路,并提供一种实现方案。 首先,理解基本概念: 1. **权限**:权限定义了用户...
通用权限系统设计的难点在于如何满足不同系统对权限需求的多样性,同时又保持设计的灵活性和扩展性。 设计目标包括创建一个灵活、通用且方便的权限管理系统。系统中的资源分为静态资源和动态资源两类。静态资源主要...
权限系统设计思路 权限系统是一个非常重要的安全机制,在现代企业中扮演着至关重要的角色。权限系统的设计主要是为了限制用户的访问范围,防止未经授权的访问和操作。下面是权限系统设计思路的详细介绍: 一、权限...
本文档作为“通用权限系统设计说明书”,将深入探讨该系统的设计理念、核心组件以及实现的细节,以期为企业提供一个高效、安全、易于管理的权限解决方案。 首先,我们明确通用权限系统设计的核心目标:确保不同职责...
权限系统的核心由以下三部分构成:1.创造权限,2.分配权限,3.使用权限,然后,系统各部分的主要参与者对照如下:1.创造权限 - Creator创造,2.分配权限 - Administrator 分配,3.使用权限 - User:
权限系统设计是软件开发中一个关键的组成部分,用于确保用户只能访问他们被授权的数据和功能。以下是基于给定文件内容的详细阐述: 1. **基于角色的访问控制(RBAC - Role-Based Access Control)** 这是最常见的...
后台权限系统设计是软件开发中的重要组成部分,尤其在企业级应用和管理信息系统中起到关键作用。权限系统的主要目标是确保用户只能访问他们被授权的操作和数据,从而保护系统的安全性和完整性。以下是对后台权限系统...
【权限管理系统设计方案】是关于如何构建一个有效管理用户权限的系统的详细文档。权限设计的核心在于理解用户、组、角色和权限这四个基本概念及其相互关系。 1. **权限设计概念** - **权限资源**:权限资源是系统...
本文档将深入探讨2022年版的全网最全权限系统设计方案,通过图解的形式,揭示权限系统设计的奥秘。 首先,我们要认识到权限管理的必要性和作用。权限管理不仅仅是一系列访问控制的规则,它是公司数据安全的基石。在...
本项目是基于SpringBoot和Vue3的renren-security权限系统设计源码,包含511个文件,其中主要包含253个java源代码文件,49个vue前端文件,33个svg图片文件等。系统采用了SpringBoot、MyBatis-Plus、Shiro、Vue3、...
#### 系统设计原则 - **安全性**:确保系统的安全性是首要考虑的因素,需要采取多种措施防止未授权访问。 - **灵活性**:系统应能够适应组织结构的变化,支持动态调整部门和角色。 - **可扩展性**:随着企业规模的...
领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法,强调以业务领域为中心进行系统设计,将复杂的业务逻辑转化为清晰的模型。在“基于DDD领域驱动设计通用后台权限系统”中,我们首先需要理解DDD的...
- **设计目标**:权限系统旨在对应用系统的所有资源实施控制,涵盖功能菜单、界面按钮等,以满足不同用户需求。设计应具备通用性,以便在多种环境和开发语言中复用。 - **运行环境**:支持Windows和Linux操作...
2. **权限系统的可扩展性**: - 系统的权限管理模块应具备高度可扩展性,能够轻松集成到任何需要权限控制的系统中,就像一个可重用的组件。这样避免了在每次开发新系统时都需要重复设计权限管理功能。 3. **功能...