[Study-10, 11주차] SpringSecurity 적용

 

[Study-8, 9주차] @RestControllerAdvice 활용 Exception + 동적쿼리 적용 및 고찰 + N+1 문제에 대한 고찰 - ②

[Study-8, 9주차] @RestControllerAdvice 활용 Exception + 동적쿼리 적용 및 고찰 + N+1 문제에 대한 고찰 - ②

 

---

 

• Admin Table 구축
  • Long id; //PK
  • String name;
  • String identity;
  • String password;
  • Role role; - Enum Class (일반 USER_ROLE) (관리자 ADMIN_ROLE)
• Spring Security 공부해오기.
• DB Index 하고 싶은 사람 해오기.

 

이번 스터디에서 진행해주기로 한 내용은 위와 같다. 

우선 해당 내용들에 들어가기 앞서 DB Index, Security에 대해 기존의 정리했던 내용들을 첨부할것이다. 해당 내용의 이론을 보고 진행하는 것이 더 유용할 것이다. DB 인덱스에 대해 공부를 해보았지만, 현재 프로젝트의 규모도 작고 우선적으로 조치가 필요한 작업이 아닌것 같기에 어떤 속성에 인덱스를 추가해줘야 할지 살펴본 후, 나중에 추가해주기로 생각했다.

또한 Admin 테이블을 생성해주기로 했는데, Role을 통해 사용자가 관리자인지 일반 유저인지 확인할 수 있기에 테이블 명이 적절하지 않은 것 같아 우선 Member로 수정해서 작업을 해줄 생각이다.

[Study] DB 인덱스(Index) 란?

[Study] DB 인덱스(Index) 란?

[개념] Spring Security 란 무엇인가?

[개념] Spring Security 란 무엇인가?

 

---

 

Spring Security

Spring Security를 적용해주기 위해서 구글링을 많이 해봤지만 대부분 구 버전의 내용들이 있었다.
스프링부트 3.0 이상 부터 Spring Security 6.0.0 이상의 버전이 적용이 되었다. 현재 우리가 진행하는 pet-clinic 프로젝트는 3.0 이상의 버전을 사용하고 있기에, 새롭게 적용된 Spring Security 6.0.0 버전 이상을 구현해줘야 한다. 기존에 사용해주던 방식들의 deprecated 된 것들이 많기에, 새롭게 바뀐 버전으로 적용해 줄 것이다.

우선적으로, Spring Security를 적용하기 위해서 build.gradle에 의존성을 추가해줬다.

// Security
implementation 'org.springframework.boot:spring-boot-starter-security'

 

위처럼 의존성을 작성해준 후, 프로젝트를 실행하게 되면 콘솔창에 아래처럼 임의로 발행된 security password를 확인할 수 있다. 그 다음 localhost:8080 로 접속을 하게 되면, 우리는 controller 화면을 구현해주지 않았기에, 오류 화면이 나와야하지만 아래처럼 로그인을 할 수 있는 화면으로 넘어가게 된다. 해당 화면에서 id는 user로 password는 아래의 임의로 발행된 security password를 입력하게 되면 기존의 우리가 구현하지 않아 오류가 발생하는 화면인 Whitelabel Error Page가 출력이 된다.

 

---

 

SecurityConfiguration

Security 설정 정보를 입력해주기 위해서 아래와 같이 해당 클래스 파일을 생성해주었다.

 

package kr.co.jshpetclinicstudy.infra.config;

@Configuration
@EnableWebSecurity
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        // jwt 사용을 해줄 것 이기에 csrf 비활성화
        http
                .csrf().disable()
                .cors().disable();

        // Authorization (인가)
        http
                .authorizeHttpRequests()
                .anyRequest()
                .authenticated();

        // Authentication (인증)
        http
                .formLogin();

        return http.build();
    }

}

 

우선 위의 코드를 하나씩 살펴보면 다음과 같다.

1. http.csrf().disable(); / http.cors().disable();

우리는 추후 jwt를 추가해줄 것이다. 그렇기에 csrf.disable()을 해줄것이다. cors의 경우는 현재 제대로 공부하지 않았기에 해당 기능 또한 disable() 해주었다.

[개념] CORS란 무엇인가?

[개념] CSRF란 무엇인가?

그렇다면 왜 csrf.disable() 해주는 것일까?

JWT (JSON Web Token)는 stateless한 인증 방식으로, 서버에서 클라이언트의 상태를 유지하지 않고 요청을 처리한다. 이는 CSRF(Cross-Site Request Forgery) 공격에 대한 추가적인 보호 기능을 제공하는데 도움이 된다. 따라서 JWT를 사용하는 경우 CSRF 보호 기능을 비활성화하는 것이 일반적으로 안전하다.

CSRF에 대해 간단히 설명하며 다음과 같다.
CSRF 공격은 공격자가 사용자의 권한으로 요청을 위장하여 악의적인 작업을 수행하는 것이다. 이를 방지하기 위해 CSRF 토큰이 사용될 수 있는데, 서버는 이 토큰을 생성하고 클라이언트에게 전달하여 요청에 포함시키도록 요구한다. 그러나 JWT는 토큰 자체가 클라이언트의 인증 정보를 포함하고 있기 때문에 별도의 CSRF 토큰을 사용할 필요가 없다.

JWT를 사용하는 경우, 클라이언트는 각 요청에서 JWT를 헤더나 쿼리 매개변수 등에 포함시켜서 서버에 전달한다. 서버는 이 JWT를 검증하여 클라이언트의 신원을 확인하고 인증을 수행한다. 이 과정에서 JWT는 서명되어 있어 변조가 불가능하며, 토큰에 포함된 클라이언트의 권한을 기반으로 요청을 처리한다. 따라서, JWT를 사용하는 경우 서버는 클라이언트의 상태를 유지하지 않으므로 CSRF 공격에 대한 추가적인 보호 기능을 제공하는 CSRF 토큰을 사용할 필요가 없다. 

 

여기서 "stateless" 하다는 것은 무엇을 의미할까?

"stateless"는 상태를 유지하지 않는다는 것으로, 서버가 클라이언트의 상태를 저장하거나 추적하지 않고 각 요청을 독립적으로 처리하는 것을 의미한다.

일반적으로 웹 애플리케이션에서는 세션(session) 기반 인증 방식을 사용하는데, 이는 서버가 클라이언트의 상태를 세션에 저장하고 유지한다. 클라이언트가 로그인하면 서버는 해당 세션을 생성하고 클라이언트의 상태를 저장하여 유지한다. 이에 반해 stateless한 시스템에서는 클라이언트의 상태를 서버에 저장하지 않으며, 각 요청은 클라이언트가 필요한 모든 정보를 요청 자체에 포함시켜야 한다.
예를 들어, RESTful API는 stateless한 아키텍처 스타일로, 클라이언트가 서버에 요청을 보낼 때 필요한 모든 정보를 요청에 포함시킨다. 서버는 해당 요청을 독립적으로 처리하고 응답을 반환하며, 클라이언트와의 상태를 유지하지 않는다. 클라이언트는 각 요청에서 필요한 인증 정보나 상태를 함께 전달하여 서버가 요청을 올바르게 처리할 수 있도록 한다.

stateless한 시스템은 확장성과 유연성을 향상시키는 장점이 있다. 상태를 유지하지 않기 때문에 서버는 클라이언트의 상태를 저장하거나 관리할 필요가 없으며, 여러 서버 인스턴스로 확장하는 것이 용이하다. 또한 클라이언트는 서버와 독립적으로 작업을 수행할 수 있으며, 서버 간의 부하 분산이 가능해진다.
요약하면, stateless는 서버가 클라이언트의 상태를 저장하거나 추적하지 않는다는 의미이다. 각 요청은 클라이언트가 필요한 모든 정보를 요청에 포함시켜야 하며, 서버는 요청을 독립적으로 처리한다. 이는 RESTful API와 같은 stateless한 아키텍처 스타일에서 사용되며, 확장성과 유연성을 제공한다.

 

2. http.authorizeRequests().anyRequest().authenticated();

인가에 대한 설정을 수행하는 것으로, 모든 요청에 대하여 인증된 사용자만 접근할 수 있도록 설정해준 것이다. 즉, 인증된 사용자만이 애플리케이션의 모든 리소스에 접근이 가능하다는 것이다.

 

3. http.formLogin()

인증에 대한 설정을 수행하는 것으로, 폼 기반 로그인을 사용하도록 설정하고 있다. 

 

---

 

 

Member Entity, Role 생성

 

Spring Security에서 제공해주는 기능 중 강력하고 유용한 기능인 권한 기능을 사용해주기 위해서 Member Entity와 Enum class인 Role 을 생성해 줄 것이다. 

package kr.co.jshpetclinicstudy.persistence.entity;

@Entity
@AttributeOverride(name = "id", column = @Column(name = "member_id", length = 4))
@Getter
@NoArgsConstructor
@Table(name = "tbl_members")
public class Member extends BaseEntity{

    @Column(name = "identity", unique = true)
    @NotNull
    private String identity;

    @Column(name = "password")
    @NotNull
    private String password;

    @Column(name = "name", length = 100)
    @NotNull
    private String name;

    @Enumerated(EnumType.STRING)
    @Column(name = "member_role")
    private Role role;

    @Builder
    public Member(String name,
                  String identity,
                  String password,
                  Role role) {
        this.name = name;
        this.identity = identity;
        this.password = password;
        this.role = role;
    }
}

 

package kr.co.jshpetclinicstudy.persistence.entity;

public enum Role {

    ROLE_ADMIN, ROLE_USER

}

 

---

 

해당 Spring Security에 대한 자세한 내용은 스터디원이 정리한 블로그 글을 참조하면 좋을 듯하다.
Spring Security의 다양한 필터기능을 통해서도 개발이 가능하지만, 우리는 추후 JWT를 적용해줄 것이기에 많은 이론적인 부분을 JWT자체에서 해결해주기도 한다. 

https://hongdosan.tistory.com/entry/Spring-Security-인증-개념-총정리-13

Spring Security - 인증 개념 총정리 (13)

https://hongdosan.tistory.com/entry/Spring-Security-인가-개념-총정리-14

Spring Security - 인가 개념 총정리 (14)

 

 

---