现在的程序，很多涉及到权限这个管理问题。一些稍大的商务软件都会涉及许多的权限，如管理、发表、浏览、收发公告等权限。在程序设计时如何很好的处理这个问题，且看本文提供的一点思路：
安全始终是可信赖的企业应用的基石。
在企业应用中，通常需要控制用户对业务操作的权限管理与控制。稍加分析不难发现这会涉及到这三个对象：用户/角色、动作/操作、授权状态，进一步分析，我们可发现“动作/操作”通常是针对某个特定的对象，譬如 『新增』动作可对应于『采购申请单』也可对应于『销售出库单』等，这些动作对应的对象我们将其称之为“应用模块”。
至此，用户权限系统中的基本逻辑显形：谁（用户/角色）对什么（应用模块）是否具有某项操作（动作）的授权（授权状态：授予-Grant、拒绝-Deny、继承-Revoke）。
使用权限的基本单位，角色是具有一组相同授权的用户的交集。用户与用户之间没有互相隶属的关系，它只可以隶属于角色，角色可以隶属于另一角色，并且可具有多重隶关系。
用户或角色通常具有以下属性：
当然，在实际的商业应用中，可能还需要更多的属性来描述特定的业务需求。
有了用户和角色对象，还必须有一个描述他们之间隶属关系的对象，这样的对象我们称之为“成员关系(Member)”，通常它可能有如下属性：
该“用户编号”和“角色编号”组合唯一约束，这里的“用户编号”可能是一个用户对象的编号，也可能是一个角色对象的编号，而“角色编号”则始终只能对应一个角色对象的编号。一个成员关系对象表示某个用户或角色隶属于另个角色。 在 iSecurityManager® 中通过『成员设置』窗口来设置任何一个用户或角色（系统固定用户和角色除外）所隶属于的角色，也可以通过『角色属性』窗口来设置所属于当前角色的直接下级成员。
在涉及数据库操作的应用中，四个基本操作是“查看(Select)”、“删除(Delete)”、“新增(Insert)”以及“更新(Update)”。在一个企业应用中当然还会有更多其他的操作，尽管这些操作可能最终都基于这四个基本操作，也可能是其他的非数据操作，而我们始终无法在刚开始就完全固定这些可能的操作，为此，必须能让系统开发人员根据每个具体的应用模块来定义其所属的特定的动作/操作。
动作/操作通常具有以下属性：
事实上，有些动作是需要针对具体的数据实例的，譬如“查看”、“删除”和“更新”等，这种对数据实例级别的控制比针对“应用模块”级的控制要更精细。譬如，某个用户能进行对【采购申请单】的各项操作，他应该能查看他刚填写的单据并进行某些适当的修改，但是他却不应该看到其他人填写的数据。那么，这种粗粒度的权限设置显然无法控制数据级的访问，在 iSecurityManager® 中，专门使用“流程控制”的方案和技术来达致更细粒度的对数据实例级的访问和控制。
应用模块通常是指对应于企业应用中的某种类型的业务单据，譬如 ERP 系统中的【采购申请单】、【销售出库单】、【客户基础资料】等，这些业务单据可能对应一或多张数据库表。如果从面向对象(Object Oriented)的视角去看，似乎可以将本文中所描述的这些概念理解成这样：“应用模块”是类，“动作/操作”则是类的方法，而“应用模块”对应的数据库表（表结构）则是类的属性，表中的这些数据/记录就是类的实例了。
在定义规划系统中的“应用模块”时，通常还需要指定某个“应用模块”可能具有的“动作/操作”，而这些“动作/操作”由『动作定义』中进行了定义。注意：应用模块是系统中的一种逻辑组织单位。
应用模块通常具有以下属性：
顾名思义，授权是指用户/角色能对哪些应用模块中的某些操作（动作）是否具有执行的许可。这里的“是否具有执行的许可”实际上指的是授权的三种状态：授予-Grant、拒绝-Deny、继承-Revoke。
如果对某个角色授予某项权力，其下属的用户或角色是可以覆盖该项授权定义的。默认情况下，采用就近优先、拒绝优先的原则。
通常“应用模块”和“动作定义”是由系统开发商在系统设计、开发阶段就定义好了，在系统交付给用户使用后就不再对此更改了（当然这也不是绝对的，不是吗？）。
至此，有关用户权限的各项设置、定义都完成了，事实上，这并不会立即为你的应用系统带来任何安全保障，这只是一堆关于用户和授权定义的设置数据而已，还必须在应用系统中去应用这些设置数据并根据其定义的控制逻辑以对业务数据进行控制。如何利用这些用户授权数据来控制应用系统对业务数据的访问，有很多不同的解决方案，但是我认为建立一个中间数据存储层来统一所有客户端对数据源的存储访问是个不错的主意，并在这个数据访问层中应用安全设置来对业务数据的各种访问进行授权验证和控制，这样就可以统一各种客户端对数据存储的安全应用（事实上 iSecurityManager® 也正是如此处理这个问题的）。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。