🌈 [Section4] 3. [ Spring Security ] Security 기본 2

📕 오늘 배운 내용!

• Spring Security의 웹 요청 처리 흐름
• 서블릿 필터 (Servlet Filter)
• Spring Security의 컴포넌트로 보는 인증 처리 흐름
• Spring Security의 권한 부여 흐름

---

✏️ Spring Security의 웹 요청 처리 흐름

(1) 사용자가 보호된 리소스 요청

(2) 인증 관리자 역할을 하는 컴포넌트가 사용자의 크리덴셜(Credential) 요청

✔️ 사용자의 크리덴셜(Credential)
➜ 해당 사용자를 증명하기 위한 구체적인 수단
Ex. password

(3) 사용자가 인증 관리자에게 크리덴셜 제공

(4) 인증 관리자가 크리덴셜 저장소에서 사용자의 크리덴셜 조회

(5) 인증 관리자가 사용자가 제공한 크리덴셜과 크리덴셜 저장소에 저장된 크리덴셜을 비교해 검증 작업 수행

(5-1) 유효한 크리덴셜이 아니라면 Exception throw

(5-2) 유효한 크리덴셜이라면

(6) 접근 결정 관리자 역할을 하는 컴포넌트가 사용자가 적절한 권한을 부여받았는지 검증

(6-1) 적절한 권한을 부여받지 못한 사용자라면 Exception throw

(6-2) 적절한 권한을 부여 받은 사용자라면 보호된 리소스의 접근 허용

---

✏️ 서블릿 필터 (Servlet Filter)

• 애플리케이션의 엔드포인트에 요청이 도달하기 전에 중간에서 요청을 가로챈 후 어떤 처리를 할 수 있도록 해주는 Java 제공 컴포넌트
  ( javax.servlet.Filter 인터페이스 )

• 이 인터페이스를 구현한 서블릿 필터는 웹 요청(request)을 가로채 전처리를 할 수 있고,
  엔드포인트에서 요청 처리가 끝난 후 도달되는 응답(response)을 클라이언트에게 전달하기 전에 후처리를 할 수 있음

• 서블릿 필터는 하나 이상의 필터들을 연결해 필터 체인 구성 가능

• 요청 URI path를 기반으로 HttpServletRequest 처리
  ➜ 클라이언트가 요청 전송하면, 서블릿 컨테이너는 요청 URI의 경로를 기반으로 어떤 Filter와 어떤 Servlet을 매핑할지 결정

✔ 서블릿 기반 애플리케이션에서 Servlet Filter 위치

➜ 클라이언트가 요청 전송하면 제일 먼저 Servlet Filter 거치고,
이후 Filter에서 처리가 모두 완료되면 DispatcherServlet에서 클라이언트의 요청을 핸들러에 매핑하기 위한 다음 작업 실행

[참고] https://docs.oracle.com/javaee/7/api/javax/servlet/Filter.html

✔️ 필터 체인 (Filter Chain)

• 여러개의 Filter가 체인을 형성하고 있는 Filter의 묶음
  ⠀
• 각각 필터들이 doFilter() 메서드 구현해야하고, doFilter() 메서드 호출을 통해 필터체인 형성
  ( 각 필터들은 순서에 따라 동작하도록 지정 가능 )
  ⠀
• Filter 인터페이스 구현하고 위 그림과 같이 구현한다면,
  서블릿 필터에서 작성한 특별한 작업들을 수행한 뒤,
  HttpServlet을 거쳐 DispatcherServlet에 요청이 전달되며,
  반대로 DispatcherServlet에서 전달한 응답에 대해 또한 특별한 작업을 수행할 수 있음

---

✔️ 필터 체인의 순서 지정

• Spring Bean으로 등록되는 Filter에 @Order 애너테이션 추가해서 순서 지정 가능
• Ordered 인터페이스 구현해서 순서 지정 가능
• FilterRegistrationBean 이용해 명시적으로 순서 지정 가능

✔ Servlet Filter 기본 구조

public class FirstFilter implements Filter {
     // 초기화 작업
     public void init(FilterConfig filterConfig) throws ServletException {
        ⠀
     }
     ⠀
     public void doFilter(ServletRequest request,
                          ServletResponse response,
                          FilterChain chain)
                          throws IOException, ServletException {
        // request(ServletRequest)를 이용해 다음 Filter로 넘어가기 전처리 작업 수행
⠀
        chain.doFilter(request, response);
⠀
        // response(ServletResponse)를 이용해 response에 대한 후처리 작업 수행
     }
     ⠀
     public void destroy() {
        // Filter가 사용한 자원을 반납하는 처리
     }
  }

• init() 메서드
  ➜ 생성한 Filter에 대한 초기화 작업 진행

• doFilter() 메서드
  ➜ 해당 Filter가 처리하는 실질적인 로직 구현

• destroy() 메서드
  ➜ Filter가 컨테이너에서 종료될 때 호출
  ➜ 주로 Filter가 사용한 자원을 반납하는 처리 등의 로직을 작성하고자 할 때 사용

✔ Spring Security의 Filter Chain

( ⬆️ 서블릿 필터에 Spring Security Filter가 추가된 모습 )

• Spring Security에서 보안을 위한 작업을 처리하는 필터의 모음

• Spring Security의 Filter Chain은 URL 별로 여러개 등록 가능

• DelegatingFilterProxy / FilterChainProxy 클래스는 Filter 인터페이스를 구현
  ➜ 서블릿 필터로써의 역할을 함
  ( 이름만 조금 다를뿐 )

✔️ DelegatingFilterProxy

• Bean으로 등록된 Spring Security의 필터 사용 시작점
  ( 서블릿 필터와 연결되는 Spring Security만의 필터를 ApplicationContext에 Bean으로 등록한 후, 이 Bean들을 이용해서 보안과 관련된 여러가지 작업들을 처리 )

• <서블릿 컨테이너 영역의 필터>와 <ApplicationContext에 Bean으로 등록된 필터들>을 연결해주는 브릿지 역할
  ( 보안 관련 X )

✔️ FilterChainProxy

• Spring Security의 Filter를 사용하기 위한 시작점
  ➜ FilterChainProxy부터 Spring Seucrity에서 제공하는 보안 필터들이 필요한 작업을 수행함

• Servlet Filter들은 Bean으로 등록이 안되지만, Security Filter들은 모두 Bean으로 등록이 됨

• Filter Chain이 있을 때 어떤 Filter Chain을 사용할지 결정
  ➜ 가장 먼저 매칭된 Filter Chain 실행

  Ex.

  • /api/** 패턴의 Filter Chain이 있고, /api/message URL 요청 전송하는 경우
    ⠀
    ➜ 디폴트 패턴인 /**도 일치하지만,
    /api/** 패턴과 제일 먼저 매칭되므로, 가장 먼저 매칭되는 /api/** 패턴과 일치하는 Filter Chain만 실행

  ---

  • /message/** 패턴의 Filter Chain이 없는데, /message/ URL 요청을 전송하는 경우
    ⠀
    ➜ 매칭되는 Filter Chain이 없으므로, 디폴트 패턴인 /** 패턴의 Filter Chain 실행

✔️ Spring Security에서 지원하는 Filter 종류

• 아주 많지만, 항상 모든 Filter가 수행되는 것이 아니라 프로젝트 구성 및 설정에 따라 일부의 Filter만 활성화 되어 있기 때문에 직접적으로 개발자가 핸들링할 필요가 없는 Filter들이 대부분
  ⠀
  ➜ 개발자가 Custom Filter를 작성하고 등록할 경우 기존 필터들 사이에서 우선 순위를 적용해 수행되어야할 필요가 있는 경우에 참고해서 적용하면 됨

[참고]
https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-security-filters

---

✏️ Spring Security의 컴포넌트로 보는 인증(Authentication) 처리 흐름

( Spring Security는 Filter로 시작해서 Filter로 끝난다 ! )

( ⬆️ 로그인에 대한 인증 처리 흐름 )

(1) 사용자가 로그인 폼 등으로 Spring Security가 적용된 애플리케이션에 request(Username/Password) 전송

• Filter Chain까지 들어오면 UsernamePasswordAuthenticationFilter가 해당 요청을 전달 받음

(2) 로그인 요청을 받은 UsernamePasswordAuthenticationFilter가 request의 정보(Username/Password)를 이용하여 UsernamePasswordAuthenticationToken 생성 후,
Authentication을 UsernamePasswordAuthenticationFilter에게 다시 전달

• UsernamePasswordAuthenticationToken
  ➜ Authentication 인터페이스를 구현한 구현 클래스

• 여기서 Authentication은 아직 인증이 되지 않음

(3) UsernamePasswordAuthenticationFilter가 해당 Authentication을 AuthenticationManager에게 전달

• AuthenticationManager
  ➜ 인증 처리를 총괄하는 매니저 역할을 하는 인터페이스

• ProviderManager
  ➜ AuthenticationManager를 구현한 구현 클래스
  ➜ ProviderManager implements AuthenticationManager

(4) ProviderManager가 AuthenticationProvider에게 Authentication 전달

(5) Authentication 전달받은 AuthenticationProvider가 UserDetailsService를 이용해 UserDetails 조회

✔️ UserDetails
데이터베이스 등의 저장소에 저장된 사용자의 Username + 사용자의 자격을 증명해주는 크리덴셜(Credential)인 Password + 사용자의 권한 정보를 포함하고 있는 컴포넌트

• 이 UserDetails를 제공하는 컴포넌트가 바로 UserDetailsService

(6) UserDetailsServic가 데이터베이스 등의 저장소에서 사용자의 크리덴셜(Credential)을 포함한 사용자의 정보 조회

(7) 조회한 사용자의 크리덴셜 + 정보 기반으로 UserDetails 생성

(8) 생성된 UserDetails를 다시 AuthenticationProvider에게 전달

(9) UserDetails를 전달 받은 AuthenticationProvider가 PasswordEncoder를 이용해 <UserDetails에 포함된 암호화 된 Password>와 <인증을 위한 Authentication 안에 포함된 Password>가 일치하는지 검증 후,

• 검증 성공 시 ➜ UserDetails를 이용해 인증된 Authentication 생성

• 검증 실패 시 ➜ Exception 발생시키고 인증 처리 중단

(10) AuthenticationProvider가 인증된 Authentication을 ProviderManager에게 전달

• 여기서 Authentication은 인증이 되어, 인증에 성공한 사용자의 정보(Principal/Credential/GrantedAuthorities) 가지고 있음

(11) ProviderManager가 인증된 Authentication을 다시 UsernamePasswordAuthenticationFilter에게 전달

• But, Credential은 유출되면 안되는 개인정보이기 때문에 내부적으로 삭제하고 전달함

(12) 인증된 Authentication을 전달 받은 UsernamePasswordAuthenticationFilter가 SecurityContextHolder를 이용해 SecurityContext에 인증된 Authentication 저장

• Principal / Credential / Collection< GrantedAuthority > 세개의 필드로 나뉘어 저장됨

• Credential 필드는 개인정보가 삭제되고 전달되기 때문에 null값임

• SecurityContext는 Spring Security의 세션 정책에 따라서 HttpSession 에 저장되어 사용자의 인증 상태를 유지하기도 하고, HttpSession을 생성하지 않고 무상태를 유지하기도 함

[참고]
https://docs.spring.io/spring-security/reference/servlet/authentication/architecture.html

✔ 인증 처리 흐름에서 사용된 Spring Security 인증 컴포넌트

✅ UsernamePasswordAuthenticationFilter

• 사용자의 로그인 request를 제일 먼저 만나는 컴포넌트

• 로그인 폼에서 제출되는 Username과 Password를 통한 인증을 처리하는 Filter

• 클라이언트로부터 전달 받은 Username/Password를 Spring Security가 인증 프로세스에서 이용할 수 있도록 UsernamePasswordAuthenticationToken 생성

내부를 살펴보면,

public class UsernamePasswordAuthenticationFilter extends AbstractAuthenticationProcessingFilter { // (1)
⠀
	public static final String SPRING_SECURITY_FORM_USERNAME_KEY = "username"; // (2)
⠀
	public static final String SPRING_SECURITY_FORM_PASSWORD_KEY = "password"; // (3)
⠀
	private static final AntPathRequestMatcher DEFAULT_ANT_PATH_REQUEST_MATCHER = new AntPathRequestMatcher("/login","POST"); // (4)
⠀
  ...
  ...
⠀
	public UsernamePasswordAuthenticationFilter(AuthenticationManager authenticationManager) {
		super(DEFAULT_ANT_PATH_REQUEST_MATCHER, authenticationManager); // (5)
	}
⠀
  // (6)
	@Override
	public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response)
			throws AuthenticationException {
    // (6-1)
		if (this.postOnly && !request.getMethod().equals("POST")) {
			throw new AuthenticationServiceException("Authentication method not supported: " + request.getMethod());
		}
⠀⠀
		String username = obtainUsername(request);
    ...
⠀
		String password = obtainPassword(request);
    ...
	⠀	
    // (6-2)
    UsernamePasswordAuthenticationToken authRequest = UsernamePasswordAuthenticationToken.unauthenticated(username, password);
		...
⠀⠀
		return this.getAuthenticationManager().authenticate(authRequest); // (6-3)
	}
⠀
	...
  ...
}

⠀
➜ (1)과 같이 AbstractAuthenticationProcessingFilter 상속
UsernamePasswordAuthenticationFilter 클래스의 이름이 Filter로 끝나지만 doFilter() 메서드 존재 X
But, doFilter() 메서드는 꼭 있어야 함
-> 상위 클래스인 AbstractAuthenticationProcessingFilter 클래스가 doFilter() 메서드를 포함하고 있음
-> 결과적으로 로그인 request를 제일 먼저 전달 받는 클래스는 UsernamePasswordAuthenticationFilter의 상위 클래스인 AbstractAuthenticationProcessingFilter 클래스인 것
⠀
➜ (2)와 (3)을 통해 클라이언트의 로그인 폼을 통해 전송되는 request parameter의 디폴트 name은 username과 password라는 것을 알 수 있
⠀
➜ (4)의 AntPathRequestMatcher는 클라이언트의 URL에 매치되는 매처
-> (4)를 통해 클라이언트의 URL이 "/login"이고, HTTP Method가 POST일 경우 매치 될거라는 사실 예측 가능

---

✏️ Spring Security의 권한 부여 처리 흐름

( 사용자 인증 후, 애플리케이션 리소스에 접근 권한을 부여하는 흐름 )

(1) AuthorizationFilter가 SecurityContextHolder로 부터 Authentication 획득

• AuthorizationManager
  • 권한 부여 처리를 총괄하는 매니저 역할을 하는 인터페이스

(2) SecurityContextHolder로 부터 획득한 Authentication + HttpServletRequest를 AuthorizationManager에게 전달

• RequestMatcherDelegatingAuthorizationManager

  • AuthorizationManager를 구현하는 구현체 중 하나

  • RequestMatcher 평가식을 기반으로 해당 평가식에 매치되는 AuthorizationManager에게 권한 부여 처리를 위임하는 역할
    ( 직접 권한 부여 처리 X )

(3) RequestMatcherDelegatingAuthorizationManager 내부에 매치되는 AuthorizationManager 구현 클래스가 있다면,
해당 AuthorizationManager 구현 클래스가 사용자의 권한을 체크

(4) 적절한 권한이라면 ➜ 다음 요청 프로세스를 계속 이어감
( Filter 다 끝나면 DispatcherServlet으로 넘어감 )

(5) 절한 권한이 아니라면 ➜ AccessDeniedException이 throw되고, ExceptionTranslationFilter가 AccessDeniedException 처리

✔ 권한 부여 흐름에서 사용된 Spring Security 권한 부여 컴포넌트

✅ AuthorizationFilter

• URL을 통해 사용자의 액세스를 제한하는 권한 부여 Filter

• Spring Security 5.5 버전부터 FilterSecurityInterceptor를 대체

내부를 살펴보면,

public class AuthorizationFilter extends OncePerRequestFilter {
⠀
	private final AuthorizationManager<HttpServletRequest> authorizationManager;
  ⠀
⠀  ...
  ...
⠀	
  // (1)
	public AuthorizationFilter(AuthorizationManager<HttpServletRequest> authorizationManager) {
		Assert.notNull(authorizationManager, "authorizationManager cannot be null");
		this.authorizationManager = authorizationManager;
	}
⠀
	@Override
	protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
			throws ServletException, IOException {
⠀
		AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request); // (2)
⠀		this.eventPublisher.publishAuthorizationEvent(this::getAuthentication, request, decision);
		if (decision != null && !decision.isGranted()) {
			throw new AccessDeniedException("Access Denied");
		}
		filterChain.doFilter(request, response);
	}
  ...
}

⠀
➜ (1)과 같이 AuthorizationFilter 객체가 생성될 때, AuthorizationManager를 DI
⠀
➜ DI 받은 AuthorizationManager를 통해 권한 부여 처리 진행
⠀
➜ (2)와 같이 DI 받은 AuthorizationManager의 check() 메서드를 호출해 적절한 권한 부여 여부를 체크
( check() 메서드는 AuthorizationManager 구현 클래스에 따라 권한 체크 로직이 다름 )

URL 기반으로 권한 부여 처리를 하는 AuthorizationFilter는 AuthorizationManager의 구현 클래스로 RequestMatcherDelegatingAuthorizationManager를 사용

✅ AuthorizationManager

• 권한 부여 처리를 총괄하는 매니저 역할을 하는 인터페이스

내부를 살펴보면,

@FunctionalInterface
public interface AuthorizationManager<T> {
  ...
⠀
	@Nullable
	AuthorizationDecision check(Supplier<Authentication> authentication, T object);
⠀
}

⠀
➜ check() 메서드 하나만 정의되어 있음
⠀
➜ Supplier와 제너릭 타입의 객체를 파라미터로 가짐

✅ RequestMatcherDelegatingAuthorizationManager

• AuthorizationManager의 구현 클래스 중 하나

• 직접 권한 부여 처리를 수행 하지 않고 RequestMatcher를 통해 매치되는 AuthorizationManager 구현 클래스에게 권한 부여 처리를 위임

내부를 살펴보면,

public final class RequestMatcherDelegatingAuthorizationManager implements AuthorizationManager<HttpServletRequest> {
⠀
  ...
  ...
⠀
	@Override
	public AuthorizationDecision check(Supplier<Authentication> authentication, HttpServletRequest request) {
		if (this.logger.isTraceEnabled()) {
			this.logger.trace(LogMessage.format("Authorizing %s", request));
		}
⠀
    // (1)
		for (RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> mapping : this.mappings) {
⠀
			RequestMatcher matcher = mapping.getRequestMatcher(); // (2)
			MatchResult matchResult = matcher.matcher(request);
			if (matchResult.isMatch()) {   // (3)
				AuthorizationManager<RequestAuthorizationContext> manager = mapping.getEntry();
				if (this.logger.isTraceEnabled()) {
					this.logger.trace(LogMessage.format("Checking authorization on %s using %s", request, manager));
				}
				return manager.check(authentication,
						new RequestAuthorizationContext(request, matchResult.getVariables()));
			}
		}
		this.logger.trace("Abstaining since did not find matching RequestMatcher");
		return null;
	}
}

⠀
➜ (1)에서 check() 메서드의 내부에서 루프를 돌면서 RequestMatcherEntry 정보를 얻고

➜ (2)에서 RequestMatcher 객체를 얻음
( 여기서의 RequestMatcher는 SecurityConfiguration에서 .antMatchers("/orders/**").hasRole("ADMIN")와 같은 메서드 체인 정보를 기반으로 생성됨 )
⠀
➜ (3)에서 MatchResult.isMatch()가 true이면 AuthorizationManager 객체를 얻은 뒤, 사용자의 권한 체크

---

🌈 느낀점

그래도 흐름까지는 외우면 괜찮다 !!
코드에서 보고 흐름을 느낄 수 있도록 공부해야지