企业IT管理员一般都能为系统定义角色，给用户分配角色。这就是最常见的基于角色访问控制。场景举例：

1、给张三赋予“人力资源经理”角色，“人力资源经理”具有“查询员工”、“添加员工”、“修改员工”和“删除员工”许可权。此时张三能够进入系统，则可以进行这些操作；

2、去掉李四的“人力资源经理”角色，此时李四就不能够进入系统进行这些操作了。

以上举例，局限于功能访问许可权。还有一些更加丰富、更加细腻的许可权管理。比如：

1、因为张三是北京分公司的“人力资源经理”，所以他能够也只能够管理北京分公司员工和北京分公司下属的子公司（海淀子公司、朝阳子公司、西城子公司、东城子公司等）的员工；

2、因为王五是海淀子公司的“人力资源经理”，所以他能够也只能够管理海淀子公司的员工；

3、普通审查员审查财务数据的许可权是：在零售行业审核最高限额是￥50万，在钢铁行业最高限额是￥1000万；高级审查员不受该限额限制；

4、ATM取款每次取款额不能超过￥5000元，每天取款总额不能超过￥20000元。

这些许可权管理和数据（可以统称为资源）直接相关，又称为数据级许可权管理、细粒度许可权管理或者内容许可权管理。

从控制力度来看，可以将许可权管理分为两大类：

1、功能级许可权管理；

2、数据级许可权管理。

从控制方向来看，也可以将许可权管理分为两大类：

1、从系统获取数据，比如查询订单、查询客户资料；

2、向系统提交数据，比如删除订单、修改客户资料。

用户身份认证，根本就不属于许可权管理範畴。用户身份认证，是要解决这样的问题：用户告诉系统“我是谁”，系统就问用户凭什幺证明你就是“谁”呢？对于採用用户名、密码验证的系统，那幺就是出示密码。当用户名和密码匹配，则证明当前用户是谁；对于採用指纹等系统，则出示指纹；对于硬体Key等刷卡系统，则需要刷卡。

密码加密，是隶属用户身份认证领域，不属于许可权管理範畴。

系统管理，一般是系统的一个模组。而且该模组一般还含有许可权管理子模组。因此，很多人误认为许可权管理系统只是系统的一个小小的子模组。系统管理里面的许可权管理模组，只是一个操作界面，让企业IT管理员能够设定角色等安全策略。系统背后还有很多许可权验证逻辑，这些都并不属于该模组。总体来说，该模组相当于给许可权管理模组提供了一些数据，比如：张三是人力资源经理等。

更多混淆概念，请参考：《对许可权管理认识的一些误区》。

按照许可权管理的力度，逐步介绍许可权管理实现技术。

功能许可权管理技术，一般就使用基于角色访问控制技术RBAC（Role Based Access Control）。该技术被广泛运用于各个系统，非常容易掌握。该技术模型如下图示：

RBAC许可权模型

许可权设定

一般来说，系统提供如下功能：

1、角色管理界面，由用户定义角色，给角色赋许可权；

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

3、一些优秀系统，还支持用户定义许可权，这样新增功能的时候，可以将需要保护的功能添加到系统。

这里，我们谈谈Spring Security框架。它将访问角色固化到程式代码里面。那幺这种控制就相当于由软体开发人员完成，而不是最终用户。这从实施角度来看，是完全错误的。更多阅读，可以查看《Spring Security优劣之我见》。

功能级的许可权验证逻辑非常简单。查看该当前登录用户的角色是否包含该功能的许可权。如果有，则表示有权访问，否则表示无权访问。

对于WEB系统，一般定义一个Filter就可以完成许可权验证，无需在各个程式入口进行许可权判断。程式伪代码如下：

// 获取访问功能

// 进行许可权验证

// 可以转到提示界面

}

目前，数据级许可权管理领域，一直没有统一的技术。大体上，软体开发人员採用如下技术：

1、硬编码，也就是将这种逻辑以if/else等形式与业务代码耦合在一起，这种情况居多；

2、使用规则引擎，也有一些企业将这种逻辑以规则形式提出来，并使用规则引擎解析规则；

3、使用第三方专业软体，有开源中间件Ralasafe；开源框架Spring Security；商业产品Oracle Entitlements Server，IBM Tivoli Access Manager，UPMS通用用户许可权系统等。

硬编码形式弊端是非常显然的。耦合性强，难以测试；系统组件复用率低；系统后期改动代价非常大，牵一髮而动全身。

使用规则引擎可以解决很多问题，学习难度尚可。但规则引擎并不是专业用于许可权管理的，所以对于複杂一些的许可权管理，就显得力不从心。

Ralasafe和Oracle、IBM的商业产品一样，都是中间件形式。对套用系统和套用资料库结构没有要求。都有管理界面进行直接操控管理，而且都能线上进行测试。相比较，Ralasafe还可以控制查询许可权（即从系统查询订单、查询客户等），Oracle、IBM的商业产品没有这方面功能；从产品学习难度来看，Ralasafe只要有一些IT经验，就能快速上手；Oracle、IBM产品即使是专业人员，也难以掌握。

Spring Security是框架，需要对你的套用系统进行改动，你的系统必须在该框架进行设计编写。它只是帮助开发人员将许可权提取出来了，但数据级许可权还需要开发人员开发Voter。而且配置工作巨大，难以测试。

虽然上述提到的产品，都是Java产品。但Ralasfe和Oracle、IBM的商业产品，以中间件形式，可以部署在独立伺服器上，使用web service等方式与非Java系统互动。

这是很多系统都能做到的。让系统使用者（一企业IT管理员）定义角色，给用户分配角色。成功实施该步骤，用户能在功能级进行许可权管理。整个过程无需软体开发商参与。

有些複杂一点的系统，提供了一些规则和管理界面，可以让系统使用者（一般是企业IT管理员）输入规则参数。比如普通审查员审查财务数据的金额区间，勾选某用户能够查询哪些组织机构的订单数据。

这是给企业提供了部分控制数据级许可权的能力。但该能力还非常弱，仅限于已定义好的策略，不能适应安全策略变化。而，企业需求肯定会随着业务发展、时间推移，发生变化。比如：普通审查员审查区间由原来的单一设定区间，改为按照行业、按照地域来设定不同的区间。用户查询订单不仅和组织机构有关，还和订单业务领域（体育、食品等）有关。当这些需求发生的时候，企业还要求助于软体开发商进行修改。

企业完整掌控安全策略，应该包括2个方面内容：1，功能级许可权管理完全自我掌控；2，数据级许可权管理完全自我掌控。实现这方面需要，还需要考虑企业的IT能力：IT能力没有软体开发商强，而且许可权管理涉及整个系统安全，关係重大。因此软体必须是这样的：1，图形化、集中管理的，便于企业管理；2，可线上测试的，定製策略后在不影响业务的情况下，进行测试，确保无误。

目前，就Ralasafe和Oracle、IBM产品满足要求。

不良的许可权管理系统，必然留下系统漏洞，给黑客可趁之机。很多软体可以轻鬆通过URL侵入、SQL注入等模式，轻鬆越权获得未授权数据。甚至对系统数据进行修改、删除，造成巨大损失。

许可权由紧密分散，转换为集中专业管理

很多系统，尤其是採用硬编码方式的系统，存在许可权逻辑与业务代码紧密耦合，同时又分散在系统各个地方。系统漏洞势必非常多，而且随着系统不断修改，漏洞逐步增多。 好的系统，应该将许可权逻辑集中起来，由专业的安全引擎进行设定、解析。业务逻辑调用安全引擎，获得许可权结果，不再使用非专业模式。这种转变，如图示：