基于用户权限

基于用户权限（通用7篇）

基于用户权限 篇1

摘要：在信息系统中使用DBMS的用户身份验证方法可以提高信息系统的安全性。验证方法的改变影响了用户的权限管理过程,信息系统既需要进行系统前端功能权限管理,也需要进行后端数据库权限的管理。使用模块级的数据库角色管理用户的数据库权限,可以减少用户的数据库权限授权的工作量并保持授权的准确性,同时保持与前端的功能权限管理的一致性。可把数据库角色的原理应用到前端功能权限的管理,实现控件级的授权和用户访问控制。

关键词：DBMS验证,权限管理,模块级数据库角色,功能角色,访问控制

0 引言

目前很多信息系统的用户身份验证由信息系统本身进行验证,所有用户的密码保存在表中,而对后端数据库的操作使用同一数据库用户帐号进行连接和使用。从实现难度来看,这种解决方案简单而方便,但它在安全性上却有问题。首先是如何保存用于连接数据库的用户帐号的密码。如果密码写在程序中则不仅信息暴露,而且也不容更改密码;如果隐藏在注册表或文件系统的某个角落,不仅隐患依然存在,而且当隔了一段时间需要更改密码时,要在许多客户端进行相同的更改操作还会造成系统的维护性问题。其次,保存在表中的用户密码会产生安全问题,即使进行了加密也仍有安全漏洞,系统管理员可以在数据库表中用已知明文密码的用户(如管理员新建的用户)的加密后的密码串替换任何其他用户加密后的密码串,然后用已知用户的明文密码冒充其他业务人员进入系统进行业务操作。因此对于安全性要求高的信息系统需要寻求安全性更高的解决方案。

1 DBMS验证方式及其权限管理的特殊性

IT人员操作数据库的过程通常是这样:首先启动数据库管理系统(DBMS)的客户端程序,接着输入数据库用户的帐号和密码,然后连接数据库,在连接成功后通过数据库管理系统的客户端操作数据库。在这个过程中,数据库用户的密码不需保存,用户自行记住自已的密码,其他人无法知道。

信息系统中用户身份验证也可使用这种方式,即把用户身份的合法性验证交由数据库管理系统进行验证,可称为DBMS验证方式。实现过程是:对于每个使用信息系统的用户,不仅建立信息系统的用户帐号,而且在后端的数据库中也各自建立数据库用户帐号,信息系统中仅保存用户ID,不存储用户的密码。用户登录信息系统时,信息系统获取用户输入的用户ID和密码,用这些用户信息来设置连接对象的用户名和密码属性,然后使用连接对象连接数据库,如果连接成功,则表明登录信息系统的用户是合法的,允许用户使用信息系统,否则是非法的用户,拒绝其进入信息系统。

DBMS验证方式提高了信息系统的安全性,但也带来了用户权限管理的复杂性。在DBMS验证方式下,用户的权限管理不仅有用户对信息系统的功能模块的使用权限问题,而且还有对后端数据库中的数据库对象的使用权限问题。

2 后端数据库的权限管理

与前端的信息系统的功能权限的管理相比,数据库权限管理要复杂得多,因此如果把数据库对象的权限直接授权到用户,则当使用信息系统的用户数比较多时,将带来很大的权限管理负担。因此通过数据库角色来管理用户的数据库权限几乎是必然的选择。

使用数据库角色管理用户的数据库权限面临的问题是数据库角色权限粒度多大合适,这可通过考察信息系统的运作过程来找答案。用户是通过信息系统的功能模块来操作数据库对象的,因此根据各模块顺利运行所需的数据库权限来建立数据库角色,可以比较精确地管理用户的数据库权限。虽然当把信息系统的功能权限细化到控件级时,这种模块级的数据库角色仍可能权限过大,但是如果进一步细分数据库角色的权限将增大权限管理的复杂性。使用模块级的数据库角色的另一个优点是,保持与信息系统前端功能权限管理的一致性,可以在授予用户某个功能模块的使用权限的同时,授予该模块对应的数据库角色,这样既方便管理,又保证前、后端授权的一致性。

在基于DBMS验证的情形下,用户对数据库对象的访问控制是由数据库管理系统实施的,因此,信息系统可以不存储用户数据库操作权限。而对于数据库角色的权限,则建立相应的数据结构进行记录,这既有利于了解数据库角色的权限情况,也有利于在信息系统中通过程序实现对数据库角色的快速授权和回收。下面是记录数据库角色的表结构:

(1)数据库角色表(DBROLES):存储信息系统中所使用的数据库角色的信息。

(2)数据库角色权限表(DBROLEAUTH):存储数据库角色的授权情况。

表中没有相应的回收权限的执行状态字段,这是因为当回收命令文本执行成功时,应从该表中删除相应记录。

信息系统用户操作数据库的权限,在后面的功能模块的授权时,同时进行模块级数据库角色授权。

3 前端功能模块的权限管理

前端功能模块的权限是指用户使用信息系统的功能的权限,实际上就是管理用户使用信息系统的哪些功能。但信息系统对用户功能权限的管理不仅要负责用户的授权,而且负责用户对信息系统的访问控制。

虽然功能权限的管理相对比较简单,但在大型的信息系统中,当用户数达到一定数量时,如果采取直接向用户授权的方法,也会产生大量的权限管理工作,因此有必要使用数据库角色的管理方式来管理用户的功能权限。然而,在信息系统的前端软件中不存在真正的“角色”对象,因此首先需要在信息系统中模似出“角色”来。在企业中,用户的权限是与职位或岗位相联系的,一个岗位可能有许多工作人员,相同岗位的人做着相同的事情,也有相同的权限。可把这个现实世界的“岗位”建立为信息系统中的“角色”,先把信息系统的某些功能权限赋予“角色”,然后再把用户与这个“角色”联系起来,从而把用户与信息系统的某些功能权限联系起来。下面就是使用“角色”进行权限管理使用的数据结构:

(1)系统功能表(MODAUTH):记录信息系统的功能模块,是功能权限管理的基础。

其中“MODID”字段中的值既是授权树的结点名称,也是主菜单的菜单项的名称,当该记录是叶结点时,还是某个子窗体名称。“PREMOD”字段中的值标识该记录的父结点记录,当无父结点时其值为“R”。这两个字段用于构建权限树,也用于在树形控件和主菜单搜索某个项。因此,表中记录的排列顺序要与按先序遍历树所形成的线性序列一致,父结点必须排在子结点之前,可通过“MODID”字段值的合理编码实现。

(2)管制控件表(CTRLAUTH):记录各模块中需要进行管制的控件信息。

(3)功能角色表(APPROLES):记录信息系统中的功能角色。

(4)功能角色模块权限表(ROLEMOD):记录各个功能角色有权使用的功能模块。

(5)功能角色控件权限表(ROLECTRL):记录各个功能角色在各个模块上可使用的控件。

后面的两个表记录各个功能角色具体的模块功能权限和控件权限,在用户被授予某些功能角色后,通过所授予的功能角色的“ROLEID”,与这两个表中的“ROLEID”进行自然连接,就可获取用户具体的功能模块授权情况和控件授权情况。

4 用户权限管理的实现

4.1 用户授权的实现

(1)根据信息系统的每个功能模块所需要的数据库权限建立相应的数据库角色,并做相应的角色授权,同时把数据库角色及其相应的权限信息记录在“数据库角色表”和“数据库角色权限表”中。

(2)把应用系统中的各功能模块的信息及其对应的数据库角色记录到“系统功能表”中。

(3)把各功能模块(窗体)中需要进行权限管理的控件记录到“管制控件表”中。

(4)根据企业的业务岗位的实际需要,建立与业务岗位相适应的功能角色,每一个功能角色对应现实世界的一个业务岗位,并把相应的功能角色信息存入“功能角色表”中。

(5)确定各个功能角色所需的功能模块权限和在这些模块中的可用控件权限,并做相应的授权。角色授权的实现是信息系统的权限管理核心,与性能、扩展性等有直接的关系。在开发的信息系统中,采用ORACLE作为后台数据库,并用Visual Stutio .NET作为开发工具,使用如下的方法开发基于功能角色的权限管理功能:

功能角色的授权设计主要由3个控件完成:显示功能角色的下拉下列框、显示功能模块权限树形控件、显示与当前树结点对应的模块中需要进行权限管理的控件的数据网格。在授权窗体的Load事件处理过程中,根据“系统功能表”构建权限树,主要代码段如下:

接着根据用户选择的功能角色,显示该功能角色现有的权限,即在树形控件的对应结点的复选框中标上选中标志。在授权者对功能角色进行功能模块授权时,如果授权者选中某树结点,就在数据网格中显示该结点所对应的模块中可授权的控件及已授权情况,并让授权者对功能角色进行控件授权。在授权者改变当前树结点时,控件的授权情况暂存入DataTable对象。在授权者确认授权情况后,遍历权限树,把当前功能角色的模块授权情况存入“功能角色模块权限表”,把控件的授权情况存入“功能角色控件权限表”。

(6)建立信息系统的用户,把用户的信息存入“用户基本信息表”(USERS),该表的结构如下:

在建立信息系统用户帐号的同时,建立相应的后端数据库帐号。

(7)信息系统的用户的授权。根据实际业务授予用户所需的功能角色,并把这些功能角色信息存入“用户功能角色表”(USERROLES),该表的结构如下:

在把用户的功能角色信息存入“用户功能角色表”后,通过把该表与“功能角色模块权限表”和“功能角色控件权限表”的关联,就可了解用户功能模块权限和控件使用权限。

用户的后端数据库权限的授权实现是在把授予用户的功能角色保存的过程中,通过“功能角色模块权限表”与“系统功能表”的关联找出各功能模块所对应的数据库角色,把这些数据库角色授予用户。

4.2 访问控制的实现

用户访问信息系统的控制分为两部分:一是控制用户只能使用哪些系统前端功能,二是控制用户只能操作哪些数据库对象。对于后一部分,DBMS会根据用户的数据库权限自动实施对用户的访问控制。因此,信息系统要完成的访问控制是控制用户对功能模块的访问和控制用户对模块(窗体)中的控件的访问。在所开发的信息系统中,功能模块的访问控制是通过管理用户对系统主菜单的菜单项的访问来实现的。主窗口的菜单按照“系统功能表”中的“MODID”和“PREMOD”字段的值来构建,“系统功能表”的每一条记录对应着一个菜单项,所有的菜单项初化为不可见。为方便访问控制的实现,建立了把“用户角色表”、“功能角色模块权限表”、“系统功能表”连接起来的数据库视图“用户权限视图(V_USER|MOD)”,具体的定义如下:

CREATE VIEW V_USER|MOD AS

SELECT DISTINCT A.USERID, B.MODID, C.MODNAME, C.PREMOD, C.LEAF, C.DBROLE

FROM USER_ROLES A, ROLE_MOD B, MODAUTH C

WHERE A.ROLEID=B.ROLEID AND B.MODID=C.MODID

通过“用户权限视图”可以直接查出用户的功能模块权限,视图中一条记录对应着系统主窗口菜单的一个菜单项,遍历该视图中与用户ID相匹配的每条记录,根据“MODID”的字段值,在主窗口菜单中找到相应的菜单项并设置为可见,从而实现对用户访问系统功能模块的控制,用户选某个菜单项就导航到相应模块(子窗体)。

控件的访问控制的实现方法是:子窗体中每个需要进行权限管理的控件都初始化为不可用的(Enabled属性为False),建立连接“用户功能角色表”、“功能角色控件权限表”、“管制控件表”的视图“用户控件权限视图”(V_USER|CTRL):

CREATE VIEW V_USER|CTRL AS

SELECT DISTINCT A.USERID, B.MODID, C.CTRLID,

C.CTRLNAME, C.CTRLDSPT

FROM USER_ROLES A, ROLE_CTRL B, CTRLAUTH C WHERE A.ROLEID=B.ROLEID AND (B.MODID=C.MODID AND B.CTRLID=C.CTRLID)

在用户通过主窗口的可用菜单项进入子窗体后,根据当前子窗体名和当前的用户ID从视图中取出相应的记录,根据记录中的“CTRLID”的字段值,在当前窗口中找到相应的控件并把控件设置为可用的,具体的实现代码如下:

5 结束语

DBMS的用户验证方式有效地提高了信息系统的安全性,特别是在限制系统管理员权力,实现管理与操作分离方面有明显的好处。但这种验证方法也带来了用户权限管理的复杂性。采用模块级的数据库角色可以比较准确地管理用户的后端数据库权限。但对于特别大型的信息系统,由于其功能模块众多,模块级的数据库角色可能显得粒度太细并且角色的数据库权限显重复。因此,使用大粒度的岗位级的数据库角色来管理用户的后端数据库权限也是不错的选择。

参考文献

[1]唐成华,陈新度,等.管理信息系统中多用户权限管理的研究及实现[J].计算机应用研究,2004(3):217-219.

基于用户权限 篇2

1 主要功能设计

基于角色的用户权限授权系统主要包括:用户管理、角色管理、菜单管理。通过为用户分配角色,为角色授权菜单权限,实现基于角色的用户权限管理。

其中用户与角色是多对多的关系,即用户可以拥有多个角色,一个角色也可以授予多个用户。例如:用户A既有仓库出货员的角色,又有仓库盘点员的角色;仓库盘点员这个角色除了被赋予给A,同时也可以赋予给B。角色与菜单权限也是多对多的关系,即一个角色可以拥有多个菜单权限,一个菜单权限也可以被多个角色拥有。例如:仓库出货员既拥有增加出库记录的菜单权限,又有查询出库记录的菜单权限;查询出库记录的菜单权限既被仓库管理员拥有,也被仓库盘点员拥有。具体关系如图1所示。

建立了用户、角色、菜单之间的关系后,当系统新增用户时,系统管理员直接在系统中为该用户授予某个或某几个角色即可,而不需要考虑该用户在系统中需要哪些菜单权限。例如,当用户A作为仓库出货员工作时,系统管理员只需要为A用户授予仓库出货员角色,而不需要再考虑仓库出货员具体要有哪些菜单权限了。

建立了用户、角色、菜单之间的关系后,当系统新增功能时,开发人员直接在系统中将新增的功能分配给一个或多个角色,而不需要考虑新增的功能需要分配给哪些用户。例如,当新增了盘点结果打印的功能,开发人员只需将这个功能对应的菜单权限分配给仓库盘点员角色即可,可不需要考虑为哪些人分配这个功能权限。

基于角色的用户权限授权系统能够更好地区分系统管理员和开发人员的职责。系统管理员负责用户管理、角色管理、为用户分配角色。开发人员负责开发系统功能,将功能分配给对应的角色。通过该系统,系统管理员和开发人员能够各司其责,避免了工作交叉带来的混乱,提高了工作效率。

2 主要技术实现

2.1 系统总体架构

基于角色的用户权限授权系统采用B/S模式(浏览器/服务器模式)。B/S模式的系统,用户使用更加方便、快捷、高效,开发人员维护和升级更加简单[3]。系统总体架构如图2所示。

2.2 开发工具的选择

基于角色的用户权限授权系统采用PHP技术+Mysql数据库+Tomcat应用服务器的开发运行模式。

PHP是被广泛使用的嵌入式脚本语言,特别适合Web开发。其语法非常接近C、Java和Perl,容易学习,并可跨平台运行。PHP支持绝大多数的数据库,支持各种Internet协议,还可以通过API进行扩展。[4]

Mysql作为PHP的最佳拍档,是广受欢迎的SQL数据库管理系统,它免费、快速,并可跨平台运行,支持多线程、多用户、重负载的性能要求,是Web应用系统理想的选择。[4]

Tomcat是一个轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP程序的首选。Tomcat技术先进、性能稳定,而且免费,因而深受Java爱好者的喜爱并得到了部分软件开发商的认可,是目前比较流行的Web应用服务器。[5]

2.3 各子模块介绍

在用户管理中,系统管理员只负责创建用户登录的相关账户信息,人员的基本信息在人事管理系统中维护,并通过员工编号相关联。用户管理中主要包括对用户信息的增加、修改和查询。如果有用户离职,系统管理员可以通过修改账户有效日期,使用户无法登陆。yonghu表如表1所示。

在角色管理中,系统管理员可以根据职能或机构的需求策略来创建角色。角色管理中主要包括对角色的增加、修改、删除和查询。juese表如表2所示。

在用户角色分配管理中,系统管理员给用户分配角色,建立用户与角色的关联关系。用户角色分配管理中主要包括对用户与角色管理关系的增加、删除和查询。yonghu_juese表如表3所示。

在菜单管理中,开发人员根据需求和开发任务开发相应的功能后,需要将系统功能与菜单通过“菜单行为”字段进行关联。用户登陆系统查看到该菜单,点击菜单可以使用相应的系统功能。菜单管理主要包括菜单的增加、修改、删除和查询。caidan表如表4所示。

在角色菜单授权管理中,开发人员根据需求将角色与菜单权限关联,给角色分配权限。角色菜单授权管理主要包括角色与菜单权限关系的增加、删除和查询。juese_caidan表如表5所示。

3 结论

基于角色的用户权限授权系统的核心思想是将权限同角色关联起来,而用户授权则通过赋予相应的角色来完成的,用户所能访问的权限是由该用户所拥有的所有角色集合的并集决定的。

通过对基于角色的用户权限授权系统的研究,使对于拥有同一个角色的用户而言,他们所拥有的权限是一致的。通过这种统一的用户权限授权机制,能够使系统的信息服务在权限管理上更加安全、高效、易于维护。

摘要：针对管理信息系统中,业务需求的不断变化、系统功能的不断增加等问题,结合企业用户流动性大的现状,分析阐述了用户、角色、菜单权限的关系,设计了基于角色的用户权限授权系统。系统包括用户、角色、菜单权限的增删改查,以及为用户分配角色,为角色关联菜单等功能。系统规范了用户、角色、菜单权限的管理,提高了用户授权的易用性。

关键词：角色,菜单,用户授权

参考文献

[1]刘峰,郑滔.应用集成原理与技术[M].北京:清华大学出版社,2010.

[2]王科,纪姗姗,刘芳,等.企业级信息系统权限控制机制设计与实现[J].计算机工程与设计,2011(11).

[3]任泰明.基于B/S结构的软件开发技术[M].西安:西安电子科技大学出版社,2006.

[4]王石,杨英娜.精通PHP+MySQL应用开发[M].北京:人民邮电出版社,2006.

基于用户权限 篇3

关键词：基于用户权限,视频监控,资源,优先级设计

建立全数字化视频监控管理系统平台, 防止违法活动的发生, 减少财产损失, 在发生事件时, 做到“有据可查、有据可依”。全面实现人防、物防、技防和联防的监控安防手段, 可对现有监控设备, 进行多画面实时查看、云台控制等;使用数字证书功能授权用户可实现历史回放、视频下载、抓图等功能;实现自定义分组设置, 特定活动区域视频设备设置;实现权限管理功能, 可分级设置控制权限;对所有操作动作进行记录, 生成操作日志, 较传统监控手段节省了大量人力、物力, 从而明显提高监控防护效率, 减少运行开支。

1 基于用户权限的资源优先级设计

每一路视频用户的连接数都有一定的限制, 这时, 会涉及到用户调用视频时优先级的问题, 在用户连接数达到最大限制时, 优先级低的用户可能无法调阅视频, 同时系统会给出相应的提示, 而优先级高的用户会抢占优先级低的用户调阅视频, 同样会对优先级低的用户给予提示。在操作云台控制时, 也会出现资源抢占的问题。资源抢占优先级特点是单线程子程序, 可以并发执行, 但不能超过视频允许的用户最大连接数, 如图1 所示。

1.1 性能

功能名称性能要求:权限判断资源调用资源调用权限判断时间不会超过200 毫秒;权限判断云台控制云台控制权限判断时间不会超过200 毫秒。

1.2 输入

权限控制需要调用控制类中的资源抢占控制层方法, 方法内置参数是request请求和response响应。调用此方法需要前台界面传入的参数为:第一, 摄像机id;第二, 资源抢占类型, 实时监控还是录像回放;第三, userid当期登陆人的用户id。

1.3 输出

用户实时监控调用/ 录像回访调用。第一, 通过摄像机的id, 我们可以判断当前的设备连接数;第二, 通过用户id, 我们可以判断当前用户的优先级别;第三, 资源抢占类型, 是实时监控在抢占资源还是录像回放在抢占资源。

1.4 算法

①每一路视频被调阅都会在数据库记录, 例如, 当前视频被调用10 次, 则用户连接数记录在数据库10 次;②获取设备限制的最大连接数;③公式:最大连接数-已使用的连接数。

1.5 流程逻辑

云台权限控制逻辑图如图2 所示。

2 安全性能设计

全数字化视频监控管理系统平台数据共享与交换对安全的设计如下。

(1) 数据包的完整性、一致性需要得到保障。

(2) 交换过程中, 参与交换的各方要具有不可抵赖性, 能进行责任认定。

(3) 在交换过程中, 数据包的机密性要求得到保障。

(4) 授权策略和鉴权控制。前置机进行信息交换时, 要有相应的控制策略, 如前置机A1能否主动跟前置机A2进行信息交换;前置机A1能否主动向信息交换中心系统提交数据;前置机A1能接收其他哪些前置机发出的交换指令等, 需要进行授权策略制订, 并在交换过程中进行鉴权识别与控制。

(5) 网络信任属性的加载与卸除, 对信息交换共享系统是透明的, 属于标准扩展范围, 不影响信息交换的完整性。

(6) 网络性能要求:图像资源接入端口带宽的配置10M, 图像资源转发端口带宽的配置, 应实现主备;平台内任意两节点间的网络传输延时宜小于等于1000ms;时钟同步采用NTP协议, 通过管理平台实现对前端设备的校时功能。

3 结语

通过全数字化视频监控系统的搭建, 可以基于用户权限进行视频监控资源优先级控制, 让用户实时调阅视频监控录像, 也可以让用户选择过去某个时间段的监控画面进行回放, 为以后回顾重大事件提供真实画面重现, 支持并发执行。用户选中播放窗口, 选择某个时间段, 若此时间段存在录像, 并且带宽允许, 网络连通, 则可以正常回放, 回放的录像还可以进行速度调节, 加速播放或者减速播放;支持暂停、回放、停止播放、截图、下载功能;播放时, 有进度条显示播放进度, 拖拽播放进度上的进度按钮, 可以将视频直接拖拽到某个点播放。监控系统将本地视频图像监控、远程实时监控、云台镜头控制有机结合起来, 构成一整套视频集中监控管理系统, 最大程度上防范各种入侵。

参考文献

[1]中华人民共和国国家质量监督检验检疫总局, 中国国家标准化管理委员会.GB/T 28181-2011, 安全防范视频监控联网系统信息传输、交换、控制技术要求[S].

[2]公安部科技信息化局.公安信息通信网边界接入平台安全规范 (试行) 视频接入安全部分[EB/OL]. (2010-04-01) [2015-12-01].http://www.wenkuxiazai.com/doc/f952349fc5da50e2524d7f80.html.

[3]中华人民共和国公安部.GB50395-2007, 视频安防监控系统工程设计规范[S].

[4]中华人民共和国公安部.GA/T 74-2000, 安全防范系统通用图形符号[S].

基于用户权限 篇4

随着国家电网SG186工程建设的深入, 企业门户的建设也开始由省电力公司一级向地市供电公司一级延伸。根据国家电网门户典型设计, 河南省电力公司采用了虚拟方式建设全省各地市门户。由于虚拟门户的软、硬件及应用均为集中部署, 全省用户访问同一套门户应用服务, 这给虚拟门户如何进行安全的权限管理带来了挑战, 大量用户的赋权和角色的管理工作将给管理员巨大的工作压力。为了解决这一难题, 充分利用SG186工程中的统一身份管理建设成果, 将LDAP目录与Web Logic相结合, 从而实现了小工作量、高灵活度的虚拟门户权限管理。

通过对这一解决方案的探讨, 希望在虚拟门户的权限管理解决方案上起到一点抛砖引玉的作用。

1 虚拟门户用户权限控制的目标

1.1 虚拟门户与实体门户

在探讨虚拟门户的权限控制方式前, 有必要对什么是虚拟门户、什么是实体门户做一对比说明。

通俗的说, 当只有一个单位使用门户系统时, 这时这个单位独占了门户系统的所有软、硬件和应用资源, 这时这个企业门户系统就称为实体门户系统。当有多个单位共享一套软、硬件和应用资源, 通过技术手段使每个单位在逻辑上又拥有自主的应用管理权限时, 这样的门户系统我们就称为虚拟门户系统。

实体门户与虚拟门户的重要区别在于是否共享一套应用。如果仅仅是共享软、硬件资源, 而应用是互相独立部署的, 则不能称之为虚拟门户系统。

就河南省电力公司来说, 如果采用实体门户的方式来建设全省门户 (仅包括省本部和18个地市公司) 的话, 就需要19套软、硬件平台及相应的应用部署。而采用虚拟门户, 则仅需1套, 在维护便利性及成本上有很明显的优势。

实体门户在运维管理上较为复杂, 每一个部署了实体门户的单位, 均需要考虑可靠性、性能、数据安全、备份、部署等事务, 这些分散在各个单位中的事务增加运维的成本的复杂性。而采用虚拟门户, 则与数据安全及硬件相关的运维事务可进行集中、统一的管理, 相比较来说, 每一个部署虚拟门户的单位, 仅需进行与自己相关的权限管理即可, 与平台相关的运维管理则不需要关注, 这将在整体上, 大大降低运维成本和复杂性。

虚拟门户系统虽然在整体上降低了运给成本, 但运维事务的集中, 也给如何保证统一管理下的权限管理独立性和访问互相隔离带来了挑战, 而如何解决这个问题, 就是本文要探讨的目标。

1.2 虚拟门户的权限控制目标

以河南省电力公司为例, 全省共同有二级单位30多个, 其中所属的地市供电公司就有18个。要在一个软、硬件平台上, 实现对这些二级单位虚拟门户的应用, 在权限上就必须要求在这一平台上能够实现以下管理目标: (1) 各单位能够对自己的用户和组织进行独立管理; (2) 能够进行角色的创建、删除、修改管理; (3) 能够进行门户功能单位的访问权限管理; (4) 各单位间的权限管理行为互不干扰, 相互独立; (5) 管理员权限能够分级代理, 逐级授权。

应用示例如图1所示。

2 基于LDAP的Web Logic权限控制实现

2.1 基于LDAP的用户及组管理

(1) LDAP概述。LDAP目录是一种特殊的数据库系统, 它专门针对读取、浏览和搜索操作进行了优化。目录一般用来包含描述性的、基于属性的信息并支持精细复杂的过滤能力。目录一般不支持通用数据库针对大量更新操作所需要的复杂的事务管理或回滚策略, 目录的更新一般都非常简单。这种目录可以存储包括个人信息、Web链接、JPEG图像等各种信息。LDAP是运行在TCP/IP之上的访问协议。LDAP目录中的信息是按照树型结构组织的, 具体信息存储在条目 (entry) 的数据结构中。条目包含了多个属性, 每个属性由一个类型和多个值构成。每个条目使用一个识别名 (DN) 标识, 每个条目DN的各个元素称为相对识别名 (RDN) 。这个树型结构类似于文件系统, RDN相当于文件, DN相当于文件的绝对路径。在LDAP标准中定义了常用的对象类 (object Class) 及其相关的必需和可选的属性 (attribute) 。目前河南省电力公司已经建设了覆盖全省的用户目录。

(2) LDAP组及动态组概念。在LDAP中有两种表示集合的方法, 分别是静态组及动态组。静态组也常简称为组, 创建静态组的时候也同时确定了组成员。动态组则是创建一定的规则, 让LDAP服务器根据规则, 动态决定组的成员对象。

静态组在使用过程中, 如果不人为干预, 则组内成员不会发生变化, 这也决定了静态组不适合于在需要将大量人员放在一个集合时的操作, 当需要把1 000或10 000人放在一个静态组中时, 工作量是惊人的。而动态组是根据规则自动将符合规则的人员加入组内, 因此动态组更适合在需要对大量人员建组时的操作。例如:部门A, 部门B的所有人员需要创建在一个组内, 这两个部门人员数量达到了500人, 由于每个人员都有一个所属部门的编号, 因此只需将人员的所属部门编号作为动态组的规则, 就可以将这两个部门的所有人员放在一个组内, 以实现作为权限与资源分配的实体。

由于动态组是根据规则自动决定成员对象, 因此在性能上会比静态组更为消耗计算机资源, 但随着服务器硬件水平的提高, 目前一般的服务器都有4个CPU内核及4G的内存, 硬盘转速普遍都在10 000转/min, 静态组对计算机资源消耗可不用考虑。

2.2 Web Logic门户中间件的权限架构

Web Logic Server提供全面的安全体系结构, 其安全框架是依照J2EE安全规范定义的, 包括用户级和组级访问控制列表 (ACL) 、基于密码的隐私权和用户验证、域、Secure Sockets Layer (SSL) , 数字签名以及其他基于标准的安全措施。

Oracle Web Logic Security Framework的一些主要功能包括: (1) 身份验证:借助用户名与口令的组合或数字证书, 确定用户的身份; (2) 授权:规定应当提供给每个经过身份验证的用户的应用功能、服务和数据资源; (3) 加密:确保内部数据的安全及秘密地进行通信和网络数据传输的安全; (4) 审核:提供记录所有与安全性相关的活动的功能; (5) 可插式安全性框架:支持与第三方安全性解决方案的集成, 允许Oracle Web Logic Server应用能够充分利用市场上“最好的”安全性解决方案所提供的全部功能; (6) 用户和用户组:用户对应于应用程序中的一个账号, 通常具有用户名和口令。用户组是多个用户组成的集合, 通常把具有类似访问系统资源权限的一组用户定义到一个用户组中; (7) 角色:角色是抽象的和逻辑意义上的用户组, 由应用程序开发人员定义。资源的访问权限赋予角色, 再通过角色把权限赋予用户; (8) 单点登录:无须任何额外的编程, Oracle Web Logic Server应用就自动能够实现单点登录。在Oracle Web Logic Server应用的范围之内, 用户不必重新进行身份验证;

其中身份验证、授权、用户和用户组、角色功能与本文所探讨的权限管理相关。

2.3 基于LDAP的Web Logic用户权限管理

基于LDAP的Web Logic用户权限管理就是充分利用LDAP的静态组和动态组功能结合Web Logic的角色权限控制策略, 实现对人员的分级权限控制。

2.3.1 Web Logic权限策略

“角色策略”由角色名和角色定义组成, 使用“安全策略”将“委托管理”角色映射到门户资源上。将资源 (门户功能) 的访问权限限制于仅被授予了特定安全角色的那些用户。Web Logic首先使用身份验证流程测试候选用户。身份验证流程通常是登录流程, 它要求候选用户提供用户名和密码。如果候选用户成功通过此质询, 将授予该用户一组标识:其中一个标识是其用户名标识, 其他标识是一组该用户具有其成员资格的组。用户的用户名标识和组标识称为用户的“委托人”, 可将这些委托人视为一组凭据, 用户在访问某些由授权流程所保护的资源时需要提供这些凭据。其次是授权, 测试用户是否已被授予了访问受保护资源所需的角色, 如果这些用户已被授予所需角色, 则他们可以访问资源;否则, 将被拒绝访问。如果用户的一个委托人已被授予了特定角色, 则该用户也被授予了该角色。

图2说明了Web Logic中组的与角色共同作用来实现功能权限控制的方式。

从上述说明中, 可以发现, 组和角色在Web Logic权限控制起主要作用, 角色用来决定权限的集合, 组用来决定人员的集合, 再通过角色与组的映射, 将权限传递给用户, 最终实现用户根据所分配权限来决定访问范围。

2.3.2 Web Logic与LDAP组功能结合实现分级权限管理

知道了角色及组在Web Logic门户中对权限控制是起主要作用, 而LDAP对组的管理又非常灵活, 因此将两者结合起来, 既能发挥Web Logic强大的权限管理功能, 也能发挥出LDAP的速度快, 灵活性高, 管理工作量小的优势。

Web Logic在其服务器的安全领域的设置功能中提供了“身份验证提供程序”功能, 这一功能预置了与LDAP、数据库等多种常见用户数据存储的访问接口, 通过设置适应于LDAP的“身份验证提供程序”, 能够将LDAP中的用户及组数据全部提取到Web Logic中, 这样就可以在Web Logic中方便地使用LDAP中的用户和组来进行权限的管理。

图3和图4是经过设置“身份验证提供程序”后, 从Web Logic管理控制台看到的来自于LDAP中的用户及组信息。“ggnovelled”是身份验证提供程序的名字。

通过将来自于LDAP中的组分配给相应的Web Logic的角色, 就可实现特定组的用户只能访问特定的内容。

例如:河南省电力公司有18个地市供电公司, 则对应就有18个虚拟门户, 如果要保证每个单位的用户只能访问本单位的虚拟门户, 则需要将每个单位的全部用户放在一个组中, 将此组与可访问本单位的Web Logic角色挂接。在不使用LDAP动态组的情况下, 要将全部用户置入一个组中, 工作量是巨大的, 通常一个地市供电公司拥有近千人员, 这有可能会耗费掉管理员一整天的时间, 而使用LDAP动态组, 则将此工作量降低为只需要几分钟的时间, 这将大大降低管理员工作强度。

3 结语

在虚拟门户的权限管理上, 如果完全依赖于Web Logic自身提供的能力, 将会使管理工作变得十分巨大, 特别是在地市供电公司众多的河南。而充分利用LDAP目录的优势, 并与Web Logic结合, 则有效的解决了这个问题。在面对问题时, 只要充分了解各类软件或平台的优缺点, 通过它们之间的互补, 则很多问题都会迎刃而解。

摘要：随着国家电网SG186工程建设的深入, 企业门户的建设在由省电力公司一级向地市供电公司一级延伸, 在采用虚拟方式进行地市供电公司企业门户建设过程中, 针对应用服务在全省集中部署的情况, 如何进行灵活、方便的权限管理, 通过将LDAP目录与WebLogic权限机制相结合的方式, 提出了一套有效可行的方案。

关键词：虚拟门户,LDAP,分级权限管理

参考文献

[1]毛莉, 刘海.WebLogic安全构架及安全技术应用[J].微展.2004 (9) :56-59.

[2]程超.使用LDAP实现构件访问权限控制[J].电子工程师.2004 (7) :65-67.

创建权限安全的SQL用户 篇5

软件换肤采用的是Iris Skin4, 此换肤组件特点 是使用简单、 方便。换肤的实现过程是这样的, 首先把皮肤文件作为资源存入项目, 然后在软件初始化的时候采用反射机制遍历出皮肤名称绑定到界面上的Combobox上。

用户改变Combobox项目 , 软件自动 释放相应 的资源皮肤, 然后把皮肤效果使用在软件中。其中反射便利皮肤代码如下所示:

2 手动设定表权限功能

软件首先在正确连接到数据库后会自动扫描本数据库中的所有表, 然后绑定到界面的List Box上。用户选择某一个表后, 在右侧有增加、删除、修改、查询功能, 选择相应功能,然后点击临时保存, 会把对于某个表的权限临时保存在内存中, 保存后的信息显示在下方的Data Gridview中。用户可以反复修改、临时保存。最后点击最终赋予权限按钮, 软件会根据界面上的登录名把相应权限赋值给相应的角色名。

其中登录名、安全用户名、角色名的对应特点如下例子。登录名: test ; 安全用户名: login_test; 角色名: role_test最终赋予权限会把权限赋予这个角色名, 然后把安全用户名加入到角色中, 这样登录名就有了这个角色拥有的所有权限。

最终赋予权限功能采用事物机制, 只有所有代码都执行成功才完成, 否则回滚, 不执行任何语句。代码如下所示:

3 创建登录名、安全用户名以及角色

创建登录名、安全用户名、角色功能采用执行系统存储功能方式完成。 以创建登录名为例, 首先软件会查找数据库中是否存在想要添加的登录名, 如果有, 则提示用户已经存在此登录名, 如果没有才允许用户添加登录名。其中, 查找是否存在相应登录名的代码如下:

添加登录名采用的存储过程为sp_addlogin, 其中有4个参数, 分别为loginame、passwd、defdb、returnvalue。代表登录名称、密码、默认数据库、返回值。 代码如下所示。

//增加登录名act.Clear Parameters();act.Add Parameter("loginame", tbdlm.Text.Trim()).Add Parameter("passwd", tbpwd.Text.Trim()).Add Parameter("defdb", tbdbname.Text.Trim()).Add Return Parameter("returnvalue").Execute Non Query Procedure ("sp_addlogin",outerror);if (! error.Is Null Or Empty()){Message Box.Show(error);return;}else{if (act._Data Sql Helper.command Procedure.Parameters [act._Data Sql Helper.pre + "returnvalue"].Value.To String()== "0"){//Message Box.Show("添加登录用户成功");rich Text Box1.UIThread Invoke (() => { richText Box1.Append Text("添加登录用户成功 rn"); });}else{//Message Box.Show("添加登录用户失败");rich Text Box1.UIThread Invoke (() => { richText Box1.Append Text("添加登录用户失败 rn"); });}}

4 最终效果

VDP系统用户角色与权限设计 篇6

本项目即“新疆维吾尔自治区职业学校数据信息平台 (简称VDP) , 由新疆维吾尔自治区职教办职业教育协调处根据业务工作的迫切需要而提出, 旨在使我区职业院校与政府职教管理部门能摆脱半手工操作模式, 提高工作效率[1];信息管理条理化、科学化, 方便管理部门快速实现准确的查询与统计;经过规范工作流程与信息的不断积累, 为我区职业教育管理工作提供数据基础, 辅助领导决策[4]。

2 角色与类的设计

角色访问控制 (Role—Based Access Control, RBAC) 模型指出, 角色是中介, 将权限授予角色, 用户通过分配角色, 从而得到对客体资源的操作权限授权[3]。而在本系统中, 系统管理员具有系统最高级别的权限, 实行信息的全局管理与数据维护工作。普通用户由系统管理员分配权限, 在角色权限范围内进行访问与操作。

2.1 角色设计

角色是一组用户的集合, 具有指定的权限完成特定的资源访问与操作行为。为对有相似权限的用户进行分类管理, 定义了系统管理员、管理员、用户、访客等角色。角色具有上下级关系, 系统管理员通过角色授权分配权限资源, 那么, 下级角色的权限范围只能在上级权限范围实行进行授权操作。

角色从属于编码级别, 角色管理两个部分, 一个是菜单功能权限, 和报表内容权限。角色报表权限不同于编码内定权限, 一旦赋予角色相关报表的权限, 则本角色可以跨越编码级别对属于本角色的报表直接管理。但系统会给出提示, 并记录日志。

本系统初步要求建立几个以下角色并赋予相关功能和报表管理范围。根据实际情况予以改变这些默认的角色。

2.2 类的设计

角色控制Role Controller依据需求设计相应功能方法, 主要代码如下所示:

3 权限设计与实现

3.1 权限要求

本系统的权限要求分为资源和功能两个部分, 资源采用管理具体到报表方式, 而功能则根据菜单来定义, 关于审批的要求具体如下:

A1A2根级权限, 可以统计查询属于它之下的所有编码范围报表信息。

B1B2B3B4属于教育管理机构级别, 可以查询统计属于本编码范围之下的任何学校报表信息。

C1C2C3C4C5C6属于终端级权限, 只可查询审批统计本学校内的所有报表信息。

3.2 权限设计

根据访问控制[2]要求, 在数据库中设计模块表、功能表和角色表等三类表。本系统按照组织机构、角色、权限三个部分设计如下:

(1) 组织机构:根据新疆的行政区划, 涉及15个地州、200多所职业院校。

(2) 角色:超级管理员、数据审核员 (自治区级) 、地州管理员、院校领导、院校管理员、院校填报员。

(3) 权限:对报表的下发、填写、功能菜单的选择等。

设计原理:首先创建根节点组织结构名称, 然后添加子节点为各个院校名称, 再把相关角色的用户分配到组织机构, 并为每个用户指定角色, 由角色和组织机构来确定用户的操作权限。

3.3 用户角色权限实现

权限控制Manage Controller依据需求设计相应功能方法如下:

实现后的主要页面如图1—图4所示。

4 结语

本文介绍了通过组织机构节点控制, 分配角色的用户分配到组织机构, 并为每个用户指定角色, 最后由角色和组织机构来确定用户的操作权限设计方法[5]。最终实现了系统管理员、教师用户、院校管理员、领导用户、地州管理员、数据审核员等几种角色的编码及菜单权限分配。符合VDP系统角色与权限的设计需求, 为整个系统的设计实现奠定了基础。

摘要：针对VDP系统中的用户、角色、权限访问控制的问题, 提出了一种基于编码的角色访问控制和用户权限设计的方法。利用角色访问控制技术可以有效地实现用户访问权限的动态管理, 取得了较好的效果。

关键词：角色,权限,设计

参考文献

[1]李忠雄, 唐雪梅.基于C#.NET的学生信息管理系统设计与实现[J].电脑与电信, 2011, 7:52-53.

[2]张锐, 张建林, 孙国忠.多业务系统的统一认证授权研究与设计[J].计算机工程与设计, 2009, 30 (8) :1826-1828.

[3]朱一群.基于用户信任的动态多级访问控制模型[J].计算机工程, 2011, 37 (23) :129-130.

[4]柳胜.性能测试从零开始:loadrunner入门[M].电子工业出版社, 2008:16-34

基于用户权限 篇7

Android操作系统的安全机制:

Android系统由于基本采用的是Linux内核, 因此它继承Linux系统基本的安全机制1 - 2, 如采用用户和用户组进行对文件的访问权限的控制等。同时, Android还有其自身的安全机制设计。

应用沙箱机制

应用沙箱是Android系统安全的基础, 每个应用程序都会被授予一个唯一的用户标识 (UID) , 通过这个用户标识来访问属于其自身的资源。每个应用在安装时都会让用户来选择通过该应用的所能拥有的权限, 如读取联系人信息、访问摄像头、访问网络等等。

签名机制

安装到Android系统中每一个应用都会有一个数字证书, 该数字证书用来对应用程序的唯一完整性进行认证。数字证书一般采用非对称加密算法, 私钥掌握在应用程序的开发者手中。

组件封装

Android系统中的应用程序一般有活动、服务、内容提供和广播接收四个类型的组件, 每个组件都可以设定公开或者私有属性来控制访问权限。其中, 公开组件是可以被其他应用访问的。

Android安全机制不足

Android系统虽然具有上文所述的安全机制, 但依然存在着不足和缺陷, 沙箱机制无法防范那些通过漏洞获得特权的应用, 组件封装机制则可以通过应用间的代理绕过, 签名机制没有统一的颁发机构, 比较容易伪造。此外, 应用间通信的权限提升问题也是一个比较明显的安全问题。

用户可视化权限管理监控

用户可视化权限管理是通过收集系统中各个应用程序所拥有的权限列表, 然后可视化的呈现给用户, 然后定义一些危险权限集合, 如读取联系人权限和访问网络权限组合为危险权限组合。在进程组件交互时判定是否存在危险权限集合, 如果存在则预警用户, 同时将访问记录、如组件名称、时间、权限等信息记录在可视化管理权限日志中, 方便用户查询。

应用程序权限列表

Android系统中每个应用程序都有它自身的应用权限集合, 获得每个应用的权限列表主要是通过Package Manager对象来实现, 首先通过get Package Info方法获得包名信息, 然后再通过应用包名信息对象Package Info中requested Permissions方法来获得该应用的权限列表。

危险权限集合定义

危险权限集合主要是指那些有可能让用户个人信息隐私和关键信息泄露的操作权限。比如, 读取联系人信息权限和访问网络权限等。这些危险权限集合的定义是后续判定预警用户的基础。

预警判定

危险权限的判定主要涉及到Android权限提升攻击的问题, 所谓权限提升是指一个应用并不具备某一个权限, 但通过另外一个应用的访问来获得该权限的访问权。如图1 所示。

如图1, 假设应用A拥有访问网络的权限, 却没有读取用户联系人信息的权限。应用B具有读取用户联系人信息的权限。此外, 应用A还拥有应用B组件接口的权限, 而这个接口组件恰好能访问到联系人信息, 这样的话应用A便能通过应用B的组件接口来获得联系人的信息, 再通过自身所拥有的访问网络的权限将用户联系人信息泄露, 这便是一个Android系统中权限提升的例子。

为了防止权限提升的问题, 及时预警用户, 采用危险权限集合在应用间进程交互时对这类型的隐私易泄露的危险情况做出及时处理。预警判定时机如图2 所示。

预警用户与记录信息

当预定判定进程间交互式存在危险权限集合时则通过对话框的形式来预警用户, 并应用进程的信息、权限信息和当前时间记录在权限管理日志中方便用户查询。

结语

Android系统安全问题是极为重要的问题, 用户对Android安全问题应该得到提升。本文提出可视化的用户权限管理监控方案能使用户提高安全意识和对安全问题做出更好的管理操作。