后台管理系统的权限设计该怎么做

由于每次开发新项目都需要一个权限管理系统，为了解决重复开发让成本增加的问题，特此开发一套狼奔权限管理系统。 狼奔权限管理系统是一个项目的基础，也是复用性最高的模块，新项目可以基于此模块开发。 系统登录 提供了登陆狼奔权限管理系统的功能。 用户必须指定用户名。如果用户没有录入登陆用户名，则提示用户“请填写 用户名” 用户必须指定验证码。如果用户没有录入登陆验证码，则提示用户“验证码 错误！” 如果用户录入的用户名称或者密码不存在，提示用户“用户名或者密码出 错。” 用户密码需要使用“”加密显示。 用户密码区分大小写。 如果用户录入的用户名

基于RBAC模型的权限管理系统的设计和实现0 引言管理信息系统是一个复杂的人机交互系统，其中每个具体环节都可能受到安全威胁。构建强健的权限管理系统，保证管理信息系统的安全性是十分重要的。权限管理系统是管理信息系统中可代码重用性最高的模块之一。任何多用户的系统都不可避免的涉及到相同的权限需求，都需要解决实体鉴别、数据保密性、数据完整性、防抵赖和访问控制等安全服务(据ISO7498-2)。例如，访问控制服务要求系统根据 *** 作者已经设定的 *** 作权限，控制 *** 作者可以访问哪些资源，以及确定对资源如何进行 *** 作。目前，权限管理系统也是重复开发率最高的模块之一。在企业中，不同的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只满足自身系统的权限管理需要，无论在数据存储、权限访问和权限控制机制等方面都可能不一样，这种不一致性存在如下弊端：a系统管理员需要维护多套权限管理系统，重复劳动。b用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证。c由于权限管理系统的设计不同，概念解释不同，采用的技术有差异，权限管理系统之间的集成存在问题，实现单点登录难度十分大，也给企业构建企业门户带来困难。采用统一的安全管理设计思想，规范化设计和先进的技术架构体系，构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统，使得权限管理系统真正成为权限控制的核心，在维护系统安全方面发挥重要的作用，是十分必要的。本文介绍一种基于角色的访问控制RBAC（Role-Based policies Access Control）模型的权限管理系统的设计和实现，系统采用基于J2EE架构技术实现。并以讨论了应用系统如何进行权限的访问和控制。 1 采用J2EE架构设计采用J2EE企业平台架构构建权限管理系统。J2EE架构集成了先进的软件体系架构思想，具有采用多层分布式应用模型、基于组件并能重用组件、统一完全模型和灵活的事务处理控制等特点。系统逻辑上分为四层：客户层、Web层、业务层和资源层。a 客户层主要负责人机交互。可以使系统管理员通过Web浏览器访问，也可以提供不同业务系统的API、Web Service调用。b Web层封装了用来提供通过Web访问本系统的客户端的表示层逻辑的服务。c 业务层提供业务服务，包括业务数据和业务逻辑，集中了系统业务处理。主要的业务管理模块包括组织机构管理、用户管理、资源管理、权限管理和访问控制几个部分。d 资源层主要负责数据的存储、组织和管理等。资源层提供了两种实现方式：大型关系型数据库（如ORACLE）和LDAP（Light Directory Access Protocol，轻量级目录访问协议）目录服务器（如微软的活动目录）。2 RBAC模型访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么[1]。企业环境中的访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，二者工作量大，不便于管理[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1减小授权管理的复杂性，降低管理开销；2灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。 a RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、 *** 作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。b RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。c RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。d RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。3核心对象模型设计根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型。对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、 *** 作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：a 控制对象：是系统所要保护的资源（Resource），可以被访问的对象。资源的定义需要注意以下两个问题：1资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。2这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑：一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例 *** 作，可以修改属于自己管辖的信息内容。另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。b权限：对受保护的资源 *** 作的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略（Access Strategy）和资源类别相关，不同的资源类别可能采用不同的访问模式（Access Mode）。例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个数据集的可修改访问模式就包含了可查询访问模式。c用户：是权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。d用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。e角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。f *** 作：完成资源的类别和访问策略之间的绑定。g分配角色权限PA：实现 *** 作和角色之间的关联关系映射。h分配用户角色UA：实现用户和角色之间的关联关系映射。该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于 *** 作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。4 权限访问机制权限管理系统端：提供集中管理权限的服务，负责提供用户的鉴别、用户信息、组织结构信息,以及权限关系表的计算。系统根据用户，角色、 *** 作、访问策略和控制对象之间的关联关系，同时考虑权限的正负向授予，计算出用户的最小权限。在业务逻辑层采用Session Bean实现此服务，也可以发布成Web Service。采用代理Proxy模式，集中控制来自应用系统的所要访问的权限计算服务，并返回权限关系表，即二元组{ObjectId，OperatorId}。应用系统端：可以通过访问能力表CL和访问控制表ACL两种可选的访问方式访问权限管理系统。以基于J2EE框架的应用系统为例，说明访问过程：a首先采用基于表单的验证，利用Servlet方式集中处理登录请求[2]。考虑到需要鉴别的实体是用户，采用基于ACL访问方式。用户登录时调用权限管理系统的用户鉴别服务，如果验证成功，调用权限计算服务，并返回权限关系表，以HashMap的方式存放到登录用户的全局Session中；如果没有全局的Session或者过期，则被导向到登录页面，重新获取权限。b直接URL资源采用基于CL访问方式进行的访问控制。如果用户直接输入URL地址访问页面，有两种方法控制访问：1通过权限标签读取CL进行控制；2采取Filter模式，进行权限控制，如果没有权限，则重定向到登录页面。5 权限控制机制权限所要控制的资源类别是根据应用系统的需要而定义的，具有的语义和控制规则也是应用系统提供的，对于权限管理系统来说是透明的，权限将不同应用系统的资源和 *** 作统一对待。应用系统调用权限管理系统所获得的权限关系表，也是需要应用系统来解释的。按此设计，权限管理系统的通用性较强，权限的控制机制则由应用系统负责处理。由于应用系统的权限控制与特定的技术环境有关，以基于J2EE架构的应用系统为例来说明，系统主要的展示组件是JSP页面，采用标记库和权限控制组件共同来实现。a 权限标识：利用标签来标识不同级别资源，页面权限标签将标识页面对象。b 权限注册：遍历JSP页面上的权限控制标签，读取JSP的控制权限。通过权限注册组件将JSP页面上的权限控制对象以及规则注册到权限管理信息系统中。c 权限控制：应用系统用户登录系统时，从权限管理系统获得权限关系表之后，一方面，权限标签控制页面展示；另一方面，利用权限控制组件在业务逻辑中进行相应的权限控制，尤其是和业务逻辑紧密联系的控制对象实例的权限控制。6 权限存储机制权限管理系统采用了两种可选的存储机制：LDAP（Lightweight Directory Access Protocol）目录服务数据库和关系型数据库。存储用户信息、组织结构、角色、 *** 作、访问模式等信息。其中，目录服务系统基于LDAP标准，具有广泛的数据整合和共享能力。元目录（Meta-Directory）功能允许快速、简洁的与企业现存基础结构进行集成，解决基于传统RDBMS等用户数据库与LDAP用户数据库的同步问题。7 结语本文论述了一种基于RBAC模型的权限管理系统的实现技术方案。该权限管理系统已成功应用于系统的设计和开发实践，与应用系统具有很好的集成。实践表明，采用基于RBAC模型的权限具有以下优势：权限分配直观、容易理解，便于使用；扩展性好，支持岗位、权限多变的需求；分级权限适合分层的组织结构形式；重用性强。

1
因为雅雅本人用的是WIN7，所以这里就以WIN7为例，XP系统方法也一样，只不过具体设置位置不同。
第一步，新建标准一个标准用户。
win7对账户控制这一方面做的非常的细致，我们可以见了不同类型的账户来保护我们的电脑，自己使用管理员账户，给其他人使用标准用户即可，这样电脑就不会因为 *** 作失误而丢失文件了。
1）打开控制面板——用户账户控制选项。
2）如果你已经设置了管理员账户那么就直接建立一个标准用户即可，如果你连管理员用户都没有的话，建议建立一个属于自己的管理员账户。
3）点击管理其他账户——添加新账户——标准用户。
4）设置标准用户的密码。

信息系统的开发，权限是绕不过的部分，一个优秀的企业系统必然需要搭配合理的权限管理，以保证业务的顺利进行。

所谓权限管理，一般是根据系统设置的安全规则或者安全策略，使用户在整个系统资源下只能访问自己被授权的资源，这样可以在保证数据安全的同时提高系统的使用效率。

常用权限--数据

企业一些重要的资料，比如财务数据，并不需要让员工知晓，这个时候就需要使用“数据权限”给员工授权，授权之后，相关数据就可以只给特定的员工查看。

常用权限--功能

和数据权限同样的道理，不同岗位的员工需要不同的功能权限，比如给张三赋予一个“销售经理”的角色，这个角色具有查询、添加、修改、删除销售部门员工的权利。那么张三就能够进入系统，进行此类的 *** 作，若没有赋予这个角色，则没有这些权限。

权限示例

一般来说，权限系统会提供以下功能：

1角色管理界面，由用户定义角色，给角色赋予权限；

2用户角色管理界面，由用户给系统用户赋予角色。

一个很简单的例子，比如你开过个人淘宝店，系统上就有众多权限管理功能，比如给客服开通商品的上传、删除权限。

权限应尽可能详细，除了为主体授权，还应可以为部门、岗位、角色等授权。

例如，在角色管理界面我们能看到系统上相关角色的记录，管理员可以对角色进行增删改查，并为特定的角色赋权。

在“更多”这里，会出现各种需要授权的模块，访问过滤则为IP和时段控制。

当选择功能授权，进入下图界面，勾选需要授权的功能模块即可。

到这里，角色功能的授权就完成了。

当然，权限的使用通常要配合流程和表单等基础功能，这里不再演示，完整功能可搜索“learun”进行在线体验。

根据用户的使用过程体验，可以将 Android 涉及的权限大致分为如下三类：

（1）Android 手机所有者权限：自用户购买 Android 手机后，用户不需要输入任何密码，就具有安装一般应用软件、使用应用程序等的权限；

（2）Android root 权限：该权限为 Android 系统的最高权限，可以对所有系统中文件、数据进行任意 *** 作。出厂时默认没有该权限，需要使用 z4Root 等软件进行获取，然而，并不鼓励进行此 *** 作，因为可能由此使用户失去手机原厂保修的权益。同样，如果将 Android 手机进行 root 权限提升，则此后用户不需要输入任何密码，都将能以 Android root 权限来使用手机。

（3）Android 应用程序权限：Android 提供了丰富的 SDK（Software development kit），开发人员可以根据其开发 Android 中的应用程序。而应用程序对 Android 系统资源的访问需要有相应的访问权限，这个权限就称为 Android 应用程序权限，它在应用程序设计时设定，在 Android 系统中初次安装时即生效。值得注意的是：如果应用程序设计的权限大于 Android 手机所有者权限，则该应用程序无法运行。如：没有获取 Android root 权限的手机无法运行 Root Explorer，因为运行该应用程序需要 Android root 权限。

Android 系统权限定义

Android 系统在 /system/core/private/android_filesystem_configh 头文件中对 Android 用户 / 用户组作了如下定义，且权限均基于该用户 / 用户组设置。

值得注意的是：每个应用程序在安装到 Android 系统后，系统都会为其分配一个用户 ID，如 app_4、app_11 等。以下是 Calendar 和 Terminal 软件在 Android 系统中进程浏览的结果（其中，黑色字体标明的即为应用分配的用户 ID）：

在 Android 系统中，上述用户 / 用户组对文件的访问遵循 Linux 系统的访问控制原则，即根据长度为 10 个字符的权限控制符来决定用户 / 用户组对文件的访问权限。该控制符的格式遵循下列规则：

第 1 个字符：表示一种特殊的文件类型。其中字符可为 d( 表示该文件是一个目录 )、b( 表示该文件是一个系统设备，使用块输入 / 输出与外界交互，通常为一个磁盘 )、c( 表示该文件是一个系统设备，使用连续的字符输入 / 输出与外界交互，如串口和声音设备 )，“”表示该文件是一个普通文件，没有特殊属性。

2 ～ 4 个字符：用来确定文件的用户 (user) 权限；

5 ～ 7 个字符：用来确定文件的组 (group) 权限；

8 ～ 10 个字符：用来确定文件的其它用户 (other user，既不是文件所有者，也不是组成员的用户 ) 的权限。

第 2、5、8 个字符是用来控制文件的读权限的，该位字符为 r 表示允许用户、组成员或其它人可从该文件中读取数据。短线“-”则表示不允许该成员读取数据。

第 3、6、9 位的字符控制文件的写权限，该位若为 w 表示允许写，若为“-”表示不允许写。

第 4、7、10 位的字符用来控制文件的制造权限，该位若为 x 表示允许执行，若为“-”表示不允许执行。

举个例子，“drwxrwxr--  2 root   root    4096  2 月 11 10:36 lu”表示的访问控制权限（黑色字体标明）为：因为 lu 的第 1 个位置的字符是 d，所以由此知道 lu 是一个目录。第 2 至 4 位置上的属性是 rwx，表示用户 root 拥有权限列表显示 lu 中所有的文件、创建新文件或者删除 lu 中现有的文件，或者将 lu 作为当前工作目录。第 5 至 7 个位置上的权限是 rwx，表示 root 组的成员拥有和 root 一样的权限。第 8 至 10 位上的权限仅是 r--，表示不是 root 的用户及不属于 root 组的成员只有对 lu 目录列表的权限。这些用户不能创建或者删除 lu 中的文件、执行 junk 中的可执行文件，或者将 junk 作为他们的当前工作目录。

Android 应用程序权限申请

每个应用程序的 APK 包里面都包含有一个 AndroidMainifestxml 文件，该文件除了罗列应用程序运行时库、运行依赖关系等之外，还会详细地罗列出该应用程序所需的系统访问。程序员在进行应用软件开发时，需要通过设置该文件的 uses-permission 字段来显式地向 Android 系统申请访问权限。

---