关于权限设计的问题

建议你去看看权限设计方面的文章。 我给你转几篇JIVE的吧。

前言： 权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。 目标： 直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。 简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 扩展，采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时 现状： 对于在企业环境中的访问控制方法，一般有三种： 1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。 2.强制型访问控制方法。用于多层次安全级别的军事应用。 3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。 名词： 粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特 定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。 细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细 粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。 原则： 权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。 需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How 的问题，其他的权限问题留给业务逻辑解决。 概念： Who：权限的拥用者或主体（Principal、User、Group、Role、Actor等等） What：权限针对的对象或资源（Resource、Class）。 How：具体的权限（Privilege, 正向授权与负向授权）。 Role：是角色，拥有一定数量的权限。 Operator：操作。表明对What的How 操作。 说明： 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的具体实体，它是接口概念，抽象的通称。 Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否“同组” 。Group是可继承的，对于一个分级的权限实现，某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入“父子关系”。 User与Group是多对多的关系。即一个User可以属于多个Group之中，一个Group可以包括多个User。子Group与父Group是多对一的关系。Operator某种意义上类似于Resource + Privilege概念，但这里的Resource仅包括Resource Type不表示Resource Instance。Group 可以直接映射组织结构，Role 可以直接映射组织结构中的业务角色，比较直观，而且也足够灵活。Role对系统的贡献实质上就是提供了一个比较粗颗粒的分配单位。 Group与Operator是多对多的关系。各概念的关系图示如下： 解释： Operator的定义包括了Resource Type和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参数，这样权限控制就完备了。 思想： 权限系统的核心由以下三部分构成：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之间的纽带。 用一个功能模块来举例子。 一．建立角色功能并做分配： 1．如果现在要做一个员工管理的模块(即Resources)，这个模块有三个功能，分别是：增加，修改，删除。给这三个功能各自分配一个ID，这个ID叫做功能代号： Emp_addEmp，Emp_deleteEmp，Emp_updateEmp。 2．建立一个角色(Role)，把上面的功能代码加到这个角色拥有的权限中，并保存到数据库中。角色包括系统管理员，测试人员等。 3．建立一个员工的账号，并把一种或几种角色赋给这个员工。比如说这个员工既可以是公司管理人员，也可以是测试人员等。这样他登录到系统中将会只看到他拥有权限的那些模块。 二．把身份信息加到Session中。 登录时，先到数据库中查找是否存在这个员工，如果存在，再根据员工的sn查找员工的权限信息，把员工所有的权限信息都入到一个Hashmap中，比如就把上面的Emp_addEmp等放到这个Hashmap中。然后把Hashmap保存在一个UserInfoBean中。最后把这个UserInfoBean放到Session中，这样在整个程序的运行过程中，系统随时都可以取得这个用户的身份信息。 三．根据用户的权限做出不同的显示。 可以对比当前员工的权限和给这个菜单分配的“功能ID”判断当前用户是否有打开这个菜单的权限。例如：如果保存员工权限的Hashmap中没有这三个ID的任何一个，那这个菜单就不会显示，如果员工的Hashmap中有任何一个ID，那这个菜单都会显示。 对于一个新闻系统(Resouce)，假设它有这样的功能(Privilege)：查看，发布，删除，修改；假设对于删除，有\"新闻系统管理者只能删除一月前发布的，而超级管理员可删除所有的这样的限制，这属于业务逻辑(Business logic)，而不属于用户权限范围。也就是说权限负责有没有删除的Permission，至于能删除哪些内容应该根据UserRole or UserGroup来决定(当然给UserRole or UserGroup分配权限时就应该包含上面两条业务逻辑)。 一个用户可以拥有多种角色，但同一时刻用户只能用一种角色进入系统。角色的划分方法可以根据实际情况划分，按部门或机构进行划分的，至于角色拥有多少权限，这就看系统管理员赋给他多少的权限了。用户—角色—权限的关键是角色。用户登录时是以用户和角色两种属性进行登录的（因为一个用户可以拥有多种角色，但同一时刻只能扮演一种角色），根据角色得到用户的权限，登录后进行初始化。这其中的技巧是同一时刻某一用户只能用一种角色进行登录。 针对不同的“角色”动态的建立不同的组，每个项目建立一个单独的Group，对于新的项目，建立新的 Group 即可。在权限判断部分，应在商业方法上予以控制。比如：不同用户的“操作能力”是不同的(粗粒度的控制应能满足要求)，不同用户的“可视区域”是不同的(体现在对被操作的对象的权限数据，是否允许当前用户访问，这需要对业务数据建模的时候考虑权限控制需要)。 扩展性： 有了用户/权限管理的基本框架，Who(User/Group)的概念是不会经常需要扩展的。变化的可能是系统中引入新的 What (新的Resource类型)或者新的How(新的操作方式)。那在三个基本概念中，仅在Permission上进行扩展是不够的。这样的设计中Permission实质上解决了How 的问题，即表示了“怎样”的操作。那么这个“怎样”是在哪一个层次上的定义呢？将Permission定义在“商业方法”级别比较合适。比如，发布、购买、取消。每一个商业方法可以意味着用户进行的一个“动作”。定义在商业逻辑的层次上，一方面保证了数据访问代码的“纯洁性”，另一方面在功能上也是“足够”的。也就是说，对更低层次，能自由的访问数据，对更高层次，也能比较精细的控制权限。 确定了Permission定义的合适层次，更进一步，能够发现Permission实际上还隐含了What的概念。也就是说，对于What的How操作才会是一个完整的Operator。比如，“发布”操作，隐含了“信息”的“发布”概念，而对于“商品”而言发布操作是没有意义的。同样的，“购买”操作，隐含了“商品”的“购买”概念。这里的绑定还体现在大量通用的同名的操作上，比如，需要区分“商品的删除”与“信息的删除”这两个同名为“删除”的不同操作。 提供权限系统的扩展能力是在Operator (Resource + Permission)的概念上进行扩展。Proxy 模式是一个非常合适的实现方式。实现大致如下：在业务逻辑层(EJB Session Facade [Stateful SessionBean]中)，取得该商业方法的Methodname，再根据Classname和 Methodname 检索Operator 数据，然后依据这个Operator信息和Stateful中保存的User信息判断当前用户是否具备该方法的操作权限。 应用在 EJB 模式下，可以定义一个很明确的 Business层次，而一个Business 可能意味着不同的视图，当多个视图都对应于一个业务逻辑的时候，比如，Swing Client以及 Jsp Client 访问的是同一个 EJB 实现的 Business。在 Business 层上应用权限较能提供集中的控制能力。实际上，如果权限系统提供了查询能力，那么会发现，在视图层次已经可以不去理解权限，它只需要根据查询结果控制界面就可以了。 灵活性： Group和Role，只是一种辅助实现的手段，不是必需的。如果系统的Role很多，逐个授权违背了“简单，方便”的目的，那就引入Group，将权限相同的Role组成一个Group进行集中授权。Role也一样，是某一类Operator的集合，是为了简化针对多个Operator的操作。 Role把具体的用户和组从权限中解放出来。一个用户可以承担不同的角色，从而实现授权的灵活性。当然，Group也可以实现类似的功能。但实际业务中，Group划分多以行政组织结构或业务功能划分；如果为了权限管理强行将一个用户加入不同的组，会导致管理的复杂性。 Domain的应用。为了授权更灵活，可以将Where或者Scope抽象出来，称之为Domain，真正的授权是在Domain的范围内进行，具体的Resource将分属于不同的Domain。比如：一个新闻机构有国内与国外两大分支，两大分支内又都有不同的资源（体育类、生活类、时事政治类）。假如所有国内新闻的权限规则都是一样的，所有国外新闻的权限规则也相同。则可以建立两个域，分别授权，然后只要将各类新闻与不同的域关联，受域上的权限控制，从而使之简化。 权限系统还应该考虑将功能性的授权与资源性的授权分开。很多系统都只有对系统中的数据（资源）的维护有权限控制，但没有对系统功能的权限控制。 权限系统最好是可以分层管理而不是集中管理。大多客户希望不同的部门能且仅能管理其部门内部的事务，而不是什么都需要一个集中的Administrator或Administrators组来管理。虽然你可以将不同部门的人都加入Administrators组，但他们的权限过大，可以管理整个系统资源而不是该部门资源。 正向授权与负向授权：正向授权在开始时假定主体没有任何权限，然后根据需要授予权限，适合于权限要求严格的系统。负向授权在开始时假定主体有所有权限，然后将某些特殊权限收回。 权限计算策略：系统中User，Group，Role都可以授权，权限可以有正负向之分，在计算用户的净权限时定义一套策略。 系统中应该有一个集中管理权限的AccessService，负责权限的维护（业务管理员、安全管理模块）与使用（最终用户、各功能模块），该AccessService在实现时要同时考虑一般权限与特殊权限。虽然在具体实现上可以有很多，比如用Proxy模式，但应该使这些Proxy依赖于AccessService。各模块功能中调用AccessService来检查是否有相应的权限。所以说，权限管理不是安全管理模块自己一个人的事情，而是与系统各功能模块都有关系。每个功能模块的开发人员都应该熟悉安全管理模块，当然，也要从业务上熟悉本模块的安全规则。 技术实现： 1．表单式认证，这是常用的，但用户到达一个不被授权访问的资源时，Web容器就发 出一个html页面，要求输入用户名和密码。 2．一个基于Servlet Sign in/Sign out来集中处理所有的Request，缺点是必须由应用程序自己来处理。 3．用Filter防止用户访问一些未被授权的资源，Filter会截取所有Request/Response， 然后放置一个验证通过的标识在用户的Session中，然后Filter每次依靠这个标识来决定是否放行Response。 这个模式分为： Gatekeeper ：采取Filter或统一Servlet的方式。 Authenticator： 在Web中使用JAAS自己来实现。 用户资格存储LDAP或数据库： 1. Gatekeeper拦截检查每个到达受保护的资源。首先检查这个用户是否有已经创建 好的Login Session，如果没有，Gatekeeper 检查是否有一个全局的和Authenticator相关的session？ 2. 如果没有全局的session，这个用户被导向到Authenticator的Sign-on 页面， 要求提供用户名和密码。 3. Authenticator接受用户名和密码，通过用户的资格系统验证用户。 4. 如果验证成功，Authenticator将创建一个全局Login session，并且导向Gatekeeper 来为这个用户在他的web应用中创建一个Login Session。 5. Authenticator和Gatekeepers联合分享Cookie，或者使用Tokens在Query字符里。

请教一个关于权限设计方面的问题 from: http://www.jdon.com/jive/article.jsp?forum=46&thread=10122 ninsky http://www.jdon.com 2003年10月21日 22:31:19 首先表示一下奇怪：我以前在这注册的号是不是给删除了，虽然我确实很久没在这发言了！ 我现在在做一个系统，一个类似信息发布的东东，本来也无所谓，可没想到用户提出了许多BT的要求，尤其是权限方面，本来照我的常规思维，这种东东一般也就是划分几个角色，划分几个信息的发布模块等等也就行了，甚至公司都有现成的东西直接用。 可没想到客户的要求比较刁钻。我先说说系统的大概模样。 信息发布吗，首先当然要划分信息的类别和层次，而这层次是不定的，可能是两三层，也可能是十层、八层（没这么变态吧^_^），其实就类似与windows的资源管理器的样式，目录里面含着文件，而文件又有可能和目录平级的说，这是显示方面大概要显示的东东。现在说说他们在权限控制方面的要求，某个用户登录系统之后，这些目录文件（使用的是资源管理器类似的样式，左边一颗树，右边基本信息列表）将需要根据用户权限的不同而不同（有的目录文件显示，有的不显示的说），当然对于不同的记录用户也需要有不同的增删改权限，列表虽然都能看见，不过有的记录他可以修改却不可以删除，有的却连修改都不许了，当然还有其他的一下操作方式的控制。更为变态的是，要求点击某条记录（或目录、或文件）时弹出的信息查看页面对于不同权限的用户也需不同，即某些字段可以显示，某些字段不能显示（my god，还是把我回收了得了），这就要求在后台的管理方面有着灵活的操作，当然用户也要求了，本着易用性的原则，管理员可以适当选择是对一条条记录赋权还是对一批记录赋权。 说了这么多，不知道各位能否看明白？ 我开始的想法是定义组，将某些权限相同的用户赋为一组，然后对记录赋权时根据组进行选择而不用对每个人进行选择，这样就不需对个人进行操作（即使一个人也给他搞个组），这样对组配置改组可以对记录有那些权限，可以显示记录的那些字段，然后针对记录选择组（一个用户可能属于多个组，如有重复，则以用户能获得的最大权限为主）。 不过后来一想，加入某些记录只是针对个人的，如果也这么做的话，会死人的啊，组的数量就太多了。 不过用户的这些要求说到底其实也挺合理，不过实现起来也确实挺头疼，反正我头疼了一个下午了，几张目录文件的表画好后，后台权限方面我死活下不了手了：（ 我也希望能够趁这个系统的机会把这个权限管理好好核计核计，反正尽量希望能在设计阶段就考虑完善，最好能将权限这块尽量独立出来，将来在其他系统中可以比较方便地移至（估计也没那个信息系统有这么繁琐的要求了，本来不大的玩意，愣是让他们搞大发了） 但本人在设计方面是个新手，所以感觉难度实在挺大，还是先听听各位在座的高论先，请指教一下该如何下手，信息表与权限表该如何关联，如果有谁做过这方面的东东的话，那就更好了。 所有经验、方法、建议，在下一律欢迎，还请各位不吝赐教，我实在是头都大了 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 00:36:37 发表人: iceant 发表文章: 398 / 注册时间: 2002-10 1. 对"有的目录文件显示，有的不显示的"疑问 具体到一个目录下的文件是可以控制显示与不显示，但是对目录而言不适合做这样的控制。为什么？假如用户只对 1.1.1 目录有访问权限，那么 1.1 的目录级别要不要体现出来？如果只列用户有权限的目录，那怎么能看得出是 1.1.1 的那个目录？ 2.组与用户 你的应用实际上是动态责任确定的应用，在程序规划与实施阶段没有办法获知有哪些角色能操作哪些对象; 另外，权限设计不可过于复杂，否则管理员也会弄不清自己分配的权限是什么样的，最少我自己加个两三层的东东就会头晕。 因此我建议你做基于 ACL 的控制。你提到了想使用组的概念，但是你想为一个人也定义一个组，我认为没有必要，完全可以是用户(User)与 Subject(Folder|Documents)直接对应。如果只能有一个人操作一个目录的文件修改，那你直接授权给某个人，和修改 Role-User Map 关系的维护量没有多大的差别。但是如果对一个目录同一种 Permission 的操作分别授权给不同的用户，维护起来肯定没有建个组或一个角色来得简单。 因此，我的选择是直接使用 Subject,Group,User 的三级关系。 这里先解释几个名词: Subject: 各种目录，文件等对象 Group: 用户集合 User:用户 Operation: 对 Subject 的某种具体操作，如 Visit,Modify,Delete 等 Permission: 是 Subject 与 Operation 的组合，如：指对某个目录的Visit操作 OK, 那让我们来建几个表吧: Permissions_Table( subject varchar(20),--对应目录或文件的ID user_name varchar(10), -- USER-Subject ACL group_name varchar(10), -- Group -Subject ACL operation_type int, --1:visit,2:modify 4:delete,3:visit+modify,5:delete+visit,6:delete+modify,7:visit+modify+delete subject_type int, --1:dir,2:document ) user_group_table( user_name varchar(10), group_name varchar(10), primary key(user_name,group_name) ) 再下面.... 我相信你有能力做完的.... Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 10:02:00 发表人: ninsky 发表文章: 13 / 注册时间: 2003-10 感谢iceant，你的意见给了我一个思路，某些地方我确实走入了歧途，也盲目的想设计一个通用的东东（估计这就是过度设计） 不过我还想请教一下就是，对于控制到字段的权限模式你能否也提供一点建议呢 我现在就是想多找些人，听一下别人的意见，然后再自己综合一下，希望能够尽量好的实现这套权限管理功能 希望各位多多发言，希望能对我这已经困累欲绝的大脑来点刺激 再次感谢iceant，jdon的讨论风气是我转的几个论坛中最好的一个了 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 11:16:11 发表人: iceant 发表文章: 398 / 注册时间: 2002-10 "对于控制到字段的权限模式你能否也提供一点建议呢" 什么叫控制到字段的权限模式? Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 12:19:51 发表人: ninsky 发表文章: 13 / 注册时间: 2003-10 > "对于控制到字段的权限模式你能否也提供一点建议呢" > > 什么叫控制到字段的权限模式? 就是对于某个表中的某些字段是可以显示的，而某些是不显示的 当然有个方法是将所有的表的字段及相关的描述信息放到一个数据字典表中，然后对数据字典进行一些相关的赋权操作，不过这样作要求数据字典和所有的表的字段同步 不过总感觉这种方法并不是太好，不过我也没想到其他的方法 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 12:29:24 发表人: iceant 发表文章: 398 / 注册时间: 2002-10 能不能详细说说你的应用情景? 举个例子 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 13:41:19 发表人: ninsky 发表文章: 13 / 注册时间: 2003-10 > 能不能详细说说你的应用情景? 举个例子 用户、单位等信息存储在LDAP中，而且是远程的，我的系统虽说取的是LDAP中的用户、单位信息，可是还得提供额外的用户、单位增加功能，也就是说在读取用户、单位信息时要将LDAP中的信息与自己增加的用户、单位信息汇合，重新进行树状排列（这个地方采取生成XML树的方式，不知效果如何），与此同时还要判断当前用户的权限，以便控制各节点是否显示（这些节点可能是单位，也可能是个人）。 然后对各个节点显示的信息还得读取控制权限，那些信息可以显示，那些不能显示，另外对各个信息的操作权限也有控制，对某条信息是增、删、改，还是仅仅查看。而对于某条记录的详细信息，又需控制某个字段是否显示，等等等等，如此这般 我的初步构想： 划分功能点：功能模块（不同用户有不同的操作模块，如我们一般程序顶的菜单项，非LDAP和相关信息）、表结构（数据字典表，控制到字段权限时用） 操作（operate）：增、删、改、查看 角色：赋功能模块，及相关操作 用户：赋角色 组：赋用户 算了，就说这点吧，我也晕了，现在思路很乱 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 13:54:05 发表人: iceant 发表文章: 398 / 注册时间: 2002-10 我的感觉是你对需求不明确，建义你回去和客户坐下来谈谈他们想要的东东。你可以把操作的界面画出来，然后问问客户是不是想这样操作，如果不是，怎么改动，最后要一个需求更改说明书(可能要你写，客户签字，这也是对你自己的一种保护!)，说明确定下来的需求是什么。 所谓有的字段显示，有的字段不显示，多数情况下在程序设计与实施阶段都可以确定的，字段显示就表明用户拥有某种权限，如拥有了增删改员工信息权限的用户，就能看到 Submit 按钮，而一般用户就看不到这个按钮。 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 14:23:36 发表人: ninsky 发表文章: 13 / 注册时间: 2003-10 呵呵，不是submit，那些倒是好说：） 例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而乙可能就是看到b、d、c等项了，是这么个意思 另：iceant你好像一直挂在坛里啊 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 15:11:44 发表人: iceant 发表文章: 398 / 注册时间: 2002-10 >>呵呵，不是submit，那些倒是好说：） >>例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而 >>乙可能就是看到b、d、c等项了，是这么个意思 所以我请你举个例子来看看啊，不能实际把应用说清楚，就表示没有理解需求，没有理解需求，是不可能做出东西来的。即使做出来了，也只是不符合用户需求的东西。 这里你可以思考一下，为什么甲进入后看到的是 a,b? 是因为甲拥有了某种权限？是甲拥有了某种身份？乙需要拥有什么样的权限或身份才能看到b,d,c? 我觉得你总在说自己头痛，但并不知道自己为什么头痛。 >>另：iceant你好像一直挂在坛里啊 我今天放自己假，不想做事，所以有空。有时忙起来，可能一两个月也不会上网了~~~ Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月22日 16:28:18 发表人: ninsky 发表文章: 13 / 注册时间: 2003-10 其实，我真正头疼的是，我在考虑这个系统的设计的时候，思路老是飘到：如果这个系统更加通用的话该如何设计呢。以设计一个通用的，复用性强的系统为己任，头不疼才怪呢 是时候放弃这种想法了，都是让那帮老是让那帮高人把我害的^_^ Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月23日 12:37:13 发表人: l_walker 发表文章: 57 / 注册时间: 2002-12 我的项目中也碰到了类似的问题，即对于每个模块，对其下的各种资源的操作都是一种权限，比如新闻模块，“新闻”是一个资源，而“发布新闻”则是一个操作，而对“新闻的发布”则成了权限 在实际中，新闻若分部门，则“发布A部门的新闻”是一个实际的权限，在权限系统中，将个权限赋给某个角色即可，后面的都好办（参看本论坛中关于权限设计中的RBAC方面的讨论） 所以系统中比一般的RBAC多了以下表： Resource Operation 角色除了和权限对应外，还和资源实例对应，即如是A部门的则有RA角色，B的是RB，将这些角色分配给对应的用户或组后即完成授权。 在权限验证的时候通过当前用户和当前可操作角色（由当前模块所对应的资源实例来确定）来验证，ACL.checkPermission(user,resource,operation) 但难点在于模块和资源是变化的，新闻也许只需要一个部门ID就可以确定当前角色，对于复杂的应用如何获取当前模块资源实例并获取当前可操作角色则还没想出好的解决办法 继续thinking... Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月23日 15:42:22 发表人: ninsky 发表文章: 13 / 注册时间: 2003-10 唉，我的问题与此类似，不过又稍微复杂了点 不知可否给我发个这方面的示例图啊，当然是非机密的 也好让我研究研究 以前自己写代码感觉挺爽的，再难的方法也都可以实现，可现在自己作设计，可真是感觉晕头转向的啊:( 努力、奋斗 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月24日 16:24:18 发表人: littlebird 发表文章: 1 / 注册时间: 2003-10 看了这么多关于权限方面的讨论真是受益匪浅。 这里说说我的想法： 我认为对于多数企业应用项目，相对而言都不是很大的项目，权限管理部分是不是可以简化成：user *-->1 role 1-->* operate 用户可能有很多组织上的层次关系，但在这里可以将它压平，不论什么层次都直接和角色相关，而且只有一个角色 权限也可能有很多层次关系（比如新闻包括A、B或C部门的），这里也把它展开，让角色直接最底层的权限相关（如A部门新闻的修改权限） 根据用户获得它的角色，再根据角色获得它拥有权限的集合。 而group是用户的集合，把它加上会变得相当复杂；当然还可以有权限集合的概念也加入，那就更复杂了。 Re: 我也请教一个关于权限设计方面的问题 发表时间: 2003年10月25日 11:07:20 发表人: iceant 发表文章: 398 / 注册时间: 2002-10 我想理一理思路，看看 ACL 与 RBAC 的区别: 还是以部门新闻来讨论，对于静态授权，在系统设计做需求分析的时候，往往就可以 确定一个系统角色的种类，像新闻系统中，根据需求，可能会有新闻发布者(Publisher)， 新闻审核者(Reviewer)，新闻浏览者(Visitor)，管理员(Manager)以及超级管理员(Administrator)。 在设计的时候我们也已经把这些角色与相应的一些 Operation 绑定在一起。 如：Publisher 拥有 Publish_Operation + Modify_Operation Reviewer 拥有 Review_Operation + Modify_Operation + Delete_Operation Visitor 拥有 Visit_Operation, Manager 拥有 Create_News_System_Instance_Operation + Modify_News_System_Instance_Operation + Delete_News_System_Instance_Operation Administrator 负责 Create_User_Operation+ Delete_User_Operation+ Assign_Permission_Operation+ Deassign_Permission_Operation + Assign_Role_Operation+ Deassign_Role_Operation 在授权时，往往先为一个用户(USER)，赋予一个角色，如: Manager. 这样，USER 就 拥有了对所有 News_Instance(也就是部门新闻) 操作的权限。 现在假设用户(UserA)访问 Create_News_System_Instance 功能来创建一个新的新闻实例， 叫做 采购部门新闻. 因为我们在设计的时候就确定，该功能只能由 Manager 来访问， 于是，系统中权限的判断部分会首先判断当前用户(UserA)是否 Manager 角色，是的话就允许 访问，否则显示没有授权的错误信息。 所以，对于 Manager 这样的应用: [1] 在设计的时候，我们就将这样的角色与相应的 Permissions(A list of Subject-Operation pairs) 关联在一起了，这里的 Subject 是所有的新闻实例(News_Instance),Operation 就是 Create,Modify以及 Delete. [2] 在授权的时候，超级管理员(Administrator)可以利用 Assign_Role_Operation 将用户(User) 与 Manager 这个角色关联起来。这样，User 就拥有了对所有新闻实例的 Create, Modify 以及 Delete 操作的权限。 [3] 在权限判断的时候，RBAC 系统首先判断当前用户是否是设计时确定的角色(这里是Manager), 如果是，就允许用户访问，否则就拒绝访问，并显示错误信息。 对于 Publisher 这样的角色有些不同，Publisher 这个角色只与 Operation 绑定在一起，并没有与 具体的 Subject 相关联，因此，在授权的时候，还需要指定相应的 Subject. 所以，对 Publisher 这样只能事先确定 Operation 的应用来说: [1] 在设计的时候，我们只能确定该角色能进行哪些操作，而不能确定这些操作实施的对象。 [2] 在授权的时候: [2.1] 首先将 Publisher 与 Subject 关联,如将 Publisher 与采购部门新闻关联产生: 采购部门新闻_News_Publisher 的角色 [2.2] Administrator 为用户(User)授于 采购部门新闻_News_Publisher 角色。从而 User 拥有了对"采购部门新闻"的发布权限 [3] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation, 系统首先判断 该用户是否 采购部门新闻_News_Publisher?如果是，就允许用户访问，否则就拒绝访问， 并显示错误信息。 这里用到的方法可能是这个样子: boolean checkPermission(采购部门新闻,Publish_Operation,User){ List publishers = RBAC.findRole(new Permission(采购部门新闻,Publish_Operation)); if(publishers==null) return false; for(Iterator it = publishers.iterator; it.hasNext();){ Role publisher = (Publisher)it.next(); if(publisher.isAssignedWithUser(User)){ return ture; } } return false; } 假如说，不采用 RBAC 的做法，考虑一下，使用 ACL，那又会是什么样子呢? 对于 Manager 那样能在设计时就确定 Subject 与 Operation 的角色，我认为没有必要考虑 ACL 了. 对于 Publisher 这样，只能事先确定 Operation 的角色，我们来做个对比. 权限系统要灵活，但是也要简洁，要不然就很可能导至失控。因为嵌套的层次太多，有可能发生不可 预知的情况. 有一天管理员可能会莫明的发现，怎么这个人会有这个权限的? 所以，我认为在 RBAC 里不支持 Role 的层级关系为妙。 好了，现在来看看 ACL 对 Publisher 应用 这里指的 ACL 是直接将 User 或 Group 与 Subject 关联的做法。 User 与 Subject 是多对多的情况， Group 与 Subject 也是多对多的情况， 同样的，User 与 Group 也是多对多的情况。 现在，还是以采购部门新闻为例: [1] 在授权的时候，可以有以下操作: [1.1] 将 User 与 Subject 关联在一起,但是要指定相应的 Operation. 如: assignPermission(采购部门新闻,Publish_Operation,User) [1.2] 将 Group 与 Subject 关联在一起: 如: assignPermission(采购部门新闻,Publish_Operation,Group) [1.3] 将 User 与 Group 关联 如: assignUserGroup(User,Group) [2] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation，系统做如下检查: boolean checkPermission(采购部门新闻,Publish_Operation,User){ boolean hasPermission = false; // users include: // 1. Permission direct assigned Users // 2. The user assigned with the groups that assigned with permission List users = getAssignedUsers(new Permission(采购部门新闻,Publish_Operation)); hasPermission=users.contains(User)?true:false; }

我曾经是在用户表里面做一个权限字段，然后不同的值代表不同的权限，满足基本需要是够了

 附件(71.1KB) sys.BMP 我们有个系统ms是这样的

【 在 tztg 的大作中提到: 】 :  : 我们有个系统ms是这样的 附件(36.4KB) sts2.BMP