ACL权限管理

ACL ： access control list
访问权限管理

在企业服务里，算是个基础服务。今天谈谈关与它的设计。
网上有好多资料，给出了ER图，类图。讲得都非常好，试用于各个场景。但是用起来，前期没什么问题，到后期发现有很大的问题。
分析原因，是因为以开发的角度去解决这个问题，去思考ACL。少了从运营的角度去分析ACL。

首先，明确一些问题与误区：
----------------------------------------------
ACL本身仅仅是负责了存储。
一个具体业务，根据那个维度进行数据权限划分，还是来自业务，存储成什么样的格式，ACL本身是不知道的。业务只是基于ACL快速建立数据权限模型。
ACL分为功能权限和数据权限
用户能访问那写表单和页面，属于功能权限。多个用户访问同一个表格，但是看到的数据不一样，这是数据权限。
正确理解角色、资源、用户三者关系
网上好多资料，对三者进行了抽象，抽象得非常好。可以适应各种场景。完美。
这里强调的是建立数据模型时，没有统一的方式。要跟具体业务来。具体分成如下
（1）用户-角色关系 （多对一）
在这个模型中，是不需要资源的。举例，针对我的系统用户，我只想给部分人提供发放邮件的功能，我只关心给哪些人发邮件，所谓的功能权限，下放到业务代码中，不需要维护到ACL里。
（2）角色-资源关系 （一对多）
系统会经常创建一个报表，要把新创建的报表分配给系统用户。那么新创键一个资源，就要绑定几十个用户，显然运营成本会很大。要事前把用户和觉色进行关联，然后把新创建的资源与角色绑定。
（3）角色-资源 （多对多）
举例，一个全国的销售人员管理系统，资源分级，至上而下：全国，大区，省，市，区
公司各个人员与期资源进行关联。而且这个关联关系，会在多个业务单元中使用，导致弱化角色的概念，只关心数据权限。
（4）账户-角色-资源
三者，两两关联，再加上一个全的。共四个场景。
没有必要用统一的方式去做存储，要根据具体业务场景套用上面的模型。
没有必要，把所有的权限，都搞成 固定的模型，账户-角色-资源。这样不方便理解。

资源设计，以及查询
我发现，目前提供的资料，仅仅强调了存储，没有强调查寻接口如何设计。这也是导致ACL不好用的根本原因。要结合上面的模型，提工一系列查询接口，要贴近业务，换位思考。

独立维护业务线的用户信息


----------------------------------------------


我设计的ACL管理系统
可以无缝迁移到各个公司系统中。
预留接口与SSO打通。
多个业务线都可一使用。选定业务线后，所有操作都在该业务线下操做。
维护账户、角色、资源以及三者映射关系。
提供批量上传的功能。针对账户、角色、资源以及三者映射关系都可以批量上传。
提供丰富，能满足业务需求的查询功能。
默认提供登陆功能，建议对代码做修改，接入公司的SSO。

特殊说明:
通过存储和查询，解决了一个业务上的复杂功能。
资源：
1 全国 华东大区 浙江省 杭州市 西湖区
某个人，可能跟资源有多条绑定关系。
最后想知道这些绑定关系，涉及哪些市，人可能绑定到任意层级，要反回某一层级的管线数据。
一个五层树状结构，用户可能绑定到任何一层。求某一层的涉及的资源。
这个需求很长用，处理起来很复杂。提供的解决方案，解决了这个问题。
代码已经实现，后面会上传到github上