访问控制之9种元素

anycmd 发布于 2014/10/17 09:49
阅读 419
收藏 1
anycmd是个权限引擎:
使用者初始化这个引擎的状态,然后往这个引擎中输入一个运动的标识它会回答是否允许这个运动发生:允许、不允许、我异常了(权限引擎异常了)。
如何标识一个运动?有这么几个要素:1 谁发起的这'个'运动,2 这'种'运动的‘种’标识。3 这个运动的实参列表。
所谓运动,其实就是一个过程,其实就是一个计算。
其实就是一个输入和输出。其实就是对象的方法啦,没什么高深的
他使用“运动”这个概念,而不使用更具体的概念是想表明,它是设计用来控制任何运动的。
比如3D打印机的打印运动,不停的运动,系统不停的采样,不停的改变权限引擎的状态,然后终于发现用户99%是在试图打印一把枪!
枪有它的核心模型,无论你怎么伪装,打印出来的枪都是使用同样的物理定律去发射子弹的,它的那个核心模型是一样的,anycmd就是要采样识别出他们的伪装从而在这个运动完成之前终止它!
在运动完成之前总是有办法终止这个运动。计算机指挥3D打印机打印的运动过程只是它的父过程的子过程,还有打印后从3D打印机中取结果的过程啊,没有权限就让你取不出。


anycmd明白rbac处在acl和安全策略语言中间的意义和重要性,anycmd明白人们花费集体智慧人力指定出标准的意义和重要性。anycmd致力于让高高在上的国家标准、国际标准发挥价值。
anycmd定义了可以任意两两组合的9中AC元素:Account 、Organization、Role、Group、Function、Menu、AppSystem、ResourceType、Privilege(暂不支持,该取值的存在是为了概念完整性。组成授权路由链表。如同面向对象机制中类的“继承”)。


发现有很多概念相互交叉甚至能够相互替代。比如Group被定义为‘资源组’,复杂的Group中放置的可以是不止一种类型的资源对于这种组改称‘手工仓库’,而组中只放置了一种资源的组称‘简单组’。按照这种思路理解的话Role其实也是一种组,Role这种组中放置了两种资源:Account和Privilege。工作组也是组,工作组中放置的也是两种资源:Account和Role。
anycmd中有9中ac元素,为什么这么多种元素?这不是我抽象出来的,而是观察现在的世界观察出来的。人们抽象出这些元素是为了帮助简化复杂的问题,这9种ac元素是站在一个更低的抽象层次来观察的,而在高一级的抽象层次看ac只有三种元素:主体、资源、运动
组织结构是对资源的单元划分,组织结构节点是边界,每一个边界绑定的角色应该只在当前用户进入这个边界后激活离开这个边界后收回,从而不能将从一个边界内得到的角色带出这个边界去操作其他边界内的资源。
计划从11个维度去考量到来的每一条命令('到来'不是说要跨进程跨网络什么的,到来可以理解为调用,就像调用一个对象的方法)。11个维度的叫法是不是正确我也不知道,11个维度的本意是想要提取出11个基本变量,控制权限就是从这11个变量出发去控制。


但是现在发现这11个变量不一定都是完全正交的,应该去除若干个。应该会随着目标数据的被一步步定位而一步步降维。
11个维度到达具体的数据单元格的时候可能只剩下两三个维度了,设计为终极降到为两维,因为我感觉如果将级为只有一维的话世界失去了意义。
加载中
0
花和尚鲁智深
花和尚鲁智深
我们知道,在功能级访问控制中至少会有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这种类型的元素会被分裂为名称、入参、返回值,入参是个列表继续分裂,返回值也是列表也可以继续分裂。无论在什么层次运用组合和分裂,模式一定都是完全一样的,因为世界是分形的)。

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