스프링 시큐리티 복습 2 - 주요 아키텍처 이해

 

 

 

 

 

 

 

1.  DelegatingFilterProxy ( Servlet Container )

1. 서블릿 필터는 스프링에서 정의된 빈을 주입해서 사용할 수 없음,
2. 특정한 이름을 가진 스프링 빈을 찾아 그 빈에게 요청을 위임

       springSecurityFilterChain 이름으로 생성된 빈을 ApplicationContext 에서 찾아 요청을 위임

      실제 보안처리를 하지 않음

 

 

 

 

 

 

2.  FilterChainProxy ( Spring Container )

1. springSecurityFilterChain의 이름으로 생성되는 필터 빈
2. DelegatingFilterProxy으로 부터 요청을 위임 받고 실제 보안 처리
3. 스프링 시큐리티 초기화 시 생성되는 필터들을 관리하고 제어
4. 사용자의 요청을 필터 순서대로 호출하여 전달
5. 사용자 정의 필터를 생성해서 기존의 필터 전후로 추가 가능
6. 마지막 필터까지 인증 및 인가 예외가 발생하지 않으면 보안 통과

 

 

 

           request                                                 위임

user        →         DelegatingFilterProxy        →         FilterChainProxy        →          Spring MVC

 

 

 

 

 

 

 

 

3.  필터 초기화와 다중 보안 설정 ( SecurityConfig 1,  SecurityConfig 2 )

 

• 설정 클래스 별로 보안 기능이 각각 작동
• 설정 클래스 별로 RequestMatcher 설정     http.antMatcher("/admin/**")
• 설정 클래스 별로 필터 생성
• FilterChainProxy가 각 필터들 가지고 있음
• 요청에 따라 RequestMatcher와 매칭되는 필터가 작동하도록 함

 

 

 

 

 

 

 

4.  Authentication (인증)

: 당신이 누구인지 증명하는 것

• 사용자의 인증 정보를 저장하는 토큰 개념
• 인증 시 id와 password를 담고 인증 검증을 위해 전달되어 사용된다.
• 인증 후 최종 인증 결과 (user 객체, 권한 정보)를 담고 SecurityContext에 저장되어 전역적으로 참조가 가능하다.

Authentication authentication = SecurityContextHolder.getContext().getAuthentication()

 

구조

1. principal : 사용자 아이디 혹은 User 객체를 저장
2. credentials : 사용자 비밀번호
3. authorities : 인증된 사용자의 권한 목록
4. details: 인증 부가 정보
5. Authenticated : 인증 여부

 

 

 

 

 

 

5.  SecurityContextHolder,  SecurityContext

• SecurityContext

Authentication 객체가 저장되는 보관소로 필요 시 언제든지 Authentication 객체를 꺼내어 쓸 수 있도록 제공되는 클래스임
ThreadLocal에 저장되어 아무 곳에서나 참조가 가능하도록 설계함
인증이 완료되면 HttpSession 에 저장되어 어플리케이션 전반에 걸쳐 전역적인 참조가 가능함

 

 

• SecurityContextHolder

SecurityContext 객체 저장 방식
1. MODE_THREADLOCAL : 스레드 당 SecurityContext 객체를 할당, 기본 값
2. MODE_INHERITABLETHREADLOCAL : 메인 스레드와 자식 스레드에 관하여 동일한 SecurityContext를 유지
3. MODE_GLOBAL : 응용 프로그램에서 단 하나의 SecurityContext를 저장함

SecurityContextHolder.clearContext() : SecurityContext 기존 정보 초기화

Authentication authentication = SecurityContextHolder.getContext().getAuthentication()

 

 

 

 

 

 

 

6.  SecurityContextPersistenceFilter

(세션에 존재하는 SecurityContext를 반환하고, 세션에 없을 경우 새로운 SecurityContext 반환하는 필터)

: SecurityContext 객체의 생성, 저장, 조회

• 익명 사용자

새로운 SecurityContext 객체를 생성하여 SecurityContextHolder 에 저장

AnonymousAuthenticationFilter 에서 AnonymousAuthenticationToken 객체를 SecurityContext 에 저장

• 인증시

새로운 SecurityContext 객체를 생성하여 SecurityContextHolder 에 저장

UsernamePasswordAuthenticationFilter 에서 인증 성공 후 SecurityContext 에 UsernamePasswordAuthenticationToken 객체를 SecurityContext 에 저장

인증이 최종 완료되면 Session 에 SecurityContext를 저장

• 인증 후

Session에서 SecurityContext 꺼내어 SecurityContextHolder 에서 저장

SecurityContext 안에 Authentication 객체가 존재하면 계속 인증을 유지한다.

• 최종 응답 시 공통

SecurityContextHolder.clearContext()

 

 

 

 

 

  

 

 

7.  AuthenticationManager

: AuthenticationProvider 목록 중에서 인증 처리 요건 ( Form 인증 / RememberMe 인증 /  Oauth 인증 )에 맞는 AuthenticationProvider 를 찾아 인증 처리를 위임한다.

부모 ProviderManager를 설정하여 AuthenticationProvider를 계속 탐색할 수 있다.

 

AuthenticationManager   →   ProviderManager   →    AuthenticationProvider

 

 

 

 

 

 

8.  AuthenticationProvider 

 

                                                     authenticate (authentication)  →  ID 검증, password 검증, 추가 검증
                                             ↗ 
AuthenticationProvider      
                                              ↘
                                                     support (authentication)

ID 검증 실패 시,  UserNotFoundException

password 검증 실패 시,  BadCredentialException

 

 

 

 

 

 

 

9.  Authorization ( 인가 )

: 당신에게 무엇이 허가 되었는지 증명하는 것

 

 

스프링 시큐리티가 지원하는 권한 계층

• 웹 계층 : URL 요청에 따른 메뉴 혹은 화면 단위의 레벨 보안
• 서비스 계층 :  화면 단위가 아닌 메소드 같은 기능 단위의 레벨 보안
• 도메인 계층 :  객체 단위의 레벨 보안

 

 

 

 

10.  FilterSecurityInterceptor

: 마지막에 위치한 필터로써 인증된 사용자에 대하여 특정 요청의 승인/ 거부 여부를 최종적으로 결정

인증 객체 없이 보호 자원에 접근을 시도할 경우 AuthenticationException을 발생
인증 후 자원에 접근 가능한 권한이 존재하지 않을 경우 AccessDeniedExeption을 발생
권한 제어 방식 중 HTTP 자원의 보안을 처리하는 필터
권한 처리를 AccessDecisionManager에 맡김

 

 

 

 

 

11.  AccessDecisionManager,   AccessDecisionVoter

 

AccessDecisionManager

: 인증 정보, 요청 정보, 권한 정보를 이용해서 사용자의 자원 접근을 허용할 것인지 거부할 것인지를 최종 결정하는 주체

여러개의 Voter 들을 가질 수 있으며, Voter 들로부터 접근 허용, 거부, 보류에 해당하는 각각의 값을 리턴받고 판단 및 결정
최종 접근 거부 시 예외 발생

 

 

접근 결정의 세가지 유형

1. AffirmativeBased : 여러개의 Voter 클래스 중 하나라도 접근 허가 결론을 내면 접근 허가로 판단된다.

2. ConsenseusBased : 다수표에 의해 최종 결정을 판단한다. 

3. UnanimousBased : 모든 보터가 만장일치로 접근을 승인해야 하며 그렇지 않은 경우 접근을 거부한다.

 

 

 

 

AccessDecisionVoter

판단을 심사하는 것

Voter가 권한 부여 과정에서 판단하는 자료
1. Authentication -  인증 정보 (user)
2. FilterInvocation -  요청 정보 (antMatcher("/user"))
3. ConfigAttributers -  권한 정보 (hasRole("USER"))

 

결정 방식

• ACCESS_GRANTED : 접근 허용 (1)
• ACCESS_DENIED : 접근 거부 (-1)
• ACCESS_ABSTAIN : 접근 보류( Voter 가 해당 타입의 요청에 대해 결정을 내릴 수 없는 경우 ) (0)