Dynamic credential-based authentication access method for associated applications and its application

Abstract

This application proposes an associated application authentication access method based on dynamic credentials and its application, including the following steps: the district-level system server responds to the user's access HTTP request operation on the browser, and uses the interface access credential to obtain a temporary credential from the municipal server; the district-level system server extracts the client source IP, and stores the client source IP and temporary credential in a temporary credential table; the district-level system server encodes and signs the data carrier and dynamically generates a browser front-end page for the district-level system user to use, and directly jumps to the municipal system in a redirected access mode; the municipal system server receives the browser's HTTP request and decodes and verifies it; the municipal system server receives the verification and returns it to the browser page according to the login-free type in the data carrier. This application allows users to access the municipal system without logging in again, regardless of whether they are logged in to the district system or not.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for accessing associated applications through authentication based on dynamic credentials and its application. Background Art

[0002] In the process of information construction and development over the past decade, government departments have established a large number of information management systems. These systems, built at different times, cover almost all business areas of the department. They are highly professional, complex, and have a strong demand for interoperability between systems.

[0003] Taking the municipal-level departments as an example, the municipal-level departments and the district-level departments have their own systematic construction systems, such as portals, decision-making screens, business systems, data services, authentication centers, government affairs apps, etc. In recent years, national policies have required government departments to avoid duplication in the construction of information systems. The upper-level departments will build some common application systems, and the lower-level departments will use these unified application systems and retain their own systems outside of the common ones. In order to maintain the integrity of the system and the consistency of usage habits, the lower-level departments will integrate the access entrances of the unified applications built by the upper-level departments into the system pages of the departments at this level in the form of page elements (such as hyperlinks). However, since the government network environment has very high security requirements, and the upper-level and lower-level departments use different authentication centers, this requires solving the problem of secure login-free access:

[0004] 1. The district-level system (without logging in, such as the portal) can directly access the function pages of the municipal-level system, but the municipal-level system requires logging in to access;

[0005] 2. District-level systems (such as decision-making systems) can access the function pages of the municipal-level system after logging in, but the municipal-level system also requires login to access;

[0006] 3. Both the accessing and accessed systems need to be able to confirm the identity of the other party corresponding to the request, and the access complies with the trust relationship to ensure security.

[0007] If the access link to the municipal system is directly placed in the district system or portal without modification, the user will have to log in twice. That is, they will first log in to the district system, then click on the link to the municipal system, and then log in to the municipal system again. This causes inconvenience to users and a very bad experience. In addition, if the district system uses a fixed username and password as the URL parameters of the municipal system, when the user clicks on the municipal system link in the district portal in the browser, the municipal system obtains the username and password for internal login, and finally the municipal system will be displayed in the browser with the user logged in. Although this method can achieve a single login, it has serious security issues and the user password can be leaked.

[0008] There are some solutions in the industry for multi-system login-free access that all require user authentication, but they are obviously insufficient for the needs of this article.

[0009] There is a method that uses traditional SSO single sign-on (SSO) but requires that both district and municipal systems use the same authentication center. This authentication center issues browser credentials to users, eliminating the need for users to log in again to access both district and municipal systems. However, this method relies heavily on the authentication center, requiring costly modifications for systems without access to the authentication center. As mentioned in the previous section, both district and municipal systems already have their own authentication centers, making the establishment of a unified single point of authentication across regions impossible under realistic conditions.

[0010] There is also a method that uses the first access system for unified authentication, uses the browser cache information (cookie) after the user logs in as the login credential for other access systems, and then requests the user login information from the first access system through the back-end service of the other access system. According to this method, one of the requirements described in this article (accessing the functional pages of the municipal system without logging in again after logging in to the district system) is achieved. The district system is the first access system. When the user logs in to the district system on the browser, the browser writes the user login cookie; when the user accesses the municipal system again on the browser (the municipal system is the other access system), the HTML code of the municipal system executed by the browser requests the district system back-end service through JSONP technology (the browser carries the previous user login cookie). The district system back-end service feedbacks whether the cookie has expired and records the request identifier; if the feedback login user has not expired, the municipal system back-end service requests the user login information from the district system back-end service (carrying the request identifier of the previous step), and then returns it to the browser login page, thus completing the login-free access to the municipal system. Although this method seems to be able to meet a requirement, it also has problems: 1. It depends on browser settings. If the browser prohibits jsonp from carrying cookies, this method cannot complete the login-free operation; 2. This method cannot meet the requirement of accessing the municipal system without logging in to the district system; 3. This method does not specify the identity confirmation mechanism for the trust relationship between the first access system and other systems. The login user information can be obtained through only a request identifier. Since there are no other measures for superimposed verification, there are great security risks, such as the request identifier being intercepted by the network, or malicious web pages being fabricated to simulate other systems, or other unauthorized systems also using the first access system for unified authentication; 4. The implementation condition of this method is that there is only one first access system (that is, the district system in this article) and multiple other systems (that is, the municipal system in this article), but the actual requirement of this article is multiple district systems and only one municipal system. The effect of the implementation of the requirement does not match the requirement.

[0011] Therefore, there is an urgent need for a dynamic credential-based associated application authentication access method and its application that enables a user's browser to access a district-level system page without logging in to a city-level system page. Summary of the Invention

[0012] The embodiments of the present application provide an associated application authentication access method based on dynamic credentials and its application, which addresses the problem that the current technology cannot meet the problem of enabling users to access the city-level system page without logging in after accessing the district-level system page through a browser.

[0013] The core technology of this invention is to splice the access link address of the municipal system on the district system server side, dynamically generate a browser front-end page for district system users, and redirect them directly to the municipal system. The splicing method uses Base64URL encoding and HMAC-SHA256 signature of a fixed-format data carrier, in which the data carrier is standardized with standard attributes, so that both the requirements of not logging in and logging into the district system and then redirecting to the municipal page can be relatively securely achieved.

[0014] In a first aspect, the present application provides a method for authenticated access to associated applications based on dynamic credentials, the method comprising the following steps:

[0015] S00. The district-level system server responds to the user's access http request operation on the browser and uses the interface access credential to send a request for obtaining a temporary credential to the municipal-level server;

[0016] S10. The municipal server verifies whether the interface access credential has expired.

[0017] S20. If it has not expired, return the temporary certificate to the district-level system server;

[0018] S30, the district-level system server extracts the client source IP in the access http request, and stores the client source IP and temporary credentials in the temporary credential table;

[0019] S40. In the district-level system server, the data carrier is encoded and signed, and the data carrier is spliced ​​into a URL and returned to the front-end page of the browser. The HTTP response status is 302 redirect.

[0020] S50: After receiving the http response with status 302, the browser initiates an http request to the municipal system server;

[0021] S60: The municipal system server receives the http request from the browser and extracts and decodes the URL parameters to verify that the URL parameters have not been tampered with. At the same time, it extracts the client source IP and temporary credentials and sends a verification request to the district system server.

[0022] S70, the district-level system server receives the verification request and extracts the client source IP and temporary credentials to query the temporary credentials table;

[0023] S80. If the extracted client source IP and temporary credentials are found, a verification result is returned to the municipal system server.

[0024] S90: The municipal system server receives and verifies that the data is correct and returns the page to the browser according to the log-free type in the data carrier;

[0025] Among them, the log-in-free type includes redirecting to the city-level page without logging in to the district-level system and redirecting to the city-level page without logging in to the district-level system.

[0026] Furthermore, in step S90, if the data carrier does not need to log in to the district-level system and redirects to the municipal-level page without logging in, an internal login is performed according to the account agreed upon by the district-level department and the municipal-level department and then the page is returned to the browser; if the data carrier needs to log in to the district-level system and redirects to the municipal-level page without logging in, the value of the subject attribute in the data carrier is extracted as the corresponding login user identifier in the municipal system, the user is internally logged in and returned to the browser page.

[0027] Furthermore, the district-level system server stores the identity credentials registered in the municipal-level system server, and periodically requests the municipal-level system server to obtain the interface access credentials, which correspond one-to-one to the identity credentials.

[0028] Furthermore, when the district-level department requests the municipal-level department to connect the municipal-level page to the district-level system without logging in, after the municipal-level department agrees, the district-level system will be registered with the municipal-level system, and the municipal-level system will provide identity credentials.

[0029] Furthermore, the identity credential includes an identifier and a key. The identifier corresponds to the district-level system and is unique. The key is used as a signature for redirection URL parameters in the district-level system.

[0030] Furthermore, the data carrier includes a log-in-free type, temporary credentials and extended attributes. When the log-in-free type requires logging into the district-level system and redirects to the city-level page, the data carrier also includes a subject attribute, the value of which is the login user identifier that needs to be passed to the city-level system.

[0031] Furthermore, in step S80, if the record of the extracted client source IP and temporary credentials is found, the record is deleted from the temporary credential table and a verification result is returned.

[0032] In a second aspect, the present application provides a method and apparatus for associated application authentication access based on dynamic credentials, including:

[0033] The human-computer interaction interface is used for users to initiate HTTP requests to the district-level system; after receiving a 302-status HTTP response, it redirects to the URL in the response header, i.e., initiates an HTTP request to the municipal-level system server; and displays the request results.

[0034] The district-level system is used to respond to the user's access HTTP request operation on the browser, and use the interface access credential to send a request for obtaining temporary credentials to the municipal server; it is used to extract the client source IP in the access HTTP request and store the client source IP and temporary credentials in the temporary credential table; it encodes and signs the data carrier to splice it into a URL and returns the response to the front-end page of the browser, and the HTTP response status is 302 redirect; it is used to receive the verification request and extract the client source IP and temporary credentials to query in the temporary credential table; if the record of the extracted client source IP and temporary credentials is queried, the correct verification result is returned to the municipal system server;

[0035] The municipal system is used to check whether the interface access credentials are expired; if not, a temporary credential is returned to the district system server; it is used to receive the browser's http request and extract the url parameters and perform decoding verification to verify that the url parameters have not been tampered with, and at the same time extract the client source ip and temporary credential to send a verification request to the district system server; it is used to receive the correct verification and return it to the browser page according to the free login type in the data carrier; among them, the free login type includes redirecting to the municipal page without logging in to the district system and redirecting to the municipal page without logging in when logging in to the district system.

[0036] In a third aspect, the present application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the above-mentioned dynamic credential-based associated application authentication access method.

[0037] In a fourth aspect, the present application provides a readable storage medium, in which a computer program is stored. The computer program includes a program code for controlling a process to execute a process, and the process includes the above-mentioned dynamic credential-based associated application authentication access method.

[0038] The main contributions and innovations of this invention are as follows: 1. Compared with the existing technology, regardless of whether the user is logged in to the district system or not, this application allows users to access the municipal system by directly clicking on the dynamic application link representing the municipal system in the browser without having to log in again. The access address of the municipal system uses URL parameters, and the district system login user is implicitly authenticated in the municipal system by redirection. The security of the redirection-free access to the system page is also well guaranteed;

[0039] 2. Compared with the existing technology, the present application can perform multiple security verifications on the redirection requests of the district-level system user end: 1) It is agreed that only the district-level system registered at the municipal level is eligible to access the municipal page without logging in. The municipal system gives the district-level system a unique identity credential (clientid, secret) as the credential root for requesting related verification actions; 2) The identity credential (clientid, secret) of the district-level system is fixed, and frequent use will pose a security risk, so an interface access credential (accesstoken) with an expiration time is used instead as an identity proof for subsequent acquisition of a temporary credential (ticket); 3) Each time the browser redirects to access the municipal page, the district-level system applies to the municipal system for a one-time temporary credential (ticket) as a parameter for subsequent source verification, thereby improving security; 4) A signature calculation verification is performed based on the request parameters and the key in the identity credential to verify the consistency of the request parameters and whether the request source comes from a registered district-level system; 5) Based on the client source authenticity verification interface registered and reserved by the district-level system in the municipal system, as well as the temporary credential (ticket) and source IP, it is verified whether the browser's redirection request comes from the currently logged-in user of the district-level system.

[0040] The details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0042] Figure 1 is a flowchart of a method for accessing associated applications based on dynamic credentials according to an embodiment of the present application;

[0043] Figure 2 is a flow chart of a preferred embodiment of the present application;

[0044] Figure 3 This is a schematic diagram of the overall structure of a preferred embodiment of the present application;

[0045] Figure 4 Schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0046] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0047] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0048] If it is necessary to implement a system where a user's browser can access the city-level system page without logging in after accessing the district-level system page, it must be independent of whether the user has logged into the district-level system or not, and security must be met. This is not as simple as simply changing two logins to one login for data transfer, especially in a government environment that emphasizes security.

[0049] Based on this, the present invention solves the problems existing in the prior art based on URL redirection.

[0050] Example 1

[0051] This application aims to propose an associated application authentication access method based on dynamic credentials. By splicing the access link address of the municipal system on the district system server, it dynamically generates a browser front-end page for the district system user to use, and directly jumps to the municipal system in a redirected access mode. The splicing method uses Base64URL encoding and HMAC-SHA256 signature of a fixed-format data carrier, in which the data carrier is standardized with standard attributes, so that both the requirements of not logging in and logging in to the district system and then redirecting to the municipal page can be relatively safely achieved in one way.

[0052] Specifically, the embodiment of the present application provides an associated application authentication access method based on dynamic credentials, specifically, referring to Figure 1 , the method comprising:

[0053] S00. The district-level system server responds to the user's access http request operation on the browser and uses the interface access credential to send a request for obtaining a temporary credential to the municipal-level server;

[0054] In this embodiment, the municipal system maintains the identity credentials and client source verification interface of all district systems that need to redirect municipal pages. When the district department requests the municipal department to connect the municipal page to the district system without logging in, after the municipal department agrees, the district system will be registered with the municipal system, and the municipal system will provide the identity credentials. Among them, the identity credentials include an identifier (clientId) and a key (secret). The identifier (clientId) corresponds to the district system and is unique; the key (secret) is used as a signature for the redirection URL parameters of the district system.

[0055] In this embodiment, the municipal system stores the registered district system identity credentials and the client source verification interface URL provided by the district system (this interface is standardized by the municipal level and implemented by the district system) for subsequent verification. In addition, the registered district system stores the identity credentials assigned by the municipal system on the server side, using the server's security measures to ensure storage security.

[0056] In this embodiment, the municipal system issues an interface access credential (accesstoken) to the district system based on the identity credential provided by the district system, after comparison and verification. The credential serves as the credential for the district system server to request the municipal system server interface service (the credential expires in 1 hour), and the interface access credential (accesstoken) is stored on the municipal system server, corresponding to the district system identity credential (clientid, secret).

[0057] In this embodiment, the district-level system page accessed by a user on a browser includes an access button representing the municipal system (the access button is for example only; other HTML tags can be used in real-world scenarios). The hyperlink URL corresponding to the access button is the district-level system server interface address. When the user clicks the button, an HTTP request is sent to the district-level system server interface, and the expected response from the interface is the actual URL redirecting to the municipal system page.

[0058] S10. The municipal server verifies whether the interface access credential has expired.

[0059] In this embodiment, the district-level system requests an access token from the municipal system, which is used to access the municipal system's page using a temporary ticket. If the access token expires, a new access token is requested. This access token can also be used to call other interfaces agreed upon by the two systems. A scheduled task is used within the district-level system to detect credential expiration.

[0060] S20. If the request has not expired, the temporary certificate is returned to the district-level system server. If the request has expired, the temporary certificate is rejected or no response is given.

[0061] S30, the district-level system server extracts the client source IP in the access http request, and stores the client source IP and temporary credentials in the temporary credential table;

[0062] In this embodiment, the district-level system server maintains a temporary ticket table corresponding to each request. This temporary ticket table stores a temporary ticket and the corresponding HTTP request source IP address. When the district-level system server interface receives an HTTP request from a browser, it first sends a request to the municipal-level system server interface with the interface access token to obtain a temporary ticket. It then extracts the client source IP address (HTTP attribute) from the HTTP request header. The source IP address and temporary ticket are then stored in the temporary ticket table for subsequent verification by the municipal-level system to verify the authenticity of the redirected request.

[0063] S40. In the district-level system server, the data carrier is encoded and signed, and the data carrier is spliced ​​into a URL and returned to the front-end page of the browser. The HTTP response status is 302 redirect.

[0064] In this embodiment, the actual city-level page redirection URL is spliced ​​and returned to the browser. In this process, the detailed process of obtaining a temporary ticket and splicing the redirection URL is as follows:

[0065] 1) Obtaining a temporary ticket: When the municipal system server interface receives a request to obtain a temporary ticket, it extracts the interface access token from the request parameters and compares it with the stored interface access token for verification. If the interface access token exists, it means that the verification is successful, and a temporary ticket is generated and returned to the corresponding district-level system server that initiated the request. At the same time, the temporary ticket and the interface access token are stored. The characteristic of the temporary ticket is that it is used once. After the subsequent verification and redirection of the authenticity of the municipal page access request, it will be deleted to ensure security.

[0066] 2) Redirection URL splicing process: In addition to the original URL address of the municipal page, the redirection URL returned by the district-level system server to the browser also contains parameters for the data carrier and signature: (a) The data carrier is in a fixed JSON format and contains field attributes: no-login type (type), temporary ticket (ticket), subject attribute (subject), and extended attribute (extend). Among them, the type value includes nologin (user does not need to log in to the district-level system) and login (user needs to log in to the district-level system); the subject attribute only exists when the type value is login, and its value is the login user ID that needs to be passed to the municipal system; the extend attribute is for possible future expansion and is only added when the two-level departments agree that additional data needs to be passed. Examples of the original data carrier include: {"type":"nologin","ticket":"xxxxxxxx"}, {"type":"login","ticket":"xxxxxxxx","subject":"yyyyyyyy","extend":"zzzzzzzz"}. Furthermore, this data is Base64URL encoded (a URL-safe Base64 encoding) to make it suitable for passing as a URL parameter, ultimately forming a string. (b) The encoded data carrier is signed using the HMAC-SHA256 algorithm (the algorithm's key uses the secret in the identity credential) to form a signature string to prevent illegal tampering during data transmission. (c) The data carrier and signature value are concatenated as URL parameters and returned to the browser, with an HTTP response status of 302 Redirect.

[0067] S50: After receiving the http response with status 302, the browser redirects to the URL in the response header, i.e. initiates an http request to the municipal system server.

[0068] S60: The municipal system server receives the http request from the browser and extracts and decodes the URL parameters to verify that the URL parameters have not been tampered with. At the same time, it extracts the client source IP and temporary credentials and sends a verification request to the district system server.

[0069] In this embodiment, the municipal system server extracts the URL parameters from the browser's http request and performs the following actions:

[0070] 1) Extract the value: Perform Base64 URL decoding on the data parameter value to obtain the JSON value of the data carrier. Extract the temporary credential (ticket) value in the JSON and use the temporary credential (ticket) to find the corresponding secret in the district-level system identity credential and the district-level system client source verification interface URL.

[0071] 2) Signature verification: Use the secret to perform an HMAC-SHA256 signature on the data parameter value, and compare the calculated signature value with the sign parameter value. If they are consistent, it means that the data parameter value has not been tampered with; otherwise, the request is discarded.

[0072] 3) Verify the source: Read the client's source IP attribute (e.g., x-forwarded-for) from the HTTP request header and extract the source IP. Using the source IP and a temporary ticket as parameters, initiate an authenticity verification request to the district-level system's client source verification interface and receive feedback.

[0073] S70, the district-level system server receives the verification request and extracts the client source IP and temporary credentials to query the temporary credentials table;

[0074] In this embodiment, after receiving the request from the city-level system server, the client source verification interface of the district-level system server first extracts the source IP and temporary ticket in the request parameters, and then searches and compares them in the temporary ticket table.

[0075] S80. If the extracted client source IP and temporary credentials are found, a verification result is returned to the municipal system server.

[0076] In this embodiment, if the comparison is successful, the record is deleted from the temporary voucher table and the success result is fed back to the municipal system.

[0077] S90: The municipal system server receives and verifies that the data is correct and returns the page to the browser according to the log-free type in the data carrier;

[0078] Among them, the log-in-free type includes redirecting to the city-level page without logging in to the district-level system and redirecting to the city-level page without logging in to the district-level system.

[0079] In this embodiment, the actions of the municipal system service after the feedback result are:

[0080] a. If the source authenticity feedback is not true, discard the request;

[0081] b. If the source authenticity feedback is true, delete the temporary ticket stored on the server and extract the type attribute value in JSON;

[0082] a) If type=nologin, it means that there is no need to log in to the district-level system and redirect to the city-level page. In this case, the system will directly log in internally using the account agreed upon by the two departments and then return to the browser page;

[0083] b) If type=login, it means that you need to log in to the district-level system and avoid redirecting to the city-level page. Then extract the subject attribute value in json as the corresponding login user ID in the city-level system, perform internal login for this user, and return to the browser page.

[0084] Preferably, secure communication between the district-level system server and the municipal-level system server can be implemented by superimposing common server security protection strategies, such as server IP whitelisting, etc. In addition, the overall data communication can also be encrypted using the https protocol.

[0085] In summary, regardless of whether the user is logged in to the district system or not, this application allows users to access the municipal system by directly clicking on the dynamic application link representing the municipal system in their browser, without having to log in again. The municipal system's access address uses URL parameters, which redirect users logged into the district system to implicitly authenticate them in the municipal system. This redirection also ensures the security of accessing the system page without logging in.

[0086] Example 2

[0087] Based on the same concept, Figure 2-3 As shown, this embodiment further illustrates the technical solution of the present application through actual operation.

[0088] The city-level system has corresponding data structures to support the storage and operation of identity credentials, access credentials, and temporary credentials of registered district-level systems. The main storage data structures are as follows:

[0089] 1. Maintain the identity credentials and client source verification interface URLs of all district-level systems that need to redirect city-level pages. The data structure is as shown in Table 1:

[0090]

[0091] Table 1

[0092] The data in Table 1 are Figure 3 In order to save space, the data of the B-level system and the C-level system are omitted. The client refers to the client accessed by the user, which can be multiple. Figure 3 Just an example.

[0093] 2. Based on the identity credentials provided by the district system, the municipal system issues an interface access token to the district system after verification. This token serves as the credential for the district system server to request the municipal system server's interface service (this credential expires in 1 hour). The interface access token is stored on the municipal system server, corresponding to the district system's identity credentials (clientid, secret). The data structure for storing the interface access token is shown in Table 2 below:

[0094]

[0095] Table 2

[0096] 3. When the municipal system server interface receives a request to obtain a temporary ticket, it extracts the interface access token from the request parameters and compares it with the stored interface access token for verification. If the verification is successful, a temporary ticket is generated and returned to the corresponding district system server that initiated the request and stored on the municipal system server. The data structure is as shown in Table 3:

[0097]

[0098] Table 3

[0099] Among them, the district-level system server also maintains a temporary credential table corresponding to each request. The temporary credential table stores the temporary credential (ticket) and the corresponding HTTP request source IP. The temporary credential table is as follows Table 4:

[0100]

[0101] Table 4

[0102] In addition, the district-level system server stores the identity information registered in the municipal system (i.e., clientId and secret), such as clientId=1, secret=4d52aec44359f3161f15e7287f738825. A scheduled task module is configured to call the municipal system access credential acquisition interface (http: / / <ip:port> / getaccesstoken), passing clientId and secret as parameters, obtains the interface access credential (accesstoken), such as b579053cagcb421cae82751cb8c7a091, and stores it on the server for subsequent interface use.

[0103] The example steps could be:

[0104] Step 1: The user accesses the district-level system on the browser. There is an access button on the district-level system page that represents the city-level system. The hyperlink URL corresponding to the access button is the district-level system server interface address (http: / / <ip:port> / getRealSite). The user clicks the button and sends a request to http: / / <ip:port> / getRealSite sends an http request.

[0105] Step 2: After the district-level system server interface receives the http request:

[0106] 1. First, use the interface access token (b579053cagcb421cae82751cb8c7a091) to the municipal system server interface (http: / / <ip:port> / getticket) to send a request to obtain temporary credentials. The full URL of the HTTP request is http: / / <ip:port> / getticket? accesstoken=b579053cagcb421cae82751cb8c7a091. The municipal system server receives the request, extracts the interface access token, and checks whether it has expired. If it has not expired, it generates and returns a temporary ticket for the district system (b47bff34f07b43ab8ac5c06c901f3c32).

[0107] 2. Then, the district-level system server extracts the client source IP (172.18.6.22) from the x-forwarded-for attribute in the HTTP request header and stores the client source IP and temporary ticket in the temporary ticket table.

[0108] 3. Then, the data carrier is encoded as follows: Base64URL({"type":"nologin","ticket":"b47bff34f07b43ab8ac5c06c901f3c32"})=e-KAnHR5cGXigJ06ICDigJxub2xvZ2lu4oCdLCDigJx0aWNrZXTigJ06IOKAnGI0N2JmZjM0ZjA3YjQzYWI4YWM1YzA2YzkwMWYzYzMy4oCdfQ, and the identity certificate key secret (i.e. 4d52aec44359f3161f15e7287f738825 ) signs the encoded data carrier, namely: HMAC-SHA256(secret:4d52aec44359f3161f15e7287f738825,data:e-KAnHR5cGXigJ06ICDigJxub2xvZ2lu4oCdLCDigJx0aWNrZXTigJ06IOKAnGI0N2JmZjM0ZjA3YjQzYWI4YWM1YzA2YzkwMWYzYzMy4oCdfQ)=c8698a353c6d30ddd39e1bc2c1111bb3dadb9b3bd043d6c3e8256dc915647a58.

[0109] 4. Finally, the encoded data carrier and signature are concatenated into a URL and a response is returned to the user's browser. The HTTP response status is 302 redirect and the response header location is http: / / <ip:port> / city_page? data=e-KAnHR5cGXigJ06ICDigJxub2xvZ2lu4oCdLCDigJx0aWNrZXTigJ06IOKAnGI0N2JmZjM0ZjA3YjQzYWI4YWM1 YzA2YzkwMWYzYzMy4oCdfQ&sign=c8698a353c6d30ddd39e1bc2c1111bb3dadb9b3bd043d6c3e8256dc915647a58.

[0110] Step 3: After receiving the HTTP response with status 302, the user's browser redirects to the location URL in the response header, i.e., initiates a request to the municipal system server.

[0111] Step 4: After the municipal system server receives the http request:

[0112] 1. First extract the url parameters:

[0113] data=e-KAnHR5cGXigJ06ICDigJxub2xvZ2lu4oCdLCDigJx0aWNrZXTigJ06IOKAnGI0N2JmZjM0ZjA3YjQzYWI4YWM1YzA2YzkwMWYzYzMy4oCdfQ;

[0114] sign=c8698a353c6d30ddd39e1bc2c1111bb3dadb9b3bd043d6c3e8256dc915647a58.

[0115] 2. Perform Base64 URL decoding on the data parameter value to obtain the JSON value of the data carrier: {"type":"nologin","ticket":"b47bff34f07b43ab8ac5c06c901f3c32"}. Extract the temporary credential (ticket) value from the JSON: b47bff34f07b43ab8ac5c06c901f3c32. Based on the temporary credential (ticket), find the corresponding district-level system identity credential: secret = 4d52aec44359f3161f15e7287f738825 and the district-level system client source verification interface url = http: / / <ip:port> / validateOrigin.

[0116] 3. Use the found secret to perform an HMAC-SHA256 signature on the data parameter value. After comparison, the calculated signature value is consistent with the sign parameter, indicating that the url parameter has not been tampered with.

[0117] 4. Extract the client source IP (i.e. 172.18.6.22) from the x-forwarded-for attribute in the HTTP request header. Use the source IP (i.e. 172.18.6.22) and the temporary ticket (i.e. b47bff34f07b43ab8ac5c06c901f3c32) as parameters to send a request to the client source verification interface (i.e. http: / / <ip:port> / validateOrigin) to initiate a request.

[0118] 5. After the client source verification interface of the district-level system server receives the request from the municipal-level system server, it extracts the source IP (i.e. 172.18.6.22) and temporary ticket (i.e. b47bff34f07b43ab8ac5c06c901f3c32) in the request parameters, and finds this record in the temporary ticket table, indicating that the client request received by the municipal-level system server is indeed from the District A system, so it returns correct feedback to the municipal-level system server.

[0119] 6. Since type=nologin, there is no need to log in to the district-level system and redirect to the city-level page, so you can directly log in internally using the account agreed upon by the two-level departments and then return to the browser page.

[0120] Step 5: The browser receives the page returned by the municipal system, and the municipal system page that the user is redirected to on the browser is in the logged-in state.

[0121] Among them, for the need to log in to the district-level system without redirecting to the city-level page, the overall process is similar, except that the type attribute value in the data carrier and the internal login of the city-level system are different (nologin is changed to login), so it will not be repeated here.

[0122] Example 3

[0123] Based on the same concept, this application also proposes a method and apparatus for associated application authentication access based on dynamic credentials, including:

[0124] The human-computer interaction interface is used for users to initiate HTTP requests to the district-level system; after receiving a 302-status HTTP response, it redirects to the URL in the response header, i.e., initiates an HTTP request to the municipal-level system server; and displays the request results.

[0125] The district-level system is used to respond to the user's access HTTP request operation on the browser, and use the interface access credential to send a request for obtaining temporary credentials to the municipal server; it is used to extract the client source IP in the access HTTP request and store the client source IP and temporary credentials in the temporary credential table; it encodes and signs the data carrier to splice it into a URL and returns the response to the front-end page of the browser, and the HTTP response status is 302 redirect; it is used to receive the verification request and extract the client source IP and temporary credentials to query in the temporary credential table; if the record of the extracted client source IP and temporary credentials is queried, the correct verification result is returned to the municipal system server;

[0126] The municipal system is used to check whether the interface access credentials are expired; if not, a temporary credential is returned to the district system server; it is used to receive the browser's http request and extract the url parameters and perform decoding verification to verify that the url parameters have not been tampered with, and at the same time extract the client source ip and temporary credential to send a verification request to the district system server; it is used to receive the correct verification and return it to the browser page according to the free login type in the data carrier; among them, the free login type includes redirecting to the municipal page without logging in to the district system and redirecting to the municipal page without logging in when logging in to the district system.

[0127] Example 4

[0128] This embodiment also provides an electronic device, referring to Figure 4 , includes a memory 404 and a processor 402, wherein the memory 404 stores a computer program, and the processor 402 is configured to run the computer program to perform the steps in any of the above method embodiments.

[0129] Specifically, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0130] Among them, the memory 404 may include a large-capacity memory 404 for data or instructions. By way of example and not limitation, the memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 404 may include a removable or non-removable (or fixed) medium. Where appropriate, the memory 404 may be inside or outside the data processing device. In a specific embodiment, the memory 404 is a non-volatile memory. In a specific embodiment, the memory 404 includes a read-only memory (ROM) and a random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (Programmable Read-Only Memory, abbreviated as PROM), an erasable PROM (Erasable Programmable Read-Only Memory, abbreviated as EPROM), an electrically erasable PROM (Electrically Erasable Programmable Read-Only Memory, abbreviated as EEPROM), an electrically alterable ROM (Electrically Alterable Read-Only Memory, abbreviated as EAROM) or a flash memory (FLASH) or a combination of two or more of these. In appropriate circumstances, the RAM can be a static random access memory (SRAM) or a dynamic random access memory (DRAM), wherein the DRAM can be a fast page mode dynamic random access memory 404 (FPMDRAM), an extended data output dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0131] The memory 404 may be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor 402 .

[0132] The processor 402 reads and executes the computer program instructions stored in the memory 404 to implement any dynamic credential-based associated application authentication access method in the above embodiments.

[0133] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408 , wherein the transmission device 406 is connected to the processor 402 , and the input / output device 408 is connected to the processor 402 .

[0134] Transmission device 406 can be used to receive or send data via a network. Specific examples of the aforementioned network may include a wired or wireless network provided by a communications provider of the electronic device. In one embodiment, the transmission device includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one embodiment, transmission device 406 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0135] The input / output device 408 is used to input or output information. In this embodiment, the input information may be an http request, etc., and the output information may be a login-free page, etc.

[0136] Example 5

[0137] This embodiment further provides a readable storage medium, in which a computer program is stored. The computer program includes a program code for controlling a process to execute a process. The process includes the dynamic credential-based associated application authentication access method according to the first embodiment.

[0138] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be repeated here.

[0139] In general, various embodiments may be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flow charts, or using some other graphical representation, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0140] Embodiments of the present invention can be implemented by computer software, which is executable by the data processor of the mobile device, such as in the processor entity, or is implemented by hardware, or is implemented by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets and / or macros can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product can include one or more computer executable components configured to perform the embodiment when the program is running. One or more computer executable components can be at least one software code or a part thereof. In addition, at this point, it should be noted that any box of the logic flow in the figure can represent a program step, or interconnected logical circuits, boxes and functions, or a combination of program steps and logical circuits, boxes and functions. The software can be stored in physical media such as memory chips or storage blocks implemented in the processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs. Physical media is non-transient media.

[0141] Those skilled in the art should understand that the technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0142] The above embodiments merely illustrate several embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.< / ip:port> < / ip:port> < / ip:port> < / ip:port> < / ip:port> < / ip:port> < / ip:port> < / ip:port>

Claims

1. A dynamic credential-based authentication access method for associated applications, characterized in that: The following steps are involved: S00. The district-level system server responds to the user's access http request operation on the browser and uses the interface access credential to send a request for obtaining a temporary credential to the municipal-level server; S10, the municipal service terminal checks whether the interface access credential is expired; S20. If the temporary certificate has not expired, return the temporary certificate to the district-level system server; S30, the district-level system server extracts the client source IP in the access http request, and stores the client source IP and the temporary credential in a temporary credential table; S40: In the district-level system server, the data carrier is encoded and signed, and the data carrier is spliced ​​into a URL and returned to the front-end page of the browser, with the HTTP response status being 302 redirect; S50: After receiving the http response with status 302, the browser initiates an http request to the municipal system server; S60, the municipal system server receives the http request from the browser and extracts the url parameters and performs decoding verification to verify that the url parameters have not been tampered with, and extracts the client source ip and temporary credentials and sends a verification request to the district system server; S70, the district-level system server receives the verification request and extracts the client source IP and temporary credentials to query the temporary credentials table; S80. If the extracted client source IP address and temporary credentials are found, a verification result is returned to the municipal system server. S90: The municipal system server receives and verifies that the data is correct and returns the page to the browser according to the free login type in the data carrier; Among them, the log-in-free type includes redirecting to the city-level page without logging in to the district-level system and redirecting to the city-level page without logging in to the district-level system.

2. The dynamic credential-based associated application authentication access method according to claim 1, wherein: In step S90, if the data carrier does not need to log in to the district-level system and redirects to the municipal-level page without logging in, an internal login is performed according to the account agreed upon by the district-level department and the municipal-level department and then the page is returned to the browser; if the data carrier needs to log in to the district-level system and redirects to the municipal-level page without logging in, the value of the subject attribute in the data carrier is extracted as the corresponding login user identifier in the municipal system, the user is internally logged in and returned to the browser page.

3. The dynamic credential-based associated application authentication access method according to claim 1, wherein: The district-level system server stores the identity credentials registered with the municipal-level system server, and periodically requests the municipal-level system server to obtain an interface access credential, which corresponds one-to-one to the identity credential.

4. The dynamic credential-based associated application authentication access method according to claim 3, wherein: When a district-level department requests the municipal department to connect the municipal page to the district-level system without logging in, after the municipal department agrees, the district-level system will be registered with the municipal system, and the municipal system will provide identity credentials.

5. The dynamic credential-based associated application authentication access method according to claim 3, wherein: The identity credential includes an identifier and a key. The identifier corresponds to the district-level system and is unique. The key is used as a signature for redirection URL parameters in the district-level system.

6. The dynamic credential-based associated application authentication access method according to claim 1, wherein: The data carrier includes a free login type, a temporary credential and an extended attribute. When the free login type requires logging into a district-level system but redirects to a city-level page, the data carrier also includes a subject attribute, the value of which is a login user identifier that needs to be passed to the city-level system.

7. The dynamic credential-based associated application authentication access method according to any one of claims 1 to 6, wherein: In step S80, if the record of the extracted client source IP and temporary credentials is found, the record is deleted from the temporary credential table and a verification result is returned.

8. A method and apparatus for accessing associated applications based on dynamic credentials, characterized in that: include: A human-computer interaction interface, used for users to initiate an HTTP request operation to access the district-level system; After receiving a 302 status HTTP response, it redirects to the URL in the response header, i.e. initiates an HTTP request to the municipal system server; it is used to display the request result; The district-level system is used to respond to the user's access HTTP request operation on the browser, use the interface access credential to send a request for temporary credentials to the municipal server; it is used to extract the client source IP in the access HTTP request and store the client source IP and temporary credentials in the temporary credential table; it encodes and signs the data carrier, splices it into a URL and returns a response to the browser's front-end page, with the HTTP response status being 302 redirect; Used to receive verification requests and extract the client source IP and temporary credentials for querying in the temporary credentials table; if the extracted client source IP and temporary credentials are found, the verification result is returned to the municipal system server; The municipal system is used to check whether the interface access credentials are expired; if not, a temporary credential is returned to the district system server; it is used to receive the browser's http request and extract the url parameters and perform decoding verification to verify that the url parameters have not been tampered with, and at the same time extract the client source ip and temporary credential to send a verification request to the district system server; it is used to receive the correct verification and return it to the browser page according to the free login type in the data carrier; among them, the free login type includes redirecting to the municipal page without logging in to the district system and redirecting to the municipal page without logging in when logging in to the district system.

9. An electronic device comprising a memory and a processor, characterized in that: The memory stores a computer program, and the processor is configured to run the computer program to execute the dynamic credential-based associated application authentication access method according to any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, wherein the computer program includes a program code for controlling a process to execute a process, wherein the process includes the dynamic credential-based associated application authentication access method according to any one of claims 1 to 7.

Images