最新の安定バージョンについては、Spring Security 6.4.2 を使用してください！

AuthorizationFilter で HttpServletRequests を認証する

このセクションは、サーブレットベースのアプリケーション内で認可がどのように機能するかを深く掘り下げて、サーブレットのアーキテクチャと実装に基づいています。

AuthorizationFilter は FilterSecurityInterceptor に取って代わります。下位互換性を維持するために、FilterSecurityInterceptor はデフォルトのままです。このセクションでは、AuthorizationFilter がどのように機能するか、およびデフォルト構成をオーバーライドする方法について説明します。

AuthorizationFilter (Javadoc) は、HttpServletRequest の認可を提供します。セキュリティフィルターの 1 つとして FilterChainProxy に挿入されます。

SecurityFilterChain を宣言するときに、デフォルトをオーバーライドできます。authorizeRequests を使用する代わりに、次のように authorizeHttpRequests を使用します。

authorizeHttpRequests を使用する

  • Java

@Bean
SecurityFilterChain web(HttpSecurity http) throws AuthenticationException {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().authenticated();
        )
        // ...

    return http.build();
}

これにより、authorizeRequests がいくつかの点で改善されます。

  1. メタデータソース、構成属性、意思決定マネージャー、投票者の代わりに、簡略化された AuthorizationManager API を使用します。これにより、再利用とカスタマイズが簡単になります。

  2. Authentication ルックアップを遅らせます。リクエストごとに認証を検索する必要はなく、認可の決定で認証が必要なリクエストでのみ認証が検索されます。

  3. Bean ベースの構成のサポート。

authorizeRequests の代わりに authorizeHttpRequests が使用される場合、FilterSecurityInterceptor の代わりに AuthorizationFilter (Javadoc) が使用されます。

authorizationfilter
図 1: HttpServletRequest を認証する

  • number 1 まず、AuthorizationFilter は SecurityContextHolder から認証を取得します。ルックアップを遅らせるために、これを Supplier でラップします。

  • number 2 次に、Supplier<Authentication> と HttpServletRequest を AuthorizationManager に渡します。

    • number 3 認可が拒否された場合、AccessDeniedException がスローされます。この場合、ExceptionTranslationFilter は AccessDeniedException を処理します。

    • number 4 アクセスが許可されると、AuthorizationFilter は FilterChain を続行します。これにより、アプリケーションは正常に処理できます。

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

リクエストを承認する

  • Java

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
	http
		// ...
		.authorizeHttpRequests(authorize -> authorize                                  (1)
			.mvcMatchers("/resources/**", "/signup", "/about").permitAll()         (2)
			.mvcMatchers("/admin/**").hasRole("ADMIN")                             (3)
			.mvcMatchers("/db/**").access((authentication, request) ->
			    Optional.of(hasRole("ADMIN").check(authentication, request))
			        .filter((decision) -> !decision.isGranted())
			        .orElseGet(() -> hasRole("DBA").check(authentication, request));
			)   (4)
			.anyRequest().denyAll()                                                (5)
		);

	return http.build();
}
1 複数の認可ルールが指定されています。各ルールは、宣言された順序で考慮されます。
2 すべてのユーザーがアクセスできる複数の URL パターンを指定しました。具体的には、URL が "/resources/" で始まるか、"/signup" に等しいか、"/about" に等しい場合、すべてのユーザーがリクエストにアクセスできます。
3"/admin/" で始まる URL は、"ROLE_ADMIN" のロールを持つユーザーに制限されます。hasRole メソッドを呼び出しているため、"ROLE_" プレフィックスを指定する必要がないことに気付くでしょう。
4"/db/" で始まる URL には、ユーザーが "ROLE_ADMIN" と "ROLE_DBA" の両方を持っている必要があります。hasRole 式を使用しているため、"ROLE_" プレフィックスを指定する必要がないことに気付くでしょう。
5 まだ一致していない URL はアクセスを拒否されます。これは、認可規則の更新を誤って忘れたくない場合に適した戦略です。

次のように独自の RequestMatcherDelegatingAuthorizationManager を構築することにより、Bean ベースのアプローチをとることができます。

RequestMatcherDelegatingAuthorizationManager の設定

  • Java

@Bean
SecurityFilterChain web(HttpSecurity http, AuthorizationManager<RequestAuthorizationContext> access)
        throws AuthenticationException {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().access(access)
        )
        // ...

    return http.build();
}

@Bean
AuthorizationManager<RequestAuthorizationContext> requestMatcherAuthorizationManager(HandlerMappingIntrospector introspector) {
    RequestMatcher permitAll =
            new AndRequestMatcher(
                    new MvcRequestMatcher(introspector, "/resources/**"),
                    new MvcRequestMatcher(introspector, "/signup"),
                    new MvcRequestMatcher(introspector, "/about"));
    RequestMatcher admin = new MvcRequestMatcher(introspector, "/admin/**");
    RequestMatcher db = new MvcRequestMatcher(introspector, "/db/**");
    RequestMatcher any = AnyRequestMatcher.INSTANCE;
    AuthorizationManager<HttpRequestServlet> manager = RequestMatcherDelegatingAuthorizationManager.builder()
            .add(permitAll, (context) -> new AuthorizationDecision(true))
            .add(admin, AuthorityAuthorizationManager.hasRole("ADMIN"))
            .add(db, AuthorityAuthorizationManager.hasRole("DBA"))
            .add(any, new AuthenticatedAuthorizationManager())
            .build();
    return (context) -> manager.check(context.getRequest());
}

リクエストマッチャーに対して独自のカスタム認証マネージャーを接続することもできます。

カスタム認可マネージャーを my/authorized/endpoint にマッピングする例を次に示します。

カスタム認証マネージャー

  • Java

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .mvcMatchers("/my/authorized/endpoint").access(new CustomAuthorizationManager());
        )
        // ...

    return http.build();
}

または、以下に示すように、すべてのリクエストに提供できます。

すべてのリクエストに対するカスタム認証マネージャー

  • Java

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest.access(new CustomAuthorizationManager());
        )
        // ...

    return http.build();
}

デフォルトでは、AuthorizationFilter は DispatcherType.ERROR および DispatcherType.ASYNC には適用されません。shouldFilterAllDispatcherTypes 方式を使用して、すべてのディスパッチャー型に認可ルールを適用するように Spring Security を設定できます。

shouldFilterAllDispatcherTypes を true に設定する

  • Java

  • Kotlin

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .shouldFilterAllDispatcherTypes(true)
            .anyRequest.authenticated()
        )
        // ...

    return http.build();
}
@Bean
open fun web(http: HttpSecurity): SecurityFilterChain {
    http {
        authorizeHttpRequests {
            shouldFilterAllDispatcherTypes = true
            authorize(anyRequest, authenticated)
        }
    }
    return http.build()
}