An intelligent program dynamic permission control method based on preset service rules

Abstract

The present application relates to the technical field of computer data processing and access control, and particularly relates to a kind of intelligent program dynamic permission control method based on preset business rules.The method comprises: receiving business rule configuration data and task instance, generating business rule relationship record, and determining target rule version when first authentication, forming task rule binding record;Request context record is generated based on task rule binding record, business rule relationship record is matched, and permission decision record and temporary permission state record are formed;According to the permission decision mark, read temporary permission state record and verify operation request;Receive business node state event, verify event mark and node state version, generate permission recovery event according to target rule version, and update temporary permission state record to invalid state according to permission state version.The present application makes the same task instance permission generation, verification and recovery reference consistent rule version and permission state.

Description

Technical Field

[0001] This invention relates to the field of computer data processing and access control technology, and in particular to an intelligent program dynamic permission control method based on preset business rules. Background Technology

[0002] In the field of computer data processing and access control technology, business applications typically employ role-based access control, attribute-based access control, or rule engine services for permission verification. Existing solutions generally pre-configure the correspondence between user identity, roles, user groups, business scenarios, target resources, and permission items. Upon receiving an authentication request, the permission center extracts the user identity and target operation, matches it with the corresponding business rules or static role permissions, and allows or prohibits the user from accessing the target function, interface, or data object based on the authentication result. Some solutions also record temporary authorization status through authorization tokens, permission validity periods, and rule versions.

[0003] When a temporary business task involves multiple business nodes, and the business rules change during task execution, existing solutions typically load the currently effective business rules during each authentication, or synchronize the latest rule version between the client and server. Multiple authentications of the same task instance may reference different rule versions, leading to inconsistencies in the basis for generating temporary permissions, the scope of business objects, and the conditions for revoking them. When relying solely on the permission items and validity period recorded in the authorization token, operation requests that have changed business nodes but whose authorization tokens have not yet expired may still carry the original permission information, easily causing a lag in the connection between the authorization token status and the server-side permission status.

[0004] Business node status is typically sent to the access control stage asynchronously by the task status management service via events. During asynchronous transmission, event duplication, changes in arrival order, or event delays may occur. Existing solutions often terminate authorization directly based on task completion status or wait for the authorization's validity period to expire before invalidating it, resulting in a lack of continuous state correspondence between business node status events, rule versions, and temporary permission states. Duplicate events may cause the same permission state to be updated multiple times, with earlier node status events potentially overwriting newer states. Delayed events may also cause inconsistencies between the rule conditions used when generating and revoking permissions. Therefore, it is necessary to address the issue of inconsistent rule versions and permission states for the generation, verification, and revocation of temporary permissions for the same task instance when business rule versions change and business node status events arrive asynchronously. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for dynamic access control of intelligent programs based on preset business rules, comprising:

[0006] S1. Receive business rule configuration data and task instances, establish mapping relationships between user identity conditions, task types, business nodes, target operations, business object scope and permission items, and generate business rule relationship records containing recycling conditions and rule versions; determine the target rule version during the first authentication of the task instance and generate task rule binding records.

[0007] S2. Receive authentication requests based on the task rule binding record, and write user identifier, task identifier, business node, target operation, business object scope, and target rule version into the request context record; match business rule relationship records to generate a permission decision record containing permission decision identifier and a temporary permission status record containing permission status version;

[0008] S3. Receive an operation request containing the permission decision identifier, read the temporary permission status record; verify the task identifier, target operation, business object scope and permission status, and generate an authentication result;

[0009] S4. Receive a business node status event containing an event identifier, a task identifier, a business node, and a node status version; when the event identifier is not recorded and the node status version is not lower than the recorded node status version, obtain the recycling conditions according to the target rule version, generate a permission recycling event, and update the temporary permission status record to the expired state when the permission status version is consistent.

[0010] Furthermore, the business rule relationship record includes rule identifier, rule version, user identity conditions, task type, applicable business node, target operation, target resource type, business object scope generation conditions, permission items, permission results, validity conditions, revocation conditions, rule priority, exclusive status, and effective status;

[0011] The business rule relationship record establishes a mapping relationship with permission items based on user identity conditions, task type, applicable business node, and target operation, and generates conditions to limit the business object scope of the permission items according to the target resource type and business object scope.

[0012] Furthermore, determining the target rule version includes:

[0013] Based on the task type and task creation time of the task instance, filter the rule version from the business rule relationship record that covers the task creation time within the effective time interval;

[0014] Write the task identifier, task type, target rule version, binding time, and binding status into the task rule binding record;

[0015] When the task instance is an in-transit task, subsequent authentication requests and business node status events continue to reference the target rule version;

[0016] When the effective status of the target rule version is updated to forced deactivation, a rule migration record is generated, and the target rule version and binding status are updated according to the rule migration record.

[0017] Furthermore, the generation of the request context record includes:

[0018] Extract the user identifier, identity identifier, task identifier, target operation, target resource, and request time from the authentication request;

[0019] Based on the task identifier, obtain the task type, business node, task status version, participating users, and business object scope from the task instance;

[0020] Obtain the target rule version based on the task rule binding record;

[0021] Verify whether the user identifier belongs to the user participating in the task, and write the verified user identifier, identity identifier, task identifier, task type, business node, task status version, target operation, target resource, business object scope, target rule version and request time into the request context record.

[0022] Furthermore, the permission decision record includes a permission decision identifier, a task identifier, a target rule version, a rule identifier, a permission item, a permission result, a business object scope, an effective time, and a permission decision status;

[0023] The temporary permission status record includes user identifier, task identifier, permission decision identifier, target rule version, permission item, business object scope, effective time, expiration time, permission status, and permission status version;

[0024] Write the same task identifier, target rule version, and permission decision identifier into the permission decision record and the temporary permission status record.

[0025] Furthermore, the matching business rule relationship record includes:

[0026] The candidate business rule set is filtered based on the target rule version, user identity conditions, task type, applicable business node, and target operation;

[0027] Filter business rule relationship records from the candidate business rule set according to rule priority and exclusivity status;

[0028] When the permission result includes both allowed and denied permissions, the denied permission item shall be used.

[0029] Take the intersection of the business object ranges corresponding to multiple permitted permission items, and select the earlier expiration time from multiple valid times;

[0030] When no business rule relationship records are found, the static role permission verification result is obtained, and the dynamic denial result takes precedence over the static role allow result.

[0031] Further, an authorization token is generated based on the temporary permission status record. The authorization token includes a permission decision identifier, a user identifier, a task identifier, an expiration time, and a verification value.

[0032] The operation request includes user identifier, task identifier, target operation, target resource, business object scope, request time, permission decision identifier, and permission status version;

[0033] Read the temporary permission status record stored on the server according to the permission decision identifier;

[0034] An access permission status is generated when the verification results of user identifier, task identifier, target operation, business object scope, and permission status version are consistent and the permission status is valid.

[0035] If the verification results are inconsistent or the permission status is not valid, an access-prohibited status is generated, and the permission status version stored on the server is returned.

[0036] Furthermore, the service node status event also includes the event time and the event source identifier;

[0037] The permission revokement event includes a permission revokement event identifier, a source event identifier, a task identifier, a temporary permission status record identifier, the permission status before revokement, the target permission status, the expected permission status version, and the revokement result;

[0038] If the event identifier has been recorded, return the permission revoke result corresponding to the event identifier;

[0039] When the node state version is lower than the recorded node state version, an out-of-order event record is generated and no new permission revocation event is generated;

[0040] If the current permission status version is inconsistent with the expected permission status version, the temporary permission status record is reread.

[0041] Furthermore, it also includes:

[0042] A temporary permission status record that is valid but whose current time has expired;

[0043] If the temporary permission status record does not contain a permission revocation event generated by a business node status event, an expiration revocation record and a permission revocation event are generated.

[0044] If updating the temporary permission status record fails, a retry record is generated and the number of retries is recorded.

[0045] If the number of retries does not exceed the maximum number of retries, the permission status version is reread and the temporary permission status record is updated.

[0046] When the number of retries exceeds the maximum number of retries, the permission status is updated to a recycling failure status, and an access-prohibited status is generated for subsequent operation requests.

[0047] Furthermore, it also includes:

[0048] Generate an operation log, which includes a request identifier, a permission decision identifier, a task identifier, a target rule version, a target operation, a business object scope, an authentication result, an interface execution result, and a request time.

[0049] Generate permission revoke results, which include event identifier, permission revoke event identifier, task identifier, permission status before revoke, updated permission status, permission status version, and processing time;

[0050] Based on the task identifier, target rule version, and permission decision identifier, establish a mapping relationship between the task rule binding record, request context record, permission decision record, temporary permission status record, operation log, permission revocation event, and permission revocation result.

[0051] The following are its main beneficial effects:

[0052] (1) To address the issue that multiple authentications of the same task instance may use different rule versions when the business rule version changes, the task instance is continuously associated with the target rule version determined during the first authentication by binding the task rule record. This ensures that the generation conditions of temporary permissions, the scope of business objects, the basis for subsequent authentication, and the conditions for revocation all correspond to the same target rule version, and retains the record relationship before and after the rule version migration.

[0053] (2) To address the potential delay in the connection between the authorization token, local operation status and server-side permission status, permission decision record, operation request and temporary permission status record are connected by permission decision identifier, so that the backend interface uses the permission status and permission status version stored on the server as the authentication basis; after the temporary permission status is updated, subsequent operation requests generate access allowed status or access denied status according to the updated permission status.

[0054] (3) To address the issues of duplicate, out-of-order, or delayed events that may occur during the asynchronous transmission of business node status events, duplicate event processing is controlled by event identifiers, old node status is restricted from entering the permission reclamation process by node status version, and old permission reclamation events are restricted from updating temporary permission status by permission status version; when a business node status event has not arrived, an expiration reclamation record and a permission reclamation event are generated based on the expiration time, so that node event reclamation and expiration reclamation act on the same temporary permission status record. Attached Figure Description

[0055] Figure 1 A flowchart illustrating a method for dynamic access control of intelligent programs based on preset business rules, provided in an embodiment of this application;

[0056] Figure 2 This is a structural block diagram of an intelligent program dynamic permission control method based on preset business rules, provided in an embodiment of this application. Detailed Implementation

[0057] Example 1: Refer to Figure 1 This is a flowchart illustrating a method for dynamic access control of intelligent programs based on preset business rules, provided by an embodiment of the present invention. The process may include at least steps S1-S4:

[0058] S1. Receive business rule configuration data and task instances, establish mapping relationships between user identity conditions, task types, business nodes, target operations, business object scope and permission items, and generate business rule relationship records containing recycling conditions and rule versions; determine the target rule version during the first authentication of the task instance and generate task rule binding records.

[0059] S2. Receive authentication requests based on the task rule binding record, and write user identifier, task identifier, business node, target operation, business object scope, and target rule version into the request context record; match business rule relationship records to generate a permission decision record containing permission decision identifier and a temporary permission status record containing permission status version;

[0060] S3. Receive an operation request containing the permission decision identifier, read the temporary permission status record; verify the task identifier, target operation, business object scope and permission status, and generate an authentication result;

[0061] S4. Receive a business node status event containing an event identifier, a task identifier, a business node, and a node status version; when the event identifier is not recorded and the node status version is not lower than the recorded node status version, obtain the recycling conditions according to the target rule version, generate a permission recycling event, and update the temporary permission status record to the expired state when the permission status version is consistent.

[0062] S1. Receive business rule configuration data and task instances, establish mapping relationships between user identity conditions, task types, business nodes, target operations, business object scope and permission items, and generate business rule relationship records including recycling conditions and rule versions; determine the target rule version when the task instance is authenticated for the first time, and generate task rule binding records.

[0063] This step is executed by the rule management module and task rule binding module in the permission center. The rule management module receives business rule configuration data and converts it into machine-readable business rule relationship records. The task rule binding module receives task instances and, when the task instance generates its first authentication request, filters the target rule version from the active business rule relationship records and establishes a mapping relationship between the task instance and the target rule version. The business rule configuration data can be submitted by the rule configuration terminal or generated from pre-stored business rule templates. The task instance is sent to the permission center by the task status management service after the creation of inventory tasks, stock transfer tasks, reconciliation tasks, promotion configuration tasks, or refund review tasks.

[0064] The business rule configuration data includes rule identifier, user identity conditions, task type, applicable business node, target operation, target resource type, business object scope generation conditions, permission items, permission results, validity conditions, eviction conditions, rule priority, exclusive status, and effective status. The user identity conditions include one or more fields such as the user's role, user group, organization, or store identifier; the task type represents the business category corresponding to the task instance; the applicable business node represents the task processing stage that the business rule allows to participate in permission matching; the target operation represents one of the following operations: query, add, modify, delete, submit, review, confirm outbound, or confirm inbound; the target resource type represents the type of page, function, interface, document, or data record; the business object scope generation conditions represent the field rules that extract store identifier, document identifier, product identifier, batch identifier, or record identifier from the task instance; the permission items represent the operations that the user is allowed or denied to execute when the matching conditions are met; the validity conditions include the permission activation node, permission activation time, and permission expiration time; the eviction conditions include the business node that triggers the permission status update, the task status, or the user participation status.

[0065] The technical feature of the business rule relationship record refers to a record formed by establishing a mapping relationship between user identity conditions, task type, applicable business node, target operation, business object scope generation conditions, and permission items according to preset fields. After receiving a business rule configuration data, the rule management module first checks whether the rule identifier is duplicated, and then checks whether the user identity conditions, task type, applicable business node, target operation, and permission items have readable fields. After the verification is passed, the business rule relationship record is written according to the corresponding order of user identity conditions to permission items, and the target resource type and business object scope generation conditions are written into the scope field corresponding to the permission item. Then, the validity conditions and recycling conditions are written into the status condition field, and the rule priority and exclusive status are written into the rule processing field.

[0066] In one implementation, the rule version consists of a version number, release time, and effective time interval. When the rule management module receives modified business rule configuration data under the same task type, it does not overwrite the original business rule relationship record, but generates a new rule version while retaining the business rule relationship record corresponding to the original rule version. The effective time interval includes the effective start time and the effective end time; rule versions without an effective end time remain effective until the rule configuration terminal submits a deactivation command or a new rule version replaces the rule version. The rule management module sorts multiple rule versions under the same task type according to their effective start time and records the relationships between the versions.

[0067] In one implementation, when multiple business rule configuration data have the same user identity conditions, task type, applicable business node, and target operation, the rule management module compares the business object scope generation conditions, permission results, and rule priority. If multiple records have different business object scopes or permission results, they are retained as multiple business rule relationship records. If all mapping fields of multiple records are the same but the rule identifiers are different, a rule duplication record is generated, and the effective status of the subsequently received business rule configuration data is set to pending review. For business rule configuration data whose effective start time is later than its effective end time, the rule management module generates a rule time anomaly record and does not add it to the business rule relationship record that is already in effect.

[0068] The task instance includes a task identifier, task type, task creation time, current business node, task status version, participating users, and task object records. The task object records include the stores, documents, products, batches, or data records involved in the task. After creating a task instance, the task status management service sends the task identifier and task type to the permission center; when the task instance has not yet generated a temporary permission request, the task rule binding module does not pre-bind the rule version. When the business application sends an authentication request for the task instance for the first time, the task rule binding module reads the task instance based on the task identifier and marks this authentication request as the first authentication trigger.

[0069] After the initial authentication is triggered, the task rule binding module filters rule versions from business rule relationship records whose effective time intervals cover the task creation time, based on the task type and task creation time. In another implementation, the initial authentication request time can be used instead of the task creation time for filtering, but subsequent authentications of the same task instance will continue to reference the initial filtering result. When only one rule version matching the time condition exists for the same task type, that rule version is set as the target rule version; when multiple rule versions with overlapping effective time intervals exist, the rule version with the later effective start time is selected, and a rule time overlap record is generated; when no rule version matching the time condition exists, a rule version mismatch status is generated, and the initial authentication does not proceed to the temporary permission generation process.

[0070] The task rule binding record technology refers to a version reference record formed by writing the task identifier, task type, target rule version, binding time, and binding status into the same record. After the task rule binding module generates the task rule binding record, it sets the binding status to valid. When a task instance is in the pending, executing, or pending review state, subsequent authentication requests and business node status events read the task rule binding record based on the task identifier, without reselecting the latest rule version. After a task instance enters the completed, canceled, rejected, or abnormally terminated state, the task rule binding record is still retained, and the binding status is updated to terminated for use in permission revocation and operation log queries.

[0071] In one implementation, when the effective status of the target rule version is updated to forced deactivation, the rule management module generates a rule deactivation record and sends the in-transit tasks bound by that target rule version to the task rule binding module. The task rule binding module filters alternative rule versions based on task type and generates a rule migration record including task identifier, original target rule version, alternative rule version, migration time, and migration status. If an alternative rule version exists and the migration status is complete, the target rule version and binding status in the task rule binding record are updated. If an alternative rule version does not exist, the binding status is updated to suspended authentication, and subsequent authentication requests do not generate new temporary permission status records. Temporary permission status records that are already in an effective state can enter S4 according to the revoke conditions in the original target rule version, or a permission revoke event can be generated based on the rule deactivation record.

[0072] Taking a cross-store transfer task as an example, the task status management service creates a task instance with task identifier T1001, task type cross-store transfer, task creation time July 1, 2026 at 10:00 AM, and current business node is pending outbound. The rule management module saves rule version V2 and rule version V3, where the effective start time of V3 is June 1, 2026, and no effective end time is set. When user A initiates the first authentication request to confirm outbound for task T1001, the task rule binding module filters out rule version V3, generates a task rule binding record, and records the task identifier T1001, task type cross-store transfer, target rule version V3, binding time, and effective binding status. When rule version V4 is subsequently released, task T1001 still references V3; newly created task instances whose first authentication time falls within the effective time range of V4 reference V4.

[0073] This step generates business rule relationship records and task rule binding records. The business rule relationship records provide S2 with the user identity conditions, task type, applicable business node, target operation, business object scope generation conditions, permission items, validity conditions, and revoke conditions corresponding to the target rule version. The task rule binding records provide S2 with the task identifier, task type, target rule version, and binding status, and provide S4 with the target rule version referenced when revoking permissions. Rule duplication records, rule time anomaly records, rule version mismatch statuses, and rule migration records are all stored by task identifier or rule identifier and used as status verification input during subsequent authentication or permission revoke.

[0074] S2. Receive authentication requests based on the task rule binding record, and write user identifier, task identifier, business node, target operation, business object scope and target rule version into the request context record; match business rule relationship records to generate a permission decision record containing permission decision identifier and a temporary permission status record containing permission status version.

[0075] This step is executed by the request context generation module, permission decision module, and rule engine service in the permission center. The request context generation module receives the task rule binding record formed by S1 and receives the authentication request sent by the business application; the permission decision module calls the rule engine service based on the request context record to filter and match records applicable to this authentication request from the business rule relationship record formed by S1; after the matching is completed, the permission decision module generates a permission decision record and generates a temporary permission status record when the permission result is that temporary authorization is allowed.

[0076] The authentication request is sent by the business application when a user requests access to a page, function, or interface with controlled permissions. The authentication request includes a request identifier, user identifier, identity identifier, task identifier, target operation, target resource, and request time. The request identifier distinguishes multiple authentication requests; the user identifier corresponds to the user account record; the identity identifier corresponds to the role, user group, organization, or store record; the task identifier is used to read the task instance and task rule binding record; the target operation represents the operation the user requests to perform; the target resource represents the page, function, interface, document, or data record targeted by this request; and the request time is submitted by the business application and verified by the permission center by recording the receipt time.

[0077] After receiving the authentication request, the request context generation module first reads the task instance based on the task identifier to obtain the task type, current business node, task status version, participating users, and task object records; then, it reads the target rule version and binding status based on the task rule binding record. The scope of the business object is jointly generated by the business object scope generation conditions in the task object record and the business rule relationship record; for example, when the business object scope generation conditions specify limiting the scope by the transfer order identifier in the task instance, the request context generation module extracts the transfer order identifier from the task object record and uses the transfer order and its detailed records as the business object scope; when the business object scope generation conditions specify limiting the scope by the inventory area, it extracts the inventory area identifier assigned to the current user from the task object record.

[0078] The aforementioned request context recording technology refers to an authentication input record formed by writing fields from the authentication request, fields from the task instance, and the target rule version from the task rule binding record into the same record. The request context generation module first verifies whether the user identifier belongs to a task participant; then it verifies whether the binding status of the task rule binding record is valid; subsequently, it verifies whether the current business node of the task instance is completed, canceled, rejected, or abnormally terminated. When the user identifier does not belong to a task participant, or the binding status is not valid, or the task instance has been terminated, an access-prohibited status and a request context exception record are generated; no temporary permission status record is generated.

[0079] After the aforementioned verification passes, the request context generation module writes the request identifier, user identifier, identity identifier, task identifier, task type, current business node, task status version, target operation, target resource, business object scope, target rule version, and request time into the request context record. Once written, the request context record remains unchanged until the current authentication request is completed. When the task status management service sends a new business node status event during this authentication period, the new node status is written to the task instance, but does not overwrite the already generated request context record. New requests after this authentication is completed regenerate the request context record based on the updated task instance.

[0080] The rules engine service filters the candidate business rule set based on request context records. Specifically, it first excludes business rule relationship records of other rule versions based on the target rule version; then, it matches the identity identifier in the request context record with the user identity condition, matches the task type with the task type in the business rule relationship record, matches the current business node with the applicable business node, and matches the target operation with the target operation in the business rule relationship record. Business rule relationship records that match all of the aforementioned fields are added to the candidate business rule set; business rule relationship records that do not match any of the required fields are not included in the candidate business rule set.

[0081] The rule engine service parses the business object scope generation conditions in the candidate business rule set and compares the parsing results with the business object scope in the request context record. When the target resource or target business object is within the scope of the business object, the scope matching status is recorded; when the target resource or target business object is not within the scope of the business object, the business rule relationship record is excluded from the candidate business rule set. For business rule relationship records that match the identity, task type, applicable business node, and target operation, but have an empty business object scope, a scope missing record is generated and is not used as a business rule relationship record that allows temporary authorization.

[0082] When multiple business rule relationship records exist in the candidate business rule set, the rule engine service continues to filter based on rule priority and exclusivity. When a high-priority business rule relationship record with exclusivity is matched, matching of low-priority records stops; when no exclusivity exists, the permission results from multiple records are read separately. When multiple permission results simultaneously include both allowed and denied permission items, the permission decision module uses the denied permission item; when multiple allowed permission items correspond to different business object ranges, the intersection of the multiple business object ranges is taken; when multiple valid conditions generate different expiration times, the earlier expiration time is used. The aforementioned processing results form allowed permission items, denied permission items, business object ranges, valid times, and eviction conditions.

[0083] In one implementation, when the candidate business rule set is empty, the permission decision module invokes static role permission verification. Static role permission verification reads the role and permission identifier based on the user identifier and verifies the permission identifier against the target operation and target resource. Rule miss status and rule engine service exception status are recorded separately; when a rule miss occurs, the static role permission verification result can be used; when the rule engine service is abnormal, it is not treated as a rule miss. If a dynamic rejection result already exists in the request context record, the static role allow result does not overwrite the dynamic rejection result.

[0084] The permission decision module generates permission decision records based on the filtering and matching results. These records include a permission decision identifier, request identifier, task identifier, target rule version, rule identifier, permission item, permission result, business object scope, effective time, and permission decision status. The permission decision identifier is generated by the permission center based on the authentication request and remains unique within the permission center. When the permission result is denied, the permission decision status is written as denied, and the denied permission item or reason is recorded. When the permission result is allowed and the source is a business rule relationship record, the permission decision status is written as temporary authorization. When the permission result originates from static role permission verification, the permission decision status is written as static permission status.

[0085] When the permission decision status is temporary authorization, the permission decision module generates a temporary permission status record. This temporary permission status record includes a user identifier, task identifier, permission decision identifier, target rule version, permission item, business object scope, effective time, expiration time, permission status, and permission status version; in one implementation, it also includes an authorization token identifier. The permission status is initially written as valid, and the permission status version is initially written as version 1. When the same user repeatedly sends authentication requests for the same task, the same target operation, and the same business object scope, and an existing temporary permission status record is still valid, the existing permission decision identifier can be returned, or a new permission decision record can be generated and mapped to the existing temporary permission status record.

[0086] Taking cross-store transfer task T1001 as an example, user A requests to execute a confirmation outbound operation. The request context generation module obtains user A, task T1001, confirmation outbound interface, and request time from the authentication request; it obtains the pending outbound node, task status version 6, participating users, and transfer order D1001 from the task instance; and it obtains the target rule version V3 from the task rule binding record. The request context record is written into the aforementioned fields. The rule engine service filters the business rule relationship records corresponding to cross-store transfer, pending outbound, inventory administrator, and confirmation outbound in V3 to generate a candidate business rule set. The business object scope generation condition is limited to transfer order D1001 and its product details. The permission result is to allow confirmation outbound from store A and refuse to modify the inbound record of store B. The permission decision module generates permission decision identifier D2001, permission decision record, and temporary permission status record P3001. The permission status of P3001 is valid, and the permission status version is version 1.

[0087] In an inventory counting task, the task object record may include multiple counting areas, and the task participant user record includes the counting area corresponding to each user. The request context generation module extracts the assigned area based on the current user identifier, and the assigned area constitutes the business object scope. When multiple allowed business rule relationship records respectively limit the store scope and the counting area scope, the intersection of the two is taken to form the data record scope of the user in the current inventory counting task. After the inventory counting task enters the pending review node from the execution node, the new authentication request reads the updated business node. The business rule relationship records that originally allowed modification permissions no longer match, but the business rule relationship records corresponding to query permissions can still enter the candidate business rule set.

[0088] This step outputs a request context record, a permission decision record, a permission decision identifier, and a temporary permission status record. The permission decision identifier and temporary permission status record are entered into S3 for operation request verification; the task identifier, target rule version, permission status, and permission status version are entered into S4 for use when a business node status event triggers permission revocation. The request context record, permission decision record, and temporary permission status record all use the same task identifier and target rule version; the permission decision record and temporary permission status record use the same permission decision identifier. Request context exception records, rule miss statuses, scope missing records, and rule engine service exception statuses are written to the operation log for subsequent request queries and status tracing.

[0089] S3. Receive an operation request containing the permission decision identifier, read the temporary permission status record; verify the task identifier, target operation, business object scope and permission status, and generate an authentication result.

[0090] This step is jointly executed by the business application, the authorization verification module in the authorization center, and the target function interface. The business application receives the authorization decision identifier returned by S2; in one embodiment, the authorization center generates an authorization token based on the temporary authorization status record formed by S2 and returns the authorization token to the business application. When a user calls the target function or target interface, the business application writes the authorization decision identifier or an authorization token carrying the authorization decision identifier into the operation request; the authorization verification module reads the temporary authorization status record stored on the server based on the authorization decision identifier and generates an authentication result based on the temporary authorization status record.

[0091] The authorization token includes a permission decision identifier, a user identifier, a task identifier, an expiration time, and a verification value. When the permission center generates an authorization token, it writes the permission decision identifier, user identifier, task identifier, and expiration time from the temporary permission status record into the token field and generates a verification value according to preset verification rules. The authorization token does not directly replace the server-side temporary permission status record. After the business application submits the authorization token, the authorization verification module first parses the authorization token to obtain the permission decision identifier; if the verification value is inconsistent, the token field is missing, or the token expiration time is earlier than the request time, an access-prohibited state is generated, and the target function data is not read.

[0092] The operation request includes a user identifier, task identifier, target operation, target resource, business object scope, request time, permission decision identifier, and permission status version. The business object scope can be represented in the operation request as a document identifier, store identifier, product identifier, batch identifier, or data record identifier. When an operation request involves multiple data records, the business application writes multiple data record identifiers into the business object scope field. The permission status version is obtained by the business application based on the temporary permission status record previously returned by the permission center. If the business application does not save the permission status version, this field can be set to empty. The authorization verification module uses the permission status version stored on the server and returns the current permission status version in the authentication result.

[0093] After obtaining the permission decision identifier, the authorization verification module queries the temporary permission status records stored in the permission center. If no corresponding record is found, an access-prohibited status and a permission decision identifier mismatch record are generated. If a corresponding record is found, the module sequentially reads the user identifier, task identifier, target rule version, permission item, business object scope, effective time, expiration time, permission status, and permission status version. The authorization verification module does not re-call the rule engine service to generate new permission results; instead, it verifies the operation request against the temporary permission status record.

[0094] User identifier verification includes comparing the user identifier in the operation request with the user identifier in the temporary permission status record; task identifier verification includes comparing the task identifier in the operation request with the task identifier in the temporary permission status record; target operation verification includes matching the target operation in the operation request with the permission items in the temporary permission status record; business object scope verification includes checking whether each data object in the operation request is within the business object scope defined by the temporary permission status record. If any user identifier, task identifier, or target operation is inconsistent, the authorization verification module generates an access-prohibited status; if the operation request includes multiple data objects and one of them is not within the business object scope, the operation request generates an access-prohibited status, and no operation is performed on the data object within the scope. In another implementation, query requests can exclude data objects outside the scope and generate an access-allowed status for data objects within the scope. This implementation requires setting the query scope processing method in the corresponding business rule relationship record.

[0095] Time verification includes comparing the request time with the effective time and expiration time; if the request time is earlier than the effective time or later than the expiration time, an access-forbidden state is generated. Permission status verification includes reading the current permission status; if the permission status is valid, version verification continues; if the permission status is pending revocation, expired, or revocation failed, an access-forbidden state is generated. Version verification includes comparing the permission status version in the operation request with the permission status version stored on the server; if they match, the target function call proceeds; if they do not match, an access-forbidden state is generated, and the permission status version stored on the server is returned to the business application.

[0096] In one implementation, the business application generates a permission decision summary based on the permission items and business object scope in the permission decision record, and sets the availability status of pages, menus, or buttons according to the permission decision summary. The user-side availability status is not considered the final authentication result of the target function interface; even if the business application still displays the operation entry point, the target function interface still needs to read the server-side temporary permission status record through the authorization verification module. When a user directly calls the target interface without submitting a permission decision identifier, the authorization verification module generates an access-prohibited status.

[0097] If the authorization verification result is consistent, the request time is within the valid time, and the permission status is valid, the authorization verification module generates an access-allowed status and forwards the operation request to the target function or target interface. After the target function completes the corresponding operation, it returns the interface execution result. The authorization verification module writes the access-allowed status, permission decision identifier, task identifier, target operation, business object scope, interface execution result, and request time to the operation log. If the target function fails to execute, the permission status does not change, and the interface execution result is recorded as failure; the business application can resend the operation request under the same permission status version.

[0098] When the verification results are inconsistent or the permission status is not valid, the authorization verification module generates an access-forbidden status and writes the "Reject" field, the server-side permission status version, and the request time to the operation log. The "Reject" field can indicate inconsistent user identifiers, inconsistent task identifiers, mismatched target operations, mismatched business object scope, request time outside the valid time period, invalid permission status, or inconsistent permission status versions. After receiving the server-side permission status version, the business application updates the locally stored permission status version; when the returned permission status is invalid, the business application clears the operation entry status of the corresponding permission decision identifier.

[0099] In an implementation where a single user accesses a task instance through multiple terminals, each terminal may hold the same permission decision identifier or different authorization tokens, but the authorization verification module reads the same temporary permission status record based on the permission decision identifier. After S4 updates the temporary permission status record, subsequent operation requests sent by each terminal will read the updated permission status. Even if a terminal does not receive permission status update information, it will not affect the backend generating authentication results based on the server-side permission status.

[0100] Taking the aforementioned cross-store transfer task as an example, user A submits an operation request including permission decision identifier D2001, task identifier T1001, target operation confirmation outbound, business object scope D1001, and permission status version 1. The authorization verification module reads the temporary permission status record P3001 based on D2001, compares the user identifier, task identifier, target operation, transfer order scope, and permission status version. If the verification matches and P3001 is valid, an access-allowed status is generated and forwarded to the confirmation outbound interface. When user A modifies the business object scope to another transfer order D1002, the scope verification is inconsistent, and an access-prohibited status is generated. After the task is completed, S4 updates P3001 to invalid and updates the permission status version to 2. When user A continues to send requests with version 1, the authorization verification module generates an access-prohibited status and returns version 2.

[0101] This step outputs the authentication result, access allowed or denied status, interface execution result, operation log, and permission status version feedback result. The operation log is entered into the record relationship defined in claim 10, and its fields include request identifier, permission decision identifier, task identifier, target rule version, target operation, business object scope, authentication result, interface execution result, and request time. The temporary permission status record is still stored by the permission center and is used as the object of update in S4. After S4 completes the permission status update, S3 reads the updated permission status and permission status version from subsequent operation requests and generates the corresponding authentication result.

[0102] S4. Receive a business node status event containing an event identifier, a task identifier, a business node, and a node status version; when the event identifier is not recorded and the node status version is not lower than the recorded node status version, obtain the recycling conditions according to the target rule version, generate a permission recycling event, and update the temporary permission status record to the expired state when the permission status version is consistent.

[0103] This step is executed by the Task Status Management Service, the Node Status Receiving Module in the Permission Center, and the Authorization Termination Module. The Task Status Management Service generates a business node status event when the business node or task status of a task instance changes, and sends it to the Node Status Receiving Module. The Node Status Receiving Module verifies the event identifier, event source identifier, and node status version. The Authorization Termination Module reads the task rule binding record formed by S1 based on the task identifier, reads the temporary permission status record formed by S2, obtains the revoke conditions according to the target rule version in the task rule binding record, generates a permission revoke event, and updates the temporary permission status record.

[0104] The business node status event includes an event identifier, a task identifier, an updated business node, a node status version, an event time, and an event source identifier. The event identifier is generated by the task status management service for a single node status change; the task identifier corresponds to the task instance whose status needs updating; the updated business node indicates the current processing stage of the task; the node status version increments with the task node; the event time represents the recorded time of the business node update; and the event source identifier indicates the task status management service or business application that sent the event. The event identifier and node status version are used for duplicate event verification and out-of-order event verification, respectively.

[0105] After receiving a business node status event, the node status receiving module first queries the stored business node status events and permission revocation results based on the event identifier. If the event identifier already exists, the permission revocation event is not generated again, and the permission revocation result corresponding to the event identifier is returned directly. If the event identifier is not recorded, the module continues to read the recorded node status version based on the task identifier. If the received node status version is lower than the recorded node status version, an out-of-order event record is generated, but the business nodes in the task instance are not updated, and no new permission revocation event is generated. If the received node status version is equal to the recorded node status version but the event identifier is different and the business node is the same, it can be recorded as a duplicate status event, and the recorded node processing result is returned. If the received node status version is higher than the recorded node status version, the business nodes and node status versions in the task instance are updated.

[0106] In one implementation, the node status receiving module also verifies whether the event source identifier is consistent with the task status management service to which the task instance belongs. If the event source identifier is inconsistent, an event source exception record is generated, and the permission revocation process is not initiated. If the event time is earlier than the recorded node event time but the node status version is higher, the node status version is used as the processing order, and an event time exception is recorded; if both the event time and the node status version are missing, a business node status event field missing record is generated.

[0107] After event verification, the authorization termination module reads the task rule binding record based on the task identifier and obtains the target rule version from the task rule binding record. When the binding status is terminated, the original target rule version is still read; when the binding status is suspended authentication and a rule migration record exists, the rule version referenced for permission revoke is determined based on the rule migration record. The authorization termination module reads the revoke conditions from the business rule relationship record corresponding to the target rule version and matches the updated business node, task status, or user participation status with the revoke conditions.

[0108] The retrieval conditions can be configured separately for each permission item. For example, when an inventory count task moves from the "in execution" node to the "pending review" node, the permission item for modifying inventory records is revoked, while the permission item for querying inventory records is retained; when the inventory count task moves to the "completed" node, the query and modification permissions are revoked. When an inter-store transfer task moves to the "completed," "cancelled," or "rejected" nodes, the permissions for confirming outbound, confirming inbound, and modifying the transfer quantity corresponding to that transfer task are revoked. The authorization termination module filters records to be revoked from the valid temporary permission status records corresponding to the task identifier based on the permission items and business object scope in the retrieval conditions.

[0109] The authorization termination module generates a permission revoke event for the temporary permission status record to be revoked. The permission revoke event includes a permission revoke event identifier, a source event identifier, a task identifier, a temporary permission status record identifier, the permission status before revoke, the target permission status, the expected permission status version, and the revoke result. The source event identifier is written to the event identifier of the business node status event; the permission status before revoke is read from the temporary permission status record; the target permission status is written as expired according to the revoke conditions; the expected permission status version is written to the current permission status version read when the permission revoke event is generated; and the revoke result is initially written to the pending status.

[0110] After generating a permission revoke event, the authorization termination module reads the current permission status and permission status version from the temporary permission status record again. If the current permission status is expired, it is not updated again, and the permission revoke result is written to the "no revoke required" status. If the current permission status is valid or pending revoke, and the current permission status version is consistent with the expected permission status version, the permission status is updated to expired, and the permission status version is updated to the next version. If the current permission status version is inconsistent with the expected permission status version, the old version is not used for the update. Instead, the temporary permission status record is read again, and a new processing result is generated based on the reread permission status.

[0111] In one implementation, when the temporary permission status record includes an authorization token identifier, the authorization termination module writes the authorization token identifier into the credential expiration record after the permission status is updated to expired. The credential expiration record includes the authorization token identifier, permission decision identifier, task identifier, expiration reason, expiration time, and permission status version. After parsing the authorization token in S3, the authorization verification module can first query the credential expiration record; if the authorization token identifier already exists, it directly generates an access-prohibited status.

[0112] After the permission status update is successful, the authorization termination module updates the revoke result in the permission revoke event to a revoke status and generates a permission revoke result. The permission revoke result includes an event identifier, a permission revoke event identifier, a task identifier, the permission status before revoke, the updated permission status, the permission status version, and the processing time. The node status receiving module returns the permission revoke result to the task status management service; in one embodiment, user-side permission status update information is also sent to the business application, and the user-side permission status update information includes a permission decision identifier, the updated permission status, and the permission status version.

[0113] When updating the temporary permission status record fails, the authorization termination module generates a recycling retry record. The recycling retry record includes a permission recycling event identifier, a temporary permission status record identifier, the current permission status version, the number of retries, and the last processing time. If the number of retries does not exceed the preset maximum number of retries, the authorization termination module rereads the permission status version and performs a status update based on the reread result; if the number of retries exceeds the maximum number of retries, the permission status of the temporary permission status record is updated to a recycling failure status. When S3 reads the recycling failure status, an access-prohibited status is generated, and operations are not allowed due to recycling failure.

[0114] In one implementation, the permission center retrieves temporary permission status records that are valid and whose current time has reached their expiration time according to a preset query cycle. For records where there is no permission revoke event generated by a business node status event, the authorization termination module generates an expiration revoke record and a permission revoke event. The expiration revoke record includes a temporary permission status record identifier, a task identifier, a permission decision identifier, an expiration time, a query time, and a revoke status; the source event identifier of the expiration revoke event can be generated by combining the task identifier, the permission decision identifier, and the expiration time, and the temporary permission status record is updated according to the aforementioned permission status version verification process. When a business node status event arrives after the expiration revoke is completed, a permission revoke result that does not need to be revoked is generated based on the expired permission status.

[0115] Taking the cross-store inventory transfer task T1001 as an example, the task status management service generates event identifier E4001 and task identifier T1001 after the task is completed. The updated business node is "completed," and the node status version is 7. The node status receiving module queries E4001 and finds no record, and compares version 7 with the recorded version 6. The authorization termination module obtains the target rule version V3 based on the task rule binding record, reads the recycling conditions corresponding to the completed node from the business rule relationship record of V3, filters the temporary permission status record P3001, and generates a permission recycling event R5001. The expected permission status version in R5001 is 1. When P3001 is read again and is still version 1, its permission status is updated to "expired," the permission status version is updated to 2, and a permission recycling result with a recycled status is generated. When E4001 is sent again, the node status receiving module returns the existing permission recycling result and does not update P3001 again.

[0116] In the implementation of out-of-order events, the task status management service first sends a completed event (node ​​status version 7), and then, due to network delay, sends an in-process event (node ​​status version 6). The node status receiving module reads the recorded version 7, writes the version 6 event into the out-of-order event record, does not restore the task instance to an in-process node, and does not regenerate allowed permissions. If a cancellation event (node ​​status version 8) arrives after the permissions have expired, the authorization termination module generates a permission revoke result that does not need to be revoked, and writes version 8 into the node status version of the task instance.

[0117] In the implementation where the node event is not successfully sent, after the expiration time of the temporary permission status record P3001 arrives, the permission center retrieves P3001 through an expiration query. If no permission revocation event generated by the business node status event is found, an expiration revocation record and a permission revocation event are generated, and an update is performed based on the current permission status version of P3001. When the subsequent task status management service sends a completed event, the authorization termination module reads that P3001 is already in an expired state and returns a permission revocation result indicating that no revocation is required.

[0118] After permission revokes, the permission center establishes a mapping relationship between task rule binding records, request context records, permission decision records, temporary permission status records, operation logs, permission revoke events, and permission revoke results, based on the task identifier, target rule version, and permission decision identifier. The permission decision identifier in the operation log points to the permission decision record and the temporary permission status record; the task identifier and temporary permission status record identifier in the permission revoke event point to the updated permission status; and the permission status version in the permission revoke result records the updated version. Subsequent queries based on the task identifier can retrieve the rule version used by the task, permission generation records, API call records, and permission status update records according to the aforementioned mapping relationship.

[0119] This step ultimately outputs the permission revoke event, the updated temporary permission status record, the permission status version, the credential expiration record, the permission revoke result, the duplicate event record, the out-of-order event record, the expiration revoke record, and the revoke retry record. The updated temporary permission status record continues to serve as the verification input for subsequent S3 operation requests; when the permission status is expired or revoke fails, S3 generates an access-prohibited status. The permission revoke result is returned to the task status management service, and the user-side permission status update information is returned to the business application; the task rule binding record, request context record, permission decision record, temporary permission status record, operation log, permission revoke event, and permission revoke result maintain a correspondence according to the task identifier, target rule version, and permission decision identifier.

[0120] Example 2: Figure 2 This diagram illustrates a structural block diagram of a dynamic access control method for intelligent programs based on preset business rules, according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0121] The rule management module 01 receives business rule configuration data, establishes a mapping relationship between user identity conditions, task type, business node, target operation, business object scope, and permission items, and generates a business rule relationship record containing eviction conditions and rule versions. Specifically, the business rule configuration data is input from the business rule configuration terminal and includes user identity conditions, task type, applicable business node, target operation, target resource type, business object scope generation conditions, permission items, permission results, validity conditions, eviction conditions, rule priority, exclusive status, and effective status. After receiving the business rule configuration data, the rule management module verifies the field status of rule identifier, rule version, applicable business node, target operation, and permission items respectively. When the fields are complete and the effective time interval is valid, it establishes a mapping relationship between the user identity conditions, task type, applicable business node, and target operation and the permission items, and limits the business object scope corresponding to the permission items according to the target resource type and business object scope generation conditions. The rule management module writes the validity conditions and eviction conditions into the corresponding business rule relationship records, and writes the rule priority, exclusivity status, and effectiveness status into the rule processing fields of the business rule relationship records. It also stores multiple business rule relationship records according to rule version and effectiveness time interval. When receiving business rule configuration data with changed content, the rule management module generates a new rule version and retains the original rule version. When receiving business rule configuration data with duplicate rule identifiers, conflicting time intervals, or missing fields, the rule management module records the corresponding rule status and does not send business rule configuration data in an abnormal state to the task rule binding module. The rule management module provides the task rule binding module with business rule relationship records in an effective state. The task rule binding module then uses the task type, rule version, and effectiveness time interval from these records to determine the target rule version. The rule management module also retains the eviction conditions for the authorization termination module to read according to the target rule version.

[0122] The task rule binding module 02, connected to the rule management module, receives task instances and, upon the initial authentication of the task instance, determines the target rule version from the business rule relationship record and generates a task rule binding record. Specifically, the task instance is input by the task status management service and includes a task identifier, task type, task creation time, business node, task status version, participating users, and business object scope. After receiving the task instance, the task rule binding module queries whether a valid task rule binding record exists based on the task identifier. If no binding record is found and the task instance is being authenticated for the first time, it filters rule versions whose effective time intervals cover the task creation time from the business rule relationship record provided by the rule management module, based on the task type and creation time. If a matching rule version exists, it is recorded as the target rule version. If multiple rule versions with overlapping effective time intervals exist, the target rule version is filtered according to the effective start time, and the version status is recorded. If no matching rule version is found, a rule version mismatch status is recorded, and the sending of the target rule version required for authentication to the permission decision module is stopped. The task rule binding module writes the task identifier, task type, target rule version, binding time, and binding status into the task rule binding record. When the task instance is in transit, subsequent authentication requests and business node status events continue to reference the target rule version and do not directly change the task rule binding record due to the generation of a new rule version. When the effective status of the target rule version is updated to forced deactivation, the task rule binding module generates a rule migration record based on the original target rule version and the replacement rule version, and updates the target rule version and binding status in the task rule binding record based on the rule migration record. The task rule binding module provides the task identifier, task type, target rule version, and binding status to the permission decision module; the task rule binding module also provides the task identifier and target rule version to the authorization termination module, allowing the authorization termination module to read the reclamation conditions corresponding to the target rule version.

[0123] The permission decision module 03, connected to the task rule binding module, receives authentication requests based on the task rule binding record. It writes the user identifier, task identifier, business node, target operation, business object scope, and target rule version into the request context record, matches the business rule relationship record, and generates a permission decision record containing a permission decision identifier and a temporary permission status record containing a permission status version. Specifically, the authentication request is input by the business application and includes a request identifier, user identifier, identity identifier, task identifier, target operation, target resource, and request time. The permission decision module reads the task type, business node, task status version, participating users, and business object scope from the task instance based on the task identifier, and reads the target rule version and binding status based on the task rule binding record. The permission decision module verifies whether the user identifier belongs to a participating user and verifies the binding status and business node. After successful verification, it writes the user identifier, identity identifier, task identifier, task type, business node, task status version, target operation, target resource, business object scope, target rule version, and request time into the request context record. The permission decision module filters a set of candidate business rules from the business rule relationship records based on the target rule version, user identity conditions, task type, applicable business node, and target operation. It then compares the target resource with the business object scope according to the business object scope generation conditions, excluding business rule relationship records with mismatched scopes. When the candidate business rule set includes multiple business rule relationship records, the permission decision module filters based on rule priority and exclusivity. When the permission result includes both allowed and denied permission items, the denied permission item is used. When multiple allowed permission items correspond to different business object scopes, the intersection of the multiple business object scopes is taken. When multiple valid conditions correspond to different expiration times, the earlier expiration time is selected. The permission decision module generates a permission decision record based on the matching result and writes the permission decision identifier, task identifier, target rule version, rule identifier, permission item, permission result, business object scope, effective time, and permission decision status. When the permission result is temporary authorization allowed, a temporary permission status record is generated, and the user identifier, task identifier, permission decision identifier, target rule version, permission item, business object scope, effective time, expiration time, permission status, and permission status version are written into the temporary permission status record. When no matching business rule relationship record is found, the permission decision module obtains the static role permission verification result; if a dynamic denial result exists, the static role allow result is not used to overwrite the dynamic denial result. The permission decision module provides the authorization verification module with a permission decision identifier and a temporary permission status record; the permission decision module retains the task identifier, target rule version, and permission status version for the authorization termination module to filter and update the corresponding temporary permission status record.

[0124] The authorization verification module 04, connected to the permission decision module, receives operation requests containing the permission decision identifier, reads the temporary permission status record based on the permission decision identifier, verifies the task identifier, target operation, business object scope, and permission status, and generates an authentication result. Specifically, the operation request is input by the business application and includes a user identifier, task identifier, target operation, target resource, business object scope, request time, permission decision identifier, and permission status version. The authorization verification module queries the temporary permission status record generated and stored by the permission decision module based on the permission decision identifier; if the temporary permission status record is not found, an access-prohibited status is generated and a permission decision identifier mismatch status is recorded. After finding the temporary permission status record, the authorization verification module reads the user identifier, task identifier, permission item, business object scope, effective time, expiration time, permission status, and permission status version therein; it verifies the user identifier and task identifier in the operation request against the user identifier and task identifier in the temporary permission status record, matches the target operation with the permission item, and checks whether the target resource in the operation request is within the business object scope. The authorization verification module compares the request time with the effective time and expiration time, and compares the permission status version in the operation request with the permission status version stored on the server. If the user identifier, task identifier, target operation, business object scope, and permission status version are consistent, and the permission status is valid, an access-allowed status is generated. If any field is inconsistent, or the permission status is pending revocation, expired, or revocation failed, an access-prohibited status is generated. The authorization verification module writes the authentication result, permission decision identifier, task identifier, target operation, business object scope, request time, and the permission status version stored on the server into the operation log. When an access-allowed status is generated, the operation request is sent to the function or interface corresponding to the target resource, and the interface execution result is recorded. When an access-prohibited status is generated, the access-prohibited status and the permission status version stored on the server are returned to the business application. After the authorization termination module updates the temporary permission status record, the authorization verification module reads the updated permission status and permission status version in subsequent operation requests and generates an authentication result according to the updated record.

[0125] The node status receiving module 05 is used to receive business node status events containing an event identifier, a task identifier, a business node, and a node status version. When the event identifier is not recorded and the node status version is not lower than a recorded node status version, the module sends the business node status event to the authorization termination module. Specifically, the business node status event is input by the task status management service, and the business node status event also includes the event time and event source identifier. After receiving the business node status event, the node status receiving module queries existing business node status events and permission revocation results based on the event identifier. If the event identifier is already recorded, the module does not resend the business node status event and returns the permission revocation result corresponding to the event identifier. When the event identifier is not recorded, the node status receiving module reads the recorded node status version in the task instance based on the task identifier and compares the received node status version with the recorded node status version. If the received node status version is lower than the recorded node status version, an out-of-order event record is generated, the business node is not updated, and the business node status event is not sent to the authorization termination module. When the received node status version is equal to the recorded node status version and the business node is the same, a duplicate status event is recorded. When the received node status version is higher than the recorded node status version, the business node and node status version in the task instance are updated. The node status receiving module also verifies the event source identifier against the task status management service corresponding to the task instance. If the event source identifier is inconsistent, the event source status is recorded, and the permission revocation process is not initiated. When the event identifier is not recorded, the node status version is not lower than the recorded node status version, and the event source identifier verification passes, the node status receiving module sends the event identifier, task identifier, business node, node status version, event time, and event source identifier to the authorization termination module. The node status receiving module receives the permission revocation result returned by the authorization termination module and establishes a correspondence between the permission revocation result and the event identifier for use when a duplicate business node status event arrives.

[0126] The authorization termination module 06 is connected to the node status receiving module, the task rule binding module, and the permission decision module, respectively. It is used to obtain the recycling conditions based on the target rule version in the task rule binding record, generate a permission recycling event based on the business node status event and the recycling conditions, and update the temporary permission status record to an expired state when the permission status version corresponding to the permission recycling event matches the permission status version in the temporary permission status record. Specifically, the authorization termination module receives the business node status event sent by the node status receiving module, calls the task rule binding record generated by the task rule binding module according to the task identifier therein, and reads the target rule version from the task rule binding record; then, according to the target rule version, calls the business rule relationship record stored by the rule management module, and reads the recycling conditions corresponding to the business node, task status, and permission item. The authorization termination module matches the business node in the business node status event with the recycling conditions; when a match is found, it filters records with valid or pending recycling permissions from the temporary permission status record stored by the permission decision module according to the task identifier, and determines the temporary permission status record to be updated according to the permission item and business object scope in the recycling conditions. The authorization termination module generates a permission revoke event for the temporary permission status record to be updated, and writes the permission revoke event identifier, source event identifier, task identifier, temporary permission status record identifier, permission status before revoke, target permission status, expected permission status version, and revoke result into the permission revoke event. After generating the permission revoke event, the authorization termination module rereads the permission status and permission status version in the temporary permission status record; if the permission status version in the temporary permission status record is consistent with the expected permission status version in the permission revoke event, and the permission status is valid or pending revoke, the permission status is updated to invalid, and the permission status version is updated. If the temporary permission status record is already in an invalid state, the permission revoke result that does not need to be revoked is recorded; if the two permission status versions are inconsistent, the temporary permission status record is reread, and the original permission revoke event is not used to overwrite the updated permission status. After the update is completed, the authorization termination module generates a permission revoke result and writes the event identifier, permission revoke event identifier, task identifier, permission status before revoke, updated permission status, permission status version, and processing time into the permission revoke result. The permission revoke result is sent to the node status receiving module, and the updated temporary permission status record is provided to the authorization verification module as the verification object for subsequent operation requests.

Claims

1. A method for dynamic access control of intelligent programs based on preset business rules, characterized in that, include: S1. Receive business rule configuration data and task instances, establish a mapping relationship between user identity conditions, task type, business node, target operation, business object scope and permission items, and generate a business rule relationship record containing recycling conditions and rule version; The target rule version is determined during the initial authentication of the task instance, and a task rule binding record is generated. S2. Receive authentication requests based on the task rule binding record, and write user identifier, task identifier, business node, target operation, business object scope, and target rule version into the request context record; match business rule relationship records to generate a permission decision record containing permission decision identifier and a temporary permission status record containing permission status version; S3. Receive an operation request containing the permission decision identifier, read the temporary permission status record; verify the task identifier, target operation, business object scope and permission status, and generate an authentication result; S4. Receive a business node status event containing an event identifier, a task identifier, a business node, and a node status version; when the event identifier is not recorded and the node status version is not lower than the recorded node status version, obtain the recycling conditions according to the target rule version, generate a permission recycling event, and update the temporary permission status record to the expired state when the permission status version is consistent.

2. The method according to claim 1, characterized in that, The business rule relationship record includes rule identifier, rule version, user identity conditions, task type, applicable business node, target operation, target resource type, business object scope generation conditions, permission items, permission results, validity conditions, revoke conditions, rule priority, exclusive status, and effective status. The business rule relationship record establishes a mapping relationship with permission items based on user identity conditions, task type, applicable business node, and target operation, and generates conditions to limit the business object scope of the permission items according to the target resource type and business object scope.

3. The method according to claim 1, characterized in that, The determination of the target rule version includes: Based on the task type and task creation time of the task instance, filter the rule version from the business rule relationship record that covers the task creation time within the effective time interval; Write the task identifier, task type, target rule version, binding time, and binding status into the task rule binding record; When the task instance is an in-transit task, subsequent authentication requests and business node status events continue to reference the target rule version; When the effective status of the target rule version is updated to forced deactivation, a rule migration record is generated, and the target rule version and binding status are updated according to the rule migration record.

4. The method according to claim 1, characterized in that, The generation of the request context record includes: Extract the user identifier, identity identifier, task identifier, target operation, target resource, and request time from the authentication request; Based on the task identifier, obtain the task type, business node, task status version, participating users, and business object scope from the task instance; Obtain the target rule version based on the task rule binding record; Verify whether the user identifier belongs to the user participating in the task, and write the verified user identifier, identity identifier, task identifier, task type, business node, task status version, target operation, target resource, business object scope, target rule version and request time into the request context record.

5. The method according to claim 1, characterized in that, The permission decision record includes permission decision identifier, task identifier, target rule version, rule identifier, permission item, permission result, business object scope, effective time, and permission decision status; The temporary permission status record includes user identifier, task identifier, permission decision identifier, target rule version, permission item, business object scope, effective time, expiration time, permission status, and permission status version; Write the same task identifier, target rule version, and permission decision identifier into the permission decision record and the temporary permission status record.

6. The method according to claim 1, characterized in that, The matching business rule relationship record includes: The candidate business rule set is filtered based on the target rule version, user identity conditions, task type, applicable business node, and target operation; Filter business rule relationship records from the candidate business rule set according to rule priority and exclusivity status; When the permission result includes both allowed and denied permissions, the denied permission item shall be used. Take the intersection of the business object ranges corresponding to multiple permitted permission items, and select the earlier expiration time from multiple valid times; When no business rule relationship records are found, the static role permission verification result is obtained, and the dynamic denial result takes precedence over the static role allow result.

7. The method according to claim 5, characterized in that, An authorization token is generated based on the temporary permission status record. The authorization token includes a permission decision identifier, a user identifier, a task identifier, an expiration time, and a verification value. The operation request includes user identifier, task identifier, target operation, target resource, business object scope, request time, permission decision identifier, and permission status version; Read the temporary permission status record stored on the server according to the permission decision identifier; An access permission status is generated when the verification results of user identifier, task identifier, target operation, business object scope, and permission status version are consistent and the permission status is valid. If the verification results are inconsistent or the permission status is not valid, an access-prohibited status is generated, and the permission status version stored on the server is returned.

8. The method according to claim 1, characterized in that, The business node status event also includes the event time and event source identifier; The permission revokement event includes a permission revokement event identifier, a source event identifier, a task identifier, a temporary permission status record identifier, the permission status before revokement, the target permission status, the expected permission status version, and the revokement result; If the event identifier has been recorded, return the permission revoke result corresponding to the event identifier; When the node state version is lower than the recorded node state version, an out-of-order event record is generated and no new permission revocation event is generated; If the current permission status version is inconsistent with the expected permission status version, the temporary permission status record is reread.

9. The method according to claim 1, characterized in that, Also includes: A temporary permission status record that is valid but whose current time has expired; If the temporary permission status record does not contain a permission revocation event generated by a business node status event, an expiration revocation record and a permission revocation event are generated. If updating the temporary permission status record fails, a retry record is generated and the number of retries is recorded. If the number of retries does not exceed the maximum number of retries, the permission status version is reread and the temporary permission status record is updated. When the number of retries exceeds the maximum number of retries, the permission status is updated to a recycling failure status, and an access-prohibited status is generated for subsequent operation requests.

10. The method according to claim 1, characterized in that, Also includes: Generate an operation log, which includes a request identifier, a permission decision identifier, a task identifier, a target rule version, a target operation, a business object scope, an authentication result, an interface execution result, and a request time. Generate permission revoke results, which include event identifier, permission revoke event identifier, task identifier, permission status before revoke, updated permission status, permission status version, and processing time; Based on the task identifier, target rule version, and permission decision identifier, establish a mapping relationship between the task rule binding record, request context record, permission decision record, temporary permission status record, operation log, permission revocation event, and permission revocation result.

Images