基於OpenID Connect及Token Relay實現Spring Cloud Gateway

2022-06-22 14:02:05

前言

當與Spring Security 5.2+ 和 OpenID Provider（如KeyClope）結合使用時，可以快速為OAuth2資源伺服器設定和保護Spring Cloud Gateway。

Spring Cloud Gateway旨在提供一種簡單而有效的方式來路由到API，併為API提供跨領域的關注點，如：安全性、監控/指標和彈性。

我們認為這種組合是一種很有前途的基於標準的閘道器解決方案，具有理想的特性，例如對使用者端隱藏令牌，同時將複雜性保持在最低限度。

我們基於WebFlux的閘道器貼文探討了實現閘道器時的各種選擇和注意事項，本文假設這些選擇已經導致了上述問題。

實現

我們的範例模擬了一個旅遊網站，作為閘道器實現，帶有兩個用於航班和酒店的資源伺服器。我們使用Thymeleaf作為模板引擎，以使技術堆疊僅限於Java並基於Java。每個元件呈現整個網站的一部分，以在探索微前端時模擬域分離。

Keycloak

我們再一次選擇使用keyclope作為身份提供者；儘管任何OpenID Provider都應該工作。設定包括建立領域、使用者端和使用者，以及使用這些詳細資訊設定閘道器。

閘道器

我們的閘道器在依賴關係、程式碼和設定方面非常簡單。

依賴項

OpenID Provider的身份驗證通過org.springframework.boot:spring-boot-starter-oauth2-client
閘道器功能通過org.springframework.cloud:spring-cloud-starter-gateway
將令牌中繼到代理的資源伺服器來自org.springframework.cloud:spring-cloud-security

程式碼

除了常見的@SpringBootApplication註釋和一些web控制器endpoints之外，我們所需要的只是：

@Bean
public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http,
    ReactiveClientRegistrationRepository clientRegistrationRepository) {
  // Authenticate through configured OpenID Provider
  http.oauth2Login();

  // Also logout at the OpenID Connect provider
  http.logout(logout -> logout.logoutSuccessHandler(
    new OidcClientInitiatedServerLogoutSuccessHandler(clientRegistrationRepository)));

  // Require authentication for all requests
  http.authorizeExchange().anyExchange().authenticated();

  // Allow showing /home within a frame
  http.headers().frameOptions().mode(Mode.SAMEORIGIN);

  // Disable CSRF in the gateway to prevent conflicts with proxied service CSRF
  http.csrf().disable();
  return http.build();
}

設定

設定分為兩部分；OpenID Provider的一部分。issuer uri屬性參照RFC 8414 Authorization Server後設資料端點公開的bij Keyclope。如果附加。您將看到用於通過openid設定身份驗證的詳細資訊。請注意，我們還設定了user-name-attribute，以指示客戶機使用指定的宣告作為使用者名稱。

spring:
  security:
    oauth2:
      client:
        provider:
          keycloak:
            issuer-uri: http://localhost:8090/auth/realms/spring-cloud-gateway-realm
            user-name-attribute: preferred_username
        registration:
          keycloak:
            client-id: spring-cloud-gateway-client
            client-secret: 016c6e1c-9cbe-4ad3-aee1-01ddbb370f32

閘道器設定的第二部分包括到代理的路由和服務，以及中繼令牌的指令。

spring:
  cloud:
    gateway:
      default-filters:
      - TokenRelay
      routes:
      - id: flights-service
        uri: http://127.0.0.1:8081/flights
        predicates:
        - Path=/flights/**
      - id: hotels-service
        uri: http://127.0.0.1:8082/hotels
        predicates:
        - Path=/hotels/**

TokenRelay啟用TokenRelayGatewayFilterFactory，將使用者承載附加到下游代理請求。我們專門將路徑字首匹配到與伺服器對齊的server.servlet.context-path。

測試

OpenID connect使用者端設定要求設定的提供程式URL在應用程式啟動時可用。為了在測試中解決這個問題，我們使用WireMock記錄了keyclope響應，並在測試執行時重播該響應。一旦啟動了測試應用程式上下文，我們希望向閘道器發出經過身份驗證的請求。為此，我們使用Spring Security 5.0中引入的新SecurityMockServerConfigurers#authentication(Authentication)Mutator。使用它，我們可以設定可能需要的任何屬性；模擬閘道器通常為我們處理的內容。

資源伺服器

我們的資源伺服器只是名稱不同；一個用於航班，另一個用於酒店。每個都包含一個顯示使用者名稱的最小web應用程式，以突出顯示它已傳遞給伺服器。

依賴項

我們新增了org.springframework.boot:spring-boot-starter-oauth2-resource-server到我們的資源伺服器專案，它可傳遞地提供三個依賴項。

根據設定的OpenID Provider進行的令牌驗證通過org.springframework.security:spring-security-oauth2-resource-server
JSON Web標記使用org.springframework.security:spring-security-oauth2-jose
自定義令牌處理需要org.springframework.security:spring-security-config

程式碼

我們的資源伺服器需要更多的程式碼來客製化令牌處理的各個方面。

首先，我們需要掌握安全的基本知識；確保令牌被正確解碼和檢查，並且每個請求都需要這些令牌。

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    // Validate tokens through configured OpenID Provider
    http.oauth2ResourceServer().jwt().jwtAuthenticationConverter(jwtAuthenticationConverter());
    // Require authentication for all requests
    http.authorizeRequests().anyRequest().authenticated();
    // Allow showing pages within a frame
    http.headers().frameOptions().sameOrigin();
  }

  ...
}

其次，我們選擇從keyclope令牌中的宣告中提取許可權。此步驟是可選的，並且將根據您設定的OpenID Provider和角色對映器而有所不同。

private JwtAuthenticationConverter jwtAuthenticationConverter() {
  JwtAuthenticationConverter converter = new JwtAuthenticationConverter();
  // Convert realm_access.roles claims to granted authorities, for use in access decisions
  converter.setJwtGrantedAuthoritiesConverter(new KeycloakRealmRoleConverter());
  return converter;
}
[...]
class KeycloakRealmRoleConverter implements Converter<Jwt, Collection<GrantedAuthority>> {
  @Override
  public Collection<GrantedAuthority> convert(Jwt jwt) {
    final Map<String, Object> realmAccess = (Map<String, Object>) jwt.getClaims().get("realm_access");
    return ((List<String>) realmAccess.get("roles")).stream()
      .map(roleName -> "ROLE_" + roleName)
      .map(SimpleGrantedAuthority::new)
      .collect(Collectors.toList());
  }
}

第三，我們再次提取preferred_name作為身份驗證名稱，以匹配我們的閘道器。

@Bean
public JwtDecoder jwtDecoderByIssuerUri(<a href="https://javakk.com/tag/oauth2" rel="external nofollow"  target="_blank" >OAuth2</a>ResourceServerProperties properties) {
  String issuerUri = properties.getJwt().getIssuerUri();
  NimbusJwtDecoder jwtDecoder = (NimbusJwtDecoder) JwtDecoders.fromIssuerLocation(issuerUri);
  // Use preferred_username from claims as authentication name, instead of UUID subject
  jwtDecoder.setClaimSetConverter(new UsernameSubClaimAdapter());
  return jwtDecoder;
}
[...]
class UsernameSubClaimAdapter implements Converter<Map<String, Object>, Map<String, Object>> {

  private final MappedJwtClaimSetConverter delegate = MappedJwtClaimSetConverter.withDefaults(Collections.emptyMap());

  @Override
  public Map<String, Object> convert(Map<String, Object> claims) {
    Map<String, Object> convertedClaims = this.delegate.convert(claims);
    String username = (String) convertedClaims.get("preferred_username");
    convertedClaims.put("sub", username);
    return convertedClaims;
  }

}

設定

在設定方面，我們又有兩個不同的關注點。

首先，我們的目標是在不同的埠和上下文路徑上啟動服務，以符合閘道器代理設定。

server:
  port: 8082
  servlet:
    context-path: /hotels/

其次，我們使用與閘道器中相同的頒發者uri設定資源伺服器，以確保令牌被正確解碼和驗證。

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://localhost:8090/auth/realms/spring-cloud-gateway-realm

測試

酒店和航班服務在如何實施測試方面都採取了略有不同的方法。Flights服務將JwtDecoder bean交換為模擬。相反，酒店服務使用WireMock回放記錄的keyclope響應，允許JwtDecoder正常引導。兩者都使用Spring Security 5.2中引入的new jwt（）RequestPostProcessor來輕鬆更改jwt特性。哪種風格最適合您，取決於您想要具體測試的JWT處理的徹底程度和方面。