Auth

只要有用户参与的系统一般都要有权限管理，权限管理实现 对用户访问系统的控制， 按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源

权限管理Auth包括 用户认证(Authentication) 和 授权(Authorization) 两部分。在HTTP中，如果认证不通过，HTTP状态码通常返回401 Unauthorized，而鉴权失败通常会返回403 Forbidden状态码。

Authentication 认证

概念：用户去访问系统，系统要验证用户身份的合法性。

认证流程：

file

关键对象：

1. subject：主体 即用户，权限管理系统需要对subject进行身份认证

2. principal ：身份信息，通常是一个主身份信息（账号）和多个辅身份信息（邮箱、QQ）

3. credential：凭证信息，比如密码、指纹、证书

总结：身份认证就是主体提供身份信息和凭证请求认证的操作。

认证方式

1. 用户密码认证

2. 证书认证

3. 生物识别（指纹人脸）

4. 第三方授权认证

Authrization 授权

概念：简单理解为 访问控制，在用户认证通过后，系统对用户访问资源进行控制，用户具有资源的访问权限方可访问。

授权流程：

file

关键对象：

1. Subject：主体

2. Resource：资源

3. Permission：权限

即Subject必须具备相应的Permission才可以操作Resources

权限模型：

1. Subject 主体

2. Resource 资源

3. Permission 权限

4. Role 角色

5. 角色权限关系

6. 主体角色关系

在企业开发中，通常将资源和权限合并为1张表。

权限控制（授权核心）

基于角色的访问控制

RBAC(Role Based Access Control)。

举例：总经理->部门经理->组长….

代码：

if (user.hasRole("部门经理")){
    // access
}

缺点：角色是经常变化的，这样不利于系统维护，可拓展性不强

基于资源的访问控制

RBAC(Resource Based Access Control)。

举例：审核权限、删除权限、读取权限…

代码：

if (user.hasPermission('删除权限')){
    // access
}

优点：资源在系统中通常是不变的，利于代码的维护，由更好的拓展性

粗粒度和细粒度权限

什么是粗粒度权限和细粒度权限

• 粗粒度：对资源类型的权限管理。资源类型比如：菜单、url、类方法、页面按钮…

• 细粒度：对资源实例的权限管理。数据级别的权限管理资源类型的具体化，比如 审核菜单、url为 xxx.com 的页面、 Xxx 类…

粗粒度权限管理实现

粗粒度权限管理比较容易将权限管理的代码抽取出来在系统架构级别统一处理。比如通过URL和拦截器实现授权。

细粒度权限管理实现

对细粒度权限管理在数据级别是没有共性可言，针对细粒度权限管理就是系统业务逻辑的一部分，如果在业务层去处理相对比较简单，如果将细粒度权限管理统一在系统架构级别去抽取，比较困难，即使抽取的功能可能也存在扩展不强。

建议细粒度权限管理在业务层去控制。比如：部门经理只查询本部门员工信息，在service接口提供一个部门id的参数，controller中根据当前用户的信息得到该 用户属于哪个部门，调用service时将部门id传入service，实现该用户只查询本部门的员工。