一点愚见欢迎讨论:RBAC角色不应该分层(RBAC1不合时宜)。 Access
程序员文章站
2024-02-22 14:17:22
...
刚才在回别人的帖子的时候谈了一下自己对RBAC的一点看法，还有关于我自己职务职位的认识，希望大家批评指证。
我认为销售人员是岗位而不是角色，角色是一系列权限的集合，而岗位是属于基础数据的范畴，所以这里角色的定义是
角色：{
修改用户资料：否,
其他：可
}
置于角色到底需不需要分出层级，这个就是仁者见仁，淫者见淫的话题了
我觉得这里有几个概念需要梳理一下：岗位，职务，职位，权限，角色。
我的理解是这样的：
毫无疑问，权限是这些概念中的最细粒度的一个东西，
而角色是一组权限的集合。
岗位是职位的同义词，他们的侧重点不同。
职务才是被大家忽略的一个概念：
具体我不知道他是怎么定义的，但是我认为他是某一业务中某一角色应当承担的责任或者说应该负责的事。
而一个职位一般来说有多个职务，比如说我们的经理助理这么一个"职位"他可能要负责的事情可能有很多类：
如，协助安排经理的日程，对下面呈上来的某类报告做初步审理等等一条条。这些被我们认为梳理出来的一条条的东西就是职务 - 他在当前职位上需要担负的义务。
大家初期容易将岗位抽象成一个角色，但是最终发现这个角色可能粒度太粗或者是不宜重用，这个时候就应该梳理一下每个职位的职务，以职务为单位抽象成角色，这样才能制定出更细粒度更好重用的角色。
当然职位由于他是我们看的见摸得着的，所以直接将职位映射成角色是非常简单清晰没有异议的，而职务就不同了，他需要我们it人员深入理解客户的业务，这样才能根据客户的业务情况梳理出一个业务职务体系，这个过程必然会很辛苦。
另外我认为角色绝绝大多数情况是不需要分级和分层的。RBAC中居然还用了derive，inheritance这样的字眼来描述两个角色之间可能存在的关系，我觉得这是一个错误。现代组织中为了完成业务，大多推崇的是分工合作，就是说一个团队中每个人的角色/职责是很清楚的，而不是一种早期“经理有权做手下小兵A能做的任何事情”，实际上企业的要求是“小斌A应该干这个，经理B应该干这个”，不能越级*，同样也不能越俎代庖！即使现在不是这个样子也会朝着这个趋势发展。如果承认这一点，那角色间就不可能存在继承关系，顶多是一些组合关系。ＲＢＡＣ中列举里例子更是把这个缺陷暴露无疑了：
书上举得例子是说Cardiologist和Oncologist本身就是Physician，所以他们具有Physician的所有权限
Cardiologist Oncologist
\ /
\ /
Physician
|
| Accounts receivable clerk
|
Resident
这个例子不能令人新服指出是他把Physician，Resident，clerk抽象成了一个个"角色Role"的同时，违背了RBAC的Role的本意 - “角色是一组权限(Permission)的集合”。Role是权限的集合，而不是属于角色的用户们的一种关系的表达，跟用户是什么身份没有任何关系，如果有关系，也是反过来：用户的身份和角色有关系。
我枉自猜测会出现这么一个问题的原因是： RABC当时如日中天，大家都认为找到了真理。手里握着锤子，就习惯把一切柱状物看成是钉子。ABAC的概念估计就是被锤子锤的受不了才出现的 ^_^ .而实际上这个权限的例子可以很好的用(ABAC)Attribute-based Access Control来表达(因为Cardiologist,Oncologist,Physisican，clerk都是用户可能的属性).
yangyi 写道
我认为销售人员是岗位而不是角色，角色是一系列权限的集合，而岗位是属于基础数据的范畴，所以这里角色的定义是
角色：{
修改用户资料：否,
其他：可
}
置于角色到底需不需要分出层级，这个就是仁者见仁，淫者见淫的话题了
我觉得这里有几个概念需要梳理一下：岗位，职务，职位，权限，角色。
我的理解是这样的：
毫无疑问，权限是这些概念中的最细粒度的一个东西，
而角色是一组权限的集合。
岗位是职位的同义词，他们的侧重点不同。
职务才是被大家忽略的一个概念：
具体我不知道他是怎么定义的，但是我认为他是某一业务中某一角色应当承担的责任或者说应该负责的事。
而一个职位一般来说有多个职务，比如说我们的经理助理这么一个"职位"他可能要负责的事情可能有很多类：
如，协助安排经理的日程，对下面呈上来的某类报告做初步审理等等一条条。这些被我们认为梳理出来的一条条的东西就是职务 - 他在当前职位上需要担负的义务。
大家初期容易将岗位抽象成一个角色，但是最终发现这个角色可能粒度太粗或者是不宜重用，这个时候就应该梳理一下每个职位的职务，以职务为单位抽象成角色，这样才能制定出更细粒度更好重用的角色。
当然职位由于他是我们看的见摸得着的，所以直接将职位映射成角色是非常简单清晰没有异议的，而职务就不同了，他需要我们it人员深入理解客户的业务，这样才能根据客户的业务情况梳理出一个业务职务体系，这个过程必然会很辛苦。
另外我认为角色绝绝大多数情况是不需要分级和分层的。RBAC中居然还用了derive，inheritance这样的字眼来描述两个角色之间可能存在的关系，我觉得这是一个错误。现代组织中为了完成业务，大多推崇的是分工合作，就是说一个团队中每个人的角色/职责是很清楚的，而不是一种早期“经理有权做手下小兵A能做的任何事情”，实际上企业的要求是“小斌A应该干这个，经理B应该干这个”，不能越级*，同样也不能越俎代庖！即使现在不是这个样子也会朝着这个趋势发展。如果承认这一点，那角色间就不可能存在继承关系，顶多是一些组合关系。ＲＢＡＣ中列举里例子更是把这个缺陷暴露无疑了：
书上举得例子是说Cardiologist和Oncologist本身就是Physician，所以他们具有Physician的所有权限
Cardiologist Oncologist
\ /
\ /
Physician
|
| Accounts receivable clerk
|
Resident
这个例子不能令人新服指出是他把Physician，Resident，clerk抽象成了一个个"角色Role"的同时，违背了RBAC的Role的本意 - “角色是一组权限(Permission)的集合”。Role是权限的集合，而不是属于角色的用户们的一种关系的表达，跟用户是什么身份没有任何关系，如果有关系，也是反过来：用户的身份和角色有关系。
我枉自猜测会出现这么一个问题的原因是： RABC当时如日中天，大家都认为找到了真理。手里握着锤子，就习惯把一切柱状物看成是钉子。ABAC的概念估计就是被锤子锤的受不了才出现的 ^_^ .而实际上这个权限的例子可以很好的用(ABAC)Attribute-based Access Control来表达(因为Cardiologist,Oncologist,Physisican，clerk都是用户可能的属性).