首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

RBAC新解:基于资源的权限管理(Resource-Based Access Control)

本文讨论以角色概念进行的权限管理策略及主要以基于角色的机制进行权限管理是远远不够的。同时我将讨论一种我认为更好的权限管理方式。 什么是角色 当说到程序的权限管理时,人们往往想到角色这一概念。角色是代表一系列可执行的操作或责任的实体,用于限定你在软件系统中能做什么、不能做什么。用户帐号往往与角色相关联,因此,一个用户在软件系统中能做什么取决于与之关联的各个角色。 例如,一个用户以关联了”项目管理员”角色的帐号登录系统,那这个用户就可以做项目管理员能做的所有事情――如列出项目中的应用、管理项目组成员、产生项目报

07
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    RBAC

    什么是角色 当说到程序的权限管理时,人们往往想到角色这一概念。角色是代表一系列可执行的操作或责任的实体,用于限定你在软件系统中能做什么、不能做什么。用户帐号往往与角色相关联,因此,一个用户在软件系统中能做什么取决于与之关联的各个角色。 例如,一个用户以关联了”项目管理员”角色的帐号登录系统,那这个用户就可以做项目管理员能做的所有事情――如列出项目中的应用、管理项目组成员、产生项目报表等。 从这个意义上来说,角色更多的是一种行为的概念:它表示用户能在系统中进行的操作。 基于角色的访问控制(Role-Based Access Control) 既然角色代表了可执行的操作这一概念,一个合乎逻辑的做法是在软件开发中使用角色来控制对软件功能和数据的访问。你可能已经猜到,这种权限控制方法就叫基于角色的访问控制(Role-Based Access Control),或简称为RBAC。

    02

    政采云大数据权限系统设计和实现

    权限管控是一个应用系统最重要的基础能力之一,通常权限可以分为功能权限和数据权限,功能权限主要用来控制用户可以执行的操作,即用户可以做什么;数据权限则控制用户可以操作的对象范围,这里的对象指业务数据,数据权限进一步细化还可以分为行级权限和字段级权限,如控制用户可以查询本部门的数据,而不能查看其他部门数据,或者只能查看一条业务数据的部分字段信息。我们接触的数据权限通常是指对某一个应用系统内部的业务数据进行管控,这些业务数据由用户的行为活动产生,如一个交易应用中的交易数据,通常用户只能查看到自己的交易记录,这就是最基本、最常见的数据权限管控策略。大数据权限系统需要管控的数据范围要大的多,包含了数据仓库中的所有表,同时管控的用户也并非普通的应用系统用户(产生数据的用户),而是数据开发人员、数据分析人员等(使用数据的用户)。本文将着重介绍政采云大数据权限系统的数据权限管控。

    01

    前端monorepo大仓权限设计的思考与实现

    前端 monorepo 在试行大仓研发流程过程中,已经包含了多个业务域的应用、共享组件库、工具函数等多种静态资源,在实现包括代码共享、依赖管理的便捷性以及更好的团队协作的时候,也面临大仓代码文件权限的问题。如何让不同业务域的研发能够顺畅的在大仓模式下开发,离不开有效的权限管理方法。好的权限管理方法能够确保研发同学轻松找到和理解项目的不同部分,而不受混乱或不必要的复杂性的影响,并且也应该允许研发同学合作并同时工作,同时也要确保代码合并的更改经过代码审查,以维护代码的质量和稳定性。本文通过实践过程中遇到的一些问题以及逐步沉淀下来的最佳实践,来阐述下前端大仓 monorepo 在权限这块是如何思考以及设计的。

    03

    权限系统设计概述

    2. 权限系统要素 资源:授权访问。 角色:访问资源的证书,定义了资源访问的界限,作为一个粗粒度的资源访问权限控制。 主体:访问资源的对象,通常为登录用户。 权限:访问资源的具体限定,权限可以细分为操作权限和数据权限。 - 操作权限:体现在2个方面,其一:通过界面来体现,具备操作权限的人才可以在界面上看到对应资源;其二:访问指定资源时进行权限检查。 - 数据权限:主体只能看到/操作他具备访问权限的资源,数据权限的设计可以通过数据库字段管关联来实现。 另外,可以根据权限系统设计的复杂性来决定权限控制粒度。可以将权限独立出来和角色进行组合,理解为通过角色和权限双重身份来限定主体授权访问资源;也可以将权限与角色关联,通过角色来定义主体/分组的权限。 分组:通常对应于现实事物中的部门,主体属于分组,为分组定义角色。

    03
    领券