Authentication method of the iam component and the iam component

By using UUIDs for authentication in the IAM component, a unique identifier is generated and associated with access permissions. This solves the problems of high maintenance costs and poor scalability of the whitelist authentication method, achieving higher security and flexibility, and improving system performance.

CN119520023BActive Publication Date: 2025-11-18CHONGQING SELIS PHOENIX INTELLIGENT INNOVATION TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411453155.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-10-17
Publication Date
2025-11-18
Estimated Expiration
2044-10-17

AI Technical Summary

Technical Problem

The existing IAM components' whitelist-based authentication method results in high maintenance costs, poor scalability, insufficient flexibility, high security risks, susceptibility to human error, lack of dynamism, and performance impact.

Method used

Authentication is performed using a Universally Unique Identifier (UUID). The first component of the IAM component generates the UUID and associates it with access permissions, while the second component transmits the authentication result, thus achieving multi-factor authentication to ensure security and scalability.

Benefits of technology

It improves the security and scalability of authentication, reduces maintenance costs, minimizes human error, and enhances the system's flexibility and performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119520023B_ABST
    Figure CN119520023B_ABST
Patent Text Reader

Abstract

The application relates to an authentication method of an IAM component and the IAM component, the method comprising: a first component configured to generate a universally unique identifier, associate corresponding access rights with the universally unique identifier, and cancel the access rights associated with the universally unique identifier; wherein the access rights represent resources accessed by a target device; a second component configured to receive a resource requested by the target device and the universally unique identifier, and send the resource requested by the target process and the universally unique identifier to the first component; the first component is configured to authenticate the universally unique identifier, and send an authentication result to the second component; and the second component is further configured to send the authentication result to the target device, so that the target device determines whether to call the requested resource according to the authentication result. Through the application, the problem that an IAM component in the prior art performs authentication based on a white list, resulting in high maintenance cost and poor expansibility, is solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of IAM component authentication, and more particularly to an authentication method for an IAM component and an IAM component. Background Technology

[0002] With the continuous development of modern automotive technology, the application of in-vehicle electronic software in vehicles is becoming increasingly widespread, and the interaction and interconnection between software are becoming more frequent, leading to a surge in internal and external security threats. To address the challenges of increasingly complex vehicle electronic systems and higher security requirements, more security and access control mechanisms are needed to protect vehicle systems from malicious attacks and unauthorized access. This has led to the development of the Identity and Access Management (IAM) component, a crucial component of AUTOSAR AP (Automotive Open System Architecture). IAM provides a centralized way to manage user identities and permissions, ensuring that only authorized users can access specific functions and data within the vehicle system. By using IAM, automakers can better protect sensitive data and functions within the vehicle system and improve the overall security and reliability of the system. In existing AUTOSAR APs, the IAM module typically employs a whitelist-based authentication method. However, this method requires maintaining a whitelist, resulting in high management complexity, and in large-scale systems, it may require significantly more resources to maintain a large number of whitelists. Summary of the Invention

[0003] This application provides an authentication method and an IAM component to solve the problem that the IAM component in the prior art is based on whitelist authentication, which leads to high maintenance costs and poor scalability.

[0004] In a first aspect, this application provides an Identity and Access Management (IAM) component, comprising a first component and a second component; the first component is configured to generate a universally unique identifier (UUID), associate the UUID with corresponding access permissions, and remove the access permissions associated with the UUID; wherein the access permissions represent the resources accessed by the target device; the second component is configured to receive the resources requested by the target device and the UUID, and send them to the first component based on the resources requested by the target process and the UUID; the first component is configured to authenticate the UUID and send the authentication result to the second component; the second component is further configured to send the authentication result to the target device, so that the target device determines whether to invoke the requested resources based on the authentication result.

[0005] Secondly, this application provides an authentication method based on the IAM component described in the first aspect. The method includes: a first component generating a universally unique identifier (UUID) and associating the UUID with corresponding access permissions, and deactivating the access permissions associated with the UUID; wherein the access permissions represent the resources accessed by the target device; a second component receiving the resources requested by the target device and the UUID, and sending them to the first component based on the resources requested by the target process and the UUID; the first component authenticating the UUID and sending the authentication result to the first component; and the second component sending the authentication result to the target device, so that the target device determines whether to invoke the requested resources based on the authentication result.

[0006] Thirdly, this application provides an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the processor is configured to execute the authentication method of the IAM component described in the second aspect of this application.

[0007] Fourthly, this application also provides a computer storage medium storing computer-executable instructions for executing the authentication method of the IAM component described in the second aspect of this application.

[0008] Compared with the prior art, the technical solution provided in this application has the following advantages: In this application embodiment, the first component in the IAM component first generates a universally unique identifier and associates the universally unique identifier with corresponding access permissions, and then removes the access permissions associated with the universally unique identifier. Afterwards, the second component in the IAM component receives the resource requested by the target device and the universally unique identifier, and sends the resource requested by the target device and the universally unique identifier to the first component. The first component authenticates the universally unique identifier and sends the authentication result to the second component. The second component sends the authentication result to the target device, so that the target device determines whether to call the requested resource based on the authentication result. It can be seen that in this application embodiment, the IAM component uses a universally unique identifier to authenticate the target device. Due to the uniqueness of the universally unique identifier, the security of authentication is improved. Moreover, the universally unique identifier can be better extended, and compared with the whitelist in the prior art, it can be better maintained and managed, thus solving the problem of high maintenance costs and poor scalability caused by the IAM component in the prior art using a whitelist for authentication. Attached Figure Description

[0009] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0012] Figure 1 This is a schematic diagram of the structure of an IAM component provided in an embodiment of this application;

[0013] Figure 2 A schematic diagram of an optional structure of an IAM component provided in an embodiment of this application;

[0014] Figure 3 This is a schematic diagram illustrating UUID-based authentication in a specific example of this application;

[0015] Figure 4 A flowchart for generating a UUID provided in an embodiment of this application;

[0016] Figure 5 A flowchart illustrating an authentication method for an IAM component provided in this application embodiment;

[0017] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, 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.

[0019] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0020] Existing technologies using IAM modules typically employ a whitelist-based authentication method, which presents the following problems:

[0021] 1) High maintenance costs: As the number of system users or devices increases, the whitelist grows larger, requiring regular updates and maintenance, which increases management complexity and costs. 2) Poor scalability: When new users or devices need to access the system, they must be manually added to the whitelist. This method is feasible when the number of users or devices is small, but its scalability is poor in large-scale systems. 3) Insufficient flexibility: Whitelist-based authentication mechanisms are usually relatively fixed and not very adaptable to rapidly changing environments. When rapid response to changes is required, timely authentication services may not be provided. 4) Security risks: If the whitelist is accessed or tampered with without authorization, the security of the entire system may be threatened. In addition, whitelist-based authentication may rely on identifiable user information, which may expose user privacy. 5) Human error: Whitelist management often involves manual operation, which may lead to unauthorized users or devices being mistakenly added to the whitelist due to negligence or error, or users or devices that no longer need access being forgotten to be removed from the whitelist. 6) Lack of dynamism: Whitelist-based authentication mechanisms are not easy to implement dynamic access control, such as adjusting access permissions based on current environmental conditions or system status. 7) Performance issues: In systems with a large number of users or devices, each access control decision may require checking a large whitelist, which can negatively impact system performance.

[0022] To address this, embodiments of this application provide an Identity Authentication and Access Management (IAM) component, such as... Figure 1 As shown, the IAM component in this embodiment includes a second component and a first component. Further, the first component is used to generate a universally unique identifier, associate the universally unique identifier with the corresponding access permissions, and remove the access permissions already associated with the universally unique identifier; wherein, the access permissions represent the resources accessed by the target device.

[0023] The universally unique identifier (UUID) refers to the unique identifier used in IAM. In a specific example, the first component of IAM can be a Policy Decision Point (PDP), and the second component can be a Policy Enforcement Point (PEP). The PEP, as the second component of IAM, functions to enforce access control policies and monitor access requests in the system. Furthermore, the PEP communicates with the PDP to obtain access control policies and determines whether to allow or deny specific access requests based on these policies. Figure 2 As shown, in this specific example, PEP consists of an authorization instance module, an asynchronous processing algorithm module, and an IPC (Inter-Process Communication) second component. PDP is the first component of the IAM (In-Process Communication) system, and its function is to determine whether to allow specific operations or access requests based on the access policy associated with the UUID, such as... Figure 2 As shown, the PDP consists of a UUID generation and registration module, an access policy definition module, a resource association module, an authentication module, a data management module, and the first IPC component.

[0024] Furthermore, in a specific example, the UUID in this application embodiment can be a 128-bit number, typically represented by 32 hexadecimal digits, divided into several groups separated by hyphens, such as 123e4567-e89b-12d3-a456-426614174000. Because this UUID is unique, authentication using this UUID is not only highly secure but also does not require maintenance like a whitelist.

[0025] Furthermore, in the embodiments of this application, the settings for accessible resources can be accessed through the service ID: instance ID or service ID: instance ID: method method. That is, one service corresponds to one instance, but one instance can correspond to multiple methods. In other words, resources can be accessed through multiple methods under an instance, or resources can be accessed through one method under an instance.

[0026] Based on this, the second component in this embodiment receives the resources and universally unique identifier requested by the target device, and sends them to the first component based on the resources and universally unique identifier requested by the target process.

[0027] Furthermore, in this embodiment, the first component can authenticate the universally unique identifier and send the authentication result to the second component. The second component can then send the authentication result to the target device, enabling the target device to determine whether to invoke the requested resource based on the authentication result.

[0028] As can be seen, the first component in the IAM component first generates a universally unique identifier (UUID) and associates it with corresponding access permissions, and then removes the access permissions already associated with the UUID. Subsequently, the second component in the IAM component receives the resource requested by the target device and the UUID, and sends the requested resource and the UUID to the first component. The first component authenticates the UUID and sends the authentication result to the second component. The second component then sends the authentication result to the target device, enabling the target device to determine whether to access the requested resource based on the authentication result. Therefore, in this embodiment, the IAM component uses a UUID to authenticate the target device. The uniqueness of the UUID improves authentication security, and the UUID can be more easily extended. Compared to whitelists in the prior art, it is easier to maintain and manage, thus solving the problem of high maintenance costs and poor scalability caused by whitelist-based authentication in the prior art.

[0029] In an optional embodiment of this application, the first component in this application embodiment is further configured to generate an initial universally unique identifier based on a random number after receiving a request from the target device to generate a universally unique identifier, and associate the universally unique identifier with the corresponding access permissions.

[0030] In a specific example, the target device's app can send a request to the first component in the IAM component to generate a UUID. The first component in the IAM component then generates a UUID using an encrypted and secure random number generator, formats the generated UUID data into a standard UUID format, such as 32 characters (8-4-4-4-12), and finally outputs the formatted UUID for the app to use.

[0031] Furthermore, the specific process by which the target device requests the required resources from the IAM component in this embodiment of the application may be as follows: After the target device calls the second component to generate an authorization instance, the second component writes the authorization instance, the process ID of the second component, and the universally unique identifier requested by the target device into a serialization object, and formats the serialization object before sending it to the first component; wherein, the authorization instance includes the requested resources; then, the first component authenticates the process ID and the universally unique identifier requested by the target device, and sends the authentication result to the second component; thereafter, the second component sends the authentication result to the target device, so that the target device determines whether to call the requested resources based on the authentication result.

[0032] As can be seen, in this embodiment, not only is it necessary to authenticate the universally unique identifier (UUID) to determine whether the IAM component contains a UUID corresponding to the target device, but it is also necessary to authenticate the process ID of the second component to determine whether the UUID currently sent to the first component was sent by the second component. Therefore, multiple authentication methods are required when the IAM component calls resources from the target device to ensure the accuracy of resource calls.

[0033] In an optional embodiment of this application, the first component can predefine the access permissions corresponding to the universally unique identifier, i.e., which resources the corresponding target device can request. Furthermore, the first component can also define the operations performed on the accessible resources and the conditions for adjusting the access permissions. Therefore, the first component in this application embodiment is also used to define the resources accessible to the target device and the operations performed on those resources, as well as to set conditions for dynamically adjusting the access permissions.

[0034] In other words, in this embodiment, the first component defines access permissions for each universally unique identifier (UUID). These permissions specify which resources the corresponding app can access and which operations it can perform. Furthermore, the resource can be presented in a format such as Service ID:Instance ID, or Service ID:Instance ID:Method. For example, using Service ID:Instance ID, the current service is to call the vehicle's music function, and the instance is the content of playing songs, such as which song to play or which type of song to search for. This is sent to the IAM component via Service ID:Instance ID. After obtaining the Service ID:Instance ID, the IAM component authenticates it based on the requested UUID. If authentication is successful, the vehicle's music function is started based on Service ID:Instance ID, and the corresponding music content is played. Furthermore, access permissions can be dynamically adjusted based on specific conditions or triggers. For example, a target device may previously have permission to play music, but its permission to play vehicle music can be restricted in real time.

[0035] Furthermore, in a specific example, the first component can be a resource that is adjustable in real time based on at least one of the following preset conditions: time, location, and target event. Further, adjusting resources based on time as a preset condition could, in a specific example, mean that during routine vehicle maintenance, a comprehensive diagnostic and debugging operation is required for all ECUs. During the maintenance period, all ECUs should have the permission to read and write diagnostic data, but during normal operation, these permissions should be restricted to prevent unauthorized access and operation. Adjusting resources based on location or a target event occurring in the system could, in a specific example, mean that the vehicle requires different operating permissions in different environments. For example, in high-risk environments (such as mountainous areas), additional safety check permissions are required. When the vehicle enters a high-risk environment, the additional safety check permissions are automatically enabled; when the vehicle is in a normal environment, these permissions should be disabled to avoid unnecessary operations.

[0036] In specific examples, "time-based" can refer to a time period of an event or a pre-defined time period. For instance, during routine vehicle maintenance, a comprehensive diagnostic and debugging operation is required for all Electronic Control Units (ECUs). During the maintenance period, all ECUs should have permission to read and write diagnostic data, but during normal operation, these permissions should be restricted to prevent unauthorized access and operation. "Location-based" refers to the target event occurring within the system, meaning the vehicle requires different operating permissions in different environments. For example, in high-risk environments (such as mountainous areas), additional safety check permissions are needed. When the vehicle enters a high-risk environment, these additional safety check permissions are automatically enabled; when the vehicle is in a normal environment, these permissions should be disabled to avoid unnecessary operations.

[0037] It should be noted that before authentication, the first component can generate corresponding authorization rules, that is, authentication and resource invocation can be performed according to the authorization rules. Based on this, the first component in this embodiment is also used to associate access permissions with a universally unique identifier, and generate corresponding authorization rules based on the universally unique identifier, process, and resource. The authorization rules represent the authentication of the target device based on the universally unique identifier, process, and resource during the target device's request to invoke resources.

[0038] Therefore, during the authentication process of the first component, the second component sends the process ID of the second component requiring authentication and its universally unique identifier to the first component in a specific way. Specifically, the second component writes the authorized instance, the process ID of the second component, and the universally unique identifier of the request into a serialization object and performs format conversion so that the authorized instance, the process ID of the second component, and the request ID of the request are arranged into byte order according to a fixed format, and then sends the byte order to the deserialization process in the first component. It can be seen that, in this embodiment, the second component can write the authorized instance information, the process ID (PID) of the IAM second component, and the request ID together into a serialization object and perform format conversion so that the data is arranged into byte order according to a fixed format, realizing data transmission over the network. In a specific example, the formatted serialization object can be sent to the first component by connecting to a Domain Socket. Compared to traditional socket communication, Domain Socket does not require going through the network protocol stack, does not require packet packing and unpacking, checksum calculation, sequence number maintenance, and response, etc. It simply copies application layer data from one process to another, improving communication efficiency and indirectly improving the operating efficiency of the IAM component.

[0039] After generating authorization rules in advance and receiving the process ID and requested universally unique identifier from the second component, the first component is further configured to authenticate the process ID and universally unique identifier read from deserialization based on the authorization rules. Specifically, the authentication process performed by the first component based on the authorization rules, i.e., authenticating the target device based on the universally unique identifier, process, and resources, includes the following steps:

[0040] Step 11: The first component compares the process ID read from the deserialization with the process ID in the serialization object;

[0041] Step 12: If the process ID read by the first component is inconsistent with the process ID in the serialized object, the first component returns an authentication failure result to the second component.

[0042] Step 13: If the process ID read by the first component matches the process ID in the serialized object, the first component verifies the universally unique identifier.

[0043] Step 14: If the universally unique identifier is invalid, the first component returns the authentication failure result to the second component;

[0044] Step 15: If the universally unique identifier is verified to be valid, the first component checks whether the target device has permission to access the access permissions corresponding to the universally unique identifier.

[0045] For steps 11 to 15 above, in a specific example, it could be: If the process ID of the IAM second component read from deserialization matches the process ID read via socket, then authentication initialization is successful. Further verification is then performed to check the validity of the universally unique identifier provided in the request, i.e., checking if the universally unique identifier exists in the system's registration list. If the universally unique identifier is valid, permission verification continues; if the universally unique identifier is invalid, the authentication result is directly returned to the second component. After the universally unique identifier is verified as valid, a permission check is performed to check whether the universally unique identifier in the request has permission to access the requested resource. This includes verifying whether the universally unique identifier is in the access control list that allows access to the app, or whether the universally unique identifier belongs to a role that has permission to access the app. If the verification is successful, the IAM component will authorize the access request and allow the app on the target device to access the resource; if the verification fails, access will be denied.

[0046] Based on this, when the second component receives the verification confirmation sent by the first component, it determines that the authentication of the target device is successful, and sends the resources requested by the target device to the target device through an asynchronous call.

[0047] In this embodiment, accessible resources are invoked asynchronously. This not only allows time-consuming operations to be performed in the background without blocking the main thread, thus improving the program's response speed and performance, but also enables multiple tasks to be executed simultaneously, improving the system's concurrency performance. Furthermore, it effectively manages system resources, avoiding resource waste and redundancy, and improving the operating efficiency of the IAM component.

[0048] The following detailed explanation, in conjunction with specific embodiments of this application, provides an optimized design method for IAM components based on UUID authentication. Figure 3 The method steps in this specific embodiment include:

[0049] Step 301: The APP calls the UUID registration and generation module. When the process creates a service for the first time, it generates a UUID by calling the UUID registration and generation module. This UUID will be registered in the PDP of the IAM component as the process's unique identifier.

[0050] Furthermore, such as Figure 4 As shown, the steps for generating a UUID include:

[0051] Step 401: The APP requests the generation of a new UUID;

[0052] Step 402: Generate a UUID using an encrypted and secure random number generator through the UUID generation and registration module.

[0053] Step 403: Format the generated UUID data into a standard UUID format (e.g., 32 characters of 8-4-4-4-12);

[0054] Step 404: Output the formatted UUID for use by the APP.

[0055] As can be seen from steps 401 to 404 above, in this embodiment of the application, a UUID can be generated based on a random number generator. Since the UUID based on random numbers ensures uniqueness by generating a sufficiently large random number, it also ensures its anonymity, unpredictability, and untraceability. Therefore, no information such as MAC address or other identifiers can be obtained from the UUID, which can fully protect user privacy. Therefore, in this embodiment of the application, a UUID version based on random numbers is adopted.

[0056] Step 302: The UUID generation and registration module calls the access strategy definition module.

[0057] The access policy definition module defines automated policies that specify access permissions for each UUID. These permissions specify which resources (service ID: instance ID or service ID: instance ID: method) the corresponding app can access and which operations it can perform. If needed, the automated policy definition module can dynamically adjust access permissions based on specific conditions or triggers.

[0058] For example, a user's permissions may vary based on time, location, or specific events occurring in the system. Further, based on time: During routine vehicle maintenance, comprehensive diagnostics and tuning of all ECUs are required. During maintenance periods, all ECUs should have read and write permissions for diagnostic data, but during normal operation, these permissions should be restricted to prevent unauthorized access and manipulation. Based on location or specific events occurring in the system: Vehicles require different operating permissions in different environments. For example, in high-risk environments (such as mountainous areas), additional safety check permissions are needed. When a vehicle enters a high-risk environment, these additional safety check permissions should be automatically enabled; when the vehicle is in a normal environment, these permissions should be disabled to avoid unnecessary operations.

[0059] Step 303: The access policy definition module calls the resource association module.

[0060] The resource association module automatically applies the defined access control policies to each UUID and associates the UUID with the permissions defined in these policies. It parses the UUID, process, and resource (service ID: instance ID or service ID: instance ID: method) into an authorization rule and stores each authorization rule in the module.

[0061] Step 304: The APP calls the authorization instance module interface;

[0062] The authorization instance object is generated using the process name and resource (service ID: instance ID or service ID: instance ID: method). The app then passes the generated authorization instance to the asynchronous processing algorithm module to achieve asynchronous invocation of the authorization result. The specific asynchronous processing algorithm flow is as follows: Promise is typically used to set the result of asynchronous operations; in this embodiment, Promise is used to set the authorization result of asynchronous operations, while Future is used to retrieve the result of asynchronous operations; in this embodiment, Future is used to set the authorization result of asynchronous operations. While the asynchronous processing function is performing asynchronous operations, it does not affect the processing of other logic; that is, it can continue to send new authorization objects to the IAM first component for processing without waiting for the authorization result.

[0063] Step 305: The authorized instance information, the process ID (PID) of the second IAM component, and the request ID are written into the serialization object and the format is converted so that the data is arranged into byte order according to a fixed format, so that the data can be transmitted over the network. The second IPC component sends the formatted serialization object to the first IPC component through the Domain Socket connection.

[0064] In contrast to traditional socket communication, UNIX Domain Socket does not require going through the network protocol stack, nor does it need to pack and unpack, calculate checksums, maintain sequence numbers and acknowledgments. It simply copies application layer data from one process to another, improving communication efficiency and indirectly improving the operating efficiency of IAM components.

[0065] Step 306: After receiving data through the Domain Socket bound to the second component, the first IPC component passes it into the deserialized object and reads the process ID and resource (service ID: instance ID or service ID: instance ID: method) of the second IAM component in the deserialized object to construct temporary authorized instance information, which is then stored in the data management module.

[0066] Step 307: PDP performs authentication;

[0067] If the process ID of the IAM second component read from deserialization matches the process ID read via socket, the authentication module initializes successfully. At this point, the authentication module verifies the validity of the UUID provided in the request, checking if the UUID exists in the system's registry. If the UUID is valid, permission verification continues; if the UUID is invalid, the authentication result is returned directly to the second component. After valid UUID verification, the authentication module performs a permission check, verifying whether the UUID in the request has permission to access the requested resource. This includes verifying whether the UUID is in the access control list allowed to access the app, or whether the UUID belongs to a role authorized to access the app. If verification succeeds, the IAM module authorizes the access request and allows the app to access the resource; if verification fails, access is denied.

[0068] Step 308: Place the authentication result into a serialization object, format it, and send it to the asynchronous processing algorithm module of the second IAM component.

[0069] Step 309: After receiving the authentication result, the asynchronous processing algorithm module will deserialize it and assign the result to the Promise object. At this time, the APP obtains the authentication result of the asynchronous call through the Future object.

[0070] As can be seen from steps 301 to 309 in the embodiments of this application, the UUID provides a globally unique identifier for each APP and resource, which reduces the risk of identity conflicts. The UUID generated based on random numbers, as used in this patent, provides unpredictability, increasing security during the IAM component authentication process. Furthermore, UUIDs allow for more dynamic access control, as permissions can be associated with or unassociated with any UUID in real time without needing to update the entire whitelist. Moreover, using UUID authentication reduces management complexity, as managing a single identifier is simpler than maintaining and auditing long whitelists. As the number of users and resources increases, the UUID authentication mechanism can scale better, while traditional whitelists may become difficult to manage and maintain. Additionally, since UUIDs are automatically generated, the possibility of human input errors is reduced, whereas the probability of errors is higher when manually managing whitelists in existing technologies.

[0071] Corresponding to the above Figure 1 This application provides an authentication method based on an IAM component, which includes a second component and a first component, such as... Figure 5 As shown, the steps of this method include:

[0072] Step 501: The first component generates a universally unique identifier, associates the universally unique identifier with the corresponding access permissions, and removes the access permissions already associated with the universally unique identifier; wherein, the access permissions represent the resources accessed by the target device;

[0073] Step 502: The second component receives the resources and universally unique identifier requested by the target device, and sends them to the first component based on the resources and universally unique identifier requested by the target process.

[0074] Step 503: The first component authenticates the universally unique identifier and sends the authentication result to the first component;

[0075] Step 504: The second component sends the authentication result to the target device so that the target device can determine whether to invoke the requested resource based on the authentication result.

[0076] Through steps 501 to 504 above, the first component in the IAM component first generates a universally unique identifier (UUID) and associates it with corresponding access permissions, and then removes the access permissions associated with the UUID. Subsequently, the second component in the IAM component receives the resource requested by the target device and the UUID, and sends the requested resource and the UUID to the first component. The first component authenticates the UUID and sends the authentication result to the second component. The second component then sends the authentication result to the target device, enabling the target device to determine whether to access the requested resource based on the authentication result. It is evident that in this embodiment, the IAM component uses a UUID to authenticate the target device. The uniqueness of the UUID improves authentication security, and the UUID can be more easily extended. Compared to whitelists in the prior art, it is easier to maintain and manage, thus solving the problem of high maintenance costs and poor scalability caused by whitelist-based authentication in the prior art.

[0077] Furthermore, in an optional embodiment of this application, the method by which the first component generates a universally unique identifier and associates the universally unique identifier with the corresponding access permissions in step 501 above may further include: after receiving a request from the target device to generate a universally unique identifier, the first component generates an initial UUID based on a random number and associates the universally unique identifier with the corresponding access permissions.

[0078] The method by which the second component in step 502 above receives the resources and universally unique identifier requested by the target device and sends the resources and universally unique identifier requested by the target device to the first component may further include: after the target device calls the second component to generate an authorization instance, the second component serializes the authorization instance, the process ID of the second component, and the universally unique identifier requested by the target device and then sends them to the first component.

[0079] like Figure 6 As shown in the figure, this application provides an electronic device, including a processor 611, a communication interface 612, a memory 613, and a communication bus 614, wherein the processor 611, the communication interface 612, and the memory 613 communicate with each other through the communication bus 614.

[0080] Memory 613 is used to store computer programs;

[0081] In one embodiment of this application, when the processor 611 executes the program stored in the memory 613, it implements the authentication method of the IAM component provided in any of the foregoing method embodiments, and its function is similar, so it will not be described again here.

[0082] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the authentication method of the IAM component as provided in any of the foregoing method embodiments.

[0083] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0085] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0086] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. An Identity Authentication and Access Management (IAM) component, characterized in that, The IAM component includes a first component and a second component; The first component is used to generate a universally unique identifier, associate the universally unique identifier with a corresponding access permission, and remove the access permission already associated with the universally unique identifier; wherein, the access permission represents the resource accessed by the target device; The second component is used to receive the resources and universally unique identifier requested by the target device, and send the requested resources and universally unique identifier to the first component based on the target process; The first component is used to authenticate the universally unique identifier and send the authentication result to the second component; The second component is further configured to send the authentication result to the target device, so that the target device determines whether to invoke the requested resource based on the authentication result; The first component is further configured to, upon receiving a request from the target device to generate a universally unique identifier, generate an initial universally unique identifier based on a random number and associate the universally unique identifier with the corresponding access permissions. The second component is further configured to, after the target device calls the second component to generate an authorization instance, serialize the authorization instance, the process ID of the second component, and the universally unique identifier requested by the target device and send them to the first component; wherein, the authorization instance includes the requested resources; The first component is further configured to authenticate the process ID and the universally unique identifier requested by the target device, and send the authentication result to the second component; The second component is further configured to send the authentication result to the target device, so that the target device determines whether to invoke the requested resource based on the authentication result.

2. The IAM component according to claim 1, characterized in that, The first component is further configured to define the access permissions as the resources accessible to the target device and the operations performed on the resources, and to set conditions for dynamically adjusting the access permissions.

3. The IAM component according to claim 1, characterized in that, The first component is further configured to associate the access permission with the universally unique identifier, and generate corresponding authorization rules based on the universally unique identifier, process, and resource, wherein the authorization rules characterize the authentication of the target device based on the universally unique identifier, process, and resource during the process of the target device requesting to call resources.

4. The IAM component according to claim 3, characterized in that, The second component is used to write the authorized instance, the process ID of the second component, and the requested universally unique identifier into a serialization object and arrange them into byte order according to a fixed format, and send the byte order to the deserialization process in the first component.

5. The IAM component according to claim 4, characterized in that, The first component is further configured to authenticate the process ID and universally unique identifier read from the deserialization based on the authorization rules.

6. The IAM component according to claim 5, characterized in that, The first component compares the process ID read from the deserialization with the process ID in the serialization object. If the process ID read by the first component does not match the process ID in the serialization object, it returns an authentication failure result to the second component. If the process ID read by the first component matches the process ID in the serialization object, it verifies the universally unique identifier. The first component is further configured to return an authentication failure result to the second component if the universally unique identifier is invalid; and to check whether the target device has permission to access the access permissions corresponding to the universally unique identifier if the universally unique identifier is valid, and to return a successful verification result to the second component if the target device has permission to access the access permissions corresponding to the universally unique identifier.

7. The IAM component according to claim 6, characterized in that, The second component is further configured to, upon receiving a successful verification from the first component, determine that the target device has been successfully authenticated, and send the resources requested by the target device to the target device via an asynchronous call.

8. An authentication method based on the IAM component according to any one of claims 1 to 7, characterized in that, The method includes: The first component generates a universally unique identifier, associates the universally unique identifier with corresponding access permissions, and removes the access permissions already associated with the universally unique identifier; wherein, the access permissions represent the resources accessed by the target device; The second component receives the resources and universally unique identifier requested by the target device, and sends them to the first component based on the resources and universally unique identifier requested by the target process; The first component authenticates the universally unique identifier and sends the authentication result to the first component; The second component sends the authentication result to the target device, so that the target device determines whether to invoke the requested resource based on the authentication result; The first component generates a universally unique identifier and associates the universally unique identifier with corresponding access permissions, including: after receiving a request from the target device to generate a universally unique identifier, the first component generates an initial UUID based on a random number and associates the universally unique identifier with corresponding access permissions. The second component receives the resources and universally unique identifier requested by the target device and sends the resources and universally unique identifier requested by the target device to the first component, including: after the target device calls the second component to generate an authorization instance, the second component serializes the authorization instance, the process ID of the second component, and the universally unique identifier requested by the target device and sends them to the first component.

Citation Information

Patent Citations

  • Resource access authentication method and device, storage medium and electronic equipment

    CN112995163A

  • Resource usage rights determining system and method

    WO2017067137A1