- 内置默认的用户认证和权限控制逻辑，仅开放对模型的扩展支持
- 支持在 Redis 中共享用户会话和用户权限信息，以支持应用多服务和服务多实例
User 既是用户认证和授权的核心对象，其也是组织机构中的重要对象，
但在组织机构中，主要关注的是其个人信息，不关注对其的权限相关的控制。
对于针对组织机构的扩展信息，可以通过可逆计算的差量机制对 User
进行按需补充，无需提前预设- 会话日志
- 操作日志
- 权限
- 数据权限（
Data）：控制可访问数据范围和字段，限制可执行操作（增删改查） - 资源权限（
Resource） - 资源操作权限（
Action）
- 所有资源（接口、页面、数据）都需要用户授权才可访问，
不需要登录便可访问的资源，其本质是授权给了匿名用户，
因此，匿名用户是一个特殊的系统用户，每次访问都会生成不同的
Access Token- 内部服务之间仅需检查 Token 的有效性即可，无需从数据库做比对：
对 Token 解码并比对帐号和一个随机值
- 多租户支持：不同租户有不同的权限范围
- 代码组织结构上分为：控制层和实现层
- 控制层应用于应用服务（含网关），负责根据用户上下文控制请求和数据权限。
注：用户上下文通过本地缓存（单体模式）或分布式缓存存放（多服务模式），
以便于服务间共享
- 实现层负责维护和管理用户、角色、资源、权限等数据，
并进行用户认证，提供用户授权数据
- 扩展仅发生在实现层，通过差量机制替换 BizModel bean 即可
- 实现层放到
platform 项目中
- 可以通过帐号、邮箱、手机号、身份证号等唯一身份信息（
authType）进行登录认证，
登录方式（loginType）又可以是账密、微信、支付宝等 - 服务之间通过证书加密传输数据，证书在部署时生成，只要能解密数据，则视为授信连接，
无需采用 Auth 认证
- 在网关侧拦截外部请求，并进行认证和鉴权，
在转发请求到服务时附带用户的认证和权限信息
- 未明确授权时，非匿名资源、接口等均不可被访问
- 内置匿名角色，可对匿名用户做权限控制。匿名访问也需记录操作日志和会话日志
Resource、Action 为静态数据，在编码期确定，运行期从 DSL 中读取。
在各个模块中声明，再在运行期扫描并合并Action 用于控制对 {bizObjName}__{bizAction} 接口的访问
组织机构
- 以差量方式对 Auth 模块中的
AuthUser 进行扩展，并在组织机构侧对用户数据进行增删改，
Auth 模块仅为 User 数据的消费者，并负责对用户做权限管理- 对于非系统使用者，则不需要扩展自
AuthUser