精华内容
下载资源
问答
  • saas erp权限设计For many SaaS applications, product designers need to design permission systems because of the concern of privacy and safety of data, or in order to make it more efficient and relevant...

    saas erp权限设计

    For many SaaS applications, product designers need to design permission systems because of the concern of privacy and safety of data, or in order to make it more efficient and relevant for different types of users to use. That could be a challenge to set up the structure and scale it as your product evolves.

    对于许多SaaS应用程序,产品设计师出于隐私和数据安全性的考虑,需要设计许可系统,或者为了使其更加有效和与不同类型的用户相关而设计。 随着产品的发展,设置结构和扩展规模可能是一个挑战。

    I’ll share some concepts and thinking based on my experience designing permissions for an enterprise data and workflow management tool.

    基于我为企业数据和工作流管理工具设计权限的经验,我将分享一些概念和想法。

    Things to expect in this article:

    本文期望:

    • User and role management

      用户和角色管理
    • Permissions management: page, operation, and data permissions

      权限管理:页面,操作和数据权限
    • Permission precedence rules

      权限优先规则
    • Tips for designing permissions

      设计权限的提示

    1.用户和角色管理 (1. User and Role Management)

    1)RBAC模型 (1) RBAC model)

    The most popular model to organize permissions is RBAC (Role-Based Access Control), which uses roles to categorize users and manage permissions for each role. Instead of explicitly listing all the available options to individual users (ACL), this method can largely save admins’ time. It also makes it easier to configure correctly by working the way administrators think.

    组织权限的最流行模型是RBAC( 基于角色的访问控制 ),它使用角色对用户进行分类并管理每个角色的权限。 此方法无需显式列出单个用户的所有可用选项( ACL ),而是可以大大节省管理员的时间。 通过管理员的思考方式,这也使正确配置更容易。

    Diagrams comparing ACL model vs RBAC model
    ACL vs RBAC model
    ACL与RBAC模型

    User roles are serving as a hub between users and permissions, so admins only need to assign roles to each user and configure which permissions the roles have.

    用户角色充当用户和权限之间的枢纽,因此管理员只需要将角色分配给每个用户并配置角色拥有的权限。

    Diagram for users, roles, and permissions
    Roles as hubs
    充当枢纽

    A popular way to manage users is to design a user list to show the information of users and allow admin to assign their roles.

    管理用户的一种流行方法是设计用户列表以显示用户信息并允许管理员分配其角色。

    Mockup for user management
    User management
    用户管理

    After assigning roles to users, admins need to configure the permissions for each role. They may also need to add new roles or duplicate, delete existing roles.

    在为用户分配角色后,管理员需要为每个角色配置权限。 他们可能还需要添加新角色或复制,删除现有角色。

    Mockup for user role management
    User role management
    用户角色管理

    2)用户组权限 (2) User group permissions)

    As your product becomes more complex and serving hundreds of people within a company, directly assigning roles to each user becomes time-consuming and hard to manage. Imagine you’re adding a new office to the software and have to assign roles to 50 users one by one.

    随着您的产品变得越来越复杂并为公司中的数百人提供服务,直接为每个用户分配角色变得既费时又难于管理。 想象一下,您要在软件中添加一个新办公室,并且必须将角色一一分配给50个用户。

    Here’s where user groups come in. Beyond the basic RBAC model, you can use groups to categorize users and only assign permissions to the groups.

    这里是用户组的所在地。除了基本的RBAC模型之外,您还可以使用组对用户进行分类,并仅向组分配权限。

    Diagram for RBAC with user groups
    RBAC + User groups
    RBAC +用户组

    The user groups usually follow human organizational structures. For internal users, the groups could be departments or offices. For external users invited to the application, user groups could be companies.

    用户组通常遵循人类的组织结构。 对于内部用户,组可以是部门或办公室。 对于受邀加入该应用程序的外部用户,用户组可以是公司。

    Diagram for user groups for internal users and external companies
    User groups for internal users and external companies
    内部用户和外部公司的用户组

    3)继承权限 (3) Inheriting permissions)

    For large organizations, the super admin may want to assign sub-admin within each group to allow micro permission management. Also, the permissions within a group can be inherited. That means the leader of the group should have the collection of all the members’ permissions and extra permissions as well.

    对于大型组织,超级管理员可能希望在每个组中分配子管理员,以允许微权限管理。 同样,可以继承组中的权限。 这意味着组长应具有所有成员的权限以及额外权限的集合。

    Diagram for inheriting permissions
    Inheriting permissions
    继承权限

    4)权限如何优先 (4) How permissions take precedence)

    Depending on applications and use cases, you may be able to assign permissions both to individual users and each group. It’s important to specify how the application gives precedence among the permissions directly assigned to dividual users, group permissions, and inherited permission.

    根据应用程序和用例的不同,您可能可以将权限分配给单个用户和每个组。 重要的是指定应用程序如何在直接分配给单独用户的权限,组权限和继承的权限中赋予优先级。

    It should try to be aligned with the actual administration system. I’m showing the permission precedence rule of Oracle below as an example.

    它应尝试与实际的管理系统保持一致。 下面以Oracle的权限优先规则为例。

    Oracle gives permission precedence in this order: 1. Service Admin role has the highest permissions. 2. Permissions that are specifically assigned to dividual users. 3. Permission assignments that are acquired by belonging to a group. Note: If one member belongs to two groups with different permissions assigned to groups, the least restrictive permission takes precedence. For example, if one group assigned Read permission and another group assigned Write permission, Write takes precedence. However if one of the groups assigned no permission, None takes precedence over Read and Write. 4. Parent-level assignments

    Oracle按照以下顺序授予权限优先级: 1. Service Admin角色具有最高权限。 2.专门分配给各个用户的权限。 3.通过属于一个组获得的权限分配。 注意:如果一个成员属于两个组,并且为每个组分配了不同的权限,则限制性最小的权限优先。 例如,如果一个组分配了读取权限,而另一组分配了写入权限,则写入优先。 但是,如果其中一组未分配权限,则“无”优先于“读取”和“写入”。 4.家长级作业

    2.权限管理 (2. Permission Management)

    Setting up how users, roles, and permissions are structured by using RBAC model is building anatomy. Then you need to determine what the permissions are and how granular it should be.

    通过使用RBAC模型设置用户,角色和权限的结构设置正在构建解剖结构。 然后,您需要确定什么是权限以及权限的精细程度。

    1)三种权限 (1) Three levels of permissions)

    There are three common levels of permissions:

    共有三种常见的权限级别:

    • Page permission: access to a page or a function.

      页面权限 :访问页面或功能。

    • Operation permission: access to a specific action on a page or within a function. Limited by page permissions.

      操作权限 :访问页面或功能内的特定操作。 受页面权限限制。

    • Data permission: access to specific data on a page or a section. Independent with operation permissions.

      数据权限 :访问页面或部分上的特定数据。 具有操作权限独立。

    Diagram for three levels of permissions
    Three levels of permissions
    三种权限级别

    The precedence of permissions should also follow the above relationship. For example, if an individual user has access to the “Invite” button but the belonged group has no access to the page of “User List”, page permission takes precedence.

    权限的优先级也应遵循上述关系。 例如,如果单个用户可以访问“邀请”按钮,但是所属组不能访问“用户列表”页面,则页面权限优先。

    For most cases, the permission for page and operation is yes/no, and the common options for data permissions are Add, Edit, Delete, and Hide(no access).

    在大多数情况下,页面和操作的权限为是/否,数据权限的常用选项为添加,编辑,删除和隐藏(无访问权限)。

    Diagram for permission levels and types
    Permission levels and types
    权限级别和类型

    2)可扩展性和独立性 (2) Scalability and independency)

    When designing the information architecture of permissions, we need to consider the scalability of how to easily add controls for new features. If the application has too many permissions, you can introduce permission groups to make it easier to configure access, just like user groups for users.

    在设计权限的信息体系结构时,我们需要考虑如何轻松地为新功能添加控件的可伸缩性。 如果应用程序的权限过多,则可以引入权限组以使其更易于配置访问,就像用户的用户组一样。

    The other important thing to keep in mind is to try to remain each permission independently. That ensures a continuous experience for the users who don’t have all the access to the software. Independency is also required when you have an a la carte pricing model.

    要记住的另一重要事项是尝试独立保留每个许可。 这样可以确保没有全部软件访问权限的用户获得连续的体验。 当您采用单点定价模式时,也需要独立性。

    Illustration for balance
    Illustration by Rocio Egio Studio Rocio Egio Studio的插图

    3.平衡粒度和易于使用 (3. Balance Granularity and Ease of Use)

    When a SaaS application grows, ease of use in permission control is a challenge that needs to be addressed. From my experience, there are some points to consider to make it more pleasant when users onboarding.

    随着SaaS应用程序的增长,权限控制的易用性是一个需要解决的挑战。 根据我的经验,有几点需要考虑,以使用户入职时更加愉悦。

    1)前端需要配置 (1) The need for configuration in front-end)

    If the app is designed for some specific industries with a standard administration system, some permission controls can be only written in back-end and not editable for users.

    如果该应用程序是针对具有标准管理系统的某些特定行业而设计的,则某些权限控件只能在后端编写,而不能对用户进行编辑。

    2)默认角色和权限 (2) Default roles and permissions)

    Presetting some default roles and permissions can largely save users time and potentially prevent some critical accidents, such as allowing clients to view vendors’ profits.

    预设一些默认角色和权限可以在很大程度上节省用户时间,并有可能避免发生一些重大事故,例如允许客户查看供应商的利润。

    3)简化选项 (3) Simplify options)

    Depending on use cases, try to simplify permission options. For example, Add, Edit, and Delete permissions can be combined as Edit in front-end. For back-end, it might be a good idea to keep all the options to remain the flexibility.

    根据使用情况,尝试简化权限选项。 例如,可以在前端将“添加”,“编辑”和“删除”权限合并为“编辑”。 对于后端,最好保留所有选项以保持灵活性。

    加起来 (Summing up)

    Designing access permission for a SaaS app is not an easy task, but it is a good exercise to sort use cases and think of how to make your application manageable and scalable.

    为SaaS应用程序设计访问权限不是一件容易的事,但对用例进行分类并思考如何使应用程序可管理和可扩展是一个不错的练习。

    Hope you find this article helpful to better understand the relationship of users, groups, roles, and different levels/types of permissions. After figuring out how permissions connect with users, you can design the permission system in an effective and elegant way.

    希望本文对您更好地了解用户,组,角色和不同级别/类型的权限之间的关系有所帮助。 在弄清楚权限如何与用户联系之后,您可以有效而优雅地设计权限系统。

    Image for post
    Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in. 海湾地区黑人设计师 :一个专业的黑人开发社区,他们是旧金山湾区的数字设计师和研究人员。 通过在社区中团结起来,成员可以共享灵感,联系,同伴指导,专业发展,资源,反馈,支持和韧性。 对系统性种族主义保持沉默是不可行的。 建立您相信的设计社区。

    翻译自: https://uxdesign.cc/design-permissions-for-a-saas-app-db6c1825f20e

    saas erp权限设计

    展开全文
  • 分享一个大神的人工智能教程。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到人工智能的队伍中来!... saas平台由于其本身“按需购买”...作为一个B端平台型产品,系统的权限设计是其中一个非常重要的组成部...

    分享一个大神的人工智能教程。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到人工智能的队伍中来!点击浏览教程 

    saas平台由于其本身“按需购买”的特性,在设计规划权限时,需要考虑统一配置权限如何规避企业没有购买的应用,以及如有部分应用存在数据权限不同的问题。现在,本文简单总结一下当前saas模式下权限的几种设计方式。

    作为一个B端平台型产品,系统的权限设计是其中一个非常重要的组成部分,没有权限管理的系统仿佛一个没有门的房子,任何人都可以随意查看甚至调整,对系统的安全性存在非常大的隐患,而saas模式下由于应用基本独立,随时可能被企业拆分使用。这里权限的统一与拆分问题也十分重要,本文简单总结一下当前saas模式下权限的几种设计方式。

    一、权限管理的重要性

    权限管理一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源,权限管理基本是任何一个系统的标配模块。它的作用不仅在于保护系统数据安全性、防止留下系统漏洞,更能在庞大的系统下进行模块和数据配置,让不同的角色进入系统看到不同的模块和数据,最大程度地提高系统的易用性。大部分系统中权限管理是作为一个独立的管理入口,统一设置所有的业务的权限。而saas平台由于其本身“按需购买”的特性,在设计规划权限时,需要考虑统一配置权限如何规避企业没有购买的应用,以及如有部分应用存在数据权限不同的问题。

    二、抽象权限组成

    权限到底是名词属性还是动词属性,还是名词、动词属性均包含,这对于权限的含义很重要。如果是名词属性的话,那么它应该是有具体的指代物;如果是动词,则应该具有行为表示。

    • 权限的名词属性:api接口、页面、功能点。
    • 权限的动词属性:可操作、不可操作。

    那么我们现在来看,其实权限是名词、动词属性,它一定是表达了两层含义。即控制的对象、操作。向上引申可将权限划分为3个组成部分:

    1. 页面权限:用户可以看到那些页面;
    2. 操作权限:用户可以在页面内进行那些操作,增删改查等;
    3. 数据权限:用户可以看到那些数据或内容;

    三、常见的权限控制模型

    (1)自主访问控制(DAC:Discretionary Access Control)

    系统会识别用户,然后根据被操作对象(object)的权限控制列表(ACL:Access Control List)或者权限控制矩阵(ACL:Access Control Matrix)的信息来决定用户的是否能对其进行哪些操作,例如读取或修改。而拥有对象权限的用户,又可以将该对象的权限分配给其他用户,所以称之为“自主(Discretionary)”控制。DAC最大缺陷就是所有用户的权限不能统一管理,用户和用户的权限比较分散,后期调整只能单个进行调整,不易维护。

    (2)强制访问控制(MAC:Mandatory Access Control)

    在MAC的设计中,每一个对象都都有一些权限标识,每个用户同样也会有一些权限标识,而用户能否对该对象进行操作取决于双方的权限标识的关系,这个限制判断通常是由系统硬性限制且无法回避的。强制访问控制多应用于对安全性要求比较高的系统,如多级安全军事系统;

    (3)基于角色的访问控制(RBAC:Role-Based Access Control)

    RBAC是我们当前使用范围最广的一种权限设计模型,模型基础就是用户和角色,角色和权限做多对多的对应。标准的RBAC模型包括四个部件模型,分别为基本模型RABC0、角色分级模型RABC1、角色限制模型RABC2、统一模型RABC3。

    1. RBAC0(基本模型)定义了完全支持RBAC概念的任何系统的最低需求。RBAC0的模型中包括用户(U)、角色(R)和许可权(P)等3类实体集合,RABC0是权限管理的核心部分,其他的版本都是建立在0的基础上。
    2. RBAC1(角色分级模型)基于RBAC0模型,引入角色间的继承关系,即角色上有了上下级的区别,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。这种模型合适于角色之间的层次明确,包含明确。
    3. RBAC2(角色限制模型)引入了角色间的约束关系,主要约束规则包括:角色间的互斥关系,在处理用户和这些角色之间的关系时,包括静态分离和动态分离,静态分离指互斥的角色不能同时赋予同一个用户;动态分离指用户不能同时操作两个互斥的角色进行登录。
    4. RBAC3(统一模型)同时包含了1和2的特性。

    总结:SAAS后台权限设计案例分析

    如图所示,每个用户关联一个或多个角色,每个角色关联一个或多个权限,从而可以实现了非常灵活的权限管理。角色可以根据实际业务需求灵活创建,这样就省去了每新增一个用户就要关联一遍所有权限的麻烦。简单来说RBAC就是:用户关联角色,角色关联权限。并且在产品和数据设计层面,有更好的扩展性,可控制到任意的粒度。

    (4)基于属性的权限验证(ABAC:Attribute-Based Access Control)

    ABAC则是通过动态计算一个或一组属性,来是否满足某种条件来进行授权判断(可以编写简单的逻辑)。属性通常来说分为四类:用户属性(如用户年龄),环境属性(如当前时间),操作属性(如读取)和对象属性(如一篇文章,又称资源属性),所以理论上能够实现非常灵活的权限控制,几乎能满足所有类型的需求。该设计过于复杂,暂未参透。

    四、基于RBAC权限模型的SAAS平台权限系统设计

    对于SAAS平台这样庞大复杂的平台来说,权限系统设计得越全面、精细、后期的系统扩展性就越高,所以这里采用RBAC权限模型,RBAC权限模型是现有比在这方面比较成熟的权限设计模型,应用这个模型能解决常规的系统权限配置问题,其基本原理也能适用于平台权限设计。

    RBAC对权限抽象概括:判断【Who是否可以对What进行How的访问操作(Operator)】

    RBAC支持三个著名的安全原则:最小权限原则,责任分离原则和数据抽象原则。

    1. 最小权限原则之所以被RBAC所支持,是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。
    2. 责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现,比如要求一个计帐员和财务管理员共参与同一过帐。
    3. 数据抽象可以通过权限的抽象来体现,如财务操作用借款、存款等抽象权限,而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

    ——来自百度百科

    以某物业公司内部信息平台为例,该物业公司平台分为客户档案、房产档案、收费系统、客服工单等多应用结构,其中物业公司组织架构为多层级,基本样式如下如。

    总结:SAAS后台权限设计案例分析

    组织架构

    总结:SAAS后台权限设计案例分析

    应用入口

    总结:SAAS后台权限设计案例分析

    功能页面,以上我们可以将:

    • 组织架构=数据权限
    • 应用入口以及应用菜单=页面权限
    • 功能操作点=操作权限

    1. 基本模型:RBAC0

    抽取角色,建立角色与用户的关系。这里的角色主要是指在组织内承担特定的业务活动,并和别的业务角色进行交互的业务角色。业务角色的抽取主要有两种方式:一种是直接和岗位对应,另外一种是根据流程的本质和需要定义角色。确定各角色的用例图,如下图(简单示例):

    总结:SAAS后台权限设计案例分析

    根据业务复杂度、用户特点进行原型草图设计,在进行权限分配时,可以从增加角色维度以及增加用户维度。如下图:

    总结:SAAS后台权限设计案例分析

    新建角色维度

    总结:SAAS后台权限设计案例分析

    新建用户维度。使用此模型时,我们需要注意的问题有:

    1. 用户和角色为多对一的关系,如果需要用到多对多的关系,将涉及到角色关系的处理,此模型并不适用。
    2. 权限一定是动态可配置的,不是静态的,这点一定要在着手开发前进行说明,一般情况,权限的数据结构为树形,合理的数据结构,便于前端根据实际需求进行解析;
    3. 人员在选择角色获取到对应的权限数据后,最好可以提供一个二次编辑界面,权限会更加灵活。

    2. 角色分级模型:RBAC1

    RBAC1基于RBAC0模型,引入角色间的继承关系,即角色上有了上下级的区别,角色分级模型适用于平台业务功能较多,单个角色设置操作过于繁琐,引用角色分级,可让角色之间存在继承或被继承的关系,比如客服主管可直拥有下级所有员工拥有的权限。建立角色管理,确定角色跟用户之间的关系。(要求角色间有明显的层级关系,所以在没有其他需求的情况下,这里根据业务部门和岗位进行角色的抽取)

    建立角色层级关系和继承关系。

    总结:SAAS后台权限设计案例分析

    角色层级关系

    总结:SAAS后台权限设计案例分析

    一般继承关系

    总结:SAAS后台权限设计案例分析

    受限继承关系

    给角色赋予权限(应用入口权限——应用页面权限、应用页面中操作功能权限、数据查看权限。)权限赋予同RBAC0。增加一个角色管理。如下图:

    总结:SAAS后台权限设计案例分析

    通过角色管理即可以将下级角色的权限直接赋值给上级权限,但由于低级角色的权限全部被高级角色继承,就会导致没有自己角色的私有权限;也可以为人员提供一个二次编辑权限界面,但是一旦编辑后,若后续所属角色权限发生变化,会直接覆盖原有编辑后的权限。

    3. 角色限制模型:RBAC2

    RBAC2,它是RBAC的约束模型,RBAC2也是建立的RBAC0的基础之上的,在RBAC0基础上假如了约束的概念,主要引入了静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。SSD是用户和角色的指派阶段加入的,主要是对用户和角色有如下约束:

    1. 互斥角色:同一个用户在两个互斥角色中只能选择一个;
    2. 基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的;
    3. 先决条件约束:用户想要获得高级角色,首先必须拥有低级角色。

    DSD是会话和角色之间的约束,可以动态的约束用户拥有的角色,如一个用户可以拥有两个角色,但是运行时只能激活一个角色。

    总结:SAAS后台权限设计案例分析

    角色权限配置界面可参照RBAC0。用户在配置角色或角色下新建添加用户时,需要根据用户已有的角色身份进行判断。示例:用户A配置角色为客服组长,则可继续添加角色为客服主管,若客服主管已被分配给他人,则也不能分配给用户A(遵从最大拥有数原则)。若同时将保安主管分派至用户A,则操作时,需要选择操作角色。

    总结:SAAS后台权限设计案例分析

    当一个用户配置了多个角色身份时,权限取并集。

    4. 统一模型:RBAC3

    统一模型是包括了继承和分离两种情况的更为复杂的模型,即既要定义角色间的的继承关系,也要维护好角色间的责任分离关系。在这里就不做过多的赘述(两张图供大家参考),因为只要维护好了角色间的约束关系,其他规则类的处理方式同RABC1和RABC2。

    总结:SAAS后台权限设计案例分析

    角色管理

    总结:SAAS后台权限设计案例分析

    权限配置

    五、总结

    1. 角色数据权限

    1. 不同的角色身份查看的角色数据时不相同的,比如物业分公司中深圳区域分公司的管理人员可能就无法管理长沙区域分公司,在给角色分配数据权限时就可以将长沙区域分公司去除。
    2. 除数据权限外,我们还会遇到字段权限,比如:分公司C和分公司D都能看到上海区域分公司的客户情况,但是C看不到客户联系方式,D则能看到联系方式。如果有需要对字段权限进行控制,则可以在设置角色的数据权限或者功能权限时,进行控制。
    3. 题前有提到针对saas模式,可能存在一个角色在管理A跟B应用时可操作的数据权限时不一样的,可以在数据权限中增加一个高级设置权限,为不同的角色针对不用的应用进行分配数据操作。

    2. 用户操作体验

    平台类或者TO B内部产品,虽然不像C端为了留住用户追求极致用户体验,但是也需要确保在交互以及文字理解上面不会让用户产生疑惑情绪,培训成本也是开发成本的一环,尤其针对权限一块可能涉及业务功能复杂,如果在文字描述以及操作上在加大操作难度,可能无法估量的后果。

    3. 默认账号以及默认权限的设置

    对于ToB类或者平台类的产品,正常来讲都会有一个默认的超级管理员的角色以及角色对应的账号,否则系统内第一个角色谁来添加?默认权限的设置则根据需要进行设置,如果是不必要进行控制的权限,当然是可以设置为默认权限的。

    综上所述,根据以上的设计模式以及解决方案,已经能实现大部分企业90%的问题了,实际上很多企业并不需要做到这么小粒度的权限控制。

    展开全文
  • Saas架构和权限设计

    2013-08-01 17:58:54
    干货分享,强烈推荐!基于多租户的Saas架构和权限系统设计
  • 为什么系统需要权限控制? 生活中有没有权限限制? 灾难片电影《2012》中富人和权贵有权登上诺亚方舟,穷苦老百姓只有等着灾难的来临; 屌丝身边为什么没有那些长得漂亮、身材好的姑娘存在? 因为有钱人...

    为什么系统需要权限控制?

     

    生活中有没有权限限制?

     

    灾难片电影《2012》中富人和权贵有权登上诺亚方舟,穷苦老百姓只有等着灾难的来临;

     

    屌丝身边为什么没有那些长得漂亮、身材好的姑娘存在?

     

    因为有钱人和漂亮姑娘都是珍贵稀有的,稀有的人在一起玩耍。而普通人往往无权拥有他们所拥有的权限。

     

     

    权限管理的本质

     

    web程序通过 url 的切换查看不同的页面(功能),所以权限管理指的其实就是URL管理,对url控制就是对权限的控制。

     

    因此,一个人有多少个权限取决于他可以访问多少个URL。

     

     

    RBAC是什么?

     

    RBAC(Role-Based Access Control),是基于角色的访问控制,是一种先进的权限管理的模型。RBAC把用户通过角色与权限进行关联。即让一个用户拥有若干角色,每一个角色拥有若干权限。

     

    这样就构造成了“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。

     

    图片

     

     

     

     

    权限系统中的概念

     

    用户

    应用系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。

     

    角色

    为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系,可以形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。

     

    为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际情况中,我们知道,组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群,一个群可以有多个用户,一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息,例如普通群、高级群等。

     

    图片

     

    权限

    系统的所有权限信息表达了两层含义。即控制的对象、操作。向上引申可将权限划分为3个组成部分:

     

    页面权限:用户可以看到那些页面;

     

    操作权限:用户可以在页面内进行那些操作,增删改查等;

     

    数据权限:用户可以看到那些数据或内容;

     

    图片

     

     

    权限模块设计

     

    完整的权限管理做大可作为独立 系统进行开发,小做也必定做为SAAS平台的核心基础模板,在最初迭代初期就进入规划、设计环节。在进行权限模块设计时,产品可以从两个角度考虑:

     

    1.权限控制管理

     

    即对系统中各类涉及权限限制的元素进行使用、查看等操作的权限控制。

     

    l最基本的权限管理是菜单管理,用户没有权限的功能模块在菜单节点上不显示。

     

    如:普通业务人员登录系统后,是看不到【用户管理】菜单的。

     

    l功能权限管理,B/S系统的功能体现为URL,所以功能权限管理主要是针对URL访问的管理。

     

    如:经过授权,部门经理可以查看【用户管理】菜单,并查看部门用户信息,但权限设计要求,该部门经理没有添加用户的权限。所以在访问【添加用户】的功能(URL)时,应该有没有授权的提示信息。同时在【用户管理】页面上,【添加用户】的按钮应该灰色显示,不能点击。

     

    l行级权限管理

     

    如:论坛管理员,权限设计要求 A能管理论坛 【新闻版块】,不能管理论坛 【技术交流】此时的权限设计就应该根据论坛的相应ID来判断权限信息。

     

    l列级权限管理

     

    如:业务权限设计要求,除销售人员以外,其他用户不能看到客户的联系方式信息。

     

    此时的权限设计要判断相应的字段(列)是否可以显示。

     

    l组织机构/部门级数据权限管理

     

    如:业务权限设计要求,销售一部的人员只能看到本部门的销售订单,销售二部的人员只能看到本部门的销售订单,但销售经理可以同时看到销售一部和销售二部的销售订单。此时的权限设计就要根据销售订单数据本身的部门属性来做判断

     

    l范围型业务数据权限管理

     

    如:大卖场销售人员在下销售订单时,要选择相应的产品所在仓库信息。业务权限设计要求,【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】,而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】

     

     

    2.权限分配管理

     

    针对权限管理内容通过系统授权功能分配给具体的用户,角色的过程。

     

    l直接对用户授权,直接分配到用户的权限具有最优先级别。

     

    l对用户所属岗位授权,用户所属岗位信息可以看作是一个分组,和角色的作用一样,但是每个用户只能关联一个岗位信息。

     

    l对用户所属角色授权,用户所属角色信息可以看作是一个权限分组,每个用户可以关联多个角色。

     

    l角色直接关联具体的功能权限(URL),也可以关联负权限,即此角色关联的权限不能使用负权限功能。负权限具有优先级别。

     

    l分级授权,系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。

     

     

    界面总体设计

     

    想想一个简单的权限系统应该有什么功能呢?当然是:用户-角色-权限,下图所示过程:

     

    图片

     

    创建角色列表

     

    图片

     

    在角色列表快速创建一个角色:点击创建角色,支持创建角色时配置权限。

     

    图片

     

    创建用户列表

     

    图片

     

    在用户列表快速创建一个用户:支持用户关联角色的功能。用户权限管理常见设计包括:

     

    l所属角色:当用户选择“修改”按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的角色。

     

    l所属组:当用户选择“修改”按钮时,弹出组的树形结构,操作人可以通过勾选或取消勾选来修改该用户所属的组。

     

    l用户权限:通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击“保存”按钮保存修改信息。

     

    l总权限:通过对已具有的权限取消勾选,或为某权限添加勾选,来修改用户的权限信息,点击“保存”按钮保存修改信息。

     

    l用户管理:当选择了某用户时,点击右键,弹出菜单列表:修改、删除、取消,点击修改和删除按钮可以实现用户的删除和修改功能。

     

    选择某个组织,例如 “广州分公司”,弹出菜单列表:添加子组织、删除组织、修改组织、添加用户、取消,点击添加用户按钮可以实现用户的添加功能。

     

    l组织管理:选择某个组织,弹出菜单列表:添加子组织、删除组织、修改组织、添加用户、取消,点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。

     

    图片

     

    上述案例是基于最简单的RBAC0模型创建,适用于大部分常规的权限管理系统。

     

    角色权限管理

     

    我们还可以在上面的内容基础上再加上角色等级。角色权限管理设计中,通常包括以下内容:

     

    l包含用户:当用户选择“修改”按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该角色所包含的用户。

     

    l包含组:当用户选择“修改”按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该角色所包含的组。

     

    l角色权限:通过对已具有的权限取消勾选,或为某权限添加勾选,来修改角色的权限信息,点击“保存”按钮保存修改信息。

     

    l管理角色:选中组1的时候,右键点击可弹出组的操作列表,包括添加、删除和修改按钮,从而完成在该组下添加子组,删除该组以及修改该组的功能。

     

    具体界面呈现如下图:

     

    图片

     

    组权限管理

     

    除此之外,还有组权限管理

     

    l包含用户:当用户选择“修改”按钮时,弹出用户列表,操作人可以通过勾选或取消勾选来修改该组所包含的用户。

     

    l所属角色:当用户选择“修改”按钮时,弹出角色树形结构,操作人可以通过勾选或取消勾选来修改该组所属的角色。

     

    l组权限:通过对已具有的权限取消勾选,或为某权限添加勾选,来修改组的权限信息,点击“保存”按钮保存修改信息

     

    l总权限:通过对已具有的权限取消勾选,或为某权限添加勾选,来修改组的权限信息,点击“保存”按钮保存修改信息

     

    l组管理:选中组1的时候,右键点击可弹出组的操作列表,包括添加、删除和修改按钮,从而完成在该组下添加子组,删除该组以及修改该组的功能

     

    操作日志管理

     

    l查询操作日志:输入上图表单中的查询信息后,点击“查询”按钮,可查询出符合条件的信息。

     

    l删除操作日志:输入上图表单中的查询信息后,点击“查询”按钮,可查询出符合条件的信息。而后点击“删除”按钮,可删除符合查询条件的操作日志。

     

    - End -

    展开全文
  • SaaS-HRM中的权限设计

    2019-12-29 11:38:27
    3 SAAS-HRM中的权限设计 3.1 需求分析 3.1.1 SAAS平台的基本元素 SAAS平台管理员: 负责平台的日常维护和管理,包括用户日志的管理、租户账号审核、租户状态管理、租户费用的管理,要注意的是平台管理员不能对租户...

    3 SAAS-HRM中的权限设计

    3.1 需求分析

    3.1.1 SAAS平台的基本元素

    在这里插入图片描述

    SAAS平台管理员: 负责平台的日常维护和管理,包括用户日志的管理、租户账号审核、租户状态管理、租户费用的管理,要注意的是平台管理员不能对租户的具体业务进行管理
    企业租户: 指访问SaaS平台的用户企业,在SaaS平台中各租户之间信息是独立的。
    租户管理员: 为租户角色分配权限和相关系统管理、维护。
    租户角色: 根据业务功能租户管理员进行角色划分,划分好角色后,租户管理员可以对相应的角色进行权限分配
    租户用户: 需对租户用户进行角色分配,租户用户只能访问授权的模块信息。

    3.1.2 需求分析

    在应用系统中,权限是以什么样的形式展现出来的?对菜单的访问,页面上按钮的可见性,后端接口的控制,都要进行充分考虑

    • 前端
      前端菜单:根据是否有请求菜单权限进行动态加载
      按钮:根据是否具有此权限点进行显示/隐藏的控制

    • 后端
      前端发送请求到后端接口,有必要对接口的访问进行权限的验证

    3.2 权限设计

    针对这样的需求,在有些设计中可以将菜单,按钮,后端API请求等作为资源,这样就构成了基于RBAC的另一种授权模型(用户-角色-权限-资源)。在SAAS-HRM系统的权限设计中我们就是才用了此方案
    在这里插入图片描述
    针对此种权限模型,其中权限究竟是属于菜单,按钮,还是API的权限呢?那就需要在设计数据库权限表的时候添加类型加以区分(如权限类型 1为菜单 2为功能 3为API)。

    3.3 表结构分析

    在这里插入图片描述
    这里要注意的是,权限表与权限菜单表、页面元素表与API接口表都是一对一的关系与传统的RBAC模型对比不难发现此种设计的好处:

    1. 不需要区分哪些是操作,哪些是资源
    2. 方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的资源表,并确定这类权限的权限类型标识即可。
    展开全文
  • SaaS系统用户权限设计讲解

    千次阅读 2017-11-01 11:16:00
    其中系统的权限设计是十分关键和重要的部分,本文以O2O业务为例讲解SaaS系统权限设计。 1、系统需求 平台管理员只能管理租户的账号和相关信息,不能操作租户的内部业务。各租户拥有自己的角色和权限,相互不能影响。...
  • 基于RBAC的saas权限系统设计

    万次阅读 2016-07-21 14:43:00
    在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相
  • 第3章-SaaS系统用户权限设计 1 组织机构管理 1.1 需求分析 1.1.1 需求分析 实现企业组织结构管理,实现部门的基本CRUD操作 1.1.2 数据库表设计 CREATE TABLE `co_department` ( `id` varchar(40) NOT NULL, `...
  • SAAS-HRM系统的权限设计中我们就是才用了此方案 针对此种权限模型,其中权限究竟是属于菜单,按钮,还是API的权限呢?那就需要在设计数据库权限表的时候添加类型加以区分(如权限类型 1为菜单 2为功能 3为API)...
  • SaaS-HRM--第3章-SaaS系统用户权限设计

    千次阅读 2019-06-15 23:51:39
    了解SAAS-HRM中权限控制的需求及表结构分析 完成组织机构的基本CRUD操作 完成用户管理的基本CRUD操作 完成角色管理的基本CRUD操作 1组织机构管理 1.1需求分析 1.1.1需求分析 实现企业组织结构管理,实现部门的基本...
  • SaaS架构设计

    万次阅读 2016-03-04 12:55:17
    一、SaaS的安全性设计  一般常见的安全性设计分为两类:系统级和程序级。  系统级:  1、使用HTTPS协议以SSL(Security Socket Layer)交换数据,增强通信安全;  2、 通过数字签名防止传输过程篡改;  3...
  • SaaS架构设计SaaS应用安全
  • 3 SAAS-HRM中的权限设计 3.1 需求分析 3.2 权限设计 针对此种权限模型,其中权限究竟是属于菜单,按钮,还是API的权限呢?那就需要在设计数据库权限表的时候添 加类型加以区分(如权限类型 1为菜单 2为功能 3为API...
  • 第3章-SaaS系统用户权限设计 学习目标: 理解RBAC模型的基本概念及设计思路 了解SAAS-HRM中权限控制的需求及表结构分析 完成组织机构的基本CRUD操作 完成用户管理的基本CRUD操作 完成角色管理的基本CRUD操作 1 ...
  • 文章目录三、SaaS系统用户权限设计1、组织机构管理<1>、需求分析(1)、需求分析(2)、数据库表设计<2>、微服务实现(1)、抽取公共部分(2)、CRUD操作<3>、前端实现(1)、创建模块(2)、配置请求API(3)、...
  • SaaS-权限管理

    2019-12-29 14:07:59
    为了方便操作,在SAAS-HRM系统的表设计中,采用基于共享主键的形式实现一对一关系维护,并且数据库约束,一切的关系维护需要程序员在代码中实现。 1.2 后端实现 1.2.1 实体类 在系统微服务中创建权限,菜单,按钮...
  • 了解SAAS-HRM中权限控制的需求及表结构分析 完成组织机构的基本CRUD操作 完成用户管理的基本CRUD操作 完成角色管理的基本CRUD操作 1 RBAC模型 1.1 什么是RBAC RBAC(全称:Role-Based Access Control)基于角色的...
  • 1RBAC 2配置系统微服务 3 后端用户基本操作(已经完成实体类部分)
  • https://www.jianshu.com/p/2f598680cbc4?utm_campaign=haruki
  • SaaS架构设计之如何转化成SaaS多租户模式
  • SaaS架构设计之共享设备

    千次阅读 2008-11-28 08:39:00
    SaaS架构设计之共享设备此文选自《互联网时代的软件革命—SaaS架构设计》一书 转眼三个月过去了,这天是元旦后的第一个周六,杨康和郭靖正在学生公寓玩网络游戏“魔兽争霸”,这时手机响了。欧阳锋:杨康,前几天梅...
  • saas架构设计基础

    2010-06-19 16:54:00
    saas是英文Software as a Service的缩写,中文的意思是:软件即服务。 saas核心理念是将软件看着服务,而非产品。 如何构建高性能的saas架构应用,需要满足以下条件: 一、满足多租户应用...
  • 彻底理解微商城多租户Saas架构设计 原文链接:https://blog.csdn.net/haponchang/article/details/104246317,感谢作者提供这么好的总结! 1.具体的SaaS架构必须 1.先仔细选择最适合应用程序需求的租户模型, 2....

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,619
精华内容 2,647
关键字:

saas权限设计