设计@权限设计的一些想法和思考( 二 ) |美好，一直在身

“最小特权”和“数据抽象”分别决定了权限中控制的对象和操作，但是这里面还差了一个角度，则是现阶段非常普遍的前后端分离的权限划分的问题。
服务端的权限

前后端分离下的服务端，本质而言只是提供接口的或者rpc服务等其他资源服务的服务提供方。
服务端能提供的权限的鉴权机制的对象：接口服务（api或者其他形式的服务）不包含前端的页面或页面中的功能点。
前端或移动端的页面元素的控制和鉴权实质上不由服务端控制。
服务端可以单独的控制服务的权限。
服务端的服务对象是前端、移动端、第三方客户端，提供的服务是接口服务。

在前后端已经分离的情况下，服务端对于前端而言只是接口的提供者，但无权干涉前端页面的展示，服务端对于前端而言，能提供的是仅鉴权服务的接口而已，但是页面的构成，页面的栏目菜单或页面内的功能点的构成均由前端单独完成的。
【设计@权限设计的一些想法和思考】 前端或移动端的权限

前端的鉴权包含页面的可访问，和页面上的某项功能按钮是否可以操作。
前端和移动端的服务对象是用户，提供的服务是可视化的页面。

本文插图

前后端的服务对象的责任划分清晰之后，我们就不会混杂权限的归属的问题，在过去前后端没分离的情况下，页面本身就是服务端的一体，就没有这方面的问题。虽然分清楚了各端本质提供的服务的情况，但是前后端分离的权限划分中仍有新的问题。
1、因为服务端和前端的鉴权对象不一致，服务端只能鉴权到api接口，那么是否将api接口和前端的页面乃至页面功能点进行数据库表与表层面的绑定关系。
2、如果进行了进行了表与表之间的绑定关系，那么整个权限系统的维护量，是否能在能承受范围之内。
3、如果不进行表与表之间的绑定关系，前端页面在操作功能的时候，服务端如何鉴权页面调用的api接口是否在用户可操作的权限之内？
其实上面的问题则需要一个取舍，要么增加运维成本严格控制前端调用api接口的关系，偏重服务端的接口服务鉴权。要么是给api接口和前端页面及功能点再提供一个通性的逻辑判断处理，如：页面及调用的功能点属于某个业务模块的操作许可，而页面触发的接口也刚好是这个业务模块的操作许可，那么鉴权通过，否则鉴权失败。这种就是属于侧重前端对于用户的控制，弱化了接口级的控制。
3.角色与权限的关系通过1 ， 2的描述，基本确定了权限的定义和划分一个权限的通用法则。用户在系统中最终是通过权限来使用各种功能点，是否有必要在用户和权限中间再额外的附加一个关系。在我们现在的权限设计中，是增加了这样一层关系的，就是角色。
1、减少操作层面的重复性。角色其实就是一组权限的集合，是权限集合的更高级抽象，为了便于运维和实际管理，通过角色的赋予，替代了权限赋予用户的繁琐性，在一套系统中，普遍情况都是权限的数量多于角色的数量。
2、权限是控制对象和操作集合，它本身不存在任何状态，但是在赋予在用户身上则拥有了状态。比如权限A中允许用户访问页面A ，权限B允许用户访问页面B ，权限D运行用户访问B页面，但是不允许访问A页面。那么这层关系的维护在角色层面的话，会更加清晰，也就是说本身角色具有权限集合组装的策略问题，对于互斥的权限有不同的方案处理。（权限中没有某个操作和权限中禁止某个操作，是两个不同的角度，不能混为一谈）
3、因为权限的可能存在互斥性，在实际业务中也会引发角色的互斥性。举一个现实中的案例来解释互斥性：张三是软件部的负责人但因为工作的特殊性也同样隶属于业务部的普通员工，我们设定负责人是可以要求人事部门给本部门进行招聘的，在实际的情况中，张三能给软件部招聘新员工，但是不能给业务部招聘员工。我们把这个案例运用在系统中，张三则是拥有负责人和普通员工两个角色，但是招聘的功能如果不加以控制，则会发生张三给业务部招人的结果。于是为了解决角色的这类问题，引入了职责划分的方案。