目的

该子框架主要是统一认证与授权、鉴权的实现方式。

设计分析

在传统的单体应用中是将认证与授权、鉴权放在同一个系统来实现的。

image.png

• 比如：移动官网系统

认证：基于用户名+短信验证权进行认证。
授权：认证成功获取一个令牌。
鉴权：一些资源可以不登录访问，比如：登录首页;
访问授限资源需要对用户的令牌进行验证，从而达到用户身份验证的目的，并判断用户是否有权访问。

• 再比如：后台管理系统（CMS）

认证：基于用户名+密码进行认证
授权：认证成功获取一个令牌，并在后端绑定用户角色，并基于ACL授权接口数据资源。
鉴权：与移动官网无异。

在微服务架构中，认证与授权、鉴权通常在不同的工程中分开部署。

PlantUML diagram

• 比如：业务中台

认证：UAA基于oauth2实现4种认证方式。
授权：在UMS中配置client为客户端授权。
鉴权：在网关对客户端权限进行校验。

综上所述，认证、授权、鉴权需要开发为独立组件，以满足各种情况的需要。

权限设计

权限设计主要分为认证、授权与鉴权。

认证

认证按类型区分，可以分为用户认证和应用认证

用户认证

• 基于用户名+密码+图形验证码认证
• 基于用户名+手机验证码认证

应用认证

• 授权码模式
  用户认证以后，用户授权客户端访问系统资源。
  客户端获取到系统授权码，换取令牌，完成客户端认证。

  
  image.png

• 简化模式
  用户认证以后，用户授权客户端访问系统资源。
  客户端获取到令牌，完成客户端认证。

  
  image.png

• 密码模式
  客户端将用户提供的发给系统，完成客户端认证。

  
  image.png

• 客户端模式
  客户端提供appid及secret，完成客户端认证。

  
  image.png

授权

用户授权

对于用户授权，我们常用RBAC基于角色的访问控制（Role-Based Access Control) 来实现。

RBAC 认为授权实际上是Who 、What 、How 三元组之间的关系，也就是Who 对What 进行How 的操作，也就是“主体”对“客体”的操作。

Who：是权限的拥有者或主体（如：User，Role）。
What：是操作或对象（operation，object）。
How：具体的权限（Privilege,正向授权与负向授权）。

应用授权

对于应用授权，可以基于oauth2协议中的scope(权限范围）来扩展进行授权。

鉴权

实现方式

鉴权通常都是在请求的入口进行控制。
在单应用中：

• 可以通过servlet的Filter中来实现
• 在SpringMVC中可以通过拦截器来实现
  在微服务中：
• 可以在网关中来实现。

不管哪种方式 ，都可以基于接口来定义一套统一的鉴权逻辑，及主体（用户、应用或其它）访问资源（界面、按钮、API、数据）时：

• 获取主体的授权信息（如：用户的角色信息）
• 获取角色对应的授权资源信息(ACL）
• 基于授权资源信息判断主体是否有访问权限。

用户鉴权

• 在用户访问资源时获取用户角色信息。
• 基于角色获取授权资源信息。
• 基于授权资源信息判断用户是否有访问权限。

应用鉴权

• 在应用访问资源时获取应用的范围（scope)信息。
• 基于访问范围限制获取授权资源信息。
• 基于授权资源信息判断应用是否有访问权限。

实现

PlantUML diagram

• auth-user
  获取授权主体信息的接口。

• auth-common
  认证、授权、鉴权的通用配置。

• auth-server
  认证的扩展

• auth-client
  鉴权的统一接口及通用实现。

• auth-enhancer
  基于spring-mvc对获取主体信息的扩展。
  基于注解，在接口处自动获取主体相关信息。

@startuml
frame 系统{
card 业务功能
card 认证
card 授权
card 鉴权
}
@enduml

@startuml
frame 网关{
card 鉴权
}

frame UAA{
card 认证
}

frame UMS{
card 授权
}

frame US {
card 业务功能
}

@enduml

@startuml
[auth-server] --> [auth-common]

[auth-client] --> [auth-common]

[auth-common] --> [auth-user]

[auth-enhancer] --> [auth-user]
@enduml