将这两天关于权限的讨论归档在这里

权限系统干了什么？
给出一套方法，将系统中的所有功能标识出来，组织起来，托管起来，将所有的数据组织起来标识出来托管起来，然后提供一个简单的唯一的接口，这个接口的一端是应用系统一端是权限引擎。
权限引擎所回答的只是：谁是否对某资源具有实施某个动作（运动、计算）的权限。返回的结果只有：有、没有、权限引擎异常了。
这个接口大概像这个样子：

http://git.oschina.net/anycmd/anycmd/blob/master/src/Anycmd/ISecurityService.cs
====
@[author]Fan丶[/author]
引用
我想问你下。页面上的按钮权限怎么来控制显示隐藏。

1。动态生成的？
2。js批量隐藏控制？
3。你是怎么做的呀。

权限引擎负责判断给定的用户是否有对给定的资源实施给定的“操作”的权限，权限引擎只负责告知有还是没有。而这个“操作”对应的是什么按钮，什么菜单，或者什么页面权限引擎是不关心这些的，这是业务系统展示层的逻辑。权限引擎告诉业务系统给定的用户没有对给定的资源实施给定的操作的权限，然后展示层不展示对应的按钮或页面或菜单就可以了。
权限引擎可以告诉调用者给定的用户是否有对给定的具体某条记录的具体属性甚至这个属性取值的具体范围有实施给定动作的权限，甚至可以如果现在不是2014年9月1日就没有权限，权限引擎为调用者返回“true、false、我异常了”，然后业务系统的展示层自己决定是否要展示和如何展示数据
====
@[author]Fan丶[/author]
我们反复提到了权限引擎，这是一个概念，是个抽象事物，它的规格已经被界定了，而这件事物的具体实现在https://git.oschina.net/anycmd/anycmd 中，而这件事物是运行在哪里的？可以在一个独立的进程也可以在和业务系统同一个进程，然后我们才需要权限数据交换。这个抽象的事物anycmd可以实现，任何人都可以实现，突破anycmd的人可能正在大学里读书，也可能是刚入职的新手，但恐怕不是我们这一代了。

====
有些概念我们不一致：
什么是组？组是没有层级概念的。
简单组。
一个组是一个地图，整个森林中的树木是一个集合，树木类型的一个组则是一张记录树木位置的坐标图，图上的树木是整个森林的一个子集。
用户绘制一张记录树木的位置的坐标图，然后可以把这张图交给某个工人，从而工人按图索骥去伐木。
不在图上的树木可能是不允许砍伐的。Group跟手工仓库的区别是一个Group里的资源的类型都是一样的，而手工仓库里的资源可以不是同一类型的
（手工仓库中的一条资源记录需要ObjectType+ObjectID两个字段来标识而组只需一个字段）。
手工仓库也是“组”，手工仓库是复杂组。
什么是分类？我们人类几万年来无数人所维护出来的知识是被组织成一棵树的结构的。所谓树就是有偏移 = 层级 = 继承。每一个节点所表示的都是一个资源集合（叶子节点都是暂时的，随着我们的开拓，叶子节点下面将来可能会分出新枝，同样根节点是虚拟的，根节点也是暂时的，这棵树的组织结构一直都在相对稳定的调整着或修剪或发新枝或合并），每一个节点的所有直接子节点称作这个节点所表示的资源集合的“分类”。分类是没有层级的。当我们的分类被有组织有纪律有偏移的进行的时候这时换个名字命名这种分类的“子类”，这种分类称作“组织结构”，组织结构是树形。关于‘图’我暂时不懂。
角色模型上记录父角色标识不合适：
角色与组织结构的差别可以从这个角度来说明，一个组织结构节点指代了一个资源集合，而一个角色同样是指代了一个资源集合的，两者的区别是组织结构是从“组织、管理”的角度对资源进行分类的，而角色是从‘使用’的角度对‘职能’进行分类的，职能是跨越组织结构的，职能是与组织结构无关的。
角色的层级分两种：受限角色层次和通用角色层次。受限角色层次就是单继承，而通用角色层次就是多继承。通用角色层次是比受限角色层次更加良好的，通用角色层次的实现是不能通过角色模型上的ParentID来实现的。
说道这里还没说完：一个组织结构节点指代一个资源集合，这个资源集合是会继续分类的，一个资源集合并不是指一“种”资源的集合。比如将我的系统视作我公司的众多系统中的一个（我的公司是一个生产力组织单元，人类对资源建立起的组织结构是十分复杂的，从各种角度/属性观察有各种组织结构，这些组织结构相互交叉吗？不交叉，如果交叉的话就说明违反了组织结构原则了。）这里不考虑咱们的计算机系统之外的组织结构，那么：
系统中一般有三次分类，三次分类从整体上看就是一种组织结构。
三次分类是：
1 划分资源类型，此为第一次分类，一个资源类型实体对应的是一种资源的全部数据集；
2 划分资源元素，此为第二次分类，这次分类是区分资源的属性，每一个属性对应定义一个值域。
3 划分资源元素的值域单元，此为第三次分类，本次分类是对整个属性值域进行单元划分，终极的单元是不划分，即每一个取值就是一个分类节点（在计算机世界中只有“离散”不存在“连续性”这个概念）。

由于基本上所有的值都是可以比较大小的，从而第三次分类往往会基于算数运算划分单元。
对与系统内部来说三次分类基本足够了

单纯的一次分类称作分类，把多次分类从整体上看的话如果这些分类具有偏移量则就是组织结构。

组织结构上不封顶下不封底！

整套人类的知识就是一个组织结构，而这个组织结构上的每一个节点就是一次分类。

所有的问题最终划归为：
1 如何组织数据；
2 如何表现数据的运动。
模型 = 数据 + 运动。

使用组织结构和分类法来分析下面几个常见的概念：
只要用劲理解了“组织结构”则部门、岗位这两个概念就弄明白了，机构的本质就是组织结构，而岗位是具有组织结构属性的工作组。
机构：毫无疑问它是组织结构节点；
岗位：岗位是绑定到组织结构的工作组；
工作组：工作组是跨越组织结构的资源集，这个资源组中“具有主体”这种类型的资源元素，具有组织结构属性的工作组的意思是该组中的资源被约束为只能来自本组织结构和它的下级组织结构。
组：资源集，这个资源集中不一定只有一种类型的资源。
简单组：单一类型的资源集；

职位：补是组织结构。职位属于分类或字典，职位不是绑定到组织结构的，职位没有组织结构属性。不同组织结构的人员可能拥有相同的职位。
我的毕生所学都会融入anycmd中去http://git.oschina.net/anycmd/anycmd
anycmd不为同代人构建，而是为下代人构建：
如果你比原作者小5岁或5岁以上，所有开源协议在anycmd这里作废（原作者1984年生）
=====
需要一个良好的标准，需要一些良好的概念，需要一层良好的抽象。需要一个良好的形式。安全管理需要凌驾于具体的业务引擎之上，具体的业务引擎具只是安全“策略执行点”，执行安全策略是业务系统的义务，这个义务执行起来不难，任何一个业务系统都是没有分别的。
像xacml这种东西既有结构又有运算，它在表达安全策略方面是功能完备的。当然没有必要使用xacml把xacml当作C#这种语言来在CLR中书写我们的所有业务逻辑，xacml提供的是一个书写安全策略的规范。规范很重要，有了这层抽象才能做到将安全管理跨越具体的业务系统。

=====
哪些是权限，哪些是业务，它们是没有清晰的分界线的。使用一个良好的权限引擎提供的语言是可以书写出任何业务逻辑的，但是我们应该用它来做它擅长的事情而不是用来书写业务逻辑。
所有的业务逻辑都可以使用权限语言来书写一份等效的代码。问题是这份代码需要策略执行点去解释，而像CLR这种是用来解释C# VB.net CLI这种语言的不是专门用来解释权限语言的，那些逻辑应该使用权限语言书写哪些应该使用C#书写是需要你我根据具体的业务需求和业务的发展变化规律来权衡的。

=====
@卤鸽
引用
认真研读了下，首先拜谢楼主分享设计
有问题想请教楼主，
1、Actions和Paths楼主设计的初衷是什么，我总感觉可以将两者合并起来
只需一个Paths表，然后附加上Url？
2、针对公司组织架构层级比较复杂的权限，你这里直接将用户组实现成组织架构图类型，不知理解有误？
3、对数据怎么控制权限，看了评论说用Restriction，不解。。

发表一下看法，我不太理解Path是个什么概念？是不是Url？如果是Url的话那么它的特点就是它有层级。它是分层的，它是属于组织结构概念范畴的。使用Url来作为系统内部的资源标识恐怕不妥，我们可以使用使用Url来引用我们的系统之外的资源但不应该使用Url这种层级结构来冲淡我们系统内部的标识。为什么这么说呢？我们的系统存在的意义是什么？就是对我们的系统内部的资源进行分类、组织、管理啊，我们的系统内部已经根据资源类型做了第一次分类，根据实体属性做了第二次分类，并且甚至面向属性的值域做了第三次分类。并且甚至我们还为资源附加上了组织结构属性用来对具体类型下的所有该类型的资源记录集合中的元素进行了单元划分。这么多次有组织有偏移有纪律的分类从整体上看就是“组织结构”就是“树”就是“层级”啊。既然这样为什么还要在系统内部使用层级性的Url，为什么不直接使用非层级的简单标识然后依赖于系统内部对资源的具有层级性的分类来索引记录而还去使用Url然后从Url中解析出层级结构呢？

====
请考虑大家的权限系统能否做到如下描述的需求：
任何虚拟主体在任何虚拟空间、虚拟时间对任何虚拟客体发引发何运动的权限，引发运动的输入、运动的结果，运动次数都是受控的。
这是anycmd努力致力于实现的
http://git.oschina.net/anycmd/anycmd

====
有一个问题我一直很纠结，就是：
面向过程 => 面向对象 => 面向物理
物理化到一定程度骇客帝国就出现了。网络空间和人类生活的空间早晚被物理化打通，一旦打通则网络空间的主体将会有机会控制我们的空间。不要说人类造不出胜过人类的智慧体，这只是早晚的事。如果我们的网络中出现了邪恶的主体怎么办？
比如这个邪恶的主体故意把一些不该运动到妻子主体系统中的信息运动到妻子主体系统中去，他/她故意让妻子看到丈夫的出轨记录。这给我们人类空间中的丈夫和妻子带来了痛苦，安全系统要防止这种事情发生！

如果一旦这种事情已经发生了，丈夫的出轨记录已经运动到妻子中去了，该怎么办呢？我想到了一个办法，控制人类：通过人类工程消除妻子和丈夫脑中的这部分数据，让这对夫妻恢复到出轨之前的状态。但是，但是控制人类是邪恶的！anycmd的目的是防止邪恶的主体控制人类，但是为了防止修复已经造成的伤害我们自己又不得不去干邪恶的事情去控制人类。
这如何是好？

====
@[author][author][author][author][author]圣殿骑士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用请考虑大家的权限系统能否做到如下描述的需求：
任何虚拟主体在任何虚拟空间、虚拟时间对任何虚拟客体发引发何运动的权限，引发运动的输入、运动的结果，运动次数都是受控的。
这是anycmd努力致力于实现的
http://git.oschina.net/anycmd/anycmd

稍微看了一下你的框架，和我的思想有很大的不同。不知道你的权限系统对这种需求是怎么实现的？
公司有IT部门和销售部门，IT部门下面有C组， Java组，C组里面有张三和李四。能够说一下你是怎么控制权限（菜单，资源和操作）?

这里我可能需要按照anycmd定义的一些稳定的概念才能回答好这个问题：
1，部门是“组织结构”节点。“组”一旦被绑定到组织结构意思就是说接受“组织结构”的约束，你这里的IT部门下的C组和Java组它们都是“组”只不过这些组被绑定到了具体的组织结构节点，从而接受组织结构的限制，组织结构限制这些组中组合的资源必须来自于本组织结构节点和自己的后代节点。
补充：就像你这里的Java组和C组，它们组合的是哪些资源呢？你这个属于“工作组”，工作组也是组，工作组属于组的子类，工作组的特点是它组合的资源中必定有“主体”类型的资源。主体是什么呢？主体通常是我们人类。工作组中组织的资源有“角色类型的资源”也有“人类类型的资源”，还可以有“计算机类型的资源”（因为C组的工作开展需要计算机需要网络需要办公桌椅），组中也可以有“操作类型的资源”但组中已经有角色类型的资源了，如果角色分类的合理的话仅通过组合角色应该是可以组合出满足需求的权限集的。
2，菜单只和操作（或叫功能、或叫动作、或叫运动）有关，跟组织结构和组和角色都没有关系，一个菜单是否展示只在于当前用户是否有实施菜单关联的操作（或叫功能、或叫动作、或叫运动）的权限。
3，Role、Group、Organization等都是用来组织资源、操作、主体用的。权限的控制最终只认Resource、Action、Subject这几个基本概念，其他概念一概不认的。

====
@[author][author][author][author][author]圣殿骑士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用@[author][author][author][author][author]圣殿骑士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用请考虑大家的权限系统能否做到如下描述的需求：
任何虚拟主体在任何虚拟空间、虚拟时间对任何虚拟客体发引发何运动的权限，引发运动的输入、运动的结果，运动次数都是受控的。
这是anycmd努力致力于实现的
http://git.oschina.net/anycmd/anycmd

稍微看了一下你的框架，和我的思想有很大的不同。不知道你的权限系统对这种需求是怎么实现的？
公司有IT部门和销售部门，IT部门下面有C组， Java组，C组里面有张三和李四。能够说一下你是怎么控制权限（菜单，资源和操作）?
这里我...

上级当然是可以拒绝请求的，这种情况是通常的正常情况。上级做的是宏观管理，上级不需要去详细了解自己管辖的资源的具体每一个单元。比如一个消息到来了，这个消息请求解雇某个公司的某个组织结构节点下的某个员工，那么这个请求不一定是会被执行的。消息来到我们的系统，这条消息上必定带有这个员工的组织结构属性值，我们的系统首先索引这个组织结构的根组织结构节点的配置信息去判断这个根组织结构下的员工是否可以解雇，然而根节点往往说“我不知道，请询问下级节点”，于是权限引擎继续往下级询问，知道明确的得知是“允许还是不允许”不可能询问到叶子节点还不知道是允许还是不允许，因为系统全局会配置“末级隐式允许意为什么允许还是不允许？”。组织结构是棵树，遇到组织结构要爬树，爬上去再下来，上级节点的“显式允许和显式”都会重写任何子节点，只有上级节点不知道允许还是不允许的时候会继续往下级询问。

====
@[author][author][author][author][author]圣殿骑士[/author][/author][/author][/author][/author]
引用
@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用
引用@[author][author][author][author][author]圣殿骑士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]圣殿骑士[/author][/author][/author][/author][/author]
引用引用@[author][author][author][author][author]xuefly[/author][/author][/author][/author][/author]
引用引用请考虑大家的权限系统能否做到如下描述的需求：
任何虚拟主体在任何虚拟空间、虚拟时间对任何虚拟客体发引发何运动的权限，引发运动的输入、运动的结果，运动次数都是受控的。
这是anycmd努力致力于实现的
http://git.oschina.net/anycmd/anycmd

稍微看了一下你的框架，和我的思想有很大的不同。不知道你的权限系统对这种需求是怎么实现的？
公司有IT部门和销售部门，IT部门下面有C组， Java组，C组里面有张三和李四。能够说一下你...

考虑一下现在我们是不是想要把权限细化到实体级？如果是的话：
实体级的权限是什么？实体级的权限要和实体记录存储在一起，要始终尽量遵循一个原则——每一级的安全策略都要和自己本级实体存储在一起。那么实体级的安全控制其实没有任何特别的，实体资源记录上会附加一个“安全字段”，这个安全资源里存储的是这个实体的安全策略，这个实体的安全策略只有在访问到这个实体的时候才会需要这也是为什么安全策略要和实体一起存储在相同的物理位置。如果只是部分实体记录需要实体级的安全控制而其它部分不需要实体级的安全控制这个时候考虑根据从是否需要实体级安全控制的角度建立分类附加到实体资源记录上去，甚至还可以考虑将分类提升为组织结构从而将需要实体级安全控制的和不需要实体级安全控制的资源组织到分别组织到不同的安全控制组织结构节点去，组织结构是什么？组织结构就累死域，比如我访问腾讯的服务器是不会为百度的服务器带来任何压力的，因为它们在路由器上就已经分开了。
无论哪一级的安全策略，都是面向相同的主体，本级的资源，相同的动作列表来书写的。不同级的安全策略只有执行顺序不同没有结构上的任何不同。