CN109587098B - 一种认证系统和方法、授权服务器 - Google Patents

Abstract

本申请提供了一种认证系统和方法、授权服务器，其中，该系统包括：产品服务器、密钥分发中心的认证服务器、授权服务器，其中：产品服务器，用于响应于用户的访问请求生成服务访问请求消息，并将服务访问请求消息发送至密钥分发中心的认证服务器；密钥分发中心的认证服务器，用于将服务访问请求消息转发至授权服务器；授权服务器，用于在确定服务器访问请求消息来源于产品服务器的情况下，将服务访问请求消息中携带的用户身份信息发送至密钥分发中心的认证服务器；密钥分发中心的认证服务器，根据用户身份信息生成身份认证后的服务访问标识，并将服务访问标识发送至产品服务器。

Description

一种认证系统和方法、授权服务器

技术领域

本申请属于互联网技术领域，尤其涉及一种认证系统和方法、授权服务器。

背景技术

目前，用于进行身份认证的方式，一般都需要在认证服务器(例如：密钥分发中心KDC)中为每个访问服务的用户创建并维护用户信息，需要提前将有访问服务需求的用户信息存储到认证服务器后端的backend中。进一步的，还需要对backend中已经录入的用户信息进行维护，例如，如果某些用户信息已经失效，则需要将这些用户的信息从backend中删除，以防止后续产生安全漏洞。

通过这种预先存储用户信息，以及需要对backend中的用户信息进行维护的方式，势必会增加运维和开发成本，开发效率比较低。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请目的在于提供一种认证系统和方法，授权服务器，以达到降低运维和开发成本的技术效果。

本申请提供了一种认证系统和方法，授权服务器。

一种认证系统包括：产品服务器、密钥分发中心的认证服务器、授权服务器，其中：

所述产品服务器，用于响应于用户的访问请求生成服务访问请求消息，并将所述服务访问请求消息发送至所述密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器，用于将所述服务访问请求消息转发至所述授权服务器；

所述授权服务器，用于确定所述服务访问请求消息是否来源于所述产品服务器，在确定所述服务器访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证，在认证通过后将所述服务访问请求消息中携带的用户身份信息发送至密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器，根据所述用户身份信息生成身份认证后的服务访问标识，并将所述服务访问标识发送至所述产品服务器。

一种授权服务器，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现如下步骤：

获取来自密钥分发中心的认证服务器的服务访问请求消息，其中，所述服务访问请求消息中携带有用户身份消息；

确定所述服务访问请求消息是否来源于所述授权服务器对应的产品服务器，在确定所述服务访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证；

在认证通过后，将所述用户身份信息发送至所述密钥分发中心的认证服务器。

一种认证方法，包括：

产品服务器响应于用户的访问请求生成服务访问请求消息，并将所述服务访问请求消息发送至密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器将所述服务访问请求消息转发至授权服务器；

所述授权服务器确定所述服务访问请求消息是否来源于所述产品服务器，在确定所述服务器访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证，在认证通过后将所述服务访问请求消息中携带的用户身份信息发送至密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器根据所述用户身份信息生成身份认证后的服务访问标识，并将所述服务访问标识发送至所述产品服务器。

一种授权认证方法，包括：

授权服务器获取来自密钥分发中心的访问请求消息，其中，所述访问请求消息中携带有用户身份信息；

确定所述访问请求消息来源于所述授权服务器对应的产品服务器；

将表示所述用户身份认证通过的消息发送至所述密钥分发中心的认证服务器。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现上述方法的步骤。

本申请提供的一种认证系统和方法、授权服务器，通过设置的授权服务器确定服务访问请求消息是否来源于产品服务器，如果确定服务器访问请求消息来源于产品服务器，则表明用户身份认证通过，即，通过对访问请求消息来源的确定取代对用户身份信息的认证，从而不再需要预设存储和维护用户的身份信息，降低了运维和开发成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是身份认证系统的结构框图；

图2是根据本申请实施例的AS返回信息示意图；

图3是根据本申请实施例的请求TGS的请求和响应信息示意图；

图4是根据本申请实施例的认证系统架构示意图；

图5是根据本申请实施例的认证系统架构的另一示意图；

图6是根据本申请实施例的基于云系统的认证系统架构的示意图；

图7是根据本申请实施例的基于云系统的认证方法流程图；

图8是根据本申请实施例的授权服务器的架构示意图；

图9是根据本申请实施例的授权服务器的结构框图；

图10是根据本申请实施例的认证方法流程图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

为了使得可以更为清楚的理解本申请，先对一种常用的用户认证方式Kerberos认证方式进行说明如下。用户通过Kerberos访问组件服务的流程说明如下：

如图1所示，提供了一种身份认证系统，可以包括：客户端(Client)、组件服务(Service Server，简称为SS)、密钥分发中心(Key Distribution Center，简称为KDC)，其中，Client与KDS和SS相连。认证过程可以包括如下两个阶段：

1)KDC的认证服务器(Authentication Server，简称为AS)对Client认证：

S1：Client携带身份信息(例如：用户名username)请求KDC的AS，以获取TGT。

S2：AS到后端(backend)的数据库中查找该用户名对应的密码(secret)；

S3：AS通过查找到的密码生成如图2所示的返回信息(response)。

S4：AS将该返回信息返回至Client；

S5：Client在获取到上的response信息后，对于该response信息中的第一部分的TGT(Ticket Granting Ticket，票据授权票据，用于获取SGT的Ticket)Client是无法进行解密的。第一部分的信息主要用于后续请求SGT(Service Granting Ticket，服务授权票据，用于访问SS的Ticket)的时候携带；Client可以通过密码对第二部分进行解密。如果密码正确，则解密成功，获取其中的TGS Session Key用于下次请求SGT的时候对相关信息进行加密，如果解密失败，则身份认证失败。

2)SS对Client认证，(即，在Client认证成功之后，还需要SS对Client完成认证才能正常访问服务)：

S1：Client携带TGT等信息向KDC的TGS(票据授权服务器)请求SGT(服务授权票据)；

S2：如图3所示，KDC中的TGS使用自己的密码解密TGT中的内容，并对解密得到的内容做校验(例如：判断username和Authenticator的username是否一致，以及进行时间戳校验等)；

S3：TGS向Client返回如图3所示的SGT等信息(response)。

S4：Client在获取到TGS返回的response，对于该response中的第一部分SGT用户无法解密，该部分用于请求SS的时候携带；对于该response中的第二部分信息，用户使用TGS Session Key进行解密并获取其中的Service Session Key，Client使用ServiceSession Key加密一些信息生成Authenticator；

S5：Client通过Authenticator请求SS；

S6：SS利用SGT和Authenticator完成对Client的认证。具体的，SS可以通过自己的密码解密SGT，获取其中的Service Session Key；然后，再使用Service Session Key解密Authenticator；最后，SS对SGT和Authenticator里的信息进行校验，从而完成SS对Client的校验。在校验成功之后用户可以正常访问集群服务。

为了实现KDC中的AS对用户身份的认证，需要为每个访问服务的用户创建并维护用户信息，需要提前将有访问服务需求的用户信息存储到backend中。进一步的，还需要对Kerberos的backend中已经录入的用户信息进行维护，例如，如果某些用户信息已经失效，则需要将这些用户的信息从backend中删除，以防止后续产生安全漏洞。通过这种预先存储用户信息，以及需要对backend中的用户信息进行维护的方式，势必会增加运维和开发成本，开发效率比较低。

上述是以在Kerberos这种身份认证方式中所存在需要预先存储和维护用户身份信息为基础进行的说明，这个问题也并不仅仅出现在Kerberos这种身份认证方式中，也会出现在其它类似的身份认证方式中。

为了解决上述问题，考虑到如果AS对用户身份认证的过程不需要预存用户信息，那么也就不需要对用户信息进行维护。为此，在本例中提供了一种认证方式，可以使得AS在对用户身份进行认证的时候，可以不需要预先存储用户信息。因为如果用户可以成功通过应用产品的接口接入，那么可以认为用户是合法用户，那么相应的，只需要对请求AS进行认证的请求是否是来自该应用产品的请求进行确认就可以。那么只需要过来的请求可以被确认为确实为该产品发过来的请求即可，这样用户就可以正常访问服务。

为此，在本例中提供了一种认证系统，如图4所示，可以包括：客户端(User，Client)、产品服务器(Product Server)、KDC(AS)、授权服务器。基于该系统，可以按照如下流程执行，下面对这几个组成部分进行具体说明：

1)产品服务器，可以用于响应于用户的访问请求生成服务访问请求消息，并将所述服务访问请求消息发送至所述密钥分发中心的认证服务器；

2)密钥分发中心的认证服务器，用于将所述服务访问请求消息转发至所述授权服务器；

3)所述授权服务器，用于确定所述服务访问请求消息是否来源于所述产品服务器，在确定所述服务器访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证，在认证通过后将所述服务访问请求消息中携带的用户身份信息发送至密钥分发中心的认证服务器；

4)密钥分发中心的认证服务器，根据所述用户身份信息生成身份认证后的服务访问标识，并将所述服务访问标识发送至所述产品服务器。

即，设置了一个授权服务器，通过该授权服务器确定服务访问请求消息是否来源于所述产品服务器，如果确定该请求是来源于产品服务器，则认为通过用户身份认证，即，通过确定请求的来源来实现对用户身份的认证，不需要预先存储用户身份信息和密码等，从而减少了维护和开发成本。

基于图4所示的认证系统，可以按照如下步骤进行身份认证：

S1：用户通过产品提供的服务访问入口访问底层服务；

S2：产品的产品服务器获取用户登陆信息以及用户要访问的具体资源服务信息；

S3：产品服务器可以将请求发送至KDC，KDC将请求转发至授权服务器；

S4：授权服务器确定该请求是否来自该产品的服务访问入口；

S5：如果确定是来自该产品的服务访问入口，则可以认为是对该产品服务器进行了身份认证，就可以确认用户身份认证成功；

S6：授权服务器将认证结果发送至KDC；

S7：KDC可以通过上述如图2所示的数据结构将username设置到TGT中返回给产品服务器；

S8：产品服务器可以通过TGT继续访问底层服务，即通过SS对用户进行身份认证。

为了使得授权服务器可以确定出请求是否来自该产品的服务访问入口，产品服务器可以通过对称加密算法对用户登陆信息进行加密，得到加密信息，然后将该加密信息放在请求中发送给KDC。相应的，授权服务器可以对请求中的信息通过对称解密的方式进行解密，如果解密成功，则表明本次请求是从产品服务器过来的，从而完成身份认证。

在本例中，进行对称加解密所使用的密钥不是针对每个用户分别设置的密钥，而是对产品本身设置的密钥，即，一个应用产品仅需要有一个密钥即可。将对用户身份的认证转换为了确定认证请求是否是来自应用的请求，如果确定该请求来自于应用，则认为该用户身份认证通过，因此，不再需要预先存储用户的身份信息和密码，从而可以减少维护和开发成本。

在一个实施方式中，上述认证系统可以如图5所示，还可以包括访问控制服务器(Access Management Service)。控制服务器可以用于在授权服务器确定请求是来自该产品的服务访问入口之后，通过访问控制服务器(Access Management Service)确定用户是否有权限访问对应的服务资源。即，通过访问控制服务器(Access Management Service)做权限的管理，可以通过控制服务器设置各个用户的权限。例如，可以设置哪些用户有权限资源访问控制系统，那么如果用户请求访问资源访问控制系统，那么可以通过访问控制服务器(Access Management Service)确定该用户是否有权限，如果没有权限，即使授权服务器确定请求是来自该产品的服务访问入口，也认为该请求用户身份认证失败。

需要说明的是，上述文字或附图中所说明的各个装置、服务器、系统等的位置关系仅是一种示意性描述，在实际实现的时候，可以采用多种方式中的一种或多种实现。例如，KDC中可以不设置AS，所有AS的操作都由KDC自身完成，或者是KDC与AS分开设置等等，都是可以被构想的。对于授权服务器而言，可以与产品服务器设置在一起，也可以不与产品服务器设置在一起。如果通过对称加解密方式进行认证，则只需要保证在授权服务器中可以存储有用于对称解密的密钥即可，对于设置的位置可以根据实际需要进行选择和设置，本申请对此不作具体限定。

上述认证系统可以应用在多种场景，多种身份认证协议中，下面以将Kerberos应用在云平台为例进行说明。在本例中提供了一种基于Kerberos服务的云产品认证方法，使得云产品可以通过Kerberos的身份认证，并且使用用户登陆身份访问底层基于Kerberos的服务。如图6所示，可以包括如下几个模块：Kerberos Client Module(用户信息模块)、ASAuth Module(AS认证模块)、Auth Server(授权服务器)、AccessManagementService(访问控制服务器)。下面对这几个模块的作用描述如下：

1)Kerberos Client Module，用于获取用户登陆云产品的登陆信息LoginInfo(例如：username等)和用户需要访问的服务资源信息ResourceInfo，其中，ResourceInfo可以用于在认证过程中进行资源访问权限的控制。云产品通过Kerberos认证后，KerberosClient Module可以使用代理用户的身份访问服务。

2)AS Auth Module为KDC的一个模块，用于将Client端携带的AuthInfo转发至Auth Server进行身份认证，并根据Auth Module的认证结果继续处理逻辑。如果身份认证成功，则Auth Server将解密的LoginInfo中username返回给KDC。

3)AccessManagementService，用于做权限的管理，例如，对云平台上的资源访问控制系统等做权限管理。

通过上述图6所示的基于Kerberos服务的云产品认证系统使得云产品可以通过Kerberos的身份认证，通过身份认证后，云平台可以代理用户以登陆用户的身份访问服务。具体的，可以按照如图7所示的时序图进行身份认证：

S1：用户user登陆云产品，通过云产品提供的服务访问入口，访问底层服务；

S2：云产品后端的ProductServer获取用户的登陆信息(例如：username等可以表征用户身份的信息，这些信息可以作为LoginInfo)，以及用户需要访问的具体服务资源信息(可以作为ResourceInfo)。

S3：ProductServer通过对称加密算法对上述LoginInfo/ResourceInfo进行加密，得到加密信息EncryptAuthInfo。然后，ProductServer可以携带EncryptAuthInfo请求KDCServer进行身份认证；

S4：KDC Server将获取到的EncryptAuthInfo转发到Auth Server。

S5：Auth Server使用和ProductServer相同的密钥对EncryptAuthInfo进行对称解密，如果解密成功，则表明该请求是从ProductServer过来，即完成了对云产品代理用户访问服务的ProductServer的身份认证；

S6：Auth Server通过对EncryptAuthInfo的解密，可以得到其中携带的LoginInfo/ResourceInfo。然后，可以继续请求访问控制服务AccessManagementService，以认证该实际访问者是否有权限访问对应的服务资源；

S7：Auth Server在认证成功后，可以将LoginInfo中的username等信息返回给KDC；

S8：KDC根据认证结果可以按照图2中数据结构将username设置到TGT中，并将TGT返回给ProductServer；

S8：ProductServer使用TGT继续按照图1的流程访问底层服务(例如：hadoop等)。

即，通过上述的过程可以完成KDC中AS的认证流程，后续再通过SS对Client进行认证，在SS对Client完成认证之后，就可以正常访问服务。

图8示出了根据本申请的一示例性实施例的授权服务器。请参考图8，在硬件层面，该授权服务器可以包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成业务实现装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图9，在软件实施方式中，该授权服务器应用于应用产品中，例如位于云产品中，可以包括获取模块901、确定模块902和发送模块903。其中：

获取模块901，用于获取来自密钥分发中心的认证服务器的服务访问请求消息，其中，所述服务访问请求消息中携带有用户身份消息；

确定模块902，用于确定所述服务访问请求消息是否来源于所述授权服务器对应的产品服务器，在确定所述服务访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证；

发送模块903，用于在认证通过后，将所述用户身份信息发送至所述密钥分发中心的认证服务器。

在一个实施方式中，确定模块902具体可以用于通过预设的密钥对所述服务访问请求消息进行解密；在解密成功的情况下，确定所述服务访问请求消息来源于所述产品服务器，则通过用户身份认证。

基于上述图4所示的认证系统，在本例中还提供了一种认证方法，如图10所示，可以包括如下步骤：

步骤1001：产品服务器响应于用户的访问请求生成服务访问请求消息，并将服务访问请求消息发送至密钥分发中心；

步骤1002：密钥分发中心将服务访问请求消息转发至授权服务器；

步骤1003：授权服务器确定服务访问请求消息是否来源于产品服务器，在确定服务器访问请求消息来源于产品服务器的情况下，则通过用户身份认证，在认证通过后将服务访问请求消息中携带的用户身份信息发送至密钥分发中心；

为了实现对用户访问权限的确定，在确定服务器访问请求消息来源于产品服务器之后，访问控制服务器可以从授权服务器获取服务访问请求消息中携带的用户请求访问的服务资源信息和用户身份信息，并根据用户请求访问的服务资源信息和用户身份信息，确定用户是否有权限访问请求访问的服务资源。

步骤1004：密钥分发中心根据用户身份信息生成身份认证后的服务访问标识，并将服务访问标识发送至产品服务器。

其中，上述的服务访问标识ZAI Kerberos认证方式中可以是TGT(TicketGranting Ticket，票据授权票据，用于获取SGT的Ticket)。

为了实现身份认证，可以采用对称加解密的方式，即，产品服务器通过预设密钥进行加密，授权服务器再通过该预设密钥进行对称解密，从而通过解密是否成功来确定是否认证通过。具体的，可以通过如下步骤实现：

S1：产品服务器接收用户的访问请求；

S2：产品服务器从访问请求中获取用户身份信息；

S3：产品服务器通过预设密码对用户身份信息进行加密，得到加密信息；

S4：将加密信息作为服务访问请求消息。

S5：；授权服务器通过预设的密钥对服务访问请求消息进行解密；

S6：在解密成功的情况下，确定服务访问请求消息来源于产品服务器，则通过用户身份认证。

本申请提供的一种认证系统和方法、授权服务器，通过设置的授权服务器确定服务访问请求消息是否来源于产品服务器，如果确定服务器访问请求消息来源于产品服务器，则表明用户身份认证通过，即，通过对访问请求消息来源的确定取代对用户身份信息的认证，从而不再需要预设存储和维护用户的身份信息，降低了运维和开发成本。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。当然，也可以将实现某功能的模块由多个子模块或子单元组合实现。

本申请中所述的方法、装置或模块可以以计算机可读程序代码方式实现控制器按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请所述装置中的部分模块可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的硬件的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，也可以通过数据迁移的实施过程中体现出来。该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请的全部或者部分可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、移动通信终端、多处理器系统、基于微处理器的系统、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (18)

1.一种认证系统，其特征在于，包括：产品服务器、密钥分发中心的认证服务器、授权服务器，其中：

所述产品服务器，用于响应于用户的访问请求生成服务访问请求消息，并将所述服务访问请求消息发送至所述密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器，用于将所述服务访问请求消息转发至所述授权服务器，其中，所述密钥分发中心的认证服务器中不存储和维护用户的身份信息；

所述授权服务器，用于确定所述服务访问请求消息是否来源于所述产品服务器，在确定所述服务访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证，在认证通过后将所述服务访问请求消息中携带的用户身份信息发送至密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器，根据所述用户身份信息生成身份认证后的服务访问标识，并将所述服务访问标识发送至所述产品服务器。

2.根据权利要求1所述的认证系统，其特征在于，还包括：访问控制服务器，与所述授权服务器进行通信，用于从所述授权服务器获取所述服务访问请求消息中携带的用户请求访问的服务资源信息和所述用户身份信息，并根据所述用户请求访问的服务资源信息和所述用户身份信息，确定用户是否有权限访问请求访问的服务资源。

3.根据权利要求1所述的认证系统，其特征在于，所述产品服务器包括：云产品后端的产品服务器。

4.根据权利要求3所述的认证系统，其特征在于，所述云产品提供服务访问入口。

5.根据权利要求1所述的认证系统，其特征在于，所述授权服务器与所述产品服务器都设置在同一产品中。

6.一种授权服务器，其特征在于，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现如下步骤：

获取来自密钥分发中心的认证服务器的服务访问请求消息，其中，所述服务访问请求消息中携带有用户身份信息，其中，所述密钥分发中心的认证服务器中不存储和维护用户的身份信息，其中，所述服务访问请求消息是产品服务器响应于用户的访问请求生成的；

确定所述服务访问请求消息是否来源于所述产品服务器，在确定所述服务访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证；

在认证通过后，将所述用户身份信息发送至所述密钥分发中心的认证服务器。

7.根据权利要求6所述的授权服务器，其特征在于，所述处理器具体用于通过预设的密钥对所述服务访问请求消息进行解密；在解密成功的情况下，确定所述服务访问请求消息来源于所述产品服务器，则通过用户身份认证。

8.一种认证方法，其特征在于，包括：

产品服务器响应于用户的访问请求生成服务访问请求消息，并将所述服务访问请求消息发送至密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器将所述服务访问请求消息转发至授权服务器，其中，所述密钥分发中心的认证服务器中不存储和维护用户的身份信息；

所述授权服务器确定所述服务访问请求消息是否来源于所述产品服务器，在确定所述服务访问请求消息来源于所述产品服务器的情况下，则通过用户身份认证，在认证通过后将所述服务访问请求消息中携带的用户身份信息发送至密钥分发中心的认证服务器；

所述密钥分发中心的认证服务器根据所述用户身份信息生成身份认证后的服务访问标识，并将所述服务访问标识发送至所述产品服务器。

9.根据权利要求8所述的认证方法，其特征在于，在确定所述服务访问请求消息来源于所述产品服务器之后，所述方法还包括：

访问控制服务器从所述授权服务器获取所述服务访问请求消息中携带的用户请求访问的服务资源信息和所述用户身份信息，并根据所述用户请求访问的服务资源信息和所述用户身份信息，确定用户是否有权限访问请求访问的服务资源。

10.根据权利要求8所述的认证方法，其特征在于，所述产品服务器包括：云产品后端的产品服务器。

11.根据权利要求10所述的认证方法，其特征在于，所述云产品提供服务访问入口。

12.根据权利要求8所述的认证方法，其特征在于，所述授权服务器与所述产品服务器都设置在同一产品中。

13.根据权利要求8所述的认证方法，其特征在于，产品服务器响应于用户的访问请求生成服务访问请求消息，包括：

所述产品服务器接收用户的访问请求；

所述产品服务器从所述访问请求中获取用户身份信息；

所述产品服务器通过预设密码对所述用户身份信息进行加密，得到加密信息；

将所述加密信息作为所述服务访问请求消息。

14.根据权利要求13所述的认证方法，其特征在于，所述授权服务器确定所述服务访问请求消息是否来源于所述产品服务，包括：

通过预设的密钥对所述服务访问请求消息进行解密；

在解密成功的情况下，确定所述服务访问请求消息来源于所述产品服务器，则通过用户身份认证。

15.一种授权认证方法，其特征在于，包括：

授权服务器获取来自密钥分发中心的认证服务器的访问请求消息，其中，所述访问请求消息中携带有用户身份信息，其中，所述密钥分发中心的认证服务器中不存储和维护用户的身份信息，其中，所述服务访问请求消息是产品服务器响应于用户的访问请求生成的；

确定所述访问请求消息来源于所述产品服务器；

将表示所述用户身份认证通过的消息发送至所述密钥分发中心的认证服务器。

16.根据权利要求15所述的方法，其特征在于，所述表示用户身份认证通过的消息包括：用户身份信息。

17.根据权利要求15所述的授权认证方法，其特征在于，确定所述服务访问请求消息来源于所述授权服务器对应的产品服务器，包括：

通过预设的密钥对所述服务访问请求消息进行解密；

在解密成功的情况下，确定所述服务访问请求消息来源于所述产品服务器。

18.一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时实现权利要求15至17中任一项所述方法的步骤。

Images