Spring极简资源服务器

-本文为填坑文-

　　很早之前我在《Spring cloud gatway适配Keycloak》中给自己留了一个坑。

可以看出token中已包含有用户相关信息，可进一步传递给下游，作为权限判断输入，符合上文中的预期。好了，用户登录有了，剩下的就是在资源服务器（即下游微服务）上实现权限验证了。

后面再单独写一章吧，因为资源服务器的实现略有不同。

　　其实能鉴权的资源服务器很早就实现了，不过因为最近在愉快的玩儿其他有意思的东东，没能顾上填坑，正好最近天气不错，那就把它填了吧。

　　先来看看效果。

　　在用户未登录的情况下，点击任意链接（根据Gateway配置判断是否需要登录访问）都会跳转至Keycloak以完成SSO流程，这一点在之前的文章中已经有过介绍。

　　但是对于微服务框架（功能尽可能解耦）来讲，Gateway最好只作为用户的访问入口（将访问跳转至服务提供者）或特殊时段的流量分流器（比如灰度版本上线时）。而用户是否有权限访问/使用某一具体服务，应该由对应的该服务提供者来判断，Gateway路由时将相关的信息（如token）完整传递下去就好，这里的服务提供者就是资源服务器。

服务权限限定

POM依赖配置
　　既然资源服务器要对访问的用户进行鉴权，那么需要首先给暴露的端点加上权限限定，这在Spring框架里倒是挺简单，只需要在POM中加入spring-boot-starter-oauth2-resource即可。

<dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
</dependency>

　　它会自动引用Security相关依赖，因此不用再单独引入。

权限配置
　　有了resource-server依赖之后，就可以对端点进行权限（访问）定义了。

　　resource-server默认使用WebSecurityConfigurerAdapter作为其安全配置器，其初始状态为：所有端点均需要登录后才能访问，换句话表述即为所有端点一视同仁。但是这并不是我们想要的效果（通常来讲，不同端点有不同的访问权限限制才是较常见的情况）。因此我们需要继承WebSecurityConfigurerAdapter，并重写里面的 protected void configure(HttpSecurity) 方法。

protected void configure(HttpSecurity http) throws Exception{
        http.authorizeRequests(authz -> authz
                .antMatchers(HttpMethod.GET, "/testing/").permitAll()
                .antMatchers(HttpMethod.GET, "/testing/auth/**").hasRole(role_auth)
                .antMatchers(HttpMethod.GET, "/testing/vip/**").hasRole(role_vip)
                .antMatchers(HttpMethod.GET, "/testing/admin/**").hasRole(role_admin)
                .anyRequest().authenticated())
                .oauth2ResourceServer().jwt().jwtAuthenticationConverter(new JwtAuthenticationConverter());
}

　　代码很简单，将所有需要控制的端点按各自访问需求配置即可。又因为KeyCloak返回的是jwt格式token，所以配完权限设定后，我们告诉资源服务器使用JWT进行token解析。

　　按道理讲这样配置后就可以正常工作了，但是实际是无法完成校验的（所有访问均无法通过）。

Token解析

　　我们将KeyCloak返回的token解码后会发现一些有意思的事儿。因为我的鉴权是基于role的，因此将token里面与role相关的字段筛选出来，如下：

{
  ……
  "realm_access": {
    "roles": [
      "offline_access",
      "admin",
      ……
    ]
  },
  "resource_access": {
    "realm-management": {
      "roles": [
        "view-realm",
        "view-identity-providers",
        "manage-identity-providers",
        "impersonation",
        "realm-admin",
        "create-client",
         ……
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "scope": "profile email",
  ……
  "roles": [
    "ROLE_offline_access",
    "ROLE_vip",
    "ROLE_user",
    ……
  ],
  ……
}

　　可以看出token中有好几个与role相关的字段，彼此之间还都有差别，我们依次解读一下。

realm_access.roles 用户具有的外部自定义权限，即提供给资源服务器鉴权用的。
resource_access 用户具有的内部权限，主要是指访问KeyCloak子功能的权限。
　　- realm-management.roles 管理当前realm的权限（如：创建、删除、查看等）
　　- account.roles 对当前账户的管理权限（如：查看、更改等）
roles 所有已分配的角色描述

备注：2与3 是可以一一对应上的

　　token中角色信息基本上就这些了，有用的的都有了，不怎么有用的也在token当中。回头再看看Spring Security是怎么取的这些信息呢？

　　经过一系列的定位，跟读代码，我发现Spring读取的信息是token中的scope字段（别问怎么跟的，也别问具体是那个文件，因为过去太久了，我也忘记了），而scope字段的值是profile email。所以默认情况下永远也无法校验通过（当然也可以把角色名改成profile email →_→）。

Token适配

　　怎么解决这个问题呢？至少有两种办法值得尝试。

　　- 修改KeyCloak产生的Token，使其适配Spring解析规则。

　　- 修改Spring解析方式，适应KeyCloak。

KeyCloak映射

　　KeyCloak提供了丰富而强大的映射功能，在上文解析token内容时所发现的ROLE_信息即通过映射的方式将自定义的角色信息映射到token自定义字段当中的。

　　然而就算有如此强大丰富的映射功能，我们也不能将realm.roles信息映射到scope中，并不是无法配置这样的映射规则，而是配置之后在校验时会有很多莫名其妙的问题。

如果有好心人知道如何正确配置，也请不吝赐教

自定义解析器

　　之前我们跟踪Spring Security会发现在使用JWT解析器的时候，实际的转换是通过JwtGrantedAuthoritiesConverter 中的covert完成。解析方法到也不复杂，简单来说就是读取jwt token的scpe字段。要解决这个问题就得用我们自己covert去替换默认的。

　　幸运的是Spring Security开放了相关接口。只需要用自定义的解析方法替换即可。

protected void configure(HttpSecurity http) throws Exception{
        JwtAuthenticationConverter converter = new JwtAuthenticationConverter();
        converter.setJwtGrantedAuthoritiesConverter(new Converter<Jwt, Collection<GrantedAuthority>>() {
            @Override
            public Collection<GrantedAuthority> convert(Jwt source) {
                JSONArray roles = (JSONArray) ((JSONObject) (source.getClaims().get("realm_access"))).get("roles");
//                JSONArray scopes = (JSONArray) ((JSONObject) (source.getClaims().get("resource_access"))).get("roles");
                ArrayList<GrantedAuthority> roleArray = new ArrayList<>();
                for(int i = 0; i < roles.size(); i++){
                    roleArray.add(new Role(roles.get(i)));
                }
                return roleArray;
            }
        });
        http.authorizeRequests(authz -> authz
                .antMatchers(HttpMethod.GET, "/testing/").permitAll()
                .antMatchers(HttpMethod.GET, "/testing/auth/**").hasRole(role_auth)
                .antMatchers(HttpMethod.GET, "/testing/vip/**").hasRole(role_vip)
                .antMatchers(HttpMethod.GET, "/testing/admin/**").hasRole(role_admin)
                .anyRequest().authenticated())
                .oauth2ResourceServer().jwt().jwtAuthenticationConverter(converter);
    }

　　因为covert需返回GrantedAuthority格式的队列，因此自定义了一个子类Role。这个子类只做一件事，给role加上ROLE_前缀。

public class Role implements Serializable, GrantedAuthority {
    private String authority;
    public Role(Object role){
        authority = "ROLE_" + (String) role;
    }

    @Override
    public String getAuthority() {
        return authority;
    }
}

　　为什么还需要一个自定义Role呢？Token中不是带有已加有前缀的字段了吗？因为在实际部署生产环境的时候，我们更倾向只对一端进行修改，而不是两端同时修改，这也是出于减少依赖，方便日后替换另一端考虑。

　　至此，一个适配KeyColaK，支持鉴权的资源服务器就算做好了。

本文内容在Spring boot 2.5.5版本上验证通过

源码 Gitee