ServerHttpRequest を認証する

Spring Security は、受信 HTTP リクエストを認可するためのサポートを提供します。デフォルトでは、Spring Security の認可では、すべてのリクエストを認証する必要があります。明示的な構成は次のようになります。

すべてのリクエストには認証済みユーザーが必要です

Java
Kotlin

@Bean
SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
    http
        .authorizeExchange(exchanges -> exchanges
            .anyExchange().authenticated()
        )
        .httpBasic(withDefaults())
        .formLogin(withDefaults());
    return http.build();
}

@Bean
fun springSecurityFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
    return http {
        authorizeExchange {
            authorize(anyExchange, authenticated)
        }
        formLogin { }
        httpBasic { }
    }
}

Spring Security を構成して、優先順位の高いルールを追加することで、異なるルールを設定できます。

複数の承認リクエストルール

Java
Kotlin

import static org.springframework.security.authorization.AuthorityReactiveAuthorizationManager.hasRole;
// ...
@Bean
SecurityWebFilterChain springWebFilterChain(ServerHttpSecurity http) {
	http
		// ...
		.authorizeExchange((authorize) -> authorize                          (1)
			.pathMatchers("/resources/**", "/signup", "/about").permitAll()  (2)
			.pathMatchers("/admin/**").hasRole("ADMIN")                      (3)
			.pathMatchers("/db/**").access((authentication, context) ->      (4)
				hasRole("ADMIN").check(authentication, context)
					.filter(decision -> !decision.isGranted())
					.switchIfEmpty(hasRole("DBA").check(authentication, context))
			)
			.anyExchange().denyAll()                                         (5)
		);
	return http.build();
}

@Bean
fun springSecurityFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain {
    return http {
        authorizeExchange {                                                           (1)
            authorize(pathMatchers("/resources/**", "/signup", "/about"), permitAll)  (2)
            authorize("/admin/**", hasRole("ADMIN"))                                  (3)
            authorize("/db/**", { authentication, context ->                          (4)
                hasRole("ADMIN").check(authentication, context)
                    .filter({ decision -> !decision.isGranted() })
                    .switchIfEmpty(hasRole("DBA").check(authentication, context))
            })
            authorize(anyExchange, denyAll)                                           (5)
        }
        // ...
    }
}

1	複数の認可ルールが指定されています。各ルールは、宣言された順序で考慮されます。
2	すべてのユーザーがアクセスできる複数の URL パターンを指定しました。具体的には、URL が "/resources/" で始まるか、"/signup" に等しいか、"/about" に等しい場合、すべてのユーザーがリクエストにアクセスできます。
3	"/admin/" で始まる URL はすべて、権限 "ROLE_ADMIN" を持つユーザーに制限されます。`hasRole` メソッドを呼び出しているため、"ROLE_" プレフィックスを指定する必要がないことに気付くでしょう。
4	"/db/" で始まる URL には、ユーザーが "ROLE_ADMIN" と "ROLE_DBA" の両方を持っている必要があります。これは、カスタム `ReactiveAuthorizationManager` を提供する柔軟性を示しており、任意の認証ロジックを実装できます。簡単にするために、サンプルはラムダを使用し、既存の `AuthorityReactiveAuthorizationManager.hasRole` 実装に委譲します。ただし、実際の状況では、アプリケーションは `ReactiveAuthorizationManager` を実装する適切なクラスでロジックを実装する可能性があります。
5	まだ一致していない URL はアクセスを拒否されます。これは、認可規則の更新を誤って忘れたくない場合に適した戦略です。