CN111291353A

CN111291353A - Account number association method and device and computer storage medium

Info

Publication number: CN111291353A
Application number: CN202010080703.5A
Authority: CN
Inventors: 谢健
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2020-02-05
Filing date: 2020-02-05
Publication date: 2020-06-16
Anticipated expiration: 2040-02-05
Also published as: CN111291353B

Abstract

The embodiment of the application provides an account number association method, an account number association device and a computer storage medium, wherein the account number association method comprises the following steps: acquiring data to be detected; when the data to be detected comprises a service request, acquiring a first jump value and a service bill from the data to be detected; the first jump value is a parameter associated with a user request service, and the service bill is a certificate issued to a legal user by a service module in the single sign-on system; determining an account number associated with the first jump value based on the cache table, establishing a first association relation between the determined account number and the service bill, and updating the first association table according to the first association relation; the first association table is used for indicating the association relationship between the service bill and the account; therefore, by extracting the data packet of the user accessing the system, the possible dangerous behaviors of the user can be warned in advance, and the safety of the system is improved.

Description

Account number association method and device and computer storage medium

Technical Field

The present application relates to the field of communications security technologies, and in particular, to an account association method, an account association apparatus, and a computer storage medium.

Background

In the initial development stage of an enterprise, one or two systems used by the enterprise are usually provided, each system is provided with an account extraction unit, and operators log in with the accounts every day, so that the operation is very convenient. However, with the development of enterprises, the number of systems used increases, and operators need to log in for many times when operating different systems, and the account numbers of each system are different, which is very inconvenient for the operators. To solve this problem, single sign-on systems have been created, i.e. other mutually trusted application systems can be accessed by one sign-on. Referring to fig. 1, a timing diagram of a CAS single sign-on process provided in a related technical solution is shown, after a user logs in to a service 1, a service 2 also logs in. However, in the message of the access service, because the account function of the single sign-on system is not perfect, the supervising department cannot effectively analyze the behavior of the user, and cannot timely perform risk monitoring on the behavior of the user, so that the user may have dangerous behaviors like deleting the library and the like.

Disclosure of Invention

In view of the above, a main object of the present application is to provide an account associating method, an account associating device, and a computer storage medium, which can early warn a user of a possible dangerous behavior in advance, so as to improve the security of the whole system.

In order to achieve the purpose, the technical scheme of the application is realized as follows:

in a first aspect, an embodiment of the present application provides an account association method, where the method includes:

acquiring data to be detected;

when the data to be detected comprises a service request, acquiring a first jump value and a service bill from the data to be detected; the first jump value is a parameter associated with a user request service, and the service bill is a certificate issued to a legal user by a service module in the single sign-on system;

determining an account number associated with the first skip value based on a cache table, establishing a first association relation between the determined account number and the service bill, and updating a first association table according to the first association relation; the cache table is used for indicating an association relationship between a jump value and an account, and the first association table is used for indicating an association relationship between a service bill and an account.

In a second aspect, an embodiment of the present application provides an account number association apparatus, where the account number association apparatus includes an obtaining unit, a first detecting unit, and an associating unit; wherein the content of the first and second substances,

an acquisition unit configured to acquire data to be detected;

the first detection unit is configured to acquire a first jump value and a service bill from the data to be detected when the data to be detected comprises a service request; the first jump value is a parameter associated with a user request service, and the service bill is a certificate issued to a legal user by a service module in the single sign-on system;

the association unit is configured to determine an account number associated with the first skip value based on a cache table, establish a first association relationship between the determined account number and the service ticket, and update a first association table according to the first association relationship; the cache table is used for indicating an association relationship between a jump value and an account, and the first association table is used for indicating an association relationship between a service bill and an account.

In a third aspect, an embodiment of the present application provides an account number associating apparatus, where the account number associating apparatus includes a memory and a processor; wherein the content of the first and second substances,

the memory for storing a computer program operable on the processor;

the processor, when executing the computer program, is adapted to perform the method according to the first aspect.

In a fourth aspect, an embodiment of the present application provides a computer storage medium storing an account association program, where the account association program, when executed by at least one processor, implements the method of the first aspect.

The embodiment of the application provides an account number association method, an account number association device and a computer storage medium, wherein the method comprises the steps of obtaining data to be detected; when the data to be detected comprises a service request, acquiring a first jump value and a service bill from the data to be detected; the first jump value is a parameter associated with a user request service, and the service ticket is a certificate issued to a legal user by a service module; determining an account number associated with the first jump value based on a cache table, and storing the determined account number and the service bill in a first association table in an associated manner; the cache table is used for indicating an incidence relation between a jump value and an account; therefore, by extracting the data packets of the user and the accessed system and using the jump value as the intermediary information, the user and the accessed service can be effectively bound, the user behavior can be more effectively analyzed, the possible dangerous behavior of the user can be early warned in advance, and the safety of the whole system is improved; in addition, by early warning of possible dangerous behaviors of the user, system breakdown caused by user operation can be effectively avoided, and therefore the stability of the whole system is guaranteed.

Drawings

Fig. 1 is a timing sequence example of a CAS single sign-on process provided in the related art;

fig. 2 is a schematic structural diagram of a single sign-on system according to a related art;

fig. 3 is a schematic flowchart of an account association method according to an embodiment of the present application;

fig. 4 is a schematic flowchart of another account association method according to an embodiment of the present application;

fig. 5 is a schematic flowchart of another account association method provided in the embodiment of the present application;

fig. 6 is a schematic flowchart of another account association method according to an embodiment of the present application;

fig. 7 is an application scene diagram of an account association method according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a component of an account association apparatus according to an embodiment of the present disclosure;

fig. 9 is a schematic structural diagram of another account association apparatus according to an embodiment of the present disclosure;

fig. 10 is a schematic hardware structure diagram of an account association apparatus according to an embodiment of the present disclosure;

fig. 11 is a schematic structural diagram of a device according to an embodiment of the present disclosure.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

Single Sign On (SSO) refers to one-time authenticated login of a user, and when the user logs in On an identity authentication server once, the user can obtain the right to access other associated systems and application software in the Single Sign On system, and meanwhile, the implementation does not require an administrator to modify the login state or other information of the user, which means that in a plurality of application systems, the user can access all mutually trusted application systems only by logging in once, see fig. 2, which shows a structural schematic diagram of the Single Sign On system in the related technical scheme, as shown in fig. 2, the SSO system in the diagram can be divided into four parts, namely, a service 1, a service 2, a service 3 and a login module. The service 1, the service 2 and the service 3 have no login module, but the login module has no service for providing service, the login module can be generally called as a login module of an SSO system, the service 1, the service 2 and the service 3 are called as service modules of the SSO system, when the service 1, the service 2 and the service 3 need to log in, the login module is jumped to, the login module completes login, and other application systems log in accordingly. However, in actual use, when a user logged in through the SSO accesses another service, the user carries an identity credential issued by the login module instead of identity information of the user, so that a monitoring person cannot bind the user and the service accessed by the user in time, and some malicious behaviors of the user cannot be prevented.

In actual use, a Central Authentication Service (CAS) is often used to perform the architecture of the SSO system. As shown in fig. 1, the main components of the CAS single sign-on process include a user, a browser, a CAS server, a service 1, and a service 2, and the main interaction steps include:

a user accesses the service 1 through a browser, wherein the service 1 needs to be logged in, but the user does not log in at present;

jumping to a CAS server, namely an SSO login module, the CAS server in the later figure is uniformly called the SSO login module; the SSO login module does not log in, and a user login page is popped up for a user to key in a password;

a user fills in an account and a password, after an SSO login module authenticates, a login state is written in a session (session, computer term, a concept of session needs to comprise a specific client, a specific server and uninterrupted operation time) of the SSO login module, and cookies (cookies, computer term, data stored on a local terminal of the user after session tracking is performed, and information temporarily or permanently stored by a computer of the client of the user) under an SSO domain are written in a browser;

after the SSO login module finishes login, a login bill is generated, then the operation 1 system is jumped to, and meanwhile the login bill is used as a parameter to be transmitted to the operation 1 system;

after the business 1 system takes the login bill, a request is sent to the SSO from the background to verify whether the login bill is valid;

after the verification is passed, the service 1 system writes the login state into session and sets cookie under the service 1 domain.

Therefore, cross-domain single sign-on is completed, and when the user accesses the service 1 again later, the service 1 is logged on; if the user accesses the service 2, the flow is as follows:

a user accesses the service 2 system, and the service 2 does not log in, and jumps to an SSO login module;

because the SSO login module is logged in, the login authentication is not required to be carried out again;

the SSO login module generates a login bill, the browser jumps to the service 2, and the login bill is taken as a parameter to be transmitted to the service 2;

the service 2 takes a login bill, accesses the SSO login module in the background and verifies whether the login bill is valid or not;

after the verification is successful, the service 2 writes the login status into the session, and writes the cookie in the service 2 domain.

Thus, the service 2 system is already logged in without going through the login process, and thus, the SSO login module, the service 1 and the service 2 are in different domains, and the session between them is not shared and is not problematic.

However, in actual use, a user who logs in through the SSO cannot bind the user and a service accessed by the user in time due to a login bill carried when accessing another system, instead of direct user information, and cannot prevent some malicious behaviors of the user.

In order to solve the technical problem, an embodiment of the present application provides an account association method, in which data to be detected is acquired; when the data to be detected comprises a service request, acquiring a first jump value and a service bill from the data to be detected; the first jump value is a parameter associated with a user request service, and the service ticket is a certificate issued to a legal user by a service module; determining an account number associated with the first jump value based on a cache table, and storing the determined account number and the service bill in a first association table in an associated manner; the cache table is used for indicating an incidence relation between a jump value and an account; therefore, by extracting the data packets of the user and the accessed SSO system and using the jump value as the intermediary information, the user and the accessed service can be effectively bound, so that the user behavior can be more effectively analyzed, and the safety of the whole system is improved; in addition, by early warning of possible dangerous behaviors of the user, system breakdown caused by user operation can be effectively avoided, and therefore the stability of the whole system is guaranteed.

In an embodiment of the present application, referring to fig. 3, a flowchart illustrating account association provided in the embodiment of the present application is shown, and as shown in fig. 3, the method may include:

s101: acquiring data to be detected;

it should be noted that the method described in this embodiment of the present application is mainly used for monitoring the service operation performed by the user of the SSO system, where the data to be detected refers to data in a data packet sent by the user to a login module or a service module in the SSO system, and the manner of acquiring the data to be detected may be interception, replication, filtering, mirror image transmission, and the like.

It should be noted that the data to be detected is essentially data in a data packet interacted between the user and the SSO system, and the application is more like extracting the data by a copying method for detection, and the process does not affect the continuous transmission of the data of the user to the SSO system.

S102: when the data to be detected comprises a service request, acquiring a first jump value and a service bill from the data to be detected; the first jump value is a parameter associated with a user request service, and the service bill is a certificate issued to a legal user by a service module in the single sign-on system;

it should be noted that, the data from the user to the single sign-on system can be divided into two categories, one is a sign-on request, and the other is a service request, wherein for the data containing the sign-on request, the information is more, the account number of the data is easier to determine, and the basis for associating the subsequent account number is mainly provided; for data containing a service request, the data does not directly contain information of a user account, and the account needs to be determined by relying on information collected when a login request is performed before.

It should be further noted that, according to the architecture rule of the SSO system, when data interacted between the user and the SSO system contains a service request, it indicates that the user has started to normally access the service module, and uses various services provided by the service module, that is, it indicates that the user has completed the process of acquiring a login ticket from the login module, accessing the service module with the login ticket, verifying validity of the login ticket by the service module to the login module, and issuing a service ticket to the user by the service module according to the login ticket, so that the data to be detected must contain the service ticket and the first jump value.

The service ticket refers to a certificate issued by a service in a service module for a legal user and identifying the identity of the legal user, wherein one implementation form of the service ticket may be a session ID, that is, after the service 1 verifies a login ticket of the user, the login state is written into the session and a cookie under a service 1 domain is set, and when the service 1 carries the session ID (that is, the service ticket) for subsequent access, the service 1 can know which session the user is in and provide a corresponding service.

The skip value is a parameter associated with a service requested by a user, that is, when the user initiates a request to different service modules, the skip value carries different skip values; for example, a service module of single sign-on may include a service 1 and a service 2, and after a user requests the service 1 to trigger a login operation, the transmitted data carries skip information. It is noted that the jump information belongs to "class" information, which in turn may include specific jump values, index words, location words, and the like. The skip value is information mainly used for identifying the skip, that is, for an individual user, the skip value is unique and remains unchanged in the same business process, and is used for informing a server of a destination and other related information of the skip. Meanwhile, after the user successfully logs in, the hop value is also included in the subsequent service data of the service 1, so that the service end can be ensured to acquire the service path corresponding to the subsequent service data, and further the service process corresponding to the subsequent service data is determined. The jump value is a parameter associated with the service requested by the user, and the same user has a determined jump value in one session; that is, the hop value is the same as the identifier of the user for a service request, and when the server receives the hop value of the user, the service path and the process corresponding to the user can be determined.

It should be further noted that, the method provided by this embodiment is used for an already-constructed SSO system, and binds an account of a user with a service accessed by the user, so that interaction rules between the SSO system and the user (i.e., a form and content of a data packet interacted between the user and the SSO system) are known. That is, the first jump value and the service ticket can be found at the specified position of the data to be detected according to the foreseen packet sending rule between the user and the SSO system.

In some embodiments, the S102 may further include:

judging whether the data to be detected contains a service address;

when the data to be detected has a service address, determining the storage positions of a service bill and a first jump value in the data to be detected according to a first preset rule, and acquiring the first jump value and the service bill from the data to be detected; the first preset rule is used for indicating a configuration relation among a pre-stored service address, a pre-stored service bill and a pre-stored skip value;

when the data to be detected has no service address, determining the storage positions of a service bill and a first jump value in the data to be detected according to a second preset rule, and acquiring the first jump value and the service bill from the data to be detected; the first preset rule is different from the second preset rule, and the second preset rule is used for indicating a configuration relationship between a pre-stored service bill and a jump value.

It should be noted that, for data containing service requests, the packet sending rules between the user and the SSO system can be divided into two categories, one category is with service addresses, and the other category is without service addresses; the forms of the data packets under the two rules are different, and the positions for storing the jump value and the service ticket are different. In order to improve the searching efficiency, firstly judging whether the data to be detected contains a service address, if so, determining the storage positions of a service bill and a first jump value in the data to be detected according to a first preset rule, and then taking out the service bill and the first jump value; if not, determining the storage positions of the service bill and the first jump value in the data to be detected according to a second preset rule; the first hop value and the service ticket are then taken out. The first preset rule and the second preset rule are both known package sending rules of the user and the SSO system.

S103: determining an account number associated with the first skip value based on a cache table, establishing a first association relation between the determined account number and the service bill, and updating a first association table according to the first association relation; the cache table is used for indicating an association relationship between a jump value and an account, and the first association table is used for indicating an association relationship between a service bill and an account.

It should be noted that when the acquired data to be detected contains a service request, it indicates that the user has logged in the service module for interaction, and indicates that the user has completed a login process, that is, the user has sent data carrying the login request, so that the account associated with the first skip value can be found in the cache table without fail, thereby determining the account associated with the first skip value, establishing a first association relationship between the determined account and the service ticket, and storing the first association relationship in the first association table to complete association.

In the above embodiment, S102 may also be configured as follows:

acquiring a service bill from the data to be detected, and judging whether the first association table contains the service bill or not;

and when the first association table does not contain the service ticket, acquiring a first jump value from the data to be detected.

It should be noted that, after the data to be detected is acquired, since the user may interact with the same service of the SSO system for multiple times, if the account of the user is already bound with the service, the binding process does not need to be repeated again each time, which consumes excessive processing amount. Therefore, after the service ticket is acquired, whether the service ticket is already stored is searched in the first association table, and if the service ticket is searched in the first association table, which indicates that the account of the user is bound with the service, the first skip value does not need to be extracted to perform S103; if the service ticket is not found in the first association table, the first skip value needs to be extracted to perform S103. Therefore, the jump value and the corresponding account number of the user can be obtained through the login request of the user, and a basis is provided for subsequent account number association.

In the above embodiment, after S103, the method may further include:

determining a service bill corresponding to the account number based on the first association table;

and monitoring behavior information corresponding to the account according to the determined service bill.

It should be noted that: the information of the service bill and the account stored in the first association table is the basis for monitoring the user behavior by the background, the account can be determined from the data of the user and the specific service according to the service bill and the account in the first association table, and the user and the accessed service are bound according to the service bill, so that the monitoring of the user behavior is realized.

The embodiment provides an account association method, which includes acquiring data to be detected; when the data to be detected comprises a service request, acquiring a first jump value and a service bill from the data to be detected; the first jump value is a parameter associated with a user request service, and the service bill is a certificate issued to a legal user by a service module in the single sign-on system; determining an account number associated with the first skip value based on a cache table, establishing a first association relation between the determined account number and the service bill, and updating a first association table according to the first association relation; the cache table is used for indicating an association relationship between a jump value and an account, and the first association table is used for indicating an association relationship between a service bill and an account; therefore, by extracting the data of the user and the accessed SSO system and using the jump value as the intermediary information, the user and the accessed service can be effectively bound, so that the user behavior can be more effectively analyzed, and the safety of the whole system is improved; in addition, by early warning of possible dangerous behaviors of the user, system breakdown caused by user operation can be effectively avoided, and therefore the stability of the whole system is guaranteed.

In another embodiment of the present application, referring to fig. 4, a flowchart illustrating another account association provided in the embodiment of the present application is shown, and as shown in fig. 4, the method may include:

s201: acquiring data to be detected;

it should be noted that the method described in this embodiment of the present application is mainly used for monitoring subsequent service operations performed by a legitimate end user of the SSO system, where the data refers to data in a data packet sent by the end user to the SSO login system or the service module, and the manner of obtaining the data may be interception, filtering, mirror image transmission, and the like.

S202: when the data to be detected comprises a single sign-on request, acquiring a second jump value and a second sign-on bill from the data to be detected; the second login bill is a certificate issued to a legal user by a login module in the single sign-on system;

it should be noted that: the single sign-on request, typically in the form of a uniform resource locator (url), represents the location of the resource requested by the user.

It should be noted that, in the SSO system, the user login can be subdivided into two steps, the first step is that the user submits a user password to the login module, the login module returns a login ticket to the user after the user passes the authentication, and the user sends the login ticket to the service module as a credential of successful login, an account of the user, and a requested service to obtain a service. For example, when the user applies for login to the service 1, because the service 1 has no independent login module, the skip login module is authenticated, after the user fills in an account password, the user waits for the login module to successfully authenticate and returns a login bill, and the user side transmits the login bill, the account number and rule information (url and the like) to the service 1 to complete the login of the service 1. Of course, this process is very fast in nature, and for the user, only the account number and password are entered, and the rest will be automatically skipped by the system. In the process, the data to be detected refers to data sent to the service 1 after the user obtains the login ticket, and because the first data only contains the account password, information related to the service ticket in the subsequent service request cannot be provided.

It should be noted that the second hop value has the same essence meaning as the first hop value, and is a parameter associated with the service requested by the user, and the same user has a certain hop value in one session; that is, the hop value is, for example, an identifier of the user for a service request, and when the server receives the hop value of the user, the service path and the process corresponding to the user can be determined.

It should be noted that the login ticket issues a credential to a valid user for the login module in the SSO system, that is, the single sign-on system provides an independent login ticket for each valid user, that is, the login module confirms the valid identity of the user by identifying the login ticket, thereby providing subsequent operations. And when the user obtains the login bill and subsequently logs in other different service modules, the login bill is used for carrying out related verification.

S203: determining an account number associated with the second login bill, establishing a second association relation between the determined account number and the second login bill, and updating the cache table according to the second association relation.

It should be noted that, because the login ticket is issued by the login module in the SSO system, according to the architecture and rules of the structured SSO system, the account number associated with the second login ticket may be determined, for example, the account number may be determined according to the login ticket by a file recording a corresponding relationship, or a specific location in the data may contain the account number, or the data may contain a specific identifier, and the account number is further determined according to a mapping relationship of the identifier, which need to be determined according to the SSO system to be monitored. Therefore, for the service request of the user, the corresponding account number can be obtained in the cache table through the jump value, and the second association relationship is established.

The embodiment provides an account association method, which elaborates the specific implementation of the embodiment, and it can be seen that, according to the technical scheme of the embodiment, after data to be detected is acquired, by extracting data of a user and an accessed SSO system and using a skip value as intermediary information, the user and a service accessed by the user can be effectively bound, so that user behavior can be more effectively analyzed, and the security of the whole system is improved; in addition, by early warning of possible dangerous behaviors of the user, system breakdown caused by user operation can be effectively avoided, and therefore the stability of the whole system is guaranteed.

In another embodiment of the present application, referring to fig. 5, a flowchart of another account association method provided in the embodiment of the present application is shown, and as shown in fig. 5, the method may include:

s301: acquiring data to be extracted including a single sign-on request; the data to be extracted is different from the data to be detected;

it should be noted that before the to-be-detected data including the service request is acquired, the to-be-extracted data including the single sign-on request of the user must be acquired, that is, when the to-be-extracted data is prior to the to-be-detected data including the service request in terms of time and is the same as the to-be-detected data, the to-be-extracted data is sent by the same user. That is, in terms of time, data to be extracted including a single sign-on request of a user is received first, and then data to be detected including a service request of the user is received. Meanwhile, for the method, when a certain time point obtains a piece of data, it may be "data to be extracted" of other users, and it may also be that "data to be detected" corresponding to "data to be extracted" is received before. Therefore, the first two are descriptions of different processing of the same data received at the same time point in the embodiment, and the description of the embodiment mainly refers to different data of the same user received at different time points.

S302: acquiring a first jump value and a first login bill from the data to be extracted; the first login bill and the service bill are certificates owned by the same user;

it should be noted that, since the data to be extracted is data included in a data packet sent when the user performs single sign-on, the data to be extracted necessarily includes a first skip value and a first login ticket, and meanwhile, the specific process of acquiring the first skip value and the first login ticket is to determine the storage location of the first skip value and the first login ticket in the data to be extracted first according to the packet sending rule of the user and the SSO system, and then take out the first skip value and the first login ticket from the corresponding location.

S303: determining an account number associated with the first login bill, establishing a third association relationship between the determined account number and the first jump value, and storing the third association relationship in the cache table.

It should be noted that: and determining an account number according to the first login bill, establishing a third association relation between the determined account number and the first jump value, and storing the third association relation in the cache table for subsequent query. The process of the account number determined according to the first login ticket comprises the following steps:

when the single sign-on request is a GET request (representing a request for data from a server), determining an account number associated with the first login bill based on a second association table; the second association table is used for indicating the association relationship between the pre-stored login ticket and the account.

And when the single sign-on request is a POST request (representing a request for transmitting data to a server), acquiring an account number associated with the first login bill from the data to be extracted.

It should be noted that the login request of the user may be divided into a POST request and a GET request, where the POST request refers to that the user submits a user password, and the GET request refers to that the user is already in a login state and initiates a request to another service module, for example, the user has logged in the login module when using the service 1, and then applies for using the service 2. For the two requests, the specific contents of the data are different, so that the corresponding account needs to be determined according to the specific contents contained in the corresponding data.

It should be noted that, determining whether the single sign-on request is a POST request or a GET request is determined according to a specific programming manner of the SSO system to be monitored, that is, for an already-constructed SSO system, it must specify a form and an identifier corresponding to the POST request and the GET request, that is, for an already-constructed SSO system, a url of the POST request and a url of the GET request have a definite distinction.

It should be noted that, when the single sign-on request is a POST request, the user should submit a user password, the data of the user necessarily also includes an account, and the account of the data can be determined through analysis of the content in the data. It is easy to understand that these data are not stored in a messy manner, but information interaction is performed according to the specification of the target SSO system, and the method in the embodiment of the present application monitors the structured SSO system, so that the specification of the form and content of the data packet containing the data in the SSO system can be known, and further the search and determination of the account number can be realized.

It should be noted that, when the single sign-on request is a GET request, the data generally only contains the first login ticket, and the account number associated with the first login ticket needs to be determined according to the pre-stored second association table, instead of taking out the account number from the data.

It should be noted that, when the GET request is received, the user is already in a login state, and a request is initiated to another service module, then the user must already send data containing a POST request, and when the data containing the POST request sent by the user before is obtained, the association relationship between the login ticket and the account needs to be determined, and then the association relationship needs to be stored in the second association table, so that when the GET request is received, the account can be determined based on the login ticket contained in the second association table and the data.

Therefore, in the above embodiment, when the single sign-on request is a POST request, the method further includes:

establishing a fourth incidence relation between the acquired account and the first login bill;

and updating the second association table according to the fourth association relation.

It should be noted that: when the single sign-on request is a POST request, the determined account and the first login ticket are also required to be stored in a second association table in an associated manner, and the account and the first login ticket are used as a basis for determining the account associated with the first login ticket in the GET request.

It should be noted that, from the stored content, the first association table is used for storing the association relationship between the service ticket and the account, and the second association table is used for storing the association relationship between the login ticket and the account, and has the same form, so that the second association table and the first association table may also be combined into one table and stored in a unified manner. Of course, for the final association result, the first association table is the association result finally presented, so that it is more convenient to store the first association table and the second association table separately.

The embodiment provides an account association method, which elaborates the specific implementation of the embodiment, and it can be seen that, according to the technical scheme of the embodiment, before data to be detected is acquired, the data to be extracted is acquired, the association relationship between a jump value and an account is determined, and an association basis is provided for the data to be detected; therefore, by extracting the data of the user and the accessed SSO system and using the jump value as the intermediary information, the user and the accessed service can be effectively bound, so that the user behavior can be more effectively analyzed, the possible dangerous behavior of the user can be early warned in advance, and the safety of the whole system is improved; in addition, by early warning of possible dangerous behaviors of the user, system breakdown caused by user operation can be effectively avoided, and therefore the stability of the whole system is guaranteed.

In yet another embodiment of the present application, referring to fig. 6, a specific flowchart of another account association method provided in the embodiment of the present application is shown, and as shown in fig. 6, the method may include:

s401: acquiring a data packet;

it should be noted that the data packet may be obtained by intercepting the interactive traffic between the user terminal and the SSO system, may also be transmitted by mirroring the user terminal, and may be obtained by a receiving module arranged before the SSO system.

S402: judging whether a single sign-on request url in the configuration file can be matched or not, and recording a hit rule ID; if not, jumping to step S412;

it should be noted that the configuration file is a file determined according to an interaction rule between the SSO system and the user, in which a content arrangement rule and an identifier of an interaction data packet between the SSO system and the user are recorded; when the single sign-on request url can be hit, the data packet is proved to be needed, and if the single sign-on request url is not hit, whether the data packet is a service request or not is verified.

S403: inquiring whether the jump keyword of the specified jump _ key is contained according to the hit rule ID and the position specified in the rule; if yes, executing S404, if not, ending the process;

it should be noted that if there is no jump _ key in the hit rule ID, the packet is not valid information for us, and the packet is discarded to end the process.

S404: searching a corresponding value, namely a jump value, in the data packet by using the key word of jump _ key;

it should be noted that, according to the hit rule ID, the key of the jump _ key contained in this rule is queried, and the jump _ key can be understood as the jump information, and then the value of the key relative to the jump information in the data packet is taken out as the jump value; that is, what needs to be said in the configuration file is the value (corresponding to the identifier or name) of the jump _ key, and what we take out from the data packet is the key of the jump information. The following are sample words about jump _ key in the configuration file, in this rule, value of jump _ key is "ticket", we look up in the data packet with "ticket" as the target character, and the found value is the jump value;

"jump_key":[{

"pos":"rsp_head:Location",

"keyword":["ticket"]

}]。

s405: inquiring whether the keywords of the single sign-on server bill sso _ srv _ token are contained or not according to the hit rule ID and the position appointed in the rule item; if yes, executing S406, and if not, ending the process;

it should be noted that if there is no key of the single sign-on server ticket sso _ srv _ token in the hit rule ID, the packet does not have information valid for us, and the packet is discarded to end the process.

S406: searching a corresponding value in a data packet by using a sso _ srv _ token key word, and recording the corresponding value as a login bill;

it should be noted that, similar to the foregoing, the value of the sso _ srv _ token key is queried in the rule entry, and then the key of the sso _ srv _ token is found in the data packet according to the value of the sso _ srv _ token and recorded as the login ticket. The following is a sample field about sso _ srv _ token in the configuration file, in this rule, value of sso _ srv _ token is "asp.net _ session id", we look up in the packet with "asp.net _ session id" as the target character, and the found value is the login ticket;

"sso_srv_token":[{

pos":"cookie",

"keyword":["ASP.NET_SessionId"]

}]。

s407: judging whether the request type is POST or GET, if the request type is POST request, executing S408, and if the request type is GET request, executing S410;

s408: according to the hit rule ID, inquiring whether a keyword of the account number user name _ key is contained according to the position specified in the rule entry; if yes, executing S409, and if not, ending the process;

it should be noted that when the request type is the POST type, it may be that the representative user is submitting an account and a password, and then all that needs to be obtained is the correspondence between the login ticket and the account, and the correspondence between the jump value and the account.

It should be noted that if the hit rule ID does not have the keyword of the account username, the packet does not have information valid for us, and the packet is discarded to end the process.

S409: two pieces of data were recorded: (1) taking a login bill (namely the value found by the sso _ srv _ token keyword) as a key, taking an account number (namely the value found by the username keyword) as a value, and recording the value in a first day table; the first day table is the first association table; (2) and (3) taking the jump value (namely the value found by the jump _ key keyword) as a key, taking the account number (namely the value found by the username keyword) as a value, and recording the value into the temporary table.

It should be noted that when the login request is a POST request, two corresponding relationships need to be obtained, one is a corresponding relationship between the login ticket and the account, and this corresponding relationship is a basis for determining the account in the GET request; one is the corresponding relationship between the jump value and the account number, which is the basis for determining the account number in the subsequent service request.

It should also be noted that: the temporary table, namely the aforementioned cache table, can be emptied periodically because the skip value is only valid for a period of time for the user.

S410: inquiring an account number in a first day table according to the login bill; if the result is queried, S411 is executed, and if the query is not successful, the flow ends.

Note that, the first day table records the association relationship between the login ticket and the account, and the first day table is the aforementioned second association table. Here, the day table is a self-defined name in actual use, and is used for indicating a long-term existing association table in which final information is recorded; corresponding to the temporary table, the temporary table is a short-term association table which only records intermediate information; the system comprises a first day table, a second day table, a service bill and an account, wherein the day table is divided into the first day table and the second day table, the first day table records the service bill and the account, and the second day table records the login bill and the account; the temporary table records a jump value and an account, when account association is performed, the first day table needs to determine the association relationship between a service bill and the account according to the jump value and the information of the account provided by the temporary table, and meanwhile, in the GET request, the temporary table needs to determine the association relationship between the jump value and the account according to the information of a login bill and the account provided by the second day table. In addition, the jump value has certain timeliness, so the temporary table can be deleted and emptied after 2-3 days of generation, and the service bill and the login bill are relatively fixed and are finally associated, so the first day table and the second day table exist for a long time.

It should be noted that, when the request type is a GET type, it represents that the user may have logged in to the module, and the current data packet is an application for another service, so it is necessary to determine an account of a login ticket carried by the user based on the first day table, and obtain a correspondence between a jump value and the account.

S411: recording a piece of data: and (3) taking the jump value (namely the value found by the jump _ key keyword) as a key, taking the account number (namely the value found by the username keyword) as a value, and recording the value into the temporary table.

It should be noted that, when the login request is a GET request, a corresponding relationship, that is, a corresponding relationship between the jump value and the account, is obtained, and is used as a basis for determining the account in a subsequent service request.

S412: judging whether any service address in the configuration file can be matched or not, and recording a hit rule ID; if yes, executing S413, if not, jumping to the step S421;

it should be noted that when the data packet does not contain a login request, it may be a service request, and more specifically, the service request may be subdivided into a service request with a service address and a service request without a service address; for the two service requests, the actual processes are the same, the skip value and the service bill are retrieved, the account is finally obtained according to the skip value, and the account and the service bill are associated. However, the content arrangement of the data packets of the two service requests is slightly different, so the specific extraction rules and flow are slightly different.

S413: according to the hit rule ID, inquiring whether the keyword of the business bill busi _ token _ key is contained or not according to the position specified in the rule entry, if yes, executing S414, and if not, ending the process;

it should be noted that if there is no key of the service ticket busi _ token _ key in the hit rule ID, the packet does not have information valid for us, and the packet is discarded to end the process.

S414: searching a corresponding value, namely a service bill, in the data packet by using the busi _ token key;

it should be noted that, similar to the foregoing, the busi _ token key is queried in the rule entry, that is, the value of busi _ token is found in the data packet according to the value of busi _ token, and the key of busi _ token is recorded as the login ticket; the following is a sample phrase field about the busi _ token in the configuration file, in this rule, the value of the busi _ token includes a plurality of values, respectively, "ci _ session", "dsyangfodataagencyusercode", "dsyangfodatagrouposusercode", "asp.net _ SessionId", ". WEBCOOKIE" and LoginUserTicket ", the values of the busi _ token are sequentially taken out to be matched in the data packet, and after matching is successful, the key corresponding to the busi _ token is taken out, namely the login ticket;

"busi_token":[{"pos":"cookie",

"keyword":["ci_session",

"DYSangForDataAgencyUserCode",

"DYSangForDataGroupUserCode",

"ASP.NET_SessionId",

".WEBCOOKIE",

"LoginUserTicket"]

}]。

s415: inquiring in the next day table by the service bill, and judging whether a corresponding item is inquired; if yes, if not, executing S416;

it should be noted that: the second day table records the association relationship between the login ticket and the account, and the second day table is the aforementioned third association table. It should be noted that this step mainly prevents repeated association, and when a user initiates a service request with a service module for the first time and has bound the user, it is not necessary to retrieve and associate the data packets of the same service process for the same user again.

S416: according to the hit rule ID and the keyword of the first jump _ key specified in the rule entry, inquiring whether the data packet contains the keyword; if yes, executing S418, if not, executing S417;

it should be noted that if there is no jump information in the hit rule ID, the packet does not have information valid for us, and the packet is discarded to end the process.

S417: inquiring whether the data packet contains the keyword or not according to the keyword of the next jump _ key specified in the rule entry until the keyword of the jump _ key is inquired;

it should be noted that, in actual use, a user may not jump to a target service at one time, so that multiple jump _ key words may exist in a hit rule entry, and therefore, all the jump _ key keywords need to be queried.

S418: searching a corresponding value in the data packet by using the jump _ key keyword, and recording the value as a jump value;

it should be noted that this step is used to extract the jump value included in the service request, so as to determine the corresponding account according to the temporary table.

S419: inquiring the temporary table by the jump value to determine a corresponding account number;

it should be noted that if the query is not received, it may be error data, and the end flow may be directly discarded.

S420: determining an association relation in a second day table of the business bill and the determined account record;

in this way, the user and the service accessed by the user can be bound to monitor the user's behavior.

S421: judging whether any rule in the configuration file can be matched, recording the rule ID and taking out the keywords of the business bill busi _ token in the rule; if yes, executing S421, otherwise, ending;

it should be noted that, further, matching is performed on the service request without the service address, and if the rule cannot be matched, the packet does not have information valid for us, and the packet is discarded to end the process.

S422: searching a corresponding value, namely a service bill, in the data packet by using the busi _ token key;

it should be noted that this step is used to take out the service ticket to confirm the corresponding account in the data packet.

S423: inquiring in the next day table by the service bill to see whether a corresponding item can be inquired; if it can be ended, if S423 cannot be performed;

it should be noted that this step mainly prevents repeated association, and when a user initiates a service request with a service module for the first time and has bound the user, it is not necessary to retrieve and associate the data packets of the same service process for the same user again.

S424: according to the hit rule ID and the keyword of the first jump _ key specified in the rule entry, inquiring whether the data packet contains the keyword; if yes, executing S426, if no, executing S425;

it should be noted that this step is mainly to determine whether the data packet contains a jump value.

S425: inquiring whether the data packet contains the key word or not according to the key word of the next jump _ key specified in the rule entry; if yes, executing S427; if not, go to S426;

it should be noted that, for the user, a jump in the service module may occur, so that there may be more than one jump _ key keyword in the request, and these jump _ key keywords need to be polled until the corresponding jump value is queried in the data packet.

S426: if the jump _ key keyword is not matched after polling, polling the next business bill keyword busi _ token _ key;

it should be noted that, in the actual interactive data packet, the user may apply for a plurality of service tickets, may contain a plurality of busi _ token _ keys, and needs to sequentially query the busi _ token _ keys.

S427: searching a corresponding value, namely a jump value, in the data packet by using the key word of jump _ key;

S428: inquiring the temporary table by the jump value to determine a corresponding account number;

S429: and determining the association relationship in the second day table of the business ticket (value found by the busi _ token key keyword) and the determined account record.

It should be noted that: the corresponding relation between the service bill and the account number is recorded in the next day table, so that the account number of the user can be determined through the service bill in the data packet after the data packet of the user is extracted by the monitoring module, and then the account number of the user and the service accessed by the account number are bound to monitor the behavior of the user.

The embodiment provides an account association method, which elaborates the specific implementation of the embodiment, and it can be seen that, according to the technical scheme of the embodiment, after data to be detected is acquired, by extracting data packets of a user and an accessed SSO system and using a skip value as intermediary information, the user and the accessed service can be effectively bound, so that the user behavior can be more effectively analyzed, and the security of the whole system is improved; in addition, by early warning of possible dangerous behaviors of the user, system breakdown caused by user operation can be effectively avoided, and therefore the stability of the whole system is guaranteed.

In yet another embodiment provided by the present application, referring to fig. 7, an application scenario diagram of an account association method provided by the embodiment of the present application is shown, as shown in fig. 7, the application scenario may include a server 501 that mounts a single sign-on system and a plurality of user terminals 502, where the plurality of user terminals 502 includes a first terminal 5021 corresponding to a user 1, a first terminal 5022 corresponding to a user 2, and a first terminal 5023 corresponding to a user 5023. When a user interacts with the single sign-on system, data sent by the user to the single sign-on system is extracted as data to be detected, and then the following operations are carried out:

when the data to be detected contains a single sign-on request of a POST request type, acquiring a login bill, a jump value and an account number from the data to be extracted, and storing the jump value and the account number in a second association table; storing the acquired account and the login ticket in a third association table;

when the data to be detected contains a single sign-on request of a GET request type, acquiring a sign-on bill and a skip value from the data to be extracted, and searching an account corresponding to the sign-on bill based on a third correlation table; storing the jump value and the account number in a second association table;

when the data to be detected comprises a service request, acquiring a jump value and a service bill from the data to be detected, searching an account corresponding to the jump value based on a second association table, and storing the service bill and the account in a first association table

Therefore, the first association table recorded with the service bill and the account is finally obtained, when the user accesses the single sign-on system, the subsequent monitoring module can determine the account of the user and the accessed service from the data sent by the user according to the first association table, so that the user behavior can be more effectively analyzed, and the safety of the whole system is improved; in addition, by early warning of possible dangerous behaviors of the user, system breakdown caused by user operation can be effectively avoided, and therefore the stability of the whole system is guaranteed.

In yet another embodiment provided by the present application, referring to fig. 8, a schematic diagram of a composition structure of an account associating apparatus 60 provided by the embodiment of the present application is shown, as shown in fig. 8, the account associating apparatus 60 includes an obtaining unit 601, a first detecting unit 602, and an associating unit 603; wherein the content of the first and second substances,

an acquisition unit 601 configured to acquire data to be detected;

a first detecting unit 602, configured to obtain a first jump value and a service ticket from the data to be detected when the data to be detected includes a service request; the first jump value is a parameter associated with a user request service, and the service bill is a certificate issued to a legal user by a service module in the single sign-on system;

an association unit 603 configured to determine an account associated with the first skip value based on a cache table, establish a first association relationship between the determined account and the service ticket, and update a first association table according to the first association relationship; the cache table is used for indicating an association relationship between a jump value and an account, and the first association table is used for indicating an association relationship between a service bill and an account.

In the above scheme, referring to fig. 9, a schematic structural diagram of another account number associating apparatus 60 provided in the embodiment of the present application is shown, as shown in fig. 9, the account number associating apparatus 60 may further include a second detecting unit 604 and a caching unit 605; wherein the content of the first and second substances,

a second detecting unit 604, configured to obtain a second jump value and a second login ticket from the data to be detected when the data to be detected includes a single sign-on request; the second login bill is a certificate issued to a legal user by a login module in the single sign-on system;

the caching unit 605 is configured to determine an account associated with the second login ticket, establish a second association relationship between the determined account and the second login ticket, and update the cache table according to the second association relationship.

In the above solution, the obtaining unit 601 is further configured to obtain data to be extracted including a single sign-on request; the data to be extracted is different from the data to be detected; acquiring a first jump value and a first login bill from the data to be extracted; the first login bill and the service bill are certificates owned by the same user; and determining an account number associated with the first login bill, and storing the first jump value and the determined account number association in a cache table.

In the foregoing solution, the obtaining unit 601 is further configured to determine, when the single sign-on request is a GET request, an account associated with the first login ticket based on a second association table; the second association table is used for indicating the association relationship between the pre-stored login ticket and the account.

In the foregoing solution, the obtaining unit 601 is further configured to obtain, when the single sign-on request is a POST request, an account associated with the first login ticket from the data to be extracted.

In the foregoing solution, the obtaining unit 601 is further configured to establish a fourth association relationship between the obtained account and the first login ticket; and updating the second association table according to the fourth association relation.

In the above solution, the first detecting unit 602 is further configured to determine whether the data to be detected includes a service address; when the data to be detected has a service address, determining the storage positions of a service bill and a first jump value in the data to be detected according to a first preset rule, and acquiring the first jump value and the service bill from the data to be detected; the first preset rule is used for indicating a configuration relation among a pre-stored service address, a pre-stored service bill and a pre-stored skip value; when the data to be detected has no service address, determining the storage positions of a service bill and a first jump value in the data to be detected according to a second preset rule, and acquiring the first jump value and the service bill from the data to be detected; the first preset rule is different from the second preset rule, and the second preset rule is used for indicating a configuration relationship between a pre-stored service bill and a jump value.

In the above scheme, the first detecting unit 602 is further configured to obtain a service ticket from the data to be detected, and determine whether the first association table contains the service ticket; and when the first association table does not contain the service ticket, acquiring a first jump value from the data to be detected.

In the above scheme, the associating unit 603 is further configured to determine, based on the first association table, a service ticket corresponding to the account; and monitoring behavior information corresponding to the account according to the determined service bill.

It can be understood that, in the embodiment of the present application, the account associating apparatus 60 may be independently arranged on a third-party server, and capture the interaction information between the user and the SSO system for monitoring; the flow capturing module can also be arranged at a flow inlet and outlet of an SSO system or an SSO server end in a module form, and captures flow for processing.

It is understood that in this embodiment, a "unit" may be a part of a circuit, a part of a processor, a part of a program or software, etc., and may also be a module, or may also be non-modular. Moreover, each component in the embodiment may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware or a form of a software functional module.

Based on the understanding that the technical solution of the present embodiment essentially or a part contributing to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, and include several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to execute all or part of the steps of the method of the present embodiment. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

Accordingly, the present embodiments provide a computer storage medium having stored thereon an account associated program that, when executed by at least one processor, performs the steps of the method of any of the preceding embodiments.

Based on the above-mentioned components of the account number associating apparatus 60 and the computer storage medium, referring to fig. 10, a specific hardware structure example of the account number associating apparatus 60 provided in the embodiment of the present application is shown, which may include: a communication interface 701, a memory 702, and a processor 703; the various components are coupled together by a bus system 704. It is understood that the bus system 704 is used to enable communications among the components. The bus system 704 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled in fig. 10 as bus system 704. The communication interface 701 is used for receiving and sending signals in the process of receiving and sending information with other external network elements;

a memory 702 for storing a computer program capable of running on the processor 703;

a processor 703 for executing, when running the computer program, the following:

acquiring data to be detected;

It will be appreciated that the memory 702 in the subject embodiment can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of example, but not limitation, many forms of RAM are available, such as Static random access memory (Static RAM, SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic random access memory (Synchronous DRAM, SDRAM), Double Data rate Synchronous Dynamic random access memory (ddr SDRAM), Enhanced Synchronous SDRAM (ESDRAM), Synchronous chained SDRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 702 of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The processor 703 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the method may be implemented by hardware integrated logic circuits in the processor 703 or by instructions in the form of software. The Processor 703 may be a general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, or discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in the memory 702, and the processor 703 reads the information in the memory 702 and performs the steps of the above method in combination with the hardware thereof.

It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the processing units may be implemented within one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), general purpose processors, controllers, micro-controllers, microprocessors, other electronic units configured to perform the functions described herein, or a combination thereof.

For a software implementation, the techniques described herein may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory and executed by a processor. The memory may be implemented within the processor or external to the processor.

Optionally, as another embodiment, the processor 703 is further configured to, when running the computer program, perform the steps of the method of any of the preceding embodiments.

Referring to fig. 11, a schematic diagram of a component structure of an apparatus provided in an embodiment of the present application is shown. As shown in fig. 11, the device 80 may at least include the account associating means 60 according to any one of the previous embodiments. The device 80 may be integrated in the SSO system, may also be a monitoring device independent of the SSO system, and may also be a server independent of the SSO system, which is not specifically limited in this embodiment of the application. In this way, the device 80 can extract the data packets of the user and the accessed system through the account association apparatus 60, and can effectively bind the user and the accessed service thereof by using the skip value as the intermediary information, so as to more effectively analyze the user behavior, thereby early warning the possibly existing dangerous behavior of the user in advance, avoiding the system crash or information leakage possibly caused by the user operation, and improving the stability and safety of the whole system.

The above description is only a preferred embodiment of the present application, and is not intended to limit the scope of the present application.

It should be noted that, in the present application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.

Features disclosed in several of the product embodiments provided in the present application may be combined in any combination to yield new product embodiments without conflict.

The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An account association method is characterized by comprising the following steps:

acquiring data to be detected;

2. The account number association method according to claim 1, wherein after the data to be detected is acquired, the method further comprises:

when the data to be detected comprises a single sign-on request, acquiring a second jump value and a second sign-on bill from the data to be detected; the second login bill is a certificate issued to a legal user by a login module in the single sign-on system;

determining an account number associated with the second login bill, establishing a second association relation between the determined account number and the second login bill, and updating the cache table according to the second association relation.

3. The account association method according to claim 1, wherein before the determining the account associated with the first jump value based on the cache table, the method further comprises:

acquiring data to be extracted including a single sign-on request; the data to be extracted is different from the data to be detected;

acquiring a first jump value and a first login bill from the data to be extracted; the first login bill and the service bill are certificates owned by the same user;

determining an account number associated with the first login bill, establishing a third association relationship between the determined account number and the first jump value, and storing the third association relationship in the cache table.

4. The account association method according to claim 3, wherein the determining the account associated with the first login ticket comprises:

when the single sign-on request is a GET request, determining an account number associated with the first login bill based on a second association table; the second association table is used for indicating the association relationship between the pre-stored login ticket and the account.

5. The account association method according to claim 3, wherein the determining the account associated with the first login ticket comprises:

and when the single sign-on request is a POST request, acquiring an account number associated with the first login bill from the data to be extracted.

6. The account number association method according to claim 5, wherein after the obtaining of the account number associated with the first login ticket from the data to be extracted, the method further comprises:

7. The account association method according to claim 1, wherein when the data to be detected includes a service request, the method further includes:

judging whether the data to be detected contains a service address;

8. The account number association method according to claim 1, wherein the acquiring a first jump value and a service ticket from the data to be detected includes:

acquiring a service bill from the data to be detected;

judging whether the first association table contains the service bill or not;

9. The account association method according to any one of claims 1 to 8, wherein after the updating the first association table according to the first association relationship, the method further includes:

10. An account association device is characterized by comprising an acquisition unit, a first detection unit and an association unit; wherein the content of the first and second substances,

the acquisition unit is configured to acquire data to be detected;

11. The account association apparatus according to claim 10, further comprising a second detection unit and a cache unit; wherein the content of the first and second substances,

the second detection unit is configured to acquire a second jump value and a second login bill from the data to be detected when the data to be detected comprises a single sign-on request; the second login bill is a certificate issued to a legal user by a login module in the single sign-on system;

the cache unit is configured to determine an account number associated with the second login ticket, establish a second association relationship between the determined account number and the second login ticket, and update the cache table according to the second association relationship.

12. An account number association apparatus, comprising a memory and a processor; wherein the content of the first and second substances,

the memory for storing a computer program operable on the processor;

the processor, when running the computer program, is configured to perform the method of any of claims 1 to 9.

13. A computer storage medium storing an account association program which, when executed by at least one processor, implements the method of any one of claims 1 to 9.