Auth

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

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

Authentication 认证

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

认证流程：

关键对象：

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

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

授权流程：

关键对象：

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

权限模型：

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

RBAC(Role Based Access Control)。

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

代码：

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

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

RBAC(Resource Based Access Control)。

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

代码：

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

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

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

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

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

最后更新于2年前

这有帮助吗？