[Spring] Spring Security - application.yml로 URL권한을 동적으로 관리하기

로그인을 구현 안하고 바로 Spring security로 클라이언트 - 서버간 통신시키려 하니 당연히 403에러가 자꾸 나서 열받는다.

빨리 로그인을 먼저 구현해야 할 것 같은데... 원하는 기능을 다 만든 후 최후에 로그인을 만들고 싶어서 미뤄놨던 이리 귀찮은 댓가를 받게 되었다.

그래도 공부한다 생각해야지....

 

1. 원래는 어떻게 관리했었는가

SecurityConfig는 프로젝트에 적용할 보안 정책을 설정하고 적용을 하는 클래스이다. 

아무 설정 없이 클라이언트와 통신하려면 403 forbidden에러를 만나게 될 것이다.

그래서 클라이언트로부터 오는 url을 허용시키기 위해 requestMatchers에 다음과 같이 작성했었다.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
                    .requestMatchers("/chat/**", "/uploads/**", "/diary/**").permitAll()
                    .requestMatchers(securityProperties.getPermitUrls().toArray(new String[0])).permitAll()
                    .anyRequest().authenticated())
            .csrf(csrf->csrf.disable())
            .headers(headers -> headers.frameOptions(frameOptions -> frameOptions.disable()));
            .headers(headers -> headers.frameOptions(frameOptions -> frameOptions.disable())
            );

    return http.build();
}

근데 봐서 알겠지만... 내가 새로운 화면과 url을 만들때마다 저렇게 문자열로 계속 추가할 순 없는 노릇이다. 

그래서 따로 관리하기로 했다.

 

2. application.yml 생성

application.yml은 resource/config파일에 작성했다.

security:
  permit-urls:
    - /chat/**
    - /uploads/**
    - /diary/**

이제 저렇게 작성하면 위 url을 포함하는 클라이언트 요청은 받아들여지게 된다.

참고로 ,는 절대 금물! ,는 무조건 뺄것. 원래는 chat, uploads... 이렇게 썼는데 콤마를 붙이니까 통신이 안이루어졌다. 알고보니 문법오류라고

 

3. ClientSecurityProperties.java 생성

SecurityConfig파일이 있는 같은 파일 아래 ClientSecurityProperties파일을 하나 생성해서 만든다. 

이 파일의 용도는 application.yml의 설정값을 Java 객체로 변환하여 보관하는 클래스이다. 

 

위에서 보면 알겠지만, permit-urls에는 다양한 URL이 담겨있으므로 반드시 List<String>으로 저장해둬야 한다. 

따라서 자료형은 List<String>이다.

@Configuration
@ConfigurationProperties(prefix="security")
public class ClientSecurityProperties {

    // private Field
    private List<String> permitUrls;
    
    // getter
    private List<String> getPermitUrls() {
      return permitUrls;
    }
    
    // setter
    private void setPermitUrls() {
      this.permitUrls = permitUrls;
    }   

}

ClientSecurityProperties의 역할은 다음과 같다.

 

1️⃣ application.yml의 값을 Java 객체로 바인딩

application.yml 혹은 application.properties의 값을 자바 코드 내에서 List<String>자료구조로 사용하려면 특정 객체의 필드에 매핑하는 과정이 필요하다.

• @Configuration : @Component를 사용해도 상관은 없지만, 설정과 관련된 파일임을 명시하기 위해 @Configuration을 작성하는게 관례이다. 지금 이 클래서그 '설정 클래스'임을 명시하여 Spring 컨테이너에 등록되게 한다.
• @ConfigurationProperties(perfix="security") : appication.yml의 security: 아래의 모든 속성을 이 클래스에 매핑시킨다. 
  • ex) chat, uploads, diary를 모두 List<String>의 형태로 permitUrls에 매핑

 

2️⃣ Spring Bean으로 등록 및 의존성 주입(DI)

SecurityConfig에서 permitUrls목록을 사용하려면 ClientSecurityProperties의 인스턴스가 Spring IoC 컨테이너에 의해 관리되는 Bean으로 등록되야 한다. 

SecurityConfig의 생성자에서 ClientSecurityProperties를 매개변수로 받아 의존성 주입(DI)를 실행할 수 있도록 한다. 'ClientSecurityProperties에 대한 SecurityConfig의 의존'

따라서 SecurityConfig에선

// SecurityConfig

public class SecurityConfig { 

... 생략, 
    private final ClientSecurityProperties securityProperties; // 의존성 주입(DI)

위와 같이 사용할 수 있다.

3️⃣동적인 목록 사용

목록이 아닌 단일 값(String)이라면 @Value를 이용할 수도 있지만, 지금과 같이(chat, upload, diary....) 여러개를 관리하는 상황일 땐 @ConfigurationProperties를 사용하는 것이 더 권장된다.

 

결론: SecurityConfig.java와 application.yml의 '중간 다리' 역할

 

➕기본 생성자와 매개변수 생성자

기본 생성자의 형태 : public ClientSecurityProperties() {}

1. 반드시 public이어야 한다
2. 현재 코드에서 없는 이유: Java Compiler가 자동으로 기본생성자를 만든 상태이다
3. setter 방식 바인딩을 위해서라도 @ConfigurationProperties는 기본 생성자가 있어야 한다.

매개 변수 생성자의 형태 : public SecurityConfig(ClientSecurityProperties securityProperty) { }

1. 현재 코드에선 Spring Security 설정에서 가장 권장되는 방식인 생성자 주입을 사용하고 있다.

// 기본 생성자의 형태
public ClientSecurityProperties(){}

// 매개변수 생성자의 형태
public SecurityConfig(ClientSecurityProperties securityProperty) {}

 

➕Java Compiler VS JVM

• Java Compiler : .java 에서 .class로 변환, 컴파일 시점에 실행됨
• JVM : .class를 실행, Run 시점에서 실행됨

➕ Getter, Setter, this 키워드

// Getter의 형태
public List<String> getPermitUrls() {
  return permitUrls;
}

// Setter의 형태
public void setPermitUrls() {
  this.permitUrls = permitUrls;
}

계속 롬복쓰다 이거 보니까 좀 반갑고... 오랜만인거 같다...

항시 잊지 말것

간단한 복습 차원에서 정리했다..

• Getter, Setter에 대해 더 자세하게 읽을려면 여기 클릭
• ⭐this : 현재 객체(인스턴스) 자신, 여기선 즉 ClientSecurityProperties 그 자체를 가리킴. 따라서 this.permitUrls는 ClientSecurityProperties의 permitUrls를 가리키는 것으로, 현재 객체 필드를 의미한다.

4. SecurityConfig 작성

SecurityConfig의 역할은 1️⃣보안 필터 없이 체인 구성, 2️⃣인증 없이 접근 가능한 URL 설정, 3️⃣모든 HTTP요청에 대한 보안 검증 수행이다.

@Configuration
@EnableWebSecurity

public class SecurityConfig {
  private final ClientSecurityProperties securityProperties; // DI준비
  
  public SecurityConfig(ClientSecurityProperties securityProperties) {
    this.securityProperties = securityProperties; // DI
  }
  
  @Bean
  public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
      .requestMatchers(securityProperties.getPermitUrls().toArray(new String[0])).permitAll()
      .anyRequest(). authenticated())
      .csrf(csrf -> csrf.disable())
      .headers(headers -> headers.frameOptions(frameOptions -> frameOptions.disable())
      );
    return http.build();
  }

}

• @Configuration은 앞과 같다. 해당 Java파일이 'Spring 설정 클래스'임을 선언
• @EnableWebSecurity : Spring Security의 핵심 기능을 활성화하고, 웹 보안 설정을 이 클래스(SecurityConfig)에서 설정한다는 뜻의 어노테이션

여기서도 아까와 마찬가지로 this에 대해서 복습할 수 있다.

 

1️⃣ 의존성 주입(DI)

• private final ClientSecurityProperties securityProperties 
  • ⭐= SecurityConfig의 필드부 ⭐
  • 기존에 정의했던 ClientSecurityProperties Bean을 주입받을 필드 준비
  • Spring Boot는 생성자 주입 방식을 사용하는데, Spring 컨테이너는 ClientSecurityProperties Bean을 찾아서 SecurityConfig 생성 시 생성자 매개변수로 ClientSecurityProperties를 자동으로 전달할 수 있도록 세팅
• public SecurityConfig(ClientSecurityProperties securityProperties){}
  • 매개변수가 있는 생성자
  • 매개변수를 통해 ClientSecurityProperties를 주입받음(DI실행)
  • 기본 생성자는 매개변수가 없다. ex) public SecurityConfig() {}와 같이
• this.securityProperties = securityProperties;
  • 헷갈리지 말것! 여기서 this는 ClientSecurityProperties가 아닌 SecurityConfig
  • 따라서 private final ClientSecurityProperties securityProperties는 SecurityConfig의 필드부
  • securityProperties : ClientSecurityProperties에서 받은 값들을 사용할 수 있도록 대입함

2️⃣ 보안 필터 체인 설정

Spring Security 핵심 보안 정책을 설정하는 곳

• authorizeHttpRequests : 접근 권한 설정 영역
  • authorizeHttpRequests(auth -> auth...) : Http 요청에 대한 검증 시작 선언
  • .requestMatchers(...).permitAll() : ClientSecurityProperties에서 가져온 URL 목록에 해당하는 요청들은 인증 없이 접근을 허용
  • .anyRequest().authenticated() : 앞에 규칙에 해당되지 않는 모든 요청들은 접근을 허용하도록 강제 (ex. 로그인 필요 etc)
• .csrf(csrf -> csrf.disable()) : CSRF 보호 기능을 비활성화
• .headers(headers -> headers.frameOptions(frameOptions -> frameOptions.disable()) : X-Frame-Options 헤더 설정을 비활성화. 주로 iFrame 내에서 페이지 로드를 허용해야 할 경우에 사용됨
• return http.build() : 설정 보안이 모두 갖춰진 SecurityFilterChain 객체를 반환, Spring Bean으로 등록. 실제 웹 요청을 처리하는 보안 필터 체인으로 사용

5. 결과

잘 통신해서 API 연결되는것 확인!