A hierarchical access method of a smart city social relief service system

Abstract

The application discloses a layered access control method of a rescue service system, characterized in that the method comprises the following steps: dividing access time periods and non-access time periods, and monitoring user requests in real time; in the non-access time periods, performing face recognition and dynamic password two-factor authentication on the user; after the authentication, limiting the user operation behavior to run in a sandbox environment; adding the user who continuously uses the non-access time periods to a white list; monitoring the operation behavior of the white list user, if it is determined that the user abuses, moving the user to a gray list, and restoring the two-factor authentication and sandbox isolation process; temporarily restoring the white list authority when the gray list user requests the non-access time period for the first time in a month, if the user still abuses, moving the user to a black list, and prohibiting the user to access the rescue service system in the month. The application provides a dynamic and layered access control mechanism, which can guarantee reasonable allocation of system resources, take into account the real needs and behavior credibility of the user, and thus build a more balanced service management system.

Description

Technical Field

[0001] This invention relates to access control technology for smart city social assistance service systems, specifically to a time-segmented and hierarchical dynamic authentication and blacklist management method. Background Technology

[0002] The Smart City Social Assistance Service System is a city-level emergency management platform that deeply integrates Internet of Things, big data and artificial intelligence technologies. Its core function is to accurately identify social assistance needs, dynamically allocate public resources and ensure the safety and controllability of the entire service process through intelligent means.

[0003] With the widespread adoption of smart city social assistance service systems, achieving efficient emergency response while ensuring system security has become a key challenge. In existing technologies, to improve the utilization efficiency of service resources and maintain system stability, many service systems set off-peak hours to restrict users from initiating service requests during off-peak or non-working periods. This mechanism is typically based on the following considerations: firstly, the supply capacity of service resources is limited during off-peak hours, requiring rate limiting to ensure the availability of core services; secondly, background operations such as system maintenance and data synchronization need to be performed during low-load periods to avoid interfering with normal services. However, this mechanism presents significant technical contradictions in its implementation: some users need to request services during off-peak hours due to urgent needs, but conventional rate limiting strategies result in cumbersome and inefficient operations, failing to meet their actual needs.

[0004] To address the aforementioned issues, existing technologies have proposed a simplified authentication scheme based on a whitelist. This scheme involves adding users who frequently initiate requests outside of peak hours to a whitelist based on pre-defined qualifications, allowing them to quickly access service resources through a streamlined process. However, this scheme has revealed new technical flaws in practice: because request processing efficiency is often higher during off-peak hours than during peak hours, some non-urgent users deliberately choose to initiate unnecessary requests during off-peak hours to obtain more efficient services. Such abuse results in the whitelist being mixed with genuine urgent users and malicious users, causing resource allocation imbalances and potentially exacerbating system load pressure during off-peak hours.

[0005] To address the issue of whitelist abuse, existing technologies have further introduced blacklist mechanisms. These mechanisms use behavioral analysis to flag abusive users and prohibit them from accessing service resources through the simplified whitelist process. However, this approach still has limitations: blacklisted users may genuinely have urgent needs in specific scenarios, and a blanket access restriction policy can prevent them from obtaining necessary services in a timely manner, creating a conflict between user experience and system security. Therefore, a dynamic, hierarchical access control mechanism is urgently needed that can ensure the rational allocation of system resources while also considering users' genuine needs and behavioral credibility, thereby building a more balanced service management system. Summary of the Invention

[0006] This invention provides a dynamic, hierarchical access control mechanism that can ensure the reasonable allocation of system resources while taking into account the real needs and credibility of users' behavior, thereby building a more balanced service management system.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0008] A hierarchical access control method for a smart city social assistance service system, characterized by comprising the following steps:

[0009] Divide access periods into access periods and non-access periods, and monitor user requests in real time;

[0010] During non-access periods, users are authenticated using two factors: facial recognition and dynamic password.

[0011] Once authentication is successful, user actions will be restricted to a sandbox environment.

[0012] Users who continuously and compliantly use non-access periods will be added to a whitelist;

[0013] Monitor the behavior of whitelisted users; if abuse is detected, move them to the gray list and restore the two-factor authentication and sandbox isolation process.

[0014] When a graylisted user makes their first request outside of designated access hours each month, their whitelist privileges will be temporarily restored. If they continue to abuse the system, they will be moved to the blacklist and banned from accessing the relief service system for the rest of the month.

[0015] Furthermore, the division of non-access periods is based on at least one of the following rules:

[0016] Fixed time period each day;

[0017] It is automatically triggered when the system resource load is below the threshold.

[0018] Furthermore, the daily fixed time period is dynamically adjusted according to the frequency of urban emergencies.

[0019] Furthermore, the sandbox environment's determination of user actions includes:

[0020] Keyword analysis of the request content;

[0021] Compare request frequency with historical behavior;

[0022] Manual review and intervention mechanism.

[0023] Furthermore, the emergency relief channel for graylisted users also includes: verifying the authenticity of the request through GPS location or emergency contact verification.

[0024] Furthermore, the conditions for adding a user to the whitelist are: the user submits requests for 30 consecutive days outside of access periods and has no history of abuse.

[0025] Furthermore, the dynamic password generation method includes: generating a one-time password based on a time synchronization algorithm and updating it periodically.

[0026] The beneficial effects of this invention are as follows: During non-access periods, users need to undergo two-factor authentication using "facial recognition + dynamic password." After successful verification, their actions must be isolated and run in a sandbox environment. Access is only granted after security is confirmed, preventing malicious access or misoperation during non-access periods while maintaining an emergency assistance channel. If a user submits requests during non-access periods for 30 consecutive days without abuse records, they are added to a whitelist, allowing for rapid access thereafter, reducing the operational burden on legitimate users and improving emergency response efficiency. The operations of whitelisted users are monitored in real time. If their request content is found to be inconsistent with their historical behavior, they are removed from the whitelist and added to a graylist, preventing non-emergency users from abusing whitelist privileges. When a graylisted user submits a request during a non-access period for the first time each month, their whitelist privileges are temporarily restored. If the request is determined to be genuinely urgent, they are automatically removed from the graylist. If it is determined to be abuse, they are marked as blacklisted and prohibited from accessing the assistance service system for the rest of the month, preventing the blacklist mechanism from mistakenly harming genuine emergency needs and preventing secondary abuse. This invention provides a dynamic, hierarchical access control mechanism that can ensure the reasonable allocation of system resources while taking into account the real needs and credibility of users' behavior, thereby building a more balanced service management system.

[0027] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0028] The above and other objects, features and advantages of the present invention will become clearer from the following description of embodiments of the invention with reference to the accompanying drawings, in which:

[0029] Figure 1 This is a flowchart illustrating a method provided in an exemplary embodiment of this application. Detailed Implementation

[0030] The present application is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without these details. To avoid obscuring the substance of the present application, well-known methods, processes, flows, elements, and circuits are not described in detail.

[0031] Furthermore, those skilled in the art should understand that the accompanying drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0032] In existing technologies, to improve the utilization efficiency of service resources and maintain system stability, many service systems set off-peak periods to restrict users from initiating service requests during off-peak or non-working hours. This mechanism is usually based on the following considerations: on the one hand, the supply capacity of service resources is limited during off-peak periods, and rate limiting is necessary to ensure the availability of core services; on the other hand, background operations such as system maintenance and data synchronization need to be performed during low-load periods to avoid interfering with normal services. However, this mechanism presents a significant technical contradiction in its implementation: some users need to request services during off-peak periods due to urgent needs, but conventional rate limiting strategies are cumbersome, inefficient, and fail to meet their actual needs.

[0033] To address the aforementioned issues, existing technologies have proposed a simplified authentication scheme based on a whitelist. This scheme involves adding users who frequently initiate requests outside of peak hours to a whitelist based on pre-defined qualifications, allowing them to quickly access service resources through a streamlined process. However, this scheme has revealed new technical flaws in practice: because request processing efficiency is often higher during off-peak hours than during peak hours, some non-urgent users deliberately choose to initiate unnecessary requests during off-peak hours to obtain more efficient services. Such abuse results in the whitelist being mixed with genuine urgent users and malicious users, causing resource allocation imbalances and potentially exacerbating system load pressure during off-peak hours.

[0034] To address the issue of whitelist abuse, existing technologies have further introduced blacklist mechanisms. This involves using behavioral analysis to flag abusive users and prohibiting them from accessing service resources through the simplified whitelist process. However, this approach still has limitations: blacklisted users may genuinely have urgent needs in specific scenarios, and a blanket access restriction policy could prevent them from obtaining necessary services in a timely manner, creating a conflict between user experience and system security.

[0035] This invention discloses a hierarchical access control method for a smart city social assistance service system, characterized by comprising the following steps:

[0036] S1. Divide access periods into access periods and non-access periods, and monitor user requests in real time;

[0037] S2. During non-access periods, perform two-factor authentication for users using facial recognition and dynamic passwords.

[0038] The system calls the user terminal's camera to capture real-time facial images, compares them with biometric features in a pre-stored database, and sets the matching threshold to 95%.

[0039] A 6-digit one-time password is generated based on a time synchronization algorithm and is updated every 60 seconds. Users must enter the password within its validity period; otherwise, it must be regenerated.

[0040] S3. After authentication is successful, user actions will be restricted to a sandbox environment.

[0041] After authentication, user operations are restricted to a sandbox environment. The system determines the security of operations through the following mechanisms:

[0042] Keyword analysis: Natural language processing technology is used to detect urgent keywords in the request content. If no keyword is found in the keyword database, it is marked as suspicious.

[0043] Request frequency comparison: If a user's daily request count exceeds three times the historical average, an exception warning will be triggered.

[0044] Manual review intervention: For high-risk requests (such as triggering keyword missing or abnormal frequency 3 times consecutively), the system will automatically transfer them to a human reviewer for review, and the review response time will not exceed 5 minutes.

[0045] S4. Add users who continuously comply with regulations during non-access periods to the whitelist;

[0046] S5. Monitor the operational behavior of whitelisted users. If abuse is detected, move them to the gray list and restore the two-factor authentication and sandbox isolation process.

[0047] S6. When a graylist user makes their first request outside of designated access hours each month, their whitelist privileges will be temporarily restored. If they continue to abuse the system, they will be moved to the blacklist and banned from accessing the rescue service system for the rest of the month.

[0048] Furthermore, the division of non-access periods is based on at least one of the following rules:

[0049] Fixed time period each day;

[0050] It is automatically triggered when the system resource load is below the threshold.

[0051] The default time period is from 11:00 PM to 6:00 AM the next day. The system dynamically adjusts this time period through the data analysis module. For example, if the frequency of emergency events in a certain area increases by more than 10% at night, the non-access period will be shortened to 1:00 AM to 5:00 AM.

[0052] When system resources (such as server CPU utilization) are below 30%, the system automatically enters a non-access period.

[0053] During non-access periods, users must undergo two-factor authentication using "facial recognition + dynamic password". Once verified, their actions must be isolated and run in a sandbox environment. Access is only granted after security is confirmed, in order to prevent malicious access or accidental operations during non-access periods, while also maintaining an emergency assistance channel.

[0054] Furthermore, the daily fixed time period is dynamically adjusted according to the frequency of urban emergencies.

[0055] Furthermore, the sandbox environment's determination of user actions includes:

[0056] Keyword analysis of the request content;

[0057] Compare request frequency with historical behavior;

[0058] Manual review and intervention mechanism.

[0059] Furthermore, the emergency relief channel for graylisted users also includes: verifying the authenticity of the request through GPS location or emergency contact verification.

[0060] For the first request outside of access hours each month, temporarily restore whitelist permissions and assist in verifying authenticity using the following methods:

[0061] GPS location verification: Compare the user's current location with historically frequently used locations. If the deviation exceeds 10 kilometers, the user is required to upload photos of the location.

[0062] Emergency contact verification: Automatically dials the user's preset emergency contact number. If the call is not answered within 3 minutes, it is considered suspicious.

[0063] When a graylist user submits a request outside of designated access hours for the first time each month, their whitelist privileges will be temporarily restored. If the request is deemed genuinely urgent, the user will be automatically removed from the graylist. If it is deemed an abuse, the user will be prohibited from accessing the relief service system for the rest of the month. This is to prevent the blacklist mechanism from mistakenly targeting genuine urgent needs and to prevent secondary abuse.

[0064] Furthermore, the conditions for adding a user to the whitelist are: the user submits requests for 30 consecutive days outside of access periods and has no history of abuse.

[0065] If a user submits requests outside of designated access periods for 30 consecutive days and has no history of abuse, they will be added to a whitelist and granted quick access thereafter. For example, they may only need facial recognition verification or a password to access the social assistance service system, reducing the workload for legitimate users and improving emergency response efficiency.

[0066] The actions of whitelisted users are monitored in real time. If their request content is found to be inconsistent with their historical behavior, they are removed from the whitelist and added to the graylist to prevent non-urgent users from abusing whitelist privileges.

[0067] In summary, this invention provides a technical solution whereby, during non-access periods, users must undergo two-factor authentication using "facial recognition + dynamic password." After successful authentication, their actions are isolated and run in a sandbox environment, and access is only granted after security is confirmed. This prevents malicious access or accidental operations during non-access periods while maintaining an emergency assistance channel. If a user submits requests during non-access periods for 30 consecutive days without abuse, they are added to a whitelist, allowing for rapid access and reducing the operational burden on legitimate users, thus improving emergency response efficiency. The actions of whitelisted users are monitored in real time. If a request content is detected to be inconsistent with historical behavior, the user is removed from the whitelist and added to a graylist to prevent non-emergency users from abusing whitelist privileges. When a graylisted user submits a request during a non-access period for the first time each month, their whitelist privileges are temporarily restored. If the request is deemed genuinely urgent, they are automatically removed from the graylist; if deemed abuse, they are marked as blacklisted and prohibited from accessing the assistance service system for the remainder of the month. This avoids the blacklist mechanism mistakenly targeting genuine emergency needs and prevents secondary abuse. This invention provides a dynamic, hierarchical access control mechanism that can ensure the reasonable allocation of system resources while taking into account the real needs and credibility of users' behavior, thereby building a more balanced service management system.

[0068] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the specific details described above.

[0069] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0070] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0071] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps are decomposable and / or recombinable. Such decomposition and / or recombination should be considered equivalent to the present disclosure. The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0072] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

[0073] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A hierarchical access control method for a smart city social assistance service system, characterized in that, Includes the following steps: Divide access periods into access periods and non-access periods, and monitor user requests in real time; During non-access periods, two-factor authentication, using facial recognition and dynamic password, is performed on the requesting user. Once authentication is successful, user actions will be restricted to a sandbox environment. Add users who consistently and compliantly use non-access periods to the whitelist; Monitor the behavior of whitelisted users; if abuse is detected, move them to the gray list and restore the two-factor authentication and sandbox isolation process. When a graylisted user requests access to the aforementioned relief service system for the first time each month outside of designated access hours, their whitelist privileges will be temporarily restored. If this continues to be an abuse of the system, they will be moved to the blacklist and banned from accessing the relief service system for the remainder of the month. The sandbox environment determines user actions by comparing request frequency with historical behavior.

2. The method according to claim 1, characterized in that, The division of non-access periods is based on at least one of the following rules: Fixed time period each day; It is automatically triggered when the system resource load is below the threshold.

3. The method according to claim 2, characterized in that, The fixed daily time periods are dynamically adjusted based on the frequency of urban emergencies.

4. The method according to claim 1, characterized in that, The sandbox environment's determination of user actions includes: Keyword analysis of the request content; Manual review and intervention mechanism.

5. The method according to claim 1, characterized in that, The emergency relief channels for graylisted users also include: The authenticity of the request can be verified through GPS location or emergency contact verification.

6. The method according to claim 1, characterized in that, The conditions for adding a user to the whitelist are: the user submits requests for 30 consecutive days outside of access periods and has no history of abuse.

7. The method according to claim 1, characterized in that, The dynamic password generation method includes: generating a one-time password based on a time synchronization algorithm and updating it periodically.

8. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a processor-executable program, characterized in that: The processor-executable program, when executed by the processor, is used to implement the method as described in any one of claims 1 to 7.

10. A computer program product, wherein a processor-executable program is stored, characterized in that: The processor-executable program, when executed by the processor, is used to implement the method as described in any one of claims 1 to 7.

Images