系统权限管理设计 （转：http://blog.csdn.net/chexlong/article/details/37697555）

标签：权限   detail   概念   等等   nis   load   ipa   padding   ast   

权限设计（转：http://blog.csdn.net/chexlong/article/details/37697555）   
  1. 前言：   
  权限管理往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。   
  2. 目标：   
  直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。   
  3. 现状：   
  对于在企业环境中的访问控制方法，一般有三种：   
  1.自主型访问控制方法：目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。   
  2.强制型访问控制方法：用于多层次安全级别的军事应用。   
  3.基于角色的访问控制方法（RBAC）：是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。   
  4. 名词：   
  粗粒度：表示类别级，即仅考虑对象的类别(the   type   of   object)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。   
  细粒度：表示实例级，即需要考虑具体对象的实例(the   instance   of   object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。   
  5. 原则：   
  权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。   
  权限公式：Who+What(Which)+How   的问题，在这里我们实现What和部分Which的权限问题(粗粒度和细粒度相合，到一定的程度)，其他的权限问题留给业务逻辑解决   
  6. 概念：   
  Who：权限的拥用者或主体（Principal(负责人)、User、Group、Role、Actor等等）   
  What：权限针对的对象或资源（Resource、Class）。   
  How：具体的权限（Privilege,   正向授权与负向授权）。   
  Role：是角色，拥有一定数量的权限。   
  Operator：操作。表明对What的How   操作。   
  7. 解释：   
  User：与   Role   相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与   Privilege   直接相关的，User   要拥有对某种资源的权限，必须通过Role去关联。解决   Who   的问题。   
  Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。   
  Privilege：是Resource   Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做"部门新闻发布权限"。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。Privilege   如"删除"   是一个抽象的名词，当它不与任何具体的   Object   或   Resource   绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的   Privilege。这就是   Privilege   Instance。   
  Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。   
  Operator的定义包括了Resource   Type和Method概念。即，What和How的概念。之所以将What和How绑定在一起作为一个Operator概念而不是分开建模再建立关联，这是因为很多的How对于某What才有意义。比如，发布操作对新闻对象才有意义，对用户对象则没有意义。   
  8. 思想：   
  权限系统的核心由以下三部分构成：1.创造权限，2.分配权限，3.使用权限，然后，系统各部分的主要参与者对照如下：1.创造权限   -   Creator创造，2.分配权限   -   Administrator   分配，3.使用权限   -   User：   
  1.   Creator   创造   Privilege，   Creator   在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是   Privilege   与   Resource   的对象声明，并没有真正将   Privilege   与具体Resource   实例联系在一起，形成Operator。   
  2.   Administrator   指定   Privilege   与   Resource   Instance   的关联。在这一步，   权限真正与资源实例联系到了一起，   产生了Operator（Privilege   Instance）。Administrator利用Operator这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等...这些操作都是由   Administrator   来完成的。   
  3.   User   使用   Administrator   分配给的权限去使用各个子系统。Administrator   是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的   Operator。程序员提供   Operator   就意味着给系统穿上了盔甲。Administrator   就可以按照他的意愿来建立他所希望的权限框架可以自行增加，删除，管理Resource和Privilege之间关系。可以自行设定用户User和角色Role的对应关系。(如果将   Creator看作是   Basic   的发明者，   Administrator   就是   Basic   的使用者，他可以做一些脚本式的编程)   Operator是这个系统中最关键的部分，它是一个纽带，一个系在Programmer，Administrator，User之间的纽带。

但凡涉及多用户不同权限的网络或者单机程序，都会有权限管理的问题，比较突出的是MIS系统。     
    
  下面我要说的是MIS系统权限管理的数据库设计及实现，当然，这些思路也可以推广开来应用，比如说在BBS中用来管理不同级别的用户权限。     
    
  权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。     
    
  这三个部分相互依存，密不可分，要实现完善的权限管理体系，必须考虑到每一个环节可行性与复杂程度甚至执行效率。     
    
  我们将权限分类，首先是针对数据存取的权限，通常有录入、浏览、修改、删除四种，其次是功能，它可以包括例如统计等所有非直接数据存取操作，另外，我们还可能对一些关键数据表某些字段的存取进行限制。除此，我想不出还有另外种类的权限类别。     
    
  完善的权限设计应该具有充分的可扩展性，也就是说，系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化，要达到这个目的，首先是数据库设计合理，其次是应用程序接口规范。     
    
  我们先讨论数据库设计。通常我们使用关系数据库，这里不讨论基于Lotus产品的权限管理。     
    
  权限表及相关内容大体可以用六个表来描述，如下：     
  1   角色（即用户组）表：包括三个字段，ID，角色名，对该角色的描述；     
  2   用户表：包括三个或以上字段，ID，用户名，对该用户的描述，其它（如地址、电话等信息）；     
  3   角色-用户对应表：该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色组也可拥有多个用户。包括三个字段，ID，角色ID，用户ID；     
  4   限制内容列表：该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述，包括三个字段，ID，名称，描述；     
  5   权限列表：该表记录所有要加以控制的权限，如录入、修改、删除、执行等，也包括三个字段，ID，名称，描述；     
  6   权限-角色-用户对应表：一般情况下，我们对角色/用户所拥有的权限做如下规定，角色拥有明令允许的权限，其它一律禁止，用户继承所属角色的全部权限，在此范围内的权限除明令禁止外全部允许，范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点，设计的思路也很多，可以说各有千秋，不能生搬硬套说某种方法好。对此，我的看法是就个人情况，找自己觉得合适能解决问题的用。     
    
  先说第一种也是最容易理解的方法，设计五个字段：ID，限制内容ID，权限ID，角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限），角色/用户ID，权限类型（布尔型字段，用来描述一条记录表示允许还是禁止）     
    
  好了，有这六个表，根据表六，我们就可以知道某个角色/用户到底拥有/禁止某种权限。     
    
  或者说，这么设计已经足够了，我们完全实现了所需要的功能：可以对角色和用户分别进行权限定制，也具有相当的可扩展性，比如说增加了新功能，我们只需要添加一条或者几条记录就可以，同时应用程序接口也无须改动，具有相当的可行性。但是，在程序实现的过程中，我们发现，使用这种方法并不是十分科学，例如浏览某个用户所拥有的权限时，需要对数据库进行多次（甚至是递归）查询，极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道，Unix文件系统将对文件的操作权限分为三种：读、写和执行，分别用1、2、4三个代码标识，对用户同时具有读写权限的文件被记录为3，即1+2。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表，加入一个字段：标识码，例如，我们可以将录入权限标识为1，浏览权限标识为2，修改权限标识为4，删除权限标识为8，执行权限标识为16，这样，我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了，例如，假定某用户ID为1，库存表对应的限制内容ID为2，同时规定角色类型为0、用户类型为1，我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为：2,15,1,1。     
    
  确实很简单，不是吗？甚至还有更过激的办法，将限制内容列表也加上一列，定义好标识码，这样，我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然，这样做的前提是限制内容数量比较小，不然，呵呵，2的n次方递增起来可是数量惊人，不容易解析的。     
    
  从表面上看，上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的，但这样做有个弊端，我们所涉及的权限列表不是相互独立而是互相依赖的，比如说修改权限，其实是包含浏览权限的，例如，我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除（1+4+8=13),但事实上，该用户具有(1+2+4+8=15）的权限，也就是说，在这种方案中，13=15。于是当我们调用API询问某用户是否具有浏览权限时，就必须判断该用户是否具有对该数据表的修改权限，因此，如果不能在程序中固化权限之间的包含关系，就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。     
    
  这个问题如何解决？我想到了另外一种设置标识码的方法，那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为2,3,5,7,11，当遇到权限互相包含的时候，我们将它的标识码设定为两个（或多个）基本标志码的乘积，例如，可以将“修改”功能的标志码定为3*5=15，然后将所有的权限相乘，就得到了我们需要的最终权限标识值。这样，我们在询问用户是否具有某项权限的时候，只需要将最终的值分解成质因子，例如，我们可以定义一个用户具有录入+修改+删除库存表的权限为   2*15*7=2*3*5*7，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。     
    
  当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：）  

通用权限管理设计篇  

http://sxiaomais.blog.163.com/blog/static/31741203200811102630406/

一．引言

       因为做过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。

       权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。

二．设计目标

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

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

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

三．相关对象及其关系

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

1.       权限

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

系统管理

        用户管理

               查看用户

                新增用户

                     修改用户

                     删除用户

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

2.       用户

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

3.       角色

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

4.       组

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

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

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

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

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

通用权限管理设计篇（二）——数据库设计

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

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

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

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

       各表及其关系如下：

1.       用户表

2.       角色表

3.       权限表

4.       组表

5.       角色权限表

6.       组权限表

7.       组角色表

8.       用户权限表

9.       用户角色表

10.   用户组表

11.   组织表

12.   操作日志表

通用权限管理系统设计篇（三）——概要设计说明书

 在前两篇文章中，不少朋友对我的设计提出了异议，认为过于复杂，当然在实际的各种系统的权限管理模块中，并不像这里设计得那么复杂，我以前所做的系统中，

由只有用户和权限的，有只有用户、权限和角色的，还有一个系统用到了用户、权限、角色、组概念，这个系统是我在思考以前所做系统的权限管理部分中找到的一

些共性而想到的一个设计方案，当然还会有不少设计不到位的地方，在设计开发过程中会慢慢改进，这个系统权当学习只用，各位朋友的好的建议我都会考虑到设计

中，感谢各位朋友的支持。

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

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

1.      引言

1.1 编写目的

本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。

1.2 背景

a、 软件系统的名称：通用权限管理系统；

b、 任务提出者、开发者：谢星星；

c、 在J2EE的web系统中需要使用权限管理的系统。

1.3 术语

本系统：通用权限管理系统；

SSH：英文全称是Secure Shell。

1.4 预期读者与阅读建议

1.5 参考资料

《通用权限管理系统需求规格说明书》

《通用权限管理系统数据库设计说明书》

2.      总体设计

2.1 设计目标

权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。

本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。

2.2 运行环境

操作系统：Windows系统操作系统和Linux系列操作系统。

2.3 网络结构

 通用权限管理系统可采用Java Swing实现，可以在桌面应用和Web应用系统中进行调用。如果需要要适应所有开发语言，可以将其API发布到WEB Service上。暂时用Java Swing实现。

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.      界面总体设计

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

4.1 组权限管理

4.1.1包含用户

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

4.1.2所属角色

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

4.1.3组权限

4.1.4总权限

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

4.1.5组管理

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

4.2 角色权限管理

4.2.1包含用户

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

4.2.2包含组

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

4.2.3角色权限

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

4.2.4管理角色

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

4.3 用户权限管理

4.3.1所属角色

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

4.3.2所属组

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

4.3.3用户权限

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

4.3.4总权限

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

4.3.5用户管理

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

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

4.3.6组织管理

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

4.4 操作日志管理

4.4.1查询操作日志

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

4.4.2删除操作日志

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

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 出错信息

6.2 补救措施

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

a．后备技术   定期对数据库信息进行备份（每天一次），当数据库因某种原因被破坏时，以最新的数据库脚本进行恢复；。

7.      系统安全设计

7.1 数据传输安全性设计

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

7.2 应用系统安全性设计

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

7.3 数据存储安全性设计           

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

OA之权限管理

权限管理自己做完了，但是很多的研究和总结，现在就来总结一下权限管理。

第一、数据库中主要类：

主要负责类：用户（User），角色（Role）、资源（module）和操作（Permission）

衍生类：用户角色（UserRole）和对某个资源的某个操作（ACL）

第二、ACL的具体理解：

一条acl授权记录中主要记录了以下信息: 角色、资源和授权 

授权作为一个int, 每一位是一个操作的权限. 

假设从右向左, 分别代表CRUD 

那么, 我们CRUD的代码就应该是0123(也就是移位时要移的位数), 因为我们要进行移位进行认证。

先看授权与取消授权的代码：

首先, 一个int temp = 1的临时变量, aclState为原始授权状态

tmp的二进制表示是: 00000000 00000000 00000000 00000001 

U对应的代码是U, 对应的是2. 

将tmp左移2位, temp = tmp < < 2; temp变成:00000000 00000000 00000000 00000100 

假设原始授权是aclState=00000000 00000000 00000000 00001010 

当变量yes=true时，为授权，将temp与aclState求|运算，因为temp现在只有他要授权的位为1，求或运算后，

aclState=00000000 00000000 00000000 00001110，这样就授权成功

当变量yes=false时，为取消授权，先将temp取反，即为11111111 11111111 11111111 11111011，

现在只有要取消权限的位为0，其余全为1，然后与aclState求&运算，则除了要取消权限的位变0，其余的都不变，

即aclState=00000000 00000000 00000000 00001010

再来看认证：

认证更简单，直接将temp变量与aclState求&，temp为1的位为要验证的权限，其余全为0，如果aclState的这一位为1，则结果不为零，即有该权限；若aclState这一位为0，即没权限，则结果为0，没有该操作权限

总结：权限管理最难理解的就是CRUD中的数据得来，至于别的我们可以关系，我们还是可以清晰的理解，还有一个概念就是集成的概念：

 

a)        针对某个资源的所有操作，我们可以设置这些权限对用户来说是“继承”或“不继承”

 

                        i.             继承：意思是这些权限将使用其（即用户）所拥有的角色的权限，而不使用其（即用户）单独设置的权限

 

                      ii.             不继承：意思是这些权限将使用其单独设置的权限，而不使用其所拥有的角色的权限

系统权限管理设计 （转：http://blog.csdn.net/chexlong/article/details/37697555）

标签：权限   detail   概念   等等   nis   load   ipa   padding   ast   

原文地址：http://www.cnblogs.com/ThreeGrowthPlan/p/6045873.html