本文主要是介绍【权限管理】RBAC 和 ABAC的对比，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
RBAC 和 ABAC的对比
- RBAC
- 三个组成部分
- 使用
- 优缺点
- ABAC
- 属性
- 访问策略示例
- 优缺点
- RBAC 和 ABAC的对比
RBAC
基于角色的访问控制（role-based access control RBAC)
三个组成部分
- 用户
- 角色
- 权限
使用
- 当用户访问系统时，根据用户具备什么角色，允许用户访问哪些菜单、允许访问那些资源。
- 需要创建拥有不同权限组合的不同角色，比如A角色具有xx权限，B角色拥有yy权限。
- 需要授予用户权限时，直接授予用户某个角色。
- 当用户访问系统的某项资源时，如果具备相应的角色，那么系统认为可以访问。
优缺点
优点：
- 便于职责的分离
- 授权方便
缺点：
- 新增资源时，需要维护所有相关的角色
- 只能根据静态的参数进行判断
ABAC
基于属性的访问控制（attribute-based access control ABAC）
当用户访问系统时，根据用户请求时具备的属性，允许用户访问哪些菜单、允许访问那些资源。
属性
属性包括：
- 用户属性：比如用户的职级、组织、角色。
- 环境属性：比如访问的时间、访问的IP。
- 资源属性：比如资源的创建日期、资源的敏感性。
- 操作属性：增删改查
访问策略示例
当用户请求系统时，根据当前的属性，指定不同的访问策略：
- 下班时间，不允许访问公司网络，或需要进一步校验身份。
- 根据职级 + 资源敏感性，确定用户是否有访问权限。
- 根据职级 + 职位 + 是否在公司内网， 决定用户是否可以下载代码。
优缺点
优点：
- 更加灵活，控制更加细粒度，且根据上下文动态执行
- 新增资源时，只需要维护较少的资源
缺点：
- 模型构建相对复杂
RBAC 和 ABAC的对比
| RBAC | ABAC |
|---|---|
| 基于角色 | 基于属性 |
| 根据角色直接具有某些权限 | 根据访问时属性，动态决定是否具有访问权限 |
| 新增资源较繁琐 | 新增资源简单 |
| 模型简单 | 模型复杂 |
【仅代表作者个人观点，欢迎大家讨论自己的理解，如有错误，欢迎指正！】
【如果对你有所帮助，希望可以点赞收藏支持一下！】
这篇关于【权限管理】RBAC 和 ABAC的对比的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
