anycmd所理解的rbac：报错
有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元素看作是支流。######
有可能，subject 这部分过细了？ principal（Account、Organization、Role、Group）这几种很好。
######是的。principal（Account、Organization、Role、Group）这几种算作用户主体，剩余几种算作系统主体。用户主体主要是面向人的，系统主体主要是面向系统的（我们的系统和和我们的系统连接的系统），通常普通用户不关心系统主体。######追加：
我们知道，在功能级访问控制中至少会有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这种类型的元素会被分裂为名称、入参、返回值，入参是个列表继续分裂，返回值也是列表也可以继续分裂。无论在什么层次运用组合和分裂，模式一定都是完全一样的，因为世界是分形的）。
看样子虽然以前的文字中一直使用的“组合”这个词， 代码 上却一直用的是“排列”，现在终于一致了。2020-06-07 13:54:43赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
