A single sign-on system, method and medium based on user permission synchronization

Abstract

This invention discloses a single sign-on system, method, and medium based on user permission synchronization. The system includes an authentication center, an application console, a message middleware, and application systems. The authentication center provides user management, authentication, authorization, and authorization functions. The application console provides links for users to access applications. The message middleware receives messages from the authentication center and distributes them to application systems that have subscribed to the messages. The application system is the business platform where users perform actual business processing. The authentication center does not immediately synchronize users to the application system upon registration; it only notifies the application system of user changes when a user requests access. This approach avoids the generation of a large number of invalid dormant users and solves the user permission synchronization and access authorization problems of single sign-on systems.

Description

Technical Field

[0001] This invention relates to the field of single sign-on technology, and in particular to a single sign-on system, method, and computer-readable storage medium based on user permission synchronization. Background Technology

[0002] Large organizations often have multiple business systems. If members need to use these systems, they typically need to enter their username and password for each system separately. This is not only cumbersome, but more importantly, the usernames and passwords for each system are not necessarily the same, making them very easy to forget. Therefore, a technical means is needed to allow users to log in once to access different systems. Currently, Single Sign-On (SSO) technology is mainly used to achieve this. A SSO system usually contains an authentication center responsible for user registration and authentication. After a user is successfully authenticated by the authentication center, a mechanism notifies each application system of the user's login status, thus achieving the goal of allowing users to access other application systems without having to re-enter their username and password.

[0003] Single sign-on systems solve the problem of users accessing different systems without authentication, but in practical applications, they still have some drawbacks:

[0004] (1) Single sign-on technology does not take into account the user's permissions in the application system. In actual application, the administrator needs to set permissions in each business system, which not only increases the maintenance cost, but also makes it difficult to centrally manage permissions.

[0005] (2) After the application system is connected to the authentication center, it will usually synchronize all the users of the authentication center to the application system, but some users may be "zombie" users in the application system.

[0006] (3) After the application system is connected to the authentication center, users who have been authenticated by the authentication center can access all application systems, which poses a certain potential risk to some systems with high security requirements. Summary of the Invention

[0007] In order to overcome the above-mentioned shortcomings and deficiencies of the prior art, the purpose of this invention is to provide a single sign-on system, method and medium based on user permission synchronization, which solves the problems of user permission synchronization and access authorization in single sign-on systems, and has the advantages of high flexibility, high security and good user consistency experience.

[0008] The objective of this invention is achieved through the following technical solution:

[0009] This invention provides a single sign-on system based on user permission synchronization, comprising an authentication center, an application console, a message middleware, and an application system:

[0010] The authentication center is used to provide user management, authentication, authorization, and authorization functions;

[0011] The application console is used to provide links for users to use the application;

[0012] The message middleware is used to receive messages from the authentication center and distribute the messages to application systems that subscribe to the messages.

[0013] The application system is a business platform for users to perform actual business processing.

[0014] The authentication center synchronizes permission messages through a message middleware to achieve data synchronization and business decoupling; the authentication center does not immediately synchronize users to the application system when registering users, but only notifies the application system through user change messages when a user requests access to the application system.

[0015] This invention also provides a single sign-on method based on user permission synchronization, including the single sign-on system as described in the above embodiments. The process of a user requesting access to the application system includes the following steps:

[0016] Users submit applications to add the system application to the certification center through the application console;

[0017] The authentication center first determines whether the user's security level is higher than the application system's security level, and then submits it to the administrator for approval;

[0018] After the administrator approves the change, the authentication center establishes a mapping relationship between the user and the application system, and then sends the user's change message to the user change message middleware. The message contains the application system ID, change type, and user information.

[0019] The application system subscribes to and parses user change messages, determines that the user is accessing this system, and then creates a new user.

[0020] In one embodiment, the process of a user accessing the application system from the application console includes the following steps:

[0021] The user clicks the application system shortcut in the application console to request to open the application system;

[0022] The application console submits the user request to the authentication center. The authentication center determines whether the mapping relationship between the user and the application system exists. If it exists, it generates a user credential and returns it to the application console; otherwise, it refuses to log in to the application system.

[0023] The application console redirects to the application system page by including user credentials in the URL;

[0024] After receiving an access request, the application system first checks whether the user exists. If the user exists, the system sends the user's credentials to the authentication center for verification; otherwise, the single sign-on process is interrupted.

[0025] The authentication center verifies the user credentials sent by the application system, and returns a success message upon successful verification.

[0026] After receiving the success message, the application system creates a session for the user and then opens the page.

[0027] In one embodiment, the single sign-on method based on user permission synchronization further includes a step of setting a security level for the user:

[0028] When a user registers at the certification center, the certification center can assign a security level to the user based on the user's role;

[0029] After a user successfully registers at the authentication center, they can apply to adjust their security level, which will take effect after administrator approval.

[0030] In one embodiment, the single sign-on method based on user permission synchronization further includes the step of setting a security level for the application system:

[0031] The certification center predefines the security level for each application system, and the security level of the application system is consistent with the user's security level.

[0032] When a user requests access to the application system, the user's security level is first compared with the application system's security level.

[0033] If the security level of the application system is equal to or lower than the user's security level, the user's request to access the application system is approved.

[0034] If the application system's security level is higher than the user's security level, the user's request to access the application system will be rejected.

[0035] In one embodiment, the definition of the user's security level and the application system's security level includes one or more of numbers, letters, and strings.

[0036] In one embodiment, the authentication center is also used to uniformly control the internal permissions of the application system, which include module authorization, menu authorization, and function authorization. The authentication center receives permission registration requests from various applications through an API interface, and the application system can register and modify the permissions involved in the system with the authentication center.

[0037] Module licensing refers to granting a user the authorization to use a specific module within an application system;

[0038] Menu authorization refers to granting certain menus within a module of an application system to a user;

[0039] Function authorization refers to granting users specific functions within a menu. These functions may include clicking a button, editing a text box, or reading data.

[0040] In one embodiment, the user authorization process for internal permissions of the application system includes the following steps:

[0041] Users can query the user management permissions on the application system in the application console and request those permissions;

[0042] The authentication center determines the requested permissions: whether the user's security level is higher than the security level of the permission. If the result is yes, the user is prompted and the application process ends; otherwise, the next step is executed.

[0043] Administrators approve user permission requests;

[0044] The authentication center archives user permissions;

[0045] The authentication center sends a permission change message to the message middleware, which includes the system ID, user ID, and permission ID.

[0046] The application system subscribes to the permission change message from the message middleware, finds that the system ID is this system, and then parses the message;

[0047] The application system parses the user ID and permission ID in the message, archives the user permissions, or queries the authentication center for user permission information based on the user ID and updates it locally;

[0048] Users perform user management operations in the application system. Once the application system authenticates and approves the user, it opens the application.

[0049] Optionally, when the application system cannot find user permissions, it can proactively query the authentication center via API and update the user permissions locally.

[0050] In one embodiment, the process of a user accessing the application system via single sign-on before requesting internal permissions for the application includes the following steps:

[0051] The user authenticates at the authentication center, and after successful authentication, is redirected to the application console.

[0052] When a user clicks on the desired application system in the application console, the application console requests user credentials from the authentication center.

[0053] The authentication center returns user credentials to the application console, and the application console uses the user credentials to open the application system page.

[0054] After receiving the user credentials, the application system sends the user credentials to the authentication center for verification;

[0055] After the authentication center successfully verifies the user's credentials, it returns a verification success response message to the application system.

[0056] The application system creates local sessions for users.

[0057] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by an electronic device, implements the single sign-on method as described in any of the above embodiments.

[0058] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0059] (1) When registering a user, the user is not immediately synchronized with the application system. Instead, a "lazy synchronization" method is used: the application system is only notified of the user change via a user change message when the user requests access to the application system. Only the application system being accessed needs to process this message; other systems ignore it, thus avoiding the generation of a large number of invalid dormant users. Only the users in the authentication center are fully registered; the application system only stores users who actually need to use the system.

[0060] (2) Users can specify their security level when registering, and application systems can also specify their security level. When a user applies to access an application system, the system security is enhanced: if the user's security level is lower than the application system's security level, the authentication center will terminate the application to prevent the user from accessing an application system with a higher security level.

[0061] (3) Establish a unified authorization mechanism: Permissions at three levels—module, menu, and function—are defined in the authentication center. The authentication center receives permission registration requests from various applications through an API interface. Application systems can register and modify the permissions involved in their systems with the authentication center, facilitating dynamic adjustments based on business needs. The authentication center can uniformly authorize modules, menus, and functions of application systems for users. After authorization, a user permission change message is sent to the message middleware, and the application system subscribes to the user permission change message. The application system filters out messages that require processing based on the system ID in the message, and then archives the user ID and permission ID in its own system (or queries the user permission information from the authentication center based on the user ID and updates it locally).

[0062] (4) Security levels can be set for all permissions, and users with lower security levels can be strictly restricted from obtaining permissions with higher security levels.

[0063] (5) The authentication center synchronizes permission messages through message middleware to achieve data synchronization and business decoupling, avoiding mutual waiting due to the mismatch between the processing rates of the sender and receiver during the synchronization process.

[0064] (6) It supports both unified authentication by the certification center and authentication by the business system, which makes it convenient for application systems to choose flexibly. Attached Figure Description

[0065] Figure 1 This is a schematic diagram of the modules of a single sign-on system according to an embodiment of the present invention;

[0066] Figure 2 This is a flowchart illustrating a single sign-on method according to an embodiment of the present invention;

[0067] Figure 3 for Figure 1 A schematic diagram illustrating the process of a user accessing the application system from the application console.

[0068] Figure 4 for Figure 1 A flowchart illustrating the user authorization process for internal permissions in an application system.

[0069] Figure 5 for Figure 4 A flowchart illustrating the process by which a user accesses an application system via single sign-on before requesting internal permissions from the application.

[0070] Figure 6 This is a flowchart illustrating the user security level setting in a specific embodiment;

[0071] Figure 7 This is a flowchart illustrating a user's (bcd) request to access the application system in a specific embodiment.

[0072] Figure 8 This is a flowchart of the user permission request and authentication process in a specific embodiment;

[0073] Figure 9 This is a flowchart of the user requesting permissions and authentication process in a specific embodiment. Detailed Implementation

[0074] The present invention is further described below through specific embodiments, but the scope of protection of the present invention is not limited thereto.

[0075] Please see Figure 1 This invention provides a single sign-on system 100 based on user permission synchronization. The single sign-on system 100 includes an authentication center 110, an application console 120, a message middleware 130, and an application system 140.

[0076] The authentication center 110 is used to provide user management, authentication, authorization, and authorization functions;

[0077] The application console 120 is used to provide links for users to use applications;

[0078] The message middleware 130 is used to receive messages from the authentication center and distribute the messages to application systems that subscribe to the messages.

[0079] The application system 140 is a business platform for users to perform actual business processing.

[0080] The authentication center 110 does not immediately synchronize users to the application system 140 when a user registers a user. It only notifies the application system 140 of user change information when the user requests access to the application system 140.

[0081] In this embodiment, after the user is authenticated at the authentication center 110, they can select the application system 140 for handling business from the application console 120 and be directly redirected to the application system 140 without needing to perform secondary authentication.

[0082] In this embodiment, when the authentication center 110 registers a user, it does not immediately synchronize the user information to the application system 140. Instead, it uses a "lazy synchronization" method: the application system 140 is only notified of a user change via a user change message when a user requests access to the application system 140. Only the application system 140 being accessed needs to process this message; other systems ignore it, thus avoiding the generation of a large number of invalid dormant users. Only the users of the authentication center 110 are fully registered; the application system 140 only stores users who actually need to use the system.

[0083] Please see also Figure 2 The present invention also provides a single sign-on method based on user permission synchronization, including the single sign-on system 100 as described in the above embodiments. The process of a user requesting access to the application system includes the following steps:

[0084] Users submit applications to add the system application to the certification center through the application console;

[0085] The authentication center first determines whether the user's security level is higher than the application system's security level, and then submits it to the administrator for approval;

[0086] After the administrator approves the change, the authentication center establishes a mapping relationship between the user and the application system, and then sends the user's change message to the user change message middleware. The message contains the application system ID, change type, and user information.

[0087] The application system subscribes to and parses user change messages, determines that the user is accessing this system, and then creates a new user.

[0088] In one embodiment, the single sign-on method based on user permission synchronization further includes a step of setting a security level for the user:

[0089] When a user registers at the certification center, the certification center can assign a security level to the user based on the user's role;

[0090] After a user successfully registers at the authentication center, they can apply to adjust their security level, which will take effect after administrator approval.

[0091] As needed, the single sign-on method based on user permission synchronization may also include the step of setting a security level for the application system:

[0092] The certification center predefines the security level for each application system, and the security level of the application system is consistent with the user's security level.

[0093] When a user requests access to the application system, the user's security level is first compared with the application system's security level.

[0094] If the security level of the application system is equal to or lower than the user's security level, the user's request to access the application system is approved.

[0095] If the application system's security level is higher than the user's security level, the user's request to access the application system will be rejected.

[0096] In this embodiment, the definition of the user's security level and the application system's security level includes one or more of numbers, letters, and strings.

[0097] In this embodiment, users can specify their security level when registering, and application systems can also specify their security level. When a user requests access to an application system, system security is enhanced: if the user's security level is lower than the application system's security level, the authentication center will terminate the request to prevent the user from accessing an application system with a higher security level.

[0098] The authentication center predefines the security level for each application system, and this security level is consistent with the user's. Users can request access to applications with a lower security level than their own, but not vice versa. When an application to access an application is approved, the authentication center establishes a mapping relationship between the user and the application system, and simultaneously synchronizes the user data to the corresponding application system via a message broker.

[0099] Please see also Figure 3 In this embodiment, the process of a user accessing the application system from the application console includes the following steps:

[0100] The user clicks the application system shortcut in the application console to request to open the application system;

[0101] The application console submits the user request to the authentication center. The authentication center determines whether the mapping relationship between the user and the application system exists. If it exists, it generates a user credential and returns it to the application console; otherwise, it refuses to log in to the application system.

[0102] The application console redirects to the application system page by including user credentials in the URL;

[0103] After receiving an access request, the application system first checks whether the user exists. If the user exists, the system sends the user's credentials to the authentication center for verification; otherwise, the single sign-on process is interrupted.

[0104] The authentication center verifies the user credentials sent by the application system, and returns a success message upon successful verification.

[0105] After receiving the success message, the application system creates a session for the user and then opens the page.

[0106] As needed, the certification center not only provides user management and authentication functions but also a unified user authorization architecture. The certification center receives and records permission registration / modification requests from various applications via an API interface. The permission ID is consistent with the application system's permission ID, allowing the application system to dynamically adjust permissions without manual intervention and facilitating users' application for corresponding permissions.

[0107] In situations where user operation security is strictly enforced, as an optional security enhancement measure, a security level can be set for each permission, with the permission security level consistent with the user's security level definition. Only users with a security level higher than the permission's security level can be authorized; permissions without a security level are considered unrestricted. This method effectively prevents users from acquiring permissions with a higher security level than themselves. In this embodiment, by setting security levels for all permissions, it is possible to strictly prevent users with lower security levels from acquiring permissions with a higher security level than themselves.

[0108] In one embodiment, the authentication center is also used to uniformly control the internal permissions of the application system, which include module authorization, menu authorization, and function authorization.

[0109] Module licensing refers to granting a user the authorization to use a specific module within an application system;

[0110] Menu authorization refers to granting certain menus within a module of an application system to a user;

[0111] Function authorization refers to granting users specific functions within a menu. These functions may include clicking a button, editing a text box, or reading data.

[0112] In this embodiment, the single sign-on method based on user permission synchronization of the present invention not only supports the control of user access permissions when jumping from the authentication center to the application system, but also supports unified control of the internal permissions of the application system. The present invention provides three levels of authorization: module authorization, menu authorization, and function authorization. Through different combinations of these three authorization methods, the user authorization requirements within various application systems can be basically met.

[0113] In this embodiment, a unified authorization mechanism is established, defining permissions at three levels: module, menu, and function. The authentication center receives permission registration requests from various applications via an API interface. Application systems can register and modify the permissions involved in their systems with the authentication center, facilitating dynamic adjustments based on business needs. The authentication center can uniformly authorize application system modules, menus, and functions for users. After authorization, a user permission change message is sent to a message middleware, and the application system subscribes to these messages. The application system filters out messages requiring its own processing based on the system ID in the message, and then archives the user ID and permission ID to its own system (or queries the authentication center for user permission information based on the user ID and updates it locally).

[0114] Users need to be authorized in advance to use the specific functions of the application. Authorization can be done in two ways: (1) the user applies and the administrator approves and completes the authorization; (2) the administrator directly authorizes the user.

[0115] Please see also Figure 4 In one embodiment, the user authorization process for internal permissions of the application system includes the following steps:

[0116] Users can query the user management permissions on the application system in the application console and request those permissions;

[0117] The authentication center determines the requested permissions: whether the user's security level is higher than the security level of the permission. If the result is yes, the user is prompted and the application process ends; otherwise, the next step is executed.

[0118] Administrators approve user permission requests;

[0119] The authentication center archives user permissions;

[0120] The authentication center sends a permission change message to the message middleware, which includes the system ID, user ID, and permission ID.

[0121] The application system subscribes to the permission change message from the message middleware, finds that the system ID is this system, and then parses the message;

[0122] The application system parses the user ID and permission ID in the message and archives the user permissions;

[0123] Users perform user management operations in the application system, and the application system authenticates and approves the user before opening the application.

[0124] If the administrator directly authorizes the user, the step of the administrator approving the user's permission request can be omitted.

[0125] In this embodiment, the authentication center synchronizes permission messages through a message middleware, thereby decoupling data synchronization from business operations and avoiding mutual waiting due to mismatched processing rates between the sender and receiver during the synchronization process.

[0126] Please see also Figure 5 In one embodiment, the process of a user accessing the application system via single sign-on before requesting internal permissions for the application includes the following steps:

[0127] The user authenticates at the authentication center, and after successful authentication, is redirected to the application console.

[0128] When a user clicks on the desired application system in the application console, the application console requests user credentials from the authentication center.

[0129] The authentication center returns user credentials to the application console, and the application console uses the user credentials to open the application system page.

[0130] After receiving the user credentials, the application system sends the user credentials to the authentication center for verification;

[0131] After the authentication center successfully verifies the user's credentials, it returns a verification success response message to the application system.

[0132] The application system creates local sessions for users.

[0133] Another way to synchronize user permission data is for the application system to query the authentication authority for the user's specific or full permissions based on the user ID, and then update the permissions in the application system. The typical difference between these two methods is that the former is suitable for changing a single permission, while the latter is suitable for initially assigning permissions or verifying and correcting permission data.

[0134] This method enables centralized access control across multiple application systems. This invention not only addresses the access control requirements of application systems by supporting a three-tiered access system (module + menu + function), but also allows application systems to dynamically adjust access definitions via an open API, making it flexible and practical.

[0135] Furthermore, the single sign-on method of this invention also supports providing unified user authentication functionality for application systems, meaning that the authentication function of application systems is uniformly handled by the authentication center. In this mode, application systems do not need to subscribe to permission change data, making it very suitable for lightweight, small application systems (no need to develop authentication functions; all authorization and authentication rely on the authentication center). Compared to individual authentication by application systems, the unified authentication mode of the authentication center has the advantage of requiring less development effort from application systems, facilitating rapid development and deployment; the disadvantage is a deeper coupling with the authentication center, which can easily cause congestion in scenarios with a large number of users frequently authenticating (this performance bottleneck can be alleviated by loading permission data into the cache). The system described in this invention is compatible with both methods, and each application system can decide whether to adopt local authentication or the unified authentication mode based on its actual situation.

[0136] As needed, the single sign-on method of the present invention supports both unified authentication by the authentication center and authentication by each business system, which allows application systems to choose flexibly.

[0137] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by an electronic device, implements the single sign-on method as described in any of the above embodiments.

[0138] The following describes the single sign-on system and single sign-on method based on user permission synchronization of the present invention through specific implementation methods.

[0139] The single sign-on system described in this invention consists of an authentication center, an application console, a message middleware, and an application system.

[0140] The authentication center provides user management (creation, modification, deletion), authentication, authorization, and authorization functions; the application console serves as the desktop for users to access daily office applications, providing links to these applications; the message middleware receives messages from the authentication center and distributes them to application systems that have subscribed to the messages; and the application systems are the business platforms where users conduct actual business processing. After authentication at the authentication center, users can select the application system for their business from the application console and be directly redirected to that application system without needing secondary authentication.

[0141] 1. User security level settings

[0142] As a security enhancement measure, the system described in this invention allows users to set security levels. Security levels can be defined in various ways (including but not limited to numbers, letters, strings, etc.), with one example being: 1 - lowest level; 2 - lower level; 3 - normal level; 4 - higher level; 5 - highest level. User levels can also be represented in different ways, such as: a - ordinary user; b - department administrator; c - system administrator. Taking the first example, the security levels for users abc and bcd are shown in Table 1.

[0143] Table 1 User Security Levels

[0144] username Security Level abc 3- Lower level bcd 4-Higher level

[0145] There are two ways to set user security levels, such as Figure 6 As shown:

[0146] (1) Users register with the authentication center. When a user registers, the authentication center can assign a security level to the user based on the user's role (one level is assigned by default or no level is assigned).

[0147] (2) After a user successfully registers, they can apply to adjust their security level. The adjustment will take effect after the administrator approves it.

[0148] 2. Application security level

[0149] The certification authority predefines the security level for each application system, and this system's security level is consistent with the user's, as shown in Table 2 (for example only). Users can request access to applications with a lower security level than themselves, but not vice versa. For example, user abc can request access to an email system with the same security level, but cannot request access to a financial system with a higher security level.

[0150] Table 2 Application System Security Level Definition Table

[0151] Application System ID Application System Name Security Level Email Email system 3- Lower level Finance Financial System 4-Higher level

[0152] When an application to access an application is approved, the authentication center establishes a mapping relationship between the user and the application system, and simultaneously synchronizes the user data to the corresponding application system via a message middleware. The flowchart is as follows: Figure 7 As shown below, the following description uses user bcd's request to access the financial system as an example.

[0153] The process for a user (bcd) to request access to the application system is described below:

[0154] (1) User BCD submits an application to the certification center to add a financial system application through the application console;

[0155] (2) The authentication center first determines whether the security level of the user's BCD is higher than the security level of the application system, and then submits it to the administrator for approval;

[0156] (3) After the administrator approves, the certification center establishes a mapping relationship between the user's BCD and the financial system, and then sends the user change message of the user's BCD to the user change message middleware. The message contains the application system ID (Finance), change type (AddUser), and user information.

[0157] (4) The financial system subscribes to and parses user change messages, determines that the user's access object is this system (Finance), and then creates a new user (Note: Other application systems also subscribe to this message, but because the access object does not match, they will not process the message to avoid generating a large number of invalid "zombie" users).

[0158] The process of a user (bcd) accessing the application system from the application console is described as follows:

[0159] (1) User bcd clicks the shortcut for the financial system in the application console to request to open the financial system;

[0160] (2) The application console submits the user request to the authentication center. The authentication center determines whether the mapping relationship between the user's BCD and the financial system exists (i.e. whether the user has permission). If it exists, a user credential (ticket) is generated and returned to the application console. Otherwise, the user is refused to log in to the financial system.

[0161] (3) The application console redirects to the financial system page by including the ticket in the URL;

[0162] (4) After receiving the access request, the financial system first checks whether the user's BCD exists. If it exists, the ticket is sent to the authentication center for verification; otherwise, the single sign-on process is interrupted.

[0163] (5) The authentication center verifies the ticket sent in step (4), and returns a success message after successful verification;

[0164] (6) After receiving the success message, the application system creates a session for the user and then opens the page.

[0165] 3. Application permission settings

[0166] The authentication center not only provides user management and authentication functions, but also a unified user authorization architecture. The permission configuration of the authentication center is shown in Table 3 (this is for illustrative purposes only and does not represent the actual configuration).

[0167] Table 3 Permission Configuration Table

[0168] Permission ID Permission types System ID Permission Name Security Level Remark Auth_ManageUser module Finance User Management 4-Higher level Registration module Auth_AddUser menu Finance New users 4-Higher level Registration Menu Auth_Submit function Finance Submit business 4-Higher level Registration function

[0169] This invention provides three levels of permissions: module level, menu level, and function level. As shown in Table 3, the first record is an example of permissions for the user management module of the financial system; the second record is an example of permissions for adding a new user in the user management module; and the third record is an example of the submit business button on the add user page.

[0170] The certification center receives permission registration / modification requests from various applications through the API interface and records them in Table 3. The permission ID is consistent with the permission ID of the application system, so that the application system can dynamically adjust permissions without manual intervention, and it is also convenient for users to apply for the corresponding permissions.

[0171] In situations where user operation security is strictly enforced, as an optional security enhancement measure, a security level can be set for each permission, with the permission security level consistent with the user's security level definition. Only users with a security level higher than the permission's security level can be authorized; permissions without a security level are considered unrestricted. This method effectively prevents users from obtaining permissions with a higher security level than themselves.

[0172] As shown in Table 3, this invention not only supports user access control when jumping from the authentication center to the application system, but also supports unified control of internal permissions within the application system. This invention provides three levels of authorization: module authorization, menu authorization, and function authorization. Module authorization refers to authorizing a user to access a specific module within a subsystem; menu authorization refers to authorizing a user to access certain menus within a module within a subsystem; function authorization refers to authorizing a user to access specific functions within a menu (such as clicking an operation button, editing a text box, reading data, etc.). Through different combinations of these three authorization methods, the user authorization needs of various application systems can be basically met.

[0173] 4. User authorization and data synchronization

[0174] Users need to grant prior authorization to use specific functions of the application. Authorization can be done in two ways: (1) the user applies for authorization, and the administrator approves it; (2) the administrator directly authorizes the user. Taking the user's permission application as an example (the process is as follows) Figure 8 (as shown)

[0175] Users first access the application system via single sign-on (the standard process, which will not be elaborated in detail):

[0176] (1) The user authenticates at the authentication center, and after successful authentication, is redirected to the application console;

[0177] (2) When a user clicks on the financial system in the application console, the application console requests user credentials (ticket) from the authentication center.

[0178] (3) The certification center returns a ticket to the application console, and the application console opens the financial system page with the ticket;

[0179] (4) After receiving the ticket, the financial system sends the ticket to the authentication center for verification;

[0180] (5) After the authentication center successfully verifies the ticket, it returns a verification success response message to the financial system;

[0181] (6) The financial system creates local sessions for users;

[0182] A user is using the financial system. Assuming the user doesn't have user management privileges, they request those privileges:

[0183] (7) The user queries the user management permissions on the financial system on the application console and applies for the permissions;

[0184] (8) The authentication center judges the requested permissions: whether the user's security level is higher than the security level of the permission. If the result is no, the user is prompted and the application process ends; otherwise, the next step is executed.

[0185] (9) The administrator approves the user's permission request;

[0186] (10) The authentication center archives user permissions and establishes a mapping relationship between users and permissions in Table 4;

[0187] (11) The authentication center sends the permission change message to the message middleware, which includes the system ID, user ID, and permission ID;

[0188] (12) The financial system subscribes to the permission change message of the message middleware, finds that the system ID is this system, and then parses the message (other application systems that subscribe to the message at the same time will automatically ignore the message because they determine that it is not this system by the system ID).

[0189] (13) The financial system parses the user ID and permission ID in the message and archives the user permissions;

[0190] (14) When a user performs user management operations in the financial system, the financial system authenticates and approves the user, and then opens the application.

[0191] If the administrator assigns permissions to the user, then step (9) is omitted.

[0192] Another way to synchronize user permission data is for the application system to query the authentication authority for the user's specific or full permissions based on the user ID, and then update the permissions in the application system. The typical difference between these two methods is that the former is suitable for changing a single permission, while the latter is suitable for initially assigning permissions or verifying and correcting permission data.

[0193] Table 4 shows an example of user permissions archived by the certification authority (this is just an example and does not represent the actual situation):

[0194] Table 4 User Permissions Table

[0195] User ID Permission ID Permission types abc Auth_ManageUser module abc Auth_AddUser menu abc Auth_Submit function

[0196] This method enables centralized access control across multiple application systems. This invention not only addresses the access control requirements of application systems by supporting a three-tiered access system (module + menu + function), but also allows application systems to dynamically adjust access definitions via an open API, making it flexible and practical.

[0197] Furthermore, this invention also supports providing a unified user authentication function for application systems, meaning that the authentication function of the application system is uniformly undertaken by the authentication center, and the process of the unified authentication mode is as follows: Figure 9 As shown. With Figure 8 Compared to the previous process, in this model, the application system does not need to subscribe to permission change data (therefore, in Figure 9 (The message middleware is not shown in the flowchart; see the bold italicized section for differences). This is very user-friendly for lightweight, small application systems (no authentication functionality needs to be developed; all authorization and authentication rely on the authentication center). Compared to application systems authenticating individually, the unified authentication mode of the authentication center has the advantage of requiring less development effort from application systems, facilitating rapid development and deployment. The disadvantage is deeper coupling with the authentication center, which can easily cause congestion in scenarios with a large number of users frequently authenticating (this performance bottleneck can be alleviated by loading permission data into the cache). The system described in this invention is compatible with both methods, and each application system can decide whether to use local authentication or the unified authentication mode based on its actual situation.

[0198] Those skilled in the art will readily understand that the above description is merely an embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A single sign-on system based on user permission synchronization, characterized in that, This includes the authentication center, application console, message middleware, and application systems: The authentication center is used to provide user management, authentication, authorization, and authorization functions; The application console is used to provide links for users to use the application; The message middleware is used to receive messages from the authentication center and distribute the messages to application systems that subscribe to the messages. The application system is a business platform for users to perform actual business processing. The authentication center synchronizes permission messages through a message middleware to achieve data synchronization and business decoupling; the authentication center does not immediately synchronize users to the application system when registering users, but only notifies the application system through user change messages when the user requests access to the application system.

2. A single sign-on method based on user permission synchronization, characterized in that, Including the single sign-on system as described in claim 1, the process of a user requesting access to an application system includes the following steps: Users submit applications to add the system application to the certification center through the application console; The authentication center first determines whether the user's security level is higher than the application system's security level, and then submits it to the administrator for approval; After the administrator approves the change, the authentication center establishes a mapping relationship between the user and the application system, and then sends the user's change message to the user change message middleware. The message contains the application system ID, change type, and user information. The application system subscribes to and parses user change messages, determines that the user is accessing this system, and then creates a new user.

3. The single sign-on method based on user permission synchronization according to claim 2, characterized in that, The process of a user accessing the application system from the application console includes the following steps: The user clicks the application system shortcut in the application console to request to open the application system; The application console submits the user request to the authentication center. The authentication center determines whether the mapping relationship between the user and the application system exists. If it exists, it generates a user credential and returns it to the application console; otherwise, it refuses to log in to the application system. The application console redirects to the application system page by including user credentials in the URL; After receiving an access request, the application system first checks whether the user exists. If the user exists, the system sends the user's credentials to the authentication center for verification; otherwise, the single sign-on process is interrupted. The authentication center verifies the user credentials sent by the application system, and returns a success message upon successful verification. After receiving the success message, the application system creates a session for the user and then opens the page.

4. The single sign-on method based on user permission synchronization according to claim 2, characterized in that, It also includes the step of setting a security level for users: When a user registers at the certification center, the certification center can assign a security level to the user based on the user's role; After a user successfully registers at the authentication center, they can apply to adjust their security level, which will take effect after administrator approval.

5. The single sign-on method based on user permission synchronization according to claim 4, characterized in that, It also includes the step of setting a security level for the application system: The certification center predefines the security level for each application system, and the definition of the application system's security level is consistent with the user's security level definition. When a user requests access to the application system, the user's security level is first compared with the application system's security level. If the security level of the application system is equal to or lower than the user's security level, the user's request to access the application system is approved. If the application system's security level is higher than the user's security level, the user's request to access the application system will be rejected.

6. The single sign-on method based on user permission synchronization according to claim 5, characterized in that, The definitions of user security levels and application system security levels include one or more of numbers, letters, and strings.

7. The single sign-on method based on user permission synchronization according to claim 5, characterized in that, The authentication center is also used to uniformly control the internal permissions of application systems, which include module authorization, menu authorization, and function authorization. The authentication center receives permission registration requests from various applications through an API interface, and application systems can register and modify the permissions involved in the system with the authentication center. Module licensing refers to granting a user the authorization to use a specific module within an application system; Menu authorization refers to granting certain menus within a module of an application system to a user; Function authorization refers to granting specific functions within a menu to the user. These functions include clicking an operation button, editing a text box, and reading data.

8. The single sign-on method based on user permission synchronization according to claim 7, characterized in that, The user authorization process for internal permissions in an application system includes the following steps: Users can query the user management permissions on the application system in the application console and request those permissions; The authentication center determines the requested permissions: whether the user's security level is higher than the security level of the permission. If the result is yes, the user is prompted and the application process ends; otherwise, the next step is executed. Administrators approve user permission requests; The authentication center archives user permissions; The authentication center sends a permission change message to the message middleware, which includes the system ID, user ID, and permission ID. The application system subscribes to the permission change message from the message middleware, finds that the system ID is this system, and then parses the message; The application system parses the user ID and permission ID in the message, archives the user permissions, or queries the authentication center for user permission information based on the user ID and updates it locally; Users perform user management operations in the application system. Once the application system authenticates and approves the user, it opens the application. When the application system cannot find the user's permissions, it actively queries the authentication center for the user's permissions via API and updates them locally.

9. The single sign-on method based on user permission synchronization according to claim 8, characterized in that, Before a user requests internal permissions for the application, the process of a user accessing the application system via single sign-on includes the following steps: The user authenticates at the authentication center, and after successful authentication, is redirected to the application console. When a user clicks on the desired application system in the application console, the application console requests user credentials from the authentication center. The authentication center returns user credentials to the application console, and the application console uses the user credentials to open the application system page. After receiving the user credentials, the application system sends the user credentials to the authentication center for verification; After the authentication center successfully verifies the user's credentials, it returns a verification success response message to the application system. The application system creates local sessions for users.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by an electronic device, it implements the single sign-on method as described in any one of claims 2 to 9.

Images