CN105721420B - 访问权限控制方法和反向代理服务器 - Google Patents

Abstract

本发明涉及一种访问权限控制方法和反向代理服务器。其中，在网络层设置反向代理服务器，反向代理服务器被配置为控制用户访问应用服务器中的资源的权限，所述方法包括：所述反向代理服务器接收所述用户发出的资源访问请求；根据所述用户标识确定所述用户所归属的用户组；确定所述用户组能够访问的至少一个可访问资源组；根据所述资源信息，确定所述用户要访问的资源所归属的待访问资源组；以及在各所述可访问资源组包括所述待访问资源组的情况下，判断为所述用户具有访问所述资源的权限。根据本发明实施例的访问权限控制方法和反向代理服务器能够灵活地进行访问权限控制的管理，并且不需要高配置的服务器，具有成本低、高可用性、维护方便等优点。

Description

访问权限控制方法和反向代理服务器

技术领域

本发明涉及互联网技术应用领域，尤其涉及一种访问权限控制方法和反向代理服务器。

背景技术

目前互联网应用系统主要是在应用层对访问进行控制，这种方法也称为“硬编码”，即在系统功能应用中实现权限控制功能。这种在应用层实现访问控制的方法相对灵活，但是需要在每个应用中都添加权限控制，因此代码冗余高。而且，实现权限控制功能的代码和应用代码高度耦合，因此，在权限发生变化时，需要修改应用代码，维护难度高。

发明内容

技术问题

有鉴于此，本发明要解决的技术问题是，在应用层进行访问控制时所面临的管理复杂并且难以维护的问题。

解决方案

为了解决上述技术问题，根据本发明的一个方面，提供了一种访问权限控制方法，其中，在网络层设置反向代理服务器，所述反向代理服务器被配置为控制用户访问应用服务器中的资源的权限，所述方法包括：所述反向代理服务器接收所述用户发出的资源访问请求，其中，所述资源访问请求包括所述用户要访问的资源信息和所述用户的用户标识；根据所述用户标识确定所述用户所归属的用户组；确定所述用户组能够访问的至少一个可访问资源组；根据所述资源信息，确定所述用户要访问的资源所归属的待访问资源组；以及在各所述可访问资源组包括所述待访问资源组的情况下，判断为所述用户具有访问所述资源的权限。

对于上述访问权限控制方法，在一种可能的实现方式中，还包括：在各所述可访问资源组不包括所述待访问资源组的情况下，判断为所述用户不具有访问所述资源的权限。

对于上述访问权限控制方法，在一种可能的实现方式中，还包括：预先设置所述用户的用户标识与所述用户所归属的用户组之间的第一对应关系，其中，一个用户与至少一个用户组相对应，根据所述用户标识确定所述用户所归属的用户组具体为，根据所述第一对应关系将与所述用户标识相对应的用户组确定为所述用户所在的用户组。

对于上述访问权限控制方法，在一种可能的实现方式中，还包括：预先设置所述资源与其所归属的资源组之间的第二对应关系，其中，一个资源与一个资源组相对应，根据所述资源信息，获取所述用户要访问的资源所归属的待访问资源组具体为，根据所述第二对应关系将与所述资源相对应的资源组确定为所述待访问资源组。

对于上述访问权限控制方法，在一种可能的实现方式中，还包括：预先设置用户组与其能够访问的资源组之间的第三对应关系，其中，一个用户组与至少一个资源组相对应，根据所述用户组确定所述用户组能够访问的至少一个可访问资源组具体为，根据所述第三对应关系将与所述用户组相对应的资源组确定为所述可访问资源组。

为了解决上述技术问题，根据本发明的另一个方面，提供了一种反向代理服务器，其中，所述反向代理服务器设置在网络层，被配置为控制用户访问应用服务器中的资源的权限，所述反向代理服务器包括：接收模块，被配置为接收所述用户发出的资源访问请求，其中，所述资源访问请求包括所述用户要访问的资源信息和所述用户的用户标识；第一确定模块，与所述接收模块连接，被配置为根据所述用户标识确定所述用户所归属的用户组；第二确定模块，与所述接收模块和所述第一确定模块连接，被配置为确定所述用户组能够访问的至少一个可访问资源组；第三确定模块，与所述接收模块和所述第一确定模块连接，被配置为根据所述资源信息，确定所述用户要访问的资源所归属的待访问资源组；以及判断模块，与所述第二确定模块和所述第三确定模块连接，被配置为判断各所述可访问资源组是否包括所述待访问资源组，并在各所述可访问资源组包括所述待访问资源组的情况下，判断为所述用户具有访问所述资源的权限。

对于上述反向代理服务器，在一种可能的实现方式中，在各所述可访问资源组不包括所述待访问资源组的情况下，所述判断模块判断为所述用户不具有访问所述资源的权限。

对于上述反向代理服务器，在一种可能的实现方式中，还包括：第一预设模块，与所述第一确定模块连接，被配置为预先设置所述用户的用户标识与所述用户所归属的用户组之间的第一对应关系，其中，一个用户与至少一个用户组相对应，所述第一确定模块具体被配置为，根据所述第一对应关系将与所述用户标识相对应的用户组确定为所述用户所在的用户组。

对于上述反向代理服务器，在一种可能的实现方式中，还包括：第二预设模块，与所述第二确定模块连接，被配置为预先设置所述资源与其所归属的资源组之间的第二对应关系，其中，一个资源与一个资源组相对应，所述第二确定模块具体被配置为，根据所述第二对应关系将与所述资源相对应的资源组确定为所述待访问资源组。

对于上述反向代理服务器，在一种可能的实现方式中，还包括：第三预设模块，与所述第三确定模块连接，被配置为预先设置用户组与其能够访问的资源组之间的第三对应关系，其中，一个用户组与至少一个资源组相对应，所述第三确定模块具体被配置为，根据所述第三对应关系将与所述用户组相对应的资源组确定为所述可访问资源组。

有益效果

通过在网络层设置反向代理服务器，来控制用户访问应用服务器中的资源的权限，根据本发明实施例的访问权限控制方法能够灵活地进行访问权限控制的管理，并且不需要高配置的服务器，具有成本低、高可用性、维护方便等优点。

根据下面参考附图对示例性实施例的详细说明，本发明的其它特征及方面将变得清楚。

附图说明

包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本发明的示例性实施例、特征和方面，并且用于解释本发明的原理。

图1示出根据本发明一实施例的访问权限控制方法的流程示意图；

图2示出根据本实施例所采用的角色访问控制模型；

图3示出根据本发明另一实施例的访问权限控制方法的流程示意图；

图4示出使用Nginx做反向代理的网络架构的示意图；

图5示出根据本发明一实施例的反向代理服务器的框图。

具体实施方式

以下将参考附图详细说明本发明的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

另外，为了更好的说明本发明，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本发明同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本发明的主旨。

实施例1

图1示出根据本发明一实施例的访问权限控制方法的流程示意图。根据本实施例的访问权限控制方法在网络层设置有反向代理服务器，该反向代理服务器被配置为控制用户访问应用服务器中的资源的权限。如图1所示，该访问权限控制方法主要可以包括：

步骤S110、反向代理服务器接收用户发出的资源访问请求，其中，资源访问请求可以包括用户要访问的资源信息和用户的用户标识；

步骤S120、根据用户标识确定用户所归属的用户组；

步骤S130、确定用户组能够访问的至少一个可访问资源组；

步骤S140、根据资源信息，确定用户要访问的资源所归属的待访问资源组；以及

步骤S150、在各可访问资源组包括待访问资源组的情况下，判断为所述用户具有访问所述资源的权限。

在一种可能的实现方式中，根据本实施例的访问权限控制方法还可以包括步骤S160、在各可访问资源组不包括所述待访问资源组的情况下，判断为所述用户不具有访问所述资源的权限。

这样，通过在网络层设置反向代理服务器，来对网络层上的所有应用服务进行灵活的访问权限控制管理，不需要高配置的服务器，并可以采用免费的开源软件，具有成本低、高可用性、维护方便等优点。

在一种可能的实现方式中，根据本实施例的访问权限控制方法在步骤S110之前，还可以包括：预先设置用户的用户标识与用户所归属的用户组之间的第一对应关系，其中，一个用户可以与至少一个用户组相对应。在这种实现方式中，步骤S120具体可以为，根据预设的第一对应关系将与用户标识相对应的用户组确定为用户所在的用户组。

在一种可能的实现方式中，根据本实施例的访问权限控制方法在步骤S110之前，还可以包括：预先设置所述资源与其所归属的资源组之间的第二对应关系，其中，一个资源可以与一个资源组相对应。在这种实现方式中，步骤S140具体可以为，根据预设的第二对应关系将与所述资源相对应的资源组确定为所述待访问资源组。

在一种可能的实现方式中，根据本实施例的访问权限控制方法在步骤S110之前，还可以包括：预先设置用户组与其能够访问的资源组之间的第三对应关系，其中，一个用户组与至少一个资源组相对应。在这种实现方式中，步骤S130具体可以为，根据预设第三对应关系将与所述用户组相对应的资源组确定为所述可访问资源组。

需要说明的是，尽管以步骤S110之后依次执行步骤S120、S130和S140作为示例介绍了本发明的访问权限控制方法如上，但本领域技术人员能够理解，本发明应不限于此。事实上，用户完全可根据个人喜好和/或实际应用场景灵活设定步骤S120至步骤S140的执行顺序，另外，这三个步骤的执行顺序也可以不分先后，可以并行执行。

这样，通过预先设置用户与其所属用户组之间的对应关系，资源与其所属资源组之间的对应关系，用户组与可访问资源组之间的对应关系，根据本发明上述实施例的访问权限控制方法能够对用户的资源访问请求做出快速、正确的响应。

实施例2

根据本实施例的访问权限控制方法基于角色访问控制(英文：Role-Based AccessControl，缩写：RBAC)和Nginx(enginex)反向代理服务配置策略来实现对网络资源访问的权限控制。下面对角色访问控制和Nginx反向代理服务进行详细说明。

访问控制是指按照预先设置的权限规则，系统的使用者能且只能对自己权限范围内的资源进行权限内的操作。传统的权限控制管理中资源的权限有一个全局的管理员进行分配，通过将系统中的资源分密级和类进行管理，以保证每个用户只能访问到那些被标明可以由他访问的资源。这种方式统筹管理系统资源的分配，但是当系统用户和资源量都非常多时，管理将会变得非常复杂而且难以维护。

而本实施例则基于角色访问控制来配置权限，即将资源以及资源的操作构成的权限授予给角色，将组织机构或具体人员用户分配给角色对象完成资源权限的授权过程。角色对象和资源操作权限所授予的对象做一对多的关联，满足了资源访问权限授予给多种角色对象的需求。

为了达到用户与资源的有效授权匹配，本申请发明人设计采取用户组与资源组的概念进行管理。图2示出了根据本实施例所采用的角色访问控制模型。如图2所示，用户组是对网站用户的一个分类，例如可以根据用户密级和职位来划分用户组，其中，一个用户可以包括在多个用户组中，例如图2所示地，用户1包括在用户组A和用户组C中。资源组是对网络系统资源进行的分类，同时定义对资源访问操作的权限，其中，资源与资源组是一对一的关系，即一个资源只包括在一个资源组中。另外，还将用户组与资源组进行绑定，其中，用户组与资源组设定为一对多关系，即一个用户组可以访问多个资源组中的资源，例如图2所示地，用户组B可以访问资源组A和资源组B中的资源。某一用户组下的用户对其所在用户组绑定的资源组下的资源按照绑定资源组分配的权限进行访问操作。

Nginx反向代理服务即在网络站群系统中，站群中的站点在展示上可能是上下级关系，但在开发时各站点是相互独立的、又是相互联系且共享的，部署也是平级的。就使得站群系统的站点管理既具有分开部署的特点，也具有集成部署的要求。利用Nginx实现的站点管理就可以实现各站点之间彼此独立，还能有机整合成一个资源共享、信息互动以及责任分明的站群平台。Nginx作为反向代理服务器时，一台Nginx在前端作为反向代理服务器，后端放置多台Web服务器。Nginx作为用户的访问入口，当客户端向Nginx反向代理服务器发送资源访问请求时，Nginx利用它的Handles处理模块为其服务，服务器根据配置好的访问控制策略进行权限判断，符合权限的请求向后端Web服务器转交。后端Web服务器接收到请求后，将请求内容返回给反向代理服务器，最后返回给客户端实现访问。不符合权限的请求由Nginx代理跳转至警告页面。

图3示出根据本发明另一实施例的访问权限控制方法的流程示意图。根据本实施例的权限访问控制的过程如下：

a.系统根据登录用户获取其所在用户组信息；

b.根据当前用户组获取该用户组绑定的资源组信息；

c.用户在系统内对某一条资源进行访问时，获取到该条资源对应的资源组信息；

d.将当前获取的资源组的信息与权限配置表中的资源组操作权限进行比对判断是否有操作权限；

e.经判断权限为“是”，则用户正常访问；权限为“否”，则系统跳转至警告页。

在一种可能的实现方式中，使用Nginx做反向代理的网络架构可以如图4所示。使用Nginx做反向代理处理，将Nginx部署在防火墙停火区外，网站部署在防火墙停火区内，互联网用户通过Nginx代理来访问门户网站，确保了内部IP和信息全部经过代理以后才能出去。将所有基于网络的应用服务访问URL作为资源，在Nginx配置文件中建立资源访问请求的处理策略，配合基于角色访问控制模型中的权限关系，对访问请求做出正确的响应。将在下面的实施例中详述本发明的用于控制用户访问应用服务器中资源的权限的。

实施例3

图5示出了根据本发明一实施例的反向代理服务器的框图示意图。根据本实施例的反向代理服务器300设置在网络层，可以经由因特网200与用户终端100连接，并与向用户终端100提供应用资源的应用服务器集群400，被配置为控制用户访问应用服务器集群400中的资源的权限。

根据本实施例的反向代理服务器300可以包括：接收模块310、第一确定模块320、第二确定模块330、第三确定模块340和判断模块350。

具体地，接收模块310可以被配置为接收用户发出的资源访问请求，其中，资源访问请求可以包括用户要访问的资源信息和用户的用户标识；第一确定模块320与接收模块310连接，可以被配置为根据用户标识确定用户所归属的用户组；第二确定模块330与接收模块310和第一确定模块320连接，可以被配置为确定用户组能够访问的至少一个可访问资源组；第三确定模块340与接收模块310和第一确定模块320连接，可以被配置为根据资源信息，确定用户要访问的资源所归属的待访问资源组；判断模块350与第二确定模块330和第三确定模块340连接，被配置为判断各所述可访问资源组是否包括所述待访问资源组，并在各所述可访问资源组包括所述待访问资源组的情况下，判断为所述用户具有访问所述资源的权限。

在一种可能的实现方式中，在各所述可访问资源组不包括所述待访问资源组的情况下，判断模块350判断为用户不具有访问所述资源的权限。接收模块310、第一确定模块320、第二确定模块330、第三确定模块340和判断模块350的具体实现可以参考实施例1中对步骤S110至步骤S160的描述。

在一种可能的实现方式中，如图5所示，根据本实施例的反向代理服务器300还可以包括：第一预设模块360。其中，第一预设模块360与第一确定模块320连接，可以被配置为预先设置用户的用户标识与用户所归属的用户组之间的第一对应关系，其中，一个用户与至少一个用户组相对应。在这种实现方式中，第一确定模块320具体可以被配置为，根据第一对应关系将与所述用户标识相对应的用户组确定为所述用户所在的用户组。

在一种可能的实现方式中，如图5所示，根据本实施例的反向代理服务器300还可以包括：第二预设模块370。其中，第二预设模块370与第二确定模块330连接，可以被配置为预先设置资源与其所归属的资源组之间的第二对应关系，其中，一个资源与一个资源组相对应。在这种实现方式中，第二确定模块330具体可以被配置为，根据第二对应关系将与所述资源相对应的资源组确定为所述待访问资源组。

在一种可能的实现方式中，如图5所示，根据本实施例的反向代理服务器300还可以包括：第三预设模块380。其中，第三预设模块380与第三确定模块340连接，可以被配置为预先设置用户组与其能够访问的资源组之间的第三对应关系，其中，一个用户组与至少一个资源组相对应。在这种实现方式中，第三确定模块340具体可以被配置为，根据第三对应关系将与所述用户组相对应的资源组确定为所述可访问资源组。

需要说明的是，尽管以用于确定用户所归属的用户组、用户组能够访问的至少一个可访问资源组、要访问的资源所归属的待访问资源组的模块为三个单独的模块为例进行了说明，但是，本领域技术人员应能理解，也可以使用一个确定模块来实现。在这种实现方式中，可以只需要一个预设模块。

通过在网络层设置反向代理服务器，被通过该反向代理服务器来控制用户访问应用服务器中的资源的权限，根据本发明上述实施例的访问权限控制方法和反向代理服务器能够克服通过应用层进行权限访问控制所存在的以下缺点：

1、访问控制必须在每个用户的接口被检测，增加了全部代码的大小并且访问控制策略的任何变动都需要改变大量的代码；

2、所有的安全策略必须被实施到每一个构建在网络层上的应用系统中，当需要进行访问控制的应用系统数量多事，管理会变得非常复杂而且难以维护；

3、应用代码非常大,有可能忽略了那些被开发的漏洞，从而破坏安全策略。例如：对于应用程序员来说，设计不当的小服务程序，很容易创建恶意的陷门，因为在一个大型的应用程序中,不可能检查每一行的代码。

另外，根据本发明上述实施例的访问权限控制方法和反向代理服务器能够实现降低站点权限管理的复杂度、提高权限实施的准确度和访问控制策略配置的便捷性的有益效果。

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

Claims (8)

1.一种访问权限控制方法，其特征在于，在网络层设置反向代理服务器，所述反向代理服务器被配置为控制用户访问应用服务器中的资源的权限，所述方法包括：

所述反向代理服务器接收所述用户发出的资源访问请求，其中，所述资源访问请求包括所述用户要访问的资源信息和所述用户的用户标识；

根据所述用户标识确定所述用户所归属的用户组；

确定所述用户组能够访问的至少一个可访问资源组；

根据所述资源信息，确定所述用户要访问的资源所归属的待访问资源组；以及

在各所述可访问资源组包括所述待访问资源组的情况下，判断为所述用户具有访问所述资源的权限，

所述方法还包括：预先设置所述用户的用户标识与所述用户所归属的用户组之间的第一对应关系，其中，一个用户与至少一个用户组相对应，

根据所述用户标识确定所述用户所归属的用户组具体为，根据所述第一对应关系将与所述用户标识相对应的用户组确定为所述用户所在的用户组。

2.根据权利要求1所述的访问权限控制方法，其特征在于，还包括：

在各所述可访问资源组不包括所述待访问资源组的情况下，判断为所述用户不具有访问所述资源的权限。

3.根据权利要求1所述的访问权限控制方法，其特征在于，还包括：预先设置所述资源与其所归属的资源组之间的第二对应关系，其中，一个资源与一个资源组相对应，

根据所述资源信息，获取所述用户要访问的资源所归属的待访问资源组具体为，根据所述第二对应关系将与所述资源相对应的资源组确定为所述待访问资源组。

4.根据权利要求1至3中任一项所述的访问权限控制方法，其特征在于，还包括：预先设置用户组与其能够访问的资源组之间的第三对应关系，其中，一个用户组与至少一个资源组相对应，

根据所述用户组确定所述用户组能够访问的至少一个可访问资源组具体为，根据所述第三对应关系将与所述用户组相对应的资源组确定为所述可访问资源组。

5.一种反向代理服务器，其特征在于，所述反向代理服务器设置在网络层，被配置为控制用户访问应用服务器中的资源的权限，所述反向代理服务器包括：

接收模块，被配置为接收所述用户发出的资源访问请求，其中，所述资源访问请求包括所述用户要访问的资源信息和所述用户的用户标识；

第一确定模块，与所述接收模块连接，被配置为根据所述用户标识确定所述用户所归属的用户组；

第二确定模块，与所述接收模块和所述第一确定模块连接，被配置为确定所述用户组能够访问的至少一个可访问资源组；

第三确定模块，与所述接收模块和所述第一确定模块连接，被配置为根据所述资源信息，确定所述用户要访问的资源所归属的待访问资源组；以及判断模块，与所述第二确定模块和所述第三确定模块连接，被配置为判断各所述可访问资源组是否包括所述待访问资源组，并在各所述可访问资源组包括所述待访问资源组的情况下，判断为所述用户具有访问所述资源的权限；

第一预设模块，与所述第一确定模块连接，被配置为预先设置所述用户的用户标识与所述用户所归属的用户组之间的第一对应关系，其中，一个用户与至少一个用户组相对应，

所述第一确定模块具体被配置为，根据所述第一对应关系将与所述用户标识相对应的用户组确定为所述用户所在的用户组。

6.根据权利要求5所述的反向代理服务器，其特征在于，在各所述可访问资源组不包括所述待访问资源组的情况下，所述判断模块判断为所述用户不具有访问所述资源的权限。

7.根据权利要求5所述的反向代理服务器，其特征在于，还包括：第二预设模块，与所述第二确定模块连接，被配置为预先设置所述资源与其所归属的资源组之间的第二对应关系，其中，一个资源与一个资源组相对应，

所述第二确定模块具体被配置为，根据所述第二对应关系将与所述资源相对应的资源组确定为所述待访问资源组。

8.根据权利要求5至7中任一项所述的反向代理服务器，其特征在于，还包括：第三预设模块，与所述第三确定模块连接，被配置为预先设置用户组与其能够访问的资源组之间的第三对应关系，其中，一个用户组与至少一个资源组相对应，

所述第三确定模块具体被配置为，根据所述第三对应关系将与所述用户组相对应的资源组确定为所述可访问资源组。