CN111291353A

CN111291353A - 一种账号关联方法、装置以及计算机存储介质

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

本申请实施例提供了一种账号关联方法、装置以及计算机存储介质，该方法包括：获取待检测数据；当待检测数据包括有业务请求时，从待检测数据中获取第一跳转值和业务票据；其中，第一跳转值是与用户请求业务关联的参数，业务票据为单点登录***内业务模块颁发给合法用户的凭证；基于缓存表确定与第一跳转值关联的账号，建立所确定的账号与业务票据之间的第一关联关系，并根据第一关联关系更新第一关联表；其中，缓存表用于指示跳转值与账号之间的关联关系，第一关联表用于指示业务票据与账号之间的关联关系；这样，通过提取用户访问***的数据包，能够提前预警用户可能存在的危险行为，从而提高了***的安全性。

Description

一种账号关联方法、装置以及计算机存储介质

技术领域

本申请涉及通信安全技术领域，尤其涉及一种账号关联方法、装置以及计算机存储介质。

背景技术

在企业发展初期，企业使用的***通常一个或者两个，每个***都有自己的账号提取单元，运营人员每天用自己的账号登录，操作很方便。但随着企业的发展，用到的***随之增多，运营人员在操作不同的***时，需要多次登录，而且每个***的账号都不一样，这对于运营人员来说很不方便。为了解决这一问题，产生了单点登录***，即通过一次登录能够访问其他相互信任的应用***。参见图1，其示出了一种相关技术方案中提供的一种CAS单点登录过程的时序示意图，当用户登录进入业务1后，业务2也会随之登录。然而，在访问业务的报文中，由于单点登录***的账号功能并不完善，使得监督部门无法有效分析用户的行为，并不能及时对用户的行为进行风险监控，导致用户可能会存在类似删库等危险行为。

发明内容

有鉴于此，本申请的主要目的在于提供一种账号关联方法、装置以及计算机存储介质，可以提前预警用户可能存在的危险行为，从而能够提高整体***的安全性。

为达到上述目的，本申请的技术方案是这样实现的：

第一方面，本申请实施例提供了一种账号关联方法，该方法包括：

获取待检测数据；

当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为单点登录***内业务模块颁发给合法用户的凭证；

基于缓存表确定与所述第一跳转值关联的账号，建立所确定的账号与所述业务票据之间的第一关联关系，并根据所述第一关联关系更新第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系，所述第一关联表用于指示业务票据与账号之间的关联关系。

第二方面，本申请实施例提供了一种账号关联装置，该账号关联装置包括获取单元、第一检测单元和关联单元；其中，

获取单元，配置为获取待检测数据；

第一检测单元，配置为当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为单点登录***内业务模块颁发给合法用户的凭证；

关联单元，配置为基于缓存表确定与所述第一跳转值关联的账号，建立所确定的账号与所述业务票据之间的第一关联关系，并根据所述第一关联关系更新第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系，所述第一关联表用于指示业务票据与账号之间的关联关系。

第三方面，本申请实施例提供了一种账号关联装置，该账号关联装置包括存储器和处理器；其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如第一方面所述的方法。

第四方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质存储有账号关联程序，所述账号关联程序被至少一个处理器执行时实现第一方面所述的方法。

本申请实施例提供了一种账号关联方法、装置以及计算机存储介质，该方法包括获取待检测数据；当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为业务模块颁发给合法用户的凭证；基于缓存表确定与所述第一跳转值关联的账号，将所确定的账号与所述业务票据关联存储在第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系；这样，通过提取用户和所访问***的数据包，利用跳转值作为中介信息，可以有效的将用户和其访问的业务绑定，能够更加有效分析用户行为，提前预警用户可能存在的危险行为，提高了整体***的安全性；另外，通过提前预警用户可能存在的危险行为，能够有效避免用户操作可能导致的***崩溃，从而还保证了整体***的稳定性。

附图说明

图1为相关技术方案中提供的一种CAS单点登录过程的时序示例；

图2为相关技术方案中提供的一种单点登录***的结构示意图；

图3为本申请实施例提供的一种账号关联方法的流程示意图；

图4为本申请实施例提供的另一种账号关联方法的流程示意图；

图5为本申请实施例提供的又一种账号关联方法的流程示意图；

图6为本申请实施例提供的再一种账号关联方法的流程示意图；

图7为本申请实施例提供的一种账号关联方法的应用场景图；

图8为本申请实施例提供的一种账号关联装置的组成结构示意图；

图9为本申请实施例提供的另一种账号关联装置的组成结构示意图；

图10为本申请实施例提供的一种账号关联装置的硬件结构示意图；

图11为本申请实施例提供的一种设备的组成结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

单点登录(Single Sign On，SSO)是指用户的一次性鉴别登录，当用户在身份认证服务器上登录一次以后，即可获得访问单点登录***中其他关联***和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用***中，用户只需一次登录就可以访问所有相互信任的应用***，参见图2，其示出了相关技术方案中单点登录***的结构示意图，如图2所示，图中的SSO***可以分为四个部分，分别是业务1、业务2、业务3和登录模块。业务1、业务2、业务3没有登录模块，而该登录模块不具有提供服务的业务，通常可以将登录模块称之为SSO***的登录模块，将业务1、业务2、业务3称之为SSO***的业务模块，当业务1、业务2、业务3需要登录时，将跳到登录模块，登录模块完成登录，其他的应用***也就随之登录了。然而，实际使用中，经过SSO登录的用户，在访问别的业务时所携带的是登录模块颁发的身份凭证，而不是自身的身份信息，导致监测人员不能及时将用户和其访问的业务绑定，无法预防用户的一些恶意行为。

实际使用中，经常使用中央认证服务(Central Authentication Service，CAS)进行SSO***的架构。如图1所示的CAS单点登录过程的时序示例，其主要组成部分有用户、浏览器、CAS服务器、业务1和业务2，主要交互步骤如下，具体包括：

用户通过浏览器访问业务1，业务1是需要登录的，但用户现在没有登录；

跳转到CAS服务器，即SSO登录模块，以后图中的CAS服务器我们统一叫做SSO登录模块；SSO登录模块也没有登录，弹出用户登录页，供用户键入密码；

用户填写账号、密码，SSO登录模块进行认证后，将登录状态写入SSO登录模块的session(session，计算机术语，一个session的概念需要包括特定的客户端，特定的服务器端以及不中断的操作时间)，浏览器中写入SSO域下的cookie(cookie，计算机术语，进行session跟踪而存储在用户本地终端上的数据，由用户客户端计算机暂时或永久保存的信息)；

SSO登录模块登录完成后会生成一个登录票据，然后跳转到业务1***，同时将登录票据作为参数传递给业务1***；

业务1***拿到登录票据后，从后台向SSO发送请求，验证登录票据是否有效；

验证通过后，业务1***将登录状态写入session并设置业务1域下的cookie。

至此，跨域单点登录就完成了，以后用户再访问业务1时，业务1就是登录的；如果用户访问业务2，流程如下：

用户访问业务2***，业务2没有登录，跳转到SSO登录模块；

由于SSO登录模块已经登录了，不需要重新登录认证；

SSO登录模块生成登录票据，浏览器跳转到业务2，并将登录票据作为参数传递给业务2；

业务2拿到登录票据，后台访问SSO登录模块，验证登录票据是否有效；

验证成功后，业务2将登录状态写入session，并在业务2域下写入cookie。

这样，业务2***不需要走登录流程，就已经是登录了，这样，SSO登录模块、业务1和业务2在不同的域，它们之间的session不共享也是没问题的。

然而，实际使用中，经过SSO登录的用户，在访问别的***时所携带的登录票据，而不是直接的用户信息，导致不能及时将用户和其访问的业务绑定，无法预防用户的一些恶意行为。

为了解决上述的技术问题，本申请实施例提供了一种账号关联方法，通过获取待检测数据；当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为业务模块颁发给合法用户的凭证；基于缓存表确定与所述第一跳转值关联的账号，将所确定的账号与所述业务票据关联存储在第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系；这样，通过提取用户和所访问SSO***的数据包，利用跳转值作为中介信息，可以有效的将用户和其访问的业务绑定，以便能够更加有效地分析用户行为，提高了整体***的安全性；另外，通过提前预警用户可能存在的危险行为，能够有效避免用户操作可能导致的***崩溃，从而还保证了整体***的稳定性。

本申请的一实施例中，参见图3，其示出了本申请实施例提供的一种账号关联的流程示意图，如图3所示，该方法可以包括：

S101：获取待检测数据；

需要说明的是，本申请实施例中描述的方法主要用于监控SSO***的用户进行的业务操作，其中的待检测数据是指用户向SSO***内的登录模块或业务模块发送的数据包中的数据，获取待检测数据的方式可以是拦截、复制、过滤、镜像传输等。

还需要说明的是，待检测数据本质是用户与SSO***之间交互的数据包中的数据，本申请更像是通过复制的方法将其提取进行检测，而这一过程并不会影响用户的数据继续传输到SSO***。

S102：当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为单点登录***内业务模块颁发给合法用户的凭证；

需要说明的是，用户与单点登录***的往来数据可以分为两大类，一类是登录请求，一类是业务请求，其中，对于含有登录请求的数据，其中的信息较多，比较容易确定该数据的账号，主要提供后续账号关联的依据；对于含有业务请求的数据，其中不会直接包含用户账号的信息，需要依赖之前进行登录请求时所收集的信息确定账号。

还需要说明的是，通过SSO***的架构规则可知，当用户与SSO***之间交互的数据含有业务请求时，说明用户已经开始正常访问业务模块，使用业务模块提供的各项服务，也就说明用户已经完成了从登录模块获取登录票据、携带登录票据访问业务模块、业务模块向登录模块验证登录票据的有效性以及业务模块根据登录票据颁发给用户业务票据的过程，所以待检测数据中必定含有业务票据和第一跳转值。

其中，所述业务票据是指业务模块中的业务为合法用户颁发的标识其身份的凭证，其中业务票据一种实现形式可以为session ID，即当业务1验证用户的登录票据后，会将登录状态写入session并设置业务1域下的cookie，当业务1携带session ID(也就是业务票据)进行后续的访问时，业务1可以获知用户在哪个session之中，并提供对应服务。

其中，跳转值是与用户请求的业务关联的参数，即用户向不同的业务模块发起请求时，携带不同的跳转值；比如，一个单点登录的业务模块可能包含业务1、业务2，当用户请求业务1从而触发登录操作后，所传输的数据中携带有跳转信息。值得注意的是，跳转信息属于“类”信息，其中又可以包含具体的跳转值、索引词、位置词之类的。其中，跳转值是主要用于标识此次跳转的信息，也就是说，对单独的用户来说，跳转值唯一且在同一个业务进程中保持不变，用于告知服务器此次跳转的目的地和其他相关信息。同时，当用户登录成功后在与业务1的后续业务往来数据中，也将包含跳转值，以便于保证业务端能够获知后续业务数据对应的业务路径，进而确定后续业务数据对应的业务进程。由于跳转值是与用户请求的业务关联的参数，同一个用户在一次会话中具有确定的跳转值；也就是说，跳转值如同是用户对于一次业务请求的标识，当服务器接收到用户的跳转值，可以确定用户对应的业务路径和进程。

还需要说明的是，本实施例所提供的方法是用于已经架构好的SSO***，将用户的账号与用户所访问的业务进行绑定，所以，对于SSO***和用户之间的交互规则(即用户和SSO***交互的数据包的形式和内容)是已知的。也就是说，可以根据预知的用户与SSO***之间的发包规则来在所述待检测数据的规定位置寻找第一跳转值和业务票据。

一些实施例中，所述S102还可以包括：

判断所述待检测数据是否包含有业务地址；

当所述待检测数据有业务地址时，根据第一预设规则确定业务票据和第一跳转值在所述待检测数据中的存储位置，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一预设规则用于指示预先存储的业务地址、业务票据与跳转值之间的配置关系；

当所述待检测数据没有业务地址时，根据第二预设规则确定业务票据和第一跳转值在所述待检测数据中的存储位置，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一预设规则与所述第二预设规则不同，所述第二预设规则用于指示预先存储的业务票据与跳转值之间的配置关系。

需要说明的是，对于包含业务请求的数据，用户与SSO***之间的发包规则又可以分为两大类，一类是含有业务地址的，一类是不含业务地址的；而这两种规则下数据包的形式是不同的，存储跳转值和业务票据的位置也不相同。为了提高查找效率，首先判断待检测数据中是否包含业务地址，如果包含，根据第一预设规则确定业务票据和第一跳转值在所述待检测数据中的存储位置，然后取出业务票据和第一跳转值；如果不包含，根据第二预设规则确定业务票据和第一跳转值在所述待检测数据中的存储位置；然后取出第一跳转值和业务票据。其中，第一预设规则和第二预设规则都是已知的用户与SSO***的发包规则。

S103：基于缓存表确定与所述第一跳转值关联的账号，建立所确定的账号与所述业务票据之间的第一关联关系，并根据所述第一关联关系更新第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系，所述第一关联表用于指示业务票据与账号之间的关联关系。

需要说明的是，当获取的待检测数据中含有业务请求时，说明用户已经登入业务模块进行交互，说明用户已经完成了登录过程，也就是说用户已经发送过携带有登录请求的数据，所以在缓存表中必定可以找到与所述第一跳转值关联的账号，从而确定与所述第一跳转值关联的账号，建立所确定的账号与所述业务票据的第一关联关系，将所述第一关联关系存储在第一关联表，完成关联。

上述实施例中，S102还可以这样设置：

从所述待检测数据中获取业务票据，判断所述第一关联表中是否含有所述业务票据；

当所述第一关联表中不含有所述业务票据时，从所述待检测数据中获取第一跳转值。

需要说明的是，当获取待检测数据后，由于用户可能与SSO***的同一业务进行多次交互，如果已经将该用户的账号与业务进行绑定，则不需要每次再次重复绑定过程，这样将会消耗过多的处理量。所以，在获取业务票据之后，在第一关联表中查找是否已经存储过业务票据，如果在第一关联表中查找到所述业务票据，说明已经将该用户的账号与业务进行绑定，则无需提取第一跳转值进行S103；当在第一关联表中查找不到所述业务票据，则需要提取第一跳转值进行S103。这样，可以通过用户的登录请求，获知用户的跳转值和对应的账号，为后续的账号关联提供依据。

上述实施例中，在S103后，该方法还可以包括：

基于所述第一关联表，确定所述账号对应的业务票据；

根据所确定的业务票据，监测所述账号对应的行为信息。

需要说明的是：第一关联表中所存储的业务票据和账号的信息即是后台监控用户行为的依据，根据第一关联表中的业务票据和账号，可以从用户与具体业务的数据确定账号，同时根据其中的业务票据将用户和所访问的业务绑定，实现对用户行为的监测。

本实施例提供了一种账号关联方法，通过获取待检测数据；当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为单点登录***内业务模块颁发给合法用户的凭证；基于缓存表确定与所述第一跳转值关联的账号，建立所确定的账号与所述业务票据之间的第一关联关系，并根据所述第一关联关系更新第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系，所述第一关联表用于指示业务票据与账号之间的关联关系；这样，通过提取用户和所访问SSO***的数据，利用跳转值作为中介信息，可以有效的将用户和其访问的业务绑定，以便能够更加有效地分析用户行为，提高了整体***的安全性；另外，通过提前预警用户可能存在的危险行为，能够有效避免用户操作可能导致的***崩溃，从而还保证了整体***的稳定性。

本申请的另一实施例中，参见图4，其示出了本申请实施例提供的另一种账号关联的流程示意图，如图4所示，该方法可以包括：

S201：获取待检测数据；

需要说明的是，本申请实施例中描述的方法主要用于监控SSO***合法的终端用户进行的后续业务操作，其中的数据是指终端用户向SSO登录***或者业务模块发送的数据包中的数据，获得数据的方式可以是拦截、过滤、镜像传输等。

S202：当所述待检测数据包括有单点登录请求时，从所述待检测数据中获取第二跳转值和第二登录票据；其中，所述第二登录票据为单点登录***内登录模块颁发给合法用户的凭证；

需要说明的是：单点登录请求，一般以统一资源定位符(uniform resourcelocator，url)的形式呈现，代表用户所请求的资源位置。

需要说明的是，在SSO***中用户登录可以细分为两个步骤，第一个步骤，用户向登录模块提交用户密码，验证通过后登录模块向用户返回登录票据，同时用户将登录票据作为登录成功的凭证和自己的账号、请求的业务发送到业务模块以获得服务。举例说明，当用户向业务1申请登录，由于业务1没有独立的登录模块，将跳转登录模块进行认证，用户填写账户密码后，等待登录模块认证成功并返回登录票据，用户端将登录票据、账号以及规则信息(url等)传送至业务1完成业务1的登录。当然，这个过程其实是非常快的，对使用者来说，只是输入了账号和密码，其余的将由***自动跳转进行。在这个过程中，所述待检测数据是指用户获得登录票据后向业务1发送的数据，因为第一个数据中仅含有账号密码，并不会提供与后续业务请求中业务票据关联的信息。

需要说明的是，第二跳转值与第一跳转值本质的意义相同，都是与用户请求的业务关联的参数，同一个用户在一次会话中具有确定的跳转值；也就是说，跳转值像是用户对于一次业务请求的标识，当服务器接收到用户的跳转值，可以确定用户对应的业务路径和进程。

需要说明的是，登录票据为SSO***中登录模块颁发给合法用户的凭证，也就是说单点登录***会为每一个合法用户提供一个独立的登录票据，即登录模块通过识别登录票据确认用户的合法身份，从而提供后续的操作。当用户在获得登录票据后，在后续对其他不同业务模块的登录时，均利用这个登录票据进行相关验证。

S203：确定与所述第二登录票据关联的账号，建立所确定的账号与所述第二登录票据之间的第二关联关系，并根据所述第二关联关系更新所述缓存表。

需要说明的是，由于登录票据是SSO***中的登录模块颁发的，根据已架构的SSO***的架构和规则，可以确定与所述第二登录票据关联的账号，比如可能是通过记录对应关系的文件根据登录票据确定的账号，也有可能是数据中的特定位置含有账号，也可能是数据中含有特定的标识，通过标识的映射关系进一步确定账号，这些都需要根据索要监控的SSO***进行确定。这样，对于用户的业务请求，可以通过其中的跳转值在缓存表中获得其对应的账号，从而建立第二关联关系。

本实施例提供了一种账号关联方法，对前述实施例的具体实现进行了详细阐述，从中可以看出，通过前述实施例的技术方案，在获取待检测数据之后，通过提取用户和所访问SSO***的数据，利用跳转值作为中介信息，可以有效的将用户和其访问的业务绑定，以便能够更加有效地分析用户行为，提高了整体***的安全性；另外，通过提前预警用户可能存在的危险行为，能够有效避免用户操作可能导致的***崩溃，从而还保证了整体***的稳定性。

本申请的又一实施例中，参见图5，其示出了本申请实施例提供的又一种账号关联方法的流程示意图，如图5所示，该方法可以包括：

S301：获取包括有单点登录请求的待提取数据；其中，所述待提取数据与所述待检测数据不同；

需要说明的是，在获取到包含有业务请求的待检测数据之前，必定已经获取到该用户包含有单点登录请求的待提取数据，也就是说，当待提取数据在时间上是先于包含有业务请求的待检测数据的，且与待检测数据一样，由同一用户进行发送。也就是说，在时间上，先收到用户的包含有单点登录请求的待提取数据，然后收到该用户的包含有业务请求的待检测数据。同时，对于本方法而言，当某个时间点获得一个数据，有可能是其他用户的“待提取数据”，也有可能之前接收到“待提取数据”对应的“待检测数据”。所以，前两个是实施例主要是对于同种时间点接收到的同个数据的不同处理的说明，本实施例主要是通过对不同时间点接受到的同一用户的不同数据进行说明。

S302：从所述待提取数据中获取第一跳转值和第一登录票据；其中，所述第一登录票据与所述业务票据为同一用户所拥有的凭证；

需要说明的是，由于待提取数据为用户进行单点登录时发送的数据包中包含的数据，所以其中必定包含第一跳转值和第一登录票据，同时，获取第一跳转值和第一登录票据的具体过程也是根据用户与SSO***的发包规则，先确定待提取数据中第一跳转值和第一登录票据的存储位置，然后从相应位置取出第一跳转值和第一登录票据。

S303：确定与所述第一登录票据关联的账号，建立所确定的账号与所述第一跳转值之间的第三关联关系，并将所述第三关联关系存储在所述缓存表。

需要说明的是：以第一登录票据为依据确定账号，建立所确定的账号与所述第一跳转值之间的第三关联关系，并将所述第三关联关系存储在所述缓存表，以备后续查询。其中，根据第一登录票据确定的账号的过程如下：

当所述单点登录请求为GET请求(表示向服务器索取数据的请求)时，基于第二关联表确定与所述第一登录票据关联的账号；其中，所述第二关联表用于指示预先存储的登录票据与账号之间的关联关系。

当所述单点登录请求为POST请求(表示向服务器传送数据的请求)时，从所述待提取数据中获取与所述第一登录票据关联的账号。

需要说明的是，对于用户的登录请求，又可分为POST请求和GET请求，其中，POST请求是指用户在提交用户密码，GET请求是指用户已经处于登录状态，又向另一业务模块发起的请求，例如，用户已经在使用业务1时进行了登录模块的登录，然后进行业务2的使用申请。针对这两种请求，数据的具体内容是不同的，所以需要根据他们对应数据所含有的具体内容确定对应的账号。

需要说明的是，判断单点登录请求为POST请求还是GET请求是根据待监测SSO***的具体编程方式确定的，即对于已经架构好的SSO***，其必然规定了POST请求和GET请求对应的形式和标识，即已经架构好的SSO***，其POST请求的url和GET请求的url具有明确的区分。

需要说明的是，当单点登录请求是POST请求，用户应当是在提交用户密码，所述用户的数据中必然还包含账号，通过对于所述数据中内容的分析，可以确定所述数据的账号。易于理解的，这些往来的数据并不是杂乱无章的存放内容，而是按照目标SSO***的规定进行信息的交互，而本申请实施例的方法是对于已架构的SSO***的监控，所以能够获知SSO***中对于含有所述数据的数据包的形式和内容的规定，进而实现账号的查找和确定。

需要说明的是，当单点登录请求是GET请求，那么数据中一般只含有第一登录票据，需要根据预先存储的第二关联表确定第一登录票据关联的账号，而不是从数据中取出账号。

还需要说明的是，当收到GET请求的是用户已经处于登录状态，又向另一业务模块发起的请求，那么用户必然已经发送过含有POST请求的数据，在获取到用户之前发送的含有POST请求的数据时，需要确定登录票据与账号之间的关联关系，然后存储到第二关联表中，这样，当收到GET请求时，基于第二关联表和数据中所含有的登录票据，就可以确定账号。

所以，在上述实施例中，当所述单点登录请求为POST请求时，还包括：

建立所获取的账号与所述第一登录票据之间的第四关联关系；

根据所述第四关联关系更新所述第二关联表。

需要说明的是：当单点登录请求为POST请求，还需要将所确定的账号和第一登录票据关联存储在第二关联表中，作为GET请求时确定第一登录票据所关联的账号的依据。

还需要说明的是，从存储的内容来看，第一关联表用于存储业务票据和账号之间的关联关系，第二关联表用于存储登录票据和账号之间的关联关系，具有同样的形式，所以第二关联表和第一关联表也可以合并为一个表，统一存储。当然对于最终的关联结果，第一关联表才是最终呈现的关联结果，所以将第一关联表和第二关联表分开存储更加方便。

本实施例提供了一种账号关联方法，对前述实施例的具体实现进行了详细阐述，从中可以看出，通过前述实施例的技术方案，在获取待检测数据之前，获取待提取数据并确定跳转值和账号之间的关联关系，为待检测数据提供关联依据；这样，通过提取用户和所访问SSO***的数据，利用跳转值作为中介信息，可以有效的将用户和其访问的业务绑定，以便能够更加有效地分析用户行为，从而可以提前预警用户可能存在的危险行为，提高了整体***的安全性；另外，通过提前预警用户可能存在的危险行为，能够有效避免用户操作可能导致的***崩溃，从而还保证了整体***的稳定性。

本申请的再一实施例中，参见图6，其示出了本申请实施例提供的再一种账号关联方法的具体流程示意图，如图6所示，该方法可以包括：

S401：获取数据包；

需要说明的是，数据包可以是从用户终端和SSO***之间交互流量中拦截获取的，也可以是用户终端镜像传输的，可以是设置在SSO***之前的接收模块获取的。

S402：判断是否能够匹配上配置文件中的一条单点登录请求url，记录下命中的规则ID；如果否，跳转步骤S412；

需要说明的是，配置文件是根据SSO***与用户之间交互规则确定的文件，其中记载了SSO***与用户交互数据包的内容编排规则和标识；当能够命中单点登录请求url时，证明所述数据包是我们需要的，如果没有命中单点登录请求，则验证是否是业务请求。

S403：根据命中的规则ID，依据该规则中指定的位置查询是否含有指定的jump_key的跳转关键字；如果是执行S404，如果否，结束流程；

需要说明的是，如果命中的规则ID中没有jump_key的关键字，那么该数据包对我们来说并不是有效的信息，则丢弃数据包结束流程。

S404：以jump_key的关键字在数据包中查找对应值，即跳转值；

需要说明的是，根据命中的规则ID，查询这个规则中所含有的jump_key的关键字，jump_key可以理解为跳转信息，然后取出数据包中相对于跳转信息关键字的值作为跳转值；也即，配置文件中需要说找的是jump_key的value(相当于标识或者名称)，而我们从数据包中取出的是跳转信息的key。如下为配置文件中关于jump_key的样例语段，在这条规则中，jump_key的value是“ticket”，我们以“ticket”作为目标字符在数据包中查找，找到的值就是跳转值；

"jump_key":[{

"pos":"rsp_head:Location",

"keyword":["ticket"]

}]。

S405：根据命中的规则ID，依据规则条目中指定的位置查询是否含有单点登录服务器票据sso_srv_token的关键字；如果有执行S406，如果否，结束流程；

需要说明的是，如果命中的规则ID中没有单点登录服务器票据sso_srv_token的关键字，那么该数据包并不具有对我们有效的信息，则丢弃数据包结束流程。

S406：以sso_srv_token关键字在数据包中查找对应值，记为登录票据；

需要说明的是，同前述相似，在规则条目中查询sso_srv_token关键字，也就是sso_srv_token的value，然后根据sso_srv_token的value在数据包中找到sso_srv_tokeny的key，记录为登录票据。如下为配置文件中关于sso_srv_token的样例语段，在这条规则中，sso_srv_token的value是“ASP.NET_SessionId”，我们以“ASP.NET_SessionId”作为目标字符在数据包中查找，找到的值就是登录票据；

"sso_srv_token":[{

pos":"cookie",

"keyword":["ASP.NET_SessionId"]

}]。

S407：判断请求类型是POST还是GET，如果是POST请求则执行S408，如果是GET请求则执行S410；

S408：根据命中的规则ID，依据规则条目中指定的位置查询是否含有账号username_key的关键字；如果有执行S409，如果否，结束流程；

需要说明的是，当请求类型是POST类型时，代表用户可能是在提交账号和密码，那么我们需要获得的是，登录票据与账号的对应关系，以及跳转值与账号的对应关系。

需要说明的是，如果命中的规则ID中没有账号username的关键字，那么该数据包并不具有对我们有效的信息，则丢弃数据包结束流程。

S409：记录两条数据：(1)以登录票据(即sso_srv_token关键字查到的value)做key，以账号(即username关键字查到的value)做value，记录第一天表中；第一天表即前述的第一关联表；(2)以跳转值(即jump_key关键字查到的值)做key，以账号(即username关键字查到的value)做value，记录到临时表中。

需要说明的是，当登录请求是POST请求时，需要获得两种对应关系，一种是登录票据和账号的对应关系，这个对应关系是GET请求中确定账号的依据；一种是跳转值和账号的对应关系，这个是用于后续业务请求中确定账号的依据。

还需要说明的是：临时表即前述的缓存表，由于跳转值对于用户而言仅在一段时间内保持有效，所以临时表中的内容可定期清空。

S410：根据登录票据在第一天表中查询账号；如果查询到结果执行S411，如果查询不到则结束流程。

需要说明的是，第一天表中记录了登录票据和账号的关联关系，这里的第一天表即前述的第二关联表。这里，天表为实际使用中的自定名称，用于指示长期存在的、记录有最终信息的关联表；与临时表相对应，临时表是短期存在的、仅记录中间信息的关联表；其中，天表又分为第一天表和第二天表，第一天表记录有业务票据和账号，第二天表记录有登录票据和账号；而临时表记录有跳转值和账号，在进行账号关联时，第一天表需要根据临时表提供的跳转值和账号的信息确定业务票据和账号的关联关系，同时，在GET请求中，临时表需要根据第二天表提供的登录票据和账号的信息确定跳转值和账号的关联关系。另外，跳转值是具有一定时效性的，所以临时表可在生成的2-3天后删除和清空，而业务票据和登录票据是相对固定的，也是最终关联的结果，所以第一天表和第二天表是长期存在的。

需要说明的是，当请求类型是GET类型时，代表用户可能已经登录模块，当前的数据包是对于另一个业务的申请，所以需要基于第一天表确定用户携带的登录票据的账号，并且获得跳转值与账号的对应关系。

S411：记录一条数据：以跳转值(即jump_key关键字查到的值)做key，以账号(即username关键字查到的value)做value，记录到临时表中。

需要说明的是，当登录请求是GET请求时，获得一种对应关系，即跳转值和账号的对应关系，用于后续业务请求中确定账号的依据。

S412：判断是否能够匹配上配置文件中的任意一条业务地址，记录下命中的规则ID；如果是执行S413，如果否跳转步骤S421；

需要说明的是，当数据包中不含有登录请求时，有可能是业务请求，更具体的，业务请求又可以细分为有业务地址的业务请求和没有业务地址的业务请求；对于这两种业务请求，其实流程是相同的，都是检索其中的跳转值和业务票据，最终根据跳转值得到账号，并将账号和业务票据进行关联。但是，这两中业务请求的数据包的内容排布有些不同，所以具体的提取规则和流程有些不同。

S413：根据命中的规则ID，依据规则条目中指定的位置查询是否含有业务票据busi_token_key的关键字，如果含有执行S414，如果不含有结束流程；

需要说明的是，如果命中的规则ID中没有业务票据busi_token_key的关键字，那么该数据包并不具有对我们有效的信息，则丢弃数据包结束流程。

S414：以busi_token关键字在数据包中查找对应值，即业务票据；

需要说明的是，需要说明的是，同前述相似，在规则条目中查询busi_token关键字，也就是busi_token的value，然后根据busi_token的value在数据包中找到busi_token的key，记录为登录票据；如下为配置文件中关于busi_token的样例语段，在这条规则中，busi_token的value包含多个，分别是"ci_session","DYSangForDataAgencyUserCode","DYSangForDataGroupUserCode","ASP.NET_SessionId",".WEBCOOKIE","LoginUserTicket"，依次取出这些busi_token的value在数据包中进行匹配，匹配成功后取出匹配上busi_token对应的key，就是登录票据；

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

"keyword":["ci_session",

"DYSangForDataAgencyUserCode",

"DYSangForDataGroupUserCode",

"ASP.NET_SessionId",

".WEBCOOKIE",

"LoginUserTicket"]

}]。

S415：以业务票据在第二天表中进行查询，判断是否查询到相应的条目；如果是结束，如果否执行S416；

需要说明的是：第二天表中记录了登录票据和账号的关联关系，这里的第二天表即前述的第三关联表。需要说明的是，该步骤主要防止重复关联，对于当用户第一次与业务模块发起业务请求，已对用户进行了绑定，此时对于同一用户对后续的同一业务进程的数据包，无需再次进行检索和关联。

S416：根据命中的规则ID，依据规则条目中指定的第一个jump_key的关键字,查询数据包中是否含有该关键字；如果能则执行S418，如果不能，则执行S417；

需要说明的是，如果命中的规则ID中没有跳转信息，那么该数据包并不具有对我们有效的信息，则丢弃数据包结束流程。

S417：依据规则条目中指定的下一个jump_key的关键字,查询数据包中是否含有该关键字，直至查询到jump_key的关键字；

需要说明的是，在实际使用中，用户可能不是一次跳转到目标业务的，所以命中的规则条目中可能存在多个jump_key语段，所以需要对所有的jump_key的关键字进行查询。

S418：以jump_key的关键字在数据包中查找对应值，记为跳转值；

需要说明的是，该步骤用于取出业务请求中含有的跳转值，从而根据临时表确定对应的账号。

S419：以跳转值在临时表中进行查询，确定对应的账号；

需要说明的是，如果查询不到，则可能是错误数据，可直接丢弃结束流程。

S420：以业务票据和所确定的账号记录都第二天表中，确定关联关系；

这样，即可将用户和其访问的业务进行绑定，以监控用户的行为。

S421：判断是否能够匹配上配置文件中的任意一条规则，记录规则ID并取出规则中的业务票据busi_token的关键字；如果是执行S421，如果否则结束；

需要说明的是，进一步的，对于不含业务地址的业务请求进行匹配，如果不能匹配上规则，那么该数据包并不具有对我们有效的信息，则丢弃数据包结束流程。

S422：以busi_token关键字在数据包中查找对应值，即业务票据；

需要说明的是，该步骤用于取出业务票据，以确认数据包中对应的账号。

S423：以业务票据在第二天表中进行查询，看能否查询到相应的条目；如果能结束，如果不能执行S423；

需要说明的是，该步骤主要防止重复关联，对于当用户第一次与业务模块发起业务请求，已对用户进行了绑定，此时对于同一用户对后续的同一业务进程的数据包，无需再次进行检索和关联。

S424：根据命中的规则ID，依据规则条目中指定的第一个jump_key的关键字，查询数据包中是否含有该关键字；如果是则执行S426，如果否，则执行S425；

需要说明的是，该步骤主要为了确认数据包中是否含有跳转值。

S425：依据规则条目中指定的下一个jump_key的关键字,查询数据包中是否含有该关键字；如果是执行S427；如果否执行S426；

需要说明的是，对于用户而言，可能出现业务模块内的跳转，所以在请求中可能不止一个jump_key的关键字，需要轮询这些jump_key的关键字，直至在数据包中查询到对应的跳转值。

S426：如果轮询完jump_key关键字没匹配上，则轮询下一个业务票据关键字busi_token_key；

需要说明的是，在实际交互的数据包中，用户可能申请过多个业务票据，可能含有多个busi_token_key，需要对这些busi_token_key进行依次查询。

S427：以jump_key的关键字在数据包中查找对应值，即跳转值；

S428：以跳转值在临时表中进行查询，确定对应的账号；

S429：以业务票据(busi_token关键字查到的value)和所确定的账号记录都第二天表中，确定关联关系。

需要说明的是：第二天表中记录了业务票据和账号的对应关系，这样，监控模块在提取到用户的数据包后，通过数据包中的业务票据可以确定用户的账号，然后将用户的账号和其访问的业务进行绑定，以监控用户的行为。

本实施例提供了一种账号关联方法，对前述实施例的具体实现进行了详细阐述，从中可以看出，通过前述实施例的技术方案，在获取待检测数据之后，通过提取用户和所访问SSO***的数据包，利用跳转值作为中介信息，可以有效的将用户和其访问的业务绑定，以便能够更加有效地分析用户行为，提高了整体***的安全性；另外，通过提前预警用户可能存在的危险行为，能够有效避免用户操作可能导致的***崩溃，从而还保证了整体***的稳定性。

本申请提供的再一实施例中，参见图7，其示出了本申请实施例提供的一种账号关联方法的应用场景图，如图7所示，该应用场景可以包括搭载单点登录***的服务器501和多个用户终端502，多个用户终端502包括用户1对应的第一终端5021、用户2对应的第一终端5022和用户3对应的第一终端5023。当用户与单点登录***进行交互时，提取用户向单点登录***发送的数据作为待检测数据，然后进行如下操作：

当所述待检测数据含有POST请求类型的单点登录请求时，从所述待提取数据中获取登录票据、跳转值和账号，将跳转值和账号存储在第二关联表中；将所获取的账号与所述登录票据存储在第三关联表中；

当所述待检测数据含有GET请求类型的单点登录请求时，从所述待提取数据中获取登录票据和跳转值，基于第三关联表查找与所述登录票据对应的账号；将跳转值和账号存储在第二关联表中；

当所述待检测数据包括有业务请求时，从所述待检测数据中获取跳转值和业务票据，基于第二关联表查找与所述跳转值对应的账号，将所述业务票据和账号存储在第一关联表中

这样，最终得到记载有业务票据以及账号的第一关联表，在用户访问单点登录***时，后续监控模块可以根据第一关联表从用户发送的数据中确定用户的账号和所访问的业务，能够更加有效地分析用户行为，提高了整体***的安全性；另外，通过提前预警用户可能存在的危险行为，能够有效避免用户操作可能导致的***崩溃，从而还保证了整体***的稳定性。

本申请提供的再一实施例中，参见图8，其示出了本申请实施例提供的一种账号关联装置60的组成结构示意图，如图8所示，该账号关联装置60包括获取单元601、第一检测单元602和关联单元603；其中，

获取单元601，配置为获取待检测数据；

第一检测单元602，配置为当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为单点登录***内业务模块颁发给合法用户的凭证；

关联单元603，配置为基于缓存表确定与所述第一跳转值关联的账号，建立所确定的账号与所述业务票据之间的第一关联关系，并根据所述第一关联关系更新第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系，所述第一关联表用于指示业务票据与账号之间的关联关系。

在上述方案中，参见图9，其示出了本申请实施例提供的另一种账号关联装置60的组成结构示意图，如图9所示，该账号关联装置60还可以包括第二检测单元604和缓存单元605；其中，

第二检测单元604，配置为当所述待检测数据包括有单点登录请求时，从所述待检测数据中获取第二跳转值和第二登录票据；其中，所述第二登录票据为单点登录***内登录模块颁发给合法用户的凭证；

缓存单元605，配置为确定与所述第二登录票据关联的账号，建立所确定的账号与所述第二登录票据之间的第二关联关系，并根据所述第二关联关系更新所述缓存表。

在上述方案中，获取单元601，还配置为获取包括有单点登录请求的待提取数据；其中，所述待提取数据与所述待检测数据不同；以及从所述待提取数据中获取第一跳转值和第一登录票据；其中，所述第一登录票据与所述业务票据为同一用户所拥有的凭证；以及确定与所述第一登录票据关联的账号，将所述第一跳转值和所确定的账号关联存储在缓存表中。

在上述方案中，获取单元601，还配置为当所述单点登录请求为GET请求时，基于第二关联表确定与所述第一登录票据关联的账号；其中，所述第二关联表用于指示预先存储的登录票据与账号之间的关联关系。

在上述方案中，获取单元601，还配置为当所述单点登录请求为POST请求时，从所述待提取数据中获取与所述第一登录票据关联的账号。

在上述方案中，获取单元601，还配置为建立所获取的账号与所述第一登录票据之间的第四关联关系；以及根据所述第四关联关系更新所述第二关联表。

在上述方案中，所述第一检测单元602，还配置为判断待检测数据是否包含有业务地址；以及当所述待检测数据有业务地址时，根据第一预设规则确定业务票据和第一跳转值在所述待检测数据中的存储位置，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一预设规则用于指示预先存储的业务地址、业务票据与跳转值之间的配置关系；以及当所述待检测数据没有业务地址时，根据第二预设规则确定业务票据和第一跳转值在所述待检测数据中的存储位置，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一预设规则与所述第二预设规则不同，所述第二预设规则用于指示预先存储的业务票据与跳转值之间的配置关系。

在上述方案中，所述第一检测单元602，还配置为从所述待检测数据中获取业务票据，判断所述第一关联表中是否含有所述业务票据；以及当所述第一关联表中不含有所述业务票据时，从所述待检测数据中获取第一跳转值。

在上述方案中，所述关联单元603，还配置为基于所述第一关联表，确定所述账号对应的业务票据；根据所确定的业务票据，监测所述账号对应的行为信息。

可以理解地，在本申请实施例中，账号关联装置60可以独立的设置在第三方服务器上，抓取用户与SSO***的交互信息进行监控；也可以模块的形式设置在SSO***或者SSO服务器端的流量出入口处，抓取流量进行处理。

可以理解地，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有账号关联程序，所账号关联程序被至少一个处理器执行时实现前述实施例中任一项所述的方法的步骤。

基于上述账号关联装置60的组成以及计算机存储介质，参见图10，其示出了本申请实施例提供的账号关联装置60的具体硬件结构示例，可以包括：通信接口701、存储器702和处理器703；各个组件通过总线***704耦合在一起。可理解，总线***704用于实现这些组件之间的连接通信。总线***704除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图10中将各种总线都标为总线***704。其中，通信接口701，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器702，用于存储能够在处理器703上运行的计算机程序；

处理器703，用于在运行所述计算机程序时，执行：

获取待检测数据；

可以理解，本申请实施例中的存储器702可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步链动态随机存取存储器(Synchronous link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请描述的***和方法的存储器702旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器703可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器703中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器703可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(业务lication Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器702，处理器703读取存储器702中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本申请描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(业务lication Specific Integrated Circuits，ASIC)、数字信号处理器(Digital SignalProcessing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(ProgrammableLogic Device，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本申请所述功能的模块(例如过程、函数等)来实现本申请所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器703还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。

参见图11，其示出了本申请实施例提供的一种设备的组成结构示意图。如图11所示，设备80至少可以包括有前述实施例中任一项所述的账号关联装置60。其中，设备80可以是集成在SSO***中，也可以是独立于SSO***的监测设备，还可以是独立于SSO***的服务器，本申请实施例不作具体限定。这样，该设备80通过账号关联装置60能够提取用户和所访问***的数据包，利用跳转值作为中介信息，可以有效的将用户和其访问的业务绑定，以便能够更加有效地分析用户行为，从而可以提前预警用户可能存在的危险行为，避免用户操作可能导致的***崩溃或者信息泄露，提高了整体***的稳定性和安全性。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种账号关联方法，其特征在于，所述方法包括：

获取待检测数据；

2.根据权利要求1所述的账号关联方法，其特征在于，在所述获取待检测数据之后，所述方法还包括：

当所述待检测数据包括有单点登录请求时，从所述待检测数据中获取第二跳转值和第二登录票据；其中，所述第二登录票据为单点登录***内登录模块颁发给合法用户的凭证；

确定与所述第二登录票据关联的账号，建立所确定的账号与所述第二登录票据之间的第二关联关系，并根据所述第二关联关系更新所述缓存表。

3.根据权利要求1所述的账号关联方法，其特征在于，在所述基于缓存表确定与所述第一跳转值关联的账号之前，所述方法还包括：

获取包括有单点登录请求的待提取数据；其中，所述待提取数据与所述待检测数据不同；

从所述待提取数据中获取第一跳转值和第一登录票据；其中，所述第一登录票据与所述业务票据为同一用户所拥有的凭证；

确定与所述第一登录票据关联的账号，建立所确定的账号与所述第一跳转值之间的第三关联关系，并将所述第三关联关系存储在所述缓存表。

4.根据权利要求3所述的账号关联方法，其特征在于，所述确定与所述第一登录票据关联的账号，包括：

当所述单点登录请求为GET请求时，基于第二关联表确定与所述第一登录票据关联的账号；其中，所述第二关联表用于指示预先存储的登录票据与账号之间的关联关系。

5.根据权利要求3所述的账号关联方法，其特征在于，所述确定与所述第一登录票据关联的账号，包括：

当所述单点登录请求为POST请求时，从所述待提取数据中获取与所述第一登录票据关联的账号。

6.根据权利要求5所述的账号关联方法，其特征在于，在所述从所述待提取数据中获取与所述第一登录票据关联的账号之后，所述方法还包括：

根据所述第四关联关系更新所述第二关联表。

7.根据权利要求1所述的账号关联方法，其特征在于，当所述待检测数据包括有业务请求时，所述方法还包括：

判断所述待检测数据是否包含有业务地址；

8.根据权利要求1所述的账号关联方法，其特征在于，所述从所述待检测数据中获取第一跳转值和业务票据，包括：

从所述待检测数据中获取业务票据；

判断所述第一关联表中是否含有所述业务票据；

9.根据权利要求1-8任一项所述的账号关联方法，其特征在于，在所述根据所述第一关联关系更新第一关联表之后，所述方法还包括：

基于所述第一关联表，确定所述账号对应的业务票据；

根据所确定的业务票据，监测所述账号对应的行为信息。

10.一种账号关联装置，其特征在于，所述账号关联装置包括获取单元、第一检测单元和关联单元；其中，

所述获取单元，配置为获取待检测数据；

所述第一检测单元，配置为当所述待检测数据包括有业务请求时，从所述待检测数据中获取第一跳转值和业务票据；其中，所述第一跳转值是与用户请求业务关联的参数，所述业务票据为单点登录***内业务模块颁发给合法用户的凭证；

所述关联单元，配置为基于缓存表确定与所述第一跳转值关联的账号，建立所确定的账号与所述业务票据之间的第一关联关系，并根据所述第一关联关系更新第一关联表；其中，所述缓存表用于指示跳转值与账号之间的关联关系，所述第一关联表用于指示业务票据与账号之间的关联关系。

11.根据权利要求10所述的账号关联装置，其特征在于，所述账号关联装置还包括第二检测单元和缓存单元；其中，

所述第二检测单元，配置为当所述待检测数据包括有单点登录请求时，从所述待检测数据中获取第二跳转值和第二登录票据；其中，所述第二登录票据为单点登录***内登录模块颁发给合法用户的凭证；

所述缓存单元，配置为确定与所述第二登录票据关联的账号，建立所确定的账号与所述第二登录票据之间的第二关联关系，并根据所述第二关联关系更新所述缓存表。

12.一种账号关联装置，其特征在于，所述账号关联装置包括存储器和处理器；其中，

所述处理器，用于在运行所述计算机程序时，执行如权利要求1至9任一项所述的方法。

13.一种计算机存储介质，其特征在于，所述计算机存储介质存储有账号关联程序，所述账号关联程序被至少一个处理器执行时实现如权利要求1至9任一项所述的方法。