참고문헌
Method Security :: Spring Security
As already noted, there is a Spring AOP method interceptor for each annotation, and each of these has a location in the Spring AOP advisor chain. Namely, the @PreFilter method interceptor’s order is 100, @PreAuthorize's is 200, and so on. The reason this
docs.spring.io
Spring Method Security
Spring Security에 의한 인증 / 인가를 메소드 레벨에서 할 수 있게끔 제어하는 것이다.
대표적으로 @PreAuthorize, @PostAuthorize, @Secured와 같은 어노테이션으로 제어하는 행위이다.
기존 컨트롤러 엔드포인트별 접근 제어 방식
@Configuration
@RequiredArgsConstructor
public class SecurityConfig {
private final JwtAuthenticationFilter jwtAuthenticationFilter;
@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeRequests(authorizeRequests ->
authorizeRequests
// 특정 엔드포인트
// AuthenticationFilter에 의해 인증 / 인가된 사용자에 한해서만 접근 가능
.requestMatchers("/post/**")
.authenticated()
// 그 외의 엔드포인트는 전부 허용
.anyRequest()
.permitAll()
)
// ...
위와 같이 기존의 Spring Security Config에서는
requestMatchers와 authenticated() 를 통한 특정 컨트롤러 API 접근 시에는
AuthenticationFilter를 통과해 SecurityContextHolder를 통해 유저 정보가 Authentication 객체에 담긴 경우에만 해당 유저가 Spring Security에 의해 인증된 유저임을 인정받아 접근할 수 있다.
즉, 모든 서버의 엔드포인트에 대해서 Spring Security의 FilterChain 설정을 통해 관리가 가능한 것이다.
Spring Method Security 도입
Spring Method Security 도입 사유 :
이러한 SecurityConfig에 의해 모든 API에 대한 인증 / 인가 전역 설정은
개인의 차원에서는 편할 수 있었으나, 팀 단위 프로젝트 작업에서는 그렇지 않았다.
따라서, 메소드 레벨에서 작성되는 API 별로 인증 / 인가 처리할 수 있는 Spring Method Security를 도입하기로 결정했다.
[SecurityConfig에 의한 전역 API 인증 / 인가 설정]
* 장점
- 모든 API에 대한 접근 권한 설정을 전역적으로 처리가 가능함
* 단점
- SecurityConfig의 잦은 수정소요로 인해 Confilct 발생 시 인증 / 인가 설정이 누락되는 경우 발생
- 컨트롤러의 API 만 확인할 시 해당 API가 인증 / 인가를 필요로 하는지 확인이 불가능
[Spring Method Security 메소드 레벨에서의 인증 / 인가 설정]
* 장점
- 컨트롤러 API만 확인해도 해당 API가 인증 / 인가를 필요로 하고, 어떠한 인증 과정을 거치는지 확인 가능
- SecurityConfig git Conflict 날 일이 없음
* 단점
- 모든 컨트롤러의 메소드마다 인증 / 인가 처리할 시 별도 어노테이션이 명시되어야 함 (코드 증가)
Spring Method Security 적용 방법
[SecurityConfig.java]
@Configuration
@RequiredArgsConstructor
@EnableWebSecurity // EnableMethodSecurity 적용, 향후 OAUTH2 확장 고려
@EnableMethodSecurity(securedEnabled = true) // @PrePostEnabled = true(default)
public class SecurityConfig {
private final JwtAuthenticationFilter jwtAuthenticationFilter;
@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeRequests(authorizeRequests ->
authorizeRequests
.requestMatchers("/gen/**")
.permitAll()
// authorizeRequest에서의 permitAll은 명시적인 선언에 불과함
// 이후 접근 제어는 각 api 메소드 별로 수행
)
@EnableWebSecurity, @EnableMethodSecurity를 적용하여 메소드 레벨에서의 @PrePostEnable과 같은 개별의 인증 / 인가 범위 설정이 가능하게 한다.
* 향후 SecurityConfig에 선언되는 requestMatcher.permitAll()은 파일 업로드 및 기타 리소스 관련 파일 등
명시적으로 선언하기 위해 남겨두었다.
[ReportController.java]
@RestController
@RequestMapping(value = "/api/v1/reports", produces = APPLICATION_JSON_VALUE)
@Tag(name = "ReportController", description = "신고내역 컨트롤러 API")
@RequiredArgsConstructor
public class ReportController {
private final ReportService reportService;
// 메소드 단위로 api 별 접근 권한을 제어할 수 있음
// @Pre/Post Authorize의 차이점은 요청 전/후로 인증을 확인
@PreAuthorize("isAuthenticated()")
@GetMapping("/{id}")
public RsData<ReportResponseDto> get(@PathVariable(value = "id") Long id) {
ReportResponseDto responseDto = reportService.get(id);
loadReportAccess(responseDto);
return RsData.of("200", "ok", responseDto);
}
}
이후 컨트롤러 단의 API별로 @Pre/PostAuthorize를 활용해 인증 / 인가 설정을 진행한다.
주의사항
Pre/PostAuthorize("Authenticated()") 로 설정된 API에 대해 요청을 보낼 시
프론트 단에서는 해당 API에 대해 credential : true로 설정해야 한다.
useEffect(() => {
const fetchReportDetail = async () => {
try {
const response = await axios.get(
`http://localhost:8090/api/v1/reports/${id}`,
// 쿠키 인증 정보 포함을 위함
{ withCredentials: true }
);
setReportDetail(response.data.data);
} catch (error) {
console.error("Error fetching report detail:", error);
}
};