Mailbox domain name verification and automatic authorization method for graph database access

Abstract

The application discloses a mailbox domain name verification and automatic authorization method for graph database access, and belongs to the technical field of graph database management, and comprises the following steps: in response to a registration request submitted by a user in a registration stage, obtaining the mailbox address of the user and extracting a domain name from the mailbox address; matching the domain name with a pre-configured blacklist domain name list, and if the matching is successful, terminating the registration and returning a failure information to the user; if the matching is not successful, matching the domain name with a pre-configured whitelist domain name list; if the domain name matches the whitelist domain name list successfully, automatically performing a permission allocation operation for the user, and the permission allocation operation at least comprises adding the user to a pre-configured target user group; and if the domain name does not match the whitelist domain name list, completing a basic registration process of the user. The application not only significantly improves the registration security and controllability, but also realizes the automation and efficiency improvement of permission management, and guarantees the high availability and maintainability of the system.

Description

Technical Field

[0001] This invention relates to the field of graph database management technology, and in particular to a method for email domain name verification and automatic authorization for graph database access. Background Technology

[0002] With graph database technology widely applied in core business areas such as enterprise knowledge graphs, intelligent operations and maintenance, and relationship analysis, ensuring secure access to internal document sites and query platforms has become a critical challenge. These systems typically contain highly interconnected sensitive data, thus requiring strict identity and access control. To avoid redundant development, many enterprises choose unified identity authentication and access management platforms such as Keycloak to build their graph database system's portal authentication system.

[0003] Keycloak natively supports email-based user self-registration; however, this general mechanism has significant shortcomings when facing enterprise-level security requirements in the specific scenario of graph databases.

[0004] 1. The sensitivity of graph database permissions conflicts with enterprise compliance requirements: Data in graph databases is highly interconnected, posing a high risk of permission leaks. Enterprises typically mandate the use of internal email domains (such as @company.com) for registration to verify employee identities and prevent data leaks from unauthorized external email registrations. Keycloak does not allow such restrictions on registered email domains by default.

[0005] 2. Lack of fine-grained domain name control for graph database businesses: Keycloak does not provide fine-grained verification of registered email domains by default. Existing technologies typically require custom development to implement domain filtering, and struggle to flexibly address the diverse needs of multiple branches within an enterprise (e.g., allowing subdomains like @shanghai.company.com and @rd.company.com to access the graph database). Furthermore, it lacks dynamic management capabilities for domain name verification rules. When the graph database project team needs to temporarily grant access to specific domains for partners, traditional hard-coding methods require service restarts, resulting in slow response times and impacting business agility.

[0006] 3. Graph database access permissions cannot be automatically granted during authentication: After a user successfully registers using their corporate email address, the system cannot automatically associate them with the corresponding access role in the graph database (such as "Graph Queryer" or "Data Maintainer"). Administrators still need to manually assign permissions in Keycloak or the graph database backend. This manual intervention is inconsistent with the agile and intelligent technology image represented by graph databases, introducing management delays and operational risks, and failing to achieve the automated process of "granting basic graph database access upon successful authentication."

[0007] 4. The contradiction between rigid operation and maintenance configurations and the rapid development of graph database services: The services supported by graph databases are usually in a state of rapid iteration, and their access control policies need to be adjusted frequently. Static configurations of domain name lists and permission mappings cannot meet the needs of dynamic operation and maintenance, becoming a bottleneck for the security operation and maintenance of graph database systems.

[0008] Therefore, existing technologies have prominent problems in the integration of graph databases and identity authentication systems, such as lack of email domain control, non-automatic permission granting, and slow operation and maintenance response. There is an urgent need for a solution that can be deeply integrated, dynamically configured, and automatically linked. Summary of the Invention

[0009] The purpose of this invention is to provide a method for email domain name verification and automatic authorization for graph database access, in order to solve the problems that existing identity authentication technologies cannot dynamically verify email domain names during the user registration process and cannot automatically complete graph database access authorization based on the verification results when integrated with graph database systems.

[0010] To achieve the above objectives, this application adopts the following technical solution:

[0011] This application discloses a method for email domain name verification and automatic authorization for graph database access, comprising the following steps:

[0012] In response to a user's registration request during the registration phase, obtain their email address and extract the domain name from it;

[0013] The extracted domain name is matched with a pre-configured blacklist of domain names. If a match is found, the registration is terminated and a failure message is returned to the user.

[0014] If a match is not found, the domain name will be matched against a pre-configured whitelist of domain names.

[0015] If the domain name matches the whitelist of domain names, then the permission allocation operation is automatically performed for the user. The permission allocation operation includes at least adding the user to a pre-configured target user group.

[0016] If the domain name does not match the whitelist of domain names, the user's basic registration process is completed.

[0017] Preferably, after adding the user to a pre-configured target user group, a notification process is triggered, which includes:

[0018] Send an email notification to the user, the email notification containing the target user group information, the user account email address, and the graph database document site access address;

[0019] Send permission granting notifications to system administrators via Webhook.

[0020] Preferably, the step of sending the permission granting notification to the system administrator via Webhook includes:

[0021] Construct a notification message body, which includes a user identifier, email address, name of the group joined, document site access address, and single sign-on site address;

[0022] In response to the existence of a pre-configured signing key, a digital signature is generated based on the current timestamp and the signing key;

[0023] The digital signature and timestamp are appended as query parameters to the URL of the Webhook request;

[0024] The notification message body is sent to a preset Webhook address via an HTTP request.

[0025] Preferably, after triggering the notification process, a group relationship adjustment operation is also performed, which includes at least one of the following:

[0026] Remove the user from the pre-configured removal group, wherein if the removal group is the same as the target user group, this operation is skipped;

[0027] The user is added to a pre-configured additional add group, where this operation is skipped if the additional add group is the same as the target user group.

[0028] Preferably, in response to the registration request, the currently effective system configuration is obtained, which includes at least one of the following: blacklist domain name list, whitelist domain name list, target user group, document site access address, Webhook address, user group to be removed, and user group to be added.

[0029] The system configuration supports dynamic updates. Changes to configuration items take effect immediately on subsequent registration requests without requiring a service restart or component redeployment.

[0030] As a preferred method, domain name matching uses either exact match or subdomain suffix match.

[0031] Preferably, the method is embedded into the registration process of the identity authentication system through a form action component;

[0032] The matching operations for the blacklist and whitelist are both performed during the form verification phase. The matching result of the blacklist is used to determine whether to terminate the registration, and the matching result of the whitelist is passed to the registration success phase to trigger the permission allocation operation when the registration is successful.

[0033] Preferably, the extracted domain name includes:

[0034] Locate the index position of the last @ symbol in the email address string;

[0035] If the at symbol exists, the substring following it is taken as the domain name, and the domain name is converted to lowercase and the leading and trailing whitespace characters are removed.

[0036] If the at symbol does not exist, an empty string is returned.

[0037] Preferably, the email domain verification and permission allocation operations are not performed during the user login phase, so that the login behavior of registered users is not affected by the update of the list.

[0038] Preferably, when an exception occurs during permission allocation, notification sending, or group adjustment operations, the method captures and records the exception while maintaining the final completion state of the user registration process to ensure the availability of core registration functions.

[0039] This invention encapsulates functions such as black / white list management, automated permission granting, instant message notification, and user group relationship management into a loosely coupled, configurable, and hot-update independent execution unit, which is then embedded into the registration process of an identity authentication system. This has the following beneficial effects:

[0040] 1. Significantly improve registration security and controllability: Through the blacklist domain matching mechanism, registration requests from high-risk or unauthorized private email domains can be effectively intercepted at the registration source, building the first line of security defense and greatly improving the security benchmark for user access.

[0041] 2. Automating and Improving the Efficiency of Access Control: Through a whitelist domain matching mechanism, users from internal member domains are granted authorization upon registration. The system automatically completes the allocation of access groups, closing the traditional access control process that required manual intervention from administrators. This reduces manual steps and delays, greatly improving the efficiency and accuracy of access control configuration.

[0042] 3. Enhanced System Observability and Operational Closed Loop: Through Webhook notification functionality integrated with external systems (such as group chat bots), administrators or relevant parties can be notified in real time when whitelisted users successfully register and authorize. This not only enhances the observability of the registration process but also forms a complete operational closed loop from registration and authorization to notification, facilitating timely tracking and auditing.

[0043] 4. Ensuring high availability and maintainability: The loosely coupled design of components and the ability to dynamically update configurations ensure the stability and high availability of the core registration process. Even if additional services (such as notifications and complex group policies) experience temporary anomalies, normal user registration will not be affected. Furthermore, configuration changes take effect immediately without requiring a service restart, significantly reducing system maintenance costs and complexity. Attached Figure Description

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

[0045] Figure 1 This is a flowchart of a method for email domain name verification and automatic authorization for graph database access provided in an embodiment of this application;

[0046] Figure 2 This is a flowchart of the domain name extraction process provided in an embodiment of this application;

[0047] Figure 3 This is a schematic diagram of the notification process provided in an embodiment of this application;

[0048] Figure 4 This is a flowchart of the sending permission activation notification provided in the embodiments of this application. Detailed Implementation

[0049] To make the technical solution of this application clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The terms "first," "second," etc., in the claims and specification of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate. This is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of units is not necessarily limited to those units, but may include other units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0050] This embodiment provides a method for email domain name verification and automatic authorization for graph database access. This method is deeply integrated into the user registration process of an identity authentication system. By embedding automated verification logic at key registration nodes, it achieves efficient verification and fine-grained access control of user email domain names. The core of this method lies in its dual verification mechanism of blacklist interception and whitelist authorization, combined with dynamically configurable system parameters, which greatly improves the efficiency and flexibility of authorization management while ensuring security.

[0051] like Figure 1 As shown, the method specifically includes the following steps:

[0052] S110. In response to the registration request submitted by the user during the registration phase, obtain the user's email address and extract the domain name from it;

[0053] S120. Match the extracted domain name with the pre-configured blacklist domain name list. If the match is successful, terminate the registration and return a failure message to the user.

[0054] S130. If the match fails, the domain name will be matched with the pre-configured whitelist of domain names.

[0055] S140. If the domain name matches the whitelist of domain names, the permission allocation operation is automatically performed for the user. The permission allocation operation includes at least adding the user to the pre-configured target user group.

[0056] S150. If the domain name does not match the whitelist of domain names, the user's basic registration process is completed.

[0057] In this embodiment, when a user submits a registration form through the registration page, the system will trigger blacklist blocking and whitelist access operations for email domains to ensure that only users with legitimate domains can complete registration or obtain automatic authorization.

[0058] Specifically, after the user fills out and submits the registration form, the system enters the form verification stage. The component directly obtains and decodes the form parameters from the user's submitted HTTP request, focusing on reading the email field and performing preliminary checks. If the email field is empty or contains only blank characters, the case is handed over to the general verification module for processing, such as returning an error message and requiring the user to re-enter the information. If the email field is not empty, the system obtains the user's email address based on the user's registration request and extracts the domain name from it.

[0059] In some embodiments, such as Figure 2 As shown, the extracted domain names include:

[0060] S210. Locate the index position of the last aitem in the email address string;

[0061] S220. If an at symbol exists, extract the substring following it as the domain name, convert the domain name to lowercase and remove leading and trailing whitespace characters.

[0062] S230. If the at symbol does not exist, return an empty string.

[0063] The domain name extraction process employs a robust design to accommodate potential user input errors. Specifically, the system parses the email address string and locates the index of the last @ symbol. This design considers the possibility of the user accidentally entering multiple @ symbols, such as user@example@domain.com. In this case, the system uses the last @ symbol as the reference and extracts the substring following it as the domain name, e.g., extracting "domain.com" in this example. If the email address does not contain the @ symbol, an empty string is returned, indicating that domain name extraction has failed. After successfully extracting the domain name, the system performs normalization, converting the domain name to lowercase and removing leading and trailing whitespace. This operation ensures the consistency and accuracy of subsequent matching operations, avoiding misjudgments caused by differences in capitalization or spaces.

[0064] After obtaining the canonicalized domain name, the system enters the blacklist matching phase. The system matches the extracted domain name with a pre-configured blacklist of domain names (emailDomainBlacklist). The blacklist of domain names contains known malicious, invalid, or restricted domain names, used to quickly block high-risk registration requests.

[0065] In some embodiments, domain name matching employs either an exact match or a subdomain suffix match mechanism.

[0066] The matching mechanism employs either exact match or subdomain suffix match. An exact match requires the extracted domain to be exactly the same as an entry in the blacklist; a subdomain suffix match allows matching the suffix of the domain. For example, if the blacklist contains "example.com", then "sub.example.com" will also be matched. This flexible matching mechanism enhances the coverage and blocking effectiveness of the blacklist.

[0067] If the extracted domain name matches the blacklist, the system immediately terminates the registration process and returns a failure message to the user, such as "Please change to a corporate email address; the current email domain is not allowed." This operation effectively prevents unauthorized access or potential security threats. If the match fails, the system will enter the whitelist access phase.

[0068] Specifically, the system will extract and normalize the domain names and match them with a pre-configured whitelist of domain names (emailDomainWhitelist). This whitelist contains a series of trusted, authorized domain names, such as the internal company domain company.com, whose users are typically considered a trusted user group.

[0069] The matching mechanism is consistent with the blacklist matching, supporting both exact matches and subdomain suffix matches. For example, if the whitelist includes trusted.com, users with email addresses such as user@trusted.com and user@mail.trusted.com will both be successfully matched, ensuring the flexibility and coverage of the policy.

[0070] If the extracted domain name matches the whitelist, the system will not only continue the registration process but also automatically perform permission allocation upon successful registration. This operation is the core of automated authorization and includes at least adding the user to a pre-configured target user group. Adding the user to a pre-configured target user group means that the system automatically associates the newly registered user with one or more user groups that have specific access permissions, based on the whitelist policy. These user groups have been pre-defined in the graph database to have access permissions to specific subgraphs, nodes, or relationships.

[0071] In some embodiments, such as Figure 3 As shown, after adding the user to the pre-configured target user group, a notification process is triggered, which includes:

[0072] S310. Send an email notification to the user, which includes the target user group information, the user's account email address, and the graph database document site access address.

[0073] S320: Send permission granting notifications to the system administrator via Webhook.

[0074] After successfully adding a user to the target user group, the system will automatically trigger a two-way notification process to immediately inform the user of the change in permission status and notify the system administrator for recording and monitoring. This process mainly includes sending an email notification to the user and sending a permission activation notification to the administrator via a webhook.

[0075] First, the system calls a built-in email sending component (such as EmailSenderProvider) to construct and send an HTML-formatted notification email to the email address used by the user during registration, based on system configuration (such as Realm's SMTP server configuration). This email typically includes: a greeting, the name of the target user group the user has been added to, the email address used for registration, and the address to access the graph database's document site.

[0076] To ensure the robustness of the notification process, the system also incorporates a fault tolerance mechanism. If an invalid user email address is detected during the sending process, or if the email sending component (such as the SMTP service) is unavailable, the system will not interrupt the registration process. Instead, it will record the sending failure event in the application log and skip the email notification step.

[0077] In some embodiments, such as Figure 4 As shown, a permission granting notification is sent to the system administrator via Webhook, including:

[0078] S410. Construct a notification message body, which includes the user identifier, email address, name of the group joined, document site access address, and single sign-on site address.

[0079] S420. In response to the existence of a pre-configured signing key, generate a digital signature based on the current timestamp and the signing key;

[0080] S430. Append the digital signature and timestamp as query parameters to the URL of the Webhook request;

[0081] S440. Send the notification message body to the preset Webhook address via an HTTP request.

[0082] Simultaneously, the system will also send permission granting notifications to endpoints specified by the administrator via Webhook to synchronize information in real time. This embodiment uses DingTalk robot Webhook as an example for illustration. Specifically, a structured notification message body is first constructed. This message body is organized in JSON format and typically includes: message title (such as permission granting notification), the user's unique identifier in the system, the user's email address, the target user group to which the user has been added, the document access address of the graph database, and the Single Sign-On (SSO) site address.

[0083] To ensure communication security, if a Webhook signing key (webhookSecret) is pre-configured, security enhancements will be performed before initiating a request. Specifically, the system obtains the current timestamp and calculates a digital signature using the HMAC-SHA256 algorithm, along with the signing key. This digital signature is then Base64 encoded. Next, the calculated timestamp and the encoded digital signature are appended as query parameters to the pre-defined Webhook address (URL). Finally, the constructed notification message body is sent to the assembled Webhook address via an HTTP POST request.

[0084] This webhook notification feature can also be globally enabled or disabled via a configuration switch (such as webhookEnabled) to improve operational flexibility. It also adheres to the design principle of non-blocking the main process; even if a webhook request fails due to network issues or recipient service malfunctions, it will not affect the user's registration and authorization results. The system will capture such exceptions and log the error information to the application log for administrators to troubleshoot later.

[0085] In some embodiments, the notification process is further followed by performing a group relationship adjustment operation, which includes at least one of the following:

[0086] Remove the user from the pre-configured removal group, skipping this operation if the removal group is the same as the target user group;

[0087] Add the user to a pre-configured additional add group. If the additional add group is the same as the target user group, skip this operation.

[0088] After successfully triggering the two-way notification process between the user and the administrator, the system will further perform a group relationship adjustment operation. This operation aims to fine-tune the user's group relationships to ensure the accuracy and optimization of their permission configuration, and is a crucial step in achieving flexible and automated permission management. This operation includes at least one of the following, all of which adhere to the principle of "avoiding redundant operations":

[0089] 1. Remove users from pre-configured removal groups

[0090] The system first checks if a pre-configured group that needs to be removed after notification exists (such as the `removeGroup` configuration item). If the group exists, the system checks if the current user is a member. If so, the system automatically performs the `leaveGroup` operation, removing the user from the group. If the group specified here has the same name as the previously automatically added "target user group," the system will skip this removal operation.

[0091] 2. Add the user to a pre-configured additional join group.

[0092] Simultaneously, the system will check if there are any pre-configured groups that need to be added after notification (such as the configuration item extraJoinGroup). If the group exists, the system will verify whether the current user has not yet joined the group. If so, the system will automatically perform the (joinGroup) operation to add the user to this additional join group. If the additional join group specified here has the same name as the previously automatically joined "target user group", the system will skip this join operation (because the user has already joined).

[0093] Group relationship adjustment operations are seamlessly integrated into the main registration and authorization process, and are executed immediately after the notification process.

[0094] If the extracted domain name does not match the whitelist, it indicates that the email domain is neither on the blacklist nor the whitelist, and is therefore an unknown or pending domain. In this case, the system will execute the user's basic registration process. This process only completes the most basic account creation and typically does not include any special access permissions to the graph database, or only grants extremely limited default permissions. Subsequent manual review and permission allocation by the administrator may be required to ensure database access security and adherence to the principle of least privilege.

[0095] In some embodiments, the email domain verification and permission allocation operations are not performed during the user login phase, so that the login behavior of registered users is not affected by the update of the list.

[0096] To ensure a good user experience and predictable system behavior, this method is designed to perform email domain verification and automatic permission allocation only during the user registration phase. Specifically, during the user login phase, the system will not perform any verification related to matching email domains to blacklists or whitelists, nor will it trigger any permission allocation or adjustment operations based on the domain.

[0097] This design ensures the stability of user permission status. Once a user successfully registers, their permissions will not be automatically changed or revoked during this or subsequent logins due to subsequent updates to the whitelist / blacklist lists by the administrator (such as removing their domain from the whitelist or adding it to the blacklist). This governance model of "strict entry control and flexible operation" avoids unexpected and uncontrollable fluctuations in the access permissions of registered users due to dynamic adjustments to system policies, ensuring business continuity and the determinism of user permissions.

[0098] In some embodiments, when an exception occurs during permission allocation, notification sending, or group adjustment operations, the method captures and records the exception while continuing to maintain the final completion state of the user registration process to ensure that the core registration function is available.

[0099] This method also ensures the availability of the core function of user registration through a robust exception handling mechanism. Specifically, during non-core operations such as permission allocation, Webhook notification sending, or user group adjustment, if any exception occurs (such as network fluctuations, non-existent target user group, external system interface timeout, etc.), the system will record detailed exception information (such as type, stack trace, and context data) in the system log for subsequent investigation and auditing by the administrator. At the same time, the system will not roll back the already successful core registration operation (i.e., user account creation) due to the failure of these additional operations, but will ignore these non-critical exceptions and return the final status of successful registration to the user.

[0100] This design achieves loose coupling and isolation between core functionality and enhanced features. It ensures that even when some auxiliary systems, such as external notification webhooks or complex group policy services, are temporarily unavailable, the core user registration process remains uninterrupted, thus providing extremely high system availability and user experience. Administrators can handle exceptions afterward based on logs without affecting real-time user registration.

[0101] In some embodiments, the method is embedded in the registration process of the identity authentication system through a form action component;

[0102] The matching operations for both the blacklist and whitelist are performed during the form validation phase. The matching results of the blacklist are used to determine whether to terminate the registration, while the matching results of the whitelist are passed to the registration success phase to trigger the permission allocation operation when the registration is successful.

[0103] This method embeds a specially designed, pluggable form action component (FormAction) into the registration process of an authentication system (such as Keycloak). This component is triggered during the form verification phase of the registration process. The matching results from the blacklist are directly used to determine whether to terminate the registration and return a failure message to the user; while the matching results from the whitelist are encapsulated as a flag or context information and passed to the subsequent registration success phase to trigger permission allocation operations after successful account creation.

[0104] This design decouples the verification logic from the business logic. The blacklist's blocking decision responds quickly during the verification phase, ensuring security; while the authorization operation triggered by the whitelist is executed after the account is successfully persisted, ensuring the atomicity and transaction consistency of the authorization operation and avoiding the problem of dirty data where permissions have already been assigned due to account creation failure.

[0105] In some embodiments, in response to a registration request, the currently effective system configuration is obtained. The system configuration includes at least one of the following: a blacklist of domain names, a whitelist of domain names, a target user group, a document site access address, a webhook address, a user group to be removed, and a user group to be added to.

[0106] The system configuration supports dynamic updates. Changes to configuration items take effect immediately on subsequent registration requests without requiring a service restart or component redeployment.

[0107] To achieve high flexibility and maintainability, this method also introduces a dynamic system configuration mechanism.

[0108] In response to each registration request, the system retrieves the currently active system configuration in real time. These configuration items include at least:

[0109] emailDomainBlacklist: A blacklist of domain names (string);

[0110] emailDomainWhitelist: A whitelist of domain names (string);

[0111] targetGroup: The target user group (string) that will be automatically added after the whitelist is hit;

[0112] removeGroup: The group to be removed after notification (string, optional);

[0113] extraJoinGroup: The additional group to be added after the notification (string, optional);

[0114] docURL: The URL of the graph database document site (string, optional);

[0115] webhookURL: Webhook address (string, optional);

[0116] webhookEnabled: Whether to enable Webhook notifications (Boolean, optional, enabled by default);

[0117] webhookSecret: Webhook signing key (string, optional).

[0118] All system configurations support dynamic updates. After an administrator modifies any configuration item through the management interface provided by the authentication system, the change takes effect immediately on subsequent registration requests. This process does not require restarting the application service or redeploying the component, achieving true "hot updates," significantly reducing system maintenance costs and ensuring business continuity.

[0119] The system supports configuring a list of domain names in text format, separated by commas or newlines. During resolution, the system automatically filters out empty entries and whitespace characters, and converts all domain names to lowercase to ensure the accuracy and robustness of domain name matching, avoiding misjudgments caused by inconsistencies in capitalization.

[0120] To ensure the flexibility of components in different deployment environments, a multi-level fallback strategy is adopted for the resolution of critical addresses, which enhances fault tolerance.

[0121] For the Webhook address, the configuration of the executor component itself (webhookURL) is used first; if it is not configured, it will try to get it from the property of the domain (Realm) (such as dingtalkWebhookUrl); if it still does not exist, it will eventually fall back to the address predefined in the environment variable or system property (WEBHOOK_URL).

[0122] For document site access addresses, they are preferably constructed from environment variables or system properties; if not configured, a built-in fallback address is used to ensure functionality availability.

[0123] In a specific application scenario of this embodiment, this method is triggered when a user fills out and submits a registration form through the registration page of the identity authentication system.

[0124] The system first enters the form validation phase. The form action component integrated here directly obtains and parses the form parameters from the submitted HTTP request, focusing on reading the email field. The component performs a preliminary non-empty check: if the email field is empty or contains only blank characters, this exception is handled by the system's general validation module; if the email field is valid, the complete process from S110 to S150 is executed, achieving automated validation and authorization of the email domain.

[0125] This method encapsulates functions such as black / white list management, automated permission granting, instant message notification, and user group relationship management into a loosely coupled, configurable, and hot-update independent execution unit, and embeds it into the registration process of the identity authentication system. This approach offers the following significant advantages:

[0126] 1. Significantly improve registration security and controllability: Through the blacklist domain matching mechanism, registration requests from high-risk or unauthorized private email domains can be effectively intercepted at the registration source, building the first line of security defense and greatly improving the security benchmark for user access.

[0127] 2. Automating and Improving the Efficiency of Access Control: Through a whitelist domain matching mechanism, users from internal member domains are granted authorization upon registration. The system automatically completes the allocation of access groups, closing the traditional access control process that required manual intervention from administrators. This reduces manual steps and delays, greatly improving the efficiency and accuracy of access control configuration.

[0128] 3. Enhanced System Observability and Operational Closed Loop: Through Webhook notification functionality integrated with external systems (such as group chat bots), administrators or relevant parties can be notified in real time when whitelisted users successfully register and authorize. This not only enhances the observability of the registration process but also forms a complete operational closed loop from registration and authorization to notification, facilitating timely tracking and auditing.

[0129] 4. Ensuring high availability and maintainability: The loosely coupled design of components and the ability to dynamically update configurations ensure the stability and high availability of the core registration process. Even if additional services (such as notifications and complex group policies) experience temporary anomalies, normal user registration will not be affected. Furthermore, configuration changes take effect immediately without requiring a service restart, significantly reducing system maintenance costs and complexity.

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

Claims

1. A mailbox domain name verification and automatic authorization method for graph database access, characterized in that, Includes the following steps: In response to a user's registration request during the registration phase, obtain their email address and extract the domain name from it; The extracted domain name is matched with a pre-configured blacklist of domain names. If a match is found, the registration is terminated and a failure message is returned to the user. If a match is not found, the domain name will be matched against a pre-configured whitelist of domain names. If the domain name matches the whitelist of domain names, then the permission allocation operation will be automatically performed for the user. The permission allocation operation includes at least adding the user to a pre-configured target user group; If the domain name does not match the whitelist of domain names, the user's basic registration process is completed. The system configuration supports dynamic updates, and changes to the configuration items take effect immediately on subsequent registration requests without requiring a service restart or component redeployment. During the user login phase, the email domain verification and permission allocation operations are not performed, so that the login behavior of registered users is not affected by the update of the domain name list; When an exception occurs during permission allocation, notification sending, or group adjustment operations, the method captures and records the exception while maintaining the final completion state of the user registration process to ensure the availability of core registration functions.

2. The mailbox domain name verification and automatic authorization method for graph database access according to claim 1, characterized in that, After adding the user to a pre-configured target user group, a notification process is triggered, which includes: Send an email notification to the user, the email notification containing the target user group information, the user account email address, and the graph database document site access address; Send permission granting notifications to system administrators via Webhook.

3. The email domain name verification and automatic authorization method for graph database access according to claim 2, characterized in that, The step of sending permission granting notifications to system administrators via Webhook includes: Construct a notification message body, which includes a user identifier, email address, name of the group joined, document site access address, and single sign-on site address; In response to the existence of a pre-configured signing key, a digital signature is generated based on the current timestamp and the signing key; The digital signature and timestamp are appended as query parameters to the URL of the Webhook request; The notification message body is sent to a preset Webhook address via an HTTP request.

4. The email domain name verification and automatic authorization method for graph database access according to claim 2, characterized in that, Following the notification process, a group relationship adjustment operation is performed, which includes at least one of the following: Remove the user from the pre-configured removal group, wherein if the removal group is the same as the target user group, this operation is skipped; The user is added to a pre-configured additional add group, where this operation is skipped if the additional add group is the same as the target user group.

5. The mailbox domain name verification and automatic authorization method for graph database access according to claim 1, characterized in that, In response to the registration request, obtain the currently effective system configuration, which includes at least one of the following: blacklist domain name list, whitelist domain name list, target user group, document site access address, Webhook address, user group to be removed, and user group to be added.

6. The mailbox domain name verification and automatic authorization method for graph database access according to claim 1, characterized in that, Domain name matching uses either an exact match or a subdomain suffix match mechanism.

7. The mailbox domain name verification and automatic authorization method for graph database access according to claim 1, characterized in that, The method embeds a form action component into the registration process of the identity authentication system; The matching operations for the blacklist and whitelist are both performed during the form verification phase. The matching result of the blacklist is used to determine whether to terminate the registration, and the matching result of the whitelist is passed to the registration success phase to trigger the permission allocation operation when the registration is successful.

8. The mailbox domain name verification and automatic authorization method for graph database access according to claim 1, characterized in that, The extracted domain names include: Locate the index position of the last @ symbol in the email address string; If the at symbol exists, the substring following it is taken as the domain name, and the domain name is converted to lowercase and the leading and trailing whitespace characters are removed. If the at symbol does not exist, an empty string is returned.

Images