A bitmap object-based cache dual-model API access control method and system

Abstract

The application discloses a bitmap materialized cache-based double-model API access control method and system. The method comprises the following steps: S1, constructing an explicit authorization write model; S2, establishing a mapping relationship between a server trusted API and a function resource identifier; S3, receiving a compilation trigger event, and converting the explicit authorization write model into a bitmap read model; S4, compressing a bitmap byte to a multi-level cache; S5, intercepting a request through a gateway, and checking a token to obtain a user identity and an application domain; S6, checking whether a user has field write permission in a write request; and S7, recording authorization changes, permission compilation, cache hits, access rejections and field interception events. The application converts real-time multi-association table query and list merging judgment into a pre-compiled compressed bitmap containing judgment, and only needs to analyze required function resource identifiers and execute bitmap containing judgment methods at runtime, so that whether a user has permission can be judged, and repeated multi-association tables for each request are avoided.

Description

Technical Field

[0001] This invention relates to the field of access control technology, and in particular to a dual-model AP1 access control method and system based on bitmap materialized caching. Background Technology

[0002] As enterprise systems accumulate more business modules, a user typically holds multiple roles, and each role may be associated with multiple menus, buttons, APIs, and field permissions. Early systems usually controlled page display through menu trees and button permissions, and maintained multiple role-resource association tables in the database, such as role-menu association tables, role-button association tables, role-field association tables, or similar tables.

[0003] The above methods can meet the requirements of page visibility and basic role authorization. However, when APIs are directly called, the amount of permission data increases, the authorization chain needs to be audited, and field read / write needs to be forcibly controlled by the backend, the existing operation method splits permission resources into types such as menus, buttons, fields, and APIs, and establishes a relationship table between roles and resources. When authorizing roles, menu IDs, button IDs, field IDs, etc., are written to different role resource relationship tables. When a user has multiple roles, multiple relationship tables need to be queried and merged to remove duplicates. In high-frequency API authentication scenarios, database access is frequent, and the list cache is large. Moreover, permission resources are scattered across multiple tables, making it difficult to form a unified server-side authentication model. The binding relationship between APIs, buttons, and fields is unclear, and the server cannot use a single mechanism to determine whether a user can call APIs, click buttons, and read / write fields. Multiple relationship tables usually only record whether roles and resources are associated, lacking complete audit information such as the authorized operator, time, reason, version, validity period, and the effect of allowing or denying, making it difficult to trace the source of authorization.

[0004] In view of this, this solution proposes a dual-model API access control method and system based on bitmap materialized caching to solve the above problems. Summary of the Invention

[0005] The purpose of this invention is to provide a dual-model AP1 access control method and system based on bitmap materialized caching to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a dual-model AP1 access control method based on bitmap materialized caching, comprising the following operational steps: S1, construct the explicit authorization write model, and write the allow or deny relationship between roles and functional resource identifiers, along with application domain and validity period information, into the explicit authorization table; S2, establish a mapping relationship between trusted APIs on the server and functional resource identifiers; S3 receives the compilation trigger event, converts the explicit authorization write model into a bitmap read model, and the compilation input includes user role relationship, role authorization record, role status, user status, authorization validity period, authorization denial priority, resource status and field binding relationship. The compilation output is a set of valid functional resource identifiers of the user under a certain application domain, and serializes the set into compressed bitmap bytes. S4 materializes compressed bitmap bytes into a multi-level cache and performs atomic switching using a versioning key and a latest version pointer. S5 intercepts requests through the gateway, verifies the token to obtain the user's identity and application domain, queries the required functional resource identifier through the mapping relationship, loads the user's compressed bitmap, and calls the inclusion judgment method of the compressed bitmap to check whether the user has the required functional resource identifier. If the user has it, the request is allowed; otherwise, the request is rejected and recorded for auditing. S6. In the write request, check whether the user has write permission for the field. If the user does not have write permission, reject or remove the field. In the read request, check whether the user has read permission for the field. If the user does not have read permission, delete, set to null or de-identify the field. S7 records events such as authorization changes, permission compilation, cache hits, access denials, and field interception.

[0007] Preferably, the resource types of the functional resource identifier in S1 include menus, buttons, APIs, and fields, and the information written in the explicit authorization table includes role identifier, functional resource identifier, application domain, authorization effect, authorizer, authorization time, expiration time, authorization reason, and version number.

[0008] Preferably, the establishment of the mapping relationship in S2 is to map the required functional resource identifier to each trusted API of the server according to the Hypertext Transfer Protocol request path, request method, application domain and module.

[0009] Preferably, the compilation trigger events in S3 include adding, revoking, and modifying role authorizations, changing user role bindings, enabling or disabling roles, enabling or disabling functional resources, changing API mappings, and scheduled reconstruction tasks.

[0010] Preferably, the step of performing authorized compilation after receiving the compilation trigger event includes the following steps: S301: Receive the compilation trigger event and determine the compilation scope. If the change only affects a single role, compile the role-level bitmap first, then find the user who has the role and update the user-level bitmap. If the change only affects the role binding of a user, only compile the user. If the change affects resource mapping or field binding, compile in batches according to the affected functional resource identifiers, application domains, or modules. S302, Read the set of valid user roles, the explicit authorization record corresponding to each role, the authorization effect, the authorization validity period, the role status, the user status, and the resource status; S303: Add function resource identifiers that are authorized and not expired or disabled to the allowed set, and add function resource identifiers that are authorized and not expired or disabled to the denied set; if business rules require role inheritance or hierarchical synchronization, the permissions of superior, subordinate or same organization roles can be merged in this step; S304, prioritizing the denial of authorization, remove the denial set from the allow set, and remove resources that do not belong to the current application domain, are expired, or are disabled, to obtain the final set of valid functional resource identifiers; S305, writes the final set of valid functional resource identifiers into the compressed bitmap to obtain serializable bytes.

[0011] Preferably, the field binding relationship in S3 is predefined by the resource mapping module, which associates the API's functional resource identifier with the field's functional resource identifier and distinguishes between read permission, write permission, or read-write permission.

[0012] Preferably, the multi-level cache in S4 includes a first-level process cache, a second-level distributed cache, and a database rollback compilation path. In the gateway interception request, the user compressed bitmap is loaded in the order of the first-level process cache, the second-level distributed cache, and the database rollback compilation path.

[0013] Preferably, when the gateway intercepts a request, it performs the following steps: S501, Hypertext Transfer Protocol request or gRPC gateway request enters the user service gateway. The gateway verifies the JSON network token, session or server identity context, and obtains user identifier, tenant, application domain and tracking identifier information. S502: Query the request path, request method, and application domain in the resource mapping to query the required functional resource identifier. If the mapping does not exist and the route is a strictly protected route, then return permission denied. S503 queries the first-level process cache. If a cache hit occurs, a bitmap object is returned directly. If the first-level process cache misses, the latest version pointer and corresponding version bitmap of the second-level distributed cache are returned. If the second-level distributed cache misses or the version expires, database rollback compilation is triggered. S504, call the inclusion judgment method of the compressed bitmap, pass in the required functional resource identifier. If it returns true, then request to enter the subsequent business logic; if it returns false, then reject the request and record the reason for not having permission. S505: If a resource mapping is missing, a cache error occurs, a compilation error occurs, or a dependency is unavailable, and there is no safe fallback path, then access is denied.

[0014] Preferably, the field deletion, nulling, or desensitization processing includes removing fields without read permissions from the response data, setting field values ​​to null, or partially hiding field values; wherein the desensitization strategy is configured according to the sensitivity level of the field.

[0015] A dual-model API access control system based on bitmap materialization caching is used to execute a dual-model API access control method based on bitmap materialization caching. It includes an explicit authorization module, a resource mapping module, a permission compilation module, a bitmap materialization caching module, a gateway authentication module, a field permission module, and an audit and observation module, which are deployed inside the user server or split into independent components. The explicit authorization module is used to map menus, buttons, APIs and fields to function resource identifiers, and to store role identifiers, function resource identifiers, application domains, authorization effects, authorizers, authorization times, expiration times, authorization reasons and version numbers in a role authorization table or an equivalent authorization table; The resource mapping module is used to establish a mapping relationship between trusted APIs on the server and authorized resources; The permission compilation module is used to convert the explicit authorization write model into a bitmap read model; The bitmap materialization cache module is used to materialize the compressed bitmap bytes output by the permission compilation module into a multi-level cache; The gateway authentication module is used to perform unified verification before the business logic is executed; The field permission module is used to unify field-level read and write operations; The control audit and observation module is used to record events such as authorization changes, permission compilation, cache hits, access denials, and field interception.

[0016] The technical effects and advantages of this invention are as follows: (1) This invention converts real-time query of multiple association tables and list merging judgment into pre-compiled compressed bitmap inclusion judgment. At runtime, it only needs to parse the required functional resource identifier and execute the bitmap inclusion judgment method to determine whether the user has permission, avoiding repeated use of multiple association tables for each request. At the same time, this solution maps menus, buttons, application programming interfaces and fields to functional resource identifiers and enters the same explicit authorization and bitmap judgment system, using the same mechanism to express multi-level permissions of application programming interface callable, button operable, and field readable and writable.

[0017] (2) The explicit authorization write model of the present invention can record the operator, authorization time, authorization reason, authorization version, authorization validity period and allow / deny effect, explain why a certain role has a certain permission, and also support authorization traceability, version playback and security audit. Attached Figure Description

[0018] Figure 1This is a schematic diagram of the operation flow of the access method of the present invention.

[0019] Figure 2 This is a logical block diagram of the access system of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Example 1: The present invention provides as follows Figure 1 The illustrated bi-model API access control method based on bitmap materialized caching includes the following steps: S1. Construct an explicit authorization writing model and write the allow or deny relationship between roles and functional resource identifiers, along with application domain and validity period information, into the explicit authorization table. Simultaneously, publish authorization change events to the message bus. The resource types of functional resource identifiers include menus, buttons, APIs, and fields. The information written into the explicit authorization table includes role identifier, functional resource identifier, application domain, authorization effect, authorizer, authorization time, expiration time, authorization reason, and version number. The administrator selects the protected resource for the target role (role_id) through the permission configuration entry and abstracts it uniformly as func_id. The administrator specifies the application domain (scope, value Web / App), authorization effect (effect, value allow / deny), validity period (expire_at), and authorization reason (reason). The authorizer (granted_by) and grant time (granted_at) are automatically filled in, and the version field is used to implement authorization version tracking.

[0022] It should be noted that the explicit authorization write model replaces the old main authorization expression of multiple role resource association tables of role_menu, role_button, and role_field classes. The system unifies the authorization relationship between roles and menus, buttons, fields, and APIs into an explicit authorization record of role to func_id, that is, different resource types are uniformly mapped to func_id and written to the explicit authorization table or equivalent write model.

[0023] The role editing interface no longer maintains multiple role_xxx association tables as the main data source, but instead writes to the explicit authorization write model; the permission compilation module then compiles the authorization records into role-level and user-level RoaringBitmaps. The old association table method is no longer used as a hot path dependency for runtime API authentication; server-side authentication is based on resource mapping and bitmap read models.

[0024] For protected APIs, the system uses strict mode to perform server-side permission checks; for field-level permissions, the system performs write permission checks and read permission checks on the request write path and response read path respectively, so that field permissions are transformed from page display rules to backend enforced rules.

[0025] S2 establishes a mapping relationship between trusted APIs on the server and functional resource identifiers. The mapping relationship is established by mapping the required functional resource identifier (required_func_id) to each trusted API on the server according to the Hypertext Transfer Protocol request path, request method, application domain and module. This mapping is maintained by the server and does not depend on the x-menu-id passed in from the front end. Even if the x-menu-id continues to exist for compatibility with the old front end, it can only be used for logging, statistics or page context analysis and cannot be used as the basis for the final authorization decision.

[0026] S3 receives compilation trigger events, transforms the explicit authorization write model into a bitmap read model, and the compilation input includes user role relationships, role authorization records, role status, user status, authorization validity period, authorization denial priority, resource status, and field binding relationships. The compilation output is a set of valid functional resource identifiers for a user under a certain application domain, and serializes the set into compressed bitmap bytes. For each user, it aggregates the authorization records of all valid roles and filters out invalid records. Invalid records are any one of the following: expired, role disabled, user disabled, and resource unavailable. Compilation trigger events include adding, revoking, and modifying role authorizations, changing user role bindings, enabling or disabling roles, enabling or disabling functional resources, changing API mappings, and scheduled reconstruction tasks. Field binding relationships are predefined by the resource mapping module, associating API functional resource identifiers with field functional resource identifiers and distinguishing between read permissions, write permissions, or read-write permissions.

[0027] Specifically, after receiving the compilation trigger event, permission-based compilation is performed, including the following steps: S301: Receive the compilation trigger event and determine the compilation scope. If the change only affects a single role, compile the role-level bitmap first, then find the user who has the role and update the user-level bitmap. If the change only affects the role binding of a user, only compile the user. If the change affects resource mapping or field binding, compile in batches according to the affected functional resource identifiers, application domains, or modules. S302, Read the set of valid user roles, the explicit authorization record corresponding to each role, the authorization effect, the authorization validity period, the role status, the user status, and the resource status; S303: Add function resource identifiers that are authorized and not expired or disabled to the allowed set, and add function resource identifiers that are authorized and not expired or disabled to the denied set; if business rules require role inheritance or hierarchical synchronization, the permissions of superior, subordinate or same organization roles can be merged in this step; S304, apply conflict rules, prioritizing denial of authorization, remove the denial set from the allow set, and remove resources that do not belong to the current application domain, are expired, or are disabled, to obtain the final valid set of functional resource identifiers; S305 generates a bitmap, which writes the final set of valid functional resource identifiers into the compressed bitmap to obtain serializable bytes. Compared with ordinary arrays or JSON lists, compressed bitmaps are suitable for storing large-scale sparse integer sets and can provide fast inclusion judgment operations with a small storage volume.

[0028] S4. The compressed bitmap bytes are materialized into a multi-level cache, and atomic switching is achieved through versioning keys and the latest version pointer. The multi-level cache includes a first-level process cache, a second-level distributed cache, and a database rollback compilation path. In the gateway interception request, the user compressed bitmap is loaded in the order of the first-level process cache, the second-level distributed cache, and the database rollback compilation path. A role-level bitmap and a user-level valid permission bitmap are maintained. The role-level bitmap is used to quickly reuse the authorization results of the same role, and the user-level bitmap is used to merge the permissions of multiple roles owned by a user and directly use them for API authentication. The multi-level cache structure consists of a first-level user service in-process cache, a second-level Redis distributed cache, and a bottom-level database rollback compilation path. First, the new bitmap is written with versioning keys such as: User {User ID}: {Application Domain}: v {Version Number}, and then the permission: User {User ID}: {Application Domain}: latest version pointer is switched to the new version through atomic operations of a remote dictionary service or an equivalent mechanism. The pointer is switched only after the new bitmap has been fully written, thus avoiding requests to read from a partially compiled state.

[0029] S5 intercepts requests through the gateway, verifies the token to obtain user identity and application domain, queries the required functional resource identifier through mapping relationships, loads the user's compressed bitmap, and calls the inclusion check method of the compressed bitmap to check whether the user possesses the required functional resource identifier. If the user does, the request is allowed; otherwise, it is rejected and recorded for auditing. This is used for unified verification before business logic execution. It obtains user identity and request information from the server context, parses the functional resource identifier (denoted as `required_func_id`) through the resource mapping module, loads the user's valid permission bitmap, and finally calls the inclusion check method of the compressed bitmap (denoted as `RoaringBitmap`) to determine whether the user has access rights. In strict mode, if the resource mapping is missing, the permission bitmap fails to load, or compilation fails, the request is rejected by default. Specifically, when the gateway intercepts a request, it performs the following steps: S501, Hypertext Transfer Protocol request or gRPC gateway request enters the user service gateway. The gateway verifies the JSON network token, session or server identity context, and obtains user identifier, tenant, application domain and tracking identifier information. S502, query the request path, request method and application domain in the resource mapping to query the required functional resource identifier. If the mapping does not exist and the route is a strictly protected route, then return permission denial. This step only uses the mapping relationship maintained by the server and does not trust the menu ID, button ID or x-menu-id passed by the client. S503 queries the first-level process cache. If a cache hit occurs, a bitmap object is returned directly. If the first-level process cache misses, the latest version pointer and corresponding version bitmap of the second-level distributed cache are returned. If the second-level distributed cache misses or the version expires, database rollback compilation is triggered. S504, execute permission check, call the inclusion check method of the compressed bitmap, pass in the required functional resource identifier, if return true value, then request to enter the subsequent business logic; if return false value, then reject the request and record the reason for no permission; S505: If a resource mapping is missing, a cache is abnormal, a compilation error occurs, or a dependency is unavailable, and there is no safe fallback path, access will be denied to prevent unauthorized access due to system anomalies.

[0030] S6: In write requests, the system checks whether the user has write permissions for a field. If the user lacks write permissions, the field is rejected or removed. In read requests, the system checks whether the user has read permissions for a field. If the user lacks read permissions, the field is deleted, set to null, or masked. Deletion, nulling, or masking includes removing fields without read permissions from the response data, setting the field value to null, or partially hiding the field value. The masking strategy is configured according to the field's sensitivity level. Fields are treated as FIELD type functional resources and enter the same func_id system, establishing a connection with specific APIs through API field binding relationships. In write requests, the system determines whether the user has write permissions for a field; in read responses, the system determines whether the user has read permissions for a field and deletes, sets, or masks fields for which the user lacks permissions.

[0031] It should be noted that field-level permissions reuse the same set of `func_id`, explicit authorization, and bitmap judgment mechanisms. Field resources are entered into the function tree as FIELD types and associated with `api_func_id` through API field binding relationships. Field permissions can distinguish between read, write, or read-write.

[0032] During the write path, the system parses the request body fields, queries the field resources bound to the current API, and determines whether the user's valid permission bitmap contains write permissions for the corresponding field. For fields without write permissions, the system can reject the request or remove the field according to business configuration; when sensitive fields, monetary fields, organizational fields, or identity fields are involved, the rejection policy is preferred.

[0033] During the read path, the system checks the read permissions of the fields bound to the current API before returning the response. For fields that the user does not have read permissions for, the system can perform deletion, set to null, or de-identify the data, and can return the field permission results to the front end to ensure that the front end display is consistent with the back end's mandatory control.

[0034] S7 records events such as authorization changes, permission compilation, cache hits, access denials, and field interceptions. For each denied request, the system records the user identifier, request path, request method, application domain, required functional resource identifier, decision result, denial reason, tracking identifier, and request identifier. For each authorization change, the system records the operator, the versions before and after the change, the authorization reason, and the scope of impact.

[0035] It should be noted that the core data structures of this technical solution include an explicit role authorization table, an API resource mapping table, and an API field binding table. The explicit role authorization table expresses the authorization facts of a role for any functional resource. The API resource mapping table expresses the trusted server-side mapping from path and method to required_func_id. The API field binding table expresses which field resources a given API involves and the applicable read / write modes for each field.

[0036] In the explicit role authorization table, `role_id` represents the role, `func_id` represents the functional resource such as a menu, button, API, or field, `scope` represents the Web, App, or other application domain, `effect` represents allow or deny, `granted_by` represents the authorizing operator, `granted_at` represents the authorization time, `expire_at` represents the authorization expiration time, `reason` represents the authorization reason, and `version` represents the authorized version. This table allows the system to clearly answer the authorization status of a specific role for a specific resource under a specific version.

[0037] In the API resource mapping table, `path` represents the request path, `method` represents the request method, `required_func_id` represents the required functional permissions to access the API, `scope` represents the application domain, `module` represents the application system it belongs to, and `status` indicates whether the mapping is enabled. In strict mode, if a protected API is not configured with a mapping, the system will deny access according to the fail-closed principle.

[0038] In the API field binding table, `api_func_id` represents the API function resource, `field_func_id` represents the field function resource, and `mode` indicates read, write, or read-write. This binding allows the system to synchronously determine field read / write permissions when calling the API, rather than simply displaying field permissions as a front-end configuration.

[0039] Example 2: The present invention provides as follows Figure 2 The illustrated dual-model API access control system based on bitmap materialization caching is used to execute a dual-model API access control method based on bitmap materialization caching in Embodiment 1. It includes an explicit authorization module, a resource mapping module, a permission compilation module, a bitmap materialization caching module, a gateway authentication module, a field permission module, and an audit and observation module, which are deployed inside the user server or split into independent components. The explicit authorization module is used to map menus, buttons, APIs and fields to function resource identifiers, and to store role identifiers, function resource identifiers, application domains, authorization effects, authorizers, authorization times, expiration times, authorization reasons and version numbers in a role authorization table or an equivalent authorization table; The resource mapping module is used to establish a mapping relationship between trusted APIs on the server and authorized resources; The permission compilation module is used to convert the explicit authorization write model into a bitmap read model; The bitmap materialization cache module is used to materialize the compressed bitmap bytes output by the permission compilation module into a multi-level cache; The gateway authentication module is used to perform unified verification before the business logic is executed; The field permission module is used to unify field-level read and write operations; The control audit and observation module is used to record events such as authorization changes, permission compilation, cache hits, access denials, and field interception.

[0040] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A dual-model AP1 access control method based on bitmap materialized caching, characterized in that, The following steps are included: S1, construct the explicit authorization write model, and write the allow or deny relationship between roles and functional resource identifiers, along with application domain and validity period information, into the explicit authorization table; S2, establish a mapping relationship between trusted APIs on the server and functional resource identifiers; S3 receives the compilation trigger event, converts the explicit authorization write model into a bitmap read model, and the compilation input includes user role relationship, role authorization record, role status, user status, authorization validity period, authorization denial priority, resource status and field binding relationship. The compilation output is a set of valid functional resource identifiers of the user under a certain application domain, and serializes the set into compressed bitmap bytes. S4 materializes compressed bitmap bytes into a multi-level cache and performs atomic switching using a versioning key and a latest version pointer. S5 intercepts requests through the gateway, verifies the token to obtain the user's identity and application domain, queries the required functional resource identifier through the mapping relationship, loads the user's compressed bitmap, and calls the inclusion judgment method of the compressed bitmap to check whether the user has the required functional resource identifier. If the user has it, the request is allowed; otherwise, the request is rejected and recorded for auditing. S6. In the write request, check whether the user has write permission for the field. If the user does not have write permission, reject or remove the field. In the read request, check whether the user has read permission for the field. If the user does not have read permission, delete, set to null or de-identify the field. S7 records events such as authorization changes, permission compilation, cache hits, access denials, and field interception.

2. The dual-model AP1 access control method based on bitmap materialized caching according to claim 1, characterized in that, The resource types of the functional resource identifier in S1 include menus, buttons, APIs, and fields. The information written in the explicit authorization table includes role identifier, functional resource identifier, application domain, authorization effect, authorizer, authorization time, expiration time, authorization reason, and version number.

3. The dual-model AP1 access control method based on bitmap materialized caching according to claim 1, characterized in that, The establishment of the mapping relationship in S2 is to map the required functional resource identifier to each trusted API of the server according to the Hypertext Transfer Protocol request path, request method, application domain and module.

4. The dual-model AP1 access control method based on bitmap materialized caching according to claim 1, characterized in that, The compilation trigger events in S3 include adding, revoking, and modifying role authorizations, changing user role bindings, enabling or disabling roles, enabling or disabling functional resources, changing API mappings, and scheduled rebuild tasks.

5. The dual-model AP1 access control method based on bitmap materialized caching according to claim 4, characterized in that, Upon receiving the compilation trigger event, performing authorized compilation includes the following steps: S301: Receive the compilation trigger event and determine the compilation scope. If the change only affects a single role, first compile the role-level bitmap, then find the user who owns the role and update the user-level bitmap. If the change only affects the role bindings of a specific user, then only compile for that user; If the change affects resource mapping or field binding, compile in batches according to the affected functional resource identifiers, application domains or modules; S302, Read the set of valid user roles, the explicit authorization record corresponding to each role, the authorization effect, the authorization validity period, the role status, the user status, and the resource status; S303, add the function resource identifiers whose authorization effect is allowed and not expired or disabled to the allowed set, and add the function resource identifiers whose authorization effect is denied and not expired or disabled to the denied set; If business rules require role inheritance or hierarchical synchronization, the permissions of superior, subordinate, or same-organization roles can be merged in this step. S304, prioritizing the denial of authorization, remove the denial set from the allow set, and remove resources that do not belong to the current application domain, are expired, or are disabled, to obtain the final set of valid functional resource identifiers; S305, writes the final set of valid functional resource identifiers into the compressed bitmap to obtain serializable bytes.

6. The dual-model AP1 access control method based on bitmap materialized caching according to claim 1, characterized in that, The field binding relationship in S3 is predefined by the resource mapping module, which associates the API's functional resource identifier with the field's functional resource identifier and distinguishes between read permission, write permission, or read-write permission.

7. The dual-model AP1 access control method based on bitmap materialized caching according to claim 6, characterized in that, The multi-level cache in S4 includes a first-level process cache, a second-level distributed cache, and a database rollback compilation path. In the gateway interception request, the user compressed bitmap is loaded in the order of the first-level process cache, the second-level distributed cache, and the database rollback compilation path.

8. The dual-model AP1 access control method based on bitmap materialized caching according to claim 7, characterized in that, When the gateway intercepts a request, it performs the following steps: S501, Hypertext Transfer Protocol request or gRPC gateway request enters the user service gateway. The gateway verifies the JSON network token, session or server identity context, and obtains user identifier, tenant, application domain and tracking identifier information. S502: Query the request path, request method, and application domain in the resource mapping to query the required functional resource identifier. If the mapping does not exist and the route is a strictly protected route, then return permission denied. S503 queries the first-level process cache. If a cache hit occurs, a bitmap object is returned directly. If the first-level process cache misses, the latest version pointer and corresponding version bitmap of the second-level distributed cache are returned. If the second-level distributed cache misses or the version expires, database rollback compilation is triggered. S504, call the inclusion judgment method of the compressed bitmap, pass in the required functional resource identifier. If it returns true, then request to enter the subsequent business logic; if it returns false, then reject the request and record the reason for not having permission. S505: If a resource mapping is missing, a cache error occurs, a compilation error occurs, or a dependency is unavailable, and there is no safe fallback path, then access is denied.

9. The dual-model AP1 access control method based on bitmap materialized caching according to claim 1, characterized in that, The deletion, nulling, or desensitization processing of the fields includes removing fields without read permissions from the response data, setting the field value to null, or partially hiding the field value; wherein, the desensitization strategy is configured according to the sensitivity level of the field.

10. A dual-model AP1 access control system based on bitmap materialized caching, used to execute the dual-model AP1 access control method based on bitmap materialized caching as described in any one of claims 1-9, characterized in that, It includes an explicit authorization module, a resource mapping module, a permission compilation module, a bitmap materialization caching module, a gateway authentication module, a field permission module, and an audit and observation module, which are deployed inside the user server or split into independent components; The explicit authorization module is used to map menus, buttons, APIs and fields to function resource identifiers, and to store role identifiers, function resource identifiers, application domains, authorization effects, authorizers, authorization times, expiration times, authorization reasons and version numbers in a role authorization table or an equivalent authorization table; The resource mapping module is used to establish a mapping relationship between trusted APIs on the server and authorized resources; The permission compilation module is used to convert the explicit authorization write model into a bitmap read model; The bitmap materialization cache module is used to materialize the compressed bitmap bytes output by the permission compilation module into a multi-level cache; The gateway authentication module is used to perform unified verification before the business logic is executed; The field permission module is used to unify field-level read and write operations; The control audit and observation module is used to record events such as authorization changes, permission compilation, cache hits, access denials, and field interception.

Images