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 )，而是可以大大节省管理员的时间。 通过管理员的思考方式，这也使正确配置更容易。

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.

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

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.

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

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.

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

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模型之外，您还可以使用组对用户进行分类，并仅向组分配权限。

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.

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

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.

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

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.

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

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).

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

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.

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

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.

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