A processing method for multi-tenant permission hierarchical access control of a zero-work platform

Abstract

This invention discloses a multi-tenant hierarchical access control processing method for gig platforms, specifically relating to the fields of computer networks and information security technology. It addresses the challenge of simultaneously achieving isolation, dynamic authorization, and tamper-proof archiving in cross-domain access under multi-tenant collaboration. By responding to cross-domain collaborative matching events triggered by the first and second tenants for a target user, it extracts minimal set attribute data and generates a target shadow entity in the second tenant. It outputs an entity binding message to the API gateway layer, generates and issues a first permission policy token around the lifecycle state vector, triggers global permission circuit breaking, identifies and rolls back concurrent write requests to be tested at the archive locking node, forms a pre-archiving cache, and obtains the final state shadow entity. Subsequently, it generates a data digest hash tree based on cross-domain interaction data, receives digital signatures, performs three-party signature consensus verification, and outputs a legality release certificate and a rights-confirming archive payload.

Description

Technical Field

[0001] This invention relates to the field of computer network and information security technology, and more specifically, to a multi-tenant hierarchical access control method for gig economy platforms. Background Technology

[0002] This invention relates to a multi-tenant collaborative processing scenario in the field of computer network and information security technology for gig work platforms. During the collaboration between idle employees of an enterprise and short-term R&D projects of the employing party, the platform needs to maintain data isolation between the first and second tenants, while also completing cross-domain collaboration, attendance tracking, work hour confirmation, and subsequent archiving around the target user. Therefore, identity mapping, dynamic authorization, concurrent write control, and archiving rights confirmation in the cross-domain access chain become continuously interconnected problems.

[0003] In the existing technology, the scheme with application number CN114884653A, entitled "A Method, System, Device and Medium for Cross-Tenant Access in Multi-Tenant Contexts," mainly determines the access type through a gateway center and processes cross-tenant access requests by combining a cross-tenant mechanism with the tenant's internal access control model. This type of processing can support general cross-tenant access, but in high-frequency collaboration scenarios of gig platforms, it is still difficult to simultaneously cover the generation of shadow entities in isolated data spaces, token issuance and circuit breaking as the state vector changes with the lifecycle, rollback and cleanup of concurrent cross-domain write requests under test, and three-party signature consensus archiving based on the final shadow entity. Therefore, the problem of an incomplete cross-domain collaboration chain still exists.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies in the prior art, embodiments of the present invention provide a multi-tenant permission-based hierarchical access control processing method for gig platforms. This method involves responding to cross-domain collaborative matching events triggered by the first and second tenants for a target user, extracting minimum set attribute data, generating a target shadow entity in the second tenant, outputting an entity binding message to the API gateway layer, generating and issuing a first permission policy token around the lifecycle state vector, triggering global permission circuit breaking, identifying and rolling back concurrent write requests under test at the archive locking node, forming a pre-archiving cache area and obtaining the final state shadow entity, then generating a data digest hash tree based on cross-domain interaction data, receiving digital signatures and performing three-party signature consensus verification, and outputting a legality release certificate and a confirmation archive payload to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: S1: In response to the cross-domain collaborative matching event triggered by the first tenant and the second tenant, intercept the flow request and extract the minimum set attribute data, generate the target shadow entity in the second tenant and output the entity binding message; S2: After receiving the entity binding message, the API gateway layer listens to the lifecycle state vector and issues the first permission policy token with timestamp and route label to the second tenant when the work execution node is executed. S3: Monitor the lifecycle state vector, revoke the first permission policy token when transitioning from the worker execution node to the archive locking node, and roll back and clean up cross-domain concurrent write requests within the latency interception window to obtain the final state shadow entity. S4: Extract cross-domain interaction data from the final shadow entity to generate a data digest hash tree. After receiving the digital signatures generated by the first tenant, the second tenant, and the target user client, execute the three-party signature consensus verification protocol and trigger the underlying security interface to perform authorization archiving when the verification is successful.

[0007] Furthermore, in step S1, the first tenant identifier, the second tenant identifier, the target user identifier, and the collaborative project identifier are concatenated in a fixed order to generate a collaborative matching index key. The collaborative matching index key is used to perform an equivalent search on the cross-domain collaborative matching event registration table. When the search results match, a processing context is formed, the unique correspondence between the first tenant, the second tenant, the target user, and the collaborative project is frozen, and the access relationship between the original identity carrier and the second tenant's isolated data space is switched to a controlled access relationship driven by the processing context.

[0008] Furthermore, in step S1, the original identity record of the target user is reorganized into an indexable attribute sequence according to the field mapping rules. Then, the target user is matched item by item according to the preset field whitelist order and the encoding is unified, the time expression is unified, and the enumeration value is standardized to form a minimal set attribute sequence that corresponds one-to-one with the field whitelist order. The target shadow entity is generated in the second tenant according to the minimal set attribute sequence, and an entity binding record between the target user and the target shadow entity is established at the same time.

[0009] Furthermore, in step S2, onboarding confirmation events, onboarding activation events, task completion events, and archive submission events are continuously collected from the collaborative project business event stream. These events are then rearranged into a status event sequence in ascending order of arrival time. The status event sequence is mapped to a lifecycle status vector that retains only one valid status bit. This vector is then written into the status cache using the unique identifier of the target shadow entity as the key, so that subsequent node decisions revolve around the continuously updated lifecycle status vector in the status cache.

[0010] Furthermore, in step S2, when the state machine-driven attribute access control algorithm is called, the lifecycle state vectors written in two adjacent entries in the state buffer are read first as state transition input pairs. Then, the work execution node is determined to be hit according to the state transition rules preset by the collaborative project. If it is hit, an access determination triplet is constructed with the second tenant identifier, the unique identifier of the target shadow entity, and the collaborative project identifier. When it is consistent with the entity binding record, an authorization trigger result is generated, and the first permission policy token is registered in the token index table.

[0011] Furthermore, in step S3, when the lifecycle state vector is detected to transition from the work execution node to the archive locking node, the current valid state of the first permission policy token is rewritten to the circuit breaker state and a revocation timestamp is written to form a revocation record corresponding to the unique identifier of the target shadow entity; then, a delay interception window is constructed with the revocation timestamp as the starting point, and its endpoint is determined by the upper quartile position of the historical network round-trip delay samples of the collaborative project in ascending order.

[0012] Furthermore, in step S3, the request header is extracted for each cross-domain concurrent write request to be tested that enters the latency interception window, and rearranged according to a fixed sorting rule to form a sequence of headers to be tested; then the baseline header sequence is extracted from the historical interaction record of the target shadow entity, and the minimum number of operation steps between the two is calculated using a dynamic programming algorithm with insertion, deletion and replacement as the transition units, so as to obtain the request message structure edit distance offset bound to the corresponding cross-domain concurrent write request to be tested.

[0013] Furthermore, in step S3, the historical request arrival timestamps of the second tenant are mapped to a time-domain discrete pulse signal sequence according to a fixed sampling interval. A fast Fourier transform is performed on the time-domain discrete pulse signal sequence, and the ratio of the energy integral value of the preset high-frequency band interval to the total energy integral value of the entire band is extracted as the high-frequency energy ratio of the access time-series frequency domain. This ratio is then input together with the distance bias of the request message structure editing into the isolated forest machine learning model to generate interception decision coefficients.

[0014] Furthermore, in step S4, using the unique identifier of the target shadow entity and the collaborative project identifier as extraction indexes, the retained local state data is extracted from the final state shadow entity in the order of writing to form a cross-domain interaction data sequence. Then, it is divided into leaf data blocks according to a fixed-length sharding rule, and leaf digests, parent digests, and root digests are generated layer by layer to form a data digest hash tree. The root digest is then bound to the unique identifier of the target shadow entity and the collaborative project identifier and written into the consensus cache.

[0015] Furthermore, in step S4, the root digest, along with the unique identifier of the target shadow entity, the collaborative project identifier, and the locking token, is encapsulated into a signature request and sent to the first tenant, the second tenant, and the target user client respectively. Digital signatures are received in a fixed order to form a three-party signature set. Then, signature verification is performed based on the pre-registered public key of each signature subject, and the consistency of the signature pointing to the digest, the entity binding record, and the final state shadow entity is verified. If the verification is successful, a legality release certificate and a confirmation archive payload are generated.

[0016] The technical effects and advantages of the multi-tenant hierarchical access control processing method for gig work platforms of the present invention are as follows: This invention first generates a target shadow entity within the isolated data space of the second tenant. This transforms the cross-domain collaboration needs of the target user in the first tenant into a controlled processing chain revolving around the target shadow entity. Therefore, the second tenant does not need to directly access the original identity object and business carrier in the first tenant during collaboration, and the cross-tenant data call boundary can be fixed after the entity binding message is established. The direct result is that writing, verification, and archiving in cross-domain collaboration all fall within the controllable scope of the second tenant. The core data of the first tenant is not continuously exposed during the collaboration process, the data isolation relationship is clearer, and subsequent processing objects do not switch back and forth between different tenants.

[0017] This invention further uses a lifecycle state vector to drive the issuance and revocation of the first permission policy token, ensuring that the second tenant obtains short-term, independent write permissions for local state data corresponding to the work execution node, rather than continuously open permissions for the entire collaboration cycle. When the lifecycle state vector transitions to the archive locking node, the global permission circuit breaker mechanism immediately revokes the first permission policy token and, combined with a latency interception window, continues to process tail-arriving cross-domain concurrent write requests. The practical benefit of this is that the write period for local state data is explicitly compressed into the executable interval, and residual writes before archiving will not directly mix into the final result. This reduces the possibility of old requests continuing to rewrite data after collaboration ends, making the data boundary more stable when the final state shadow entity is formed.

[0018] This invention also uses the request message structure edit distance offset and the proportion of high-frequency energy in the access time frequency domain together to identify cross-domain concurrent write requests under test. When the interception decision coefficient meets the conditions, rollback cleanup is performed. Then, a data digest hash tree is generated from the cross-domain interaction data in the final-state shadow entity, and the three-party signature consensus verification is completed by combining the digital signatures of the first tenant, the second tenant, and the target user client. The specific benefits of this are that abnormal writes and normal writes no longer rely solely on a single rule for judgment. Data before archiving can be converged before entering signature verification, and the resulting legal release certificate and ownership-confirming archive payload can correspond one-to-one with the final-state shadow entity, facilitating subsequent consistency verification of collaborative results, signature sources, and archived content. Attached Figure Description

[0019] Figure 1 This is a diagram illustrating the overall architecture of the multi-tenant hierarchical access control method for the gig economy platform of the present invention. Figure 2 This is a graph for generating permission policy tokens driven by the lifecycle state vector of this 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] Please see Figures 1-2 This invention provides a multi-tenant hierarchical access control processing method for a gig economy platform, comprising: S1: In response to the cross-domain collaborative matching event triggered by the first tenant and the second tenant, intercept the flow request and extract the minimum set attribute data, generate the target shadow entity in the second tenant and output the entity binding message; S2: After receiving the entity binding message, the API gateway layer listens to the lifecycle state vector and issues a first permission policy token with a timestamp and routing label to the second tenant at the work execution node. S3: Monitor the lifecycle state vector, revoke the first permission policy token when transitioning from the work execution node to the archive locking node, and roll back and clean up cross-domain concurrent write requests within the latency interception window to obtain the final state shadow entity. S4: Extract the cross-domain interaction data within the final state shadow entity to generate a data digest hash tree. After receiving the digital signatures generated by the first tenant, the second tenant, and the target user client, execute the three-party signature consensus verification protocol and trigger the underlying security interface to perform authorization archiving when the verification is successful.

[0022] This invention uses the cross-domain collaborative relationship between the first tenant, the second tenant, and the target user as the input basis. First, the minimum set attribute data of the target user in the first tenant is projected as the target shadow entity in the second tenant, and the mapping relationship and subsequent reference boundary are fixed through entity binding messages. Then, the API gateway layer continuously listens to the lifecycle state vector around the target shadow entity, and issues the first permission policy token to the second tenant at the worker execution node, so that the local state data is written into the controlled link. When the lifecycle state vector enters the archive locking node, the cross-domain concurrent write request under test is identified, judged, and rolled back and cleaned up in combination with the latency interception window, and the final state shadow entity is obtained. Finally, the cross-domain interaction data in the final state shadow entity is used as the object to generate a data digest hash tree, and the digital signatures of the first tenant, the second tenant, and the target user client are aggregated to complete the three-party signature consensus verification and form a legality release certificate and a rights confirmation archive payload.

[0023] In the multi-tenant collaboration scenario of the gig economy platform, after the first tenant and the second tenant form a cross-domain collaboration relationship around the target user, the target user's business identity begins to be projected from the original tenant to the collaborating tenant. However, the existing cross-tenant direct connection method will cause the second tenant to directly access the data carrier of the first tenant, resulting in the instability of the isolation boundary and the permission boundary. Therefore, step S1 completes the interception of identity transfer requests, minimal set attribute projection, and target shadow entity generation when the collaboration matching event is triggered, forming the controlled access object on which subsequent permission control depends from the source. The first tenant is the tenant to which the target user belongs, and serves as the source tenant for the target user's original identity record and original business relationship; the second tenant is the tenant that establishes a collaboration relationship with the first tenant around the same collaboration project, and serves as the carrier tenant for the target shadow entity, local state data, and the cache area before subsequent archiving; the target user is the business entity belonging to the first tenant and participating in the execution of the second tenant's collaboration project.

[0024] S101: Cross-domain collaborative matching event targeted identification and identity transfer request interception.

[0025] When a cross-domain collaborative matching event is formed between the first tenant and the second tenant for the target user, the server takes this cross-domain collaborative matching event as the starting point for step S1 and performs interception processing before the identity transfer request enters the inter-tenant routing link, so that the original identity object of the target user is first removed from the direct cross-domain transmission path and then enters the controlled mapping process.

[0026] In practice, the server synchronously reads the first tenant identifier, the second tenant identifier, the target user identifier, and the collaborative project identifier from the business collaboration triggering link, and concatenates these four objects in a fixed order to generate a collaborative matching index key. Then, it performs an equivalent search in the cross-domain collaborative matching event registration table using the collaborative matching index key. When the search result is completely consistent with the source tenant, destination tenant, user affiliation, and project affiliation in the current identity transfer request, the identity transfer request is marked as a verified identity transfer request, and its corresponding processing context is frozen. The processing context at least maintains a unique correspondence between the first tenant, the second tenant, the target user, and the collaborative project.

[0027] Once this processing context is established, the server will transfer the verified identity transfer request into the attribute extraction link and switch the direct access relationship between the original identity carrier and the isolated data space of the second tenant to a controlled access relationship driven by the verified identity transfer request. As a result, all subsequent attribute extraction actions will use the verified identity transfer request as the sole entry object, avoiding the formation of a sustainable cross-tenant direct connection channel for the target user during the identity projection stage, while providing a definite source and destination boundary for the subsequent generation of minimal set attribute data.

[0028] S102: Generate minimal set attribute data projection based on a preset field whitelist.

[0029] After the verified identity transfer request is formed, the processing chain enters the attribute convergence stage. At this time, the full identity data of the target user in the first tenant is no longer processed. Instead, ordered projection is performed according to the preset field whitelist to make the data range entering the isolated data space of the second tenant consistent with the range of subsequent collaborative processing.

[0030] In practice, the server first calls the field mapping rules corresponding to the first tenant's identity model to reorganize the target user's original identity record in the first tenant into an indexable attribute sequence. Then, it performs field matching judgment item by item according to the preset field whitelist order. Once any whitelist field is matched, the corresponding attribute value is extracted from the original identity record, and format normalization processing is performed simultaneously. The format normalization processing includes encoding unification, time expression unification, and enumeration value standardization, so that the attribute values ​​output by different first tenant internal identity models can enter the same sequence under a unified semantics. After all whitelist fields are processed, the server only retains the matched attribute values ​​and their whitelist order positions to generate minimal set attribute data.

[0031] To enable this minimal set attribute data to directly participate in subsequent mappings, the server continues to assign fixed ordinal positions to each attribute value according to the whitelist order, and binds the fixed ordinal positions to the attribute values ​​one by one to form a minimal set attribute sequence. This minimal set attribute sequence does not retain extended attributes that are not related to subsequent collaborations, but only retains the necessary attributes to support the establishment of the target shadow entity, subsequent local state updates of the target shadow entity, and the generation of entity binding messages. At this point, the minimal set attribute data obtains a definite source object, sequential structure, and mappable boundaries, and serves as the direct input for the next sub-step to generate the target shadow entity.

[0032] S103: Output of target shadow entity construction, mapping binding and entity binding messages.

[0033] After the minimal set attribute data is generated, the processing chain enters the identity projection stage. The server creates a target shadow entity that only maps the minimal set attribute data in the isolated data space of the second tenant, so that subsequent collaborative writing revolves around the target shadow entity.

[0034] In practice, the server first allocates a unique identifier for the target shadow entity within the isolated data space of the second tenant for the current processing context, and creates a target shadow entity carrier using this unique identifier as the primary index. Then, it writes the minimum set attribute sequence item by item into the target shadow entity according to its fixed order, establishing a one-to-one mapping between the target shadow entity and the target user in the first tenant. After writing, the server generates an entity binding record based on the first tenant identifier, the second tenant identifier, the target user identifier, the collaborative project identifier, and the unique identifier of the target shadow entity. This entity binding record maintains a stable mapping between the target user's original identity object and the target shadow entity, and serves as the binding basis for the subsequent API gateway layer to identify collaborative access objects.

[0035] After the entity binding record is finalized, the server extracts the unique identifier of the target shadow entity as the core output item, and encapsulates it with the collaborative project identifier and tenant correspondence to form an entity binding message, which is then sent to the API gateway layer. Upon receiving the entity binding message, the API gateway layer can establish a listening entry point for the subsequent lifecycle state vector around the unique identifier of the target shadow entity, and perform the necessary access control processing on the local state data related to the target shadow entity within the second tenant without touching the original identity object of the first tenant.

[0036] Through step S1, the server has completed the determination of the verified identity transfer request, the ordered extraction of the minimum set attribute data, and the isolation construction of the target shadow entity after the cross-domain collaborative matching event is triggered. It further generates an entity binding message containing the unique identifier of the target shadow entity. The target shadow entity, entity binding record, and entity binding message formed in this way constitute the direct calling basis for subsequent steps, enabling the API gateway layer to continue to perform lifecycle state monitoring and permission policy issuance processing around the target shadow entity rather than the original identity object of the first tenant.

[0037] After step S1 is completed, the API gateway layer has received the entity binding message and obtained the unique identifier of the target shadow entity, the entity binding record, and the processing context corresponding to the collaborative project. At this time, although the second tenant has a controlled access object, it has not yet obtained any write authorization. However, attendance, work hour reporting, and phased result confirmation in gig collaboration all occur during the continuous change of the target user's business status. Therefore, step S2 needs to establish a status determination link around the lifecycle state vector of the target user in the collaborative project on the basis that the entity binding relationship has been established, and generate a routable, time-stampable, and revocable first permission policy token when determining entry into the work execution node.

[0038] S201: Acquisition and construction of lifecycle state vectors and establishment of listening entry points.

[0039] After the entity binding message arrives at the API gateway layer, the processing chain first uses the unique identifier of the target shadow entity in the entity binding message as the main index for listening. At this time, the API gateway layer does not directly establish a listener for the original identity object of the target user in the first tenant, but instead puts the tenant correspondence and the collaborative project identifier in the entity binding record into the listening context, so that all subsequent status collection actions revolve around the target shadow entity.

[0040] In practice, the API gateway layer continuously collects status trigger events related to the target user from the business event stream of the collaborative project, and rearranges them into a status event sequence in ascending order of event arrival time. The status trigger events include at least the onboarding confirmation event, onboarding activation event, task completion event, and archive submission event that can change the collaborative execution stage. Subsequently, the API gateway layer maps the status event sequence into a lifecycle state vector. The lifecycle state vector is a discrete state representation organized in a fixed state bit order, used to identify the unique business stage that the target user is in in the current collaborative project. Each state bit corresponds one-to-one with the collaborative project stage, and includes at least the pending collaboration node, the work execution node, and the archive locking node, where only one valid state bit is retained at any given time.

[0041] Once the lifecycle state vector is generated for the first time, the API gateway layer establishes a state cache using the unique identifier of the target shadow entity as the key, and writes the latest lifecycle state vector into the state cache. Subsequently, the state trigger events that arrive later are continued to be incorporated into the state event sequence, and the single-value evolution result of the lifecycle state vector is maintained through sequential updates. In this way, the API gateway layer obtains a continuously monitored lifecycle state vector, providing continuous input for the next sub-step to call the state machine-driven attribute access control algorithm.

[0042] S202: State machine-driven attribute access control algorithm invocation and worker execution node determination.

[0043] After the lifecycle state vector enters the state cache, the processing chain moves to the authorization determination stage. At this time, the API gateway layer uses the latest lifecycle state vector in the state cache as the current state input, and uses the tenant correspondence in the entity binding record and the unique identifier of the target shadow entity as the access object constraint. It calls the state machine-driven attribute access control algorithm to determine whether the second tenant has the qualification to write to the target shadow entity in the current stage.

[0044] In practice, the state machine-driven attribute access control algorithm employs a joint decision-making method combining finite state machines and attribute access control. The finite state machine calculates whether the lifecycle state vector has transitioned to the working execution node, while the attribute access control determines whether the second tenant's operation scope on the target shadow entity is limited to local state data. The finite state machine first reads the lifecycle state vectors written in two consecutive steps from the state buffer to form a state transition input pair. Then, it performs node matching according to the state transition rules preset by the collaborative project. When the valid state bit corresponding to the latest lifecycle state vector falls into the working execution node, and this valid state bit is allowed to be reached by the state transition rules, the working execution node hit result is output.

[0045] After the work execution node hit result is formed, the attribute access control part continues to construct an access decision triplet using the second tenant identifier, the unique identifier of the target shadow entity, and the collaborative project identifier. This access decision triplet is then compared with the tenant correspondence in the entity binding record for consistency. If the consistency comparison passes, the operation to be authorized is limited to a local state data write operation. This local state data is a set of state data attached to the target shadow entity and reflecting the progress of the collaborative project execution, used to carry the business update results generated by the second tenant during the work execution phase. Only when the work execution node hit result is true and the access decision triplet is consistent with the entity binding record will the state machine-driven attribute access control algorithm output an authorization trigger result, which is then sent to the next sub-step as the condition for generating the first permission policy token.

[0046] S203: Generation, encapsulation, and distribution of the first permission policy token.

[0047] After the authorization trigger result is output, the processing chain enters the token construction stage. At this time, the API gateway layer uses the authorization trigger result as the start condition, and uses the unique identifier of the target shadow entity, the second tenant identifier, and the local state data writing range as the token payload to generate the first permission policy token that can directly drive the subsequent write route.

[0048] In practice, the API gateway layer first generates a timestamp for the current authorization trigger result. This timestamp is taken from the moment the API gateway layer completes the authorization determination and serves as the effective start point for the first permission policy token. Subsequently, a routing label is generated based on the combination relationship between the second tenant identifier and the unique identifier of the target shadow entity. This routing label is used to direct subsequent write requests to the local state data write entry point corresponding to the target shadow entity within the second tenant. After the timestamp and routing label are written, the API gateway layer encapsulates the short-term independent write permission into a token permission bit. The short-term independent write permission only points to the local state data of the target shadow entity and maintains the same mapping boundary with the entity binding record, thus forming a complete first permission policy token.

[0049] After the first permission policy token is generated, the API gateway layer distributes it to the second tenant and simultaneously registers the target shadow entity's unique identifier, timestamp, route tag, and the token's current validity status in the token index table. The registration results in the token index table serve as the direct basis for subsequent write request verification, route matching, and permission circuit breaking. After receiving the first permission policy token, the second tenant must include this first permission policy token in the API gateway layer's verification chain when initiating writes to local state data of the target shadow entity, thus completing the closed-loop processing from state determination to the issuance of short-term independent write permissions.

[0050] Through step S2, the API gateway layer has established a lifecycle state vector listening entry based on the entity binding message and entity binding record, completed the state machine-driven attribute access control algorithm call, and generated and issued a first permission policy token with a timestamp and routing label when the lifecycle state vector is at the working execution node. The lifecycle state vector, authorization trigger result, first permission policy token and token index table registration result formed therefrom can all be directly called by subsequent steps. Among them, the lifecycle state vector continues to be used for node transition monitoring, and the first permission policy token and its current valid state continue to serve as the basis for global permission circuit breaking and concurrent write verification.

[0051] After step S2 is completed, the API gateway layer has established a lifecycle state vector listening entry around the target shadow entity and issued a first permission policy token with timestamp and routing label to the second tenant. At this time, the local state data enters the writable stage. However, once the target user's business phase in the collaborative project changes from the execution stage to the archiving stage, continuous writing will change the data boundary that has been formed. Therefore, step S3 needs to complete the permission revocation first after the node jump occurs, and then perform dual-parameter identification and cleanup on the remaining cross-domain concurrent write requests to be tested in the latency interception window, and finally output the final state shadow entity that can be processed by hash consensus.

[0052] S301: Lifecycle state vector transition monitoring and global permission circuit breaker triggering.

[0053] After the first permission policy token is in a valid state, the processing chain continues to expand the lifecycle state vector written in the state cache in step S2. The API gateway layer uses the unique identifier of the target shadow entity as the retrieval key to continuously read the latest lifecycle state vector and the previous lifecycle state vector in the state cache, and performs adjacent node comparisons according to the state transition rules of the collaborative project, thereby determining whether the target user has transitioned from the work execution node to the archive locking node.

[0054] When the comparison results of adjacent nodes satisfy the directed transfer relationship from the work execution node to the archive locking node, the API gateway layer immediately triggers the global permission circuit breaker mechanism. The global permission circuit breaker mechanism is a revocation action that performs an atomic rewrite of the current valid state of the first permission policy token in the token index table. Specifically, it includes updating the current valid state of the first permission policy token to the circuit breaker state, writing a revocation timestamp, and establishing a one-to-one correspondence between the unique identifier of the target shadow entity and the circuit breaker state. After the revocation record is generated, all subsequent write requests from the second tenant for the local state data of the target shadow entity must first go through the circuit breaker state comparison. Only requests that have entered the gateway link before the revocation timestamp will be transferred to the next stage for further review.

[0055] After the revocation record is formed, the API gateway layer constructs a preset latency interception window starting from the revocation timestamp. The preset latency interception window is a limited time period used to absorb residual requests at the end of the route. Its endpoint is determined by the upper quartile of the historical network round-trip latency samples of the collaborative project in ascending order. Subsequently, the API gateway layer collects all write requests carrying the unique identifier of the target shadow entity and the first permission policy token within this time period, forming a set of cross-domain concurrent write requests to be tested, which are then called one by one by the subsequent two-parameter identification links.

[0056] S302: Request message structure editing distance offset construction calculation.

[0057] After the set of cross-domain concurrent write requests to be tested is formed, the processing chain first enters the message structure analysis stage. At this time, the API gateway layer extracts the request header from each cross-domain concurrent write request to be tested, rearranges it according to the fixed sorting rules of the header key name, and then converts the rearranged header string character by character into an ASCII encoding sequence to generate an array of header ASCII strings to be tested. Correspondingly, the API gateway layer extracts the write request headers that were normally received during the validity period of the first permission policy token from the historical interaction record of the target shadow entity, and generates a baseline header ASCII string array according to the same sorting rules and the same encoding method, so that the two types of arrays are on the same comparison dimension.

[0058] After the two types of arrays are aligned, the API gateway layer calls the Levenshtein edit distance dynamic programming algorithm for calculation. Specifically, the API gateway layer first establishes a two-dimensional dynamic programming matrix using the sequence positions of the ASCII string array of the header to be tested and the ASCII string array of the baseline header. Then, using insertion, deletion, and replacement as state transition units, it calculates the cumulative minimum number of operation steps from the starting position to the current comparison position for each type of array. After the dynamic programming matrix has been traversed, the minimum number of operation steps in the terminating unit is read and recorded as the edit distance offset of the request message structure.

[0059] After the request message structure editing distance bias is generated, the API gateway layer establishes an index binding with the corresponding cross-domain concurrent write request to be tested and writes it into the interception feature cache. Since this bias directly represents the structural offset of the cross-domain concurrent write request to be tested relative to the baseline header ASCII string array, it will subsequently be used as the first dimension input of the isolated forest machine learning model, together with the high-frequency energy ratio of the access time series frequency domain to form a two-dimensional feature space.

[0060] S303: Extraction of the proportion of high-frequency energy in the access time-frequency domain.

[0061] After the distance offset of the request message structure is edited and cached, the processing chain continues to enter the time sequence feature construction stage. The API gateway layer establishes a time sequence based on the arrival timestamps of historical requests initiated by the second tenant against the target shadow entity. The arrival timestamps of the historical requests are taken from the token index table and the write records in the gateway access log that have completed route matching, and rearranged into an arrival timestamp sequence in chronological order.

[0062] Subsequently, the API gateway layer discretizes the arrival timestamp sequence at fixed sampling intervals, recording each arrival event within a sampling interval as a discrete pulse. If multiple arrival events occur within the same sampling interval, they are summed according to their arrival counts to form a pulse amplitude, thus constructing a time-domain discrete pulse signal sequence. After this sequence is formed, the API gateway layer calls the Fast Fourier Transform algorithm to transform the time-domain discrete pulse signal sequence to the frequency domain. Based on the upper quartile boundary of the normal collaborative writing sample spectrum energy distribution, a preset high-frequency band interval is determined. Then, the spectral energy within this interval is integrated and summed to obtain the energy integral value of the preset high-frequency band interval. Simultaneously, the entire frequency band is integrated and summed to obtain the total energy integral value of the entire frequency band. Subsequently, the API gateway layer divides the energy integral value of the preset high-frequency band interval by the total energy integral value of the entire frequency band to obtain the high-frequency energy proportion in the access time sequence frequency domain. This proportion is written into the interception feature buffer as the second dimension input of the subsequent isolated forest machine learning model.

[0063] S304: Isolation Forest Machine Learning Model Decision, Rollback Cleanup, and Final State Shadow Entity Generation.

[0064] Once the distance offset of the request message structure editing and the proportion of high-frequency energy in the access time frequency domain have been written into the interception feature cache, the processing chain enters the joint judgment stage. The API gateway layer reads the two feature values ​​corresponding to the same cross-domain concurrent write request under test from the interception feature cache one by one, forming a two-dimensional feature vector. This two-dimensional feature vector is then input into a pre-built isolated forest machine learning model, where multiple random decision trees cut the two-dimensional feature space to measure the isolation difficulty of the cross-domain concurrent write request under test in all random cutting paths.

[0065] For example, the pre-built isolated forest machine learning model can be characterized by a tree set structure; correspondingly, the model can be obtained through offline training. Specifically, the model structure can be set to 256 isolated trees, with a maximum tree depth of 9 for each isolated tree, a subsampling sample size of 512 for a single isolated tree, a minimum number of split samples per node of 2, and each split randomly selecting one feature from two input features as the current split feature. The split threshold is randomly generated within the current value range of the feature. The anomaly contamination rate can be set to 0.12 for example, and the random seed can be set to 2024 for example. If it is necessary to further tighten the anomaly detection boundary, the number of trees can be adjusted to 300 for example, the maximum tree depth can be adjusted to 10 for example, and the anomaly contamination rate can be adjusted to the optimal training value within the range of 0.08 to 0.15 for example.

[0066] For example, the training dataset can consist of historical cross-domain write samples, with a total of 120,000 samples, including 90,000 normal write requests and 30,000 abnormal write requests. Each sample is a two-dimensional feature record consisting of the request message structure edit distance offset and the proportion of high-frequency energy in the access time-series frequency domain, and is correlated with the sample source time, the unique identifier of the target shadow entity, and whether a rollback cleanup has occurred in the historical results. Abnormal write requests can be obtained in two ways: one is by directly extracting them from historical rollback cleanup records, and the other is by performing message header perturbation and arrival rhythm compression on normal write requests to form simulated abnormal samples. During training, the training and validation sets can be divided in an 8:2 ratio, and linear normalization is first performed on all two-dimensional feature records. Then, each isolated tree is built independently on the training set. Afterward, the recall rate for abnormal requests and the false blocking rate for normal requests are calculated on the validation set to select the final parameter combination. For example, when the recall rate for abnormal requests reaches 0.96 and the false blocking rate for normal requests is controlled within 0.03, the corresponding tree set parameters are written into the model configuration table as pre-training parameters to be called during deployment. Since the isolated forest machine learning model uses an unsupervised isolated modeling approach, the completion of model training can be defined, for example, as the validation set metric fluctuating by no more than 0.005 for three consecutive rounds.

[0067] In the current processing, the Isolation Forest machine learning model outputs the average path length for each cross-domain concurrent write request to be tested, and uses the reciprocal of the average path length to form the interception decision coefficient. The shorter the average path length, the larger the interception decision coefficient, indicating that the corresponding request deviates more from the normal interaction area in the two-dimensional feature space. The security threshold can be taken as the 90th percentile of the interception decision coefficients of all normal requests in the validation set corresponding to the online parameters. The API gateway layer compares the interception decision coefficient of the current cross-domain concurrent write request to be tested with the security threshold. When the interception decision coefficient exceeds the security threshold, a rollback cleanup is performed on the corresponding cross-domain concurrent write request to be tested. Specifically, this includes locating the local state data change fragments that have been written but not yet archived by the request, reversing the change fragments in reverse order according to the revocation timestamp, restoring the data image that has been confirmed at the time of the circuit breaker trigger, and writing a lock mark on the target shadow entity. When the interception decision coefficient does not exceed the security threshold, only the valid write results completed by the request before the circuit breaker trigger are retained and merged into the data image before the lock is triggered.

[0068] After the latency interception window closes, the API gateway layer reconstructs the current state of the target shadow entity using the data mirror before locking and the retained valid write results, obtaining the final state shadow entity with locked state and consistent data. The final state shadow entity, locking flag, interception decision coefficient and its corresponding cleanup result are written into the pre-archiving cache area, so that step S4 can directly extract cross-domain interaction data and generate a data digest hash tree.

[0069] Through step S3, the API gateway layer has completed global permission circuit breaking when the lifecycle state vector transitions from the worker execution node to the archive locking node. Within the preset latency interception window, it forms the set of cross-domain concurrent write requests to be tested, the request message structure edit distance offset, the proportion of high-frequency energy in the access time frequency domain, and the interception decision coefficient. Then, it performs rollback cleanup on abnormal requests and outputs a final state shadow entity with a locking mark and consistent data. The final state shadow entity, the locking mark, and the cleanup results in the pre-archiving cache can all be directly called by subsequent steps to continue to execute the three-party signature consensus verification and automated data rights confirmation and archiving.

[0070] After step S3 is completed, a final-state shadow entity with a lock mark and consistent data has been formed in the pre-archiving cache area, and the cleaned cross-domain interaction results and corresponding processing traces are retained. At this time, the write link of the second tenant has stopped, and the collaborative data boundary is fixed. However, the lock result alone is not enough to support cross-enterprise data ownership confirmation and subsequent automatic archiving. Therefore, step S4 needs to complete the generation of data digest hash tree, aggregation of three-party digital signatures and verification of three-party signature consensus on the basis of the final-state shadow entity, and output the legality release certificate after the verification is passed and trigger the underlying security interface to execute automatic data ownership confirmation and archiving.

[0071] S401: Cross-domain interactive data extraction and data digest hash tree generation.

[0072] After the final-state shadow entity enters the locked state, the processing chain first reads the final-state shadow entity, the locking flag, and the corresponding cleanup result from the pre-archiving cache. Using the unique identifier of the target shadow entity and the collaborative project identifier as extraction indexes, it extracts the already retained local state data from the final-state shadow entity in the order it was written, forming a cross-domain interaction data sequence. Subsequently, the server divides the cross-domain interaction data sequence into multiple leaf data blocks according to a fixed-length sharding rule and calls the Merkle tree construction algorithm to calculate the digest value layer by layer. Specifically, it first executes the SM3 hash algorithm on each leaf data block to obtain a leaf digest, then concatenates adjacent leaf digests in order and continues to execute the SM3 hash algorithm to generate a parent digest, until a unique root digest is obtained. All leaf digests, parent digests, and root digests together constitute the data digest hash tree. After the data digest hash tree is generated, the server writes the root digest, the unique identifier of the target shadow entity, and the collaborative project identifier into the consensus cache as a unified digest benchmark for the three-party signature.

[0073] S402: Generation, reception, and signature set construction of third-party digital signatures.

[0074] After the data digest hash tree is generated, the processing chain moves to the signature aggregation stage. At this time, the server uses the root digest in the consensus cache as the unique signature object, encapsulates the root digest together with the unique identifier of the target shadow entity, the collaborative project identifier and the locking token into a signature request, and sends it to the first tenant, the second tenant and the target user client respectively, so that the three parties perform the signature action around the same digest object.

[0075] Upon receiving the signature request, the first tenant, the second tenant, and the target user client each use their respective private keys to generate digital signatures for the root digest, and return the digital signatures along with the corresponding signature subject identifiers to the server. After receiving the three digital signatures, the server first rearranges the signatures in a fixed order: first tenant, second tenant, and target user client. Then, it binds the three digital signatures with the root digest, the unique identifier of the target shadow entity, and the collaborative project identifier to form a three-party signature set. Once the three-party signature set is formed, the server writes it to the consensus cache for the next sub-step to execute the three-party signature consensus verification protocol.

[0076] S403: Generation of execution and legality release certificate for the three-party signature consensus verification protocol.

[0077] After the three-party signature set enters the consensus buffer, the processing chain enters the verification and release phase. At this time, the server uses the root digest in the data digest hash tree, the three-party signature set, the entity binding record, the final shadow entity, and the locking flag as joint inputs to execute the three-party signature consensus verification protocol. In specific implementation, the server first performs SM2 digital signature verification on each of the three digital signatures according to the pre-registered public keys of the first tenant, the second tenant, and the target user client to obtain the corresponding valid signature results. Subsequently, the digest values ​​pointed to by the three digital signatures are compared with the root digest in the consensus buffer for consistency, and the signature subject identifier is bound to the correspondence between the first tenant, the second tenant, the target user, and the collaborative project in the entity binding record for binding verification, so that the signature source, digest object, and business object complete the same source matching.

[0078] When all three digital signatures are valid and the digest consistency comparison and binding verification pass simultaneously, the three-party signature consensus verification protocol outputs a consensus pass result. The server then generates a legitimacy release credential based on the root digest, the unique identifier of the target shadow entity, the collaborative project identifier, and the consensus pass result, and writes the legitimacy release credential into the archiving control queue. Subsequently, the underlying security interface is triggered to extract the cross-domain interaction data, data digest hash tree, three-party signature set, and legitimacy release credential from the final-state shadow entity in the pre-archiving cache, combine them to form the rights confirmation archiving payload, and write it into the rights confirmation archiving storage area, thereby completing the automated data rights confirmation archiving.

[0079] Through step S4, the server has extracted cross-domain interaction data and generated a data digest hash tree based on the final shadow entity and the locking token. It then receives digital signatures generated by the first tenant, the second tenant, and the target user client based on their respective independent private keys, completes the execution of the three-party signature consensus verification protocol, and generates a legitimacy release credential after the verification is passed, triggering the underlying security interface to complete the automated data ownership confirmation and archiving. The resulting data digest hash tree, three-party signature set, consensus result, legitimacy release credential, and ownership confirmation and archiving payload together constitute the final state result of data ownership confirmation in the cross-enterprise collaboration scenario of this invention.

[0080] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for hierarchical access control for multi-tenant permissions on a gig economy platform, characterized in that, Including the following steps: S1: In response to the cross-domain collaborative matching event triggered by the first tenant and the second tenant, intercept the flow request and extract the minimum set attribute data, generate the target shadow entity in the second tenant and output the entity binding message; S2: After receiving the entity binding message, the API gateway layer listens to the lifecycle state vector and issues the first permission policy token with timestamp and route label to the second tenant when the work execution node is executed. S3: Monitor the lifecycle state vector, revoke the first permission policy token when transitioning from the worker execution node to the archive locking node, and roll back and clean up cross-domain concurrent write requests within the latency interception window to obtain the final state shadow entity. S4: Extract cross-domain interaction data from the final shadow entity to generate a data digest hash tree. After receiving the digital signatures generated by the first tenant, the second tenant, and the target user client, execute the three-party signature consensus verification protocol and trigger the underlying security interface to perform authorization archiving when the verification is successful.

2. The multi-tenant access control method for a gig economy platform according to claim 1, characterized in that, In step S1, the first tenant identifier, the second tenant identifier, the target user identifier, and the collaborative project identifier are concatenated in a fixed order to generate a collaborative matching index key. An equivalent search is performed on the cross-domain collaborative matching event registration table using the collaborative matching index key. When the search results match, a processing context is formed, the unique correspondence between the first tenant, the second tenant, the target user, and the collaborative project is frozen, and the access relationship between the original identity carrier and the second tenant's isolated data space is switched to a controlled access relationship driven by the processing context.

3. The multi-tenant access control method for a gig economy platform according to claim 2, characterized in that, In step S1, the original identity record of the target user is reorganized into an indexable attribute sequence according to the field mapping rules. Then, the target user is matched item by item according to the preset field whitelist order and the encoding is unified, the time expression is unified, and the enumeration value is standardized to form a minimal set attribute sequence that corresponds one-to-one with the field whitelist order. The target shadow entity is generated in the second tenant according to the minimal set attribute sequence, and the entity binding record between the target user and the target shadow entity is established at the same time.

4. The multi-tenant access control method for a gig economy platform according to claim 1, characterized in that, In step S2, onboarding confirmation events, onboarding activation events, task completion events, and archive submission events are continuously collected from the collaborative project business event stream. These events are then rearranged into a status event sequence in ascending order of arrival time. The status event sequence is mapped to a lifecycle status vector that retains only one valid status bit. The sequence is then written into the status cache using the unique identifier of the target shadow entity as the key, so that subsequent node decisions revolve around the continuously updated lifecycle status vector in the status cache.

5. The multi-tenant access control method for a gig economy platform according to claim 4, characterized in that, In step S2, when the state machine-driven attribute access control algorithm is called, the lifecycle state vectors written in two consecutive steps in the state buffer are read as state transition input pairs. Then, the work execution node is determined to be hit according to the state transition rules preset by the collaborative project. If it is hit, an access determination triplet is constructed with the second tenant identifier, the unique identifier of the target shadow entity, and the collaborative project identifier. When it is consistent with the entity binding record, an authorization trigger result is generated, and the first permission policy token is registered in the token index table.

6. The multi-tenant hierarchical access control method for a gig economy platform according to claim 1, characterized in that, In step S3, when the lifecycle state vector is detected to transition from the work execution node to the archive locking node, the current valid state of the first permission policy token is rewritten to the circuit breaker state and a revocation timestamp is written to form a revocation record corresponding to the unique identifier of the target shadow entity. Then, a delay interception window is constructed starting from the cancellation timestamp, and its endpoint is determined by the upper quartile position of the historical network round-trip delay samples of the collaborative project in ascending order.

7. The multi-tenant hierarchical access control method for a gig economy platform according to claim 6, characterized in that, In step S3, the request header is extracted for each cross-domain concurrent write request to be tested that enters the latency interception window, and rearranged according to a fixed sorting rule to form a sequence of headers to be tested; then the baseline header sequence is extracted from the historical interaction record of the target shadow entity, and the minimum number of operation steps between the two is calculated using a dynamic programming algorithm with insertion, deletion and replacement as the transition units, so as to obtain the request message structure edit distance offset bound to the corresponding cross-domain concurrent write request to be tested.

8. The multi-tenant access control method for a gig economy platform according to claim 7, characterized in that, In step S3, the arrival timestamps of the historical requests of the second tenant are mapped to a time-domain discrete pulse signal sequence according to a fixed sampling interval. A fast Fourier transform is performed on the time-domain discrete pulse signal sequence, and the ratio of the energy integral value of the preset high-frequency band to the total energy integral value of the entire band is extracted as the high-frequency energy ratio of the access time-series frequency domain. This ratio is then input together with the distance bias of the request message structure editing into the isolated forest machine learning model to generate interception decision coefficients.

9. The multi-tenant hierarchical access control method for a gig economy platform according to claim 1, characterized in that, In step S4, using the unique identifier of the target shadow entity and the collaborative project identifier as extraction indexes, the retained local state data is extracted from the final state shadow entity in the order of writing to form a cross-domain interaction data sequence. Then, it is divided into leaf data blocks according to the fixed length sharding rule, and leaf digests, parent digests and root digests are generated layer by layer to form a data digest hash tree. The root digest is then bound to the unique identifier of the target shadow entity and the collaborative project identifier and written into the consensus cache area.

10. A multi-tenant hierarchical access control processing method for a gig economy platform according to claim 9, characterized in that, In step S4, the root digest, along with the unique identifier of the target shadow entity, the collaborative project identifier, and the locking token, is encapsulated into a signature request and sent to the first tenant, the second tenant, and the target user client respectively. The digital signatures are received in a fixed order to form a three-party signature set. Then, the signature verification is performed based on the pre-registered public key of each signature subject, and the consistency of the signature pointing to the digest, the entity binding record, and the final shadow entity is verified. If the verification is successful, a legality release certificate and a confirmation archive payload are generated.

Images