关于权限体系的一些思考

开始

权限体系无非是办理两个问题，Authentication（认证-你是谁）和 Authorization（授权-你醒目什么）。
Authentication

认证的问题，很好理解，就是根据用户的身份凭据，计算出这个用户的身份信息。
而身份凭据，常见有 Token 和 Session，还有 Permanent Token（永世令牌）、Application password（应用专用暗码）等。
这里可以延伸聊一下登录问题，实在登录不应该算作 Authentication 范畴，登录只是一个 Action，用于换取身份凭据的动作。没有登录这个工作，换种方式颁发身份凭据，难道权限体系就不能工作了吗？
Authorization

Authorization 又可以划分为三个问题来办理：

• 分配：赋予谁什么权限；
  
• 办理/计算：计算谁有什么权限；
  
• 判断：判断谁是否有某个权限；
  

分配

分配要思量的问题有两个，一个是谁、一个是目标。因此分配要办理的问题就是：要给谁在什么目标上分配什么权限。
给谁？好比用户、用户组等，我们称为 Owner。
什么目标？权限分配一定要有一个附着点，好比项目、公司、组织等，我们称为 AuthTarget 。
什么权限？为了分配上的方便，我们常常把一堆权限集称为 脚色，脚色的作用仅仅是为了分配上的轻便，一般不用来做判断，什么原因，下文会解释。
我们一般推荐权限体系是模块独立于业务体系的，很简单，权限体系本来就是业务不相关的。我们只要将权限体系的 AuthTarget  和业务体系的资源做关联，就能驱动业务体系完成权限工作，而这个关联活动是权限体系关联业务体系，照旧业务体系关联权限体系，或是单独关联，仁者见仁，智者见智。
办理

计算一个 Owner 有什么权限，并缓存起来。
这点主要是为了性能的思量，如果在判断的时间再去计算 Owner 的权限，必将大大拖累业务体系的性能，而且一个 Owner 的权限大部分时间内都是不变的，因此缓存掷中率特别高，特别适合缓存。
缓存的 Key 的是 Owner，Value 包括 权限 + AuthTarget。
判断

判断一个 Owner 是否有权限访问资源。
判断分为前端和后端，而判断的前提就是依赖 办理 中缓存的用户权限。
为什么不用 脚色 来判断 Owner 是否能访问资源呢？如果诸多资源都用一个脚色 判断，不方便扩展和拆分，更严重的是，随着时间推移，常常出现自己都预想不到的越权活动，因为到处都是基于某个脚色的判断。那么我多界说一些脚色呢？额。这不就变成了权限判断？
直接使用权限进行判断，可以为用户提供更精细的权限控制。安全体系设计的一个重要原则是“最小权限原则”（Principle of Least Privilege），即应尽大概只授予用户完成使命所需的最低权限。通过直接基于权限判断，可以更加严酷地控制用户权限的分配，减少误授权的大概性。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。