开源权限引擎-anycmd视频介绍《anycmd筑基》

用于帮助群友和感兴趣的同学快速知晓anycmd是什么?权限引擎是什么?应群友要求昨天用QQ群录制了一个视频,现已未做任何剪辑放在了土豆上分享大家。 感谢jdon感谢banq让我学到很多才有了最近的思考。

第一次录视频,有改进余地。欢迎吐槽

视频地址:http://www.tudou.com/programs/view/4jXoarZKwCk/

提纲:

主体、客体、运动
1 权限引擎是什么?
2 它是开源的,开源协议是什么?mit
开源多久了?开发了多长时间了?
3 它构建到什么程度了
什么是200层?
前100层是功能级权限,后100层是数据级权限。
前100层基本上是可用的了
4 它符合国家和国际标准吗?
5 国家和国际标准有哪些?
rbac、xacml、javascript
6 哪里可以找到资料
7 它是分布式的
权限数据交换
8 权限数据标准
9中AC元素
9 构造定律、树形结构
如何构建一个系统?相信它是树形的。
树形在代码里对应的是什么?
资源树、运动树。
字段、方法。


主体:指对客体有认识和实践能力的对象。比如人、系统、服务提供者、服务消费者等。
客体:可被主体感知或想象到的任何事物。如文件、打印机、终端、数据库记录等。
对象/资源:资源是需要进行访问控制的系统资源,例如文件、打印机、终端、数据库记录等。
资源类型:基于人类发明的分类法对资源按照性质、特点、用途等作为区分的标准而做的第一次分类。
权限:对受保护的对象执行某个操作的许可。
操作:一个过程,这个过程通常有输入与输出,这个过程可能影响系统的状态也可能不影响系统的状态,是否影响系统的状态有赖于你的领域边界。首先基于资源类型定义一类资源的操作列表,通常这就够了,但也有可能会需要针对特定对象实例定义操作列表。
这些术语从哪来的?国家标准文档上。
标准文档很好,不要害怕读不懂。


有9种AC元素:Account、Organization、Role、Group、Function、Menu、AppSystem、ResourceType、Privilege。
Privilege的定义是这9种AC元素的任意两两组合,两元中的一元是“主体”,一元是“客体”,主体负责感知客体。区分主客体就是为这两两组合定义了方向。一共是(9 * 8)/(2*1) = 36 + 9 = 45种结果。
在功能级权限的这45种组合中只有一种组合最关键:(Account,Function),主体是Account,客体是Function。其余44种组合的目的最终都是为了得出这个主体为Account客体为Function的组合。
每一个组合实例称作一个Privilege,Privilege也是9种AC元素的一员,有一种组合比较特殊,它是(Privilege,Privilege),这种组合目的是组成Privilege的继承链条,类似面向对象中的继承。另外上面的36+9中的9种是(Account,Account)、(Organization,Organization)、(Role,Role)、(Group,Group)、(Function,Function)、(Menu,Menu)、(AppSystem,AppSystem)、(ResourceType,ResourceType)、(Privilege,Privilege)。
功能级的权限是常驻内存的。
进入数据权限的时候又多了一个元素,第10种元素是Entity或者叫资源记录,数据级权限是10种AC元素的组合。数据级权限和资源记录存储在相同的物理位置,随同对资源记录的访问一起加载进内存,用完后随时丢弃不会常驻内存。
按照rbac标准上的说法是能够完成任何功能级的权限控制的,那么多ac元素最终都是为了得到(account,function)组合,系统运行到一个受控的区域时什么都不管只认(account,function)组合,只问当前用户是否可以执行当前function。
要鉴权只需要知道当前的account和当前正在试图访问的function分别是什么,其中account可以从UserSession中直接读取,而如何识别function相对曲折,对于asp.net mvc来说可以基于这样的约定:ControllerName=ResourceTypeCode,ActionName=FunctionCode,知道了ResourceType.Code和Function.Code就可以直接到FunctionSet中索引到function了。


为了开始构建后100层的数据级权限,anycmd需要尽快为前100层的功能级权限打个好节。
anycmd构建时找到的最重要的指向标是:始终以(主体,客体)的两两组合为中心,始终将主客体组合看作干流,始终将那单个的9种AC元素看作是支流。


关于鉴权流程的捕获和冒泡子流程:
anycmd的鉴权流程会像dom那样(dom是树),有捕获流程还有冒泡流程。
当前节点要发生某件事情(运动)的时候如果它确定不了权限则往上进行鉴权冒泡,权限管理员可以在靠近根节点的少数节点中书写少数的逻辑也可以在远离根节点的节点中书写精确的逻辑。它往上冒泡询问它的父节点是否允许当前运动的发生?一直往上冒泡直到明确的得知是允许还是不允许。
它会支持javascript,安全管理员可以通过在整棵树的任意节点书写javascript来处理捕获和冒泡。
技术不新鲜但是这种概念被应用到权限管理领域还是比较新鲜的
所以说她计划盖200层楼,现在才盖100层楼,而当今在这个领域平均才50层楼。

讲得很诚恳,继续努力。感谢你对我的提名。

我们知道,在功能级访问控制中至少会有Account、Catalog、Role、Group、Function、Menu、AppSystem、Privilege这几种元素。并且之前我们认识到这若干种元素是可以任意两两组合的,(Account, Account)、(Account, Catalog)、(Catalog, Role)等每一种二元组都是可以有明确的访问控制意义的。到达数据级权限的时候就是又多出了一个元素:Object。这种Object元素也要与前面几种元素任意两两组合并且有明确的意义。每一种组合一定都是有意义的,合适的意义到底是什么这需要我们去发现。

最近发现前面那样的无方向的二元组的粒度不够。二元组合需要分裂为二元排列。比如(account1, account2)需要分裂为<account1, account2>和<account2, account1>,(catalog1, role1)需要分裂为<catalog1, role1>和<role1, catalog1>,(role1, function1)需要分裂为<role1, function1>和<function1, role1>等。

<Catalog,Role>和<Role,Catalog>是不同的,<Role,Catalog>也有意义。以前没发掘出<Role,Catalog>的意义,现在发现了。<Role,Catalog>的意义是限定role的作用范围,<role1,catalog1>和<role1,catalog2>共同限定了role1的作用范围只能是在catalog1和catalog2目录下,主体进入这俩目录的时候才会激活主体的role1角色,主体出了这俩目录时role1就被收回。而<catalog1, role1>的意思是授予catalog1主体目录下的主体role1角色。catalog1是主体目录,可以是组织机构(组织机构目录树上的每一个节点下组织的资源包括桌子、电脑、办公室等,重要的是包括“员工”这种主体类型的资源)。组织机构是一棵树,单继承的。如果subject1是catalog1.catalog1.001节点下的主体的话,由于<catalog1, role1>这条记录的存在,subject1就可以沿着组织机构树获得role1角色。

如果按照把一条二元组合记录分裂为两条二元排列记录这种模式思考的话会发现(Role, Function)可以被拆分为<Role, Function>和<Function, Role>。<Role, Function>是角色授权的意思,而<Function, Role>可以解释为:限制给定的功能可被授予的角色的范围。<function1, role1>、<function1, role2>、<function1, role3>
这三条记录共同限制function1只能被授予role1、role2、role3角色不能被授予role4角色。

由“Account、Catalog、Role、Group、Function、Menu、AppSystem、Privilege”这些元素组成的任意二元排列在权限引擎中都应有明确的意义,后续我们一一发现。至此终于完善了模型,一条二元排列记录由两个元素按照顺序组合得到,不可能再继续分裂了,再继续分裂就是对元素进行分裂了(对元素进行分裂是这样的分裂:比如Function这种类型的元素会被分裂为名称、入参、返回值,入参是个列表继续分裂,返回值也是列表也可以继续分裂。无论在什么层次运用组合和分裂,模式一定都是完全一样的,因为世界是分形的)。

看样子虽然以前的文字中一直使用的“组合”这个词,代码上却一直用的是“排列”,现在终于一致了。