Masa auth - overall design from the user's perspective

user

In the system , User is a core concept . It represents a person's unique identity , In addition to roles 、 The team 、 Organizational structure, etc , It will even affect the operation process and display content of different users in the same interface , If it's more complicated , Perhaps the identity of a user in the same system will change after entering different products

Users and roles

Users can have one or more roles , Let roles act as permission groups , Assign one or more groups of permissions to users indirectly

Users and teams

Users can work in multiple teams , Each team can have one or more roles , Associate one or more groups of permissions with the team through roles , And give it to the members of the team

Team members can be internal , It can also be external . The unified user table is used as the unique identity of people . Re pass Employee and ThirdPartyUser Distinguish user identity attributes .

Users and organizational structure

Users can be specified in a node of the organizational structure

But the organizational structure is a virtual tree structure , It belongs to the business , Therefore, it is not directly associated with permissions

besides , It is sometimes difficult for an organizational structure to represent role inheritance relationships . Different members in the same organizational structure node often have different roles , And the parent-child relationship may not be closely linked as a parent-child node . There may be several levels between the upper and lower levels of some companies

In our early definition, organizational structure is associated with authority and does not have the concept of team . But in fact, the project system exists in many companies , When running on a project basis , People's permissions and virtual organization relationships change frequently . As a result, it is often necessary to make choices on the adjustment of organizational structure and a large number of fine-tuning of personal permissions , In order to completely solve this split behavior . We regard the organizational structure as a virtual tree structure to describe everyone's department ownership , At the same time, the team approach is adopted to solve the problem of authority change caused by frequent personnel access and four operations under the project system

Users and permissions

In addition to having roles , There may also be some permissions that need to be granted or disabled temporarily under some special businesses

Although with RBAC2 There is a little conflict , But in fact, such scenes do exist , For example, the finance department that is about to leave the company needs the temporary payment recovery function , This obviously violates the principle of mutual exclusion , In terms of design, our choice is that the priority of extended permission is higher than the permission contained in the role . In this way, some sensitive permissions can be withdrawn through hedging

The user types

There are three types of users ： End user , staff , Resident staff

for instance ：

• A It's the employees of the company , Have internal permissions . It is also the end user of the company's products
• B They are resident employees , Have some internal permissions . It is also the end user of the company's products

User privilege priority

The user's permissions should have a certain priority , To select which permission to activate when multiple permissions under the same business are effective at the same time

We will apply the following rules ：

1. Super administrator / Administrators

   The super administrator is the system administrator , The administrator is the administrator of the specified project

2. User's extended configuration permissions

3. User role permissions

   When the user's role permissions conflict , Deny has priority over allow , Lower than the user's extended configuration permission

4. Default role permissions for the team

5. Parent role permissions in the team

   In the future, after the team supports the parent-child relationship , The current user is not assigned permission , When the current team has a parent, it will recursively look up the nearest default role to obtain the permission list

User permission type

The permission types of users can be divided into four categories

• menu ： Whether a page can be accessed through the menu

• Page elements ： Whether the elements in the page can be operated , Button like . Page elements need to be hung under the menu

• data ： Whether to display the specified field . Data needs to be hung under the menu

  Data is similar to page elements , But it is independent of page elements

• API： Whether the specified... Can be accessed API.API It usually needs to be hung under the menu or page element , It can also be hung under the data if necessary

Authority hierarchy

summary

thus , From the perspective of a user, we define roles and permissions , Front end and back end are connected in series . But so far, it is still the stage of combing the concept , It is difficult to be a authority center . Each team has its own management style , How to extract common ground from different team requirements and connect the main line , It still needs time to verify that it can not only meet the needs of most scenarios, but also leave room for expansion .

（ This article does not represent the final design ）

Reference resources ：

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

Open source address

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Utils：https://github.com/masastack/MASA.Utils

MASA.EShop：https://github.com/masalabs/MASA.EShop

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

If you treat our MASA Framework Interested in , Whether it's code contribution 、 Use 、 carry Issue, Welcome to contact us