CN1960252A - 基于角色的多维度对象访问控制方法 - Google Patents

基于角色的多维度对象访问控制方法 Download PDF

Info

Publication number
CN1960252A
CN1960252A CN 200610085769 CN200610085769A CN1960252A CN 1960252 A CN1960252 A CN 1960252A CN 200610085769 CN200610085769 CN 200610085769 CN 200610085769 A CN200610085769 A CN 200610085769A CN 1960252 A CN1960252 A CN 1960252A
Authority
CN
China
Prior art keywords
role
dimension
user
data
permission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN 200610085769
Other languages
English (en)
Inventor
吴旻哲
黄小新
宋海华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LIAN Technology (Nanjing) Co., Ltd.
Original Assignee
LINKAGE SYSTEM INTEGRATION CO Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LINKAGE SYSTEM INTEGRATION CO Ltd filed Critical LINKAGE SYSTEM INTEGRATION CO Ltd
Priority to CN 200610085769 priority Critical patent/CN1960252A/zh
Publication of CN1960252A publication Critical patent/CN1960252A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Storage Device Security (AREA)

Abstract

基于角色的多维度对象访问控制方法：在被管理对象集中引入“对象维度”的概念，细化被管对象定义；在不同的维度下将被管对象划分为多个组，同时允许组之间的嵌套，形成树状层次关系；不同维度代表对象不同的分类方式，系统中支持多种分类方式并存。将系统权限划分为数据权限和操作权限。针对数据权限，系统中所有需要受权限控制的数据实体都应该拥有对应的安全管理对象，将这些安全对象与不同的角色Role关联，即可完成数据权限的划分；在该模型中将安全管理对象进行了分组，支持在同一运行时对系统中的所有安全管理对象进行多种分组方式，每一个分组方式都称之为一个“维度”，而在该维度下的取值，即具体的一个组别。

Description

基于角色的多维度对象访问控制方法
                            技术领域
本发明涉及计算机数据库的安全解决方案，尤其是涉及对数据库的访问控制方法。
                            背景技术
访问控制(Access Control)：或者说授权(Authorization)。访问控制是众多计算机安全解决方案中的一种，是最直观自然的一种方案。信息安全的风险可以被宽泛的归结为CIA：信息机密性(Confidentiality)、信息完整性(Integrity)和信息可用性(Availability)。访问控制主要为信息机密性和信息完整性提供保障。具体来说对软件系统提供如下控制：允许被授权的主体对某些客体的访问；拒绝向非授权的主体提供服务。
RBAC(Role Based Access Control)：基于角色的访问控制模型。访问控制存在多种主流的实现模型，包括自主访问控制，强制访问控制，以及RBAC。在RBAC中，在用户(User)和访问权限(Permission)之间引入角色(Role)的概念，用户与特定的一个或多个角色相联系，角色与一个或多个访问许可权相联系，角色可以根据实际的工作需要生成或取消。RBAC在管理大型网络应用安全时表现出灵活和经济性。
根据对不同复杂度权限的需求，RBAC参考模型定义了三部分组件，分别是：
1.Core RBAC核心角色访问控制模型
2.Hierarchical RBAC分级角色访问控制模型
3.Constraining RBAC强制角色访问控制模型
Core RBAC定义了RBAC模型最基本的五个元素：User人或机器，Role角色，Operations可执行的反映，Objects资源对象，Permissions许可。
User代表人，但是也可以时一台机器，agent，或其他任何智能系统。
Role表示一个工作职责，在一个组织机构环境中的工作职责。该职责可以关联一些关于权力和责任的语义。例如：部门经理，工单维护人员等。
Permission是一个许可，对在一个或多个Objects上执行Operation的许可。我们说，一条数据库记录，这不是权限。删除，这也不是权限。只有“对数据库记录的删除“，才是权限。另外，RBAC标准中定义的权限指正权限。
Operation是程序的可执行的反映，被User调用和执行。Operation的类型取决于实现系统的类型。例如文件系统可能的操作为读写、执行等，数据库系统则是CRUD。
Objects：表示资源对象，任何访问控制机制都是为了保护系统的资源。Objects可能包括文件、目录、数据库表、行、字段等，甚至于磁盘空间、打印机、CPU周期都是资源。
Session：会话。用户每次通过建立会话来激活角色，得到相应的访问权限
RBAC是关系模型，关注点在于角色Role和用户User、许可Permission的关系。称为User Assignment(UA)和Permission Assignment(PA)。关系的左右两边都是Many-to-Many关系。
分层RBACHierarchal RBAC引入了角色继承的概念，约束的RBAC增加了职责关系分离的部分。这两个模型是对Core RBAC的扩展。
CN200410095998.4对保护数据的用户进行识别、认证和授权的方法，通过用户在注册区域的输入字段中输入的用户标识(NAME＝“姓名1”；“姓名2”；“姓名G”；…)识别该用户；将输入的用户标识(NAME)和由该用户输入的密码(PW＝“pw1”；“pw2”；“pwG”；…)组合，并用单向加密函数转换为认证该用户的系统标识(token1，token2，token3…)；至少将系统标识(token1，token2，token3…)以访问标记的形式从注册区域发送到保护区域；通过该发送访问标记授权该用户访问保护区域内的保护数据。
CN200410090408.9提供数据安全的方法和系统，通过使用循环冗余校验提高数据的安全性。使用一个或更多循环冗余校验将数据编码，然后将其从一发射器发送到一接收器。接收器接收编码的数据并将其解码，以使用所述一个或更多循环冗余校验来确定该数据是否由授权的用户发送。
CN200410095998.4对保护数据的用户进行识别、认证和授权的方法，对保护数据的用户、尤其是自动化系统的保护数据的用户进行识别、认证和授权的方法，其中：通过用户在注册区域的输入字段中输入的用户标识(NAME＝“姓名1”；“姓名2”；“姓名G”；…)识别该用户；将输入的用户标识(NAME)和由该用户输入的密码组合，并用单向加密函数转换为认证该用户的系统标识(token1，token2，token3…)；至少将系统标识(token1，token2，token3…)以访问标记的形式从注册区域发送到保护区域；通过该发送的访问标记授权该用户访问保护区域内的保护数据(函数A，函数B，函数C)。
在Core RBAC模型中，如果系统实施细粒度的权限控制，随着访问控制的客体——被管理对象的规模增长，PA(允许指定Permission Assignment)关联数量将会急剧膨胀，带来授权工作的复杂性。另外在模型中没有定义各被管的对象之间的有机联系，无法体现软件系统宏观的结构，不利于分层次引入管理策略。
                            发明内容
本发明目的是：为解决如上问题，现针对Core RBAC模型进行扩展。达到授权工作简单，利于分层次引入管理策略。在被管理对象集中引入“对象维度”的概念，不同维度代表对象不同的分类方式，系统中支持多种分类方式并存。我们把扩展后的模型称为基于角色的多维度对象访问控制技术：MDO-RBAC(Multiple DimensionObjects-Role Based Access Control)。
基于角色的多维度对象访问控制方法：将系统权限划分为数据权限和操作权限。针对数据权限，系统中所有需要受权限控制的数据实体都应该拥有对应的安全管理对象(SecuredObject)，将这些安全对象与不同的角色(Role)关联，即可完成数据权限的划分；在该模型中将安全管理对象进行了分组，支持在同一运行时对系统中的所有安全管理对象进行多种分组方式，每一个分组方式都称之为一个“维度(Dimension)”，而在该维度下的取值，即具体的一个组别，称之为“维度取值(DimensionValue)”；在分组之后，可以在系统中建立角色与维度取值之间的关联，以达成数据权限的分配。
针对操作权限，设有虚拟角色(VirtualRole)，将虚拟角色与操作权限(Permission)关联，可完成对操作权限的分配；同时，在模型中建立虚拟角色与角色之间的多对一的关系，以完成数据权限和操作权限的融合。
模型中的用户(User)最终和角色关联，达到最终的授权效果。
基于角色的多维度对象访问控制方法：即MDO-RBAC为关系型模型，其本身由一些概念和这些概念之间的关联关系组成。该模型将系统权限划分为数据权限和操作权限。针对数据权限，模型认为系统中所有需要受权限控制的数据实体都应该拥有对应的安全管理对象(SecuredObject)，如果将这些安全对象与不同的角色(Role)关联，即可完成数据权限的划分。但是这样的关联关系是复杂而低效的，因此在该模型中将安全管理对象进行了分组，支持在同一运行时对系统中的所有安全管理对象进行多种分组方式，每一个分组方式我们都称之为一个“维度(Dimension)”，而在该维度下的取值，即具体的一个组别，我们称之为“维度取值(DimensionValue)”。在分组之后，可以在系统中建立角色与维度取值之间的关联，以达成数据权限的分配。针对操作权限，模型中提出虚拟角色(VirtualRole)的概念，将虚拟角色与操作权限(Permission)关联，可完成对操作权限的分配。同时，在模型中建立虚拟角色与角色之间的多对一的关系，以完成数据权限和操作权限的融合。模型中的用户(User)最终和角色关联，达到最终的授权效果。
本发明的有益效果：通过引入维度这一中间层，将系统中的被管对象有机组织起来，减少了授权工作量；同时系统可通过不同的分类方式达成灵活多变的管理策略。在被管理对象集中引入“对象维度”的概念，细化被管对象定义。在不同的维度下将被管对象划分为多个组，同时允许组之间的嵌套，形成树状层次关系；不同维度代表对象不同的分类方式，系统中支持多种分类方式并存。本发明将系统权限划分为数据权限和操作权限。针对数据权限，系统中所有需要受权限控制的数据实体都应该拥有对应的安全管理对象(SecuredObject)，将这些安全对象与不同的角色(Role)关联，即可完成数据权限的划分；在该模型中将安全管理对象进行了分组，支持在同一运行时对系统中的所有安全管理对象进行多种分组方式，每一个分组方式都称之为一个“维度(Dimension)”，而在该维度下的取值，即具体的一个组别，称之为“维度取值(DimensionValue)”；在分组之后，可以在系统中建立角色与维度取值之间的关联，以达成数据权限的分配。实现用户与访问权限的逻辑分离和构造角色之间的层次关系，从而方便了数据的安全管理。为实现RBAC在复杂环境中的应用。
基于角色的多维度对象访问控制技术的改进是：即MDO-RBAC为关系型模型，其本身由一些概念和这些概念之间的关联关系组成。该模型将系统权限划分为数据权限和操作权限。针对数据权限，模型认为系统中所有需要受权限控制的数据实体都应该拥有对应的安全管理对象(SecuredObject)，如果将这些安全对象与不同的角色(Role)关联，即可完成数据权限的划分。但是这样的关联关系是复杂而低效的，因此在该模型中将安全管理对象进行了分组，在分组之后，可以在系统中建立角色与维度取值之间的关联，以达成数据权限的分配。针对操作权限，模型中提出虚拟角色(VirtualRole)的概念，将虚拟角色与操作权限(Permission)关联，可完成对操作权限的分配。同时，在模型中建立虚拟角色与角色之间的多对一的关系，以完成数据权限和操作权限的融合。模型中的用户(User)最终和角色关联，达到最终的授权效果。
通过引入维度这一中间层，将系统中的被管对象有机组织起来，减少了授权工作量；授权工作简单，利于分层次引入管理策略。同时系统可通过不同的分类方式达成灵活多变的管理策略。
                            附图说明
图1是本发明应用的软件框图，其结构参见现有技术及说明
图2是用户及用户管理类UML类图
图3是角色、虚拟角色及角色管理类UML类图
图4是权限及权限管理类图UML类图
图5是维度、维度取值、SecuredObject及维度管理类UML类图
图6是支撑功能所表示的类图
图7是权限信息控制逻辑流程图
图8是另一种权限信息控制逻辑流程图
                            具体实施方式
1实施背景：假设现有一交换机监控系统，管理电信网络中的各程控交换机(SWITCH)。系统维护人员可以完成如下操作：
1.交换机状态查询(SWITCH.READ)
2.交换机启动及停止(SWITCH.OPER)
规定管理员(ADMIN)才能够进行查询及启停操作，而普通维护人员(ATTENDANT)仅能够查询交换机状态。在项目的建设中共有4台交换机需要被监控管理：SWITCH1，SWITCH2，SWITCH3，SWITCH4。依据地域的划分，系统将被江苏省公司(JIANGSU)、南京分公司(NANJING)、苏州分公司(SUZHOU)同时维护。其中SWITCH1、SWITCH2归南京分公司维护，SWITCH3、SWITCH4归苏州分公司维护，而省公司可以同时维护这四台交换机。依据部门的划分，规定网发部(DEP.NET)可以维护SWITCH1、SWITCH4，运维部(DEP.RUN)维护SWITCH2、SWITCH3。也就是说，省公司网发部可以对SWITCH1、SWITCH4进行操作，省公司运维部可以对SWITCH2、SWITCH3进行操作；南京分公司网发部可以对SWITCH1进行操作，南京分公司运维部可以对SWITCH2进行操作；苏州分公司网发部可以对SWITCH3进行操作，苏州分公司运维部可以对SWITCH4进行操作。
现使用本发明所使用模型实现上述访问控制各需求。
为实现上述访问控制需求，模型应实现如下几个功能域：
1.管理功能域(Administrative Functions)：创建，管理模型中各元素集合及关系，以建立访问控制的多种组件；
2.支撑功能域(Supporting System Functions)：实现访问控制模型功能，用于当用户与系统进行交互的时候插入访问控制逻辑；
3.检查功能域(Reviews Functions)：检查管理功能的行为结果，包括查询、日志、统计等
在该示例中，我们就管理功能域和支撑功能域进行描述。
4.Administrative Functions：创建，管理元素集合及关系，以建立访问控制的多种组件；
5.Supporting System Functions：实现访问控制模型功能，用于当用户与系统进行交互的时候插入访问控制逻辑；
6.Reviews Functions：检查管理功能的行为结果，包括查询、日志、统计等Administrative Functions
首先应完成各概念的管理，包括各用户、角色等等记录的增删改查等功能，考虑使用数据库实现数据的存储，建表语句如下：
1.用户
CREATE TABLE TC_USER(
    ID        VARCHAR2(32)PRIMARY KEY，
    NAME      VARCHAR2(64)，
    PASSWORD  VARCHAR2(32)，
2.角色
CREATE TABLE TC_ROLE(
    ID                  VARCHAR2(32)PRIMARY KEY，
    TITLE           VARCHAR2(64)，
    DESCRIPTION     VARCHAR2(256)，
    VIRTUALROLEID   VARCHAR2(32)
3.用户角色关联表
CREATE TABLE TC_USER_ROLE(
    USERID VARCHAR2(32)，
    ROLEID VARCHAR2(32)，
    PRIMARY KEY(USERID，ROLEID)
4.虚拟角色
CREATE TABLE TC_VIRTUALROLE(
    ID            VARCHAR2(32)PRIMARY KEY，
    TITLE         VARCHAR2(64)，
    DESCRIPTION   VARCHAR2(256)
5.权限
CREATE TABLE TC_PERMISSION(
    ID       VARCHAR2(32)PRIMARY KEY，
    TITLE    VARCHAR2(64)
6.虚拟角色权限关联表
CREATE TABLE TC_VROLE_PERMISSION(
    VIRTUALROLEID   VARCHAR2(32)，
    PERMISSIONID    VARCHAR2(32)，
    PRIMARY KEY(VIRTUALROLEID，PERMISSIONID)
7.维度
CREATE TABLE TC_DIMENSION(
    ID        VARCHAR2(32)PRIMARY KEY，
    NAME      VARCHAR2(64)，
    TITLE     VARCHAR2(64)
8.维度取值
CREATE TABLE TC_DIMENSIONVALUE(
    ID          VARCHAR2(32)PRIMARY KEY，
    PARENTID    VARCHAR2(32)，
    DIMENSIONID VARCHAR2(32)，
    TITLE       VARCHAR2(64)，
    NAME       VARCHAR2(32)
9.角色维度取值关联表
CREATE TABLE TC_ROLE_DIMENSIONVALUE(
    ROLEID             VARCHAR2(32)，
    DIMENSIONVALUEID   VARCHAR2(32)，
    PRIMARY KEY(ROLEID，DIMENSIONVALUEID)
10.维度取值被管对象关联表
CREATE TABLE TC_DV_SO(
    DVID    VARCHAR2(32)，
    SOID    VARCHAR2(32)
考虑到模型中SevuredObject概念来源于软件系统的各个数据实体，假设各数据实体在数据库中存在记录，可以使用数据库视图来完成SecuredObject的收集，比如系统中需要将交换机(Switch)和端口(PortCode)纳入访问控制，可建立如下视图：
CREATE OR REPLACE VIEW VC_SECUREDOBJECT(ENTITYID，TYPE，TITLE)AS(
    SELECT ID，′SWITCH′，NAME FROM TC_SWITCH
    UNION
    SELECT ID，′PORTCODE′，PORTCODE FROM TC_PORTCODE
    UNION
    SELECT ID，TYPE，TITLE FROM TC_GENERALSO)
TC_GENELRALSO表为SecuredObject的存储提供了通用的解决方式，如果系统中数据实体没有相应数据表，可以将手动配置记录在该表中以纳入管理。CREATE TABLE TC_GENERALSO(
ID    VARCHAR2(32)PRIMARY KEY，
TITLE VARCHAR2(64)，
TYPE  VARCHAR2(32))
Supporting System Functions
用户的授权信息得到记录之后，系统在运行时应完成对用户权限的判断，以实现访问控制模型的功能。可将发出业务操作请求的用户信息与系统中记录的授权信息进行匹配，如果发现请求在记录信息允许的范围之内，则通过；否则失败。
控制过程可分为操作控制和数据控制两步。
1.操作控制
用户请求的业务方法，其方法本身应该知道该方法使用什么Permission来控制用户的请求，因此应该业务方法应该承担起选取合适Permission记录的职责。并委托模型中提供的通用Authorizator完成对权限的判断。
2管理功能域实现
首先应完成模型中各元素的管理，包括各用户、角色、虚拟角色、权限、维度、维度取值等要素记录的增删改查等功能。
2.1类设计
下面给出管理功能域的类设计。类共分为三种，实体类、管理类和数据访问类。实体类为模型中的各个要素；管理类实现了对这些实体类的查询、修改等管理操作，依据其分管范围的不同，管理类罗列如下：
1.UserManager：管理用户的增删改查，管理用户和角色之间的关系分配
2.RoleManager：管理角色的增删改查，管理角色和虚拟角色、角色和维度取值之间的关系分配
3.PermissionManager：管理权限的读取、虚拟角色的增删改查，管理虚拟角色和权限之间的关系分配
4.DimensionManager：管理SecuredObject的查询、管理维度、维度取值的增删改查，管理SecuredObject和维度取值之间的关系分配。
各管理类将数据库原子操作委托给数据访问类实现，这里我们将其称为DAO(数据访问对象)。管理类关注于面向模型的业务操作，并统一协调数据库事务处理。而各DAO关心某一种数据实体的数据库操作，在该示例中以接口形式描述，具体实现可以采用JDBC、ORMapping等方式，由于和本发明没有直接关系，这里不再赘述。
下面以UML类图的方式给出管理功能域相关类的静态设计：
1.图2是用户及用户管理类UML类图
2.图3是角色、虚拟角色及角色管理类UML类图
3.图4是权限及权限管理类图
4.图5是维度、维度取值、SecuredObject及维度管理类
以上各类实现了模型中管理功能域的核心功能，客户端代码可以通过调用各Manager类实现对模型中各要素的查询及修改。同时管理功能域也是支撑功能域的基础，为运行时访问控制提供基本的数据支持。
2.2数据库设计
使用数据库实现模型中各元素的存储，另下面描述的各表中的记录均可以通过客户端代码调用管理功能域提供的API生成。建表语句如下：
1.用户表：记录系统中所有用户
CREATE TABLE TC_USER(
   ID        VARCHAR2(32)PRIMARY KEY，
   NAME      VARCHAR2(64)，
   PASSWORD  VARCHAR2(32)，
2.角色表：记录系统中所有角色
CREATE TABLE TC_ROLE(
   ID             VARCHAR2(32)PRIMARY KEY，
   TITLE          VARCHAR2(64)，
   DESCRIPTION    VARCHAR2(256)，
    VIRTUALROLEID    VARCHAR2(32))
在该示例中角色表应该存在如下各记录：
  ID   TITLE   DESCRIPTION   VIRTUALROLEID
  JIANGSU_NET_ADMIN   江苏网发部管理员   ADMIN
  JIANGSU_NET_ATTENDANT   江苏网发部维护人员   ATTENDANT
  JIANGSU_RUN_ADMIN   江苏运维部管理员   ADMIN
  JIANGSU_RUN_ATTENDANT   江苏运维部维护人员   ATTENDANT
  NANJING_NET_ADMIN   南京网发部管理员   ADMIN
  NANJING_NET_ATTENDANT   南京网发部维护人员   ATTENDANT
  NANJING_RUN_ADMIN   南京运维部管理员   ADMIN
  NANJING_RUN_ATTENDANT   南京运维部维护人员   ATTENDANT
  SUZHOU_NET_ADMIN   苏州网发部管理员   ADMIN
  SUZHOU_NET_ATTENDANT   苏州网发部维护人员   ATTENDANT
  SUZHOU_RUN_ADMIN   苏州运维部管理员   ADMIN
  SUZHOU_RUN_ATTENDANT   苏州运维部维护人员   ATTENDANT
3.用户角色关联表：记录用户和角色之间多对多的关联关系
CREATE TABLE TC_USER_ROLE(
   USERID VARCHAR2(32)，
   ROLEID VARCHAR2(32)，
   PRIMARY KEY(USERID，ROLEID)
4.虚拟角色表：记录系统中所有虚拟角色
CREATE TABLE TC_VIRTUALROLE(
   ID           VARCHAR2(32)PRIMARY KEY，
   TITLE        VARCHAR2(64)，
   DESCRIPTION  VARCHAR2(256)
在该示例中虚拟角色应该存在如下各记录：
  ID   TITLE   DESCRIPTION
  ADMIN   管理员   具有所有操作权限
  ATTENDANT   维护人员   具有查看权限
5.权限表：记录系统中所有权限点
CREATE TABLE TC_PERMISSION(
   ID      VARCHAR2(32)PRIMARY KEY，
   TITLE   VARCHAR2(64))
在该示例中权限表应该存在如下各记录：
  ID   TITLE
  SWITCH.READ   查询交换机状态
  SWITCH.OPER   对交换机启停
6.虚拟角色权限关联表：记录系统中虚拟角色和权限点之间多对多的联系
CREATE TABLE TC_VROLE_PERMISSION(
   VIRTUALROLEID VARCHAR2(32)，
   PERMISSIONID    VARCHAR2(32)，
   PRIMARY KEY(VIRTUALROLEID，PERMISSIONID)
在该示例中虚拟角色权限关联表应该存在如下各记录：
  VIRTUALROLEID   PERMISSIONID
  ADMIN   SWITCH.READ
  ADMIN   SWITCH.OPER
  ATTENDANT   SWITCH.READ
7.维度表：记录系统中所有维度
CREATE TABLE TC_DIMENSION(
    ID       VARCHAR2(32)PRIMARY KEY，
    NAME     VARCHAR2(64)，
   TITLE    VARCHAR2(64)
在该示例中维度表应该存在如下各记录：
  ID   TITLE
  DOMAIN   地域
  DEPART   部门
8.维度取值表：记录系统中所有维度取值
CREATE TABLE TC_DIMENSIONVALUE(
   ID          VARCHAR2(32)PRIMARY KEY，
   PARENTID    VARCHAR2(32)，
   DIMENSIONID VARCHAR2(32)，
   TITLE       VARCHAR2(64)，
   NAME        VARCHAR2(32)
在该示例中维度取值表应该存在如下各记录：
  ID   PARENTID   DIMENSIONID   TITIE  NAME
  JIANGSU   DOMAIN   江苏  JIANGSU
  NANJING   JIANGSU   DOMAIN   南京  NANJING
  SUZHOU   JIANGSU   DOMAIN   苏州  SUZHOU
  NET   DEPART   网发部  NET
  RUN   DEPART   运维部  RUN
9.角色维度取值关联表：记录系统中角色与维度取值之间的多对多的关联关系
CREATE TABLE TC_ROLE_DIMENSIONVALUE(
   ROLEID           VARCHAR2(32)，
   DIMENSIONVALUEID VARCHAR2(32)，
   PRIMARY KEY(ROLEID，DIMENSIONVALUEID)
在该示例中角色维度取值关联表应该存在如下各记录：
  ROLEID   DIMENSIONVALUEID
  JIANGSU_NET_ADMIN   JIANGSU
  JIANGSU_NET_ADMIN   NET
  JIANGSU_NET_ATTENDANT   JIANGSU
  JIANGSU_NET_ATTENDANT   NET
  JIANGSU_RUN_ADMIN   JIANGSU
  JIANGSU_RUN_ADMIN   RUN
  JIANGSU_RUN_ATTENDANT   JIANGSU
  JIANGSU_RUN_ATTENDANT   RUN
  NANJING_NET_ADMIN   NANJING
  NANJING_NET_ADMIN   NET
  NANJING_NET_ATTENDANT   NANJING
  NANJING_NET_ATTENDANT   NET
  NANJING_RUN_ADMIN   NANJING
  NANJING_RUN_ADMIN   RUN
  NANJING_RUN_ATTENDANT   NANJING
  NANJING_RUN_ATTENDANT   RUN
  SUZHOU_NET_ADMIN   SUZHOU
  SUZHOU_NET_ADMIN   NET
  SUZHOU_NET_ATTENDANT   SUZHOU
  SUZHOU_NET_ATTENDANT   NET
  SUZHOU_RUN_ADMIN   SUZHOU
  SUZHOU_RUN_ADMIN   RUN
  SUZHOU_RUN_ATTENDANT   SUZHOU
  SUZHOU_RUN_ATTENDANT   RUN
10.安全管理对象视图：记录系统中所有受访问控制模块管理的被管理对象
考虑到模型中SecuredObject概念来源于软件系统的各个被管理对象，假设各对象在数据库中存在记录，可以使用数据库视图来完成SecuredObject的收集，比如系统中需要将交换机(SWITCH)纳入访问控制，可建立如下视图：
    CREATE OR REPLACE VIEW VC_SECUREDOBJECT(ENTITYID，TYPE，TITLE)AS(

        SELECT ID，′SWITCH′，TITLE FROM TC_SWITCH

        UNION

        SELECT ID，TYPE，TITLE FROM TC_GENERALSO

    )

    CREATE TABLE TC_SWITCH(

      ID   VARCHAR2(32)PRIMARY KEY，

      TITLE VARCHAR2(64)，

    )

    CREATE TABLE TC_GENERALSO(

      ID    VARCHAR2(32)PRIMARY KEY，

      TITLE VARCHAR2(64)，

      TYPE  VARCHAR2(32))
ENTITYID代表系统中该被管理对象的唯一标识；TYPE代表该对象的类型，在这里我们把所有交换机类型对象的类型定义为“SWITCH”；TITLE为其可识别的名字。
TC_GENELRALSO表为SecuredObject的存储提供了通用的解决方式，如果系统中被管理对象没有象交换机那样拥有自己独立的数据表，可以将其记录配置在该表中以纳入管理。注意需要为对象定义合适的类型。
这里我们将交换机信息配置在TC_SWITCH表中，记录如下：
  ID   TITLE
  SWITCH1   交换机1
  SWITCH2   交换机2
  SWITCH3   交换机3
  SWITCH4   交换机4
则视图VC_SECUREDOBJECT中记录为：
  ENTITYID   TYPE  TITLE
  SWITCH1   SWITCH  交换机1
  SWITCH2   SWITCH  交换机2
  SWITCH3   SWITCH  交换机3
  SWITCH4   SWITCH  交换机4
在该示例中TC_GENERALSO表中不需要配置任何数据。
11.维度取值被管对象关联表：记录系统中维度取值与被管理对象之间多对多的关联关系
CREATE TABLE TC_DV_SO(
    DVID      VARCHAR2(32)，
    SOID      VARCHAR2(32)
在该示例中维度取值被管对象关联表应该存在如下各记录：
  DVID   SOID
  JIANGSU   SWITCH1
  JIANGSU   SWITCH2
  JIANGSU   SWITCH3
  JIANGSU   SWITCH4
  NANJING   SWITCH1
  NANJING   SWITCH2
  SUZHOU   SWITCH3
  SUZHOU   SWITCH4
  NET   SWITCH1
  NET   SWITCH4
  RUN   SWITCH2
  RUN   SWITCH3
3支撑功能域实现
用户的授权信息得到记录之后，系统在运行时应完成对用户权限的判断，以实现访问控制模型的功能。我们将这样的功能称为支撑功能域。
在本示例的实现中，我们期望将访问控制介入的逻辑剥离于核心业务逻辑之外，即核心业务逻辑不必关心权限这么一件事。可以通过代理模式实现该目的。类图如图6所示：说明：
1.接口ISwitchService描述了系统提供的业务功能：交换机状态查询(read方法)、交换机启动(start方法)和交换机停止(stop方法)
2.类SwitchManager实现这三个业务方法的逻辑
3.SwitchService织入访问控制逻辑
控制过程可分为操作权限控制和数据权限控制两步。
3.1操作权限控制
SwitchService实现操作权限控制逻辑织入的原理是：对每个需要控制的业务方法进行包装，在执行真正的业务方法之前，根据上下文环境获取调用该用户的身份信息，并根据该业务方法所绑定的权限点进行查找匹配，如果该用户与该权限点具有关联关系，则认为通过操作权限的控制，否则应该抛出权限异常。
这里需要注意的是，用户请求的业务方法，其方法本身应该知道该方法使用什么Permission来控制用户的请求。因此，业务方法应该承担起选取合适Permission记录的职责。
操作权限查找匹配的详细过程由Authorizator组件封装，SwitchService只需收集用户和权限信息，将控制逻辑委托给Authorizator即可。流程如图7所示：
以start()方法为例，典型的SwitchService伪代码如下：
public void start()throws Exception{
   User user=getUserFromContext();
   String permissionId="SWITCH.OPER";
   try{
      authrizator.hasOperationPermission(user,permissionId);
   }catch(PermissionDeniedException e){
      throw e;
   switchManager.start();
Authorizator实现权限控制的具体方法为获取该用户所有角色，并根据角色获取对应的虚拟角色，虚拟角色记录了权限信息，如果在虚拟角色集中最终找到了对应Permission，认为该用户具有该操作权限。伪代码如下：
　　public void hasOperationPermission(User user,String permissionId)<br/>
throws PermissionDeniedException{

　　   Set roles=user.getRoles();

　　   for(Iterator iter=roles.iterator();iter.hasNext();){

　　      Role role=(Role)iter.next();

　　      Set permissionSet=role.getVirtualRole().getPermissions();

　　      if(permissionSet==null)

　　        continue;

　　      for(Iterator iterl=permissionSet.iterator();iterl.hasNext();)<br/>
{

　　        Permission element=(Permission)iterl.next();

　　        if(element.getId().equals(permissionId))

　　            return;

　　            throw new PermissionDeniedException(user,permissionId);
3.2数据权限控制
数据控制同样可以通过包装业务方法来实现。比如当用户请求查询某些被管理对象的时候，可以考虑使用过滤器来将用户不具有数据权限的对象过滤掉：
过滤器应该由各业务模块自行实现，具体流程可以是获取该用户所有角色，判断角色下的DimensionValue的集合，就可以得到SecuredObject的集合，使用该集合作为过滤的依据，在过滤过程中应该注意在同一Dimension下各DimensionValue之间，应该对SecuredObject取并集，在不同Dimension下应该取交集。
对于那些非查询类的业务操作，可以通过类似的匹配方法，判断该用户是否具有对相关对象的权限。匹配的详细过程可以委托给DataAuthorizator实现。
以read方法为例，典型的SwitchService的伪代码如下：
public SwitchStatus read(Switch switch)throws Exception{
   User user=getUserFromContext();
   String securedObjectType="SWITCH";
   try{
      dataAuthorizator.hasDataPermission(user,switchId,securedObjectType);
 }catch(PermissionDeniedException e){
    throw e;return switchManager.read(switch);
dataAuthorizator伪代码如下:
public void hasDataPermission(User user,String soId,String soType)throws
              PemissionDeniedException{
  Set securedObjectsUnderUser=
              dimensionManager.getSecuredObjectsUnderUser(user,soType);
可以看出，DimensionManager封装了获取用户名下所有安全管理对象的逻辑，由于用户可以同时具有一个或多个角色，因此，用户名下所有安全管理对象应该是各角色下安全管理对象的并集。
为了求出某一个角色下所有该类型的被管理对象的集合，必须先将该角色下所有维度取值按照其维度类型进行分组。求出每个维度取值下关联的被管理对象，同组间先取并集，然后各组间取交集。最终得到被管对象集合。

Claims (3)

1、基于角色的多维度对象访问控制方法：其特征是在被管理对象集中引入“对象维度”，细化被管对象定义；在不同的维度下将被管对象划分为多个组，同时允许组之间的嵌套，形成树状层次关系；不同维度代表对象不同的分类方式，系统中支持多种分类方式并存。将系统权限划分为数据权限和操作权限；针对数据权限，系统中所有需要受权限控制的数据实体都应该拥有对应的安全管理对象SecuredObject，将这些安全对象与不同的角色Role关联，即可完成数据权限的划分；在该模型中将安全管理对象进行了分组，支持在同一运行时对系统中的所有安全管理对象进行多种分组方式，每一个分组方式都称之为一个“维度Dimension”，而在该维度下的取值，即具体的一个组别，称之为“维度取值DimensionValue”；在分组之后，可以在系统中建立角色与维度取值之间的关联，以达成数据权限的分配。
2、根据权利要求1所述的多维度对象访问控制方法：其特征是针对操作权限，设有虚拟角色VirtualRole，将虚拟角色与操作权限Permission关联，可完成对操作权限的分配；同时，在模型中建立虚拟角色与角色之间的多对一的关系，以完成数据权限和操作权限的融合。
3、根据权利要求1所述的多维度对象访问控制方法：其特征是模型中的用户最终和角色关联，达到最终的授权效果。
CN 200610085769 2006-06-30 2006-06-30 基于角色的多维度对象访问控制方法 Pending CN1960252A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN 200610085769 CN1960252A (zh) 2006-06-30 2006-06-30 基于角色的多维度对象访问控制方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 200610085769 CN1960252A (zh) 2006-06-30 2006-06-30 基于角色的多维度对象访问控制方法

Publications (1)

Publication Number Publication Date
CN1960252A true CN1960252A (zh) 2007-05-09

Family

ID=38071757

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 200610085769 Pending CN1960252A (zh) 2006-06-30 2006-06-30 基于角色的多维度对象访问控制方法

Country Status (1)

Country Link
CN (1) CN1960252A (zh)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101866360A (zh) * 2010-06-28 2010-10-20 北京用友政务软件有限公司 基于对象多维属性空间的数据仓库鉴权方法及系统
CN102004951A (zh) * 2010-10-29 2011-04-06 西安交通大学 一种基于角色关联的角色组划分方法
CN102063479A (zh) * 2010-12-22 2011-05-18 北京中电普华信息技术有限公司 一种控制数据访问权限的方法和系统
CN102354356A (zh) * 2011-09-29 2012-02-15 用友软件股份有限公司 数据权限管理装置和方法
CN102523330A (zh) * 2011-12-21 2012-06-27 广东步步高电子工业有限公司 基于三维权限级别模型的手机权限管理及验证方法
CN101571858B (zh) * 2008-04-28 2013-06-19 国际商业机器公司 多个对象的安全性设定及检查的方法和装置
CN104112085A (zh) * 2013-04-19 2014-10-22 阿里巴巴集团控股有限公司 一种应用系统集群的数据权限控制方法和装置
CN105095198A (zh) * 2014-04-16 2015-11-25 阿里巴巴集团控股有限公司 一种访问数据实体的方法及装置
CN105426770A (zh) * 2015-11-13 2016-03-23 广东网金控股股份有限公司 面向多维数据的权限管理机制的配置方法及装置
CN105956460A (zh) * 2016-05-12 2016-09-21 浪潮电子信息产业股份有限公司 一种信息安全管理的权限系统
CN106599718A (zh) * 2016-12-09 2017-04-26 中国人民银行清算总中心 信息访问权限的控制方法及装置
CN107292143A (zh) * 2017-06-08 2017-10-24 安徽大智睿科技技术有限公司 一种操作权限与数据权限结合的系统权限管理方法及系统
CN108629166A (zh) * 2018-04-27 2018-10-09 华中科技大学 一种信息系统的用户权限多维度多级管理方法
CN109302373A (zh) * 2017-07-25 2019-02-01 全球能源互联网研究院 一种用于新能源电站通信安全接入的方法及装置
CN112101992A (zh) * 2020-09-10 2020-12-18 拉扎斯网络科技（上海）有限公司 基于多个对象端的对象管理方法及装置

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101571858B (zh) * 2008-04-28 2013-06-19 国际商业机器公司 多个对象的安全性设定及检查的方法和装置
CN101866360A (zh) * 2010-06-28 2010-10-20 北京用友政务软件有限公司 基于对象多维属性空间的数据仓库鉴权方法及系统
CN102004951A (zh) * 2010-10-29 2011-04-06 西安交通大学 一种基于角色关联的角色组划分方法
CN102004951B (zh) * 2010-10-29 2015-05-27 西安交通大学 一种基于角色关联的角色组划分方法
CN102063479A (zh) * 2010-12-22 2011-05-18 北京中电普华信息技术有限公司 一种控制数据访问权限的方法和系统
CN102354356A (zh) * 2011-09-29 2012-02-15 用友软件股份有限公司 数据权限管理装置和方法
CN102354356B (zh) * 2011-09-29 2014-06-04 用友软件股份有限公司 数据权限管理装置和方法
CN102523330A (zh) * 2011-12-21 2012-06-27 广东步步高电子工业有限公司 基于三维权限级别模型的手机权限管理及验证方法
CN102523330B (zh) * 2011-12-21 2014-12-03 广东步步高电子工业有限公司 基于三维权限级别模型的手机权限管理及验证方法
CN104112085A (zh) * 2013-04-19 2014-10-22 阿里巴巴集团控股有限公司 一种应用系统集群的数据权限控制方法和装置
CN105095198A (zh) * 2014-04-16 2015-11-25 阿里巴巴集团控股有限公司 一种访问数据实体的方法及装置
CN105426770A (zh) * 2015-11-13 2016-03-23 广东网金控股股份有限公司 面向多维数据的权限管理机制的配置方法及装置
CN105426770B (zh) * 2015-11-13 2018-05-15 广东网金控股股份有限公司 面向多维数据的权限管理机制的配置方法
CN105956460A (zh) * 2016-05-12 2016-09-21 浪潮电子信息产业股份有限公司 一种信息安全管理的权限系统
CN106599718A (zh) * 2016-12-09 2017-04-26 中国人民银行清算总中心 信息访问权限的控制方法及装置
CN106599718B (zh) * 2016-12-09 2019-04-05 中国人民银行清算总中心 信息访问权限的控制方法及装置
CN107292143A (zh) * 2017-06-08 2017-10-24 安徽大智睿科技技术有限公司 一种操作权限与数据权限结合的系统权限管理方法及系统
CN109302373A (zh) * 2017-07-25 2019-02-01 全球能源互联网研究院 一种用于新能源电站通信安全接入的方法及装置
CN108629166A (zh) * 2018-04-27 2018-10-09 华中科技大学 一种信息系统的用户权限多维度多级管理方法
CN112101992A (zh) * 2020-09-10 2020-12-18 拉扎斯网络科技（上海）有限公司 基于多个对象端的对象管理方法及装置
CN112101992B (zh) * 2020-09-10 2021-09-07 拉扎斯网络科技（上海）有限公司 基于多个对象端的对象管理方法及装置

Similar Documents

Publication Publication Date Title
CN1960252A (zh) 基于角色的多维度对象访问控制方法
CN100351788C (zh) 嵌入式设备的驱动方法
CN1794645A (zh) 基于程序行为的入侵检测方法与系统
CN1280716C (zh) 计算机处理方法、分布式计算方法和网络计算方法
CN1320487C (zh) 许可信息变换装置
CN1115884C (zh) 可编程的呼叫处理系统和方法
CN1220953C (zh) 通过多个外部登记从主登记检索明码口令
CN1020811C (zh) 动态管理输入/输出(i/o)连接的方法和装置
CN1174319C (zh) 数据结构管理装置、数据结构管理系统和方法
CN1783086A (zh) 用于在数据库管理系统中的查询管理的系统和方法
CN1637710A (zh) 用于调度数据处理基础结构中工作单元执行的方法和系统
CN1698033A (zh) 有效管理企业的可配置组件的系统和方法
CN1928840A (zh) 存储装置虚拟化装置的设备控制交接方法
CN1801146A (zh) 用于确定访问控制的方法和装置
CN101080714A (zh) 用于由数据库服务器执行文件操作的基础结构
CN1906600A (zh) 计算实用工具的分级资源管理
CN1788263A (zh) 登录系统和方法
CN1786955A (zh) 用于管理相互相关的数据对象的方法和系统
CN1276575A (zh) 数据库存取系统
CN1437812A (zh) 对设置参数层进行组织及组合以生成与通讯网络相关的实体的整体文件
CN1661511A (zh) 文件管理的系统与装置以及方法
CN1173933A (zh) 建立通信网络数据库的一种方法和设备
CN101052969A (zh) 内容使用装置及内容使用方法
CN1203430C (zh) 数据管理系统和数据管理方法
CN1959569A (zh) 刻蚀机集群控制器

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
EE01 Entry into force of recordation of patent licensing contract

Assignee: LIAN Technology (Nanjing) Co., Ltd.

Assignor: Linkage System Integration Co., Ltd.

Contract fulfillment period: 2009.6.23 to 2027.8.30 contract change

Contract record no.: 2009320001548

Denomination of invention: Multidimension object access control method based on roles

License type: exclusive license

Record date: 2009.8.17

LIC Patent licence contract for exploitation submitted for record

Free format text: EXCLUSIVE LICENSE; TIME LIMIT OF IMPLEMENTING CONTACT: 2009.6.23 TO 2027.8.30; CHANGE OF CONTRACT

Name of requester: LIANCHUANG SCIENCE ( NANJING ) CO., LTD.

Effective date: 20090817

ASS Succession or assignment of patent right

Owner name: LIANCHUANG SCIENCE ( NANJING ) CO., LTD.

Free format text: FORMER OWNER: NANJING LIANCHUANG SCIENCE CO., LTD.

Effective date: 20091211

C41 Transfer of patent application or patent right or utility model
TA01 Transfer of patent application right

Effective date of registration: 20091211

Address after: 16 F, 12 Huai gate, Nanjing City, Jiangsu Province, China: 210013

Applicant after: LIAN Technology (Nanjing) Co., Ltd.

Address before: 16 F, 12 Huai gate, Nanjing City, Jiangsu Province, China: 210013

Applicant before: Linkage System Integration Co., Ltd.

C12 Rejection of a patent application after its publication
RJ01 Rejection of invention patent application after publication

Open date: 20070509