SpringBootProject

Project Part1 - 로그인 구현하기. (5. Spring Security)

dding-shark 2024. 11. 28. 12:25
728x90

스프링 시큐리티(Spring Security)

1. 스프링 시큐리티 :

  • Spring 에서 만든 애플리케이션의 보안을 담당하는 하위 프레임워크(인증 : Authentication, 권한인가 : Authorization 등)

    • 인증 : 사용자가 누구인지를 확인하는 과정 <- Cookie 와 Session 에서 원했던 그 기능

    • 권한 인가 : 인증된 사용자가 해단 자원에 접근할 수 있는지 판단 하는 단계. (권한 인가라고 해야하지만, 편의를 위해 권한 Permission 의 개념이라 생각해도 나쁘지 않음)

  • Spring Security 를 사용하는 이우 :

    • 조금 여러 가지 이유가 있을 수도 있는데, 오랜 세월동안 살아남은 시큐리티 프레임워크이다.
    • 초기 설정을 잘 해주면, 많은 로직을 작성 하지 않아도 보안 관련 서비스를 처리 해주는 편리함이 있다.

2. 스프링 시큐리티의 특징과 구조 :

  • 보안과 관련하여 체계적으로 많은 옵션을 제공하여 편리하게 사용할 수 있음
  • Filter 기반으로 동작.
  • 어노테이션을 통한 설정
  • Spring Security는 기본적으로 세션 & 쿠키 방식으로 인증

  • 인증관리자(Authentication Manager)와 접근 결정 관리자(Access Decision Manager)를 통해 사용자의 리소스 접근을 관리

    => 상당히 스프링 기본원칙을 잘 만족하고 있다.

  • 인증 관리자는 UserNamePasswordAuthenticationFilter, 접근 관리자는 FilterSecurityInterceptor가 수행

3. Spring Security 의 동작 원리.

스프링 시큐리티 동작원리

  1. User가 From을 통해 로그인 정보를 입력하고 인증 요청을 한다.

  1. AuthenticationFilter 가 HttpServletRequest 에서 사용자가 보낸 로그인 정보를 인터셉트 한다.(백단에서도 한번더 유효성 검사를 한다.)

    • HttpServletRequest에서 꺼내온 사용자 아이디와 패스워드를 진짜 인증을 담당할 AuthenticationManager 인터 페이스에게 인증용 객체로 만들어서 위임한다.
  1. AuthenticationFilter 에게 인증용객체(UsernamePasswordAuthenticationTocken)을 전달 받는다.
  1. 실제 인증을할 AuthenticationProvider에게 Authentication 객체를 다시 전달한다.

  1. DB에서 사용자 인증 정보를 가져올 UserDetailService 객체에게 사용자 아이디를 넘겨주고 DB에서 인증에 사용될 사용자정보를 UserDeatils라는 객체로 전달 받는다.

    • UserDetails : tip. 인증용 객체와 도메인 객체를 분리하지 않기 위해서 도메인에 UserDetail 을 상속 하기도 한다.(이렇게 짜여진 코드를 좀 더 많이 본거 같다.)
  1. AuthenticationProvider 는 UserDetails 객체를 전달 받은 이후 실제 사용자의 입력정보와 UserDetails 객체를 가지고 인증을 시도한다.
  1. 인증이 완료되면 사용자 정보를 가진 Authentication 객체를 SecurityContextHolder에 담은 이후 AuthenticationSuccessHandele을 실행한다. (실패시 FailureHandler 실행.)

장황하게 설명을 해놨지만... 순서대로 잘 따라가다보면 생각보다 별거 없다.

4. 스프링 시큐리티 아키택쳐

스프링 시큐리티 아키택쳐

  • 클라이언트부터 쭉 진행해보자

  1. 필터(Filter) :

    • 스프링 시큐리티는 기본적으로 서블릿의 필터를 기반으로 작동한다.
    • 일반적으로 서블릿이 하나의 HttpServeletRequest를 받아 요청을 처리하고 응답을 클라이언트로 보내지만, Filter 가 포함되게 되면, 요청이 클라이언트에 보내기전에 컨테이너는 하나의 필터체인(FilterChain)을 생성한다.
    • FilterChain안에는 필터와 서블릿이 존재한다.
    • => 말 그대로 '필터'의 역할이라 보면된다. 인터셉터와 구분해서 알아둘 필요는 있다.

  1. DelegationFilterProxy :

    • 사용자의 요청이 서블릿에 전달되어 자원에 접근하기전에, 스프링 시큐리티는 필터의 생명주기를 이용해서 인증과 권한 작업을 수행한다.
    • 하지만, 서블릿컨테이너 에서는 스프링 컨테이너에 등록된 빈을 인식할 수 없다.
    • 따라서 DelegationFilterProxy라는 서블릿 필터의 구현체를 제공한다.
    • DelegationFilterProxy는 서블릿 매커니즘을 통해 서블릿 필터로 등록 될수 있으며, 스프링에 등록된 빈을 가져와 의존성을 주입할 수 있ㄷ.
    • 정리하면, 서블릿 컨테이너의 생명주기와 스프링의 ApplicationContext사이를 연결하는 다리역할을 한다.

  1. FilterChainProxy :

    • DelegationFilterProxy 를 통해 받은 요청과 응답을 스프링키슈리티의 필터체인에 전달하고 작업을 위임하는 역할을 한다.
    • 중간에 체인 프록시를 두는 이유는, 서블릿을 지원하는 시작점의 역할을 하기 위해서다. 서블릿에 문제가 발생 -> 체인프록시의 문제 이렇게.

  2. SecurityFilterChain :

    • 인증을 처리하는 여러개의 시큐리티 필터를 담은 체인이다.
    • 따라서 여러개의 필터체인을 구성하여 매칭되는 URL에 따라 다른 필터체인이 사용되게 할 수 있다.

  3. Security Filters :

    • 스프링 시큐리티 매커니즘에 따라 처리하는 필터이다. -> 실제 기능을 수행하는 지점이다.

    • 필터 체인 api 를 통해 필터체인프록시에 삽입되고 스프링 빈으로 등록된다.

    • 기능들을 정리하고 싶지만,, 너무 많기에.. 찾아보면서 구현하길...


      필터 사진 자료

728x90