oa系统权限管理（共8篇）
l 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。
l 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
l 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。
针对OA系统的特点，权限说明：
权限
在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。
权限组
为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。角色
权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。
用户组
将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。
通过给某个人赋予权限，有4种方式(参考飞思办公系统)A.通过职位
a)在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限不可继承。
b)实例中：如前台这个职位，对于考勤查询有权限，则可以通过对前台这个职位设置考勤查询的浏览权，使他们有使用这个对象的权限，然后再设置个，考勤查询权（当然也可以不设置，默认能进此模块的就能查询），则所有前台人员都拥有考勤查询的权利。
B.通过项目
a)在项目中，项目成员的权限来自于所在项目的权限，他们同样不能继承下级项目的权限，而对于项目组长，他对项目有全权，对下级项目也一样。
b)实例中：在项目中，项目成员可以对项目中上传文档，查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口，这样每个成员能访问这个项目了，再加上项目文档的上传权和查看文档权即可。c)对于组长，因为可以赋予组长一个组长权（组长权是个特殊的权限，它包含其他各种权限的一个权限包），所有组长对于本项目有全权，则项目组长可以对于项目文档查看，审批，删除，恢复等，这些权限对于本项目的下级项目依然有效。
C.通过角色
a)角色中的成员继承角色的权限，角色与角色没有上下级关系，他们是平行的。通过角色赋予权限，是指没办法按职位或项目的分类来赋予权限的另一种方式，如：系统管理员，资料备份员…
b)实例中：对于本系统中，全体人员应该默认都有的模块，如我的邮件，我的文档，我的日志，我的考勤……，这些模块系统成员都应该有的，我们建立一个角色为系统默认角色，把所有默认访问的模块的浏览权加入到里面去，则系统成员都能访问这些模块。
D.直接指定
a)直接指定是通过对某个人具体指定一项权限，使其有使用这个权限的能力。直接指定是角色指定的一个简化版，为了是在建立像某个项目的组长这种角色时，省略创建角色这一个步骤，使角色不至于过多。
b)实例中：指定某个项目的组长，把组长权指定给某个人。
针对职位、项目组：
如果用添加新员工，员工调换职位、项目组，满足了员工会自动继承所在职位、项目组的权限，不需要重新分配权限的功能。
用户管理
用户可以属于某一个或多个用户组，可以通过对用户组授权，来对组中的所有用户进行权限的授予。一个用户可以属于多个项目组，或担任多个职位。授权管理
将一个基本权限或角色授予用户或用户组，使用户或用户组拥有授予权限的字符串，如果角色、职位、项目中存在相同的基本权限，则取其中的一个；如脱离角色、职位、项目组，只是取消用户或用户组的中此角色、职位、项目组所授予的权限。用户所拥有的权限是所有途径授予权限的集合。管理员用户可以查看每个用户的最终权限列表。
权限管理
基本操作权限与权限组（基本操作权限的集合）的管理。
OA权限管理设计的实现 物理数据模型图如下：
物理数据模型图
根据以上设计思想,权限管理总共需要以下基本表：
tb_User：用户信息基本表；
tb_Department：部门表；
tb_Company：公司表；
tb_Module：系统模块表； tb_Action：系统中所有操作的动作表；
tb_Permit：由tb_Module与tb_Action两表结合产生的系统基本权限表；
tb_Permit_Group：权限组表，将一模块的中的所有权限划分一个权限组中，可以通过权限组授予用户权限；
tb_Role：角色表，基本权限的集合。无上级与下级之分；
tb_Position：职位表，有上级与下级之分；
tb_Project：项目组表，tb_Role_Permit：角色授权表；
tb_Postion_Permit：职位授权表；
tb_Project_Permit：项目授权表；
tb_Project_User：项目成员表，IsLead字段代表此成员为项目组长；
tb_Postion_User：职位成员表；
tb_User_Permit：用户授权表，用户ID与角色、职位、项目及直接授予的权限串表；
权限的产生：
由tb_Module中的ModuleCode与tb_Action中的ActionCode组成权限代码PermitCode=ModuleCode+ActionCode。
实例：ModuleCode=0101，ActionCode=01,则PermitCode=010101。
权限值则有ModuleValue与ActionCode组合而成，采用下划线来连接。实例：ModuleValue=Sys_User,ActionValue=AdD，PermitValue= Sys_User_Add 权限组：
包括一组同一模块下的权限的组合，如管理用户包括基本的权限：添加、删除、修改、查看等，将这些组合起来构成一个用户组——“用户管理”权限组。其它类似。只是为了更方便的查看系统权限与权限的分配。
实例：如管理用户的权限代码为010101à查看用户，010102à添加用户,010103à删除用户，010104à修改用户，010105à审核用户等，将这些基本权限组合起来一个集合而构成了“用户管理”权限组。
角色、职位、项目：
也就是按特定的需要划分一种权限的集合。使用角色授权表、职位授权表、项目授权表来实现。授权表中存放的是权限代码PermitCode,而不是权限组的GroupCode代码。
用户授权：
由用户授权表来实现，用户授权表中的RoleCode、PositionCode、ProjectCode分别是角色表中RoleCode组成的串、职位表PositionCode组成的串、ProjectCode组成的串。与角色授权表中的角色代码RoleCode、职位授权表中PositionCode、项目授权表中的ProjectCode不对应（不是主表与从表之间外键关系）。
从而能够实现了一个用户可以拥有多个角色、多个职位、多个项目的情况。
用户授权表中的PermitCode为直接授权的权限代码串，直接给用户分配权限。
实例：
用户ID为UserId=1的用户权限授权表的记录为： RoleCode=001,003 PostionCode = 001,002 ProjectCode=001,005
PermitCode = 010101,020102
表明此用户拥有两个角色，代码为001和003，并继承这两个角色的权限；
担任两个职位，代码为001与002，并继承两个职位的权限；
属于两个项目组中的成员，项目代码为001与005，并继承两个项目中的权限。直接指定给用户的权限为010101与010102这两个权限代码的权限
用户权限字符串：
关键词：数据库应用程序,数据,操作,权限
1 权限管理
数据库应用程序中存放着大量重要的数据, 这些数据中有些只有系统管理员能操作;有些数据只有相关用户才能进行相应的修改工作, 但没有添加和删除权限;有些数据用户既没有修改权又没有添加和删除权, 只能查看。所以权限的管理对一个数据库应用程序来说是十分重要的。
以往数据库应用程序的权限管理一般都采用系统管理员将所需要的权限添加到权限表, 并将权限分配给每一个用户。这种权限管理方法不够灵活, 在权限数量较多的情况下给系统管理员增加了大量添加、修改和删除等权限管理工作。
利用Delphi应用程序的特点, 使用角色表、角色权限表和用户角色表3个表来管理系统权限。先在角色表中预设教师、学生和系统管理3个角色 (系统管理员默认具有所有权限) , 不够时由系统管理员根据需要添加和修改, 在教师表中预设一个系统管理员的帐号, 自动成为系统管理角色的成员。在应用程序界面显示前 (即Form的OnShow事件中) 将需要设置的所有权限自动添加到角色权限表中, 然后由系统管理员将这些权限分配给不同角色, 再通过角色分配给每一位教师和学生。每个教师自动拥有教师角色, 每个学生自动拥有学生角色。其他的角色由系统管理员添加, 并分配给需要的教师和学生。
1.1 添加权限
为方便程序统一管理角色权限表中的权限, 本系统在主界面显示前将菜单中的每个项目自动添加到角色权限表中, 方法是为角色表中的每个角色遍历菜单中的每个菜单项目, 并将这些菜单项目添加到每个角色中, 供管理员分配使用, 具体通过AddRoleRight过程实现, 代码如下:
因篇幅有限, AddRoleRight过程仅对主菜单中的菜单项设置使用权限, 第48-51行代码用于遍历菜单中的每个主菜单项, 并递归调用SearchSubMenu过程完成每个下级菜单项的遍历工作;第14、16和31行代码用于遍历角色表中的每个角色;第20-29行代码先判断该菜单项目在角色权限表中是否存在, 若不存在则在角色权限表中添加该对象;第38-42行代码表示检测到一个含有子菜单的菜单项目, 则再递归调用SearchSubMenu过程完成其下级所有子菜单项目的检测。如此执行当AddRoleRight调用结束时, 则菜单中的所有菜单项目都自动地添加到ADODataSetRoleRight所指向的角色权限表RoleRight中。
1.2 管理用户角色权限
为管理系统用户的使用权限, 需要添加一个权限管理界面。权限管理界面由系统管理员管理, 负责角色的添加、修改、角色权限的设置、用户角色的分配等工作。
1.2.1 界面设计
成绩管理系统中存在两种用户:教师和学生, 所以设计了一个用户类型列表框供查询使用。每个用户都是某个角色的成员, 每种角色又有不同的角色权限, 故在窗体下部左右两边各放置一个TPageControl分页组件, 每个分页组件设置4个选项页, 分别显示“用户”、“用户角色”、“角色”和“角色权限”信息, 其中左边以表格形式显示, 而右边相对应选项页则显示当面记录的详细信息。权限管理界面如图1和图2所示, 其属性设置见表1所示。
左边的分页对象PageCtrlUser设置了“用户”、“用户角色”、“角色”和“角色权限”4个选项页, 每个选项页上放置一个TDBGrid对象。右边的分页对象PageCtrlInfor与左边的相对应, 也设置了“用户信息”、“用户角色信息”、“角色信息”和“角色权限信息”4个选项页, 每个选项页上对象的设置情况如图1右下部、图2所示, 除“用户角色信息”选项页中的“角色ID”是TCheckListBox对象外, 其他都是数据感知组件, 分别通过DataSource属性指向各自对应的TDataSource对象, DataField属性设置需显示数据的字段名, 具体可参考图2中各个对象中显示的数据, 如DBTextBirthday就表示显示Birthday字段的数据。
1.2.2 代码设计
(1) 因为存在两种不同的用户, 查询时要用到教师信息表和学生信息表, 而这两个表的字段名是不同的, 故在该单元文件的implementation后设计了一个全局变量“strKeyField”用于存放表的关键信息 (用户ID和用户名) 。
var//存放查询所需的关键信息 (用户ID和用户名)
strKeyField:Array[0..1]of String;
(2) 图2左边“用户角色信息”选项页中的“角色ID”CheckListBoxRole对象, 显示的是系统中存在的所有角色及当前用户所拥有的角色信息, 供系统管理员使用打勾方式分配, 因此需要编制一个过程将系统角色表中的所有角色以列表的方式显示在CheckListBoxRole对象的列表框中, 详细代码如下:
(3) 设计查询按钮代码。按不同的用户类型和不同的查询类型, 动态生成SQL语句。如图1右下部的“用户信息”选项页中的“用户ID”DBTextUserID对象、“用户名”DBTextUserName对象和“学院”DBTextUserUnit对象, 在查询教师时要需教师ID、教师名和该教师所在学院;查询学生时则要显示学号、学生名和所在班级, 因此这三个对象需要根据不同的用户设置不同的字段名, 相关代码如下:
(4) 设计PageCtrlUser、PageCtrlInfor分页组件的OnChange事件, 一方面使左右两个分页组件保持联动, 另一方面设置“添加”、“保存”按钮的可用性, 相关代码如下:
(5) 当角色表中的记录添加和修改后, 需要刷新CheckListBoxRole对象中的角色项, 因此需要设计ADODataSetRole角色数据集的AfterPost事件, 相关代码如下:
(6) 当用户表中的记录位置发生变化后, 需要更新ADODataSetUserRole用户角色数据集为当前用户所具有的角色, 并在CheckListBoxRole对象中设置该用户所拥有的角色, 因此需要设计ADODataSetUserRole角色数据集的AfterScroll事件, 相关代码如下:
(7) 设计“保存”按钮代码, 保存添加的角色、当前用户所拥有的角色和角色权限信息, 相关代码如下:
(8) 当需要添加角色时, 需要设计“添加”按钮, 相关代码如下:
(9) 当界面显示时, 需要初始化界面对象的属性, 并自动设置ADODataSet_User对象的AfterScroll事件和ADODataSetRole对象的AfterPost事件, 因此需要编制FormRightManage的OnShow () 事件, 相关代码如下:
(10) 退出界面时, 释放OnShow () 事件中动态设置的事件关联, 并关闭临时使用的ADODataSet_User, 因此需要编制FormRightManage的OnClose () 事件, 相关代码如下:
用户角色权限管理界面运行后的效果如图3、4、5和6所示。
在图4中可以分配相关用户所拥有的角色;在图5中可以添加或修改系统中存在的角色;在图6中可以对每个角色分配相关对象的使用权限。
1.3 设置用户权限
当用户登录成功后, 需要按系统管理员分配给该用户的角色动态设置该用户所具有的使用权限, 该过程由系统主界面的OnShow () 事件调用, 相关代码如下:
2 用户登录
对一个数据库应用程序来说, 用户登录是必不可少的。用户登录不仅是为了系统安全, 也是为了设置登录用户的系统使用权限。
登录时, 设置了一个计数器, 用于对用户登录中出现的输入错误进行计数, 当超过一定次数时, 系统将退出。因此在登录界面类中定义一个计数变量, 在登录界面的OnShow事件中进行初始化, 并编制“登录”按钮的OnClick事件, 进行用户登录的判定。用户登录界面如图7所示。
(1) 定义计数变量。在登录界面类的private (私有数据定义一个LoginCount变量:
LoginCount:Integer;//输入计数器
(2) 编制登录界面的OnShow事件, 完成界面的初始化:
(3) 编制“登录”按钮的OnClick事件。完成用户的登录工作, 并设置登录用户的系统使用权限, 代码如下:
3 系统主界面
本系统的各个功能模块通过主界面上的各个菜单项加以实现, 在主界面中加入一个TMainMenu组件, 其属性设置见表2所示, 界面如图8所示。
在进入系统主界面前, 需要打开与用户登录、用户权限设置等相关的角色权限表、角色表实现用户登录;完成自动添加角色权限、设置登录用户权限等工作, 因此需要设计主界面的OnShow事件, 相关代码如下:
其他的各个菜单项分别使用一个界面 (若干模块) , 用于实现相应的功能, 这里以本文中要实现的“教师信息”、“任课教师安排”、“课程成绩”和“查询与统计”等任务为例加以说明, 其他的读者可以参考编写, 也可下载本系统源代码加以模仿。
(1) “教师信息”菜单项OnClick事件的代码如下:
(2) “任课教师安排”菜单项OnClick事件的代码如下:
(3) “课程成绩”菜单项OnClick事件的代码如下:
(4) “查询与统计”菜单中的各个子菜单项的OnClick事件采用了事件共享技术, 共用NSearchClick事件, 通过菜单项对象的Tag属性值加以识别。“查询功能”菜单项OnClick事件的代码如下:
(5) 最后编写主界面的OnClose事件, 系统退出时关闭打开的数据集, 代码如下:
相关用户登录后, 系统将按管理员分配给他的用户权限设置菜单项的可用性, 如图9所示。
4 总结
系统的使用权限涉及到系统数据的安全, 因此是数据库应用系统必须要考虑的问题, 文中给出了一个对象使用权限自动添加和设置的通用过程和函数, 并提供一个用户权限分配界面, 用于完成登录用户使用权限的分配与管理。由于篇幅有限, 本文仅给出了菜单项对象的使用权限分配, 但已预留了接口, 读者可以参考AddRoleRight和SetObjRight过程, 设置其他对象的使用权限, 为适合每个界面中对象使用权限的分配和使用, 可以在RoleRight角色权限表中增加一个字段FormClass, 用于表示该对象所在的窗体类, 如此就可以对应用程序中所有窗体类中定义的所有菜单、按钮进行使用权限的分配和管理。
关键词：ERP；权限管理；案例；途径
一、ERP权限管理的概念及其重要性
ERP权限管理的概念及内容。权限管理是ERP上线后系统运维管理的一个重要工作内容，包括用户管理、角色维护与授权、角色参数维护以及ERP内部控制工作等。系统上线后能安全、高效运行的前提是权限运维必须规范，即用户管理规范、授权管理清晰，最终用户的权限设置符合内控部制规范。否则，将产生直接负面影响，轻者业务员无法正常开展业务，重者会导致ERP管理混乱，业务停滞，信息数据泄密，给企业和公司带来损失。可以说，规范的系统权限管理和有力的管控是保证系统安全运行和数据保密的必要手段。因此，构建高效的权限管控体系和规范的授权业务流程是保证系统安全、高效和数据保密的重中之重。
二、ERP权限管理失控导致公司业务混乱，内控审查困难案例
以下两个案例来均自于某国有企业下属某地区公司。案例1. 2011年该地区公司业务人员发现系统中有一笔已建投资项目计划被更改，同时还存在一笔未知投资项目，引起了领导的高度重视和关注，经层层查找，最终发现以上操作是一个未及时关闭的ERP实施期间的大权限账号所操作，但已无法查找创建人。庆幸的是以上两个问题被及时发现和处理，否则将造成了该公司项目投资计划、预算分配混乱，给该公司带来严重的经济损失。案例2.公司在接受总部2012年内控检查时，权限测试结果中发现了互斥及敏感权限达到7万余条，涉及到的用户占总用户数的70%以上，账号权限互斥非常严重，业务和流程混乱。测试结果影响了当年该企业对其下属的地区公司的内控工作和生产业績考核，当年部分工作总额因此被扣除，导致了职工年终奖金下降。
三、原因分析
以上两个案例究其原因，都是由于ERP权限运维混乱、授权失控，管理不规范所造成的。案例1主要是因为ERP上线后，没有规范ERP权限管理，未能及时梳理系统账号，未及时系统实施账号和收回诸如投资项目计划创建之类的受控权限。案例2是由于公司未建立起规范的ERP运维体系，ERP权限管理和内控管理严重脱节，用户账号授权失去控制和监督，用户权限设置不符合职责分离原则所造成。
四、优化ERP系统权限管理，提升管控力的有效途径
（一）建立健全ERP权限管理规章制度。实际上，我们不可能完全通过技术手段来进行权限的维护, 还需要建立起相应的规章制度，理顺、理清权限申请和授权的工作流程，以此来规范和约束权限管理，做到管理有理、有据、流程化、规范化，减少用户和管理员在权限申请和授权过程中主观意识的负面作用，使授权工作过程可控、授权结果合规。
（二）建立清晰、有效的权限控制解决方案。ERP权限控制从事务代码级、组织机构级、权限对象字段值级等三个层次进行。（1）事务代码级控制是授予用户的权限角色中必须包含具有操作某项系统业务所对应事务代码，也就是为其分配的具体角色中须在用户菜单或事务代码中含有该事务代码；（2）组织机构级控制是指用户具有了事务代码的执行权限，还必须具有相应组织的操作权限才能完成业务。实施中需根据实际设计不同性质的组织架构，通过为角色分配不同的公司代码值，将用户的业务限制在不同的公司代码下；（3）权限对象字段值是指用户具有了某事务代码的执行权限和相应组织的操作权限之后，ERP 系统又对相应的操作根据权限对象进一步控制。
（三）建立起清晰的用户岗位职责体系。如何才能快速、高效地解决企业权限管理混乱的现状，就必须在系统中的用户账号和权限申请及权限分配按照“一人一岗”的原则进行。事实上，企业不断追求人力资源最小化，一人承担多个岗位工作是必然的，这种管理现实势必造成人员职责交叉，权限设置混乱就是必然结果。因此，如果没有清晰的岗位职责体系，就无法合理划分各个岗位的职责分工，无法保障用户在工作岗位职责划分合理、合规，符合内部控制规范。最终会出现两种结果，一是为了符合内控规定，系统中授予用户的业务处理权限无法满足用户需求，导致企业生产经营停滞和业务中断；二是为了能维持企业生产经营和业务流程正常进行，用户就会无约束的申请权限，而管理员也无约束的给用户授权，最终导致用户权限分配失控。所以在系统中建立起合理、清晰的岗位设置和职责体系对于解决ERP权限管理混乱的情况是非常重要的。
（四）强化“三部门”沟通协调，畅通用户信息反馈渠道 “三部门”是指ERP系统应用部分、权限运维支持部门。以及人事管理部门。实际上，岗位、职责、权限三者之间的关系是环环相扣的，人员岗位变动引起职责变化，职责变化就意味着权限需要调整，反过来，用户权限调整了就意味着他的岗位和职责发生了变化。这是因为ERP系统用户账号与用户实际岗位和职责绑定的，用户的岗位和业务职责决定了其账号在系统中应分配的角色和权限。但人事岗位调整和分工是由人事管理部门具体操作，业务部门只有建议权，没有处理权，所以在这种情况下，
ERP应用业务部门、人事管理部门和ERP运维支持部门需要建立起有效的沟通协调体系。人事部门和业务部门介入ERP系统的权限管理工作中，一方面人事部门可以及时协调处理人事岗位、职责调整的信息反馈，形成畅通的人事信息反馈机制，当有人员岗位和职责分工调整的情况时，人事管理部门可以及时将相关信息反馈到业务部门和权限管理部门，以便业务部门和权限管理部门能迅速作出反应，及时撤销应该撤销的用户ID，冻结该冻结的ID，变更该变更的业务权限，删除该删除的权限，保证系统运营风险最小化；另一方面人事部门与业务部门可以通过有效的沟通系统，不断梳理、调整、优化部门岗位设置和人员职分工，达到合理分配人力资源。
（五）定期开展ERP账号梳理。ERP用户账号管理是权限管理工作中最基础的工作，因为没有用户账号，根本就不用考虑该业务人员岗位职责是否互相冲突，业务处理权限是否互斥。所以要做好ERP权限管理工作，保证管理程序上清晰、规范，首先就要做好账号管理的规范，因此按照ERP内部控制规范，定期开展ERP账号梳理。这样做可以取得两个方面的好处，一是可以及时关闭和撤销不再需要的用户账号，降低用户账号的闲置率，有效提升账号利用率，减少企业因为存在大量闲置账号而承担不必要的运维费用；二是可以及时清理出存在权限互斥的账号，及时向业务部门反馈，并及时处理，将ERP内控管理要求落实在日常管理中，而不至于在开展内控检查工作前手忙脚乱、头痛以头、脚痛医脚的状况。
（六）内控工作部门全程参与ERP权限管理。内控管理部门在业务上具有业务指导和协助管理的工作职责。国内大多数实施了ERP的企业或公司后，权限运维管理面临一个怪现状，内控管理部门基本上根本未参与ERP权限管理工作，完全脱离ERP内控工作，根本不会关注运维部门具体的执行过程，重点只关注每年的内控审查结果。没有检查就不会关注执行部门是否把ERP内控工作执行的到底怎么样，给用户授权的过程是否可控，用户授权权限是否合规，角色分配是否符合职责分离原则等，往往在内控测试检查出问题后，再要求执行部门去整改。因此，内控管理部门参与到ERP权限管理工作中，做好权限内控测试，把好用户权限申请的第一关是必须的。
综上所述，在ERP系统用户权限设定上，就要充分考虑岗位设置的合理性，对岗位的职能，职责进行科学的区分，优化人力资源合理配置，才能真正做到合理分配用户操作权限和限制用户操作范围，从而保证系统的安全性，数据的完整性。
参考文献：
[1] 孙士学.苏瑞. SAP权限管理浅谈.电脑知识与技术，2011，7(11)：2527-2537.
[2] 张震.张巍钟. ERP 系统权限管理.中国管理信息化，2012，15 (3):53-54.
OA行业发展至今，已经远远超过了传统意义上的“无纸化办公”，或“办公自动化”等老概念所描述的应用。新兴的OA系统在智能性、整合性应用上已经取得了突破性的进展，这时行业已经找到一个更贴切的词语来替代OA，那就是“协同”。
(中国软件网讯)OA行业发展至今，已经远远超过了传统意义上的“无纸化办公”，或“办公自动化”等老概念所描述的应用。新兴的OA系统在智能性、整合性应用上已经取得了突破性的进展，这时行业已经找到一个更贴切的词语来替代OA，那就是“协同”。
关于“协同”，具体来说包括四大类：人员的协同、流程的协同、数据的协同、资源的协同，构成了企业完整的经营管理活动。其中数据的协同是当前OA系统的应用重点，也就是华天动力最新提出的工作流2.0，其含义是：不但要实现OA系统内部的数据整合，又实现OA系统和其他业务系统之间的数据整合，消除信息孤岛，减少重复工作。
说到OA系统的数据整合，其实这些年来厂商和用户一直在热烈探讨，却缺乏实践案例。为了填补这个空白，最近华天动力发布了一系列数据整合方面的案例，包括借款与报销、预算与费用等，这次我们看到的是一个关于请假管理方面的数据整合应用。
简单的请假管理流程，为什么还要进行数据整合呢?在华天动力OA办公系统中，请假单可以直接关联请假人的请假历史。无论这个请假记录是保存在OA系统中，还是HR系统中，都可以自动提取过来，为审批人提供决策依据，一项小的改进可以大大提升工作的便利性。
如下图一所示，是大连富强企业集团在华天动力OA系统中使用的“病假请假申请单”，申请人在填写这个表单的时候，能够直接看到自己一年内的请假历史。这些数据来自于OA系统内部，是对以往审批完成的请假单的汇总，根据这个请假历史，申请人就可以更合理的安排自己的假期。
南京苏欣三采软件科技有限公司
Tel: 025-66915810
Fax: 025-83676150 E-mail：suxinsancai@163.com Http：
地址：南京建邺区新安江街80号西堤国际西堤坊6-602
图一：OA系统内部请假数据关联
而如下图二所示，这是上海利众集团在华天动力OA系统中使用的“员工请假申请单”，这张表单主要用于由申请人给自己的下属提交请假申请。申请人在填写申请单时，只要输入员工的工号，系统就会自动从HR系统中提取该员工的姓名、部门、职务，同时该员工的所有请假记录也被提取过来，一目了然，为申请人和审批人提供了准确的参考。
图二：OA系统外部请假数据关联
显然，OA系统自动从系统内、外提取请假记录，直接显示在申请单上，对审批人来说是非常有用的。比如人事部经理在审批一个请假单的时候，发现某员工近期频繁的请病假，那么到底是该员工真的生病了，还是另有原因呢?他可以找来该员工的主管了解情况，如果真的是生病了，就建议员工好好检查一下;如果是另有原因，就调查一下到底是怎么回事，以便及时解决问题，防止突发事件。
可以想象，如果申请单上没有员工的请假历史记录，那么审批人就要完全靠自己的脑袋去记忆了，想起来了还好，想不起来可能就做出了错误的审批，掩盖了问题。当一个公司有几百、几千、甚至几万人的时候，再好的脑袋恐怕也靠不住了。
可见，OA系统的数据整合并非石破天惊的应用，而是解决了企业中点点滴滴的实际问题。这种应用就像水泥一样，用来抹平、粘合石头和砖块之间的缝隙，让大厦更加牢固，让企业更加健康。
南京苏欣三采软件科技有限公司
Tel: 025-66915810
Fax: 025-83676150 E-mail：suxinsancai@163.com Http：
为什么这不是好想法
这样一来，会有什么隐患呢?咱们不妨先说说这个事实：用户没有经过相应的培训，所以并不了解CRM系统错综复杂的细节。他们不知道自己看似无关紧要的改动会带来什么样的危害。他们也不知道安全模型、对象模型、外部集成或工作流程。即便他们只是想在屏幕上移动某个文件，操作不当也会给他们根本不知道存在的用户和业务流程造成严重破坏。
幸运的是，没有受过培训的管理员不可能真正破坏许多现有数据。当然，他们偶尔会破坏，但他们在试图更改数据时，这些数据通常只是他们自己的记录而已。只要你启用审计跟踪记录功能DD比如Salesforce.com的历史跟踪，重现破坏活动就相当容易。对安装的任何重要系统而言，绝对需要定期备份所有CRM系统的数据和元数据。
比数据破坏更值得关注的是这种风险：超级用户查看本该在其权限范围之外的数据。CRM系统与IT基础架构之间的集成度越高，管理员能够看到的敏感信息就越多，他们无意中违反的流程控制也就越多。这可能包括公司总体订购预测、库存、合同、委托任务，甚至还有员工的家庭电话号码，
就算你不是律师，一想到这方面潜在的监管和法律问题，也会不寒而栗。
正确的办法
幸好，这方面有一些清晰的最佳实践。首先就是“敢于说不”。即便某个经理或用户有充足理由需要一些特殊的权限，负责CRM系统的管理员数量也应当严格加以控制。我还没有找到哪个充足的理由说一家企业的CRM管理员应当超过六人DD假设这家企业在全球全天候不间断开展经营。作为贵公司的《萨班斯-奥克斯利法案》第409条款流程文档的一部分，要具体明确管理员的角色和权限。成为管理员就意味着需要接受大量的脱产培训和在岗培训，而且不能由临时工和兼职工来担任管理员这个岗位。
系统管理员的角色需要包括至少一个人充当数据管理员，其职责是通过控制设计和外部数据输入，密切关注数据的健康状况和干净程度。如果你的CRM系统与其余IT系统高度集成，CRM数据管理员就应当是负责管理完善政策、流程控制和系统变更的配置控制委员会的一员。考虑到干净数据对CRM成功的重要性，我经常惊讶地发现很少有客户认识到需要设立数据管理员。
应利用你CRM系统的安全功能为管理任务和访问设立授权机制。比方说，许多营销用户可能需要读取一系列广泛的数据;几个用户需要能够使用批量导入工具。而这并不意味着他们就应该是超级用户。可以为这些用户创建特定的配置文件，并授予管理权限，然后限制他们的登录时间/位置，以便控制滥用风险。
第一章 总则
第一条 为加强信息系统用户账号和权限的规范化管理,确保各信息系统安全、有序、稳定运行，防范应用风险，特制定本制度。
第二条 本制度适用于场建设和管理的、基于角色控制和方法设计的各型信息系统，以及以用户口令方式登录的网络设备、网站系统等。
第三条 信息系统用户、角色、权限的划分和制定，以人力资源部对部门职能定位和各业务部门内部分工为依据。
第四条 场协同办公系统用户和权限管理由场办公室负责，其他业务系统的用户和权限管理由各业务部门具体负责。所有信息系统须指定系统管理员负责用户和权限管理的具体操作。
第五条 信息系统用户和权限管理的基本原则是：
（一）用户、权限和口令设置由系统管理员全面负责。
（二）用户、权限和口令管理必须作为项目建设的强制性技术标准或要求。
（三）用户、权限和口令管理采用实名制管理模式。
（四）严禁杜绝一人多账号登记注册。
第二章 管理职责
第七条 系统管理员职责
负责本级用户管理以及对下一级系统管理员管理。包括创建各类申请用户、用户有效性管理、为用户分配经授权批准使用的业务系统、为业务管理员提供用户授权管理的操作培训和技术指导。
第八条 业务管理员职责
负责本级本业务系统角色制定、本级用户授权及下一级本业务系统业务管理员管理。负责将上级创建的角色或自身创建的角色授予相应的本级用户和下一级业务管理员，为本业务系统用户提供操作培训和技术指导，使其有权限实施相应业务信息管理活动。
第九条 用户职责
用户须严格管理自己用户名和口令，遵守保密性原则，除获得授权或另有规定外，不能将收集的个人信息向任何第三方泄露或公开。系统内所有用户信息均必须采用真实信息，即实名制登记。
第三章 用户管理
第十条 用户申请和创建
（一）申请人在《用户账号申请和变更表》上填写基本情况，提交本部门负责人；
（二）部门负责人确认申请业务用户的身份权限，并在《用户账号申请和变更表》上签字确认。
（三）信息系统管理部门经理进行审批后，由系统管理员和业务员创建用户或者变更权限。
（四）系统管理员和业务管理员将创建的用户名、口令告知申请人本人，并要求申请人及时变更口令；
（五）系统管理员和业务管理员将《用户账号申请和变更表》存档管理。
第十一条 用户变更和停用
（一）人力资源部主管确认此业务用户角色权限或变更原因，并在《用户账号申请和变更表》上签字确认；
（二）执行部门主管确认此业务用户角色权限或变更原因，并在《用户账号申请和变更表》上签字确认；
（三）系统管理员变更
系统管理员变更，应及时向上级系统管理员报告，并核对其账户信息、密码以及当时系统中的各类用户信息及文档，核查无误后方可进行工作交接。新任系统管理员应及时变更账户信息及密码。
（四）业务管理员变更
业务管理员变更应及时向本级系统管理员及上级业务管理员报告，上级业务管理员和系统管理员及时变更业务管理员信息。
（五）用户注销
用户因工作岗位变动，调动、离职等原因导致使用权限发生变化或需要注销其分配账号时，应填写《用户账号申请和变更表》，按照用户账号停用的相关流程办理，由系统管理员和业务管理员对其权限进行注销。
第四章 安全管理
第十二条 使用各信息系统应严格执行国家有关法律、法规，遵守公司的规章制度，确保国家秘密和企业利益安全。
第十三条 口令管理
（一）系统管理员创建用户时，应为其分配独立的初始密码，并单独告知申请人。
（二）用户在初次使用系统时，应立即更改初始密码。
（三）用户应定期变更登陆密码。
（四）用户不得将账户、密码泄露给他人。
第十四条帐号审计
账号审计工作由信息系统管理部门的负责人或者主管进行审计，并应定期向其领导进行汇报，由场信息系统管理部门负责人定期和不定期检查。
第十五条 应急管理
（一）用户及业务管理员账户信息泄露遗失
用户及业务管理员账户信息泄露遗失时，应在24小时内通知本级系统管理员。本级系统管理员在查明情况前，应暂停该用户的使用权限，并同时对该账户所报数据进行核查，待确认没有造成对报告数据的破坏后，通过修改密码，恢复该账户的报告权限，同时保留书面情况记录。
（二）系统管理员账户信息泄露遗失
系统管理员账户信息泄露遗失时，应立即向上级系统管理员报告，暂停其系统管理员账户权限，同时对系统账户管理及数据安全进行核查，采取必要的补救措施，在最终确认系统安全后，方可恢复其系统管理员账户功能。
第五章 附则
第十六条 本制度自2013年月日起施行。
企业资源计划(Enterprise Resource Planning)是以MRP II(企业制造资源计划)为基础的企业管理软件。 是将企业所有资源进行整合集成管理,包括:物流、资金流、信息流进行全面一体化管理的管理信息系统。 ERP以流程管理的理念,打破了传统以职能管理为核心的管理模式, 把客户需求和企业内部的制造活动以及供应商的制造资源整合在一起, 形成企业一个完整的供应链,其核心管理思想主要体现在以下三个方面:①体现对整个供应链资源进行管理的思想;②体现精益生产、敏捷制造和同步工程的思想;③体现事先计划与事前控制的思想。 任何多用户的系统均不可避免地涉及权限问题,而ERP的权限系统也更为复杂。
1权限总体设计
企业级应用环境中的权限设计主要有三种: 自主性访问控制、强制性访问控制和基于角色的访问控制,其中自主式控制能力太弱、强制式控制太强,两者工作量大且不方便管理,基于角色的访问控制是目前公认的解决大型企业级系统的权限管理的有效方法。 可以有效减少权限管理的复杂性,提供企业权限管理的灵活性。
权限体系引用了账号、角色、参数文件、授权对象、字段等权限概念, 结合系统中企业组织架构及业务处理的配置等对用户进行权限控制。 同时也通过设计大量的数据表记录各事务处理的权限检查情况及系统用户的授权情况。 其中:
用户登录ERP时需输入的用户名称。 用户的创建一般在基本的ID等之外,需要维护包括姓名、身份、通讯信息等。
单一角色简单的说就是一个操作功能的集合。其中包含了控制功能操作的“权限对象”“权限字段”以及允许的操作及允许的值。
复合角色又叫通用角色,即多个单一角色的集合。 复合角色中可以包含多个单一角色, 此复合角色包含了多个单一角色所控制的权限。
2权限实施与管理
ERP的权限管理主要由权限设计、权限测试、权限反向查找和建立权限管理运维制度等几个方面的工作组成。
2.1 权限设计
ERP项目的权限设计严格遵守ERP系统的权限设计标准,其步骤如图1 所示。
(1) 从客户需求出发, 根据前期的业务蓝图成果, 明确各部门、岗位的职责。
(2)根据岗位职责进行通用角色权限设计,如工资数据维护角色、合同信息查询角色。
(3)根据通用角色权限设计进行复合角色设计,如人力资源部劳动组织专责角色。
(4) 根据复合角色结果提供权限模板, 进行用户收集, 并将用户名与角色匹配。
在设计的过程中,注意以下关键点:
(1) 下级不能查看上级的各类信息, 而上级可查看下级的,同级不可互看。
(2)在人员管理范围上,按照企业管理的职务级别分层次管理。
(3) 在人事信息类型管理上, 本着 “ 谁管理谁维护” 的原则,在保证各部门、各岗位必需的权限的同时,尽量紧缩角色授权。
(4)对部分高度保密的信息,如后备干部、人员薪资等信息,确保授权与实际岗位职责准确匹配。
2.2 权限测试
(1)针对通用角色和复合角色,重点考察其配置结果是否符合预期设计,能否实现要求的业务操作。
(2)针对最终用户岗位角色,重点考察其不应当具备哪些权限,然后测试在应当具备的权限中是否能正常执行业务操作。
(3) 从信息类型的角度, 重点考察后备干部信息、 薪资信息等保密性强的信息类型,测试拥有该信息类型的用户是否恰当。
(4)为保证测试更全面、准确要学会利用反过来查找有哪些用户拥有这些命令和信息查看的权限。
3权限运行与管理
在ERP上线后, 需要通过如下措施监控权限变更情况以及系统数据的访问情况,确保数据安全和权限严格管理。
(1)ERP用户审计。 在ERP生产系统中, 启用用户审计机制,对所有用户执行的交易代码和报表进行记录,对发现的异常及时处理, 并检查同类用户的权限设计是否合适以及权限管理流程的合理性。
(2)ERP敏感表更改记录。 在ERP生产系统中,启用ERP敏感表的更改记录机制, 对设定的某些ERP的表的更改进行日志记录,可以用作日常的运维报告和以后的查询。 针对异常检查开发及运维角色的权限管理是否存在漏洞。
(3)权限和用户变更记录。运维人员可以通过ERP的权限和用户变更记录工具,随时查询用户和权限的变更时间、变更内容和变更人员。
(4)对照权限设计文档检查此用户权限是否正常。
(5) 如果不正常, 通过权限和用户变更记录, 查找变更情况和变更人。
(6)查看变更记录单。
(7)查看权限变更人员操作记录。
4结语
ERP权限的重要性是毋庸置疑的,但在运行过程中,大多不太重视权限, 主要的原因是在上线期间以及上线后的短期内负面效果往往体现不出来,突发的权限问题也可以立即处理掉。这样做很可能在一段时间之后ERP系统的权限管理者会忽然发现在不知不觉中权限管理已经变成了无序的状态, 各种流程也变成了一种形式。在ERP的实施过程中多投入一点儿关注,就会为以后系统的健康使用打下良好的基础。
摘要：本文通过企业资源管理系统(ERP)项目实施的总结和汇总,对ERP的权限管理进行规范化的管理实施策略,形成一套比较成熟并长期可用的数据安全保障屏障。本文介绍ERP在权限管理的架构,设计思路,实施方法和整体权限的策略。讨论了ERP的权限工作日常需严格遵守的实施标准和比较优秀的做法,并根据系统建立一套由用户、运维人员、业务专业人员和技术专业人员共同参与的权限管理机制。
关健词:AJAX;WebGIS;权限管理系统
中图分类号:TP311.52 文献标识码:A文章编号:1007-9599 (2010) 04-0000-03
Design&Implementation of WebGIS Access Control System Based on NET&AJAX
Zhong Weixiong
(China Geosciences University,Information Engineering College, Wuhan430074,China)
Abstract:This article has elaborated in detail the whole process of how to design and realize the Access Control system under the .NET platform using the AJAX technic,including the site verification mode,the site login way,the Access Control management's database design,the Access Control navigation tree's design,the interface of Access Control management’s design and so on. The author also has proposed the different methods for each step,and contrasted various methods good and bad points, in order to seeking one kind the Access Control system which is most suitable for WebGIS application, in aspects such as security, flexibility, integrity,maintainability and so on.
Keywords:AJAX;WebGIS;Access Control System
GIS是一门集计算机科学、信息科学、现代地理学、测绘遥感学、地图学、环境科学、城市科学、空间科学和管理科学等为一体的新兴学科[2],WebGIS是Internet技术应用于GIS开发的产物[3]。由于GIS的地理底图数据和属性数据本身就涉及到安全与机密问题,加上Internet这个复杂的环境,使得WebGIS的网络安全和权限管理显得尤为重要,另外GIS应用的特殊性,在权限管理系统的设计和实现上也有其特殊的要求。
一、站点验证方式
.NET框架下,ASP.NET提供了四种用户验证方式:Windows身份验证(Windows)、窗口身份验证(Forms)、Passport验证(Passport)以及IIS身份验证(None)[4]。对比四种验证方式,在WebGIS应用下,最适用的就是Forms验证方式。该方式在虚拟目录的web.config文件中设置,具体如下:
首先,指定应用程序或目录的验证类型:
然后,设置禁止所有非登陆用户访问:
最后,再设置非登陆用户可以访问的个别目录或文件:
至此,站点的验证方式就设置好了,但是这只是第一步。
二、站点登陆方式与设计
站点登陆采用单点登录(Single Sign On)方式,单点登陆简称SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制[5]。单点登录采用用户认证凭证ticket,ticket合法则通过验证,这样用户可以在不再次登陆的情况下访问本系统的其它系统。具体设置简介如下:
FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket(1, 用户名,时刻,时间,
false,角色名,"/");//创建一个ticket
string HashTicket = FormsAuthentication.Encrypt(Ticket);//对该ticket进行加密
HttpCookie UserCookie = new HttpCookie(FormsAuthentication.FormsCookieName,
HashTicket);//新建一个cookie
Context.Response.Cookies.Add(UserCookie);//将该cookie写入Response
登陆界面的设计有两种方式,一种是直接利用asp.net自带的登陆控件,这种控件直接集成了用户注册,登陆,忘记密码,登陆后根据权限的不同而显示不同的页面等功能。另一种方式是自己编写组合登陆控件。显然,前一种方式编写容易,但不够灵活,不能满足具体的需求,后一种方式是我要重点介绍的。
在站点登陆里,从安全角度考虑,我们必须设置验证码验证,以防止机器软件注册登陆;从用户体验角度考虑,我们必须使用AJAX技术,给用户即时提示而不刷新页面。如图1所示,2JPN验证码是在后台用C#随机生成的图片,防止机器狗注册和登陆。而根据用户输入不同的内容给出不同的即时提示如“用户名长度不对”等,以及当信息没填完整时登陆按钮是发灰的,都是采用的AJAX技术,用来增强用户体验。
图1使用AJAX技术和验证码的站点登录
三、权限管理设计
权限管理,我们采用windows系统经典的用户、角色、权限方式。可以简单表述为:判断“Who对What(Which)进行How的操作”[6]。即每个用户都属于某个或多个角色,每个角色都拥有一个或多个权限。把它想象成单位的人员管理,即每个员工都属于某个或多个部门,每个部门都拥有一个或多个权利,就很好理解了。
.NET框架下,实现用户、角色、权限的权限管理有两种方式:
一是采用asp.net中新引进的框架membership,利用Web站点管理工具来创建新的用户和角色,以及控制对Web应用程序中页面的访问。使用该工具能使不具备编程技巧的用户都可以方便地通过拖拉控件来配置Web应用程序,再加以少量的代码,就可以完全实现对用户、角色、权限等的管理。这一种方式有其致命的缺点,就是数据库必须用SqlServer,而且角色和权限的配置也不能完全满足WebGIS的应用。
另一种是自行建库,自行编码。该方式可扩展性好,适合任何数据库,可以完全满足WebGIS权限管理的要求。该方式的实现如下:
(一)数据库设计
在数据库中建立五个表,其中三个信息表:用户表(User)、角色表(Role)、权限表(Module);两个关系表:用户角色表(UserRole)、角色权限表(RoleModule)。如图2所示。
图2权限管理系统的数据库表
(二)登陆后跳转的页面:获取已登陆的用户名,并转换为相应的角色名。代码如下:
userName = Context.User.Identity.Name;//获取当前已登陆用户的用户名
roleName = userRole.UserID2RoleName(userName);//查询数据库UserRole表,获取角色名
(三)权限设置导航树:对相应的角色进行权限的控制
对于通常的应用,我们可以直接查询数据库表RoleModule获得角色和权限的对应关系,但对于WebGIS应用的特殊性,可以采用更为直观的方式,即采用XML文件方式:将地图数据资源的名称以树节点的形式存储在XML文件中,通过更改和读取该XML文件的每个树节点
-
这样,可以直观的对某个角色值赋予是否拥有导航树节点上任意节点的权力。如图3所示,我们选中角色“测试员0512”后,再在导航树上选中roalk.wl、roalk.wt、roalk_hig.wl节点,点击确定后即给角色“测试员0512”赋予了拥有roalk.wl、roalk.wt、roalk_hig.wl节点的权限值。
对于节点树的构造,我们推荐使用AJAX方式动态构造,这样的好处是,点击某个节点展开其子节点时,页面不刷新,即提高了效率,又增强了用户体验[7]。
图3权限设置导航树
四、权限管理界面
权限管理界面是为超级管理员对各种用户、角色、权限、用户角色、角色权限进行任意增、删、改、查询等操作提供的一个可视化管理界面。如图4所示。至此,一个完整的权限管理系统就呈现出来了。
图4权限管理界面
五、结束语
GIS的地理底图数据和属性数据本身就涉及到安全与机密问题,加上Internet这个复杂的环境,WebGIS的网络安全和权限管理显得尤为重要。本文探讨的基于.NET和AJAX的WebGIS权限管理系统适用于绝大部分WebGIS应用,可以将该系统成熟之后提取出来,作为一个公用的模块,这样,在以后实际的项目开发中可以复用该模块,避免重复开发,节省开发成本。
参考文献:
[1]宋振.基于角色和任务的权限管理扩展模型研究及应用[D].中国优秀硕士学位论文全文数据库,2008,11
[2]吴信才.地理信息系统原理与方法[M].北京:电子工业出版社,2002
[3]黄颖._NET和VML及脚本技术在WebGIS系统地图文档显示中的应用[J].测绘科学,2006,(7):130-132
[4]王勇,尹凡,雷俊.ASP.NET两种身份验证方式及比较[J].电脑知识与技术(学术交流),2007,1(4)
[5]http://baike.baidu.com/view/809410.htm?fr=ala0_1
[6]http://www.jdon.com/jivejdon/thread/7309
[7]彭建伟.Ajax技术在WebGIS中的应用研究[D].中国优秀硕士学位论文全文数据库,2008,(02)
作者简介:钟伟雄(1978-),男(汉族),湖北仙桃人,硕士生研究生,专业:地图制图学与地理信息工程,主要研究方向:WebGIS。
【oa系统权限管理】推荐阅读：
NC系统用户及权限管理制度11-18
Linux操作系统的权限代码分析06-29
oa日程管理系统12-22
oa办公系统管理制度10-19
OA办公系统使用管理制度11-24
OA与档案管理系统集成文档01-01
酒店经理权限管理制度05-30
权限管理作业指导书06-09
质量管理部权限和职责07-01
