[Spring Security] 5.7 부터의 WebSecurityConfigureAdapter 와 SecurityConfig

안녕하세요

오늘은 Spring Boot 와 Spring Security 의 버전 업데이트에 따라

변경된 Security 의 Configuration 구성 방식에 대해 말씀드리겠습니다.

 

우선 22년 2월 22일 (오 날짜..)

Spring Security 5.7 이 release 되면서 Configuration 에 대한 큰 변화가 생겼습니다.

 

https://github.com/spring-projects/spring-security/releases/tag/5.7.0-M2 

Release 5.7.0-M2 · spring-projects/spring-security

 

또한 마찬가지로 Spring Boot 2.7.0 버전부터 Spring Security 5.7 이 반영되어지면서

만약 프로젝트의 version 을 2.7+ 로 변경하시게 될 경우,

기존 레거시의 Security Configuraion 을 변경하셔야합니다.

 

https://github.com/spring-projects/spring-boot/releases/tag/v2.7.0

Release v2.7.0 · spring-projects/spring-boot

 

자 그럼 이제부터

어떤 점이 변경되었고,

왜 변경되었고,

어떻게 변경해야하는지

에대해서 설명드리겠습니다 :) 

 

어떤 점이 변경되었는가?

우선 사실 Spring Boot 2.7 이 배포되었지만,

아직 많은 분들이 2.6.* 를 사용하시기에, 아마 변화에대해서 큰 감지를 못하셨을겁니다.

(22.06 기준)

 

저는 이번 주말에 토이 프로젝트를 수행하던중에 Spring Boot 2.7.0 을 선택하게되었고,

Security Setting 을 하던 와중에 WebSecurityConfigureAdapter 가 Deprecated 된것을 보았습니다.

우선 면밀히 말하자면,

Spring Security의 5.7 부터 WebSecurityConfigurerAdapter 를 상속한 SecurityConfig 구성 방식을 지양하게 된것인데요

 

잠깐 모르시고 사용하시는 분들이 있을 수 있으니, 

WebSecurityConfigurerAdapter 를 상속한 Configuration 구성에 대해서 잠시 설명드리겠습니다

여러 디자인 패턴이 적용되었으며, 특히나 Template Method 패턴 적용이 확연하게 들어납니다.
Spring Boot 를 사용하면, Auto Configuration 을 통해 미리 관례로, Default 로 Configuration 이 구성되어집니다.
그리고 사용자는 @EnableWebSecurity 를 통해 HttpSecurityConfiguration, WebSecurityConfiguration 등
Security 구성에 필요한 기본 구성들을 @Import 를 통해 미리 주입받으면서,
WebSecurityConfigurerAdapter 를 상속받아 Security Configuration 을 커스터마이징하여 
FilterChainProxy 를 구성하게 됩니다.

아래 블로그에서 Security의 큰 flow에 대해서 간략히 요약이 잘되어있으니 참고해주세요! 
https://yoon0120.tistory.com/47

 

Spring Security는 5.7 부터 해당 패턴에 대해 사용을 지양하여 Deprecated 시켰으며,

새로운 방식으로 Security Configuration 을 커스터마이징 해야합니다.

 

 

왜 바뀌었을까?

그럼 잘 쓰고있던 패턴을 왜 갑자기 바꾸었을까 하는 궁금증이 분명히 드실겁니다.

 

우선 설명에 앞서 해당 변경에 대한 공식 issue 를 참고하시면 좋습니다!

https://github.com/spring-projects/spring-security/issues/10822

Deprecate WebSecurityConfigurerAdapter · Issue #10822 · spring-projects/spring-security

 

그리고 이러한 변경 이유에 대한 핵심은 바로

람다를 활용한 Component 구성 방식 이라고 생각합니다.

 

공식 블로그의 설명에 따르면,

WebSecurityConfigurerAdapter 를 지양한것은

사용자로 하여금 Component 기반의 Security 설정을 하기 위함 이라고 설명합니다.

 

Component 기반이라하면,

단순히 Chaining 형식으로 쭉 나열된 구성이 아니라

각 설정이 필요한 요소에 대한 Bean (Component)에 대해 설정을 직접하고 주입하는 방식을 의미합니다.

 

또한 이번 반영은 갑자기 툭- 튀어나온 변화가 아니라,

5.2 부터 예견된 변화입니다.

 

5.2 업데이트에서 설정에 있어 람다 형식 (함수형방식) 이 적용되기 시작했습니다.

https://spring.io/blog/2019/11/21/spring-security-lambda-dsl

Spring Security - Lambda DSL

 

즉 기존에

http.formLogin().disable()

       .and()

       ...

이런 chaining 방식에서 벗어나

 

http.formLogin(AbstractHttpConfigurer::disable)

       .httpBasic(AbstractHttpConfigurer::disable)

...

 

과 같이 람다를 통해 표현하는 방식으로 변경되었습니다.

 

이런 변화하는 프로그래밍 유연한 방법론에 따라

SpringSecurity도 설정방식에 변화를 준것입니다.

 

또한 이런 변화의 추가적인 장점으로는

- .and() 와 같은 연결 메서드가 사라짐

- withDefault() 를 통해 기본설정이 편하게 가능함

- MVC module 뿐 아니라, WebFlux 에서도 함수형에 맞게 설정이 가능함

 

등이 있습니다.

 

그래서 어떻게 변경해야하는데?

그럼 이제 기존 방식에서 어떻게 변경을 해야하는지 알아보겠습니다.

 

가장 우선

@EnableWebSecurity 는 유지한체로

WebSecurityConfigurerAdapter 에 대한 상속을 지워야합니다.

 

@EnableWebSecurity 는 HttpSecurity, WebSecurity 등 과 같이

FilterChain 생성에 영향을 주는 인스턴스에 대한 구성정보와 Bean 생성을 담당합니다.

HttpSecurityConfiguration 내의 HttpSecurity Bean 주입

 

이렇게 두가지를 통해 기본 세팅만되어도,

이제 변경된 방식을 활용할 수 있습니다.

 

핵심은 기존에 @Override 를 통해 설정한 방식에서 벗어나

@Bean 을 통해 SecurityFilterChain 으로 새롭게 등록한다는 것입니다.

 

WebSecurity 도 마찬가지로 커스터마이징후에 WebSecurityCustomizer 를 빈으로 등록해

Spring Security Filter에 대한 빈 등록을 수행합니다.

 

 

 

사실 긴 글과 설명에 비해 코드상 변경할 것은 기본적인 상속과 빈에 대한 변경외에는 큰 변화가 없습니다.

 

 

또한 Spring 에서도 많은 사람들이 혼란을 걱정해

블로그로 친절하게 디테일한 설정에 대해서도 설명을 해주었습니다.

(제 글도 해당 블로그를 많이 참고했습니다 :) )

 

https://spring.io/blog/2022/02/21/spring-security-without-the-websecurityconfigureradapter

Spring Security without the WebSecurityConfigurerAdapter

 

기대효과

아마 앞으로도 기존 레거시 방식들에 대해 이런 변화가 많이 일어날 것입니다.

(함수형 프로그래밍을 지향하는 추세..)

그래서 자바 스프링에서 코프링으로 많이 변화되는 여파로 이어지는것일수도 있지않을까? 생각합니다.

 

많은 분들께서 이 글을 통해

Deprecate 된 방식에 대해 당황하지마시고 

대응을 잘 하기를 바라며 글 마치겠습니다 :)

 

긴 글 읽어주셔서 감사합니다.