权限管理中，Group和Role究竟有什么却别？

要理解基于角色的权限系统含义RBAC
角色和组（groups）是有区别的，组是就是纯粹代表一群用户；角色一方面代表一系列用户，另外一方面可以代表一系列权限，因此可以说是用户和权限的结合体。

我在实现时，把group看作一个特殊的role,group下的role自动从所属的group中继承权限

Group和Role的区别，我自己理解是这样的：Group是一个或多个具有Role的User组成的，而Role是由某些权限组成的权限集，它可以赋给User。不知道这样说是不是正确呢？

千万不要把group和role混淆在一起

为什么会诞生RBAC？因为以往大家都是把用户和权限混淆在一起，这样当用户或权限变动时，都会涉及到对方，很显然这在实际中是非常复杂的，所以诞生RBAC，创造一个角色名词，注意这是人为创造的语义词，角色就是用户和权限之间的第三者，通过引入角色概念，将用户和权限的关系解耦，这样用户的变化只要涉及到角色就可以，无需考虑权限，而权限的变化只涉及到角色，无需考虑用户或用户组。

我对Group和Role的理解如下：
Group是拥有某些权限的用户的抽象。
Role是一组权限的集合。
这样一来，Group和权限打交道，用户和Group打交道。

这样做的好处是什么呢？非常同意banq的话：将用户和权限的关系解藕。

Role的概念曾得到广泛的应用。但从本质上讲，它只是一组权限罢了...

不对之处，请指正

个人认为Group应该和用户打交道,而ROLE和权限打交道,然后通过GROUP与ROLE的关系,来建立,用户与权限的关系

Group一般是静态的，
Role一般是动态的。

个人认为，group是user的集合，group也可以与role建立映射关系。三者两两之间都是多对多的关系。

我觉得主体不同。
group代表一个群体，拥有共同的特征，出于管理的需要。
角色代表了用户的行为能力，他很难独自成为用户分组的依据。
应该说，group和role一横一纵。就好像一个项目组（group）里头有很多个岗位角色(role),他们都是和实际生活直接联系的，不是凭空捏造出来。

“我觉得主体不同。group代表一个群体，拥有共同的特征，出于管理的需要。角色代表了用户的行为能力，他很难独自成为用户分组的依据。应该说，group和role一横一纵。”----tomfan的描述很清晰，受启发。
补充一下，当行为能力或许可被抽象成Role后，必然会损失掉许多特性，而划分Group，恰恰可以将损失的特性弥补回来。

我有一个疑问，Role 的层级继承是一个很好的想法，但是在真实的应用中，倒底会用到多少级的层级继承关系呢? 管理员会不会这样用呢?

我个人觉得，层级继承太多，对管理员来说维护成本会增加。
一般我们会将问题简单化，如果一级 Role 就能解决问题我们决不希望用到二级 Role。那么在实际应用中，这样的层级继承到底应用有多广呢？如果应用不广，去实现这样花时耗力的功能是不是不太值得呢?

我是这样理解的：

1、一个role有很多user,这些user的权限相同。
2、一个group也有很多user,这些user的权限可以相同，也可以不同。
3、一个group也有他自己的权限，其中的user都继承这些权限。

不知道对不对请多指教。

“一个group也有他自己的权限，其中的user都继承这些权限。”
我觉得Group应该是没有什么权限的。

Role是权限关系
Group是业务关系

我想问：各个Role之间应该是包含关系呢，还是各自分开但又有交集？

group，物理组，是一类人的集合；
role，逻辑组，是一类能作的事情的集合。

二者对应就产生了我们现实中讨论的组