基于岗位抽象的角色权限控制模型设计与实现

合集下载

基于RBAC模型权限管理的设计与实现

基于RBAC模型权限管理的设计与实现

基于RBAC模型权限管理的设计与实现【摘要】对RBAC模型分析和研究的基础上,对RBAC模型进行了改进,设计了可以同时对角色和用户进行授权的更灵活的权限管理模型,满足了企业多样化的授权管理需要。

【关键词】RBAC;权限;角色RBAC(Role—Base Access Control)模型[1—2]是目前最为广泛接受和使用最广泛的权限模型,该模型是基于角色进行授权的,虽然授权的机制很好,但有时候却不太符合国内的实际情况,特别是某些企业的管理不太规范的情况下。

在实际项目中,不仅仅对角色授权,还要支持直接对用户单独授权。

当然对用户的授权可以通过创建一个不存在的角色通过对角色的授权来实现,但用户往往不太赞同,同时会造成角色迅速膨胀,就出现了针对用户进行授权的需求,在实际操作宗也往往采用直接对用户进行授权。

这样一来,就需要对RBAC再次进行扩展来满足需要。

在本系统的开发中,就采用了针对角色授权和针对用户授权相结合的方式来进行。

该模型既不是特别简单也不特别复杂,忽略了很多概念也创建了很多概念,它能比较灵活的实现授权的灵活度,能够适应不太规范的企业,克服了RBAC模型只能对角色进行授权的缺点。

1.权限管理的设计1.1对象及权限定义利用基于角色的访问控制进行用户权限设定时,首先要进行的就是确定系统对象及对对象的访问权限,实际上就是对系统资源的访问权限。

这里的对象指系统中各种功能模块、数据、操作等等,是主体能访问的各种对象。

由于对象的机密情况及所属单位的不同,能对他们操作的用户也不相同。

1.2角色定义与权限分配(1)角色定义基于角色的访问控制方法就是用角色来充当用户行使权限的中介,对角色进行授权,为用户分配角色,就等于把角色的权限分配给用户,这样,用户与角色之间以及角色与权限之间就形成了两个多对多的关系[3],即一个用户可以拥有多个角色,一个角色也可以供多个用户使用。

即如果某个用户拥有角色M的同时还拥有N的角色,即双重甚至多重角色,那么在默认的情况下,系统会为该用户分配角色M和角色N拥有的所有权限,它的权限为两个角色的权限的合集。

基于岗位抽象的角色权限控制模型设计与实现

基于岗位抽象的角色权限控制模型设计与实现

基于岗位抽象 的角色权 限模型l
—= == = == == [ == == = == _一
薹 型塑塑笪望
堡 筻堡
蓉 操人 角 岗 岗权l 模l 畚l I 曩 里 奎日 l l I l J
理l理 理j 理 I 权 理1是I岗 理 I 理I 理l l
被授 权 客 体 或 资 源 执 行 某 种 操 作 , 保 障 系 统 安 全 不 可 或 是
效 地 弥 补 了传 统 R A B C的 不 足 。
骤 简单 。 主要 优 点 如 下 : 引 入 了 “ 位 ” 念 , 拟 现 实 ① 岗 概 模
2 基 于 岗 位 抽 象 的 角 色 权 限 控 制 模 型
2 1 模 型 定 义 .
中 的 岗位 机 制 , 于理 解 , 于操 作 ; 易 便 ②权 限定 义 为模 块 与 操 作 的 二元 组 , 仅 实 现 了页 面 级 别 的 访 问控 制 , 且 实 不 而
摘 要 : 通过 对传统访 问控 制技 术及其局 限性 的探讨 , 出了全新的基 于岗位抽 象的 角色权限控制模型 , 提 画出了新模
型 的 图 示 , 绍 了新 模 型 中“ 户定 岗” 岗位 授 权 ” 个 主 要 关 系 , 述 了 新 模 型 的 优 点 。详 细 地 阐述 了 实现 新 模 介 用 和“ 两 阐
第1 卷 第 1 l 期
2 1年 1 02 月
软 件 导 刊
S0fwa e Gui e t r d
Vo11 0 1 . 1N . J n. 0l a 2 2
基 于 岗位 抽 象 的角 色 权 限控 制模 型 设计 与实现
王 伟 全 张 学平 ,
( . 南 医学 院 网络 管理 中心 , 南 海 口 5 1 0 ;. 南师 范大 学 信 息科 学与技 术 学院 , 1海 海 7 1 12 海 海南 海 口 5 1 5 ) 7 1 8

角色权限定位系统的设计与实现

角色权限定位系统的设计与实现


—~

















—,
图 3: “协 同” 内 容展 示
的 问题 是 , 盘【J果系 统 中 的 流 程 没 有 及 时 闭环 或 i“锚 ,领 导 难 以对 相 关 责任 人进 行 追 责 。
因 以 f:一 系 列 的 问 题 , 导致 供 电 局 管 理 层 亟 须 一套 角 色权 限 定 位 系 统 ,能 够 根 据 基层 单 位 实 际情 况 量 身 定 制 业 务 流 程 表 单 . 细 化 基 层 供 电所 系 统 权 限 的 本 地 化 配 置 , 明 晰 基 层 供 电 所每 位员J:的工作职 责和 系统中的角色权限 。 同时能够对 工 个人量 身定制 个人工作表单 , 明 确 个 人 f:作 内 容 ,助 员 工 掌 握 各 业 务 流 程 环
EM PL0YEE、 流 程 节 点 表 SYS NODE、 人 员 与节 点 的 对 应 衷 MAP EMP2NOD,针 对 前 两 者与后者分别配置 了主 外键 约束和级联删除 。
系 统 从 功 能 上 主 要 划 分 为 三 大 模 块 , 分 别 是总 表 、 分 表 以及 统 计 分 析 。总 表 展 示 的 是 单位或部 门的业务流程表单 ,分表 呈现了员工 个人的工作 内容表单 ,统计 分析则根据总表 、 分表的数据汇总 、提炼 出有参 考意义的 、可供 决 策 的 信 息 。
一 体 化 系 统 体 量 庞 大 , 功 能 复 杂 。 新 入 企 员 T 或 转 岗 员:【:一开 始 接 触 系 统 应 用 时 往 往
配电班 班品

基于角色权限管理:rbac设计分析以及具体细节

基于角色权限管理:rbac设计分析以及具体细节

基于⾓⾊权限管理:rbac设计分析以及具体细节权限管理---设计分析以及具体细节说起权限我们⼤家都知道,不⼀样的⾓⾊会有不⼀样的权限。

⽐如就像学⽣管理系统⼀样,管理员,⽼师,学⽣之间的权限都是不⼀样的,那么展⽰的页⾯也是不⼀样的。

所以,我们现在来看看具体操作。

⽬标:⽣成⼀个独⽴的组件,到哪都能⽤!(是不是很厉害)步骤⼀、先创建⼀个项⽬,建⽴⼀个app01和rbac的应⽤⼆、表结构的设计 1、先看配置⽂件合适不,给创建的rbac在配置⽂件⾥⾯设置⼀下 找到INSTALLED_APPS=['rbac'] 2、表结构设计 models中创建类:五个类,七张表 ⾓⾊表: ⽤户表: 权限表: 权限组表: 菜单表: ⾓⾊表和权限表是多对多的关系(⼀个⾓⾊可以有多个权限,⼀个权限可以对应多个⾓⾊) ⽤户表和⾓⾊表是多对多的关系(⼀个⽤户可以有多个⾓⾊,⼀个⾓⾊有多个⽤户) 所以有会多⽣成两张关系表 ⼀个菜单下⾯有多个组 ⼀个组下⾯有多个菜单 ⼀个菜单下⾯有多个权限from django.db import models# Create your models here.class Role(models.Model):title = models.CharField(max_length=32,verbose_name="⾓⾊")permissions = models.ManyToManyField(to="Permission",verbose_name="拥有权限的⾓⾊",blank=True) #权限和⾓⾊是多对多的关系def__str__(self):return self.titleclass Meta:verbose_name_plural = "⾓⾊表"class Permission(models.Model):title = models.CharField(max_length=32,verbose_name="权限名")url = models.CharField(max_length=32,verbose_name="带正则的url")codes = models.CharField(max_length=32,verbose_name="代码")group = models.ForeignKey(to="Group",verbose_name="所属组",blank=True) #组和权限是⼀对多的关系,⼀个组有多个权限menu_gp = models.ForeignKey(to='Permission',related_name='aaa',null=True,blank=True,verbose_name="组内菜单")def__str__(self):return self.titleclass Meta:verbose_name_plural = "权限表"class UserInfo(models.Model):name = models.CharField(max_length=32,verbose_name="姓名")password = models.CharField(max_length=64,verbose_name="密码")email = models.CharField(max_length=32,verbose_name="邮箱")roles = models.ManyToManyField(to="Role",blank=True) #⽤户和⾓⾊是多对多的关系def__str__(self):return class Meta:verbose_name_plural = "⽤户表"class Group(models.Model):title = models.CharField(max_length=32,verbose_name="组名称")menu = models.ForeignKey(to="Menu",verbose_name="组内菜单",blank=True) #⼀个组下有多个菜单def__str__(self):return self.titleclass Meta:verbose_name_plural = "权限组"class Menu(models.Model):caption = models.CharField(max_length=32,verbose_name="菜单")def__str__(self):return self.captionclass Meta:verbose_name_plural = "菜单表"为什么要多加个code列和权限组表呢?1、我们⼀般是先看到的是列表页⾯,在这个页⾯上是否显⽰添加,是否显⽰编辑,是否显⽰删除,都是需要判断的有⽆添加权限,有⽆删除权限,有⽆编辑权限,我们可以给每⼀个url⼀个代号dict = {1:{ 代号 /userinfo/ list /userinfo/add/ add /userinfo/del(\d+)/ del /userinfo/edit(\d+)/ edit } }不仅在列表页⾯需要知道他有那些权限,在其他页⾯也知道他有那些权限所以上⾯的⽅案还是有点不好,那么我们采取下⾯的⽅案。

基于RBAC的通用权限管理设计与实现

基于RBAC的通用权限管理设计与实现

基于RBAC的通用权限管理设计与实现
一.引言
RBAC(Role-Based Access Control)是一种基于角色的访问控制模型,它试图通过将用户分配到不同的角色来简化系统管理员的工作,提高系统
安全性、可用性、可维护性等。

目前,RBAC已经成为最重要的安全管理
技术之一,在企业级应用系统中使用得越来越多。

本文将介绍基于RBAC的通用权限管理设计与实现,专注于实现RBAC
模型的原理和实现方式,并结合实际应用,分析实现过程中可能遇到的问
题与解决方案,从而为设计RBAC权限管理系统提供参考。

二.RBAC原理
RBAC模型的核心思想是,将用户分配到不同的角色,通过对角色进
行权限的分配和控制来控制用户的访问权限。

关于RBAC的实现有以下几个步骤:
1、划分角色:首先,要把用户划分成不同的角色,每一个角色都有
一系列可以被执行的操作,这些操作可以是其中一种操作,也可以是一系
列的操作。

2、分配权限:然后,将每个角色对应的操作权限分配给角色,这些
权限可以是可执行的操作,也可以是可读写的操作,可以是可访问的文件,也可以是其中一种权限。

3、赋予用户角色:接下来,将角色分配给具体的用户,这样就可以
实现用户与角色之间的关联,也实现了对不同的用户可以访问不同的权限。

基于角色的访问控制系统设计与实现

基于角色的访问控制系统设计与实现

基于角色的访问控制系统设计与实现角色是访问控制系统中的重要概念之一,它用于定义用户、员工或其他实体在组织内的职责和权限。

基于角色的访问控制系统提供了一种有效管理和控制用户访问权限的方法,并且可以适应组织的变化和扩展。

本文将介绍基于角色的访问控制系统的设计和实现,并探讨其在不同场景中的应用。

首先,基于角色的访问控制系统设计需要明确定义角色的层次结构和权限。

角色的层次结构可以根据组织的结构和职责划分,例如高级管理人员、普通员工和访客等。

每个角色都有一组预定义的权限,这些权限指定了用户可以执行的操作。

在设计阶段,需要详细描述每个角色的职责和权限,以确保用户得到适当的访问权限。

其次,基于角色的访问控制系统的实现需要考虑身份验证和授权。

身份验证确保用户的身份得到验证,通常使用用户名和密码等凭据进行验证。

授权是根据用户的身份和角色来确定其访问权限的过程。

在实现阶段,需要选择合适的身份验证和授权机制,例如单一登录(SSO)和访问令牌等。

这些机制可以提高系统的安全性和用户体验。

此外,基于角色的访问控制系统还需要定义访问策略和审计机制。

访问策略规定了用户在执行操作时必须满足的条件,例如时间、地点和设备等。

审计机制用于记录用户的访问和操作行为,以便进行安全审计和追踪。

在设计和实现过程中,需要仔细考虑访问策略和审计机制的需求和实际情况,以确保系统的安全性和合规性。

基于角色的访问控制系统在不同的场景中有着广泛的应用。

例如,企业可以使用基于角色的访问控制系统来管理内部员工的权限,确保只有具备相应角色的员工可以访问敏感信息和关键系统。

在医疗保健领域,基于角色的访问控制系统可以帮助医生和护士等医疗人员根据其职责和权限访问患者的电子健康记录。

此外,基于角色的访问控制系统还可以用于对外提供服务的组织,例如银行和电子商务网站,以确保用户只能访问其授权的内容和功能。

在实际应用中,基于角色的访问控制系统还可以与其他安全技术和机制结合使用,以提高系统的安全性和灵活性。

基于岗位抽象的角色权限控制模型设计与实现

基于岗位抽象的角色权限控制模型设计与实现作者:王伟全张学平来源:《软件导刊》2012年第01期摘要:通过对传统访问控制技术及其局限性的探讨,提出了全新的基于岗位抽象的角色权限控制模型,画出了新模型的图示,介绍了新模型中“用户定岗”和“岗位授权”两个主要关系,阐述了新模型的优点。

详细地阐述了实现新模型的关键技术,给出了新模型的总体结构图和总体类图,并对总体类图中的各个类及其关系进行了详细的说明。

最后,总结了新模型的实用性及其推广应用价值。

关键词:RBAC;岗位;岗位互斥;定岗;授权中图分类号:TP311.52 文献标识码:A 文章编号:1672-7800(2012)001-0107-1 传统访问控制技术及其局限性访问控制实质上是对资源使用的限制,决定主体是否被授权客体或资源执行某种操作,是保障系统安全不可或缺的重要组成部分。

目前,主要有3种不同类型的访问控制:自主访问控制(DAC)、强制访问控制(MAC)和基于角色的访问控制(RBAC)。

自主访问控制(DAC)是目前计算机系统中实现最多的访问控制机制,如Windows操作系统。

强制访问控制(MAC)是强加给访问主体的,即系统强制主体服从既定的访问控制策略,主要应用于军事方面。

这两种访问控制方式都只适用于特定的领域,具有一定的局限性。

基于角色的访问控制(RBAC)引入了角色的概念,在授权主体和客体之间增加的角色这个中间层,实现了主客体的逻辑分离,具有一定的通用性。

但RBAC在实际的应用中仍然存在一些问题,如:角色的继承机制有缺陷,会造成某些角色的权限过大;权限定义较模糊、笼统,不够清晰;无法满足“同角色不同人员不同权限”的需求。

基于上述原因,本文提出一种扩展的RBAC新模型,引入了“岗位”概念,有效地弥补了传统RBAC的不足。

2 基于岗位抽象的角色权限控制模型2.1 模型定义新模型是在传统RBAC模型基础上引入“岗位”概念,模拟现实中的岗位管理制。

其基本思想是:机构与角色结合形成岗位,模块与操作结合形成权限,先将权限赋给岗位(授权),再将人员指派到岗位(定岗),实现对系统资源的细粒度访问控制。

权限约束支持的基于角色的约束访问控制模型与实现

授权时 , 它是受控对象的一个子集 .
R ( 角色集) 指一个角色的属性既包括角色应具有的权
限 ( ep) , 也包括角色与角色之间的约束关系 . 在大部分系统 中 , 角色 ( r) 本身也是一个受控对象 ( co) .
PA ( 权限分派) 表示建立权限与角色的关系 , 即将权限
其元素简称客体 .
[ 2001/ 1/ 1 , 2001/ 2/ 1 ]) , 并可以将它授予相应的角色 .
其中 , R C T M 指角色互约束类型集 , R C TS 指角色自约束类
4期
韩伟力等 : 权限约束支持的基于角色的约束访问控制模型与实现
335
型集 .
EPEPCI R ules ( EP2EP 约 束 传 递 规 则 集 ) . epeprule ∈ EPEPCI R ules :2
见问题 ( 如普通用户授权问题) . 此外 ,在 RBAC96 模型中 ,安
1 引 言
分布式系统中多用户对多对象的访问控制一直是系统 安全管理的研究热点 . 文献 [ 125 ] 提出的基于角色的访问控 制模型能较好地解决这一问题 . 它们将受控对象的访问权限 授予某个角色 ,然后再对控制主体分派这个角色 , 从而使控 制主体得到受控对象的访问权限 ,大大简化了分布式系统的 授权操作和安全管理 . 然而 ,现有的基于角色的约束访问控 制模型存在着许多不足 .
( 浙江大学计算机科学与工程学系 杭州 310027)
摘 要 阐述现有基于角色的安全控制中的不足 ,通过分析角色间约束产生的根源 ,提出通过建立权限约束关系来 支持角色之间的约束管理和实现访问控制 . 文中定义了权限约束支持的基于角色的约束访问控制模型及增强权限 模型 ,并介绍这个约束访问控制模型在 ZD2PDM 中的应用 . 实践表明 ,这种访问控制模型除了增强系统安全访问之 外 ,还可以提供一种更灵活的授权机制 ,并降低安全管理员的工作复杂性 . 关键词 约束访问控制 ,基于角色的访问控制 ,权限约束 ,产品数据管理 中图法分类号 TP309. 2

基于角色访问控制的通用权限管理方案设计与实现


根 据 上 文 对 远 程 教 育 系 统 模 式的分 析 ,系 统 中会 包
含: ( 1 )教 师实体 :教工 号 、姓名 、性 别 、职称 、 联系 电
话 、E - m a i l 、讲 授的课程 。 ( 2 )学生 实体 :学号 、姓 名 、性 别 、年 龄 、联系 电话 、E - m a i l 。 ( 3 )课 程实体 :课程 编号、 课 程 名称 、 章节数 。 ( 4 )考 试实 体 :考试 编号 、学 号 、课 程 编 号 、考 试 时 间 、考 试 成 绩 、批 改人 。 ( 5 )管 理 员 实 体 :编 号、帐 号、姓名 、性别 、E ma i l 、联 系 电话 。 ( 6 )教 学 资源实体 :资源 编号 、课 程编 号、标题 、制作者 。 通 过 以上 对 数据 库 的 具体 分 析 ,在远 程 教 育系 统 中 需 要 建立 :教 师信 息 数 据库 、学生 信 息 数据 库 、教 学 资源 管 理数 据 库和 考试 数 据库 。 2 实现远 程 教 育 系统 的关键 技术 2 . 1 HT M 语 言 设 计 用 户 界面 。HTML ( Hy p e r T e x t Ma r k u p L a n g u a g e )及 超文 本 语 言, 网页 一般 运用 这种 超文 本 标 识语 言来 编排 页 面 格 式 。H T ML 文 件 是 一种 自带专 属 于H T ML 控件 的用 于 编排 文 档 格 式属 性 的标 准 文 本 文件 。
爨 蠹
软 件 设 计 应用 研发 0
心基 础 是 存储 有 教 师 学生 信 息和 教 学资 源 的数 据 库 ,数 据 库 也是 远程 教 育 系统 的各个 部 分 能不 能 完美 结 合 到一 起 的

基于Spring框架的角色权限控制系统的设计和实现

至三塑堡矍塑堕鱼堡堡丝塑竺盟墼盐兰壅翌3.2面向方面编程是面向对象编程的延续软件工程师们逐步认识到,传统的程序经常表现出一些不能自然地适合单个程序模块或者几个紧密相关的程序模块的行为。

例如日志记录、对上下文敏感的错误处理、性能优化以及安全处理等等、我们将这种行为称为“横切关注点(crosscuttingconcern)”,因为它跨越了给定编程模型中的典型职责界限。

因为横切行为的实现是分散的,开发人员发现这种行为难以作逻辑思维、实现和更改。

这些类似于日志,权限控制,安全处理,持久化的需求具有如下的特点”“”j:不是这个类所要完成的主要任务,和业务逻辑关系不大。

日恚之类的需求的实现方法和镱略和业务逻辑是独立的,不耦合的。

日志这类操作分散在整个系统中,系统中会有很多个类受到这个类的影响。

如果把系统看作一批关注点我们可以把一个复杂的系统看作是由多个关注点来组合实现的。

一个典型的系统可能会包括几个方面的关注点,如业务逻辑、性能,数据存储、日志和调度信息、授权、安全、线程、错误检查等,还有开发过程中的关注点,如易懂、易维护、易追查、易扩展等。

图3.1演示了由不同模块实现的一批关注点组成一个系统【”。

图3.1在业务逻辑模块中包含各种关注Fig,3.1Cohere-har.oraainadinbusinesslogicmodules当前方法学实现横切关注点是不好的。

它会带来一些问题,我们可以大致把这些问题分为两类。

代码混乱:软件系统中的模块可能要同时兼顾几个方面的需要。

举例来说,开发者经常要同时考虑业务逻辑、性能、同步,日志和安全等问透.兼顾各方面的需要导致相应关注点的实现元素同时出现,引起代码混乱。

从而可以根据“是自己的资源”这个等价关系对所有的资源集合进行等价类的划分。

那么对于任何一个用户,所有的资源都可以分为两个互斥的等价类,自己的资源和别人的资源。

同样,对于所有的评论的集合,也可以类似的划分为“自己评论自己”,“自己评论别人”,“别人评论自己”和“别人评论别人”四个互斥的等价类。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

基于岗位抽象的角色权限控制模型设计与实现
摘要:通过对传统访问控制技术及其局限性的探讨,提出了全新的基于岗位抽象的角色权限控制模型,画出了新模型的图示,介绍了新模型中“用户定岗”和“岗位授权”两个主要关系,阐述了新模型的优点。

详细地阐述了实现新模型的关键技术,给出了新模型的总体结构图和总体类图,并对总体类图中的各个类及其关系进行了详细的说明。

最后,总结了新模型的实用性及其推广应用价值。

关键词:RBAC;岗位;岗位互斥;定岗;授权
1 传统访问控制技术及其局限性
访问控制实质上是对资源使用的限制,决定主体是否被授权客体或资源执行某种操作,是保障系统安全不可或缺的重要组成部分。

目前,主要有3种不同类型的访问控制:自主访问控制(DAC)、强制访问控制(MAC)和基于角色的访问控制(RBAC)。

自主访问控制(DAC)是目前计算机系统中实现最多的访问控制机制,如Windows操作系统。

强制访问控制(MAC)是强加给访问主体的,即系统强制主体服从既定的访问控制策略,主要应用于军事方面。

这两种访问控制方式都只适用于特定的领域,具有一定的局限性。

基于角色的访问控制(RBAC)引入了角色的概念,在授权主体和客体之间增加的角色这个中间层,实现了主客体的逻辑分离,具有一定的通用性。

但RBAC在实际的应用中仍然存在一些问题,如:角色的继承机制有缺陷,会造成某些角色的权限过大;权限定义较模
糊、笼统,不够清晰;无法满足“同角色不同人员不同权限”的需求。

基于上述原因,本文提出一种扩展的RBAC新模型,引入了“岗位”概念,有效地弥补了传统RBAC的不足。

2 基于岗位抽象的角色权限控制模型
2.1 模型定义
新模型是在传统RBAC模型基础上引入“岗位”概念,模拟现实中的岗位管理制。

其基本思想是:机构与角色结合形成岗位,模块与操作结合形成权限,先将权限赋给岗位(授权),再将人员指派到岗位(定岗),实现对系统资源的细粒度访问控制。

如图1所示:
图 1 基于岗位抽象的角色权限图 2 基于岗位抽象的角色控制模型权限模型总体结构
新模型中包含的主要关系:
用户定岗:为用户指派岗位,受岗位基数约束,当岗位基数大于1时是用户与岗位之间是多对多的关系。

岗位授权:将权限赋给岗位,岗位和权限之间是多对多的关系。

新模型中定义的约束:岗位互斥关系(Mutually Exclusive Posts):用于指定两个岗位具有不同的职责,不能让同一个用户同时拥有。

岗位基数限制(Post Cardinality Constraints):用于指定一个岗位可被同时授权的数目。

比如一个学校的校长只能由一个用户担任,那么这个学校校长岗位的岗位基数就为1。

2.2 模型优点
基于岗位抽象的角色权限控制模型以“人员定岗”、“岗位授权”为核心,权限访问控制整个过程逻辑清晰、步骤简单。

主要优点如下:①引入了“岗位”概念,模拟现实中的岗位机制,易于理解,便于操作;②权限定义为模块与操作的二元组,不仅实现了页面级别的访问控制,而且实现了功能(按钮)级别的访问控制,即能将访问权限限制到某个用户对某个模块的某个具体操作;③机构与角色结合形成岗位,通过岗位授权、人员定岗控制访问权限,有效地解决了RBAC 中“同角色不同人员不同权限”这一问题,遵循了最小特权原则。

3 基于岗位抽象的角色权限控制模型实现
3.1 实现模型的关键技术
3.1.1
是一种将各种Web元素组合在一起的服务器技术,是一个统一的Web开发平台,用来提供开发人员生成企业级Web 应用程序所需的服务。

完全基于模块与组件,是一种建立在公共语言运行时CRL基础之上的程序开发架构,具有很好的可扩展性与可定制性。

开发人员可以方便利用其托管的公共语言运行库环境、类型安全、继承等,有效缩短Web应用程序的开发周期。

3.1.2 Ajax
Ajax全称为“Asynchronous JavaScript and XML”(异步JavaScript和XML),结合了XML、JavaScript等编程技术,是一种创建交互式网页应用的网页开发技术。

Ajax以一种崭新的方式来使用所有的这些技术,实现异步交互无刷新,使得基于B/S模式的传统
Web开发焕发了新的活力,大大改善了用户体验。

3.2 模型总体结构图
为了使基于岗位抽象的角色权限模型更加清晰、更易操作和管理,特将其分为基础数据管理和权限管理两大部分,总体结构图如图2所示。

3.3 模型总体类图及说明
图3 基于岗位抽象的角色权限模型总体类图
Department:机构,使用系统的组织机构,Department具有树形层次关系。

Role:角色,表示用户在一个机构中担任的职务。

例如:学校机构中,校长、教师、学生都是角色。

Post:岗位,是(Department,Role)的二元组,直接映射现实中的岗位。

例如:海南师范大学校长、计算机科学与教育技术系主任都是岗位。

一个岗位可以有一个或多个Person,一个Person可以指派到一个或多个岗位上。

OpposePost:互斥岗位,不能同时指派给某一个用户的两个岗位为互斥岗位。

例如在银行系统中,一个用户不能同时为出纳员和审计员。

UserGroup:表示User的组织关系,UserGroup是具有树形层次关系的。

一个Person可以属于多个UserGroup,一个UserGroup可以包含多个用户。

Resource:功能模块,系统中的功能页面。

通常是在系统设计阶段就定义好的,客户不可以自行修改的。

Operate:操作,可简单理解为数据的增、删、改、查等操作,一个Operate本身没有任何意义,只有与Resource结合起来才有意义。

Permission:权限,是(Resource,Operate)二元组,用户在系统中的任何操作都可以被定义为权限,例如:增加用户、删除日志都是不同的权限。

4 结束语
基于B/S模式的管理信息系统面临着日益复杂的数据资源安全管理难题,基于岗位抽象的角色权限控制模型引入了岗位概念,实现了用户与访问权限的逻辑分离和构造角色之间的层次关系,达到了细粒度的权限控制。

该权限控制模型已经成功地应用于管理信息系统的设计和开发实践中,集成性良好。

实践表明,该权限控制模型具有权限分配直观、容易理解、便于使用、扩展性好、支持岗位管理、权限多变等优点,具有很强的实用性和可重用性。

参考文献:
[1]普继光.基于角色的访问控制系统的设计和应用[D].成
都:电子科技大学,2004.
[2]王电化.基于角色访问控制的研究[D]. 天津:天津工业大学,2005.
[3]胡勇辉,曹倬瑝,兰湘涛,等开发实战详解[M].北京:电子工业出版社,2006.
[4][英]克拉恩,帕斯卡雷洛,杰姆斯.Ajax实战[M].北京:人民邮电出版社,2006.
[5]盛蕾,方华.基于的四层Web应用模型设计与实现[J].计算机与数字工程,2006(7).
[6]刘萍.基于角色的访问控制(RBAC)及应用研究[D].成都:电子科技大学,2004.。

相关文档
最新文档