overview
#Anycmd开源权限引擎介绍
系统中的权限管理大家都很熟悉，实现模式大同小异。研究和尝试实现权限框架的人很多，基本上把这块想明白了并实现出来就不再是初学者了。**总的来说权限管理就是：**给出一套方法，将系统中的所有功能标识出来，组织起来，托管起来，将所有的数据组织起来标识出来托管起来， 然后提供一个简单的唯一的接口，这个接口的一端是应用系统一端是权限引擎。权限引擎所回答的只是：谁是否对某资源具有实施某个动作（运动、计算）的权限。返回的结果只有：有、没有、权限引擎异常了。
Rbac（role base access control）分了好几级，每一级都在说什么这篇文章不去研究也不评价，您可以在这里下载到Anycmd搜集的Rbac相关的标准。您正在阅读的这篇文章是按照Anycmd的思维模式书写的。在我们起初实践的时候我们也试图阅读前人的文章，继承前人的知识，但是我看不懂。不是因为前人在遮遮掩掩或者故作高深，而是因为多年前作为一个初学者的我准备不够。虽然很多人认为搞计算机工作充满创造性，但是我还是认为我是搞生产的不是搞科研的，我相信在我搞生产的时候遇到的95%的困难前人都留下有解决方案，只不过我不知道罢了。记得从一位前辈的书上看到过这样一句他的老师告诉他的话：理论看不懂就去实践，实践有困难就去理论，反复即可，重复的力量可以摧毁世间任何强大之物。
##控制什么？
从动词开始。要控制权限首先得明白是系统要发生某种变化，“花是红的”这种陈述句是没有什么权限可以控制的。什么样的动作是潜在的需要被控制的动作呢？这个答案很简单——任何动作。但具体哪些控制是有意义的哪些控制是无意义的这要根据你的业务需求具体分析。本文不是分析具体领域的业务逻辑的而是探讨访问控制的方法的。
回顾：动词（Verb）。有动词才有控制，没动词的陈述句是无需控制的。“太阳会落”不需要控制，“林教授对学生说太阳会落”就可能需要被控制，因为‘林教授“说”’，说是动词。下图的Message就可能是含有动词的Command。
如图1
很显然，我们要控制的是cmd，因为它还没有被action（行动），action后就已经成为Event（事实）了没有控制的意义了，下一个控制的机会属于下一个受控区域了。
- Command = Action + Input；
- Action = ResourceType + Verb；
- Event = handledAction + Output；
- Message集 = Command集 + Event集。
Anycmd没有好的方法来表达想法，就让我使用上面的公式来表达吧。这些公式肯定不严谨，比如我都没有定义加法的意义就随意的使用了它。通过这些公式我想表达的意思是**Message分两种：一种是Command，它描述的是尚未发生的事情并且它为事情的发生提供了完整的输入；Event是已经发生过的事情。Command和Event分别是输入与输出。**设想一下确实是这样的，一条message所表达的事情无非是两种：表达某个主体想要针对某个客体做些什么但尚没有做；表达某个主体对某个客体已经做了什么。
从上图可以看出msg在我们的系统中又分为两个阶段：
如图2
- 进入系统后但尚未进入受控区域前；
- 在控区域中。
##如何控制
说明：Ac缩写的意思是Access Control。
那么msg进入我们的受控区域前会是一个比较好的访问控制策略执行点。如果Ac策略设计的合理和使用的得当的话是可以做到仅在一个策略执行点就能完成所有的权限控制工作的。但很多业务系统的功能划分没能做到是完全正交的，这就使得我们无法做到仅在一个执行点来完成所有的Ac事务。没关系，在那些难以覆盖到的受控区域前设立专门的执行点就可以了。比如图1中的handler1我们可以认为是展示层的控制器，因为展示层控制器是收集收入的地方所以在它前面放置AC执行点会是最佳位置，而handler2大家可以认为是应用服务或领域服务，如果将Ac执行点放置在handler2前能够降低你在唯一的前端控制器前实现AC的困难的话也是可以在这里放置Ac逻辑的。 访问控制有很多访问策略信息点。策略信息点是为AC提供信息的。比如msg的类型就是一个策略信息点，前面我们把msg分类为Command和Event两种，而如果当前收到的msg是条Event的话那就是没有控制的必要的，而只有可能引起系统状态变化的Command才是有控制意义的。比如Command声明的action和提供input也是策略信息点，如果我们的message是像http request message那样的无状态的带有完整的一次请求的信息的message的话那么message已经提供了我们的AC所需的所有策略信息点了。当然通常都是有状态的，UserSession也是我们的策略信息点。
**为什么不验证Event权限？**请求分两种：Command和Event。权限只控制Command请求是基于这样的假设的——权限控制是分布式进行的，每一个业务节点中都嵌入有权限引擎。命令进入任何业务节点的时候就已经被那个节点本地的权限引擎验证过授权了，命令被处理后，性质变成了事件，事件可能会通告到远端中心节点，对于远端节点来说这是一个已经发生过了的事情，所以没有控制权限的意义了。如果这个事件后来被发现是非法的，只有通过新命令去以只做加法的方式去修正历史，时间箭头变化方向是一直向前的它是不能往后倒的。 如果希望远端节点也对当前请求的这条命令进行授权验证的话就需要本节点往远端节点转移Command而非Event了，Command和Event没有任何结构上的不同只是性质不同，如果远端节点收到的是Command的话它是会验证权限的。Anycmd是分布式的，中心节点会将安全管理员授权所产生的与各自业务节点相关的权限数据，自动、即时、高效地交换到各自业务节点本地中去，建议所有业务节点永远依靠自己本地的权限引擎来验证权限，永远不要调用远端的接口。
##Anycmd是什么？
Anycmd是一个.net平台的完全开源的，完整支持rbac的，将会支持xacml、javascript的通用的权限框架、引擎、中间件、解决方案。（golang、nodejs、java平台也在推进）
它给出一套方法，将系统中的所有功能标识出来，组织起来，托管起来，将所有的数据组织起来标识出来托管起来， 然后提供一个简单的唯一的接口，这个接口的一端是应用系统一端是权限引擎。权限引擎所回答的只是：谁是否对某资源具有实施某个动作（运动、计算）的权限。返回的结果只有：有、没有、权限引擎异常了。
Rbac非常好，且有国家和国际标准文档。Anycmd会完整的支持Rbac（包括核心Rbac、角色层次Rbac、静态和动态责任分离Rbac），她会大大超出Rbac定义的能力范围，她计划提供一套完整的容易学习的Ac方法论和拿来即可使用的实践框架、引擎、中间件、系统。她会比市面上现有的各种Ac框架来的更加美丽大方、简洁高效。作者有美好的理想并愿意一直为她付诸努力。
XACML是一种用于决定请求/响应的通用访问控制策略语言和执行授权策略的框架，它在传统的分布式环境中被广泛用于访问控制策略的执行。
需要一个良好的标准，需要一些良好的概念，需要一层良好的抽象。需要一个良好的形式。安全管理需要凌驾于具体的业务引擎之上，具体的业务引擎具只是安全“策略执行点”，执行安全策略是业务系统的义务，这个义务执行起来不难，任何一个业务系统都是没有分别的。 像xacml这种东西既有结构又有运算，它在表达安全策略方面是功能完备的。当然没有必要使用xacml把xacml当作C#这种语言来在CLR中书写我们的所有业务逻辑，xacml提供的是一个书写安全策略的规范。规范很重要，有了这层抽象才能做到将安全管理跨越具体的业务系统 Anycmd会支持xacml。 哪些是权限，哪些是业务，它们是没有清晰的分界线的。使用一个良好的权限引擎提供的语言是可以书写出任何业务逻辑的，但是我们应该用它来做它擅长的事情而不是用来书写业务逻辑。 所有的业务逻辑都可以使用权限语言来书写一份等效的代码。问题是这份代码需要策略执行点去解释，而像CLR这种是用来解释C# VB.net CLI这种语言的不是专门用来解释权限语言的，那些逻辑应该使用权限语言书写哪些应该使用C#书写是需要你我根据具体的业务需求和业务的发展变化规律来权衡的。
考虑到大多数程序员掌握xacml可能存在困难，Anycmd会同时提供一份与xacml等效的javascript端口。
Anycmd已经定义好了Account、Catalog、Role、Group、Function、Menu、AppSystem、ResourceType、Privilege这9大Ac元素。并且已经完成了这9种元素的元素集的内存管理代码。如果不追求更高级的特性的话那么她现在基本可以使用了（不建议使用）。
9种Ac元素都应是可以随意的两两组合的，每一种组合都应是有特定的意义的。比如（function1,menu1）可以定义为如果授予主体function1权限那么系统可以自动展示出相应的menu1而无需安全管理员再进行“菜单授权”。比如（role1,role2）的组合可以定义为role1继承role2，当然（role1,role3）表示role1集成role3，你看到了这就是RBAC的层级Role特性在Anycmd中的实现。比如(catalog1,group1)可以定义为把整个catalog1组织结构下的用户逻辑的加入group1工作组。就举这些例子吧，请注意：Anycmd的9类AC元素对象的任意两两组合都是有意义的。如果您感兴趣的话现在可以先观察Anycmd的源码，期待您为Anycmd提供帮助确保她走在正确的道路上。
她从11个变量出发控制具体的业务节点的具体主体对具体类型的具体资源记录实施具体的动作，她还可以深入到这个具体资源记录的具体字段（可以认为这是控制到了行列单元格，当然资源记录不一定存储在关系数据库）。它从11个变量去考量到来的每一条命令（'到来'不是说要跨进程跨网络什么的，到来可以理解为调用，就像调用一个对象的方法）。这11个变量会随着目标数据的被一步步定位而一步步降维。11个变量到达具体的数据单元格的时候就只剩下两三个维度了，设计为终极降到为两个变量（主体和客体），因为如果降到只有一维的话世界失去了意义。