我认为没必要去划分的太清楚，不管是组还是角色，都是为了更好的管理和分配权限在最原始的ACL模型上做的改进。如果有需要，甚至可以把权限分配到部门，职位上。
MAC(Mandatory Access Control)(强制访问控制)MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中，每一个对象都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。访问时，系统先对用户的访问许可级别和资源对象的密级进行比较，再决定用户是否可以访问资源对象。用户不能改变自身和资源对象的安全级别，只有系统管理员或管理程序才能 控制资源对象和用户的级别。比如在影视作品中我们经常能看到特工在查询机密文件时，屏幕提示需要“无法访问，需要一级安全许可”，这个例子中，文件上就有“一级安全许可”的权限标识，而用户并不具有。
MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。
MAC可以继续使用DAC的模型，但是要对用户进行等级划分，比如一级，二级，三级。。。，对对象资源也要做划分，比如机密，秘密和最高机密。用户访问的资源的时候，根据用户等级与资源访问级别来做判断，比如一级用户只能访问机密文件，如果访问的是最高机密文件，系统就会拒绝。这一系列规则是优先于DAC的，如果MAC与DAC混用，要先校验MAC再校验DAC。
RBAC(Role-Based Access Control)(基于角色的访问控制)ACL的访问控制机制中，直接维护的是用户与功能的关系，这一系列的关系就是一个权限列表。当很多的用户具有相同功能权限的时候，就要进行繁琐的关联操作。RBAC就是在用户与权限之间引入了角色的概念。用户与角色之间做关联，权限列表维护的是角色与功能的关系。
RBAC是目前使用最普遍的权限控制模型。当某些用户具备相同的权限的时候，只需要为这些用户建一个角色，把相应的功能关联到这个角色上，生成角色的权限列表。当有新的用户需要相同权限的时候，把用户关联到这个角色上即可。而当用检查或校验用户的操作权限的时候，查询用户所属角色的权限列表即可。
当然，RBAC也不是完美的，比如想要为某个用户单独设置某个功能权限，可能需要为这个功能权限单独创建一个角色，然后把特定的用户关联到这个角色上。当想要移除某个用户的特定功能权限的时候，可能需要重新设置角色的功能权限，把特定功能权限从当前角色中移除，建立新的角色并关联特定的功能权限，然后再把新角色与相关的用户做关联(也可以直接在特定功能的程序里校验操作用户)
这里说一个比较常见的RBAC的错误的用法：那就是直接使用角色做权限判断。比如只有角色A才能做文章的删除操作。
function delPost(postId){ if(!isRole('A')){ return false; } }如果需求该为角色B也可以删除文章。那就必须修改代码
function delPost(postId){ if(!isRole('A')&&!isRole('B')){ return false; } }正确的做法应该是添加"删除文章"这个功能，把这个功能关联到相应的角色上。判断的时候是根据功能去判断而不是角色。
function delPost(postId){ if(!hasPermission('POST_DEL')){ return false; } }针对“只有角色A才能做文章的删除操作”这一需求，把这个删除功能关联到角色A上，然后把需要这个操作权限的用户加入到角色A中即可。当别的角色也需要这个操作权限，把功能关联到对应角色上即可，不需要再修改代码。
在RBAC的核心基础上，还可以做相应的扩展，比如角色继承，角色分组之类的，这些扩展都是为了在一定程度简化权限管理工作。
ABAC(Attribute-Based Access Control)(基于属性的权限控制)RBAC虽然是目前最普遍的权限控制模型。但是某些情况下，RBAC是无法满足并且也实现不了的。比如业务员1和业务员2都属于业务员角色，都有查看客户订单的权限。当有一个需求，要求业务员1只能查看北京地区的客户的订单，业务员2只能查看上海的客户的订单。这单单使用RBAC是无法实现。借助RBAC，可行的做法是，分地区创建角色，然后程序中根据角色做数据的过滤，这种做法缺点之前也提到过，需求变更的时候可能需要每次都修改代码。