Data processing method, device and equipment and readable storage medium

Abstract

The invention discloses a data processing method and device, equipment and a readable storage medium, and the method comprises the steps: obtaining a target administrator account mapped by a target object account for an account management service from a pre-stored account model in response to an access request triggered by the target object account for the account management service; generating a single sign-on voucher of the target object account based on the target administrator account; determining at least one target administrator role mapped by the target object account and preset management authority information of each target administrator role for the target object account from the account model according to the single sign-on certificate; and sending management authority information preset by each target administrator role for the target object account to a source end where the target object account is located for authority information display. Therefore, the target administrator account does not need to be directly allocated to the target object, the target object account can also perform the management authority in the account management service, and the management efficiency of the administrator account is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a data processing method, apparatus, device, and readable storage medium. Background Technology

[0002] With the development of information technology, a wide range of business services can provide self-service to individuals, such as online shopping, electronic ticketing, and employee management. However, when individuals use these services, they may need administrator privileges to access the corresponding business service functions.

[0003] The relevant technology specifies the administrator type of the administrator account and sets the scope of administrator permissions for the administrator type. In other words, it binds the scope of administrator permissions to the administrator account. When an individual object needs to use the corresponding administrator permissions, the administrator account needs to be assigned to the individual object.

[0004] In the process of researching and practicing related technologies, the inventors of this application discovered that the related technologies, by assigning administrator accounts to individual objects to enable administrator privileges, can lead to the abuse of administrator accounts. When different types of administrator privileges need to be granted to the same individual object, multiple different administrator accounts need to be assigned to that individual object. Furthermore, assigning the same administrator account to multiple objects can easily lead to usage conflicts, which is not conducive to the management of administrator account information. Summary of the Invention

[0005] This application provides a data processing method, apparatus, device, and readable storage medium that can avoid scenarios where administrator accounts are assigned to individual objects or multiple objects, ensuring that each object can be empowered with corresponding management permissions, thereby improving the management efficiency and convenience of administrator accounts.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] This application provides a data processing method, including:

[0008] In response to an access request triggered by a target object account for the account management service, the target administrator account mapped by the target object account for the account management service is obtained from the pre-stored account model;

[0009] The account model includes a target administrator account pre-set in the account management service for the target object account, a target administrator role pre-set for the target object account by the target administrator account, and management permission information pre-set for the target object account by the target administrator role.

[0010] Generate single sign-on credentials for the target object account based on the target administrator account;

[0011] Based on the single sign-on credential, determine at least one target administrator role mapped to the target object account from the account model, and obtain the pre-set management permission information for each target administrator role for the target object account;

[0012] The pre-defined management permission information for each target administrator role for the target account is sent to the source server where the target account is located for permission information display.

[0013] Accordingly, embodiments of this application provide a data processing apparatus, including:

[0014] The acquisition unit is used to, in response to an access request triggered by a target object account for the account management service, acquire the target administrator account mapped by the target object account for the account management service from a pre-stored account model;

[0015] The account model includes a target administrator account pre-set in the account management service for the target object account, a target administrator role pre-set for the target object account by the target administrator account, and management permission information pre-set for the target object account by the target administrator role.

[0016] The generation unit is used to generate a single sign-on credential for the target object account based on the target administrator account;

[0017] The determining unit is configured to determine at least one target administrator role mapped to the target object account from the account model based on the single sign-on credential, and to obtain the management permission information preset for each target administrator role for the target object account.

[0018] The sending unit is used to send the pre-set management permission information of each target administrator role for the target object account to the source end where the target object account is located for permission information display.

[0019] In some embodiments, the determining unit is further configured to:

[0020] Log in to the account management service using the single sign-on credential and obtain the login result;

[0021] When the login result is successful, determine at least one target administrator role that the target object account is mapped to in the account management service from the account model;

[0022] Determine the pre-defined management permissions for each target administrator role for the target account.

[0023] In some embodiments, the determining unit is further configured to:

[0024] Based on the single sign-on credentials, determine the address of the device to be confirmed at the source end where the target object account is currently located;

[0025] Obtain the target device address pre-stored for the target object account, and perform login verification on the device address to be confirmed based on the target device address;

[0026] When the address of the device to be confirmed matches the address of the target device, the account management service is accessed based on the single sign-on credential, and the login success is determined as the login result.

[0027] When the address of the device to be confirmed does not match the address of the target device, the login failure will be determined as the login result.

[0028] In some embodiments, the generating unit is further configured to:

[0029] Based on the target object account and the target administrator account, obtain the historical single sign-on credential generated by the target object account last time, and determine the validity period of the historical single sign-on credential.

[0030] When the effective usage period matches the current time, the historical single sign-on credential is determined as the single sign-on credential for the target account;

[0031] When the effective usage period does not match the current time, obtain the historical generation frequency of single sign-on credentials for the target account within the historical time period;

[0032] When the frequency of historical data generation is less than the preset upper limit threshold, a single sign-on credential for the target object account is generated based on the target administrator account.

[0033] In some embodiments, the data processing apparatus further includes a creation unit for:

[0034] In response to a role creation request sent by an administrator account, obtain a list of pre-configured administrator roles in the account management service;

[0035] Obtain the administrator role to be created selected by the administrator account based on the list of administrator roles, and select the management permission to be created from the pre-configured management permissions supported by the administrator role to be created;

[0036] Bind the administrator account with the administrator role to be created and the management permissions to be created to obtain the binding information of the administrator account;

[0037] Create an account model based on the administrator account's binding information.

[0038] In some embodiments, the data processing apparatus further includes an update unit for:

[0039] Obtain the role customization request sent by the administrator account, wherein the role customization request carries a role customization identifier;

[0040] Send the set of management permissions supported by the account management service to the administrator account;

[0041] Obtain at least one candidate management permission selected by the administrator account from the set of management permissions, and create a custom administrator role corresponding to the role custom identifier based on the at least one candidate management permission;

[0042] The administrator account is bound to the custom administrator role and the candidate management permissions to obtain custom binding information;

[0043] Add the custom binding information to the account model.

[0044] In some embodiments, the data processing apparatus further includes a permission allocation unit, used for:

[0045] Obtain a permission allocation request, the permission allocation request carrying the administrator role identifier and object account to be allocated;

[0046] Search the account model for candidate administrator accounts that are bound to the administrator role corresponding to the administrator role identifier;

[0047] The object account is bound to the candidate administrator account and the administrator role corresponding to the administrator role identifier to obtain permission allocation information, and the permission allocation information is added to the account model.

[0048] In some embodiments, the data processing apparatus further includes a login unit for:

[0049] In response to a login request triggered by the target object account on the object account service page, the target object account is verified, and a verification result is obtained;

[0050] When the verification result is successful and it is confirmed that the target object account has the right to use the account management service, the application permission information of the account management service is sent to the target object account.

[0051] In response to an access request to the account management service triggered by the target object account based on the application permission information.

[0052] In some embodiments, the data processing apparatus further includes an execution unit for:

[0053] Obtain the target management permissions selected by the target object account based on the management permission information in the permission information page;

[0054] Execute the target management request sent by the target object account according to the target management permissions.

[0055] In some implementations, the target management permissions include at least application management permissions, and the execution unit is further configured to:

[0056] Based on the application management permissions, obtain the list of candidate applications that have been added to the account management service;

[0057] The list of candidate applications is sent to the source server where the target account is located for rendering and displaying the application management page;

[0058] Obtain at least one candidate application selected by the target object account based on the application management page, and bind the at least one candidate application to the target object account in the account model.

[0059] Furthermore, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described data processing method.

[0060] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the above-described data processing method.

[0061] Furthermore, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a storage medium. A processor of a computer device reads the computer instructions from the storage medium and executes the computer instructions to implement the aforementioned data processing method.

[0062] In response to an access request triggered by a target account for the account management service, this application embodiment can retrieve the target administrator account mapped to the account management service from a pre-stored account model. The account model includes the target administrator account pre-set in the account management service, the target administrator role pre-set by the target administrator account for the target account, and the management permission information pre-set by the target administrator role for the target account. A single sign-on credential for the target account is generated based on the target administrator account. Based on the single sign-on credential, at least one target administrator role mapped to the target account is determined from the account model, and the management permission information pre-set by each target administrator role for the target account is obtained. The management permission information pre-set by each target administrator role for the target account is sent to the source server where the target account is located for permission information display.

[0063] Based on this, this application can query the target administrator account mapped to the target account from the pre-created account model based on the target account's access request to the account management service. Then, it generates a single sign-on credential for the target account to access the account management service through the target administrator account. Next, it determines the administrator role and corresponding management permissions granted to the target account in the account management service through the single sign-on credential. Finally, it sends the granted administrator role and corresponding management permissions to the source end where the target account is located for permission information display.

[0064] Therefore, compared to existing technologies that empower individual objects with administrator privileges by assigning administrator accounts to individual objects or multiple objects, this application pre-maps object accounts to administrator accounts, at least one administrator role within the administrator account, and corresponding management permissions within the account model of the account management service. This enables fine-grained authorization management of administrator accounts based on administrator roles and the management permissions under those roles. Consequently, when a target object account needs to exercise management permissions in the account management service, single sign-on for the account management service is completed directly using the target administrator account mapped to the target object account. This determines the administrator role and management permissions associated with the target object account. Thus, there is no need to directly assign the target administrator account to the target object, and the target object account can still exercise the management permissions granted in the account management service. This ensures that each object can be effectively empowered with the corresponding management permissions, improving the management efficiency and convenience of administrator accounts.

[0065] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0066] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0067] Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application.

[0068] Figure 2 This is a flowchart illustrating the steps of the data processing method provided in the embodiments of this application;

[0069] Figure 3 This is another step of the data processing method provided in the embodiments of this application;

[0070] Figure 4 An example image of a page showing the list of administrator roles in an account management service provided in this application embodiment;

[0071] Figure 5 An example diagram illustrating the editing scenario of administrator role management permissions provided in this application embodiment;

[0072] Figure 6 This is an example image of a page showing the administrator account list in the account management service of this application embodiment;

[0073] Figure 7 Example image of the administrator account creation page provided in this application embodiment;

[0074] Figure 8 An example diagram illustrating a scenario where an object account is mapped to an administrator account, as provided in an embodiment of this application.

[0075] Figure 9 This is an example diagram of the application permission page of the object account in the object account service according to an embodiment of this application;

[0076] Figure 10 Example diagram of the account management service provided in the embodiments of this application;

[0077] Figure 11 Example diagram of administrator account mapping management architecture provided in the embodiments of this application;

[0078] Figure 12 A timing flowchart illustrating a data processing scenario example provided in the embodiments of this application;

[0079] Figure 13This is a schematic diagram of the structure of the data processing apparatus provided in the embodiments of this application;

[0080] Figure 14 This is a schematic diagram of the terminal structure provided in the embodiments of this application;

[0081] Figure 15 This is a schematic diagram of the server structure provided in an embodiment of this application. Detailed Implementation

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

[0083] It is understood that in the specific implementation of this application, data related to target object accounts, administrator accounts, administrator roles, management permissions, etc. are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the target object is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0084] Furthermore, when this application embodiment needs to obtain data related to the target object account, administrator account, administrator role, management permissions, etc., it will obtain separate permission or separate consent for the target object account, administrator account, administrator role, management permissions, etc. through pop-up windows or redirection to a confirmation page. After clearly obtaining separate permission or separate consent for the target object account, administrator account, administrator role, management permissions, etc., it will then obtain the necessary target object account, administrator account, administrator role, management permissions, etc., data required for the normal operation of this application embodiment.

[0085] It should be noted that while some processes described in the specification, claims, and accompanying drawings contain multiple steps that appear in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not represent any particular order of execution. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

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

[0087] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0088] Single Sign-On (SSO) is a method of authentication where an object logs in once. Once an object logs in to the identity authentication server, it gains access to other related systems and applications within the SSO system. This is achieved without requiring administrators to modify the object's login status or other information. This means that across multiple application systems, an object only needs to log in once to access all mutually trusted applications. This approach reduces the time spent on logins and facilitates object management.

[0089] Self-service: A platform for self-service used by individual objects within a product, primarily by individual entities. In this embodiment, it can be understood as a "platform for object account services," which will be demonstrated and described later.

[0090] Console: A platform used by administrator-type objects, primarily by human administrators. In this embodiment, it can be understood as a platform for "account management services".

[0091] This application provides a data processing method, apparatus, device, and readable storage medium. Specifically, this application will describe the data processing apparatus from the perspective of the data processing apparatus. This data processing apparatus can be integrated into a computer device, which can be a server or a terminal device, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal device can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, smart home appliance, vehicle terminal, smart voice interaction device, aircraft, etc., but is not limited to these.

[0092] This application provides a data processing method, which is specifically illustrated through the following embodiments:

[0093] When granting administrator privileges to individual objects, the relevant technology binds administrator accounts with administrator types and permission scopes, and then assigns these administrator accounts to individual objects. However, this method can lead to the abuse of administrator accounts. Furthermore, when different types of administrator privileges need to be granted to the same individual object, multiple administrator accounts of different types must be assigned to that individual object. When the same administrator account is assigned to multiple objects, it can cause conflicts in account usage and is detrimental to the management of administrator account information.

[0094] To address the aforementioned issues, this application proposes a data processing method. This method pre-maps object accounts to administrator accounts, at least one administrator role within the administrator account, and corresponding management permissions within the account model of the account management service. This enables fine-grained authorization management of administrator accounts based on administrator roles and their associated permissions. Consequently, when a target object account needs to exercise management permissions within the account management service, single sign-on is directly performed using the target administrator account mapped to the target object account. This determines the associated administrator role and management permissions of the target object account. Therefore, it eliminates the need to directly assign the target administrator account to the target object, allowing the target object account to exercise the management permissions granted by the account management service. This ensures that each object is effectively empowered with the corresponding management permissions, improving the efficiency and convenience of administrator account management. Please refer to the following specific embodiments for details.

[0095] This application provides a data processing system. The devices in this system may include a server and / or a terminal. The terminal may request the server to execute the data processing method of this application.

[0096] For example, the system includes a server or terminal. The terminal or server can respond to an access request triggered by a target account for the account management service, and retrieve the target administrator account mapped to the account management service from a pre-stored account model. The account model includes the target administrator account pre-set in the account management service, the target administrator role pre-set for the target account, and the management permission information pre-set for the target account by the target administrator role. A single sign-on credential for the target account is generated based on the target administrator account. Based on the single sign-on credential, at least one target administrator role mapped to the target account is determined from the account model, and the management permission information pre-set for each target administrator role is obtained. The management permission information pre-set for each target administrator role is sent to the source server where the target account is located for permission information display.

[0097] For example, see Figure 1 This is a schematic diagram of a data processing system provided in an embodiment of this application. The system includes a terminal 110 and a server 120.

[0098] The terminal 110 can send tasks to be processed to the server 120; in addition, a client can be installed on the terminal 110, which can send requests to the server.

[0099] The server 120 can be a distributed system composed of one or more physical machines, with each physical machine corresponding to a service node. When executing the data processing method, the server 120 can respond to an access request triggered by a target account for the account management service, and retrieve the target administrator account mapped to the account management service from a pre-stored account model. The account model includes the target administrator account pre-set in the account management service, the target administrator role pre-set for the target account, and the management permission information pre-set for the target account by the target administrator role. A single sign-on credential for the target account is generated based on the target administrator account. Based on the single sign-on credential, at least one target administrator role mapped to the target account is determined from the account model, and the management permission information pre-set for each target administrator role is obtained. The management permission information pre-set for each target administrator role is sent to the source server where the target account is located for permission information display.

[0100] Based on the above, this application can pre-map object accounts to administrator accounts, at least one administrator role among the administrator accounts, and corresponding management permissions in the account model of the account management service. This enables fine-grained authorization management of administrator accounts according to administrator roles and the management permissions under those roles. Thus, when a target object account needs to exercise management permissions in the account management service, single sign-on for the account management service can be completed directly using the target administrator account mapped to the target object account. This determines the administrator role and management permissions associated with the target object account. In this way, there is no need to directly assign the target administrator account to the target object, and the target object account can also exercise the management permissions granted in the account management service. This ensures that each object can be effectively empowered with the corresponding management permissions, improving the management efficiency and convenience of administrator accounts.

[0101] It should be noted that the above are just examples and can be applied to other data processing scenarios, which will not be elaborated here.

[0102] For ease of understanding, each step of the data processing method will be described in detail below. It should be noted that the order of the following embodiments is not intended to limit the preferred order of the embodiments.

[0103] In this application embodiment, the description will focus on the data processing device, specifically, the data processing device that can be integrated into a computer device, such as a terminal or server. See also Figure 2 , Figure 2 This is a flowchart illustrating the steps of the data processing method provided in this application embodiment. Taking the data processing device specifically integrated on a server as an example, the specific process when the processor on the server executes the program instructions corresponding to the data processing method is as follows:

[0104] 101. In response to an access request triggered by the target object account for the account management service, retrieve the target administrator account mapped to the account management service from the pre-stored account model.

[0105] Groups, organizations, institutions, or enterprises typically contain multiple individual members. These groups usually assign an object account to each of their members through a management system, or each member registers their own object account in the management system of the corresponding group. Each member's object account represents their identity information in the group's management system. Each member can apply for and complete corresponding daily tasks within the group through their respective object account. The group can also use the management system and each object account to achieve information management of its members, thereby improving the efficiency of collaboration and management among members within the group.

[0106] However, within a group, members can be divided into administrators and ordinary members. Administrators typically have management accounts and can use both administrator and object accounts simultaneously. Ordinary members generally only have object accounts within the group. Object accounts can log in to the group's self-service platform (defined as the "object account service" platform in this embodiment) to perform corresponding business tasks. Administrator accounts can be used to log in to the "account management service" platform to manage the management permissions and other matters of each member's object account. It should be noted that in some application scenarios, ordinary members need to use the administrator's management permissions, such as in scenarios involving promotions, changes in responsibilities, or business needs. In these cases, it is necessary to grant administrator management permissions to ordinary employees.

[0107] When granting administrative permissions to ordinary employees, related technologies aim to prevent abuse of unrelated permissions by assigning one administrator account to one administrator type, with each administrator type corresponding to a fixed scope of administrative permissions. This defines the administrative permissions for each administrator account. Administrator accounts are then assigned to ordinary employees to grant administrative permissions. However, this approach can lead to the abuse of administrator accounts. Furthermore, when different types of administrator permissions need to be granted to the same individual, multiple administrator accounts of different types must be assigned to that individual. When the same administrator account is assigned to multiple individuals, it can cause account conflicts and hinder the management of administrator account information.

[0108] To address the above issues, in this embodiment, a mapping is pre-established in the account model of the account management service between the target account and the administrator account, at least one administrator role among the administrator accounts, and the corresponding management permissions. This enables fine-grained authorization management of the administrator account based on the administrator role and the management permissions under the administrator role. Thus, when the target target account needs to exercise management permissions in the account management service, single sign-on for the account management service is completed directly according to the target administrator account mapped to the target target account. This determines the administrator role and management permissions associated with the target target account. In this way, there is no need to directly assign the target administrator account to the target object, and the target target account can also exercise the management permissions granted in the account management service. This ensures that each object can be effectively empowered with the corresponding management permissions, improving the management efficiency and convenience of the administrator account.

[0109] The account model includes the target administrator account pre-defined in the account management service for the target object account, the target administrator role pre-defined for the target object account by the target administrator account, and the management permission information pre-defined for the target object account by the target administrator role. Specifically, the account model can be understood as a data structure containing the account system corresponding to the account management service. It records and stores the administrator account mapped to each object account under the account system of the account management service, the administrator role granted to the corresponding object account by the administrator account, and the corresponding management function permissions associated with the current object account. Therefore, the account management service can be logged into subsequently through the administrator account mapped to the object account in the account model, in conjunction with single sign-on technology. It should be noted that the account model pre-configures the target administrator account for logging into the account management service, the target administrator role of the target account in the account management service based on the target administrator account, and the management permission information associated with the target administrator role in relation to the target account. This allows the target account to access the account management service through mapping and exercise the corresponding management permissions of the target administrator role in the account management service, based on the pre-configured target administrator account in the account model and single sign-on technology. In this way, there is no need to directly send the entity's administrator account to the target object for use, thus improving the management efficiency and convenience of the administrator account.

[0110] The account management service can be a platform accessed via an administrator account. This platform is primarily used to manage object accounts. Specifically, each administrator account can create administrator roles and management permissions within the account management service to manage object accounts and perform other tasks. It's important to note that object accounts cannot be directly used to log in to the account management service platform. However, with authorization from an administrator account, they can log in to the account management service using a mapped administrator account and exercise the corresponding management permissions within that administrator role through the administrator role authorized by that administrator account.

[0111] The target object account can be a non-administrator account currently logged into the "Object Account Service" platform. It can be understood as an account used by a target ordinary member in the target group. The target object account can be created in advance by the administrator based on the target object's attribute information and assigned to the target object, or it can be obtained by the target object itself by registering and applying based on the object information.

[0112] The target administrator account refers to the target account that can be directly logged into on the "Account Management Service" platform. The person holding the administrator account can be a member with management functions in the target group (collective), which can be understood as a non-ordinary member.

[0113] It should be noted that the "Object Account Service" platform and the "Account Management Service" platform are two different platforms. Object accounts can only be used to directly log in to the "Object Account Service" platform, not the "Account Management Service" platform. To enable object accounts to access the "Account Management Service" platform and exercise administrative privileges, it is necessary not only to establish a mapping between object accounts and administrator accounts, one or more administrator roles within those administrator accounts, and their administrative privileges, but also to treat the "Account Management Service" platform as an application within the Object Account Service platform, connecting to it via a protocol interface. Specifically, the computer device (such as a server) in this embodiment can be a server on the "Object Account Service" side, or a target sub-server in a distributed system. This target sub-server corresponds to the "Object Account Service" side, while the "Account Management Service" corresponds to another sub-server in the distributed system. The "Account Management Service" connects to this target sub-server via a protocol interface, i.e., it connects to the "Object Account Service" side. Therefore, the administrator account mapped to the object account can be used in conjunction with single sign-on technology to log in and access the "Account Management Service" platform through the protocol interface in the "Object Account Service" platform. In this way, there is no need to directly assign the target administrator account to the target object, and the target object account can also exercise the management permissions in the Account Management Service.

[0114] In some implementations, the target object account itself cannot be directly used to log in to the account management service. Instead, it needs to be based on the mapped target administrator account and the single sign-on account management service in the object account service platform. Therefore, the target object account needs to log in to the object account service first.

[0115] For example, before step 101, "responding to the access request triggered by the target object account for the account management service," the process may further include: responding to the login request triggered by the target object account on the object account service page, verifying the target object account, and obtaining a verification result; when the verification result is successful and it is confirmed that the target object account has the right to use the account management service, sending the application permission information of the account management service to the target object account. Therefore, "responding to the access request triggered by the target object account for the account management service" in step 101 could include: responding to the access request for the account management service triggered by the target object account based on application permission information.

[0116] The application permission information can be application permissions corresponding to the account management service. This includes, but is not limited to, the identifier, interface information, and / or service address of the account management service that forms an application mapping relationship with the target account, indicating that the target account can access and use the account management service corresponding to that identifier, interface information, or service address. It should be noted that the account management service is integrated into the target account service platform as an application or application function; therefore, the application permission information indicates that the target account has the permission to access and use the account management service.

[0117] Specifically, the target user can enter their account information (username and password) on the object account service page to log in. The server will then verify the username and password. If the verification is successful, the target user account has successfully logged in on the object account service side. Furthermore, the application permissions for each object account on the object account service side are pre-defined by the administrator through the account management service. Each object account's application permission information is pre-stored in the account model. Therefore, the system can determine from the account model whether the target object account has permission to access the account management service. If permission exists, the application permission information for the account management service is sent to the target object account. This allows the target object corresponding to the target account to subsequently request access to the account management service on the object account service platform.

[0118] Subsequently, since the target account itself does not possess an administrator account entity, but rather uses a mapping authorization method to map the administrator role and corresponding management permissions of an administrator account to the target account, and the target account service platform connects to the "Account Management Service" platform via a protocol interface, when a target account requests access to the account management service in the target account service platform, the system can look up the target administrator account mapped to the target account in the pre-stored account model according to the pre-built mapping relationship for the target account in the account model. This allows subsequent login and access to the account management service in the target account service platform using the mapped target administrator account and in conjunction with single sign-on technology.

[0119] In this embodiment, to avoid directly assigning administrator accounts to object accounts, an authorization mapping method is needed to pre-authorize the administrator account of the account management service, along with the administrator roles and management permissions within those administrator accounts, to the object accounts. This allows the object accounts to access the account management service and exercise management permissions. Based on this, one or more administrator roles need to be created within the administrator account. When creating each administrator role, corresponding management permissions need to be selected for each role. This binds the administrator account with an administrator role and the management permissions under that role. An account model is then created and generated based on this binding information. This allows for the subsequent pre-authorization of administrator accounts to object accounts, ensuring that the account model includes one or more administrator accounts mapped to the object accounts within the account management service's account system, administrator roles granted by the administrator accounts to the corresponding object accounts, and the management function permissions associated with those administrator roles for the corresponding object accounts.

[0120] In some implementations, an administrator account can create pre-configured administrator roles and select one or more management permissions supported by the administrator roles for configuration to create an account model. For example, before step 101, the method may further include: responding to a role creation request sent by an administrator account, obtaining a list of pre-configured administrator roles in the account management service; obtaining the administrator role to be created selected by the administrator account based on the list of administrator roles, and selecting the management permission to be created from the pre-configured management permissions supported by the administrator role to be created; binding the administrator account with the administrator role to be created and the management permission to be created to obtain the binding information of the administrator account; and creating an account model based on the binding information of the administrator account.

[0121] The list of administrator roles can contain one or more selectable administrator roles. These roles are pre-configured by the account management service platform and can be understood as being built into the platform. For example, these roles include, but are not limited to, audit administrators, business administrators, and system administrators. Furthermore, one or more administrator roles can be selected from the list to create roles for the current administrator account based on actual needs.

[0122] The binding information can be the association information between the current administrator account and administrator roles and permissions. This binding information includes the mapping relationship between the administrator account, administrator roles, and management permissions. It should be noted that this binding information can be a storage structure representing the mapping relationship, for example, stored in a key-value format. For example, it can be represented as "administrator account => administrator role => management permission," which can be understood as: using administrator role as the key, the value is management permission; using administrator account as the key, the value is administrator role; or the value is both administrator role and management permission. These are just examples and not intended as specific limitations.

[0123] It should be noted that one or more administrator accounts can be pre-registered and created in the account management service. For example, an administrator account can be created at any time before an administrator role is created, and each administrator account can create one or more administrator roles. Specifically, each object holding an administrator account can send a role creation request from its corresponding source end to the server corresponding to the account management service. This server can be a distributed system composed of multiple servers, with the account management service corresponding to one of the servers in the distributed system. Furthermore, the object account service and the account management service can also share a single server.

[0124] The server can respond to a role creation request, retrieve pre-configured administrator role information from the account management service, generate an administrator role list, and then send this list to the source server containing the corresponding administrator account for display. At this point, the administrator account can select one or more administrator roles to be created based on the list displayed on the source server and send the selected roles to the server.

[0125] Then, the server can obtain the administrator role to be created selected by the administrator account, and determine the pre-configured management permissions supported by the administrator role in the account management service. Based on these pre-configured management permissions, the server selects the management permissions corresponding to the current administrator role to be created. Specifically, this can be done by directly using these management permissions as the management permissions to be created for the current administrator role, or by sending these management permissions to the source server where the administrator account is located to select the management permissions to be created; this is not limited here. Afterwards, the administrator account is bound to the administrator role to be created and the selected management permissions to be created, obtaining the binding information of the administrator account. Based on the binding information of each administrator account, an account model is created. This account model can contain multiple administrator accounts and one or more administrator roles mapped to each administrator account, with each administrator role having corresponding management permissions.

[0126] In some implementations, custom administrator roles can be created for the administrator account, i.e., non-pre-defined administrator roles in the account management service. For example, if the administrator account has already been pre-registered and created, the process of creating an administrator role may also include: obtaining a role customization request sent by the administrator account, the role customization request carrying a role customization identifier; sending a set of management permissions supported by the account management service to the administrator account; obtaining at least one candidate management permission selected by the administrator account from the set of management permissions, and creating a custom administrator role corresponding to the role customization identifier based on at least one candidate management permission; binding the administrator account with the custom administrator role and the candidate management permission to obtain custom binding information; and updating the custom binding information to the account model.

[0127] The custom identifier for this role can be an identifier composed of corresponding characters, including Chinese characters, English characters, Arabic numerals, punctuation marks, and any other form of characters. Specifically, it can be an identifier composed of one or more forms of characters, representing the name of the custom-created administrator role. For example, "test", "application administrator", "application permission administrator", "device administrator", and "device permission administrator" are all administrator role identifiers. The above are just examples and are not limited here.

[0128] The set of management permissions can include multiple management permissions. It should be noted that the set of management permissions includes all management permissions supported by the account management service, and each management permission in the set is a set of all management permissions pre-configured in the account management service.

[0129] Specifically, each object holding an administrator account can send a role customization request from its corresponding source server to the server corresponding to the account management service. A description of the server can be found above and will not be repeated here. The server responds to the role customization request, determines that it carries a role customization identifier based on the request, and simultaneously obtains the pre-configured management permissions from the account management service to generate a set of management permissions. This set of management permissions is then sent to the source server containing the corresponding administrator account for display. At this point, the object with the administrator account can select one or more candidate management permissions based on the information in the set of management permissions displayed on the source server and send the selected one or more candidate management permissions to the server.

[0130] Next, the server can obtain one or more candidate management permissions selected by the administrator account. Based on these candidate management permissions, it creates an administrator role corresponding to the custom role identifier in the administrator account, thus generating a custom administrator role. Afterward, the administrator account is bound to the custom administrator role and the candidate management permissions to obtain custom binding information. This custom binding information can be the association information between the administrator account, administrator role, and management permissions. This binding information includes the mapping relationship between the administrator account, administrator role, and management permissions. For a description of this "custom binding information," please refer to the aforementioned description of "binding information." Subsequently, the custom binding information is updated in the account model so that the current administrator account in the account model is mapped to the custom administrator role.

[0131] The above describes how to create administrator roles within an administrator account. In addition, if an object account is granted administrator role creation permissions, it can also create administrator roles mapped to its object account independently. The creation method can refer to the above implementation method, and will not be repeated here.

[0132] In this embodiment of the application, for the administrator roles already created in each administrator account in the account model, and the management permissions associated with each administrator role, and by mapping, at least one administrator account, the administrator role in the administrator account, and the management permissions in the administrator role are pre-authorized and configured to the object account. In this way, in conjunction with single sign-on, even if the object of the object account does not hold the entity of the administrator account, it can still log in to access the account management service and exercise the management permissions corresponding to the administrator role in the account management service.

[0133] When assigning management permissions, you can first select an administrator account, then select an administrator role from the administrator account, and select one or more management permissions from the set of management permissions supported by the administrator role. Then, establish a mapping relationship between the object account to be assigned permissions and the selected administrator account, administrator role, and one or more management permissions to obtain permission assignment information, and add the permission assignment information to the account model.

[0134] In some implementations, candidate administrator accounts for authorization can be selected according to the administrator roles that need to be authorized, and the target account can be bound to the selected candidate administrator account and the management permissions under the administrator role. The resulting permission allocation information can then be added to the account model. For example, the specific permission allocation process may include: obtaining a permission allocation request, which carries the administrator role identifier to be assigned and the target account; searching the account model for candidate administrator accounts that are bound to the administrator role corresponding to the administrator role identifier; binding the target account to the candidate administrator account and the administrator role corresponding to the administrator role identifier to obtain permission allocation information, and adding the permission allocation information to the account model.

[0135] The administrator role identifier can be information representing the corresponding administrator role, specifically the globally unique identifier, name, code, or other information of the administrator role, used to distinguish different administrator roles.

[0136] The permission allocation information may include the binding information between the object account and the administrator account, the administrator role under the administrator account, and the management permissions under the administrator role, i.e., the mapping relationship information, to indicate that the administrator account, the administrator role under the administrator account, and the management permissions under the administrator role are authorized to the bound object account.

[0137] It should be noted that when a permission allocation request carries multiple administrator role identifiers, the permission allocation information includes mapping information between the object account and one or more administrator accounts, the multiple administrator roles corresponding to the relevant administrator accounts, and the corresponding management permissions. Similarly, when a permission allocation request carries multiple object accounts and one administrator role identifier, the permission allocation information includes mapping information between each object account and the same or different administrator accounts, the same administrator role corresponding to the relevant administrator accounts, and the corresponding management permissions. As for permission allocation requests carrying multiple object accounts and multiple administrator role identifiers, permission allocation is performed according to the correspondence between the object accounts and the administrator role identifiers.

[0138] Specifically, any object can request the allocation of administrative permissions to one or more object accounts. For example, taking a super administrator (or "super manager") as an example, a super administrator has a corresponding super administrator account. The super administrator can be the highest-ranking administrator in the object group or a specifically assigned administrator, and has the authority to allocate administrative permissions. The super administrator can directly log in to the account management service platform and send a permission allocation request to the account management service platform's server. After receiving the permission allocation request, the server should note that it can allocate rights and permissions according to administrator roles, improving the accuracy and efficiency of permission allocation. Therefore, when allocating administrative permissions to object accounts, the request can include an administrator role identifier to quickly and specifically specify the administrator role, without having to iterate through the administrator roles in each administrator account.

[0139] Furthermore, the server can determine the administrator role identifier and the target account to be assigned based on the permission allocation request. It then searches the account model according to the administrator role identifier to find candidate administrator accounts that have created the administrator role corresponding to the administrator role identifier. Further, after finding the candidate administrator account, the server binds the target account with the candidate administrator account and the administrator role corresponding to the administrator role identifier to obtain permission allocation information, which is then added to the account model. This achieves fine-grained allocation of the administrator role corresponding to the administrator role identifier of an administrator account to a target account, enabling the target account to access the account management service platform through the corresponding administrator account. Even if the administrator account has created multiple administrator roles in the account management service, the target account can only exercise the management permissions of the mapped administrator role within the account management service platform, effectively preventing the abuse of other management permissions within the administrator account and ensuring reliability.

[0140] In some implementations, the account model may contain multiple administrator accounts with the same administrator role. In this case, multiple administrator accounts with that administrator role can be identified from the account model based on the administrator role identifier. Then, a target administrator account can be selected for permission allocation based on the matching degree between the account level and the object attribute. For example, if there are multiple candidate administrator accounts, the process further includes: determining the account level corresponding to each candidate administrator account and determining the object attribute corresponding to the target account; selecting a target administrator account from the multiple candidate administrator accounts based on the account level and object attribute; binding the target administrator account and the administrator role corresponding to the administrator role identifier to the target account to obtain permission allocation information, and adding the permission allocation information to the account model.

[0141] Here, the account level can be a level coefficient of the corresponding administrator account, representing the account's level. It should be noted that administrator accounts can be differentiated by level, and the number of administrator roles that different levels of administrator accounts can create can differ. The higher the account level, the more administrator roles the account can create, and vice versa. Alternatively, different levels of administrator accounts can have different numbers of administrative permissions associated with the same administrator role. The higher the account level, the more administrative permissions the account can have associated with the same administrator role, and vice versa.

[0142] The object attribute can represent the attributes possessed by the object account, such as, but not limited to, the object's name, length of time in the object group, function, historical frequency of related operations, and role. Object attributes are used to assess the object account's past performance, such as the frequency of operations related to account management services, or the object account's management level within the object group. These indicators can be used to assess and measure the object account's importance within the overall object group.

[0143] It should be noted that each administrator account has a corresponding account level. During the permission allocation process, if multiple candidate administrator accounts with administrator roles corresponding to the administrator role identifier carried in the permission allocation request are searched from the account model, a target candidate administrator account can be selected. The administrator role in the target candidate administrator account is then mapped to authorize the allocation to the target account. Specifically, the process of selecting a target candidate administrator account includes: determining the account level corresponding to each candidate administrator account; obtaining the object attributes corresponding to the target account; specifically, obtaining the relevant attributes of the target account from the server's data records. Object attributes can reflect the object account's object function and / or its importance within its object group. Furthermore, based on one or more attribute indicators in the object attributes, the target account level can be matched from the account levels corresponding to each candidate administrator account. The target candidate administrator account corresponding to the target account level is then bound. Subsequently, the target account is bound to the target candidate administrator account and the administrator role corresponding to the administrator role identifier to obtain permission allocation information, which is then added to the account model.

[0144] In some implementations, each administrator account has a corresponding account level, and each account level is pre-associated with an operation frequency threshold for account management services. A target candidate administrator account can be determined by matching the target account level to the operation frequency threshold determined by the historical operation frequency based on object attributes. Therefore, the step "selecting a target candidate administrator account from multiple candidate administrator accounts based on account level and object attributes" can include: obtaining the pre-associated operation frequency threshold for each account level's operations related to account management services; determining the historical operation frequency of the object account for account management services based on object attributes; determining the target account level corresponding to the historical operation frequency based on the operation frequency threshold corresponding to each account level; and identifying the candidate administrator account corresponding to the target account level as the target candidate administrator account.

[0145] The operation frequency threshold can be a measure of the workload of a corresponding object account in performing operations related to account management services. This threshold can be a range, and it assesses the workload of the object account within the object group. Understandably, the amount of workload can reflect, to some extent, the importance or functional role of the object account within the object group. Therefore, when assigning permissions, each account level can correspond to an operation frequency threshold. The target account level is determined by matching the target operation frequency threshold with the historical operation frequency of the object account, and then the target candidate administrator account corresponding to the target account level is selected for permission assignment.

[0146] The operational items mentioned here can be routine tasks within the target group. Taking an enterprise as an example, these operational items can be business matters within the enterprise. For instance, these operational items could include designing business matters, creating business matters, reviewing business matters, testing business matters, and publishing business matters. The target account can perform these operations on the target account service platform, and the operations are recorded through the platform and stored on the server. Since the target account service platform connects to other business applications, such as account management services or other business service applications, and the application permissions for these applications need to be authorized through the account management service, the account management service can manage the target account's operational permissions for the above business matters. These business matters belong to the operational items of the account management service.

[0147] Specifically, after determining the account level of each candidate administrator account, a pre-defined operation frequency threshold for account management services is obtained for each account level. This threshold is associated with each account level to allocate management permissions between different account levels. Further, based on object attributes, the frequency of operations performed by the object account on account management services over historical time is calculated. The historical operation frequency is obtained by comparing the ratio of the operation frequency to the historical duration. This historical operation frequency is then compared with the operation frequency threshold corresponding to each account level to determine the target operation frequency threshold. This matching process can use the operation frequency threshold matched by the historical operation frequency as the target operation frequency threshold. If the current account level lacks a matched operation frequency threshold, the endpoint of the threshold closest to the object account's historical operation frequency can be selected as the target operation frequency threshold. Finally, the target account level is determined based on the target operation frequency threshold, and a target candidate administrator account is selected from multiple candidate administrator accounts based on the target account level for mapping and authorization. Therefore, the workload of the target account for each business matter in the historical time can be used as the basis for assessing the importance or function of the target account in the target group, so as to select target candidate administrator accounts of appropriate account level for permission allocation.

[0148] In some implementations, object attributes may include the job level of the object account within the object group. This job level may represent the management role attribute of the object account within the object group, with different management role attributes corresponding to different management levels. For example, the step "selecting a target candidate administrator account from multiple candidate administrator accounts based on account level and object attributes" may include: determining the target management level of the object account in the account management service according to the object attributes; determining the target account level corresponding to the target management level according to the correspondence between management levels and account levels contained in a preset management level table; and determining the candidate administrator account corresponding to the target account level as the target candidate administrator account.

[0149] The target management level can be understood as the functional level of the object account within the object group, and can also reflect the importance of the object account within the object group. Since the account management service can be used by administrators to manage various aspects of information about ordinary members, the relevant information of ordinary members' object accounts can be recorded in the account management service platform, such as the target management level, name, length of time in the object group, function, historical number of times related to operations, and functional role of the object account.

[0150] It should be noted that after determining the account level of each candidate administrator account, the target management level of the target account can also be determined, so as to select the target candidate administrator account corresponding to the target account level for permission allocation based on the target management level.

[0151] Specifically, object attributes can include the target management level of the object account in the account management service. This target management level can be understood as the functional level of the object account within the object group. Based on the correspondence between management levels and account levels contained in the preset management level table, the target account level corresponding to the current object account's target management level can be determined. Furthermore, the candidate administrator accounts corresponding to the target account level are identified as target candidate administrator accounts for mapping and authorization. In this way, the management level of the object account within the object group serves as the basis for assessing the object account's importance or function within the object group, thereby selecting target candidate administrator accounts with appropriate account levels for permission allocation and improving the rationality of administrator account permission allocation.

[0152] Using the above methods, the administrator role and management permissions of the administrator account can be pre-authorized to the object account through mapping. When a target object account requests access to the account management service in the object account service platform, the target administrator account mapped to the target object account can be found from the pre-stored account model according to the mapping relationship pre-built for the target object account in the account model. This allows the target administrator account to log in and access the account management service in the object account service platform in conjunction with single sign-on technology.

[0153] 102. Generate single sign-on credentials for the target object account based on the target administrator account.

[0154] In this embodiment, after finding the target administrator account mapped to the target object account from the account model, a single sign-on credential for the target object account can be generated based on the target administrator account. This single sign-on credential enables the target object account to access the account management service accessed in the object account service platform. Specifically, since the account management service is accessed through a protocol interface to the object account service platform, the target object account can directly access the account management service after logging into the object account service. Thus, there is no need to directly assign the entity's target administrator account to the target object account, and the target object account can still access the account management service, which is reliable.

[0155] The single sign-on credential can be a login pass for the target account's account service platform for account management services. This credential includes, but is not limited to, the target account's identity information, login status on the account service platform, login device address, the credential's generation time and validity period, the target administrator account, etc. Through the single sign-on credential, relevant information about the target account and target administrator account can be obtained in the corresponding account management service. For example, it can obtain at least one target administrator role mapped to the target account within the target administrator account, the management permissions associated with that target administrator role, and other information, which will not be elaborated here.

[0156] It should be noted that the object account service platform integrates an account management service. For a target object account to access the account management service, it needs to use the mapped target administrator account in conjunction with single sign-on (SSO) technology to generate SSO credentials for the account management service. Since these SSO credentials are generated based on the mapped target administrator account, they are only applicable to the target object account accessing the account management service. However, for other service applications integrated into the object account service platform, login credentials for the target object account need to be generated using those other application accounts.

[0157] In some implementations, when a previously valid single sign-on credential is detected, it can be used as the current single sign-on credential. Conversely, when a previously invalid single sign-on credential is detected, a decision on whether to generate a new single sign-on credential can be made based on the generation frequency of single sign-on credentials within a historical timeframe. For example, step 102 may include: obtaining the previously generated historical single sign-on credential for the target account based on the target account and the target administrator account, and determining the validity period of the historical single sign-on credential; when the validity period matches the current time, determining the historical single sign-on credential as the single sign-on credential for the target account; when the validity period does not match the current time, obtaining the historical generation frequency of single sign-on credentials for the target account within a historical timeframe; and when the historical generation frequency is less than a preset frequency upper limit threshold, generating a single sign-on credential for the target account based on the target administrator account.

[0158] The preset frequency limit can be a limit on the number of times any account can request to generate a single sign-on credential within a preset time period. For example, the frequency of generating a single sign-on credential cannot exceed 5 times / hour or 10 times / hour, and this limit can be determined based on actual circumstances. This is to improve the security of account management services.

[0159] It should be noted that, in order to improve the security of the account management service, the frequency of single sign-on access to the account management service by a target account within a specific time period can be limited. For example, the frequency of generating single sign-on credentials cannot exceed 5 times / hour or 10 times / hour, in order to avoid risks such as malicious occupation of computing resources and malicious use of permissions in the account management service.

[0160] Therefore, to minimize the frequency of single sign-on (SSO) credential generation, before generating SSO credentials based on the target administrator account mapped from the target account, the system first searches for the target account's previously generated historical SSO credentials, using both the target account and the target administrator account. The validity period of these historical SSO credentials is then determined from their information. This determines whether the current timeframe matches the validity period. If the validity period does not exceed the current timeframe, the two are considered a match, and the previously generated historical SSO credential can be used as the target account's SSO credential for accessing the account management service without needing to generate it again. However, if the validity period exceeds the current timeframe, the two are considered a mismatch, and the SSO credential needs to be regenerated. In this case, to improve the security of the account management service, the system queries the historical generation frequency of SSO credential requests based on the mapped target administrator account within a given timeframe. This historical generation frequency is then compared to a preset frequency upper limit threshold to decide whether to regenerate the SSO credential. Finally, if the historical generation frequency is greater than or equal to the preset frequency upper limit threshold, the generation of single sign-on credentials for the target account will be rejected. If the historical generation frequency is less than the preset frequency upper limit threshold, single sign-on credentials for the target account will be generated based on the target administrator account.

[0161] Therefore, when generating single sign-on credentials, the validity of the previous historical single sign-on credential is first determined. If it is valid, the previously generated single sign-on credential is directly used without the need to regenerate it. If a single sign-on credential needs to be regenerated, the generation frequency within the historical period needs to be determined. If the frequency is too high, it may be stolen or maliciously occupy computing resources, so the generation of the credential is refused. Only when the generation frequency within the historical period does not exceed the preset generation frequency threshold is a single sign-on credential generated, thereby improving the security of the account management service.

[0162] Using the above methods, after logging into the object account service, the target object account can generate a single sign-on credential for the target object account based on the target administrator account mapped to the target object account. This allows the target object account to directly access the account management service in the object account service. In this way, there is no need to directly assign the entity's target administrator account to the target object account, and the target object account can also access the account management service, which is reliable.

[0163] 103. Based on the single sign-on credentials, determine at least one target administrator role mapped to the target object account from the account model, and obtain the pre-set management permission information for each target administrator role for the target object account.

[0164] In this embodiment, after obtaining the single sign-on credential for the target account's account management service, the target administrator account can be used to obtain at least one target administrator role authorized for the target account in the account management service, as well as the pre-configured management permission information for each target administrator role for the target account. It should be noted that the account model can be understood as data belonging to the account management service. The above data can be determined from the account model to obtain the target administrator role and management permission information mapped to the target account, so that the management permission information can be fed back to the target account in the future.

[0165] The management permission information can be information representing one or more management permissions. The management permission information can be in the form of a list, a set, or other forms of data. Each management permission information can correspond to a target administrator role. That is, a management permission information contains one or more management permissions associated with the corresponding target administrator role. Each management permission can be represented by a permission identifier (such as name, number, creator information, etc.). There is no limitation here.

[0166] In some implementations, the account management service can be accessed using single sign-on credentials, and upon successful login, the target administrator role and management permissions mapped to the target account in the account management service can be verified. For example, step 103 may include:

[0167] (103.1) Log in to the account management service using the single sign-on credential and obtain the login result;

[0168] (103.2) When the login result is successful, determine at least one target administrator role that the target object account is mapped to in the account management service from the account model;

[0169] (103.3) Determine the pre-defined management permissions for each target administrator role for the target account.

[0170] The login result can be the verification result of the account management service accessed in the login object's account service platform based on the single sign-on credential. The login result includes login success and login failure. If the login is successful, it means that the login verification of the account management service based on the single sign-on credential has passed. If the login fails, it means that the login verification of the account management service based on the single sign-on credential has failed. Reasons for login failure include, but are not limited to, the single sign-on credential has expired, i.e., it has exceeded the validity period, or the login device address does not match, etc.

[0171] Specifically, to enhance the security of the account management service and ensure the legitimacy of access, after obtaining the single sign-on credentials for the target account, a login request can be made to the account management service using these credentials. This login request, based on the single sign-on credentials, indicates the target account's request to access the account management service platform. Login verification is performed during this process, resulting in a login result. Furthermore, if the login result indicates successful login to the account management service using the single sign-on credentials, at least one target administrator role mapped to the target account within the account management service is determined from the account model corresponding to the account management service. This role represents the target administrator roles authorized and open for the target account within the target administrator account. Additionally, the management permissions granted to each target administrator role for the target account within the account management service are determined, resulting in the management permission information for each target administrator role for the target account.

[0172] It should be noted that the management permission information configured for each target administrator role for the target account may include all or some of the management permissions supported by the corresponding target administrator role, depending on the actual situation. This primarily depends on the permission allocation information during the authorization mapping stage. If, after determining the administrator role, all the management permissions supported by the administrator role are associated with the target administrator role in the target administrator account mapped to the target account, then the management permission information corresponding to the target administrator role includes all the management permissions supported by the administrator role. If only some of the management permissions supported by the administrator role are associated, then the management permission information corresponding to the target administrator role will only include some of the management permissions, depending on the specific circumstances. This allows for fine-grained permission allocation management based on administrator roles and the management permissions under those roles, improving the accuracy and reliability of management permission allocation.

[0173] In some implementations, login verification can be performed based on the device address used when the target account requests access to the account management service, thus obtaining a login result. For example, step (103.1) may include: determining the device address to be verified on the source end where the target account is currently located based on single sign-on credentials; obtaining the target device address pre-stored for the target account, and performing login verification on the device address to be verified based on the target device address; when the device address to be verified matches the target device address, accessing the account management service based on the single sign-on credentials, and determining successful login as the login result; when the device address to be verified does not match the target device address, determining failed login as the login result.

[0174] The device address to be verified can be the device address used by the target account when requesting access to the account management service, i.e., the terminal device address. Since the account management service is integrated into the object account service as an application function, the device address to be verified can also be understood as the terminal device address of the target account when logging into and using the object account service platform. This device address to be verified can include, but is not limited to, Internet Protocol address (IP), Media Access Control address (MAC address), globally unique identifier of the current device, etc., etc., and is not limited here.

[0175] It should be noted that, to improve the security of the account management service, the access to the account management service must be legitimate, which may include, but is not limited to, the legitimacy of the device address. Therefore, when a target account requests access to the account management service, the device address of the target account at the time of the request can be verified, i.e., login verification is performed based on the device address, to ensure that the target account is requesting access to the account management service based on a legitimate device address, thereby improving the security of the account management service.

[0176] The target device address can be a pre-recorded device address. If the target account uses the source device corresponding to that device address to request login access to the account management service, it is considered legitimate. Specifically, device addresses can be declared and authorized through device management permissions or device authorization management permissions.

[0177] Specifically, single sign-on credentials can include the device address currently used by the target account. Based on the single sign-on credentials, the device address to be confirmed when the target account requests access to the account management service can be determined. Furthermore, in the initial mapping and authorization phase, when mapping and authorizing the target administrator account, target administrator role, and management permissions of the target administrator role to the target account, one or more target device addresses can be restricted when the target account accesses the account management service using the mapped target administrator account. These target device addresses can be valid device addresses. Further, the device address to be confirmed is compared with one or more target device addresses to determine if the device address to be confirmed is a valid address among the one or more target device addresses. If the device address to be confirmed matches the target device address, access to the account management service is requested based on the single sign-on credentials, and login success is determined as the login result; conversely, if the device address to be confirmed does not match the target device address, it means that the single sign-on credentials cannot be used to access the account management service, and login failure is determined as the login result.

[0178] For example, the device address to be verified when the target account requests access to the account management service can be verified to confirm its legitimacy. If the device address to be verified matches the target device address pre-declared for the target account, the device address to be verified is considered legitimate; otherwise, it is illegitimate. For instance, taking the entire enterprise as the target and the employee accounts of the enterprise's employees as the target accounts, assuming that the pre-declared target device addresses for the employee accounts include the company computer address and the employee's home computer address, and based on these two pre-declared target device addresses, the target administrator account, target administrator role, and management permissions are mapped to the employee accounts. If the employee account requests access based on either the company computer address or the employee's home computer address, it is considered a legitimate address, and the login verification passes. Conversely, if the request to access the account management service is made from any other private device address or a device address in a commercial location, it is considered an illegitimate device address, and the login verification fails.

[0179] Using the above methods, based on the single sign-on credential, one can request access to the account management service in the object account service platform without needing the target administrator account of the entity. In turn, one can obtain the target administrator role and management permission information mapped to the target object account from the account management service, so that the management permission information can be fed back to the target object account in the future.

[0180] 104. Send the pre-defined management permission information for each target administrator role to the source server where the target account is located to display the permission information.

[0181] In this embodiment of the application, after obtaining the target administrator role and management permission information mapped to the target object account, the management permission information associated with each target administrator role can be sent to the source end where the target object account is located. Specifically, the management permission information associated with each target administrator role can be merged to obtain a management permission information set, or merged to generate a management permission information list. The management permission information set or management permission information list is then sent to the source end where the target object account is located for rendering and displaying the permission information page, thereby showing the target administrator roles supported by the target object account in the account management service, as well as the management permissions corresponding to each target administrator role.

[0182] It should be noted that after sending the management permission information of each target administrator role to the source end where the target account is located for permission information display, the target management permissions selected by the target account based on the displayed permission information can be determined, and the relevant business requests sent by the target account can be executed according to the target management permissions.

[0183] In some implementations, after sending the management permission information of each target administrator role to the source server where the target account is located for permission information display, a management request sent by the target account based on the target management permissions can be responded to. For example, it may also include: obtaining the target management permissions selected by the target account based on the displayed permission information; and executing the target management request sent by the target account according to the target management permissions.

[0184] The target management permission can be any management permission in the permission information. For example, the target management permission can be application management permission, device management permission, human resources management permission, audit management permission, etc. The above are just examples and are not intended to limit the specific implementation method.

[0185] Specifically, after sending the pre-configured and pre-authorized management permission information for each target administrator role to the source server of the target account, the source server will render and display a permission information page for each target administrator role. This page shows the target administrator roles supported by the target account in the account management service, as well as the management permissions corresponding to each target administrator role. The target account can then select any target management permission from the permission information page. Specifically, it can click on a target management permission to enter the corresponding page, where it can trigger a business request—a target management request—to send to the server. The server can then respond to the target management request after verifying that the target account has valid authorization for the target management permission.

[0186] In some implementations, taking application management permissions as an example, the target account can request to add other applications based on application management permissions. For example, if the target management permissions include at least application management permissions, then the step "execute the target management request sent by the target account according to the target management permissions" may also include: obtaining a list of candidate applications currently added to the account management service according to the application management permissions; sending the list of candidate applications to the source server where the target account is located for rendering and displaying the application management page; obtaining at least one candidate application selected by the target account based on the application management page, and binding at least one candidate application to the target account in the account model.

[0187] The application management permissions can be the permissions to add, delete, or view the application functions of the target account itself, or the permissions to add, delete, or view the application functions of other accounts; there is no limitation here.

[0188] The application management page contains information on one or more applications corresponding to the list of candidate applications. For example, each application information may include the application's identifier, icon, business type, function description, etc., which are not limited here.

[0189] It should be noted that, assuming the target account selects application management permissions, the target management request can be a request to add application permissions in the account management service, a request to delete hospital permissions in the account management service, a request to view hospital permissions in the account management service, and so on.

[0190] Specifically, taking the addition of a new application function in the account management service as an example, after determining that the target object account has selected application management permissions, the application managed in the account management service is queried based on the application management permissions. These applications have been connected to the object account service platform. It should be noted that since the account management service can be understood as the highest-level service in the object group, the account management service can manage the permissions of each object account, such as the application permissions for application functions in the object account service platform, and the management permissions of the object account in the account management service.

[0191] Furthermore, based on the applications managed in the queried account management service, a candidate application list is established. Application management permissions can have permission levels, and the candidate application list corresponding to different permission levels contains different applications. For example, the higher the application management permission level, the more applications are included in the candidate application list, or different application management permission levels result in different applications included in the candidate application list. In this way, fine-grained management of application permissions can be achieved, allowing object accounts with different application permission levels to use different application permissions.

[0192] Furthermore, the list of candidate applications is sent to the source server where the target account resides for rendering and displaying the application management page. This allows the target account to select one or more candidate applications from the application management page. The server then retrieves the selected candidate applications and binds them to the target account in the account model. Thus, the target account has added accessible application functionality to its own account through application management permissions. This means that other applications, such as office software applications, have been added to the target account service platform, allowing login access. These applications are parallel to the "account management service," indicating that the target account supports using and accessing them. After successful login verification on the target account service platform, the target account is redirected to the target account service page, which displays multiple application functions that the target account can use and access. In this way, the target account can add accessible application functionality to its own account through application management permissions, improving the convenience of application management.

[0193] In some implementations, after a target object account adds or removes its application functionality in the object account service based on application management permissions, it can select a target application and perform single sign-on for the target application account of the target object account to access the target application. For example, after binding candidate applications to the target object account in the account model, the method further includes: obtaining multiple candidate applications bound to the target object account from the updated account model, and generating a target application information list based on the multiple candidate applications; determining the target application selected by the target object account based on the target application information list, and obtaining the target application account of the target object account for the target application from the updated account model; generating a target single sign-on credential for the target object account for the target application based on the target application account, and obtaining the application account information in the target application based on the target single sign-on credential.

[0194] It should be noted that the above process for "target application" can be referred to the login and access process of "account management service", which will not be repeated here.

[0195] Using the above methods, the management permission information associated with each target administrator role can be sent to the source server where the target account is located for rendering and displaying the permission information page. This will show the target administrator roles supported by the target account in the account management service, as well as the management permissions corresponding to each target administrator role, so that the target account can exercise the above permissions.

[0196] As can be seen from the overall description of the embodiments of this application, the embodiments of this application can, in response to an access request triggered by a target object account for the account management service, obtain the target administrator account mapped by the target object account for the account management service from a pre-stored account model; wherein, the account model includes the target administrator account pre-set in the account management service for the target object account, the target administrator role pre-set by the target administrator account for the target object account, and the management permission information pre-set by the target administrator role for the target object account; generate a single sign-on credential for the target object account based on the target administrator account; determine at least one target administrator role mapped by the target object account from the account model based on the single sign-on credential, and obtain the management permission information pre-set by each target administrator role for the target object account; and send the management permission information pre-set by each target administrator role for the target object account to the source end where the target object account is located for permission information display.

[0197] Based on this, this application can query the target administrator account mapped to the target account from the pre-created account model based on the target account's access request to the account management service. Then, it generates a single sign-on credential for the target account to access the account management service through the target administrator account. Next, it determines the administrator role and corresponding management permissions granted to the target account in the account management service through the single sign-on credential. Finally, it sends the granted administrator role and corresponding management permissions to the source end where the target account is located for permission information display.

[0198] Therefore, compared to existing technologies that empower individual objects with administrator privileges by assigning administrator accounts to individual objects or multiple objects, this application pre-maps object accounts to administrator accounts, at least one administrator role within the administrator account, and corresponding management permissions within the account model of the account management service. This enables fine-grained authorization management of administrator accounts based on administrator roles and the management permissions under those roles. Consequently, when a target object account needs to exercise management permissions in the account management service, single sign-on for the account management service is completed directly using the target administrator account mapped to the target object account. This determines the administrator role and management permissions associated with the target object account. Thus, there is no need to directly assign the target administrator account to the target object, and the target object account can still exercise the management permissions granted in the account management service. This ensures that each object can be effectively empowered with the corresponding management permissions, improving the management efficiency and convenience of administrator accounts.

[0199] Based on the methods described in the above embodiments, the following examples will provide further detailed explanations.

[0200] Figure 3This is a schematic flowchart of another step in the data processing method provided in the embodiments of this application. For ease of understanding, the embodiments of this application are combined with... Figure 3 Describe it.

[0201] In this embodiment, the description will be from the perspective of a data processing device, which can be integrated into a computer device such as a terminal or server. For example, when the processor on the computer device executes the program corresponding to the data processing method, the specific flow of the data processing method is as follows:

[0202] 201. In response to the login request triggered by the target object account on the object account service page, verify the target object account and obtain the verification result.

[0203] In this embodiment, two types of accounts are included: object accounts and administrator accounts. Object accounts are used to log in to the "Object Account Service" platform, while administrator accounts can be used to log in to the "Account Management Service" platform. The "Object Account Service" platform and the "Account Management Service" platform are two different platforms. Object accounts can only be used to directly log in to the "Object Account Service" platform and cannot be used to log in to the "Account Management Service" platform. To enable object accounts to access the "Account Management Service" platform and exercise management privileges, it is necessary not only to establish a mapping between object accounts and administrator accounts, one or more administrator roles within the administrator accounts, and management privileges, but also to treat the "Account Management Service" platform as an application within the object account service platform and connect to it via a protocol interface. Specifically, the computer device (such as a server) in this embodiment can be a server on the "Object Account Service" side or a target sub-server in a distributed system. This target sub-server corresponds to the "Object Account Service" side, while the "Account Management Service" corresponds to another sub-server in the distributed system. The "Account Management Service" connects to this target sub-server via a protocol interface, i.e., connects to the "Object Account Service" side. Therefore, the administrator account mapped to the object account can be used in conjunction with single sign-on technology to log in and access the "Account Management Service" platform through the protocol interface in the "Object Account Service" platform. In this way, it is not necessary to directly assign the target administrator account of the entity to the target object account, and the target object account can also exercise the management permissions in the Account Management Service.

[0204] Therefore, the target can enter the target account on the target account service page, that is, enter the corresponding username and password of the target account to log in on the target account service page. At this time, the server will verify the login by verifying the username and password of the target account and obtain the verification result.

[0205] 202. When the verification result is successful and it is confirmed that the target account has the right to use the account management service, the application permission information of the account management service will be sent to the target account.

[0206] In this embodiment, if the verification result is successful, it indicates that the target object account has successfully logged in on the object account service side. Furthermore, the application permissions for each object account on the object account service side are pre-set by the administrator through the account management service. The application permission information for each object account is pre-stored in the account model. Therefore, it can be determined from the account model whether the target object account has the permission to access the account management service. If the permission exists, the application permission information of the account management service is sent to the target object account, enabling the target object account to request access to the account management service.

[0207] 203. In response to an access request to the account management service triggered by the target object account based on application permission information, retrieve the target administrator account mapped to the account management service from the pre-stored account model.

[0208] In this embodiment, since the target account itself does not have a physical administrator account, it only maps the administrator role and corresponding management permissions of an administrator account to the target account through a mapping authorization method. Furthermore, the target account service platform connects to the "Account Management Service" platform via a protocol interface. Therefore, when a target account requests access to the account management service in the target account service platform, the target administrator account mapped to the target account can be found from the pre-stored account model according to the pre-built mapping relationship for the target account in the account model. This allows subsequent login and access to the account management service in the target account service platform using the mapped target administrator account and in conjunction with single sign-on technology.

[0209] 204. Generate single sign-on credentials for the target object account based on the target administrator account.

[0210] In this embodiment, after finding the target administrator account mapped to the target object account from the account model, a single sign-on credential for the target object account can be generated based on the target administrator account. This single sign-on credential enables the target object account to access the account management service accessed in the object account service platform. Specifically, since the account management service is accessed through a protocol interface to the object account service platform, the target object account can directly access the account management service after logging into the object account service. Thus, there is no need to directly assign the entity's target administrator account to the target object account, and the target object account can still access the account management service, which is reliable.

[0211] 205. Based on the single sign-on credentials, determine at least one target administrator role mapped to the target object account from the account model, and obtain the pre-set management permission information for each target administrator role for the target object account.

[0212] In this embodiment, after obtaining the single sign-on credential for the target account's account management service, the target administrator account can be used to obtain at least one target administrator role authorized for the target account in the account management service, as well as the management permission information associated with each target administrator role. It should be noted that the account model can be understood as data belonging to the account management service. The above data can be determined from the account model, thereby obtaining the target administrator role and management permission information mapped to the target account, so that the management permission information can be fed back to the target account in the future.

[0213] It should be noted that the management permission information included in each target administrator role can be all or part of the management permissions supported by that target administrator role, depending on the actual situation. This primarily depends on the permission allocation information during the authorization mapping stage. If, after determining the administrator role, all the management permissions supported by the administrator role are associated with the target administrator role in the target administrator account mapped to the target object account, then the management permission information corresponding to the target administrator role includes all the management permissions supported by the administrator role. If only some of the management permissions supported by the administrator role are associated, then the management permission information corresponding to the target administrator role only includes some of the management permissions, depending on the specific circumstances. This allows for fine-grained permission allocation management based on administrator roles and the management permissions under those roles, improving the accuracy and reliability of management permission allocation.

[0214] 206. Send the pre-set management permission information for each target administrator role to the source server where the target account is located to display the permission information.

[0215] In this embodiment of the application, after obtaining the target administrator role and management permission information mapped to the target object account, the management permission information associated with each target administrator role can be sent to the source end where the target object account is located. Specifically, the management permission information associated with each target administrator role can be merged to obtain a management permission information set, or merged to generate a management permission information list. The management permission information set or management permission information list is then sent to the source end where the target object account is located for rendering and displaying the permission information page, thereby showing the target administrator roles supported by the target object account in the account management service, as well as the management permissions corresponding to each target administrator role.

[0216] It should be noted that after sending the pre-configured management permission information for each target administrator role to the source end where the target account is located for permission information display, the target management permissions selected by the target account based on the displayed permission information can be determined, and the relevant business requests sent by the target account can be executed according to the target management permissions.

[0217] To facilitate understanding of the embodiments of this application, specific application scenario examples will be used to describe the embodiments of this application. Specifically, the application scenario example will be described by performing the above steps 201-206.

[0218] It should be noted that this data processing method applies to object account service systems. Specifically, an object account can be a regular user account within the object account service system, while an administrator account can be understood as the super account of the account management service connected to the object account service system, i.e., a "super administrator," capable of managing various permissions for any object account, such as application permissions within the object account service system and administrative permissions within the account management service. For example, an administrator account and its administrator role can be mapped to an object account to grant the object account administrative permissions within the account management service. Furthermore, after an object account logs into the object account service system, if it chooses to log into the account management service, it can use the administrator account to log in via single sign-on and obtain the mapped administrator role to exercise the administrative permissions of that role. This eliminates the need to directly assign an administrator account to an object account to use administrator permissions, effectively preventing the abuse of administrator accounts. The following is a case study illustrating this data processing method:

[0219] I. A brief introduction to this data processing scenario is as follows:

[0220] In application products that differentiate between users and administrators, there is often a need to associate users with administrator permissions. This means that after logging in, users should be able to exercise administrator privileges, i.e., be authorized to have administrator privileges. Furthermore, a single user may have multiple types or scopes of administrator permissions. If the administrator in the product is a single account entity, it will be impossible to perform fine-grained authorization actions.

[0221] For example, related technologies directly specify the administrator's permissions when creating an administrator account, and directly specify the account type. This can be understood as binding the administrator type, management permission scope, and administrator account together. Thus, when administrator permissions need to be granted to users, while this makes the administrator account's administrator type and permission scope clear and unambiguous, it results in low functional scalability. Furthermore, physical administrator accounts are prone to abuse and are not conducive to the granting and adjustment of multiple permission types.

[0222] Unlike related technologies, this data processing scenario presents the following example: A general model for administrator role splitting and management is proposed. This model bridges the gap between third-party application accounts, object accounts, and administrator accounts. The object account can be an Identity and Access Management (IAM) user, and the administrator account can be an IAM administrator, with centralized control implemented within the IAM product. Furthermore, combined with the application's single sign-on method, when logging into the object account service system, users can log into the "console" (i.e., the account management service platform) through the mapped administrator account to execute the permissions and functions granted to the administrator account.

[0223] II. The specific implementation process of this data processing scenario example is as follows:

[0224] This data processing scenario example introduces the concept of administrator roles, separating administrator accounts, roles, and permissions. This allows a single administrator account to be associated with multiple administrator roles, and a single role to be associated with various permissions. By combining this with single sign-on (SSO) technology using object accounts, single sign-on on the self-service side (object account service platform) enables login to the console (i.e., the account management service platform), carrying the administrator role's permission information. This login method prevents administrator account leakage. It's important to note that one administrator account can map to multiple object accounts, allowing multiple object accounts to share a single administrator account and its associated administrator roles and permissions. Furthermore, one administrator account can be bound to multiple administrator roles, greatly increasing administrator flexibility, enabling fine-grained permission control, and enhancing the flexibility of the administrator permission model.

[0225] To facilitate understanding, the following sections will explain the processes of administrator roles, binding administrator accounts to administrator roles, mapping object accounts to administrator accounts, and logging in to and using administrator accounts with object accounts, with reference to accompanying diagrams. Details are as follows:

[0226] Figure 4 This is an example image of a page showing the list of administrator roles in the account management service provided in this application embodiment. (Combined with...) Figure 4As shown, multiple administrator roles are illustrated, such as "test, audit administrator, device authorization administrator, device administrator, application authorization administrator, application administrator, user administrator, authentication domain administrator, system administrator, super administrator," etc. The attribute information corresponding to each administrator can include role type, which refers to a preset role or a custom role. Specifically, role types include preset default roles and custom roles. Preset roles indicate that the functional permissions of this type of role are default, while custom administrator roles can customize and edit the functional permissions that can be accessed under this administrator role.

[0227] In the account management service, after logging in with an administrator account, you can create, edit, copy, view, and delete various administrator roles. Editing can refer to editing the management permissions and functions corresponding to the administrator role. Copying can refer to copying the administrator role and its corresponding management permissions. Deleting can refer to deleting the administrator role or its corresponding permissions. There are no restrictions here.

[0228] Figure 5 This is an example diagram illustrating an editing scenario for the administrator role's management permissions, provided in an embodiment of this application. (Combined with...) Figure 5 As shown, for the administrator role with the role name "Management Role," the management permission information for this administrator role can be edited, such as editing "Monitoring Dashboard" and "Authentication Domain Management." The permissions for "Authentication Domain Management" can include viewing and editing. This authentication domain management permission can be further subdivided functionally into "User Management," "Password Rule Settings," "Configuration Management," "Notification Channel Management," "Authentication Source Management," "Upstream Identity Source Synchronization," and "Downstream Data Source Supply," etc. Each permission function has corresponding usage permissions, such as "View, Add, Edit, Delete." The above is an example of the administrator role's management permissions and further subdivided functional permissions.

[0229] Figure 6 This is an example image of a page displaying the administrator account list in the account management service of this application embodiment. (Combined with...) Figure 6As shown, after logging into the account management service with an administrator account, you can create an administrator account through the "Create Administrator" button. This can be understood as one of the ways to create an administrator account, which requires the consent of an existing administrator account before a new administrator account can be created. As shown in the figure, the page includes "admin", "test", and "111", which are all administrator accounts. The attributes of each administrator account can include multiple attributes such as account name, account type, account status, authorized role, bound role, authorizer, creation time, latest update time, and operations. "Authorized role" can be the administrator roles created by this administrator account. "Authorizer" can be the administrator who authorized and agreed to create the current administrator account, i.e., the authorized administrator or super administrator. "Account status" can be the availability status of the current administrator account, which is not limited here.

[0230] Figure 7 This is an example image of the administrator account creation page provided in an embodiment of this application. (Combined with...) Figure 7 As shown, during the administrator account creation process, the creator can enter the "administrator account name," "account password," "email," and "description," and set the authorization information for the administrator account, such as user data, application data, supported administrator roles, etc. One administrator account can be bound to multiple administrator roles; when multiple administrator roles exist, the actual effective set is the union of permissions for all roles.

[0231] Figure 8 This is an example diagram illustrating a scenario where an object account is mapped to an administrator account, as provided in an embodiment of this application. (Combined with...) Figure 8 As shown, the administrator account "test" is bound to the actual object account "New User 1". It's important to note that the administrator account "test" can be mapped to multiple object accounts. For example, the administrator account "test" can be mapped to both the object accounts "New User 1" and "New User". This allows multiple object accounts to share the same administrator account permissions. It's crucial to understand that this "mapping" refers to "authorization," specifically granting permissions to the object accounts "New User 1" and "New User" within the "authentication domain scope".

[0232] Figure 9 This is an example diagram of the application permission page for an object account in the object account service, according to an embodiment of this application. (Combined with...) Figure 9 As shown, after completing account authentication in the object account service platform, the user is redirected to the application permissions page within the object account service. This page displays the application permissions granted to the object account. Figure 9The page displays the application permissions of the object account "New User 1", including the permissions of the "CAS" application, the "OIDC" application, and the "Console" application. In this page, the "Console" application refers to the application terminal or interface protocol component of the account management service platform. The "CAS" application, the "OIDC" application, and the "Console" application can also be understood in this way, and no limitation is made here.

[0233] Figure 10 Example page diagrams of the account management service provided in this application embodiment. (In conjunction with...) Figure 9 and Figure 10 As shown, after an object account completes account authentication in the object account service platform, it is redirected to the application permissions page of the object account service. When the object corresponding to the object account selects the "Console" application on the application permissions page, the mapping relationship previously completed in the console (the platform of the account management service) will be used. The administrator account's permissions will be used to log in to the console (the platform of the account management service) and display the corresponding resources, such as the resources for the "Monitoring Dashboard" permission. The permission resources for this monitoring dashboard correspond to data such as "Global Overview," "Health Status Statistics," and "User Count Statistics." For the "Authentication Domain Management" permission, the corresponding permission resources can be determined according to the previously mapped permissions, which will not be elaborated here.

[0234] Figure 11 This is an example diagram of the administrator account mapping management architecture provided in an embodiment of this application. (Combined with...) Figure 11 As shown, this can be understood as including an object account service platform and a console (account management service platform). The object account service platform is used by ordinary object accounts to log in. The account management service platform can be understood as a human resource management system. The account management service platform is generally used by administrator accounts to log in and manage ordinary object accounts. If an ordinary object account wants to exercise some administrator privileges in the "console", it needs to use a mapping method to map the administrator role and management privileges of the administrator account to the ordinary object account. Thus, after the ordinary object account completes account authentication in the object account service platform, it is redirected to the application permissions page in the object account service. The ordinary object account can enter the "console" through single sign-on. The "console" page will display the resources of the administrator role and management privileges mapped to the ordinary object account. The ordinary object account can choose to exercise the management privilege resources.

[0235] Combination Figure 11As shown, the specific process is as follows: First, the object account "demouser01" is a regular user on the object account service platform and can log in to the console through the administrator account "admin01". To improve the security and scalability of management permissions, enhance the management effectiveness of the administrator account, and prevent account entity and password leakage, a mapping is established between the object account "demouser01" and the administrator account "admin01". Specifically, the administrator role and management permissions of the object account "demouser01" and the administrator account "admin01" are mapped to achieve management permission authorization. Then, by logging into the server (i.e., the object account service platform), the page displays an application entry for "Console" (i.e., account management service). Clicking it allows single sign-on to the console, using the mapped admin01 account to complete console verification and log in. Finally, the administrator account "admin01" can use the management permissions of the mapped administrator role.

[0236] It should be noted that, as Figure 11 As shown, when the object account "demouser01" logs in through the mapped administrator account "admin01", the administrator roles it has in the "Console" include "Administrator", "Custom Role 1" and "Custom Role 2". Since multiple roles are bound, the corresponding management permissions can be the union of the management permissions of the multiple bound administrator roles. The relationship between administrator accounts and administrator roles can be manually added through the preset administrator roles in the "Console" or imported in batches from the user side.

[0237] Figure 12 This is a timing flowchart illustrating a data processing scenario example provided in the embodiments of this application. To better understand the above data processing scenario example, it will be combined with... Figure 12 This data processing scenario example is introduced, mainly including the configuration phase and the login phase, as detailed below:

[0238] (1) During the configuration phase, the specific process is as follows:

[0239] (1.1) Application authorization requires creating an application that allows single sign-on for the object account in order to authorize the application permissions to the object account; for example, the administrator can add application permissions for the object account in the "Console".

[0240] (1.2) Account mapping: Specifically, an administrator account can be mapped to an object account to complete the administrator account mapping.

[0241] (1.3) Authorize roles: Authorize the administrator role in the administrator account to the object account, thus authorizing the administrator role for the object account.

[0242] (2) The specific process during the login phase is as follows:

[0243] (2.1) User login: Any object can log in using the object account on the login page of the object account service platform.

[0244] (2.2) User authentication: Specifically, object account authentication is performed based on the object account information entered by the user on the login page of the object account service platform.

[0245] (2.3) Permission check: Specifically, after completing the account and password authentication of the object account, check the application permissions that the object account currently supports for single sign-on, so as to display the applications that can be single sign-on to the page where the object account is located.

[0246] (2.4) Select an application. Specifically, users can select one of the applications displayed on the page to perform single sign-on. For example, they can select the "Console" application entry.

[0247] (2.5) Check the mapping. For example, for the "Console" application selected by the user, check the account mapping to determine which administrator account in the console application is being mapped, i.e., find the mapped administrator account.

[0248] (2.6) Confirm application account. Specifically, the user can select an application account. For example, the user can select the administrator account of the "Console" application to log in. If there are multiple application account mappings, the user can be given the function to select the specific account to log in.

[0249] (2.7) Generate single sign-on credentials. If Xu follows the specific application account to log in, the single sign-on process is initiated to generate single sign-on credentials (token).

[0250] (2.8) Redirecting the application: Specifically, redirecting the user to the corresponding third-party application based on the single sign-on credential (token), i.e., the application the user chooses to log in to, such as the "Console" application.

[0251] (2.9) Verify the single sign-on credential token and obtain object information related to the application account.

[0252] (2.10) Obtain the role information of the object account in the current application service. For example, taking "Console" as an example, obtain the information of the administrator role of the object account under the "Administrator Account" mapping.

[0253] (2.11) Display relevant application functions and information based on account-related object and role information. For example, taking "Console" as an example, display the administrator role, management permissions and related information granted to the object account in "Console".

[0254] By executing the above data processing scenario examples, the following effects can be achieved: Based on the administrator role splitting and management model, the relationship between third-party application accounts, object accounts, and administrator accounts is established. Simultaneously, combined with the application's single sign-on method, when logging into the object account service system, users can log into the "console" (i.e., the account management service platform) through the mapped administrator account to execute the permissions and functions possessed by the administrator account.

[0255] As can be seen from the above, the embodiments of this application can be based on this. Based on the target object account's access request to the account management service, this application can query the target administrator account mapped to the target object account from the pre-created account model. Then, a single sign-on credential for the target object account to the account management service is generated through the target administrator account. Next, the administrator role and corresponding management permissions granted to the target object account in the account management service are determined through the single sign-on credential. Finally, the granted administrator role and corresponding management permissions are sent to the source end where the target object account is located for permission information display. Therefore, compared to existing technologies that empower individual objects with administrator privileges by assigning administrator accounts to individual objects or multiple objects, this application pre-maps object accounts to administrator accounts, at least one administrator role within the administrator account, and corresponding management permissions within the account model of the account management service. This enables fine-grained authorization management of administrator accounts based on administrator roles and the management permissions under those roles. Consequently, when a target object account needs to exercise management permissions in the account management service, single sign-on for the account management service is completed directly using the target administrator account mapped to the target object account. This determines the administrator role and management permissions associated with the target object account. Thus, there is no need to directly assign the target administrator account to the target object, and the target object account can still exercise the management permissions granted in the account management service. This ensures that each object can be effectively empowered with the corresponding management permissions, improving the management efficiency and convenience of administrator accounts.

[0256] For details on the implementation of each of the above steps, please refer to the previous examples, which will not be repeated here.

[0257] To facilitate better implementation of the data processing method provided in the embodiments of this application, the embodiments of this application also provide an apparatus based on the above-described data processing method. The meanings of the terms used are the same as in the data processing method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0258] Please see Figure 13 , Figure 13This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device is integrated into the computer equipment of this application, and the data processing device may include an acquisition unit 401, a generation unit 402, a determination unit 403, and a sending unit 404.

[0259] The acquisition unit 401 is used to retrieve the target administrator account mapped to the account management service from the pre-stored account model in response to the access request triggered by the target object account for the account management service.

[0260] The account model includes the target administrator account pre-set in the account management service for the target object account, the target administrator role pre-set for the target object account by the target administrator account, and the management permission information pre-set for the target object account by the target administrator role.

[0261] The generation unit 402 is used to generate single sign-on credentials for the target object account based on the target administrator account;

[0262] The determining unit 403 is used to determine at least one target administrator role mapped to the target object account from the account model based on the single sign-on credential, and to obtain the pre-set management permission information of each target administrator role for the target object account;

[0263] Sending unit 404 is used to send the pre-set management permission information of each target administrator role for the target object account to the source end where the target object account is located for permission information display.

[0264] In some implementations, the determining unit 403 is further configured to: log in to the account management service based on the single sign-on credential and obtain a login result; when the login result is successful, determine at least one target administrator role mapped to the target object account in the account management service from the account model; and determine the management permission information preset for each target administrator role for the target object account.

[0265] In some implementations, the determining unit 403 is further configured to: determine the address of the device to be confirmed at the source end where the target object account is currently located based on the single sign-on credentials; obtain the target device address pre-stored for the target object account, and perform login verification on the address to be confirmed based on the target device address; when the address to be confirmed matches the target device address, access the account management service based on the single sign-on credentials, and determine the login success as the login result; when the address to be confirmed does not match the target device address, determine the login failure as the login result.

[0266] In some implementations, the generation unit 402 is further configured to: obtain the historical single sign-on credential previously generated by the target object account based on the target object account and the target administrator account, and determine the validity period of the historical single sign-on credential; when the validity period matches the current time, determine the historical single sign-on credential as the single sign-on credential for the target object account; when the validity period does not match the current time, obtain the historical generation frequency of the single sign-on credential for the target object account within the historical time period; when the historical generation frequency is less than a preset frequency upper limit threshold, generate the single sign-on credential for the target object account based on the target administrator account.

[0267] In some embodiments, the data processing apparatus further includes a creation unit, configured to: in response to a role creation request sent by an administrator account, obtain a list of pre-configured administrator roles in the account management service; obtain the administrator role to be created selected by the administrator account based on the list of administrator roles, and select the management permission to be created from the pre-configured management permissions supported by the administrator role to be created; bind the administrator account with the administrator role to be created and the management permission to be created to obtain the binding information of the administrator account; and create an account model based on the binding information of the administrator account.

[0268] In some embodiments, the data processing apparatus further includes an update unit, configured to: obtain a role customization request sent by an administrator account, the role customization request carrying a role customization identifier; send a set of management permissions supported by the account management service to the administrator account; obtain at least one candidate management permission selected by the administrator account from the set of management permissions, and create a custom administrator role corresponding to the role customization identifier based on the at least one candidate management permission; bind the administrator account with the custom administrator role and the candidate management permission to obtain custom binding information; and add the custom binding information to the account model.

[0269] In some embodiments, the data processing apparatus further includes a permission allocation unit, configured to: obtain a permission allocation request, the permission allocation request carrying an administrator role identifier to be allocated and an object account; search for a candidate administrator account in the account model that is bound to an administrator role corresponding to the administrator role identifier; bind the object account to the candidate administrator account and the administrator role corresponding to the administrator role identifier to obtain permission allocation information, and add the permission allocation information to the account model.

[0270] In some embodiments, the data processing apparatus further includes a login unit, configured to: verify the target object account in response to a login request triggered by the target object account on the object account service page, and obtain a verification result; when the verification result is successful and it is confirmed that the target object account has the right to use the account management service, send the application permission information of the account management service to the target object account; and respond to the access request of the account management service triggered by the target object account based on the application permission information.

[0271] In some embodiments, the data processing apparatus further includes an execution unit for: obtaining the target management permissions selected by the target object account based on the management permission information in the permission information page; and executing the target management request sent by the target object account according to the target management permissions.

[0272] In some implementations, the target management permissions include at least application management permissions. The execution unit is also used to: obtain a list of candidate applications currently added to the account management service according to the application management permissions; send the list of candidate applications to the source end where the target object account is located for rendering and displaying the application management page; obtain at least one candidate application selected by the target object account based on the application management page, and bind at least one candidate application to the target object account in the account model.

[0273] As can be seen from the above, the embodiments of this application can be based on this. Based on the target object account's access request to the account management service, this application can query the target administrator account mapped to the target object account from the pre-created account model. Then, a single sign-on credential for the target object account to the account management service is generated through the target administrator account. Next, the administrator role and corresponding management permissions granted to the target object account in the account management service are determined through the single sign-on credential. Finally, the granted administrator role and corresponding management permissions are sent to the source end where the target object account is located for permission information display. Therefore, compared to existing technologies that empower individual objects with administrator privileges by assigning administrator accounts to individual objects or multiple objects, this application pre-maps object accounts to administrator accounts, at least one administrator role within the administrator account, and corresponding management permissions within the account model of the account management service. This enables fine-grained authorization management of administrator accounts based on administrator roles and the management permissions under those roles. Consequently, when a target object account needs to exercise management permissions in the account management service, single sign-on for the account management service is completed directly using the target administrator account mapped to the target object account. This determines the administrator role and management permissions associated with the target object account. Thus, there is no need to directly assign the target administrator account to the target object, and the target object account can still exercise the management permissions granted in the account management service. This ensures that each object can be effectively empowered with the corresponding management permissions, improving the management efficiency and convenience of administrator accounts.

[0274] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0275] See Figure 14 , Figure 14 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. It includes a structural block of a portion of the terminal 110 implementing this embodiment. The terminal 110 includes: a radio frequency (RF) circuit 510, a memory 515, an input unit 520, a display unit 540, a sensor 550, an audio circuit 560, a wireless fidelity (WiFi) module 570, a processor 580, and a power supply 590, among other components. Those skilled in the art will understand that... Figure 14 The terminal 110 structure shown does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0276] The RF circuit 510 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 580; in addition, it transmits uplink data to the base station.

[0277] The memory 515 can be used to store software programs and modules. The processor 580 executes various functional applications and data processing of the terminal by running the software programs and modules stored in the memory 515.

[0278] The input unit 520 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 520 may include a touch panel 531 and other input devices 532.

[0279] The display unit 540 can be used to display input or provided information, as well as various menus of the terminal. The display unit 540 may include a display panel 541.

[0280] Audio circuit 560, speaker 561, and microphone 562 provide an audio interface.

[0281] In this embodiment, the processor 580 included in the terminal 110 can execute the data processing method of the previous embodiment.

[0282] The terminal 110 in this application embodiment includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. This invention embodiment can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0283] See Figure 15 , Figure 15 This is a schematic diagram of the server structure provided in an embodiment of this application, which includes a structural block of a portion of the server 120 implementing this embodiment. The server 120 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 622 (e.g., one or more processors) and memory 632, and one or more storage media 630 (e.g., one or more mass storage devices) for storing application programs 642 or data 644. The memory 632 and storage media 630 can be temporary or persistent storage. The program stored in the storage media 630 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server 600. Furthermore, the CPU 622 may be configured to communicate with the storage media 630 and execute the series of instruction operations in the storage media 630 on the server 600.

[0284] Server 600 may also include one or more power supplies 626, one or more wired or wireless network interfaces 650, one or more input / output interfaces 658, and / or one or more operating systems 641, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0285] The central processing unit 622 in server 600 can be used to execute the data processing method of the embodiments of this application, as follows:

[0286] In response to an access request triggered by a target account for the account management service, the system retrieves the target administrator account mapped to the account management service from a pre-stored account model. The account model includes the target administrator account pre-defined in the account management service, the target administrator role pre-defined for the target account, and the management permission information pre-defined for the target account by the target administrator role. A single sign-on credential for the target account is generated based on the target administrator account. Based on the single sign-on credential, at least one target administrator role mapped to the target account is determined from the account model, and the management permission information pre-defined for each target administrator role is retrieved. The management permission information pre-defined for each target administrator role is sent to the source server where the target account resides for permission information display.

[0287] This application also provides a computer-readable storage medium for storing program code, which is used to execute the data processing methods of the foregoing embodiments, as follows:

[0288] In response to an access request triggered by a target account for the account management service, the system retrieves the target administrator account mapped to the account management service from a pre-stored account model. The account model includes the target administrator account pre-defined in the account management service, the target administrator role pre-defined for the target account, and the management permission information pre-defined for the target account by the target administrator role. A single sign-on credential for the target account is generated based on the target administrator account. Based on the single sign-on credential, at least one target administrator role mapped to the target account is determined from the account model, and the management permission information pre-defined for each target administrator role is retrieved. The management permission information pre-defined for each target administrator role is sent to the source server where the target account resides for permission information display.

[0289] This application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the data processing method described above.

[0290] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0291] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0292] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0293] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0294] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0295] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0296] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0297] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0298] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0299] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A data processing method, characterized in that, include: In response to an access request triggered by a target object account for the account management service, the target administrator account mapped by the target object account for the account management service is obtained from the pre-stored account model; The account model includes a target administrator account pre-set in the account management service for the target object account, a target administrator role pre-set for the target object account by the target administrator account, and management permission information pre-set for the target object account by the target administrator role. Generate single sign-on credentials for the target object account based on the target administrator account; Based on the single sign-on credential, determine at least one target administrator role mapped to the target object account from the account model, and obtain the pre-set management permission information for each target administrator role for the target object account; The pre-defined management permission information for each target administrator role for the target account is sent to the source server where the target account is located for permission information display.

2. The method according to claim 1, characterized in that, The step of determining at least one target administrator role mapped to the target object account from the account model based on the single sign-on credential, and obtaining the pre-defined management permission information for each target administrator role for the target object account, includes: Log in to the account management service using the single sign-on credential and obtain the login result; When the login result is successful, determine at least one target administrator role that the target object account is mapped to in the account management service from the account model; Determine the pre-defined management permissions for each target administrator role for the target object account.

3. The method according to claim 2, characterized in that, The step of logging into the account management service based on the single sign-on credential and obtaining the login result includes: Based on the single sign-on credentials, determine the address of the device to be confirmed at the source end where the target object account is currently located; Obtain the target device address pre-stored for the target object account, and perform login verification on the device address to be confirmed based on the target device address; When the address of the device to be confirmed matches the address of the target device, the account management service is accessed based on the single sign-on credential, and the login success is determined as the login result. When the address of the device to be confirmed does not match the address of the target device, the login failure will be determined as the login result.

4. The method according to any one of claims 1 to 3, characterized in that, The process of generating single sign-on credentials for the target account based on the target administrator account includes: Based on the target object account and the target administrator account, obtain the historical single sign-on credential generated by the target object account last time, and determine the validity period of the historical single sign-on credential. When the effective usage period matches the current time, the historical single sign-on credential is determined as the single sign-on credential for the target account; When the effective usage period does not match the current time, obtain the historical generation frequency of single sign-on credentials for the target account within the historical time period; When the frequency of historical data generation is less than the preset upper limit threshold, a single sign-on credential for the target object account is generated based on the target administrator account.

5. The method according to claim 1, characterized in that, Prior to responding to an access request triggered by the target account for the account management service, the method further includes: In response to a role creation request sent by an administrator account, obtain a list of pre-configured administrator roles in the account management service; Obtain the administrator role to be created selected by the administrator account based on the list of administrator roles, and select the management permission to be created from the pre-configured management permissions supported by the administrator role to be created; Bind the administrator account with the administrator role to be created and the management permissions to be created to obtain the binding information of the administrator account; Create an account model based on the administrator account's binding information.

6. The method according to claim 5, characterized in that, The method further includes: Obtain the role customization request sent by the administrator account, wherein the role customization request carries a role customization identifier; Send the set of management permissions supported by the account management service to the administrator account; Obtain at least one candidate management permission selected by the administrator account from the set of management permissions, and create a custom administrator role corresponding to the role custom identifier based on the at least one candidate management permission; The administrator account is bound to the custom administrator role and the candidate management permissions to obtain custom binding information; Update the custom binding information to the account model.

7. The method according to claim 5 or 6, characterized in that, The method further includes: Obtain a permission allocation request, the permission allocation request carrying the administrator role identifier and object account to be allocated; Search the account model for candidate administrator accounts that are bound to the administrator role corresponding to the administrator role identifier; The object account is bound to the candidate administrator account and the administrator role corresponding to the administrator role identifier to obtain permission allocation information, and the permission allocation information is added to the account model.

8. The method according to claim 7, characterized in that, Prior to responding to an access request triggered by the target account for the account management service, the method further includes: In response to a login request triggered by the target object account on the object account service page, the target object account is verified, and a verification result is obtained; When the verification result is successful and it is confirmed that the target object account has the right to use the account management service, the application permission information of the account management service is sent to the target object account. The response to the access request triggered by the target account for the account management service includes: In response to an access request to the account management service triggered by the target object account based on the application permission information.

9. The method according to any one of claims 1 to 8, characterized in that, After sending the pre-defined management permission information for each target administrator role to the source server where the target account is located for permission information display, the process includes: Obtain the target management permissions selected by the target object account based on the displayed permission information; Execute the target management request sent by the target object account according to the target management permissions.

10. The method according to claim 9, characterized in that, The target management permissions include at least application management permissions, and executing the target management request sent by the target object account according to the target management permissions includes: Based on the application management permissions, obtain the list of candidate applications that have been added to the account management service; The list of candidate applications is sent to the source server where the target account is located for rendering and displaying the application management page; Obtain at least one candidate application selected by the target object account based on the application management page, and bind the at least one candidate application to the target object account in the account model.

11. A data processing apparatus, characterized in that, include: The acquisition unit is used to, in response to an access request triggered by a target object account for the account management service, acquire the target administrator account mapped by the target object account for the account management service from a pre-stored account model; The account model includes a target administrator account pre-set in the account management service for the target object account, a target administrator role pre-set for the target object account by the target administrator account, and management permission information pre-set for the target object account by the target administrator role. The generation unit is used to generate a single sign-on credential for the target object account based on the target administrator account; The determining unit is configured to determine at least one target administrator role mapped to the target object account from the account model based on the single sign-on credential, and to obtain the management permission information preset for each target administrator role for the target object account. The sending unit is used to send the pre-set management permission information of each target administrator role for the target object account to the source end where the target object account is located for permission information display.

12. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the data processing method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the data processing method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the data processing method according to any one of claims 1 to 10.

Images