权限系统作为商业系统的一个基础平台而存在。权限系统的设计有一些基本的准则，如用户（User），用户组（Group），角色（Role），动作（Action），视图（View），组织结构（Organization）。它们是权限系统设计的基本要素。

系统中的权限通常可以定义为3个权限子集：模块访问权限，操作权限，数据视图权限。

模块访问权限 – 通常商业系统都按功能特性组织成不同的子系统或功能模块。每个子系统中有包含若干功能单元。比如，某销售管理系统包括“商机系统”、“客户管理系统”、“管理分析和BI系统”、“电子商务系统”、“信息共享平台”、“基础框架平台”。不同的用户将被授予不同的子系统及其子模块的访问权限。

模块权限在实现时常常表现为功能菜单的访问授权。

操作权限 – 定义用户进入某个子系统后可以做什么、不可以做什么。比如，商机系统包含“普通商机”流程，其中有“商机报备”、“技术可行性和价格回复”、“立项申请”、“价格审批”、“物料编号回复”、“合同拟制”、“合同审核”、“下单”。其中，O/S,I/S具有“商机报备”、“合同拟制”的操作权限，技术支持人员具有“技术可行性回复”的操作权限，各级审批人员具有相应的“价格审批”操作权限，法务代表具有“合同审核”的操作权限，渠道伙伴具有“下单”操作权限。等等。

操作权限相对于模块权限通常处于较低的控制级别。就是说，通常先检查模块访问权限，有模块访问权限的前提下，才检查是否有某个功能的操作权限。打个比方，就像你进公园，先要检查你是否有门票。进去之后，如果有些景点是需要单独购票的，你还有单独购票才能进去。操作权限通常控制到用户界面的操作按钮是否可用（或可见）、在Code的方法调用级别做权限检查。

数据视图权限 – 商业系统中往往存在大量数据，如产品数据、客户数据、销售数据、财务数据、报表数据。为了数据安全性和保密性的需要，往往需要对用户有权查看或操作的数据集进行定义，即不同的用户有不同的数据视图。

数据视图权限的定义往往与公司的组织架构紧密相关。比如常常有类似这样的需求：总经理能够查看系统内的任何数据，销售总监可以查看全部的销售数据，区域销售经理只能查看自己管辖区域的销售数据，销售人员只能看到自己的销售数据。

数据视图权限同时又与操作权限紧密相关。如区域销售经理能查看自己下属销售人员的销售数据，但没有修改或删除的权限；但是区域销售经理对他本人的销售数据具有完全的操作权限（增加、修改、删除、查看）。简言之，不同的操作权限往往与不同的数据视图权限相关。

权限系统的设计必须要结合特定系统的业务规则和用户需要来进行，并且需要做细致、周密的规划。

权限系统设计的关键是做到模块化、接口化、可配置。

权限判定的逻辑往往会渗透到整个系统的代码中。为了便于系统维护，需要采用AOP设计和编程。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13651903/viewspace-1028848/，如需转载，请注明出处，否则将追究法律责任。