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

Posted on by

前言

當與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處理的徹底程度和方面。

結論

有瞭所有這些，我們就有瞭功能網關的基礎。它將用戶重定向到keydeport進行身份驗證，同時對用戶隱藏JSON Web令牌。對資源服務器的任何代理請求都使用適當的access_token來豐富，該token令牌經過驗證並轉換為JwtAuthenticationToken，以用於訪問決策。

到此這篇關於基於OpenID Connect及Token Relay實現Spring Cloud Gateway的文章就介紹到這瞭,更多相關Spring Cloud Gateway內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：