权限设计原理

《权限设计原理》一、权限设计概要21.1前言21.2目标21.3现状2二、权限设计原那么22.1原那么简述22.2相关名词解释32.3权限设计思想52.4权限设计例如52.5权限设计的扩展的思路62.5需要注意的几个问题7三、RBAC〔Role-BasedAccessControl〕模型介绍83.1RBAC开展历史83.1RBAC模型初探83.1一个RBAC模型的实现11四、ACL〔AccessControlList〕介绍124.1ACL〔AccessControlList〕概述12权限设计概要1.1前言权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据工程的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比拟权衡，1.2目标直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比拟重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比拟强的局部判断为业务逻辑，而将常常相同的“通用”特点比拟强的局部判断为权限逻辑就是基于这样的思路。扩展，采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组方式定义的同时有效防止了权限的重复定义。1.3现状对于在企业环境中的访问控制方法，一般有三种：1.自主型访问控制方法〔DAC/授权Authorization〕。目前在我国的大多数的信息系统中的访问控制模块中根本是借助于自主型访问控制方法中的访问控制列表(ACLs)。2.强制型访问控制方法〔多级平安/MultilevelSecurity〕。用于多层次平安级别的军事应用。3.基于角色的访问控制方法〔RBAC-Role-BasedAccessControl〕。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的平安策略，并对企业的变化有很大的伸缩性。权限设计原那么2.1原那么简述权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供效劳为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是"业务逻辑"的一局部。比方，要求："合同资源只能被它的创立者删除，与创立者同组的用户可以修改，所有的用户能够浏览"。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原那么归结为："系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责"。需要再次强调的是，这里表述的权限系统仅是一个"不完全"的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个根底，并解决那些具有"共性"的(或者说粗粒度的)局部。在这个根底之上，根据"业务逻辑"的独特权限需求，编码实现剩余局部(或者说细粒度的)局部，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How的问题，其他的权限问题留给业务逻辑解决。2.2相关名词解释粗粒度：表示类别级，即仅考虑对象的类别(thetypeofobject)，不考虑对象的某个特定实例。比方，用户管理中，创立、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。细粒度：表示实例级或数据级，即需要考虑具体对象的实例(theinstanceofobject)或对象的属性，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比方，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创立。Who：权限的拥用者或主体〔Principal、User、Group、Role、Actor等等〕What：权限针对的对象或资源〔Resource、Class〕。How：具体的权限〔Privilege,正向授权与负向授权〕。User：与Role相关，用户仅仅是纯粹的用户，权限是被别离出去了的。User是不能与Privilege直接相关的，User要拥有对某种资源的权限，必须通过Role去关联。(注：在如blog中的细粒度权限的解决，控制应该在底层解决。Resource在实例化的时候，必需指定Owner和GroupPrivilege。)解决Who的问题。Role：是角色，拥有一定数量的权限。是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。有关role和group的定义有需要补充的地方：根据模型的不同〔有关role和group的定义有需要补充的地方：根据模型的不同〔如RBAC和GBAC等等〕role和group的概念是有很容易混淆的。下面的对Group的定义实际上也是有针对性的〔似乎是基于RGAC模型的定义〕。把权限分配给组还是分配给角色应该根据实际情况和权限模型具体分析。在rbac中，权限只赋予role，通过role的分层继承概念和强制性约束条件从而达成了权限的控制。但对于细粒度的控制〔如不同部门的相同角色，他们的操作相同，但资源客体不同〕上实现就比拟复杂。我大致了解了一下，gbac出发点似乎更注重将相同权限进行抽象集合〔相同的权限规定为一个组〕，并通过继承等概念赋予不同用户的操作授权。举个简单的例子：一个公司中如果只一个部门，从这个部门中再划分不同的职务。这样的话role和group所起的作用是重合的，我们只需引入其一即可；但如果有了多个部门，我们可以同时引入角色和组〔一个部门一个组〕，组里又有相同的role〔此时role拥有相同的权利，但部门不同，职能范围不同〕。这样一来，将权限分配给组还是分配和role、是对role进行约束还是对组进行约束是需要我们根据具体情况进行分析和选型的。这里给出的概念只是网上比拟经典的一些论述，整理出来有助于大家学习。所以在后面介绍RBAC时给出的概念可能和现在给出的概念有所区别。Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创立时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否"同组"。Group是可继承的，对于一个分级的权限实现，某个Group通过"继承"就已经直接获得了其父Group所拥有的所有"权限集合"，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要"扩展"的那局部权限。子组继承父组的所有权限，规那么来得更简单，同时意味着管理更容易。User与Group是多对多的关系。即一个User可以属于多个Group之中，一个Group可以包括多个User。子Group与父Group是多对一的关系。Resource：[注：应等同于object]就是系统的资源，比方部门新闻，文档等各种可以被提供应用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与假设干指定权限类别相关可定义是否将其权限应用于子节点。Privilege：[注：应等同于permission]是ResourceRelated的权限。就是指，这个权限是绑定在特定的资源实例上的。比方说部门新闻的发布权限，叫做"部门新闻发布权限"。这就说明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义。权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理权限包含前两种权限)。Privilege如"删除"是一个抽象的名词，当它不与任何具体的Object或Resource绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的，只有当发布与新闻结合在一起才会产生真正的Privilege。Operator：操作。说明对What的How操作。Operator的定义包括了ResourceType和Method概念。即，What和How的概念。之所以将What和How绑定在一起作为一个Operator概念而不是分开建模再建立关联，这是因为很多的How对于某What才有意义。比方，发布操作对新闻对象才有意义，对用户对象那么没有意义。How本身的意义也有所不同，具体来说，对于每一个What可以定义N种操作。比方，对于合同这类对象，可以定义创立操作、提交操作、检查冲突操作等。可以认为，How概念对应于每一个商业方法。其中，与具体用户身份相关的操作既可以定义在操作的业务逻辑之中，也可以定义在操作级别。比方，创立者的浏览视图与普通用户的浏览视图要求内容不同。既可以在外部定义两个操作方法，也可以在一个操作方法的内部根据具体逻辑进行处理。具体应用哪一种方式应依据实际情况进行处理。这样的架构，应能在易于理解和管理的情况下，满足绝大局部粗粒度权限控制的功能需要。但是除了粗粒度权限，系统中必然还会包括无数对具体Instance的细粒度权限。这些问题，被留给业务逻辑来解决，这样的考虑基于以下两点：一方面，细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。比方，如果要求创立者和普通用户看到不同的信息内容，那么，资源本身应该有其创立者的信息。另一方面，细粒度的权限常常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原那么和策略。相比之下，粗粒度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，而且不是那么的有必要，用定制的代码来实现就更简洁，更灵活。所以细粒度控制应该在底层解决，Resource在实例化的时候，必需指定Owner和GroupPrivilege。在对Resource进行操作时也必然会确定约束类型：究竟是OwnerOK还是GroupOK还是AllOK。Group应和Role严格别离，User和Group是多对多的关系，Group只用于对用户分类，不包含任何Role的意义；Role只授予User，而不是Group。如果用户需要还没有的多种Privilege的组合，必须新增Role。Privilege必须能够访问Resource，同时带User参数，这样权限控制就完备了。Domain：为了授权更灵活，可以将Where或者Scope抽象出来，称之为Domain，真正的授权是在Domain的范围内进行，具体的Resource将分属于不同的Domain。比方：一个新闻机构有国内与国外两大分支，两大分支内又都有不同的资源〔体育类、生活类、时事政治类〕。假设所有国内新闻的权限规那么都是一样的，所有国外新闻的权限规那么也相同。那么可以建立两个域，分别授权，然后只要将各类新闻与不同的域关联，受域上的权限控制，从而使之简化。正向授权与负向授权：正向授权在开始时假定主体没有任何权限，然后根据需要授予权限，适合要求严格的系统。负向授权在开始时假定主体有所有权限，然后将某些特殊权限收回。2.3权限设计思想权限系统的核心由以下三局部构成：创造权限-Creator创造，分配权限-Administrator分配，使用权限-User：1.Creator创造Privilege，Creator在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是Privilege与Resource的对象声明，并没有真正将Privilege与具体Resource实例联系在一起，使之形成Operator。2.Administrator指定Privilege与ResourceInstance的关联。在这一步，权限真正与资源实例联系到了一起，产生了Operator〔PrivilegeInstance〕。Administrator利用Operator这个根本元素，来创造他理想中的权限模型。如，创立角色，创立用户组，给用户组分配用户，将用户组与角色关联等等...这些操作都是由Administrator来完成的。3.User使用Administrator分配给的权限去使用各个子系统。Administrator是用户，在他的心目中有一个比拟适合他管理和维护的权限模型。于是，程序员只要答复一个问题，就是什么权限可以访问什么资源，也就是前面说的Operator。程序员提供Operator就意味着给系统穿上了盔甲。Administrator就可以按照他的意愿来建立他所希望的权限框架可以自行增加，删除，管理Resource和Privilege之间关系。可以自行设定用户User和角色Role的对应关系。(如果将Creator看作是Basic的创造者，Administrator就是Basic的使用者，他可以做一些脚本式的编程)Operator是这个系统中最关键的局部，它是一个纽带，一个系在Programmer，Administrator，User之间的纽带。2.4权限设计例如A、建立角色功能并做分配1．如果现在要做一个员工管理的模块(即Resources)，这个模块有三个功能，分别是：增加，修改，删除。给这三个功能各自分配一个ID，这个ID叫做功能代号：Emp_addEmp，Emp_deleteEmp，Emp_updateEmp2．建立一个角色(Role)，把上面的功能代码加到这个角色拥有的权限中，并保存到数据库中。角色包括系统管理员，测试人员等。3．建立一个员工的账号，并把一种或几种角色赋给这个员工。比方说这个员工既可以是公司管理人员，也可以是测试人员等。这样他登录到系统中将会只看到他拥有权限的那些模块。B、把身份信息加到Session中登录时，先到数据库中查找是否存在这个员工，如果存在，再根据员工的sn查找员工的权限信息，把员工所有的权限信息都入到一个Hashmap中，比方就把上面的Emp_addEmp等放到这个Hashmap中。然后把Hashmap保存在一个UserInfoBean中。最后把这个UserInfoBean放到Session中，这样在整个程序的运行过程中，系统随时都可以取得这个用户的身份信息。C、根据用户的权限做出不同的显示可以比照当前员工的权限和给这个菜单分配的"功能ID"判断当前用户是否有翻开这个菜单的权限。例如：如果保存员工权限的Hashmap中没有这三个ID的任何一个，那这个菜单就不会显示，如果员工的Hashmap中有任何一个ID，那这个菜单都会显示。对于一个新闻系统(Resouce)，假设它有这样的功能(Privilege)：查看，发布，删除，修改；假设对于删除，有"新闻系统管理者只能删除一月前发布的，而超级管理员可删除所有的这样的限制，这属于业务逻辑(Businesslogic)，而不属于用户权限范围。也就是说权限负责有没有删除的Permission，至于能删除哪些内容应该根据UserRoleorUserGroup来决定(当然给UserRoleorUserGroup分配权限时就应该包含上面两条业务逻辑)。一个用户可以拥有多种角色，但同一时刻用户只能用一种角色进入系统〔？？？〕。角色的划分方法可以根据实际情况划分，按部门或机构进行划分的，至于角色拥有多少权限，这就看系统管理员赋给他多少的权限了。用户—角色—权限的关键是角色。用户登录时是以用户和角色两种属性进行登录的〔因为一个用户可以拥有多种角色，但同一时刻只能扮演一种角色〕，根据角色得到用户的权限，登录后进行初始化。这其中的技巧是同一时刻某一用户只能用一种角色进行登录。针对不同的"角色"动态的建立不同的组，每个工程建立一个单独的Group，对于新的工程，建立新的Group即可。在权限判断局部，应在商业方法上予以控制。比方：不同用户的"操作能力"是不同的(粗粒度的控制应能满足要求)，不同用户的"可视区域"是不同的(表达在对被操作的对象的权限数据，是否允许当前用户访问，这需要对业务数据建模的时候考虑权限控制需要)。登陆：检查员工是否存在登陆：检查员工是否存在是根据员工sn查找员工权限信息根据用户的权限做出不同的显示2.5权限设计的扩展的思路有了用户/权限管理的根本框架，Who(User/Group)的概念是不会经常需要扩展的。变化的可能是系统中引入新的What(新的Resource类型)或者新的How(新的操作方式)。在三个根本概念中，仅在Permission上进行扩展是不够的。这样的设计中Permission实质上解决了How的问题，即表示了"怎样"的操作。那么这个"怎样"是在哪一个层次上的定义呢？将Permission定义在"商业方法"级别比拟适宜。比方，发布、购置、取消。每一个商业方法可以意味着用户进行的一个"动作"。定义在商业逻辑的层次上，一方面保证了数据访问代码的"纯洁性"，另一方面在功能上也是"足够"的。也就是说，对更低层次，能自由的访问数据，对更高层次，也能比拟精细的控制权限。确定了Permission定义的适宜层次，更进一步，能够发现Permission实际上还隐含了What的概念。也就是说，对于What的How操作才会是一个完整的Operator。比方，"发布"操作，隐含了"信息"的"发布"概念，而对于"商品"而言发布操作是没有意义的。同样的，"购置"操作，隐含了"商品"的"购置"概念。这里的绑定还表达在大量通用的同名的操作上，比方，需要区分"商品的删除"与"信息的删除"这两个同名为"删除"的不同操作。提供权限系统的扩展能力是在Operator(Resource+Permission)的概念上进行扩展。Proxy模式是一个非常适宜的实现方式。实现大致如下：在业务逻辑层(EJBSessionFacade[StatefulSessionBean]中)，取得该商业方法的Methodname，再根据Classname和Methodname检索Operator数据，然后依据这个Operator信息和Stateful中保存的User信息判断当前用户是否具备该方法的操作权限。应用在EJB模式下，可以定义一个很明确的Business层次，而一个Business可能意味着不同的视图，当多个视图都对应于一个业务逻辑的时候，比方，SwingClient以及JspClient访问的是同一个EJB实现的Business。在Business层上应用权限较能提供集中的控制能力。实际上，如果权限系统提供了查询能力，那么会发现，在视图层次已经可以不去理解权限，它只需要根据查询结果控制界面就可以了。2.5需要注意的几个问题1、Group和Role，只是一种辅助实现的手段，不是必需的。如果系统的Role很多，逐个授权违背了"简单，方便"的目的，那就引入Group，将权限相同的Role组成一个Group进行集中授权。Role也一样，是某一类Operator的集合，是为了简化针对多个Operator的操作。〔注：例如员工、财务员工、测试、管理员他们之间有很多共同的权限也有属于自己的特殊的权限，此时可以将相同的权限规划到一个组，不同的权限另外规划组。其思想就是将通用的东西尽量集中管理并通过组的继承的概念尽量简化授权规划。〕注：由于rbac只是提供一个授权模型，在实际应用中很多人的设计都走了型只保存了概念而已，如果参考rbac的文档会发现上述观点也是一种混淆。个人观点：对于角色不同但权限相同的情况也可以通过？？？？？？注：由于rbac只是提供一个授权模型，在实际应用中很多人的设计都走了型只保存了概念而已，如果参考rbac的文档会发现上述观点也是一种混淆。个人观点：对于角色不同但权限相同的情况也可以通过？？？？？？2、Role把具体的用户和组从权限中解放出来。一个用户可以承当不同的角色，从而实现授权的灵活性。当然，Group也可以实现类似的功能。但实际业务中，Group划分多以行政组织结构或业务功能划分；如果为了权限管理强行将一个用户参加不同的组，会导致管理的复杂性。3、权限系统还应该考虑将功能性的授权与资源性的授权分开。很多系统都只有对系统中的数据〔资源〕的维护有权限控制，但没有对系统功能的权限控制。4、权限系统最好是可以分层管理而不是集中管理。大多客户希望不同的部门能且仅能管理其部门内部的事务，而不是什么都需要一个集中的Administrator或Administrators组来管理。虽然你可以将不同部门的人都参加Administrators组，但他们的权限过大，可以管理整个系统资源而不是该部门资源。5、权限计算策略：系统中User，Group，Role都可以授权〔？？？前面说User只能通过组来和授权相联系〕，权限可以有正负向之分，在计算用户的净权限时定义一套策略。系统中应该有一个集中管理权限的AccessService，负责权限的维护〔业务管理员、平安管理模块〕与使用〔最终用户、各功能模块〕，该AccessService在实现时要同时考虑一般权限与特殊权限。虽然在具体实现上可以有很多，比方用Proxy模式，但应该使这些Proxy依赖于AccessService。各模块功能中调用AccessService来检查是否有相应的权限。所以说，权限管理不是平安管理模块自己一个人的事情，而是与系统各功能模块都有关系。每个功能模块的开发人员都应该熟悉平安管理模块，当然，也要从业务上熟悉本模块的平安规那么。RBAC〔Role-BasedAccessControl〕模型介绍3.1 RBAC开展历史访问控制技术是由美国国防部〔DepartmentofDefense,DoD〕资助的研究和开发成果演变而来的。这一研究导致两种根本类型访问控制的产生：自主访问控制〔DiscretionaryAccessControl,DAC〕和强制访问控制〔MandatoryAccessControl,MAC〕。〔两者区别请参考附录《an_introduction_to_rbac.pdf》〕它们最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。由于DAC和MAC的特殊背景，人们越来越发现在实际情况中并不适合商用，在1992年，由DavidFerraiolo和RickKuhn合作提出了RBAC〔Role-BasedAccessControl〕模型，在RBAC模型中，在用户〔user〕和访问权限〔permission〕之间引入了角色〔role〕的概念，用户于特定的一个或多个角色相联系，而角色与一个或多个访问许可权相联系，角色可以根据实际的工作需要生成或取消。由于RBAC在管理大型网络应用平安时所表现出的灵活性和经济性，使得RBAC迅速成为最具有影响的高级访问控制模型。3.1 RBAC模型初探RBAC为了将人和权限解耦引入了ROLE的概念，整个RBAC参考模型都是围绕Role来建立的。其根本思想是通过分配和取消角色来完成用户权限的授予和取消，根据不同的职能岗位划分角色，资源访问许可被封装在角色中，用户通过赋予的角色间接地访问系统资源和对系统资源可进行的操作。授权者根据需要定义各种角色，并设置适宜的访问权限，而部门或个人根据其工作性质和职责再被指派为不同的角色，完成权限授予。这样，整个访问控制过程就分成两个局部，即访问权限与角色相关联，角色再与部门或个人关联，从而实现了部门或个人与访问权限的逻辑别离。标准的RBAC模型由4个部件模型组成，下面分别介绍。A：模型1：CoreRBACCroeRBAC定义了5个根本元素集合〔USERS、ROLES、OBS、OPS、PRMS〕，RBAC模型的本质其实就是基于这几个根本集合的一系列关系〔如图〕。包括：角色授权关系(PA)、用户的角色授权关系(UA)和角色的层次关系(RH)等；一些函数，包括：会话到用户的映射()、会话到角色集合的映射()等；以及一些相关约束。用户(Users)：一个用户被定义成一个人。虽然它的概念可以扩展成一个机器、网络、以及智能代理等，但我们为了简单起见，在这个文档中我们将用户定义成一个人的概念。角色(Role)：在一个组织机构的关系中，Role表示一个工作职责。如果将用户指派到角色上，那么Role暗含关联权限和职责的语义。权限(Permission)：一个许可，是对一个或多个Object执行operation的许可。〔资源客体objects〔OBS〕〕、操作〔operations〔OPS〕〕会话(Session)：会话在RBAC标准草案中似乎没有给出具体定义，它跟web应用中session的概念有些不同。根据标准发布的内容可以看出session在rbac中是一个关系映射的概念。具体来说是一个user和一〔多〕个role之间关系的映射；在一个RBAC模型的系统中，每个用户进入系统得到自己的控制时，就得到了一个session。每个session是动态产生的，附属于一个用户。只要静态定义过这些角色与该用户的关系，会话根据用户的要求负责将它所代表的用户映射到多个角色中去。一个session可能激活的角色是用户的全部角色的一个子集，对于用户而言，在一个session内可获得全部被激活的角色所代表的访问许可权。角色和会话的设置带来的好处是容易实施最小特权原那么〔Least-PrivilegePrinciple〕。所谓最小特权原那么是将超级用户的所有特权分解成一组细粒度的特权子集，定义成不同的“角色”，分别赋予不同的用户，每个用户仅拥有完成其工作所必须的最小特权，防止了超级用户的误操作或其身份被假冒后而产生的平安隐患。一个session只能关联一个user，一个user可以关联多个sessions；上面的图例中有两个函数：user_sessions给出了和用户关联的session集合；session_roles给出了rolesactivated〔激活的角色〕。session由用户控制，允许动态激活/取消角色，实现最小特权。应防止同时激活所有角色；session和user别离可以解决同一用户多账号带来的问题，如审计、计账等实现核心RBAC必须具备的功能管理方面的功能：增加及删除使用者、增加及删除角色、分配角色给使用者及移除原先分配给使用者的角色、分配权利给角色及移除原先分配给角色的权利系统支持方面的功能：产生或删除一个会话期、在一个会话期参加或删除角色，既能在一个会话期启动或停止局部角色、检查一个会话期是否具有某个权利。核查〔Review〕功能：查询所有拥有某一角色的使用者、查询一个使用者所拥有的全部角色。增强型核查功能：查询一个角色所有的权利、查询一个使用者所拥有的权利、查询一个会话期所启用的角色、查询一个会话期所具有的权利、查询一个角色对某一个物件所能行使的操作、查询一个使用者对某一个物件所能行使的操作B：模型1：HierarchicalRBACHierarchicalRBAC在coreRBAC的根底上引入了角色继承的概念。如下图：Hierarchical是反映一个组织结构层次的授权和责任的自然方式，它定义了角色的继承关系。如：Roler1“继承”Roler2,那么角色r2的权限同样是r1的权限。相比拟coreRBAC，角色分层带来的好处就是解决了重复授权的问题。例如：在没有引入角色分层概念时，经理和高级经理的权限可能有80％都是重合的。这样一来管理员具体实施时对角色授权的重复操作度就很高。而且随着组织结构层次复杂度的提高，这种授权操作的复杂度成线性增加；在引入了rolehierarchy后高级经理自动获取经理的所有权限，然后管理员在分配其特有的权限即可。见过类似的公式推导，以一个全国性跨地区的公司，角色分层的实现和不实现相比其赋权的复杂度降低了约十倍。C：模型2：StaticSeparationofDutyRelationsSSD定义了一个用户角色分配的约束关系，一个用户不可能同时分配SSD中的两个角色。它的作用就是防止了角色的冲突。举个简单的例子：在一个公司，一个员工不应该既是会计又是出纳〔注意：一个财务经理，如果她既继承了会计的角色又继承了财务的角色。这种特殊的情况没有很好的解决方法。应尽力防止〕。在UserAssignment中引入SSD，这样在系统初始化的时候，当角色授权给用户时来判断是否将冲突的角色给了一个用户。在StaticSeparationofDutyRelations模型中冲突的角色用一个二元关系定义，任何一个用户只能拥有其中的一个角色。D：模型1：DynamicSeparationofDutyRelations动态别离的概念是指两个或多个冲突的角色可以赋给一个用户。它的特点不是在系统初始化时将责任进行别离，而是在一个用户会话过程进行约束。虽然用户可以同时启用这两种角色，但同一会话期只能选择其一。一个RBAC模型的实现ACL〔AccessControlList〕介绍4.1ACL〔AccessControlList〕概述不好意思，查了N久也没看到ACL名称的历史和起源。目前大家能看到ACL使用最多的地方根本都是在网络平安配置和UNIX系统平安配置中。简单的总结一下：所谓的ACL就是指访问控制列表，是存储在计算机中的一张表。它记录了用户和设备可以访问哪些现有资源〔文件目录、单个文件、数据等等〕，是用来保证系统平安性的一种手段。4.2 ACL在web应用中描述1.Javaacl开始第一步是建立一个主体Principal，其中SecurityOwner是主体的拥有者：privatestaticfinalPrincipal_securityOwner=newPrincipalImpl("SecurityOwner");补上：主体的定义。主体表示一个实体，如单独用户或一个用户组2.当用户login进来时，他带有两个根本数据：访问密码和他要访问的对象ApplicationName。首先验证用户名和密码，然后从数据库中取出其权限数据，建立Permission,这里使用Feature继承了Permission，在Feature中定义了有关权限的细节数据〔如读写删〕。//取出用户和被访问对象之间的权限关系,这种权限关系可能不只一个，也就是说，用户//可能对被访问对象拥有读写删等多个权限，将其打包在Hasbtable中。Hashtablefeatures=loadFeaturesForUser(sApplicationName,sUserID);3.创立一个用户对象Useruser=newUserImpl(sUserID,newHashtable());4.为这个用户创立一个活动的aclentryaddAclEntry(user,features);其中最关键的是第四步addAclEntry,我们看看其如何实现的：//为这个用户创立一个新的AclentryAclEntrynewAclEntry=newAclEntryImpl(user);//遍历Hashtablefeatures，将其中多种权限参加:feature=(Feature)hFeatures.get(keyName);newAclEntry.addPermission(feature);最后也要参加主体拥有者SecurityOwner，这样一个平安体系就已经建立完成。当你在系统中要检验某个用户使用拥有某个权限，如读的权利时，只要acl.checkPermission(user,feature)就可以,acl是ACL的一个实例，这样权限检查就交给java.security.acl.ACL去处理了。当一个用户login后，我们就要在内存中为其建立相应的授权访问机制，使用java.security.acl可以很方便的建立这样一个平安系统。An—introduction－to－rbac：7页、Grbc中权限和group相连。实际上rbac也借鉴了gbac的概念，group和user都和组织机构有关，但不是组织机构。二者在概念上是不同的我个人理解group组一般按企业的组织结构来，分部门。role角色一般按职能来，它是对组的细化和补充，role分为全局role和局部roleActor作为一个通用的接口与Role通讯。Role作为一个用户与权限的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或Group。PrivilegeManager〔名字不好听〕就是用来进行R-P之间的关系操作的。例如getRoleByPrivilege()之类的。SecurityManager作为系统对外的接口，接受Actor,Resource,Operation作为参数，并判断Actor中的Role是否有操作Privilege(Resource,Operation)的权限。〔个人理解：这两个函数的作用是：当一个用户做某些操作时，user_sessions给出了和这个用户关联的sessions，而session_roles又给出和用户关联的可用roles，这样就完成了用户和角色的关联――暂时标注〕增加代码增加代码id：mp_addEmp建立角色功能并做分配详细步骤见jive手册账号2账号1〔role〕管理员员工测试人员修改代码id：建立角色功能并做分配详细步骤见jive手册账号2账号1〔role〕管理员员工测试人员修改代码id：mp_updateEmp删除代码删除代码id：mp_deleteEmp把身份信息加把身份信息加进Session中登陆：检查员工是否存在登陆：检查员工是否存在是根据员工sn查找员工权限信息根据用户的权限做出不同的显示比照当前员工的权限和给这个菜单分配的“功能ID”比照当前员工的权限和给这个菜单分配的“功能ID”判断当前用户是否有翻开这个菜单的权限所有权限信息放到Hashmap中如上面的Emp_addEmp等然后把Hashmap保存在一个UserInfoBean中。最后把这个UserInfoBean放到Session中例如：如果保存员工权限的Hashmap中没有这三个ID的任何一个，那这个菜单就不会显示，如果员工的Hashmap中有任何一个ID，那这个菜单都会显示。

对于一个新闻系统(Resouce)，假设它有这样的功能(Privilege)：查看，发布，删除，修改；假设对于删除，有\"新闻系统管理者只能删除一月前发布的，而超级管理员可删除所有的这样的限制，这属于业务逻辑(Businesslogic)，而不属于用户权限范围。也就是说权限负责有没有删除的Permission，至于能删除哪些内容应该根据UserRoleorUserGroup来决定(当然给UserRoleorUserGroup分配权限时就应该包含上面两条业务逻辑)。例如：如果保存员工权限的Hashmap中没有这三个ID的任何一个，那这个菜单就不会显示，如果员工的Hashmap中有任何一个ID，那这个菜单都会显示。

对于一个新闻系统(Resouce)，假设它有这样的功能(Privilege)：查看，发布，删除，修改；假设对于删除，有\"新闻系统管理者只能删除一月前发布的，而超级管理员可删除所有的这样的限制，这属于业务逻辑(Businesslogic)，而不属于用户权限范围。也就是说权限负责有没有删除的Permission，至于能删除哪些内容应该根据UserRoleorUserGroup来决定(当然给UserRoleorUserGroup分配权限时就应该包含上面两条业务逻辑)。一个用户可以拥有多种角色，但同一时刻用户只能用一种角色进入系统。角色的划分方法可以根据实际情况划分，按部门或机构进行划分的，至于角色拥有多少权限，这就看系统管理员赋给他多少的权限了。用户—角色—权限的关键是角色。用户登录时是以用户和角色两种属性进行登录的〔因为一个用户可以拥有多种角色，但同一时刻只能扮演一种角色〕，根据角色得到用户的权限，登录后进行初始化。这其中的技巧是同一时刻某一用户只能用一种角色进行登录。

针对不同的“角色”动态的建立不同的组，每个工程建立一个单独的Group，对于新的工程，建立新的Group即可。在权限判断局部，应在商业方法上予以控制。比方：不同用户的“操作能力”是不同的(粗粒度的控制应能满足要求)，不同用户的“可视区域”是不同的(表达在对被操作的对象的权限数据，是否允许当前用户访问，这需要对业务数据建模的时候考虑权限控制需要)。另一个word文档通用权限管理系统设计篇〔三〕——概要设计说明书在前两篇文章中，不少朋友对我的设计提出了异议，认为过于复杂，当然在实际的各种系统的权限管理模块中，并不像这里设计得那么复杂，我以前所做的系统中，由只有用户和权限的，有只有用户、权限和角色的，还有一个系统用到了用户、权限、角色、组概念，这个系统是我在思考以前所做系统的权限管理局部中找到的一些共性而想到的一个设计方案，当然还会有不少设计不到位的地方，在设计开发过程中会慢慢改良，这个系统权当学习只用，各位朋友的好的建议我都会考虑到设计中，感谢各位朋友的支持。

今天抽时间整了一份概念设计出来，还有一些地方尚未考虑清楚，贴出1.0版，希望各位朋友提出珍贵建议。

大家也可以点击此处《通用权限管理概要设计说明书》自行下载，这是1.0版本，有些地方可能还会进行局部修改，有兴趣的朋友请关注我的blog。

1.引言1.1编写目的本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统平安数据进行了说明。1.2背景a、软件系统的名称：通用权限管理系统；b、任务提出者、开发者：谢星星；c、在J2EE的web系统中需要使用权限管理的系统。1.3术语本系统：通用权限管理系统；SSH：英文全称是SecureShell。1.4预期读者与阅读建议预期读者阅读重点开发人员总体设计、接口设计、数据结构设计、界面总体设计、系统出错处理设计设计人员总体设计、接口设计、数据结构设计、系统平安设计1.5参考资料《通用权限管理系统需求规格说明书》《通用权限管理系统数据库设计说明书》2.总体设计2.1设计目标权限系统一直以来是我们应用系统不可缺少的一个局部，假设每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少珍贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。本系统的设计目标是对应用系统的所有资源进行权限控制，比方应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。2.2运行环境操作系统：Windows系统操作系统和Linux系列操作系统。2.3网络结构通用权限管理系统可采用JavaSwing实现，可以在桌面应用和Web应用系统中进行调用。如果需要要适应所有开发语言，可以将其API发布到WEBService上。暂时用JavaSwing实现。2.4总体设计思路和处理流程在说明总体设计思路前，我们先说明本系统的相关概念：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文本框

|________|6TextArea

|…………|7页签未选中时：选项名称

选中时：选项名称8未选中链接链接文字9选中链接链接文字10说明信息说明信息4.1组权限管理包含用户组信息

组1

组11

组12

组…

组2

组21

组22

组…

所选择组：组1[包含用户][所属角色][组权限][总权限][修改]用户名

姓名

号

最近登录时间

登录次数阿蜜果

谢星星

2007-10-8

66sterningxxx

2007-10-8

10

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

组1

组11

组12

组…

组2

组21

组22

组…

所选择组：组1[包含用户][所属角色][组权限][总权限][修改]角色ID

角色名称

角色描述1

访客

--

2

初级用户

--

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

组1

组11

组12

组…

组2

组21

组22

组…

所选择组：组1[包含用户][所属角色][组权限][总权限]

[保存][取消]总权限组信息

组1

组11

组12

组…

组2

组21

组22

组…

所选择组：组1[包含用户][所属角色][组权限][总权限]

[保存][取消]通过对已具有的权限取消勾选，或为某权限添加勾选，来修改组的权限信息，点击“保存”按钮保存修改信息。组管理在下列图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。组信息

组1

组11

组12

组…

组2

组21

组22

组…

所选择组：组1[包含用户][所属角色][组权限][总权限][修改]用户名

姓名

号

最近登录时间

登录次数阿蜜果

谢星星

2007-10-8

66sterningxxx

2007-10-8

10

……4.2角色权限管理包含用户角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所选择角色：角色1[包含用户][包含组][角色权限][修改]用户名

姓名

号

最近登录时间

登录次数阿蜜果

谢星星

2007-10-8

66sterningxxx

2007-10-8

10

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

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所选择角色：角色1[包含用户][包含组][角色权限][修改]组ID

组名称

组描述1

xxx1

--2

xxx2

--

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

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所选择角色：角色1[包含用户][包含组][角色权限]

[保存][取消]通过对已具有的权限取消勾选，或为某权限添加勾选，来修改角色的权限信息，点击“保存”按钮保存修改信息。管理角色在下列图中，选中组1的时候，右键点击可弹出组的操作列表，包括添加、删除和修改按钮，从而完成在该组下添加子组，删除该组以及修改该组的功能。角色信息

角色1

角色11

角色12

角色…

角色2

角色21

角色22

角色…

所选择角色：角色1[包含用户][包含组][角色权限][修改]用户名

姓名

号

最近登录时间

登录次数阿蜜果

谢星星

2007-10-8

66sterningxxx

2007-10-8

10

……4.3用户权限管理所属角色用户权限信息xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所选择用户：阿蜜果[所属角色][所属组][用户权限][总权限][修改]角色ID

角色名称

角色描述1

访客

--

2

初级用户

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

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所选择用户：阿蜜果[所属角色][所属组][用户权限][总权限][修改]组ID

组名称

组描述1

组1

--

2

组2

--…当用户选择“修改”按钮时，弹出组的树形结构，操作人可以通过勾选或取消勾选来修改该用户所属的组。用户权限用户信息xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所选择用户：阿蜜果[所属角色][所属组][用户权限][总权限]

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

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所选择用户：阿蜜果[所属角色][所属组][用户权限][总权限]

[保存][取消]通过对已具有的权限取消勾选，或为某权限添加勾选，来修改用户的权限信息，点击“保存”按钮保存修改信息。用户管理中选择了某用户时，点击右键，弹出菜单列表：修改、删除、取消，点击修改和删除按钮可以实现用户的删除和修改功能。选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加用户按钮可以实现用户的添加功能。用户权限信息xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所选择用户：阿蜜果[所属角色][所属组][用户权限][总权限][修改]角色ID

角色名称

角色描述1

访客

--

2

初级用户

--…组织管理选择某个组织，例如下表中的“广州分公司”，弹出菜单列表：添加子组织、删除组织、修改组织、添加用户、取消，点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。用户权限信息xx公司

广州分公司

阿蜜果

肖xx

yy…

北京分公司

zz1

zz2

zz3…

所选择用户：阿蜜果[所属角色][所属组][用户权限][总权限][修改]角色ID

角色名称

角色描述1

访客

--

2

初级用户

--…4.4操作日志管理查询操作日志操作名称：|________|

操作人：|________|操作时间从

|________|到|________|

[查询][重置][删除]编号

操作名称

操作内容

操作人

操作时间1

xx1

--

Amigo

2007-10-82

xx2

--

xxyy

2007-10-8…输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。删除操作日志操作名称：|________|

操作人：|________|操作时间从

|________|到|________|

[查询][重置][删除]编号

操作名称

操作内容

操作人

操作时间1

xx1

--

Amigo

2007-10-82

xx2

--

xxyy

2007-10-8…输入上图表单中的查询信息后，点击“查询”按钮，可查询出符合条件的信息。而后点击“删除”按钮，可删除符合查询条件的操作日志。5.数据结构设计数据库设计的模型请参见《通用权限管理系统_数据库模型.pdm》。表的说明请参见《通用权限管理系统数据库设计说明书》。5.1设计原那么命名的标准数据库中表、主键、外键、索引的命名都以统一的规那么，采用大小写敏感的形式，各种对象命名长度不要超过30个字符，这样便于应用系统适应不同的数据库平台。数据的一致性和完整性为了保证数据库的一致性和完整性，往往通过表间关联的方式来尽可能的降低数据的冗余。表间关联是一种强制性措施，建立后，对父表〔ParentTable〕和子表(ChildTable)的插入、更新、删除操作均要占用系统的开销。如果数据冗余低，数据的完整性容易得到保证，但增加了表间连接查询的操作，为了提高系统的响应时间，合理的数据冗余也是必要的。使用规那么〔Rule〕和约束〔Check〕来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段，但是，不必要的规那么和约束也会占用系统的不必要开销，需要注意的是，约束对数据的有效性验证要比规那么快。所有这些，需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。5.2数据库环境说明数据库：MySql5.0设计库建模工具：PowerDesigner12.05.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进行加密。另一个文档理清了对象关系之后，让我们接着来进行数据库的设计。在数据库建模时，对于N对N的关系，一般需要参加一个关联表来表示关联的两者的关系。初步估计一下，本系统至少需要十张表，分别为：权限表、用户表、角色表、组表、用户权限关联表、用户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。各表及其关系如下：1.用户表用户表〔TUser〕字段名称字段类型备注记录标识tu_idbigintpk,notnull所属组织to_idbigintfk,notnull登录帐号login_namevarchar(64)notnull用户密码passwordvarchar(64)notnull用户姓名vsernamevarchar(64)notnull号mobilevarchar(20)电子邮箱emailvarchar(64)创立时间gen_timedatetimenotnull登录时间login_timedatetime上次登录时间last_login_timedatetime登录次数countbigintnotnull2.角色表角色表〔TRole〕字段名称字段类型备注角色IDtr_idbigintpk,notnull父级角色IDparent_tr_idbigintnotnull角色名称role_namevarchar(64)notnull创立时间gen_timedatetimenotnull角色描述descriptionvarchar(200)3.权限表权限表〔TRight〕字段名称字段类型备注权限IDtr_idbigintpk,notnull父权限parent_tr_idbigintnotnull权限名称right_namevarchar(64)notnull权限描述descriptionvarchar(200)4.组表组表〔TGroup〕字段名称字段类型备注组IDtg_idbigintpk,notnull组名称group_namevarchar(64)notnull父组parent_tg_idbigintnotnull创立时间gen_timedatetimenotnull组描述descriptionvarchar(200)5.角色权限表角色权限表〔TRoleRightRelation〕字段名称字段类型备注记录标识trr_idbigintpk,notnull角色Role_idbigintfk,notnull权限right_idbigintfk,notnull权限类型right_notnull〔0:可访问，1:可授权〕6.组权限表组权限表〔TGroupRightRelation〕字段名称字段类型备注记录标识tgr_idbigintpk,notnull组tg_idbigintfk,notnull权限tr_idbigintfk,notnull权限类型right_notnull〔0:可访问，1:可授权〕7.组角色表组角色表〔TGroupRoleRelation〕字段名称字段类型备注记录标识tgr_idbigintpk,notnull组tg_idbigintfk,notnull角色tr_idbigintpk,notnull8.用户权限表用户权限表〔TUserRightRelation〕字段名称字段类型备注记录标识tur_idbigintpk,notnull用户tu_idbigintfk,notnull权限tr_idbigintfk,notnull权限类型right_notnull〔0:可访问，1:可授权〕9.用户角色表用户角色表〔TUserRoleRelation〕字段名称字段类型备注记录标识tur_idbigintpk,notnull用户tu_idbigintfk,notnull角色tr_idbigintfk,notnull10.用户组表用户组表〔TUserGroupRelation〕字段名称字段类型备注记录标识tug_idbigintpk,notnull用户tu_idbigintfk,notnull组tg_idbigintfk,notnull11.组织表组织表〔TOrganization〕字段名称字段类型备注组织idto_idbigintpk,notnull父组parent_to_idbigintnotnull组织名称org_namevarchar(64)notnull创立时间gen_timedatetimenotnull组织描述descriptionvarchar(200)12.操作日志表操作日志表〔TLog〕字段名称字段类型备注日志IDlog_idbigintpk,notnull操作类型op_notnull操作内容contentvarchar(200)notnull操作人tu_idbigintfk,notnull操作时间gen_timedatetimenotnull另一个文档权限管理设计方案 andy加深理解::用户是:某个人,角色:某个职位,权限是:添加,删除,修改,查询权力用户和角色的关联:一个用户可以有多个职位,一个职位可以有多个用户角色和权限的关联:一个职位可以有多个权力一个权力可以是多个职位权限是被别离出去了的1设计思路为了设计一套具有较强可扩展性的权限管理，需要建立用户、角色和权限等数据库表，并且建立之间的关系，具体实现如下。1.1用户用户仅仅是纯粹的用户，用来记录用户相关信息，如用户名、密码等，权限是被别离出去了的。用户〔User〕要拥有对某种资源的权限，必须通过角色〔Role〕去关联。用户通常具有以下属性：ü编号，在系统中唯一。ü名称，在系统中唯一。ü用户口令。ü注释，描述用户或角色的信息。1.2角色角色是使用权限的根本单位，拥有一定数量的权限，通过角色赋予用户权限，通常具有以下属性：ü编号，在系统中唯一。ü名称，在系统中唯一(监控人员)ü注释，描述角色信息.(在线监控人员)1.3权限权限指用户根据角色获得对程序某些功能的操作，例如对文件的读、写、修改和删除功能，通常具有以下属性：ü编号，在系统中唯一。ü名称，在系统中唯一(添,删,改,查)ü注释，描述权限信息

.允许增加监控对象1.4用户与角色的关系一个用户〔User〕可以隶属于多个角色〔Role〕，一个角色组也可拥有多个用户，用户角色就是用来描述他们之间隶属关系的对象。用户〔User〕通过角色〔Role〕关联所拥有对某种资源的权限，例如l用户〔User〕：UserID

UserName

UserPwd1

张三

xxxxxx2

李四

xxxxxx

……l角色〔Role〕：RoleID(角色编号)

RoleName(角色名称)

RoleNote(角色注释)

01