## 一、再看流程  依照上面的流程，我们已经完成了 * 在网关上开发登录认证的功能，用户登录认证后返回给客户端JWT令牌 * 在网关上新建了全局过滤器，当有请求发送到网关后，该过滤器校验JWT令牌的合法性。只有令牌合法请求才会被转发到具体的业务服务。并且在过滤器中我们在JWT令牌中解析出userId（用户身份信息），并向网关后面的服务传递。  **其他服务**分为两种： * 一种服务是对系统内所有的用户开放，即：用户通过了网关的JWT鉴权，服务自身就不再对用户进行权限限制，所有的接口都可以被访问。 * 另一种服务是自己有权限要求，比如根据角色来判断你是否具有访问某些接口的权限。比如：作为系统管理员用户，你可以访问“系统日志”、“系统管理”等功能接口；作为系统的操作员，你只能访问一些业务操作接口。 ## 三、微服务内部的权限管理 已知：我们可以获得userId（用户身份信息），其他一概不知。我们可以使用RBAC权限模型管理用户权限。  * 根据userId查询可以得到用户信息 * 根据用户信息可以查询到角色信息（一个用户有多个角色） * 根据角色信息可以查到接口权限信息（一个角色有多个权限） 最终服务内部通过userId（用户身份信息）获取到该用户能够访问的接口权限的列表X。**用户正在访问的接口在X列表中，表示该用户可以访问该接口，否则无权限。** ### 数据库模型 我们可以用下图中的数据库设计模型，描述这样的关系。[rbac-sql-mysql.sql](https://gitee.com/hanxt/dongbb-cloud/blob/master/dbcloud-persistence-spring-boot-starter/src/main/resources/com/zimug/dongbb/cloud/starter/persistence/sql/rbac-sql-mysql.sql) * 一个用户有一个或多个角色 * 一个角色包含多个用户 * 一个角色有多种权限 * 一个权限属于多个角色  * sys\_user是用户信息表，用于存储用户的基本信息，如：用户名、密码 * sys\_role是角色信息表，用于存储系统内所有的角色 * sys\_menu是系统的菜单信息表，用于存储系统内所有的菜单。用id与父id的字段关系维护一个菜单树形结构。 * sys\_user\_role是用户角色多对多关系表，一条userid与roleid的关系记录表示该用户具有该角色，该角色包含该用户。 * sys\_role\_menu是角色菜单(权限)关系表，一条roleid与menuid的关系记录表示该角色由某菜单权限，该菜单权限可以被某角色访问。 这个过程你可以结合Spring Security去实现，也可以结合shiro去实现，或者不用任何框架自己去判断实现都可以。**微服务内部的权限管理**的知识已经超出了Spring Cloud这本书的范畴，我就不带着大家一一讲解实现了。 ## 四、dbcloud-security-spring-boot-starter 为了方便大家集成使用，我已经在dongbb-cloud项目中写好了：dbcloud-security-spring-boot-starter。  > 其核心的实现原理可以参考学习：[https://www.kancloud.cn/hanxt/springsecurity/content](https://www.kancloud.cn/hanxt/springsecurity/content)。 ### 用法如下： 在微服务中集成dbcloud-security-spring-boot-starter ~~~ <dependency> <groupId>com.zimug.dongbb.cloud</groupId> <artifactId>dbcloud-security-spring-boot-starter</artifactId> </dependency> ~~~ 进行配置 ~~~ zimug: security: csrfDisabled: true devOpeningURI: - /sysuser/info # 服务开发阶段不想去配置数据库用户、角色、权限。临时开放接口访问 permitAllURI: - /xxxx/yyyy #公开访问的接口 ~~~