Permission system RGCA four-step architecture method

This paper introduces the idea of the RGCA four-step architecture method, and designs a general rights management system without code buried points through the RGCA four-step architecture method.

Table of contents

RGCA four-step architectural approach

Requirement: Get requirements from stakeholders
Goal: Turn requirements into goals (functional intent)
Concept: expand the goal into a complete concept
Architecture: Extending the concept to architecture

Obtain requirements from stakeholders

▌ Benefit principle

A good architecture must benefit people. If you want to do a good job in the architecture, you must focus on the emergence of functions, so that the system can expose its main functions to the outside world through interfaces that cross the system boundary.

▌ Pain point

For the internal management system of the enterprise, there will basically be an authority management system. When designing a product, the product manager needs to determine the key of each menu and each button, and then match and bind the key with the authority. However, the product manager cannot determine all the places that require permission management in the future, so developers need to set keys for all places in advance
Since there are many keys that need to be set, the naming may not be standardized, and there may be gaps. In the future, the missing parts will need to be re-coded and released by developers to meet the needs. This is the pain point of developing the internal rights management function of the enterprise▌Benefits Stakeholders • Party A: developers, architects, investors • Clients: developers, product managers, system operators, bosses

▌Requirement classification, sorting, characteristics!

Translate requirements into goals (functional intent)

From the top-level perspective of the system: define the form and function of the system and determine the functional intent (the functional intent is derived from the main beneficiaries, the main requirements)
Form: Universal rights management system
to..by..using
In order to use functions: no need to bury the code, change the accessibility of resources (pages, buttons, data, API) through UI configuration, and achieve the purpose of permission control process + operation <= tools

Expand the goal into a complete concept

A solution-independent process is proposed in the target phase: interception, a vaguely abstract process that does not specify who intercepts and in what way solution-independent operations Objects: protected resources, an abstract object, The classification of objects is derived from the requirements, but it is still not particularly specific, and there is no specific scenario. At the conceptual stage, a specific solution process needs to be proposed: from the solution unrelated to the solution related The solution is to help us solve the problem, in the goal The stage roughly defines what problem needs to be solved, and the functional level only explains the advantages of the product. The specific solution is proposed in the concept stage, which reflects how to describe the function in detail, so it needs to be deduced to the scene related to the solution.

The protected resource is deduced by taking the API as an example, which is defined as API Action, and the interception is expressed as AuthorizationFilter in ASP .NET Core
Because it is a noun and cannot represent a process, adding ing represents a process AuthorizationFiltering
API Action becomes a solution-related thing after AuthorizationFiltering and becomes a Result in ASP.NET Core Mvc, which is an attribute of AuthorizationContext
Result has several types: Sucess, Forbiden, Challenge

In addition to API Action, protected resources can also be Entity, and all EF operations are ultimately placed in DBContext
DBContext has a SaveChanges operation, and a ChangeTracker property that records all state specializations of the entity: becoming more specific From protected resources to API Action is a specialization process, and from target to concept is also a specialization process Generalization: Becoming more abstract From data, pages, buttons, APIs to protected resources is a generalization process Intent to intercept: Protect resources
AuthorizationFilter can only be intercepted by tagging Authorize on Action in ASP .NET Core. This is the so-called code burying point. For example, tagging on the entity is also a code burying point.

The upper layer of interception is to protect resources. Interception is a way to protect resources. It is necessary to define protected resources in advance. Except for protected resources, dynamic protection is required for all resources, which can be dynamically intercepted by dynamic interception. A DynamicAuthorizationFiltering needs to be implemented. , can not overwrite the original function

The upper layer of protecting resources is security. In addition to protecting resources, there are many other things that can be done. For example, logging and auditing logs will record all access records of users. Enterprises can set permissions. Looking up one level, until reaching the top level, in addition to looking up, you can also look down to extend the overall concept. Through the combination of concept fragments, a complete overall concept is formed. Next, the process of interception is expanded and expanded into a group The internal process of execution must be obtained. For each internal process, select specific operands, process and tool objects to specialize it, and then the corresponding concept fragments can be obtained. This is also a specialization process.

• Configuration: The system administrator wants to control all API requests in the background, so it is necessary to know which APIs are available first, and each action needs to be configured. • Authorization: Assign roles to users. • Authentication: Users have an identity after authentication. • Authorization: Authorization based on identity

Extend concepts to architecture

▌Value Path and System Architecture

From resources to permissions, permissions are bound to users, users log in, and then authorization is performed after login

Resources are divided into ActionAccess and EntityAccess
EntityAccess has CanCreate, CanDelete, EntityName, Key several properties, and whether each field is allowed to modify MemberAccess
Similarly ActionAccess has several properties Url, Name, DisplayName, Verb

Registered resources are divided into Entity Explorer and API Explorer
Entity Explorer scans through DbContext to obtain entities that need to be monitored for registration
API Explorer registers Action through IActionDescriptorCollectionProvider

Authorization has an interceptor AuthorizeFilter
ASP.NET Core Identity has an authentication and authorization mechanism based on Claims, which is an array of key:value
Clamis belong to User object, User object belongs to HttpContext
AuthorizeFilter receives Claims and ActionDescriptior, and Action information can be obtained in Claims, so the two are related

For this step of empowerment, you need to define permissions Permission and roles, enter permissions and roles into the empowerment, and generate a role permission RolePermission
Role permission RolePermission is a composite object, including roles, permissions and resources. There is an inclusion relationship between permissions and resources. A permission includes multiple resources. So far, a path has been completed: after defining keys for multiple Actions, assign the key to the role, and bind the role to the role. Set to the user, when the user logs in, he can get a list of Actions, which can be compared by AuthorizeFilter

Authorization is determined by the AuthorizationContext to determine whether there is permission. The response is divided into API response and Entity response. There are different processing methods for different responses. For API response, it is necessary to determine whether permission is allowed. Unauthenticated returns 401, and no permission returns 403.
For Entity response, Claims and EntityAccessList are required, and the Claims and AccessList are compared

After the user logs in, he gets the User identity and initiates a request to generate an ActionRequest
ActionRequest belongs to HttpContext and will finally be input to AuthorizeFilter

The whole process is such a value path from top to bottom, and it has already included formal objects from resources to permissions, roles, to the binding of roles and users, and then to the entire system of authorization, forming a system architecture.

▌Hierarchical decomposition

First find the entity objects from the system architecture: resources, permissions, roles, and user resources are provided by ResourceProvider, which are divided into ActionResourceProvider and EntityResourceProvider
Users and roles using ASP .NET Core Identity's UserManager and RoleManager

ASP.NET Core Identity only contains users and roles, and needs to be extended for Identity, plus permissions
UIprotron.Security.Core is responsible for managing resources and permissions
As an extension of Identity, UIprotron.Security.Identity adds resources and permissions to Identity, which is equivalent to an adaptation layer

UIprotron.Security.ActionAccess and UIprotron.Security.EntityAccess are responsible for the permissions of Action and Entity respectively

Generally divided into the following parts:
• ASP .NET Core Identity: User authentication library • UIprotron.Security.Identity: Core and Identity integration components • UIprotron.Security.Core: Management of resources and permissions • UIprotron.Security.ActionAccess: Action resource discovery and permission control • UIprotron.Security.EntityAccess: Entity resource discovery and permission control • UIprotron.Security.Store.EntityFramework: EF Core persistence layer for resources and permissions

Onion Architecture

• CoreAdapters: The core and most stable are placed in the innermost • Application Security.Identity: Application layer, the extension of Identity • Action Access
• Entity Access
• EfResourceStore

Split each layer, split the functionality into Core, Models, Store and EFStore

The RGCA four-step architectural approach captures requirements from stakeholders, transforms requirements into goals (functional intent), then expands goals into complete concepts, and finally expands concepts into architecture. According to the idea of RGCA four-step architecture method, we have completed the design of a general rights management system without code buried points, and implemented the code according to the architecture design. For the specific implementation, you can refer to the complete code of the project, or refer to this series of related articles.

Microsoft Most Valuable Professional (MVP)

The Microsoft Most Valuable Professional is a global award given to third-party technology professionals by Microsoft Corporation. For 29 years, technology community leaders around the world have received this award for sharing their expertise and experience in technology communities both online and offline.

MVPs are a carefully selected team of experts who represent the most skilled and intelligent minds, passionate and helpful experts who are deeply invested in the community. MVP is committed to helping others and maximizing the use of Microsoft technologies by Microsoft technical community users by speaking, forum Q&A, creating websites, writing blogs, sharing videos, open source projects, organizing conferences, etc.
For more details, please visit the official website:
https://mvp.microsoft.com/en-us

Scan the code to continue to discover more interesting Microsoft first-party developer programs!

Long press to identify the QR code

Click to watch the developer show~