A method and device for managing a delegated identity for a multi-simulation service system

Abstract

Embodiments of the present application disclose a kind of multi-simulation service system-oriented delegation identity management method and device.The method comprises: obtaining the business application identification of target simulation subsystem by parsing access request;Determine the front-end management context based on business application identification;Lock the current operating domain and hide global switching entry using front-end management context;Filter target user set and target permission set from unified identity database;Define target role scope using target permission set, and update the mapping relationship of target user set based on target role scope to obtain role mapping dataset;Delete execution result is obtained by processing target user set using context-aware deletion strategy;The role mapping dataset and the deletion execution result are encapsulated and returned, forming a management interface, so that the unified identity platform capability can be reused, and the delegation identity management of accurate business isolation can be realized, the repeated construction cost is reduced, and the risk of exceeding authority and misdeletion is reduced.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a method and apparatus for delegated identity management for multi-simulation business systems. Background Technology

[0002] With the development of technology, large platforms in fields such as industrial digitalization often need to simultaneously support multiple business subsystems, including simulation training, simulation engines, and model services. These systems typically share a unified identity platform to reduce account management costs. Under this architecture, how to securely and efficiently delegate identity management capabilities to administrators of each business system, enabling them to maintain only users, roles, and permissions within their own system, has become a pressing technical problem to be solved.

[0003] To address the aforementioned delegation management requirements, existing technologies primarily employ two approaches. One is to build a separate identity management sub-backend for each business system, with each system having its own independent interface and API logic. The other is to isolate only the front-end interface layer, differentiating business systems through different entry points, while the back-end still uses a globally unified interface for querying and changing users, roles, and permissions.

[0004] However, the above approach has significant drawbacks. Building separate sub-backends leads to a large amount of code duplication, high maintenance costs, and difficulties in evolution. When only frontend isolation is implemented, due to the lack of business context constraints on the backend, business administrators may still exceed their authority to operate on data in other systems, such as accidentally deleting global user role mappings in other systems or assigning roles across systems, making it easy for deletion operations to inadvertently damage shared identities. Summary of the Invention

[0005] This invention provides a method and apparatus for delegated identity management for multi-simulation business systems. It can reuse the capabilities of a unified identity platform and achieve precise business isolation in delegated identity management, thereby reducing the cost of redundant construction, improving operational focus, and reducing the risk of unauthorized access and accidental deletion.

[0006] In a first aspect, embodiments of the present invention provide a method for delegated identity management in a multi-simulation business system, comprising: Obtain the access request initiated by the business administrator through the access path; parse the access request to obtain the business application identifier corresponding to the target simulation subsystem; determine the front-end management context corresponding to the target simulation subsystem based on the business application identifier; use the front-end management context to lock the current operation domain and hide the global switching entry; Based on preset filtering rules and user affiliation attributes, the unified identity database is filtered to obtain the target user set and target permission set belonging to the business application identifier; In response to a role assignment instruction initiated within the current operation domain, the target permission set is used to define the scope of target roles that are allowed to operate, and the mapping relationship of target objects in the target user set is updated based on the scope of target roles to obtain an updated role mapping dataset; In response to a deletion command initiated within the current operation domain, the target user set is processed using a context-aware deletion strategy to obtain a deletion execution result; Using the business application identifier as the boundary, the role mapping dataset and the deletion execution result are encapsulated and returned to the front-end management context to form the management interface of the target simulation subsystem.

[0007] Optionally, the method further includes: querying user records and permission records in the unified identity database, extracting the direct application field from the user records as the user affiliation attribute; based on the business application identifier and preset filtering rules, filtering permission nodes in the permission table whose affiliation field is the business application identifier, and constructing a target permission set; filtering private users in the user table whose direct application field is the business application identifier, and obtaining global users with role relationships under the business application identifier through the association table mapping between users and roles, and constructing a target user set.

[0008] Optionally, the method further includes: in response to a role assignment instruction initiated within the current operation domain, extracting role identifiers associated with all permission nodes from the target permission set, and using the set of extracted role identifiers as the target role range for permitted operations; deleting existing role mapping relationships of target objects in the target user set within the target role range; and rebinding the role identifiers submitted in the role assignment instruction and belonging to the target role range to the target object, thereby generating an updated role mapping dataset.

[0009] Optionally, the method further includes: responding to a deletion command initiated within the current operation domain, using the business application identifier to locate the authorization relationship to be removed of the target object under the target simulation subsystem, and obtaining a mapping dataset to be deleted; performing user affiliation identification on the target object according to the user affiliation attribute, and determining the user affiliation determination result; if the user affiliation determination result is a global user, then removing the role mapping in the mapping dataset to be deleted and retaining the user entity, and obtaining a first deletion execution result; if the user affiliation determination result is a private user, then removing the role mapping in the mapping dataset to be deleted and deleting the user entity, and obtaining a second deletion execution result.

[0010] Optionally, the method further includes: responding to a permission tree retrieval request initiated within the current operation domain, filtering a set of permission nodes belonging to the target simulation subsystem from the permission table based on the business application identifier; assembling the permission node set into a multi-level permission tree according to the parent-child hierarchical relationship between the nodes in the permission node set; and returning the assembled permission tree to the front-end management context to assist in the generation of the role allocation instruction.

[0011] Optionally, the method further includes: defining a unique business application identifier for each simulation subsystem in the multi-simulation business system, and generating an access path carrying the business application identifier for the business console of each simulation subsystem.

[0012] Secondly, embodiments of the present invention also provide a delegated identity management device for multi-simulation business systems, the device comprising: The operation domain locking module is used to obtain access requests initiated by business administrators through access paths; parse the access requests to obtain the business application identifier corresponding to the target simulation subsystem; determine the front-end management context corresponding to the target simulation subsystem based on the business application identifier; and lock the current operation domain and hide the global switching entry using the front-end management context. The data filtering module is used to filter the unified identity database based on preset filtering rules and user affiliation attributes to obtain the target user set and target permission set belonging to the business application identifier. The role mapping dataset update module is used to respond to the role assignment instruction initiated in the current operation domain, define the scope of target roles that are allowed to operate using the target permission set, and update the mapping relationship of target objects in the target user set based on the scope of target roles to obtain the updated role mapping dataset; The deletion execution result determination module is used to respond to a deletion command initiated in the current operation domain, process the target user set using a context-aware deletion strategy, and obtain the deletion execution result; The management interface forming module is used to encapsulate the role mapping dataset and the deletion execution result with the business application identifier as the boundary, and return them to the front-end management context to form the management interface of the target simulation subsystem.

[0013] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the delegated identity management method for multi-emulation business systems provided in any embodiment of the present invention.

[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the delegated identity management method for multi-simulation business systems provided in any embodiment of the present invention.

[0015] Fifthly, embodiments of the present invention provide a computer program product, including a computer program that, when executed by a processor, implements the delegated identity management method for multi-simulation business systems provided in any embodiment of the present invention.

[0016] The technical solution of this invention involves: acquiring access requests initiated by a business administrator through an access path; parsing the access request to obtain the business application identifier corresponding to the target simulation subsystem; determining the front-end management context corresponding to the target simulation subsystem based on the business application identifier; locking the current operation domain and hiding the global switching entry using the front-end management context; achieving context locking from the front-end entry to the operation interface, fundamentally defining the administrator's work domain. A unified identity database is filtered based on preset filtering rules and user affiliation attributes to obtain a set of target users and a set of target permissions belonging to the business application identifier; application boundaries are enforced at the back-end data query layer, achieving effective data isolation and supporting the coexistence of global and private users. In response to a role allocation instruction initiated within the current operation domain, the target permission set is used to define the scope of allowed operations for target roles, and the mapping relationship of target objects in the target user set is updated based on the target role scope to obtain an updated role mapping dataset; ensuring the security boundary of role allocation operations, preventing unauthorized allocation across applications, and avoiding unintended impact on the authorization relationships of other applications. In response to a deletion command initiated within the current operation domain, a context-aware deletion strategy is used to process the target user set to obtain the deletion execution result. This provides a semantically clear and context-constrained deletion mechanism, resolving the issue of accidental deletion of shared identities. Using the business application identifier as the boundary, the role mapping dataset and the deletion execution result are encapsulated and returned to the front-end management context, forming the management interface of the target simulation subsystem. This ensures the ultimate consistency between the front-end display and the back-end data status, forming a complete closed loop. This solves problems such as high costs of redundant construction, unauthorized operations, incomplete data isolation, and accidental deletion when multiple business systems share an identity platform, achieving secure, efficient, and reusable delegated identity management.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a delegated identity management method for a multi-simulation business system provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a delegated identity management method for a multi-simulation business system provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the structure of a delegated identity management device for a multi-simulation business system provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the delegated identity management method for multi-simulation business systems according to embodiments of the present invention. Detailed Implementation

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

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0022] Example 1 Figure 1 This invention provides a flowchart of a delegated identity management method for multi-emulation business systems, as described in Embodiment 1. This embodiment is applicable to situations where multiple business systems share a unified identity platform, requiring the secure delegation of identity management capabilities to administrators of each business system, enabling them to manage users, roles, and permissions only within their own business scope. This method can be executed by a delegated identity management device for multi-emulation business systems. This device can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes: S110. Obtain the access request initiated by the business administrator through the access path; parse the access request to obtain the business application identifier corresponding to the target simulation subsystem; determine the front-end management context corresponding to the target simulation subsystem based on the business application identifier; use the front-end management context to lock the current operation domain and hide the global switching entry.

[0023] In this embodiment, a business administrator can refer to a user assigned to manage a specific business system, such as the administrator of the command and control support system in a military simulation platform, rather than the global administrator of the unified identity platform. An access path can refer to the Uniform Resource Locator (URL) through which the business administrator accesses the management backend of a specific business system. For example, the access path might be in the form of: https: / / platform.com / console / {appCode} / user, where {appCode} is a variable part. An access request can refer to an HTTP request sent to the server by the business administrator after entering the access path in the browser address bar or clicking a relevant link. The target simulation subsystem can refer to the specific business system that the business administrator currently wishes to operate, such as a simulation training system, a simulation engine system, or a model service system.

[0024] In this embodiment, the business application identifier (appCode) can refer to a context code used to uniquely identify a simulation business system, training subsystem, or model service subdomain. For example, drill-train represents the inference training system, and model-service represents the model service system. The front-end management context can refer to the runtime environment of front-end page components (such as user management and role management pages). This environment knows which business system it is currently serving. In this context, all component operations will revolve around a fixed business application identifier. The current operation domain can refer to the scope of data and functions that the business administrator is authorized to operate within in this management session, i.e., it is locked within the target simulation subsystem. The global switching entry can refer to a UI control existing in the unified identity platform's main console that allows administrators to switch between different business system management views, such as an application dropdown selection box.

[0025] Specifically, the system receives an access request initiated by the business administrator. By parsing the URL path parameters of the request, it extracts the business application identifier representing the target simulation subsystem, such as appCode=drill-train. The business application identifier is transmitted between the front-end and back-end via URL path parameters, HTTP request headers, or session context, and context consistency is maintained at the routing layer, component layer, and interface layer to maintain the validity of the current operating domain. In this embodiment, the identifier is transmitted via URL path parameters. Based on the extracted business application identifier, the system dynamically constructs a dedicated front-end management context. This includes loading the configuration, permission model, and interface resources related to appCode. Using this front-end management context, the system performs interface locking. For example, it fixes the name of the current business system displayed at the top of the page (such as the simulation training system console) and hides or disables the global switching entry for switching to other business systems (such as the simulation engine system). Therefore, the business administrator is clearly aware from the beginning of the operation and cannot leave the current working domain.

[0026] By injecting the business application identifier into the management context at the entry point and locking the interface, the possibility of business administrators accidentally entering the unauthorized management domain is fundamentally avoided. This sets a clear boundary for all subsequent management operations and solves the problems of an overly cumbersome global management interface and the inability to truly isolate the system by simply hiding it on the front end.

[0027] S120. Based on preset filtering rules and user affiliation attributes, filter the unified identity database to obtain the target user set and target permission set belonging to the business application identifier.

[0028] In this embodiment, the preset filtering rule can refer to a set of predefined data filtering logic. The core of the preset filtering rule is to enforce the use of the appCode obtained in S110 as a necessary condition for all queries and operations. For example, the rule stipulates that when querying the user list, filtering must be performed based on the appCode. The user affiliation attribute can refer to a field stored in the user record. The user affiliation attribute can be used to identify whether the user is a global user or a private user of a specific business system application. In this embodiment, this attribute is represented by the direct application field in the user table. The unified identity database can refer to the basic database that centrally stores the users, roles, permissions, and their relationships of all business systems. The target user set can refer to the list of users that the business administrator has the right to view and manage under the current business application identifier after filtering. These users are all users related to the current simulation subsystem (i.e., the target simulation subsystem). The target permission set can refer to the list of permission nodes belonging to the current business application identifier after filtering. These permissions define the executable operations and accessible resources within the current simulation subsystem.

[0029] For example, the query results include a target user set containing private users whose direct application field equals the business application identifier, and global users whose roles exist under the business application identifier, mapped through a user-role association table (i.e., the association table between users and roles). The target permission set contains permission nodes in the permission table whose attribution field equals the business application identifier.

[0030] Specifically, after receiving a query request carrying a business application identifier (such as appCode=director-support), the system backend does not directly perform a global query on the unified identity database. Instead, it first calls an application context query builder specifically designed for delegation management scenarios. This builder encapsulates preset filtering rules, and its core logic is that all data query operations must be forced to add a filter condition based on appCode.

[0031] Specifically, the system accesses the permission table in the unified identity database. Each permission record in this table contains an application identifier field. The system uses the current business application identifier as the query condition and executes SQL equivalent logic. The query result is all permission nodes belonging to the current simulation subsystem. These nodes constitute the target permission set. Taking the model service system as an example, if appCode=model-service, the query result will only return permission nodes such as model upload, model version management, and service deployment, and will not include the creation scenario permission node of the simulation training system.

[0032] Specifically, the system uses a dual-source merging method to obtain the user list. The first source is the access user table, which filters out all user records whose direct application identifier field value equals the current appCode. These users are the application-private users of this business system. The second source is the access user-role association table, which is joined with the role table to find the user IDs corresponding to roles in the role table whose application identifier field equals the current appCode. Then, based on these user IDs, the corresponding user records are retrieved from the user table. These users are the global users with role relationships in the current business system. The system merges the user records obtained from the first and second sources to form the final target user set. Taking the aforementioned director support system as an example, this set includes both temporary director accounts (private users) whose direct application is director-support, and global users who, although their direct application is empty, have been granted the director planner role in the director support system.

[0033] Specifically, the system encapsulates the constructed target permission set and target user set, and can cache them briefly according to a strategy to improve the performance of subsequent consecutive queries within the same business console. By using a dynamic view filtering method, the appCode-based filtering logic is moved to the lowest level of data querying, ensuring that any request issued through this query builder cannot obtain user and permission data from other business systems. Simultaneously, the dual-source merging method cleverly accommodates the unified presentation of both application-private users and global users, ensuring that the user list seen by business administrators is both complete and controlled, thus resolving the risk of unauthorized access to cross-application data at the data source.

[0034] As an optional implementation of this disclosure, filtering the unified identity database based on preset filtering rules and user affiliation attributes to obtain a target user set and a target permission set belonging to a business application identifier may specifically include: querying user records and permission records in the unified identity database, extracting the direct application field from the user records as the user affiliation attribute; based on the business application identifier and preset filtering rules, filtering permission nodes in the permission table whose affiliation field is the business application identifier, and constructing a target permission set; filtering private users in the user table whose direct application field is the business application identifier, and obtaining global users with role relationships under the business application identifier through the mapping between user and role association tables, and constructing a target user set.

[0035] In this embodiment, a user record can refer to a row of data in a user table. A user record may contain basic information such as user ID, username, and direct application field. A permission record can refer to a row of data in a permission table. A permission record may contain basic information such as permission ID, permission name, and belonging field (appCode). The direct application field can refer to a field in the user table used to mark the user's affiliation. If the value of this field is empty or a specific value (such as GLOBAL), it indicates that the user is a global user. If its value is equal to a specific appCode, it indicates that the user is a private user under this application. A permission table can refer to a table in a database specifically storing permission definitions. The belonging field can refer to a field in the permission table used to identify which business application the permission belongs to.

[0036] In this embodiment, a permission node can refer to the smallest unit in a permission tree. A permission node can represent a specific operation permission or menu entry. A user table can refer to a table in a database that stores information about all user entities. A private user can refer to a user who belongs only to a specific business application and is maintained independently by that application. The direct application field in a private user's user record is equal to the appCode of that application. A relation table can refer to a database table used to establish many-to-many relationships between users and roles. A relation table can contain user ID and role ID. A role relationship can refer to a specific record in the relation table. A role relationship can indicate that a user has been assigned a certain role. A global user can refer to a user that exists in the unified identity platform and whose direct application field is empty or marked as global. Global users can be granted role relationships by multiple business systems.

[0037] Specifically, taking querying the user list as an example, the backend interface executes logic similar to the following: It queries all permission nodes whose attribution field is "drill-train" based on `appCode=drill-train`, constructing a permission set. It then finds all users whose direct application field is "drill-train" (i.e., private users) from the user table, and then finds all user IDs with role records in the "drill-train" context from the association table, retrieving the information of these global users from the user table accordingly. Finally, it merges the two parts to form the target user set. In this way, the director administrator can only see private accounts related to the director system and global accounts that have been granted director roles, but cannot see exclusive users of other simulation systems.

[0038] By forcing the filtering logic based on appCode to be executed at the backend data query layer, effective data isolation is achieved. This ensures that no matter how the business administrator operates the frontend, they cannot obtain user and permission data outside their authorized scope, thus resolving the risk of unauthorized access caused by the backend still processing data according to global logic. It also enables global users and application-private users to coexist and be managed uniformly on the same platform.

[0039] S130. In response to the role assignment instruction initiated in the current operation domain, the target role range allowed to operate is defined using the target permission set, and the mapping relationship of the target objects in the target user set is updated based on the target role range to obtain the updated role mapping dataset.

[0040] In this embodiment, the role assignment instruction can refer to a request sent from the front end to the back end after a business administrator selects roles for a user on the front-end interface and clicks "save" or "assign." This request includes the target user ID, a list of role IDs to be assigned, and the appCode of the current operation domain. The target role scope can refer to the set of role IDs allowed to be assigned under the current business application identifier. This set consists of roles associated with the target permission set. The target object can refer to the specific user being operated on in this role assignment instruction. The target object can be a global user or an application-private user. The mapping relationship can refer to the association between a user and a role, i.e., a record in the user-role association table. The role mapping dataset can refer to all or part of the data set of the user-role association table in the database.

[0041] Specifically, when the system frontend initiates a role assignment command within the current operation domain, the command carries at least the following three parameters: the current business application identifier (appCode), the target object's user ID, and a list of role IDs to be assigned (submitted by the frontend). Upon receiving the command, the backend does not directly trust it and add it to the role list; instead, it enters a role assignment processing flow constrained by the application context.

[0042] Specifically, the system first uses the current business application identifier to retrieve all role identifiers associated with any permission node in the target permission set, starting from the target permission set already constructed in S120, through a reverse lookup of the role-permission association table. The set of these role identifiers constitutes the scope of allowed roles for operation within the current business system. For example, in a simulation training system, the roles corresponding to the target permission set might only be training planner and simulation operator; while in a simulation engine system, the scope of target roles might only be engine configurer and log viewer. This step ensures that the allowed roles do not exceed the legal boundaries of the current business system.

[0043] Specifically, the system performs differentiated updates to role mappings. Using the target object (user) and the current business application identifier as joint conditions, the system performs the following operations: The system queries the user-role association table and deletes all records where the user ID equals the target object ID and the role ID belongs to the current target role range. This step aims to clear all existing role mappings for the user in the current business system without affecting mappings in other systems. The system iterates through the list of role IDs submitted from the front end, validating each role ID in the list. It determines whether the role belongs to the subdefined target role range. Only when the validation passes does the system insert a new record into the user-role association table, binding the role to the target object. If the submitted role ID does not belong to the target role range (e.g., a director administrator attempts to assign a role that only belongs to the model service system), the system will ignore the role and may selectively log alarms.

[0044] Specifically, after completing the above deletion and insertion operations, the system re-queries all valid role mapping relationships of the target object under the current business application, forms an updated role mapping dataset, and returns it to the front end as the execution result of this role allocation instruction.

[0045] For example, suppose the current business system is the director support system (appCode=director-support), and the target role range is [R01: Director, R02: Situation Monitor]. The target object is user Li Si (global user). The role ID list submitted by the front end is [R01, R03], where R03 is a role in the simulation engine system. The system performs an operation to remove expired relationships, deleting all existing roles of Li Si in the director system (assuming there was previously R02). Then, it performs an operation to bind newly assigned roles, iterating through the submitted list. R01 is within the target role range, so R01 is assigned to Li Si; R03 is not within the range and is ignored. Finally, Li Si's role mapping dataset in the director system becomes [R01], while his role R03 relationship in other systems (such as the simulation engine system) remains unchanged.

[0046] By employing a two-phase role synchronization method, the system achieves both updating and strong boundary checks for role assignment operations. On one hand, the pattern of first deleting all roles and then adding new roles based on conditions avoids the complex logic of requiring the frontend to submit a complete set of roles, simplifying frontend implementation. On the other hand, mandatory verification of each role to be assigned ensures that it falls within the target role range of the current application, completely eliminating the possibility of cross-system role assignment through tampering with requests or the management backend. Simultaneously, it guarantees that modifications to role relationships within one application will not affect the authorization status in other applications, effectively enforcing security constraints within the backend business logic.

[0047] As an optional implementation of this disclosure, in response to a role assignment instruction initiated within the current operation domain, the target role scope allowed for operation is defined using a target permission set, and the mapping relationship of target objects in the target user set is updated based on the target role scope to obtain an updated role mapping dataset. Specifically, this may include: in response to a role assignment instruction initiated within the current operation domain, extracting role identifiers associated with all permission nodes from the target permission set, and using the set of extracted role identifiers as the target role scope allowed for operation; deleting existing role mapping relationships of target objects in the target user set within the target role scope; rebinding role identifiers submitted in the role assignment instruction and belonging to the target role scope to the target objects, thereby generating an updated role mapping dataset.

[0048] In this embodiment of the disclosure, the role identifier can refer to the unique ID of a role. The role identifier can be used to locate a specific role in the database. Existing role mapping relationships can refer to all role association records that the target object has been granted under the current business application.

[0049] Specifically, suppose that for the drill-train system, the role identifiers associated with its target permission set are [201, 202, 203] (e.g., 201: Training Planner, 202: Inference Operator, 203: Data Observer). The administrator assigns the role [201, 205] to user Zhang San on the interface, where 205 is a role in another system's model-service. During backend processing, it first extracts the allowed role range [201, 202, 203]. Then, it deletes all existing role relationships for Zhang San in the drill-train system (e.g., previously only role 202). Finally, it iterates through the role list [201, 205] submitted by the administrator, rebinding only the role belonging to the allowed range [201, 202, 203] (i.e., role 201) to Zhang San. Ultimately, Zhang San's role in the drill-train system becomes

[201] , while role 205 is not assigned, and his role relationships in other systems (such as role 301 in model-service) are not affected in any way.

[0050] By enforcing the use of a target permission set in the backend to define the scope of operable roles and performing a delete-then-rebuild operation on role mapping relationships, the boundary security of role assignment is ensured. This completely eliminates unauthorized behavior in assigning roles across systems and ensures that modifications to role relationships in the current system will not inadvertently affect user authorizations in other systems, thus solving the problem of easily accidental modification of cross-application role relationships.

[0051] S140. In response to a deletion command initiated within the current operation domain, the target user set is processed using a context-aware deletion strategy to obtain the deletion execution result.

[0052] In this embodiment, the deletion instruction can refer to a request sent from the front end to the back end after a business administrator clicks the delete button on the user list page. This request includes the user ID to be deleted and the appCode of the current operation domain. The context-aware deletion strategy can refer to a logical rule that determines the specific deletion behavior based on the current operation domain (appCode) and the affiliation attribute of the user to be deleted. The core of this strategy is to distinguish between removing the current application relationship and global permanent deletion. The deletion execution result can refer to the operation result information returned to the front end after processing by the context-aware deletion strategy, such as successfully removing the user from the current system or successfully deleting the application's private user.

[0053] Specifically, upon receiving a deletion command carrying the appCode, the system invokes the context-aware deletion module. This module first queries the user's attribution attribute based on the user ID. If the user is a global user (the direct application field is empty or marked as global), the system only deletes all role mappings related to that user and the current appCode, while retaining the user entity record. If the user is a private user of the current application (the direct application field equals appCode), the system first deletes all role mappings, and then further deletes the user entity record in the user table. This processing logic prevents a global user from being completely wiped out due to an operation within a subsystem.

[0054] By introducing a context-aware deletion strategy, this invention provides explicit and predictable semantics for deletion operations, solving the problem of deletion operations easily inadvertently damaging shared identities. This allows business administrators to confidently clean up irrelevant user relationships or private accounts within their own consoles without worrying about affecting the normal operation of other subsystems.

[0055] S150. Using the business application identifier as the boundary, encapsulate the role mapping dataset and deletion execution results, and return them to the front-end management context to form the management interface of the target simulation subsystem.

[0056] In this embodiment of the disclosure, the boundary may refer to the data and scope defined by the appCode. All data returned to the front end must be within this boundary. The management interface may refer to the web page interface that is ultimately presented to the business administrator after context locking and data filtering. For example, the console interface of the directing and support system, which only displays users, roles, and menus related to directing.

[0057] Specifically, after completing all query, allocation, and deletion operations, the backend encapsulates all processing results (such as the updated user list, successful role allocation confirmation, deletion results, etc.) along with the appCode of this request into a unified response data structure and returns it to the frontend. Upon receiving the response, the frontend renders this data into the corresponding UI components based on the current management context. For example, after deleting a global user, the user will be immediately removed from the frontend user list (because its relationship with the system no longer exists), but the user entity will still exist in the backend user database. This entire process ensures that all information seen by the business administrator on the frontend is consistent with the actual results processed by the backend and is strictly confined within the boundaries of the current appCode.

[0058] This forms a complete closed loop from request to response, ensuring that the information displayed on the management interface is strictly consistent with the backend data status, providing users with a clear, accurate, and unambiguous experience.

[0059] The technical solution of this invention involves: acquiring access requests initiated by a business administrator through an access path; parsing the access requests to obtain the business application identifier corresponding to the target simulation subsystem; determining the front-end management context corresponding to the target simulation subsystem based on the business application identifier; locking the current operation domain and hiding the global switching entry point using the front-end management context; achieving context locking from the front-end entry point to the operation interface, fundamentally defining the administrator's work domain. Based on preset filtering rules and user affiliation attributes, the unified identity database is filtered to obtain a set of target users and a set of target permissions belonging to the business application identifier; application boundaries are enforced at the back-end data query layer, achieving effective data isolation and supporting the coexistence of global and private users. In response to a role assignment instruction initiated within the current operation domain, the target permission set is used to define the scope of allowed operations for target roles, and the mapping relationship of target objects in the target user set is updated based on the target role scope to obtain an updated role mapping dataset; ensuring the security boundary of role assignment operations, preventing unauthorized assignment across applications, and avoiding unintended impact on the authorization relationships of other applications. Responding to deletion commands initiated within the current operating domain, the system utilizes a context-aware deletion strategy to process the target user set and obtain the deletion execution result. It provides a semantically clear and context-constrained deletion mechanism, resolving the issue of accidental deletion of shared identities. Using business application identifiers as boundaries, the system encapsulates the role mapping dataset and deletion execution result, returning it to the front-end management context to form the management interface of the target simulation subsystem. This ensures the ultimate consistency between the front-end display and the back-end data state, forming a complete closed loop. It solves problems such as high costs of redundant construction, unauthorized operations, incomplete data isolation, and accidental deletion when multiple business systems share an identity platform, achieving secure, efficient, and reusable delegated identity management.

[0060] As an optional implementation of this disclosure, the method further includes: responding to a permission tree acquisition request initiated in the current operating domain, filtering a set of permission nodes belonging to the target simulation subsystem from the permission table based on the business application identifier; assembling the permission node set into a multi-level permission tree according to the parent-child hierarchical relationship between the nodes in the permission node set; and returning the assembled permission tree to the front-end management context to assist in the generation of role allocation instructions.

[0061] In this embodiment, the permission tree retrieval request can refer to a request automatically initiated by the front-end to the back-end when a business administrator opens the role management or permission allocation page, used to obtain the current system permission structure. This request carries the current appCode. The permission node set can refer to a list of all permission records filtered from the permission table whose attribution field equals the current appCode. The parent-child hierarchy can refer to the hierarchical relationship between permission nodes defined by fields such as parentId. For example, user management is the parent node, and creating and deleting users are its child nodes. A multi-level permission tree can refer to tree-structured data organized by permission nodes according to parent-child hierarchical relationships. A multi-level permission tree can be used to visually display all manageable permissions within a business system.

[0062] Specifically, when a business administrator enters the role assignment page, the frontend sends a permission tree retrieval request with the current appCode (e.g., model-service). Upon receiving the request, the backend interface queries the permission table for all permission nodes whose appCode field equals model-service, forming a set. Based on the parentId field in these nodes, the backend uses a recursive or iterative algorithm to assemble the hashed list of nodes into one or more complete tree structures. This permission tree, containing only permissions related to the model service system (such as model upload, model version management, service deployment, etc.), is returned to the frontend. The frontend uses this permission tree to render the role assignment interface, ensuring that the permissions seen and assigned by the business administrator are entirely limited to the current system.

[0063] This ensures that the permission tree structure seen by business administrators in the consoles of different simulation subsystems is completely independent and corresponds to their own system. This avoids confusion and misassignment of permissions, making the mapping relationship between permission management and business systems clear and unambiguous, further improving management focus. Unlike solutions that only isolate permissions by menu, this invention guarantees the accuracy of the permission tree from the backend data source.

[0064] As an optional implementation of this disclosure, the method further includes: defining a unique business application identifier for each simulation subsystem in the multi-simulation business system, and generating an access path carrying the business application identifier for the business console of each simulation subsystem.

[0065] In this embodiment, a multi-simulation business system can refer to a complex platform composed of multiple simulation subsystems with different functions, such as a military simulation platform. A simulation subsystem can refer to a single business unit constituting the platform, such as a simulation training system, a simulation engine system, a model service system, or a command and control support system. The business console can refer to a management view with a specific appCode as its context entry point. The business console serves only the identity governance of a single business system.

[0066] Specifically, this optional implementation method is a preparatory process for the delegated identity management method. During system initialization or when a new business system is integrated, the administrator of the unified identity platform registers a record in the application table for each simulated subsystem and generates a globally unique business application identifier for that record. For example, appCode=director-support is defined for the directing and support system. Based on this identifier, the system automatically or through administrator configuration generates a dedicated access path for the business console of that subsystem, for example, the access path is: https: / / unified-idp.com / console / director-support. This path will serve as the sole entry point for the business administrator of that subsystem to access its management interface.

[0067] By standardizing the identifier definition and path generation process, the integration of new business systems becomes simple and standardized. When the platform needs to add a new simulation subsystem, this step can be repeated to provide an isolated and accessible management entry point for that subsystem, without the need to develop a separate identity management backend. This greatly improves the platform's scalability and solves the problems of high costs and hindering the long-term evolution of the platform by developing a separate backend for each system.

[0068] Example 2 Figure 2 This is a flowchart of a delegated identity management method for a multi-simulation business system provided in Embodiment 2 of the present invention. Based on the above embodiments, this embodiment describes in detail the context-aware processing of the deletion operation. Explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here. Figure 2 As shown, the method includes: S210. Obtain the access request initiated by the business administrator through the access path; parse the access request to obtain the business application identifier corresponding to the target simulation subsystem; determine the front-end management context corresponding to the target simulation subsystem based on the business application identifier; use the front-end management context to lock the current operation domain and hide the global switching entry.

[0069] S220. Based on preset filtering rules and user affiliation attributes, filter the unified identity database to obtain the target user set and target permission set belonging to the business application identifier.

[0070] S230. In response to the role assignment instruction initiated within the current operation domain, the target role range allowed to operate is defined using the target permission set, and the mapping relationship of the target objects in the target user set is updated based on the target role range to obtain the updated role mapping dataset.

[0071] S240. In response to a deletion command initiated within the current operation domain, the business application identifier is used to locate the authorization relationship to be removed of the target object under the target simulation subsystem, and the mapping dataset to be deleted is obtained.

[0072] In this embodiment of the disclosure, the authorization relationship to be removed can refer to all user-role association records that the target object has under the current business application (appCode). The mapping dataset to be deleted can refer to the set of these authorization relationships to be removed.

[0073] Specifically, when the system receives a deletion command, it queries the user-role association table for all associated records in the application to which the role belongs whose appCode is equal to the current appCode, based on the appCode and target user ID in the command. These records are then extracted as a dataset to be processed to obtain the mapping dataset to be deleted.

[0074] S250. Identify the user affiliation of the target object based on the user affiliation attribute and determine the user affiliation determination result.

[0075] In this embodiment, the user affiliation determination result can refer to the category conclusion obtained after identifying the target user's affiliation attributes (such as the value of the direct application field in the user table) in the unified identity database. This conclusion includes at least two types: global users and application-private users. A global user indicates that the user is a shared account existing in the unified identity platform and can be granted role relationships by multiple business systems. An application-private user indicates that the user belongs only to the simulation subsystem corresponding to the current business application identifier and is independently maintained by that subsystem. This determination result is used to determine different paths for subsequent deletion operations.

[0076] Specifically, the system queries the user table to retrieve the value of the direct application field from the target user record. If the value is empty or equal to a specific value representing the global context (such as NULL or GLOBAL), the user is determined to be a global user. If the value is equal to the current appCode, the user is determined to be a private user.

[0077] S260. If the user affiliation determination result is a global user, then remove the role mapping from the mapping dataset to be deleted and retain the user entity to obtain the first deletion execution result.

[0078] In this embodiment, a user entity can refer to a complete and independent user record stored in the user table of the unified identity database. This record contains all attribute information, including the user's unique identifier, username, direct application field, and creation time. The user entity is the form in which a user exists on the platform. The user entity is independent of any role mapping relationship between it and any business system. The first deletion execution result can refer to the result information returned by the system after performing an operation that removes only the role mapping relationship under the current application and retains the user entity when the user's affiliation determination result is a global user. This result includes at least the following: a status indicator indicating whether the operation was successful, the number of role mappings removed under the current business application, and a clear statement indicating that the user entity has not been deleted and is still retained in the unified identity platform.

[0079] Specifically, for target objects identified as global users, the system will perform database operations to delete all authorization relationships to be removed located in S240. However, the system will not delete the user record in the user table. The final returned first deletion execution result may include information such as user Zhang San has been removed from the current simulation training system.

[0080] S270. If the user ownership determination result is a private user, then remove the role mapping in the mapping dataset to be deleted and delete the user entity to obtain the second deletion execution result.

[0081] In this embodiment of the disclosure, the second deletion execution result may refer to the result information returned by the system after performing the operation of removing the role mapping relationship under the current application and further deleting the user entity when the user ownership determination result is a private user of the application. The result includes at least the following: a status indicator of whether the operation was successful, the number of role mappings removed, confirmation information that the user entity has been completely deleted, and the related data cleanup situation that may be caused by the deletion of the user entity (such as the user reference in the operation log being marked as a deleted user, etc.).

[0082] Specifically, for a target object determined to be a private user, the system first performs the same operation as in S260, namely, deleting all authorization relationships to be removed. The system then performs a deletion operation to completely remove the user record from the user table. The final returned second deletion execution result may include information such as the private user temporary tester has been completely deleted.

[0083] S280. Using the business application identifier as the boundary, encapsulate the role mapping dataset and deletion execution results, and return them to the front-end management context to form the management interface of the target simulation subsystem.

[0084] The technical solution of this invention, in response to a deletion command initiated within the current operating domain, utilizes the business application identifier to locate the authorization relationship to be removed from the target object in the target simulation subsystem, obtaining the mapping dataset to be deleted; it accurately locates the authorization relationship that needs to be removed in the current context, avoiding global and ambiguous deletion operations. User affiliation is identified for the target object based on user affiliation attributes, determining the user affiliation judgment result; this provides a key basis for subsequent differentiated deletion strategies and is the foundation for refined management. If the user affiliation judgment result is a global user, the role mapping in the mapping dataset to be deleted is removed while the user entity is retained, resulting in the first deletion execution result; this achieves the deletion semantics of removing relationships within the current system, protecting the integrity and availability of shared identities in other systems. If the user affiliation judgment result is a private user, the role mapping in the mapping dataset to be deleted is removed while the user entity is deleted, resulting in the second deletion execution result; this achieves the deletion semantics of thoroughly cleaning up private data, meeting the lifecycle management needs of temporary or exclusive accounts; it clearly distinguishes deletion operations into two context-constrained actions, significantly improving the security and flexibility of deletion operations, and comprehensively solving the problem of deletion operations easily damaging shared identities.

[0085] The following are embodiments of the delegated identity management device for multi-simulation business systems provided by the present invention. This device and the delegated identity management method for multi-simulation business systems in the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the delegated identity management device for multi-simulation business systems, please refer to the embodiments of the delegated identity management method for multi-simulation business systems described above.

[0086] Example 3 Figure 3 This is a schematic diagram of a delegated identity management device for a multi-simulation business system provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes: an operation domain locking module 310, a data filtering module 320, a role mapping dataset update module 330, a deletion execution result determination module 340, and a management interface formation module 350.

[0087] The system comprises the following modules: Operation Domain Locking Module 310, which acquires access requests initiated by the business administrator through access paths; parses the access requests to obtain the business application identifier corresponding to the target simulation subsystem; determines the front-end management context corresponding to the target simulation subsystem based on the business application identifier; and locks the current operation domain and hides the global switching entry using the front-end management context. Data Filtering Module 320, which filters the unified identity database based on preset filtering rules and user affiliation attributes to obtain a set of target users and a set of target permissions belonging to the business application identifier. Role Mapping Dataset Update Module 330, which responds to role assignment instructions initiated within the current operation domain, defines the scope of allowed operation roles using the target permission set, and updates the mapping relationship of target objects in the target user set based on the target role scope to obtain the updated role mapping dataset. Deletion Execution Result Determination Module 340, which responds to deletion instructions initiated within the current operation domain, processes the target user set using a context-aware deletion strategy to obtain the deletion execution result. Management Interface Forming Module 350, which encapsulates the role mapping dataset and the deletion execution result with the business application identifier as the boundary, returns it to the front-end management context, and forms the management interface of the target simulation subsystem.

[0088] The technical solution of this invention involves: acquiring access requests initiated by a business administrator through an access path; parsing the access requests to obtain the business application identifier corresponding to the target simulation subsystem; determining the front-end management context corresponding to the target simulation subsystem based on the business application identifier; locking the current operation domain and hiding the global switching entry point using the front-end management context; achieving context locking from the front-end entry point to the operation interface, fundamentally defining the administrator's work domain. Based on preset filtering rules and user affiliation attributes, the unified identity database is filtered to obtain a set of target users and a set of target permissions belonging to the business application identifier; application boundaries are enforced at the back-end data query layer, achieving effective data isolation and supporting the coexistence of global and private users. In response to a role assignment instruction initiated within the current operation domain, the target permission set is used to define the scope of allowed operations for target roles, and the mapping relationship of target objects in the target user set is updated based on the target role scope to obtain an updated role mapping dataset; ensuring the security boundary of role assignment operations, preventing unauthorized assignment across applications, and avoiding unintended impact on the authorization relationships of other applications. Responding to deletion commands initiated within the current operating domain, the system utilizes a context-aware deletion strategy to process the target user set and obtain the deletion execution result. It provides a semantically clear and context-constrained deletion mechanism, resolving the issue of accidental deletion of shared identities. Using business application identifiers as boundaries, the system encapsulates the role mapping dataset and deletion execution result, returning it to the front-end management context to form the management interface of the target simulation subsystem. This ensures the ultimate consistency between the front-end display and the back-end data state, forming a complete closed loop. It solves problems such as high costs of redundant construction, unauthorized operations, incomplete data isolation, and accidental deletion when multiple business systems share an identity platform, achieving secure, efficient, and reusable delegated identity management.

[0089] Optionally, the data filtering module 320 is specifically used to: query user records and permission records in the unified identity database, extract the direct application field from the user records as the user's attribution attribute; based on the business application identifier and preset filtering rules, filter permission nodes in the permission table whose attribution field is the business application identifier, and construct a target permission set; filter private users in the user table whose direct application field is the business application identifier, and obtain global users with role relationships under the business application identifier through the mapping between the user and role association table, and construct a target user set.

[0090] Optionally, the role mapping dataset update module 330 is specifically used to: in response to a role assignment instruction initiated in the current operation domain, extract the role identifiers associated with all permission nodes from the target permission set, and use the set of extracted role identifiers as the target role range for allowed operations; delete the existing role mapping relationships of the target objects in the target user set within the target role range; rebind the role identifiers submitted in the role assignment instruction and belonging to the target role range to the target objects, and generate an updated role mapping dataset.

[0091] Optionally, the deletion execution result determination module 340 is specifically used to: respond to a deletion command initiated in the current operation domain, locate the authorization relationship to be removed of the target object in the target simulation subsystem using the business application identifier, and obtain the mapping dataset to be deleted; identify the user affiliation of the target object according to the user affiliation attribute, and determine the user affiliation judgment result; if the user affiliation judgment result is a global user, remove the role mapping in the mapping dataset to be deleted and retain the user entity, and obtain the first deletion execution result; if the user affiliation judgment result is a private user, remove the role mapping in the mapping dataset to be deleted and delete the user entity, and obtain the second deletion execution result.

[0092] Optionally, the device further includes: The permission node filtering module is used to respond to permission tree retrieval requests initiated within the current operation domain and filter the set of permission nodes belonging to the target simulation subsystem from the permission table based on the business application identifier. The permission tree assembly module is used to assemble the permission node set into a multi-level permission tree based on the parent-child hierarchy relationship between the nodes in the permission node set; The permission tree return module is used to return the assembled permission tree to the front-end management context to assist in the generation of role assignment instructions.

[0093] Optionally, the device further includes: The access path generation module is used to define a unique business application identifier for each simulation subsystem in the multi-simulation business system, and to generate an access path carrying the business application identifier for the business console of each simulation subsystem.

[0094] The delegated identity management device for multi-simulation business systems provided in this embodiment of the invention can execute the delegated identity management method for multi-simulation business systems provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the delegated identity management method for multi-simulation business systems.

[0095] It is worth noting that in the above-described embodiments of delegated identity management for multi-simulation business systems, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of this invention.

[0096] Example 4 Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0097] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0098] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0099] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the delegated identity management method for multi-emulation business systems.

[0100] In some embodiments, the delegated identity management method for a multi-emulation business system can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the delegated identity management method for a multi-emulation business system described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the delegated identity management method for a multi-emulation business system by any other suitable means (e.g., by means of firmware).

[0101] Various implementations of the systems and techniques described above herein can be implemented in digital circuit systems, integrated circuits, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0102] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0103] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0104] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0105] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0106] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0107] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the delegated identity management method for multi-emulation business systems as provided in any embodiment of this application.

[0108] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider). This program product belongs to the same inventive concept as the delegated identity management method for multi-emulation business systems disclosed in the embodiments of this application, and therefore will not be described further here.

[0109] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0110] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for managing delegated identities in a multi-simulation business system, characterized in that, include: Obtain access requests initiated by the business administrator through the access path; Parse the access request to obtain the business application identifier corresponding to the target simulation subsystem; The front-end management context corresponding to the target simulation subsystem is determined based on the business application identifier; The current operation domain is locked and the global switching entry is hidden using the aforementioned front-end management context; Based on preset filtering rules and user affiliation attributes, the unified identity database is filtered to obtain the target user set and target permission set belonging to the business application identifier; In response to a role assignment instruction initiated within the current operation domain, the role identifiers associated with all permission nodes are extracted from the target permission set, and the set of extracted role identifiers is taken as the target role range for permitted operations; the existing role mapping relationships of the target objects in the target user set within the target role range are deleted; Rebind the character identifiers submitted in the character assignment instruction that belong to the target character range to the target object, and generate an updated character mapping dataset; In response to a deletion command initiated within the current operation domain, the business application identifier is used to locate the authorization relationship to be removed of the target object under the target simulation subsystem, thereby obtaining the mapping dataset to be deleted; Based on the user affiliation attributes, the target object is identified to determine the user affiliation determination result. If the user affiliation determination result is a global user, then remove the role mapping from the mapping dataset to be deleted and retain the user entity to obtain the first deletion execution result; If the user ownership determination result is a private user, then remove the role mapping from the mapping dataset to be deleted and delete the user entity to obtain the second deletion execution result; Using the business application identifier as the boundary, the role mapping dataset and the deletion execution result are encapsulated and returned to the front-end management context to form the management interface of the target simulation subsystem.

2. The method according to claim 1, characterized in that, The step of filtering the unified identity database based on preset filtering rules and user affiliation attributes to obtain a target user set and a target permission set belonging to the business application identifier includes: Query user records and permission records in the unified identity database, and extract the direct application field from the user record as the user's attribution attribute; Based on the business application identifier and preset filtering rules, permission nodes in the permission table whose belonging field is the business application identifier are selected to construct a target permission set; Private users whose direct application field in the user table is the business application identifier are filtered out, and global users who have a role relationship under the business application identifier are obtained through the association table mapping between users and roles, thus constructing a target user set.

3. The method according to claim 1, characterized in that, The method further includes: In response to a permission tree retrieval request initiated within the current operation domain, a set of permission nodes belonging to the target simulation subsystem is selected from the permission table based on the business application identifier. Based on the parent-child hierarchical relationship between the nodes in the permission node set, the permission node set is assembled into a multi-level permission tree; The assembled permission tree is returned to the front-end management context to assist in the generation of the role assignment instructions.

4. The method according to claim 1, characterized in that, The method further includes: Define a unique business application identifier for each simulation subsystem in the multi-simulation business system, and generate an access path carrying the business application identifier for the business console of each simulation subsystem.

5. A delegated identity management device for multi-simulation business systems, characterized in that, The device includes: The operation domain locking module is used to obtain access requests initiated by business administrators through access paths; parse the access requests to obtain the business application identifier corresponding to the target simulation subsystem; determine the front-end management context corresponding to the target simulation subsystem based on the business application identifier; and lock the current operation domain and hide the global switching entry using the front-end management context. The data filtering module is used to filter the unified identity database based on preset filtering rules and user affiliation attributes to obtain the target user set and target permission set belonging to the business application identifier. The role mapping dataset update module is used to respond to the role assignment instruction initiated in the current operation domain, define the scope of target roles that are allowed to operate using the target permission set, and update the mapping relationship of target objects in the target user set based on the scope of target roles to obtain the updated role mapping dataset; The deletion execution result determination module is used to respond to a deletion command initiated in the current operation domain, process the target user set using a context-aware deletion strategy, and obtain the deletion execution result; The management interface forming module is used to encapsulate the role mapping dataset and the deletion execution result with the business application identifier as the boundary, and return them to the front-end management context to form the management interface of the target simulation subsystem. Specifically, the role mapping dataset update module is used to: respond to a role assignment instruction initiated within the current operation domain, extract role identifiers associated with all permission nodes from the target permission set, and use the set of extracted role identifiers as the target role range for allowed operations; delete existing role mapping relationships of target objects in the target user set within the target role range; rebind the role identifiers submitted in the role assignment instruction and belonging to the target role range to the target object, and generate an updated role mapping dataset; The deletion execution result determination module is specifically used for: responding to a deletion command initiated within the current operation domain, using the business application identifier to locate the authorization relationship to be removed of the target object under the target simulation subsystem, and obtaining a mapping dataset to be deleted; performing user affiliation identification on the target object according to the user affiliation attribute, and determining the user affiliation determination result; if the user affiliation determination result is a global user, then removing the role mapping in the mapping dataset to be deleted and retaining the user entity, and obtaining a first deletion execution result; if the user affiliation determination result is a private user, then removing the role mapping in the mapping dataset to be deleted and deleting the user entity, and obtaining a second deletion execution result.

6. An electronic device, characterized in that, The electronic device includes: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the delegated identity management method for multi-emulation business systems as described in any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the delegated identity management method for multi-simulation business systems as described in any one of claims 1-4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the delegated identity management method for multi-simulation business systems as described in any one of claims 1-4.

Images