Network protocol login authority control method, system, device and readable storage medium

Abstract

The application relates to a network protocol login permission control method, system, device and readable storage medium. The method comprises the following steps: in response to an SSH login request initiated by a user based on a client, obtaining an SSH certificate carried by the SSH login request; analyzing the SSH certificate to obtain user group information, wherein the user group information is determined by a user identity token obtained by a certificate issuing structure service based on a GitLab OIDC protocol calling token access interface; and comparing a server grouping tag list allowed to access in a satellite intelligent algorithm machine server with the user group information to control the SSH login permission of the client. The method can unify the GitLab permission and the server SSH access permission.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a network protocol login access control method, system, device and readable storage medium. Background Technology

[0002] During the development, integration, and testing phases, spaceborne intelligent computing systems require comprehensive verification of functional performance, simulation of complex space environments, ensuring development efficiency and quality, and guaranteeing system reliability and security. Therefore, they need to simultaneously manage a large number of heterogeneous computing nodes, including jump servers, test boards, electrical component servers, and prototype servers. Self-built GitLab services typically serve as a unified management platform for spaceborne software development. Each satellite model and payload mission is managed with isolated permissions within independent GitLab Groups. Members of different groups can only access and operate projects within their own group and cannot view or modify content from other groups.

[0003] In the context of spaceborne intelligent computing, a user's GitLab Group and the servers it can access naturally form a one-to-many mapping relationship. This means that a user can pull source code for a specific model or payload within a group. Besides pulling code, the user also needs to access the jump server or board server corresponding to that group for code deployment, debugging, and testing. The jump server is typically used to securely connect to other servers, while the board server may be used to run and test the code.

[0004] However, existing SSH (Secure Shell Protocol) login methods, such as static public keys, usernames and passwords, and LDAP (Lightweight Directory Access Protocol), cannot automatically inherit GitLab's group permissions. There is a lack of a unified access control method among related technologies that can unify GitLab permissions and server SSH access permissions. Summary of the Invention

[0005] Therefore, it is necessary to provide a network protocol login permission control method, system, computer device, computer-readable storage medium, and computer program product that can unify the permission control method for GitLab permissions and server SSH access permissions to address the above-mentioned technical problems.

[0006] Firstly, this application provides a network protocol login access control method, applied to a spaceborne intelligent computing server, comprising:

[0007] In response to an SSH login request initiated by a user based on a client, obtain the SSH certificate carried in the SSH login request;

[0008] The SSH certificate is parsed to obtain user group information, which is determined by the user identity token obtained by the certificate issuance structure service based on the GitLab OIDC protocol calling the token access interface;

[0009] The list of allowed server group labels in the onboard intelligent computing server is compared with the user group information to control the SSH login permissions of the client.

[0010] In one embodiment, comparing the list of allowed server group tags in the onboard intelligent computing server with the user group information to control SSH login permissions for the client includes:

[0011] Obtain the public key sent by the certificate authority service, and verify the validity of the SSH certificate based on the public key;

[0012] After successful verification, the onboard intelligent computing server loads its list of allowed server group tags and compares the list of allowed server group tags with the user group information.

[0013] If the intersection of the server group label list and the user group information is not empty, then the SSH login permission authorization for the user is granted.

[0014] In one embodiment, the method further includes:

[0015] The SSH certificate is parsed to obtain the user's email address;

[0016] By calling the GitLab interface, the latest user group information of the client can be obtained based on the user's email address;

[0017] The server group label list is compared with the latest user group information to control the user's SSH login permissions.

[0018] In one embodiment, parsing the SSH certificate to obtain user group information includes:

[0019] The SSH certificate is parsed to obtain the Principals field in the SSH certificate;

[0020] Extract the user group information from the Principals field.

[0021] Secondly, this application provides a network protocol login access control method, applied to a certificate issuance structure service, the method comprising:

[0022] Obtain the client's user identity token by calling the token access interface through the GitLab OIDC protocol;

[0023] Parse the user identity token to obtain the user group information of the corresponding user;

[0024] Obtain the original SSH certificate of the client, write the user group information into the original SSH certificate to obtain an SSH certificate, so that when the user initiates an SSH login request to the spaceborne intelligent computing server based on the client, the spaceborne intelligent computing server can control the client's SSH login permissions according to the user group information in the SSH certificate.

[0025] In one embodiment, the user identity token includes a user email address, and the method further includes:

[0026] The user's email address is written into the SSH certificate so that when the user initiates an SSH login request to the spaceborne intelligent computing server based on the client, the spaceborne intelligent computing server obtains the latest user group information based on the user's email address in the SSH certificate, and performs SSH login permission control on the client based on the latest user group information.

[0027] In one embodiment, the method further includes:

[0028] Obtain the validity period of the SSH certificate; if the validity period of the SSH certificate is not the preset validity period, trigger the generation of a certificate update command.

[0029] In response to the certificate update instruction, the step of calling the token access interface via the GitLab OIDC protocol to obtain the client's user identity token is executed to obtain the updated SSH certificate.

[0030] Thirdly, this application also provides a network protocol login access control system, the system including a GitLab service, a certificate issuance structure service, server nodes, and clients, wherein:

[0031] The certificate issuance structure service is used to call the token access interface through the GitLab OIDC protocol of the GitLab service to obtain the user identity token of the client; parse the user identity token to obtain the user group information of the corresponding user; obtain the original SSH certificate of the client, write the user group information into the original SSH certificate to obtain the SSH certificate, and send the SSH certificate to the client.

[0032] The server node is configured to respond to an SSH login request initiated by a user based on the client, obtain the SSH certificate carried in the SSH login request, parse the SSH certificate to obtain user group information, and compare the list of allowed server group labels in the server node with the user group information to control the SSH login permissions of the client.

[0033] Fourthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement any of the steps described in the above method.

[0034] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the steps described in the above method.

[0035] Sixthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the steps described in the above method.

[0036] The aforementioned network protocol login access control method, system, computer device, computer-readable storage medium, and computer program product obtain user group information by calling the token access interface based on the GitLab OIDC protocol and writes the user group information into the client's SSH certificate. This means GitLab permissions are written into the SSH certificate. Therefore, when responding to a user's SSH login request initiated by the client, SSH login access control is only required by obtaining the SSH certificate carried in the SSH login request. The user group information in the SSH certificate is compared with the allowed server group label list and user group information on the server to control SSH login access for the client. This method writes GitLab permissions into the SSH certificate and uses this for access control on the server, enabling SSH login permissions to be directly based on GitLab permission snapshots. This unifies GitLab permissions and server SSH access permissions, eliminating the need for separate SSH permission configuration and saving resources. Attached Figure Description

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

[0038] Figure 1This is a flowchart illustrating a network protocol login permission control method in one embodiment;

[0039] Figure 2 This is a flowchart illustrating a network protocol login permission control method in another embodiment;

[0040] Figure 3 This is a flowchart illustrating the network protocol login permission control method in yet another embodiment;

[0041] Figure 4 This is a schematic diagram illustrating an application scenario of a network protocol login permission control method in one embodiment.

[0042] Figure 5 This is a structural block diagram of a network protocol login permission control system in one embodiment;

[0043] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0045] In the context of spaceborne intelligent computing, the development and operation of such computing involves extensive code writing, testing, and deployment. GitLab, as a code version management tool, stores different versions of the project's code. The server serves as the actual environment for code execution and testing. However, spaceborne intelligent computing scenarios demand high security and reliability, which necessitates manual maintenance of SSH logins to meet these requirements.

[0046] Because SSH login permissions and GitLab permissions are inherently unrelated and independent, existing SSH login methods cannot inherit GitLab group permissions, nor can they guarantee a unified access boundary between server resources and code resources. This leads to problems such as fragmented permissions, complex maintenance, difficulty in revoking permissions, and missing audit trails. For example, a user may be removed from a GitLab project, but their permissions on the server are not deleted, allowing them to still SSH into the production machine. Therefore, a unified permission control method is needed to unify GitLab permissions and server SSH access permissions.

[0047] To achieve this solution, based on a self-built GitLab and CA (Certificate Authority) service, user identity and user group information are obtained through GitLabOIDC, and written into the user's SSH certificate in the form of certificate Principals, thereby unifying GitLab permissions and server SSH access permissions.

[0048] In one embodiment, such as Figure 1 As shown, a network protocol login permission control method is provided. This embodiment illustrates the method applied to a server. It is understood that this method can also be applied to a terminal, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0049] Step 102: In response to the SSH login request initiated by the user based on the client, obtain the SSH certificate carried in the SSH login request.

[0050] SSH (Secure Shell) login, or simply SSH login, is a specific method used in this context. Spaceborne intelligent computing servers can include jump servers, test boards, electrical component servers, and prototype servers. SSH certificates are configured with short validity periods, ranging from 1 to 24 hours.

[0051] Step 104: Parse the SSH certificate to obtain user group information. The user group information is determined by the user identity token obtained by the Certificate Authority Service based on the GitLab OIDC protocol call to the token access interface.

[0052] The user group information, or the obtained group information, is used to identify the user group to which the user currently belongs. Based on the user group, the servers that the user can access can be determined. This user group information is obtained by parsing the SSH certificate, specifically by retrieving the Principals field from the SSH certificate. The Principals field, which declares the identity or role that the certificate can represent, is then extracted from it. The Principals field contains multiple strings corresponding to GitLab Groups, which can verify whether the user has the necessary permissions for the group corresponding to the server they are trying to log into.

[0053] The Certificate Authority (CA) service is responsible for generating and issuing SSH certificates. The CA listens for GitLab system events or responds to user requests, calls the OIDC interface to obtain an identity token, parses the token to obtain the user's identity and group information (i.e., group information), and writes the obtained group information into the client's raw SSH certificate to obtain the SSH certificate. The raw SSH certificate is generated by the Certificate Authority (CA) adding additional metadata and a signature to the SSH public key. This metadata includes information such as the certificate's validity period and principals (e.g., username or hostname).

[0054] Optionally, the determination of the SSH certificate can be achieved by the user initiating an authentication request to the CA, the CA calling the token access interface via the GitLabOIDC protocol to obtain the client's user identity token; parsing the user identity token to obtain the corresponding user group information; obtaining the client's original SSH certificate; writing the user group information into the original SSH certificate to obtain the SSH certificate, and returning the SSH certificate to the client. The token access interface can be, but is not limited to, the GitLab / oauth / token interface. Writing the user group information into the original SSH certificate can be done by writing the user group information into the Principals of the original SSH certificate, enabling SSH to obtain the GitLab user and their group, and thus determine SSH login based on GitLab permissions.

[0055] The GitLabOIDC protocol is a derivative protocol of the open standard OAuth 2.0 implemented by GitLab. It is used to securely transmit user identity claims across systems, provide external systems with a verifiable source of user identity, and support third-party services in real-time querying of GitLab permissions.

[0056] Step 106: Compare the list of allowed server group labels and user group information in the spaceborne intelligent computing server to control SSH login permissions for the client.

[0057] The onboard intelligent computing server pre-stores a list of server group tags, or server tag group list, which identifies the access group to which the server belongs and the users who can access the server. For example, it defines which GitLabGroup members can log in to the current server. The server tag group list is maintained by the administrator in the form of a configuration file on the server side. The allowed server group tag list in the onboard intelligent computing server is compared with the user group information, that is, the user group to which the user currently belongs is determined based on the group information; based on the user group, the servers that the user can access can be determined. When the server goes online for the first time, it applies for a server certificate from a CA. The certificate contains server identity information, which facilitates automatic trust by clients.

[0058] A spaceborne intelligent computing server can be a collection of heterogeneous computing nodes deployed in a ground-based R&D environment, including physical or virtual hosts such as jump servers and test board servers. It is used to host the compilation, deployment, debugging, and testing tasks of spaceborne software and is the target resource for SSH access control. Users are prohibited from modifying the server's SSH configuration and server tag information. Server permission tags are maintained by the administrator to ensure the immutability of access boundaries.

[0059] For example, the list of allowed server group labels and user group information in the onboard intelligent computing server are compared. If there is an overlap between the group in the user certificate's Principals and the server's list of allowed groups, it means that one of the user's groups is one of the groups allowed by the server. In this case, the server considers the user to have access rights, authorization is granted, and the server automatically creates the user's local or working directory. If there is no overlap, meaning that none of the user's groups are in the server's list of allowed groups, the server determines that the user does not have access rights and denies authorization. This associates the GitLab group's membership and permission information with the SSH certificate's Principals, thereby achieving fine-grained access control based on GitLab groups.

[0060] The aforementioned network protocol login access control method obtains user group information by calling the token access interface based on the GitLab OIDC protocol and writes the user group information into the client's SSH certificate. This means GitLab permissions are written into the SSH certificate. Therefore, when responding to a user's SSH login request initiated by the client, it only needs to obtain the SSH certificate carried in the SSH login request. The user group information in the SSH certificate is compared with the allowed server group label list and user group information on the server to control SSH login permissions for the client. This method writes GitLab permissions into the SSH certificate and uses this for access control on the server, enabling SSH login permissions to be directly based on GitLab permission snapshots. This unifies GitLab permissions and server SSH access permissions, eliminating the need for separate SSH permission configuration and saving resources.

[0061] In one exemplary embodiment, the list of allowed server group labels and user group information in the spaceborne intelligent computing server are compared to control SSH login permissions for clients, including:

[0062] The system obtains the public key sent by the certificate authority service and verifies the validity of the SSH certificate based on the public key. After successful verification, the onboard intelligent computing server loads its own list of allowed server group labels and compares the server group label list with the user group information. If the intersection of the server group label list and the user group information is not empty, the system controls the user's SSH login permission authorization.

[0063] The public key can be an asymmetric encryption key used to verify the signature of an SSH certificate, generated and publicly distributed by a certificate authority service. It can be used on the server side to verify the digital signature of the SSH certificate, ensuring it was issued by a trusted authority and has not been tampered with.

[0064] Validation of an SSH certificate can be a process of verifying, through cryptographic means, whether the certificate was legitimately issued by a designated certificate authority. It can be used to exclude forged, expired, or revoked certificates, ensuring the authenticity and integrity of identity credentials. Validating an SSH certificate based on its public key can involve using asymmetric encryption algorithms (such as RSA and ECDSA) to verify whether the digital signature of the SSH certificate matches the public key and to check attributes such as the certificate's validity period.

[0065] Understandably, SSH login checks certificate validity; if the certificate is expired, login will be denied. Therefore, users need to update their certificates regularly to ensure the information in the certificate is up-to-date. The CA sets a short validity period for the certificate (e.g., 8 hours) to ensure permissions are dynamically updated with the group. This means that SSH access permissions on the server are dynamically updated based on user permissions in GitLab. For example, when a user's role in GitLab changes, their SSH access permissions on the server are automatically adjusted.

[0066] In the above embodiments, by verifying the validity of the SSH certificate and then comparing the server group label list with the user group information, it can be ensured that SSH login permissions are dynamically updated with the Group.

[0067] In one exemplary embodiment, such as Figure 2 As shown, a network protocol login access control method is provided, including the following steps:

[0068] Step 202: In response to the SSH login request initiated by the user based on the client, obtain the SSH certificate carried in the SSH login request.

[0069] Step 204: Parse the SSH certificate to obtain the user's email address.

[0070] Step 206: By calling the GitLab interface, obtain the latest user group information of the client based on the user's email address.

[0071] Step 208: Compare the server group label list with the latest user group information to control SSH login permissions for users.

[0072] The user email address can be a unique electronic user email address registered in the GitLab system. It serves as a global identifier for identification, an index key for querying the user's real-time permission status, and a means to call the GitLab interface to obtain the latest membership relationships.

[0073] By calling the GitLab API, the latest user group information of the client can be obtained based on the user's email address. This can be achieved by constructing an API request containing the user's email address as a parameter, initiating a call to the GitLab user query interface, and parsing the user's group membership relationships from the returned JSON data. Furthermore, by calling the GitLab API, the latest user group information of the client can be obtained by using a service-level token to batch query the permission status of multiple users, thereby obtaining the user's current actual permission ownership in GitLab and improving the accuracy and timeliness of authorization decisions.

[0074] In the above embodiments, by obtaining the user's email address from the certificate, access control judgment based on the latest permission status can be realized, enabling the server access control to respond instantly to permission changes in GitLab. This is suitable for real-time verification scenarios or model teams with frequent permission changes.

[0075] In one exemplary embodiment, such as Figure 3 As shown, a network protocol login access control method is provided. This embodiment illustrates the method by applying it to a certificate issuance structure service, and includes the following steps:

[0076] Step 302: Obtain the client's user identity token by calling the token access interface through the GitLab OIDC protocol.

[0077] Step 304: Parse the user identity token to obtain the user group information of the corresponding user;

[0078] Step 306: Obtain the client's original SSH certificate, write the user group information into the original SSH certificate to obtain the SSH certificate, so that when the user initiates an SSH login request to the spaceborne intelligent computing server based on the client, the spaceborne intelligent computing server can control the client's SSH login permissions according to the user group information in the SSH certificate.

[0079] For example, a user initiates an authentication request to a Certificate Authority (CA). The CA, through the GitLab OIDC protocol, calls the GitLab / oauth / token interface to obtain the client's user identity token. It then parses the token to obtain the corresponding user's group information, email address, and user identifier. To generate an SSH key pair, the CA generates the client's original SSH certificate based on this key pair, writes the group information into the Principals of the original SSH certificate, and returns the SSH certificate to the client. The token access interface can be, but is not limited to, the GitLab / oauth / token interface. This can be understood as writing the username, email address, and group information into the certificate. The group information specifically corresponds to a software development project. Once the software is developed and deployed on a server, being able to access the code also means being able to log in to the server for development and debugging.

[0080] In the above embodiments, identity information and user group information are obtained through OIDC and written to the user's SSH certificate in the form of certificate Principals. This establishes a permission mapping system between GitLab Group and SSH certificate Principals, realizing the unification of GitLab permissions and server SSH access permissions. There is no need to configure SSH permissions separately, saving resources.

[0081] Optionally, in an exemplary embodiment, the user identity token includes a user email address, and the method further includes: writing the user email address into an SSH certificate, so that when a user initiates an SSH login request to the onboard intelligent computing server based on a client, the onboard intelligent computing server obtains the latest user group information based on the user email address in the SSH certificate, and performs SSH login permission control on the client based on the latest user group information.

[0082] Optionally, in an exemplary embodiment, the method further includes: obtaining the validity period of the SSH certificate; if the validity period of the SSH certificate is not a preset validity period, triggering the generation of a certificate update instruction; and in response to the certificate update instruction, executing the step of calling the token access interface through the GitLab OIDC protocol to obtain the client's user identity token, thereby obtaining the updated SSH certificate. This approach, by setting a validity period for the SSH certificate, ensures that SSH login permissions are automatically updated as GitLabGroup changes, mitigating the risk of long-term credentials.

[0083] In one exemplary embodiment, such as Figure 4The diagram illustrates a spaceborne intelligent computing scenario using a network protocol login access control method. This scenario includes a client, a step-ca server (certificate authority server), server nodes, and a GitLab service. Server nodes may include jump server 1, jump server 2, board 1, board 2, and board 3. Jump server 1 and board 1 are configured with CA and sshd (configuration of certificate authority and secure remote login service). Communication connections are established between the client, the step-ca server (certificate authority server), server nodes, and the GitLab service. It should be noted that the number of jump servers and boards in this scenario is for illustrative purposes only; the actual number can be adjusted according to specific needs.

[0084] The user initiates an authentication request to the CA via the client. The CA calls the GitLab / oauth / token interface according to the GitLab OIDC protocol to obtain the user ID token. The CA parses the user ID token to obtain the user identifier (sub), the user email address, and user group information. The CA generates an SSH key pair for the client user using the configured Step CLI (i.e., configuration step command-line tool), generates an SSH certificate based on the SSH key pair, writes the user group information into the SSH certificate principals, sets the validity period of the SSH certificate, and returns the final SSH certificate to the client. The user ID token is used after the client successfully logs in via SSO (Single Sign-On).

[0085] When a server node (also called a server) first comes online, it applies for a server certificate from a CA. The server certificate contains the server's identity information so that clients can automatically trust it.

[0086] Users connect to the server (such as a jump server, expansion card, etc.) using a client carrying an SSH certificate. The server verifies the validity of the SSH certificate using a CA public key. If valid, the server loads its own list of allowed server group tags, which can only be modified by the administrator. The server compares its own list of allowed server group tags with the user group information parsed from the SSH certificate; if they overlap, authorization is granted. It's understandable that if the initial login verification is successful, the server will automatically create a local account or working directory for the user; and the logged-in user will not have permission to modify the SSH configuration file or the server group tag list.

[0087] Furthermore, in situations where real-time dynamic permission verification is required, the server can parse the SSH certificate to obtain the user's email address; by calling the GitLab interface, it can retrieve the latest user group information of the client based on the user's email address; and compare the server's group tag list with the latest user group information to control the user's SSH login permissions.

[0088] In the above embodiments, fine-grained access control for SSH login is achieved based on a self-built GitLab and Certificate Authority (CA) service. User identity and user group information are obtained through OIDC and written to the SSH certificate as certificate principals, enabling unified access management capabilities unique to spaceborne scenarios. When a user logs in, the user group information carried in the SSH certificate is compared with the list of allowed server group tags on the server to confirm whether the user is authorized to log in. In addition to offline certificate access control using certificate principal verification, a real-time API query mode is also supported, allowing real-time querying of user group information via the GitLab API to ensure real-time performance. Furthermore, it supports jump link and board-based networking environments, suitable for managing large-scale spaceborne intelligent computing clusters. It can solve the access management challenges of complex personnel, numerous devices, and frequent permission changes in spaceborne environments, significantly improving the maintainability of device and personnel permissions and engineering automation capabilities.

[0089] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0090] Based on the same inventive concept, this application also provides a network protocol login permission control system for implementing the network protocol login permission control method described above. The solution provided by this system is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more embodiments of the network protocol login permission control system provided below can be found in the limitations of the network protocol login permission control method described above, and will not be repeated here.

[0091] In one exemplary embodiment, such as Figure 5As shown, a network protocol login access control system is provided, including: GitLab service, certificate issuance structure service, server node and client, wherein:

[0092] The Certificate Issuance Structure Service is used to call the token access interface through the GitLab OIDC protocol of the GitLab service to obtain the user identity token of the client; parse the user identity token to obtain the user group information of the corresponding user; obtain the client's original SSH certificate, write the user group information into the original SSH certificate to obtain the SSH certificate, and send the SSH certificate to the client.

[0093] The server node is used to respond to SSH login requests initiated by users based on clients, obtain the SSH certificate carried in the SSH login request, parse the SSH certificate to obtain user group information, and compare the list of allowed server group labels in the server node with the user group information to control SSH login permissions for clients.

[0094] The aforementioned network protocol login access control system obtains user group information by calling the token access interface based on the GitLab OIDC protocol and writes the user group information into the client's SSH certificate. This means GitLab permissions are written into the SSH certificate. Therefore, when responding to a user's SSH login request initiated by the client, the system only needs to retrieve the SSH certificate carried in the SSH login request. It then compares the user group information in the SSH certificate with the allowed server group tag list and user group information on the server to control SSH login permissions for the client. This method writes GitLab permissions into the SSH certificate and uses this for access control on the server, enabling SSH login permissions to be directly based on GitLab permission snapshots. This unifies GitLab permissions and server SSH access permissions, eliminating the need for separate SSH permission configuration and saving resources.

[0095] In one exemplary embodiment, the server node is further configured to obtain the public key sent by the certificate issuance structure service and verify the validity of the SSH certificate based on the public key;

[0096] After successful verification, the onboard intelligent computing server loads its list of allowed server group tags and compares the list of server group tags with the user group information.

[0097] If the intersection of the server's group label list and the user group information is not empty, then the SSH login permission authorization for the user is granted.

[0098] In one exemplary embodiment, the server node is also used to parse the SSH certificate to obtain the user's email address; obtain the latest user group information of the client based on the user's email address by calling the GitLab interface; and compare the server group tag list with the latest user group information to control the user's SSH login permissions.

[0099] In one exemplary embodiment, the server node is also used to parse the SSH certificate to obtain the Principals field in the SSH certificate; and extract user group information from the Principals field.

[0100] In one exemplary embodiment, the certificate issuance structure service is also used to write the user's email address into the SSH certificate, so that when the user initiates an SSH login request to the onboard intelligent computing server based on the client, the onboard intelligent computing server obtains the latest user group information based on the user's email address in the SSH certificate, and performs SSH login permission control on the client based on the latest user group information.

[0101] In one exemplary embodiment, the certificate issuance structure service is also used to obtain the validity period of the SSH certificate. If the validity period of the SSH certificate is not a preset validity period, a certificate update instruction is generated; in response to the certificate update instruction, the SSH certificate is updated.

[0102] The modules in the aforementioned network protocol login access control system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0103] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores the data required for network protocol login access control. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a network protocol login access control method.

[0104] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0105] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0106] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0107] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0108] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0109] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0110] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0111] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for controlling login access permissions using a network protocol, characterized in that, Applied to a spaceborne intelligent computing server, the method includes: In response to an SSH login request initiated by a user based on a client, obtain the SSH certificate carried in the SSH login request; The SSH certificate is parsed to obtain user group information. This user group information is determined by the user identity token obtained by the Certificate Authority Service based on the GitLab OIDC protocol and calling the token access interface. The user group information is used to identify the user's current user group. The user group is used to determine the servers that the user is allowed to access. The list of allowed server group tags in the onboard intelligent computing server is compared with the user group information to control the SSH login permissions of the client. The method further includes: The SSH certificate is parsed to obtain the user's email address; By calling the GitLab interface, the latest user group information of the client can be obtained based on the user's email address; The server group label list is compared with the latest user group information to control the user's SSH login permissions.

2. The method according to claim 1, characterized in that, The step of comparing the list of allowed server group tags in the onboard intelligent computing server with the user group information to control SSH login permissions for the client includes: Obtain the public key sent by the certificate authority service, and verify the validity of the SSH certificate based on the public key; After successful verification, the onboard intelligent computing server loads its list of allowed server group tags and compares the list of allowed server group tags with the user group information. If the intersection of the server group label list and the user group information is not empty, then the SSH login permission authorization for the user is granted.

3. The method according to claim 1, characterized in that, The step of parsing the SSH certificate to obtain user group information includes: The SSH certificate is parsed to obtain the Principals field in the SSH certificate; Extract the user group information from the Principals field.

4. A method for controlling login access permissions using a network protocol, characterized in that, Applied to a certificate issuance structure service, the method includes: Obtain the client's user identity token by calling the token access interface through the GitLab OIDC protocol; Parse the user identity token to obtain the corresponding user group information; the user group information is used to represent the user's current user group; the user group is used to determine the servers that the user is allowed to access; Obtain the original SSH certificate of the client, write the user group information into the original SSH certificate to obtain an SSH certificate, so that when the user initiates an SSH login request to the spaceborne intelligent computing server based on the client, the spaceborne intelligent computing server can control the client's SSH login permissions according to the user group information in the SSH certificate; The user identity token includes the user's email address, and the method further includes: The user's email address is written into the SSH certificate so that when the user initiates an SSH login request to the spaceborne intelligent computing server based on the client, the spaceborne intelligent computing server obtains the latest user group information based on the user's email address in the SSH certificate, and performs SSH login permission control on the client based on the latest user group information.

5. The method according to claim 4, characterized in that, The method further includes: Obtain the validity period of the SSH certificate; if the validity period of the SSH certificate is not the preset validity period, trigger the generation of a certificate update command. In response to the certificate update instruction, the step of calling the token access interface via the GitLab OIDC protocol to obtain the client's user identity token is executed to obtain the updated SSH certificate.

6. A network protocol login access control system, characterized in that, The system includes GitLab services, certificate issuance structure services, server nodes, and clients, wherein: The certificate issuance structure service is used to call the token access interface through the GitLab OIDC protocol of the GitLab service to obtain the user identity token of the client; parse the user identity token to obtain the user group information of the corresponding user; obtain the original SSH certificate of the client, write the user group information into the original SSH certificate to obtain the SSH certificate, and send the SSH certificate to the client; the user group information is used to identify the user's current user group; the user group is used to determine the servers that the user is allowed to access; The server node is configured to respond to an SSH login request initiated by a user based on the client, obtain the SSH certificate carried in the SSH login request, parse the SSH certificate to obtain user group information, and compare the list of allowed server group tags in the server node with the user group information to control the SSH login permissions of the client. The server node is also used to parse the SSH certificate to obtain the user's email address; to obtain the latest user group information of the client based on the user's email address by calling the GitLab interface; and to compare the server group tag list with the latest user group information to control the user's SSH login permissions.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images