一种访问控制方法及系统与流程

本发明属于应用系统/业务系统的权限控制技术领域，尤其涉及一种访问控制方法及系统。

背景技术：

授权访问控制是一般的软件系统都具有的基础功能，最经典的是基于角色的访问控制(RBAC，Role-Based Access Control)，RBAC模型一般包括：用户(主体)、角色、资源(如菜单、功能、统一资源定位符URL)等，其中，用户、角色及资源具体是m:n:q(m、n、q均为自然数)的关系，即一个用户可以拥有多个角色，一个角色拥有多个资源。一个用户拥有哪些菜单、能够使用哪些功能(操作)，都可以根据这三层关系确定。

基于RBAC模型的访问控制方式较为单一，其无法满足大型企业级系统针对不同业务场景的更细粒度的控制要求，如假设某系统包括工程、档案、资料库等业务场景，针对工程场景，要求在RBAC模型的基础上按工程进行授权，比如某用户能够访问工程A的施工日志，可以对工程A的施工日志进行添加、修改、删除等操作；但对工程B的施工日志，只能查看，不能添加、修改或删除；对工程C的施工日志则所有功能和数据都不可见，而另一用户则拥有对工程A、B、C的全权访问权限(查看、新建、修改、删除)等，RBAC模型由于控制方式较为单一，则无法按照业务场景实现更细粒度的授权控制。

传统方式下，针对大型企业级系统针对不同业务场景的控制要求，一般将系统按不同业务场景，如以上的工程、档案、资料库等拆分成不同的子系统，并针对每一子系统，根据业务需求通过硬编码方式在业务层面对其访问控制策略进行定制开发，此种方式存在开发效率低、随意性大的弊端，且缺乏系统级的标准控制逻辑，各子系统之间的控制策略可能不一致，导致影响系统架构稳定和用户操作体验。

技术实现要素：

有鉴于此，本发明的目的在于提供一种访问控制方法及系统，旨在解决现有技术的控制方式存在的问题，支持对业务系统的不同业务场景进行更细粒度的权限控制。

为此，本发明公开如下技术方案：

一种访问控制方法，包括：

截获用户向业务系统发出的业务请求，所述业务请求包括第一用户标识、授权实例标识及资源标识；其中，所述业务系统包括至少一个业务场景，每个业务场景对应一相应的授权实例集合，所述授权实例集合中的每一授权实例与相应业务场景的一相应应用实例提供的资源集合相对应；所述资源标识对应的目标资源属于目标授权实例对应的资源集合，所述目标授权实例为所述授权实例标识对应的授权实例；

基于所述第一用户标识、所述授权实例标识、所述资源标识及预先存储的授权关系数据，验证所述用户是否具有访问所述目标授权实例下的所述目标资源的权限；

如果具有，则发送所述业务请求至所述业务系统，使得所述业务系统响应所述业务请求；如果不具有，则进行预定的错误处理。

上述方法，优选的，所述业务系统中的每个业务场景对应一相应的授权领域，每个所述授权领域对应一授权实例集合及一候选角色集合；所述候选角色集合中的每一候选角色与相对应授权领域下的至少一个授权实例对应的部分或全部资源相对应；所述授权关系数据包括用户标识与授权角色间的对应关系，所述授权角色属于所述候选角色集合；

则所述基于所述第一用户标识、所述授权实例标识、所述资源标识及预先存储的授权关系数据，验证所述用户是否具有访问所述目标授权实例下的所述目标资源的权限包括：

依据已授权用户的用户标识与授权角色间的对应关系，以及各候选角色与相应授权实例及资源间的对应关系，验证所述第一用户标识与所述目标授权实例及所述目标资源是否匹配；

如果匹配，则所述用户具有访问所述目标授权实例下的所述目标资源的权限；如果不匹配，则所述用户不具有访问所述目标授权实例下的所述目标资源的权限。

上述方法，优选的，所述业务系统对应一全局授权领域，所述全局授权领域对应且仅对应一个系统级授权实例，所述系统级授权实例对应的资源集合为由所述业务系统的系统级资源构成的集合。

上述方法，优选的，还包括：

当所述业务系统的业务场景对应的应用实例发生变化时，对发生变化的应用实例进行同步的授权实例信息更新。

上述方法，优选的，所述当所述业务系统的业务场景对应的应用实例发生变化时，对发生变化的应用实例进行同步的授权实例信息更新包括：

当业务场景产生新增的应用实例时，通过预设的同步接口为所述业务场景新增的应用实例产生相对应的授权实例；

当业务场景对应的应用实例发生修改时，通过所述同步接口对所述业务场景发生修改的应用实例对应的授权实例进行相应的信息修改；

当业务场景对应的应用实例被删除时，通过所述同步接口清除被删除的应用实例所对应的授权实例。

一种访问控制系统，包括：

截获模块，用于截获用户向业务系统发出的业务请求，所述业务请求包括第一用户标识、授权实例标识及资源标识；其中，所述业务系统包括至少一个业务场景，每个业务场景对应一相应的授权实例集合，所述授权实例集合中的每一授权实例与相应业务场景的一相应应用实例提供的资源集合相对应；所述资源标识对应的目标资源属于目标授权实例对应的资源集合，所述目标授权实例为所述授权实例标识对应的授权实例；

验证模块，用于基于所述第一用户标识、所述授权实例标识、所述资源标识及预先存储的授权关系数据，验证所述用户是否具有访问所述目标授权实例下的所述目标资源的权限；

控制模块，用于在验证通过时，则发送所述业务请求至所述业务系统，使得所述业务系统响应所述业务请求；在验证不通过时，进行预定的错误处理。

上述系统，优选的，所述业务系统中的每个业务场景对应一相应的授权领域，每个所述授权领域对应一授权实例集合及一候选角色集合；所述候选角色集合中的每一候选角色与相对应授权领域下的至少一个授权实例对应的部分或全部资源相对应；所述授权关系数据包括用户标识与授权角色间的对应关系，所述授权角色属于所述候选角色集合；

则所述验证模块包括：

验证单元，用于依据已授权用户的用户标识与授权角色间的对应关系，以及各候选角色与相应授权实例及资源间的对应关系，验证所述第一用户标识与所述目标授权实例及所述目标资源是否匹配；

确定单元，用于在匹配时，确定所述用户具有访问所述目标授权实例下的所述目标资源的权限；在不匹配，确定所述用户不具有访问所述目标授权实例下的所述目标资源的权限。

上述系统，优选的，还包括：

同步更新模块，用于在所述业务系统的业务场景对应的应用实例发生变化时，对发生变化的应用实例进行同步的授权实例信息更新。

上述系统，优选的，所述同步更新模块包括：

第一同步单元，用于在业务场景产生新增的应用实例时，通过预设的同步接口为所述业务场景新增的应用实例产生相对应的授权实例；

第二同步单元，用于在业务场景对应的应用实例发生修改时，通过所述同步接口对所述业务场景发生修改的应用实例对应的授权实例进行相应的信息修改；

第三同步单元，用于在业务场景对应的应用实例被删除时，通过所述同步接口清除被删除的应用实例所对应的授权实例。

综上所述，大型的企业级业务系统往往包含至少一个业务场景，每个业务场景会对应包含至少一个应用实例，基于此，本申请方法在RBAC模型的基础上，增加了新的模型对象——授权实例，其中，授权实例与业务系统中业务场景的具体应用实例相对应，也就是说，业务系统包含的每个业务场景均对应一相应的授权实例集合，授权实例集合中的每一授权实例与相应业务场景的一相应应用实例提供的资源集合相对应。由此可见，本申请方法通过新增的模型对象——授权实例，可实现对业务系统按各业务场景进行更细粒度的授权资源划分，在应用本申请时，可基于这一更细粒度的授权资源划分情况，在权限控制层面针对每个业务场景分别设置该场景下对应于不同资源权限的多个候选角色，即实现了按业务场景进行场景下的候选角色设置，后续在用户访问系统时，可基于用户具有的业务场景下的角色，对其按业务场景进行更细粒度的访问权限控制，可见本申请克服了现有技术存在的问题，可有效满足大型企业级系统针对不同业务场景的更细粒度的控制要求。

附图说明

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

图1是本发明实施例一提供的访问控制方法流程图；

图2是本发明实施例二提供的访问控制方法流程图；

图3-图4是本发明实施例三提供的访问控制系统的结构示意图。

具体实施方式

为了引用和清楚起见，下文中使用的技术名词、简写或缩写总结解释如下：

资源：系统具有的功能资源信息，是一个树型结构，包括系统的菜单、功能(按钮)、服务或接口地址等。

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

实施例一

本申请实施例一提供一种访问控制方法，该方法适用于对大型企业级系统按业务场景进行更细粒度的授权控制，参考图1示出的访问控制方法流程图，该方法可以包括以下步骤：

S101：截获用户向业务系统发出的业务请求，所述业务请求包括第一用户标识、授权实例标识及资源标识；其中，所述业务系统包括至少一个业务场景，每个业务场景对应一相应的授权实例集合，所述授权实例集合中的每一授权实例与相应业务场景的一相应应用实例提供的资源集合相对应；所述资源标识对应的目标资源属于目标授权实例对应的资源集合，所述目标授权实例为所述授权实例标识对应的授权实例。

S102：基于所述第一用户标识、所述授权实例标识、所述资源标识及预先存储的授权关系数据，验证所述用户是否具有访问所述目标授权实例下的所述目标资源的权限。

S103：如果具有，则发送所述业务请求至所述业务系统，使得所述业务系统响应所述业务请求。

S104：如果不具有，则进行预定的错误处理。

接下来对本申请方案的实现过程进行详细说明。

大型的企业级业务系统往往包含至少一个业务场景，如工程、档案及资料库等业务场景，每个业务场景会对应包含至少一个应用实例，以工程为例，其可以包括工程A、工程B、工程C等应用实例，各应用实例分别提供相应的资源集合，如菜单、功能和/或URL(Uniform Resoure Locator，统一资源定位符)等各种资源。基于大型企业级系统存在的针对不同业务场景的更细粒度的控制需求，本申请方法在RBAC模型的基础上，增加了新的模型对象——授权实例，其中，授权实例与业务系统中业务场景的具体应用实例相对应，也就是说，业务系统包含的每个业务场景均对应一相应的授权实例集合，授权实例集合中的每一授权实例与相应业务场景的一相应应用实例提供的资源集合相对应。

本申请同时针对业务系统的业务场景增加授权领域这一对象，其中授权领域用于对业务系统按不同业务场景进行授权控制时的领域划分，假设业务系统包括工程、档案及资料库等不同场景，则可对应将业务系统的授权领域划分为系统领域、工程领域、档案领域及资料库领域等各个授权领域，一个授权领域对应一个业务场景，而对于系统领域，则其具体与整个业务系统相对应，是系统级的授权领域。

某一业务场景对应的各个授权实例具体是该业务场景所对应的授权领域下的实例，即一个业务场景对应的授权领域可对应包含一相应的授权实例集合，仍以工程场景为例，在该场景对应的授权领域即工程领域下，可对应包括工程A授权实例、工程B授权实例、工程C授权实例等等，其中，授权实例具体为对业务系统按业务场景进行更细粒度的授权控制时，所需的针对业务场景应用实例的一些关联基础数据，比如所述工程A授权实例具体可以包括工程A的工程编号、负责人员和/或台账信息等用于与业务系统中的工程A相关联的一些基础数据，而对于档案授权实例，则其具体可以包括档案分类号，如工程档案号、财务档案号等，通过包含的一些必要的关联基础数据，授权实例可实现与业务系统中相应业务场景下的相应应用实例相关联，进而可实现与相应应用实例提供的一系列资源相关联。

而系统领域只有一个实例，其代表整个系统本身，该实例对应的资源具体为系统级别的资源，即业务系统中各个业务场景所提供的资源之外的资源。从而，本申请中，业务系统提供的某一个资源一定属于某一个授权领域，具体按该资源属于系统级资源或场景级资源分别对应属于系统领域或相应业务场景对应的授权领域。

在增加授权领域和授权实例两个对象的基础上，本申请利用授权领域及授权对象对业务系统按业务场景进行更细粒度的授权资源划分，具体地，可在权限控制层面针对业务系统包括的业务场景构建授权领域，例如针对业务系统包括的工程、档案、资料库等业务场景，构建相应的工程、档案、资料库等授权领域，并在每一授权领域下，按相应业务场景包含的应用实例，构建该授权领域下的授权实例集合，同时针对每一授权实例，为其关联相应应用实例提供的资源集合的资源信息。在权项控制层面所创建的包含授权领域、授权实例、资源信息的三级架构，实现了对业务系统按业务场景进行更细粒度的授权资源划分。

之后，可针对各个授权领域进行相互独立的角色设置，对于某一授权领域，具体可根据该领域的实际业务需求分别设置对应于不同访问权限/资源权项的多个候选角色，每一候选角色与相对应授权领域下的至少一个授权实例对应的部分或全部资源相对应；以工程领域为例，可针对工程领域包含的工程A、工程B、工程C等多个授权实例，以及各个授权实例对应的不同的资源信息，设置角色1、角色2、角色3等多个候选角色，每个候选角色拥有不同的访问权限，例如角色1能够对工程领域下所有工程进行全权访问(查看、增删该等)，角色2能够访问工程A的施工日志，可以对工程A的施工日志进行添加、修改、删除等操作；但对工程B的施工日志，只能查看，不能添加、修改或删除；对工程C的施工日志则所有功能和数据都不可见等等。相类似地，对于档案、资料库等授权领域，同样可按其业务需求预先设置一系列分别对应不同访问权限的候选角色。

在此基础上，可通过为各个用户在其所需的授权领域下为其分配所需的角色，实现为各个用户按业务场景配置相应的访问权限/资源权限，同一用户可在多个业务场景/授权领域下分别拥有相匹配的多个角色，从而，该用户可通过其在多个业务场景下拥有的相应角色，对多个业务场景进行相应权限的资源访问。比如，假设工程总监在工程领域拥有角色x，该角色x可以对工程领域的所有工程资源进行全权访问，而其在档案领域拥有角色y，该角色y仅能对工程档案号对应的相关档案进行全权访问，而对于财务档案号对应的相关档案则仅具有查看权限等，从而工程总监可基于所述角色x、角色y分别对工程场景及档案场景进行相应权限的访问。

通过以上阐述可知，本申请将授权模型扩展为包含用户、授权实例、角色、资源等模型对象，且所述各模型对象：用户、授权实例、角色、资源间存在m:n:q:r的关系，其中，m、n、q、r均为自然数，通过这一扩展的授权模型，可有效满足大型企业级系统针对不同业务场景的更细粒度的控制要求。

在构建授权模型并基于授权模型为用户分配相应角色的基础上，可对用户对业务系统的访问过程进行相应的访问权限控制。

具体地，在用户向业务系统发出业务请求时，如用户通过客户端向业务系统发出业务请求时，拦截用户的业务请求，该业务请求包括所述用户的第一用户标识、授权实例标识及资源标识(如用户ID、授权实例ID、资源ID等)，其中，该资源标识对应的目标资源属于目标授权实例对应的资源集合，所述目标授权实例为所述授权实例标识对应的授权实例。

之后，基于所述第一用户标识、所述授权实例标识、所述资源标识在维护的授权关系数据中查询匹配项，若匹配成功，则验证通过，否则验证未通过。具体地，可首先通过查询已授权的用户标识与授权角色间的对应关系数据，确定所述第一用户标识是否存在相匹配的授权角色，如果存在，则继续查询各候选角色与相应授权实例及资源间的对应关系数据，确定该对应关系数据中是否存在与所述授权角色(第一用户标识对应的授权角色)、所述目标授权实例、所述目标资源相对应的匹配项，如果存在相应匹配项，则表征该用户存在对所述目标授权实例下的所述目标资源进行访问的权限，从而验证通过；否则，则不具备相应的访问权项，验证未通过。

在验证通过时，可对拦截的用户业务请求进行放行，将其发送至所述业务系统，从而使得所述业务系统基于该业务请求执行相应的响应操作；如果验证未通过，则向用户返回错误信息，访问失败。

具体实施本发明时，可在应用服务器上实现本申请提供的授权模型构建及权限控制过程，并将其作为大型应用系统的一个基础组件，该基础组件针对业务系统的各业务场景可提供相一致的系统级控制策略，本申请所提供的控制策略的开发过程与业务系统中业务场景的开发过程相互独立，从而与现有技术中针对每一业务场景，根据业务需求通过硬编码方式在业务层面对其访问控制策略进行定制开发的方式存在实质不同，因此应用本申请方案可有效保证业务系统的系统架构稳定，可提升用户的操作体验。

由此可见，本申请方法通过新增的模型对象——授权实例，可实现对业务系统按各业务场景进行更细粒度的授权资源划分，在应用本申请时，可基于这一更细粒度的授权资源划分情况，在权限控制层面针对每个业务场景分别设置该场景下对应于不同资源权限的多个候选角色，即实现了按在业务场景进行候选角色设置，后续在用户访问系统时，可基于用户具有的业务场景下的角色，对其按业务场景进行更细粒度的访问权限控制，可见本申请克服了现有技术存在的问题，可有效满足大型企业级系统针对不同业务场景的更细粒度的控制要求。

实施例二

本实施例二中，参考图2示出的访问控制方法的流程图，所述方法还可以包括以下步骤：

S105：当所述业务系统的业务场景对应的应用实例发生变化时，对发生变化的应用实例进行同步的授权实例信息更新。

具体地，当业务场景产生新增的应用实例时，通过预设的同步接口在相对应的授权领域下为所述新增的应用实例产生相对应的授权实例；例如，在工程场景中，如果新增了工程D，则通过所述同步接口在工程领域下生成工程D对应的授权实例，如生成工程D的工程编号、负责人员等等；

当业务场景对应的应用实例发生修改时，通过所述同步接口在相对应的授权领域下对发生修改的应用实例对应的授权实例进行相应的信息修改；如当工程A的负责人员发生变化时，则通过所述同步接口具体对工程A的授权实例中的负责人信息进行更新；

当业务场景对应的应用实例被删除时，通过所述同步接口在相对应的授权领域下清除被删除的应用实例所对应的授权实例，例如，当工程B在业务系统中被删除时，则通过所述同步接口对工程领域下的工程B的授权实例进行同步删除。

后续，相应管理人员，如系统级管理人员或业务场景级/授权领域级的管理人员可基于同步更新后的新的授权实例信息进行角色的权限划分或授权。

需要说明的是，系统领域只有一个实例，其代表整个系统本身，不需要进行更新同步。还需要说明的是，本实施例的步骤S105与以上步骤S101-S104的先后执行次序不局限于图2示出的次序，其中，授权实例信息的更新是与业务系统中业务场景产生的相应数据变化同步进行的，即当业务系统产生相应数据变化时，数据接口实时地、同步地更新相应的授权实例信息，因此实际应用中该步骤S105的执行不限于步骤S101-S104的执行情况，在步骤S101-S104未执行或执行过程中均可基于业务系统的数据变化情况，对授权实例信息进行所需的实时更新。

本实施例通过在业务系统的数据发生变时，利用同步接口同步更新对应的授权实例信息，可有效维护权限控制层面信息与业务层面信息的一致性，进而可有效确保业务系统访问权限控制的高度准确性。

实施例三

本实施例三公开一种访问控制系统，该系统与以上实施例公开的访问控制方法相对应。

相应于实施例一，参考图3示出的访问控制系统的结构示意图，该系统可以包括截获模块100、验证模块200和控制模块300。

截获模块100，用于截获用户向业务系统发出的业务请求，所述业务请求包括第一用户标识、授权实例标识及资源标识；其中，所述业务系统包括至少一个业务场景，每个业务场景对应一相应的授权实例集合，所述授权实例集合中的每一授权实例与相应业务场景的一相应应用实例提供的资源集合相对应；所述资源标识对应的目标资源属于目标授权实例对应的资源集合，所述目标授权实例为所述授权实例标识对应的授权实例。

验证模块200，用于基于所述第一用户标识、所述授权实例标识、所述资源标识及预先存储的授权关系数据，验证所述用户是否具有访问所述目标授权实例下的所述目标资源的权限。

所述验证模块200包括验证单元和确定单元。

验证单元，用于依据用户标识与授权角色间的对应关系，以及各候选角色与相应授权实例及资源间的对应关系，验证所述第一用户标识与所述目标授权实例及所述目标资源是否匹配；

确定单元，用于在匹配时，确定所述用户具有访问所述目标授权实例下的所述目标资源的权限；在不匹配，确定所述用户不具有访问所述目标授权实例下的所述目标资源的权限。

控制模块300，用于在验证通过时，则发送所述业务请求至所述业务系统，使得所述业务系统响应所述业务请求；在验证不通过时，进行预定的错误处理。

相应于实施例二，参考图4示出的访问控制系统的结构示意图，所述系统还可以包括同步更新模块400，该模块包括第一同步单元、第二同步单元和第三同步单元。

第一同步单元，用于在业务场景产生新增的应用实例时，通过预设的同步接口为所述新增的应用实例产生相对应的授权实例；

第二同步单元，用于在业务场景对应的应用实例发生修改时，通过所述同步接口对发生修改的应用实例对应的授权实例进行相应的信息修改；

第三同步单元，用于在业务场景对应的应用实例被删除时，通过所述同步接口清除被删除的应用实例所对应的授权实例。

对于本发明实施例三公开的访问控制系统而言，由于其与实施例一至实施例二公开的访问控制方法相对应，所以描述的比较简单，相关相似之处请参见实施例一至实施例二中访问控制方法部分的说明即可，此处不再详述。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

为了描述的方便，描述以上系统或装置时以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。