Java 構成

Java 構成の一般的なサポートが Spring 3.1 の Spring Framework に追加されました。Spring Security 3.2 は、ユーザーが XML を使用せずに Spring Security を構成できるようにする Java 構成を導入しました。

セキュリティ名前空間の構成に精通している場合は、セキュリティ名前空間の構成と Spring Security Java 構成の間にかなりの類似点があるはずです。

Spring Security は、Spring Security Java 構成の使用法を示すための多くのサンプルアプリケーションを提供 [GitHub] (英語) します。

Hello Web セキュリティ Java 構成

最初のステップは、Spring Security Java 構成を作成することです。この構成により、springSecurityFilterChain と呼ばれるサーブレットフィルターが作成されます。これは、アプリケーション内のすべてのセキュリティ（アプリケーションの URL の保護、送信されたユーザー名とパスワードの検証、ログインフォームへのリダイレクトなど）を担当します。次の例は、Spring Security Java 構成の最も基本的な例を示しています。

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.context.annotation.*;
import org.springframework.security.config.annotation.authentication.builders.*;
import org.springframework.security.config.annotation.web.configuration.*;

@Configuration
@EnableWebSecurity
public class WebSecurityConfig {

	@Bean
	public UserDetailsService userDetailsService() {
		InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
		manager.createUser(User.withDefaultPasswordEncoder().username("user").password("password").roles("USER").build());
		return manager;
	}
}

この構成は複雑でも大規模でもありませんが、多くのことを行います。

アプリケーションのすべての URL に認証を要求する
ログインフォームを生成します
user のユーザー名と password のパスワードを持つユーザーにフォームベース認証で認証させます
ユーザーにログアウトさせます
CSRF 攻撃 [Wikipedia] 防止
セッション固定 [Wikipedia] 保護
セキュリティヘッダーの統合:
- セキュアリクエストの HTTP Strict Transport Security [Wikipedia]
- X-Content-Type-Options [Mozilla] 統合
- キャッシュ制御 (これは、アプリケーションの後半でオーバーライドして、静的リソースのキャッシュを許可できます。)
- X-XSS-Protection [Mozilla] 統合
- クリックジャッキング [Wikipedia] の防止に役立つ X-Frame-Options の統合
次のサーブレット API メソッドとの統合:

AbstractSecurityWebApplicationInitializer

次のステップは、springSecurityFilterChain を WAR ファイルに登録することです。これは、Servlet 3.0+ 環境の Spring の WebApplicationInitializer サポートを使用した Java 構成で行うことができます。当然のことながら、Spring Security は、springSecurityFilterChain が確実に登録されるようにするための基本クラス（AbstractSecurityWebApplicationInitializer）を提供します。AbstractSecurityWebApplicationInitializer の使用方法は、すでに Spring を使用しているかどうか、Spring Security がアプリケーションで唯一の Spring コンポーネントであるかどうかによって異なります。

Spring が存在しない AbstractSecurityWebApplicationInitializer - Spring をまだ使用していない場合は、これらの手順を使用してください
Spring MVC を使用した AbstractSecurityWebApplicationInitializer - すでに Spring を使用している場合は、これらの手順を使用してください

Spring が存在しない AbstractSecurityWebApplicationInitializer

Spring または Spring MVC を使用していない場合は、WebSecurityConfig をスーパークラスに渡して、構成が確実に取得されるようにする必要があります。

import org.springframework.security.web.context.*;

public class SecurityWebApplicationInitializer
	extends AbstractSecurityWebApplicationInitializer {

	public SecurityWebApplicationInitializer() {
		super(WebSecurityConfig.class);
	}
}

SecurityWebApplicationInitializer:

アプリケーション内のすべての URL に対して springSecurityFilterChain フィルターを自動的に登録します。
WebSecurityConfig をロードする ContextLoaderListener を追加します。

Spring MVC を使用した AbstractSecurityWebApplicationInitializer

アプリケーションの他の場所で Spring を使用している場合は、Spring 構成をロードしている WebApplicationInitializer がすでに存在している可能性があります。以前の構成を使用すると、エラーが発生します。代わりに、Spring Security を既存の ApplicationContext に登録する必要があります。例: Spring MVC を使用する場合、SecurityWebApplicationInitializer は次のようになります。

import org.springframework.security.web.context.*;

public class SecurityWebApplicationInitializer
	extends AbstractSecurityWebApplicationInitializer {

}

これにより、アプリケーション内のすべての URL に対して springSecurityFilterChain が登録されるだけです。その後、WebSecurityConfig が既存の ApplicationInitializer にロードされていることを確認する必要があります。例: Spring MVC を使用する場合、getServletConfigClasses() に追加されます。

public class MvcWebApplicationInitializer extends
		AbstractAnnotationConfigDispatcherServletInitializer {

	@Override
	protected Class<?>[] getServletConfigClasses() {
		return new Class[] { WebSecurityConfig.class, WebMvcConfig.class };
	}

	// ... other overrides ...
}

その理由は、基盤となるリクエストマッチャーを適切に構成するために、Spring Security が一部の Spring MVC 構成をインスペクションできる必要があるため、それらは同じアプリケーションコンテキスト内にある必要があるためです。Spring Security を getRootConfigClasses に配置すると、Spring MVC の HandlerMappingIntrospector を見つけられない可能性がある親アプリケーションコンテキストに配置されます。

複数の Spring MVC ディスパッチャーの構成

必要に応じて、Spring MVC に関係のない Spring Security 構成を次のように別の構成クラスに配置できます。

public class MvcWebApplicationInitializer extends
		AbstractAnnotationConfigDispatcherServletInitializer {

	@Override
    protected Class<?>[] getRootConfigClasses() {
		return new Class[] { NonWebSecurityConfig.class };
    }

	@Override
	protected Class<?>[] getServletConfigClasses() {
		return new Class[] { WebSecurityConfig.class, WebMvcConfig.class };
	}

	// ... other overrides ...
}

これは、AbstractAnnotationConfigDispatcherServletInitializer の複数のインスタンスがあり、それらの両方で一般的なセキュリティ構成を複製したくない場合に役立ちます。

HttpSecurity

これまでのところ、WebSecurityConfig には、ユーザーを認証する方法に関する情報のみが含まれています。Spring Security は、すべてのユーザーに認証を要求することをどのように認識しますか？ Spring Security は、フォームベース認証をサポートすることをどのように認識していますか？実際には、バックグラウンドで呼び出されている構成クラス（SecurityFilterChain と呼ばれる）があります。これは、次のデフォルトの実装で構成されています。

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
	http
		.authorizeHttpRequests(authorize -> authorize
			.anyRequest().authenticated()
		)
		.formLogin(withDefaults())
		.httpBasic(withDefaults());
	return http.build();
}

デフォルトの構成（前の例に示されています）:

アプリケーションへのリクエストでは、ユーザーの認証が必要であることを保証します
ユーザーがフォームベースのログインで認証できるようにします
ユーザーが HTTP 基本認証で認証できるようにします

この構成は、XML 名前空間構成と類似していることに注意してください。

<http>
	<intercept-url pattern="/**" access="authenticated"/>
	<form-login />
	<http-basic />
</http>

複数の HttpSecurity インスタンス

XML に複数の <http> ブロックを含めることができるのと同じように、複数の HttpSecurity インスタンスを構成できます。重要なのは、複数の SecurityFilterChain@Bean を登録することです。次の例では、/api/ で始まる URL の構成が異なります。

@Configuration
@EnableWebSecurity
public class MultiHttpSecurityConfig {
	@Bean                                                             (1)
	public UserDetailsService userDetailsService() throws Exception {
		// ensure the passwords are encoded properly
		UserBuilder users = User.withDefaultPasswordEncoder();
		InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
		manager.createUser(users.username("user").password("password").roles("USER").build());
		manager.createUser(users.username("admin").password("password").roles("USER","ADMIN").build());
		return manager;
	}

	@Bean
	@Order(1)                                                        (2)
	public SecurityFilterChain apiFilterChain(HttpSecurity http) throws Exception {
		http
			.securityMatcher("/api/**")                              (3)
			.authorizeHttpRequests(authorize -> authorize
				.anyRequest().hasRole("ADMIN")
			)
			.httpBasic(withDefaults());
		return http.build();
	}

	@Bean                                                            (4)
	public SecurityFilterChain formLoginFilterChain(HttpSecurity http) throws Exception {
		http
			.authorizeHttpRequests(authorize -> authorize
				.anyRequest().authenticated()
			)
			.formLogin(withDefaults());
		return http.build();
	}
}

1	通常どおり認証を構成します。
2	`@Order` を含む `SecurityFilterChain` のインスタンスを作成して、どの `SecurityFilterChain` を最初に考慮するかを指定します。
3	`http.securityMatcher` は、この `HttpSecurity` は `/api/` で始まる URL にのみ適用可能であると述べています。
4	`SecurityFilterChain` の別のインスタンスを作成します。URL が `/api/` で始まらない場合は、この構成が使用されます。この構成は、`1` の後に `@Order` 値があるため、`apiFilterChain` の後に考慮されます（`@Order` のデフォルトは持続しません）。

カスタム DSL

Spring Security で独自のカスタム DSL を提供できます。

Java
Kotlin

public class MyCustomDsl extends AbstractHttpConfigurer<MyCustomDsl, HttpSecurity> {
	private boolean flag;

	@Override
	public void init(HttpSecurity http) throws Exception {
		// any method that adds another configurer
		// must be done in the init method
		http.csrf().disable();
	}

	@Override
	public void configure(HttpSecurity http) throws Exception {
		ApplicationContext context = http.getSharedObject(ApplicationContext.class);

		// here we lookup from the ApplicationContext. You can also just create a new instance.
		MyFilter myFilter = context.getBean(MyFilter.class);
		myFilter.setFlag(flag);
		http.addFilterBefore(myFilter, UsernamePasswordAuthenticationFilter.class);
	}

	public MyCustomDsl flag(boolean value) {
		this.flag = value;
		return this;
	}

	public static MyCustomDsl customDsl() {
		return new MyCustomDsl();
	}
}

class MyCustomDsl : AbstractHttpConfigurer<MyCustomDsl, HttpSecurity>() {
    var flag: Boolean = false

    override fun init(http: HttpSecurity) {
        // any method that adds another configurer
        // must be done in the init method
        http.csrf().disable()
    }

    override fun configure(http: HttpSecurity) {
        val context: ApplicationContext = http.getSharedObject(ApplicationContext::class.java)

        // here we lookup from the ApplicationContext. You can also just create a new instance.
        val myFilter: MyFilter = context.getBean(MyFilter::class.java)
        myFilter.setFlag(flag)
        http.addFilterBefore(myFilter, UsernamePasswordAuthenticationFilter::class.java)
    }

    companion object {
        @JvmStatic
        fun customDsl(): MyCustomDsl {
            return MyCustomDsl()
        }
    }
}

これは、実際に HttpSecurity.authorizeHttpRequests() などのメソッドが実装される方法です。

その後、カスタム DSL を使用できます。

Java
Kotlin

@Configuration
@EnableWebSecurity
public class Config {
	@Bean
	public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
		http
			.with(MyCustomDsl.customDsl(), (dsl) -> dsl
				.flag(true)
			)
			// ...
		return http.build();
	}
}

@Configuration
@EnableWebSecurity
class Config {

    @Bean
    fun filterChain(http: HttpSecurity): SecurityFilterChain {
        http
            .with(MyCustomDsl.customDsl()) {
                flag = true
            }
            // ...

        return http.build()
    }
}

コードは次の順序で呼び出されます。

Config.filterChain メソッドのコードが呼び出されます
MyCustomDsl.init メソッドのコードが呼び出されます
MyCustomDsl.configure メソッドのコードが呼び出されます

必要に応じて、SpringFactories を使用して、デフォルトで HttpSecurity に MyCustomDsl を追加させることができます。例: META-INF/spring.factories という名前のクラスパスに、次の内容のリソースを作成できます。

META-INF/spring.factories

org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer = sample.MyCustomDsl

デフォルトを明示的に無効にすることもできます。

Java
Kotlin

@Configuration
@EnableWebSecurity
public class Config {
	@Bean
	public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
		http
			.with(MyCustomDsl.customDsl(), (dsl) -> dsl
				.disable()
			)
			...;
		return http.build();
	}
}

@Configuration
@EnableWebSecurity
class Config {

    @Bean
    fun filterChain(http: HttpSecurity): SecurityFilterChain {
        http
            .with(MyCustomDsl.customDsl()) {
                disable()
            }
            // ...
        return http.build()
    }

}

構成済みオブジェクトの後処理

Spring Security の Java 構成は、構成するすべてのオブジェクトのすべてのプロパティを公開するわけではありません。これにより、大多数のユーザーの構成が簡素化されます。結局のところ、すべてのプロパティが公開されている場合、ユーザーは標準の Bean 構成を使用できます。

すべてのプロパティを直接公開しないのには十分な理由がありますが、ユーザーはさらに高度な構成オプションを必要とする場合があります。この課題に対処するために、Spring Security は ObjectPostProcessor の概念を導入します。これは、Java 構成によって作成された Object インスタンスの多くを変更または置換するために使用できます。例: FilterSecurityInterceptor で filterSecurityPublishAuthorizationSuccess プロパティを構成するには、次を使用できます。

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
	http
		.authorizeHttpRequests(authorize -> authorize
			.anyRequest().authenticated()
			.withObjectPostProcessor(new ObjectPostProcessor<FilterSecurityInterceptor>() {
				public <O extends FilterSecurityInterceptor> O postProcess(
						O fsi) {
					fsi.setPublishAuthorizationSuccess(true);
					return fsi;
				}
			})
		);
	return http.build();
}