Spring Security 이론, 그리고 느낌

스프링에서 피할 수 없는 난제, 스프링 시큐리티이다.

대부분 이 과정에서 큰 좌절을 하고, 나도 Reactive Spring Security에서 좌절을 먹고 Spring boot에서 힘을 얻는 중이다. 

 

가장 중요한건 이론적인 글이 아니라 생각한다. 이론이야 누구나 칠판에 꽉꽉 채워서 필기는 가능하지만

그걸 설명하는게 진짜 어려움이니까... 

 

스프링 시큐리티의 장점

1. 보안에 대해서 체계적인 옵션과 기본적인 제공(암호화)을 한다.

2. Annotation(@쓰는거)로 설정이불편간단하다

3. 세션과 쿠키방식으로 인증한다.JWT쓸꺼다

4. 필터 기반이며 MVC와 별도로 분리되어서 관리를 할수 있다. 

 

이것보다 더 잘 그린 건 없는거같다.

스프링 시큐리티를 사용하게 되면 위의 구조도로 데이터가 이동한다. 

 

 

 

각 필터별 기능 설명

SecurityContextPersistenceFilter	SecurityContextRepository에서 SecurityContext를 로드하고 저장하는 일을 담당함
LogoutFilter	로그아웃 URL로 지정된 가상URL에 대한 요청을 감시하고 매칭되는 요청이 있으면 사용자를 로그아웃시킴
UsernamePasswordAuthenticationFilter	사용자명과 비밀번호로 이뤄진 폼기반 인증에 사용하는 가상 URL요청을 감시하고 요청이 있으면 사용자의 인증을 진행함
DefaultLoginPageGeneratingFilter	폼기반 또는 OpenID 기반 인증에 사용하는 가상URL에 대한 요청을 감시하고 로그인 폼 기능을 수행하는데 필요한 HTML을 생성함
BasicAuthenticationFilter	HTTP 기본 인증 헤더를 감시하고 이를 처리함
RequestCacheAwareFilter	로그인 성공 이후 인증 요청에 의해 가로채어진 사용자의 원래 요청을 재구성하는데 사용됨 SecurityContextHolderAwareRequestFilter HttpServletRequest를 HttpServletRequestWrapper를 상속하는 하위 클래스(SecurityContextHolderAwareRequestWrapper)로 감싸서 필터 체인상 하단에 위치한 요청 프로세서에 추가 컨텍스트를 제공함
AnonymousAuthenticationFilter	이 필터가 호출되는 시점까지 사용자가 아직 인증을 받지 못했다면 요청 관련 인증 토큰에서 사용자가 익명 사용자로 나타나게 됨
SessionManagementFilter	인증된 주체를 바탕으로 세션 트래킹을 처리해 단일 주체와 관련한 모든 세션들이 트래킹되도록 도움
ExceptionTranslationFilter	이 필터는 보호된 요청을 처리하는 동안 발생할 수 있는 기대한 예외의 기본 라우팅과 위임을 처리함
FilterSecurityInterceptor	이 필터는 권한부여와 관련한 결정을 AccessDecisionManager에게 위임해 권한부여 결정 및 접근 제어 결정을 쉽게 만들어 줌

출처: https://devuna.tistory.com/55 [튜나 개발일기]

 

...라고하지만 이걸 읽으면 전부 파악되기 보다는 키보드를 창문 밖으로 던져버릴 것이다.

당연하다. 한방에 이해가 되면 그게 스프링 시큐리티인가?

 

차근차근  실제 개발할때의 느낌을 설명해보면

 

1번 : httpRequest가 들어온다. 사용자가 뉘신지도, 뭐하러 왔는지도 모르지만 일단 온 요청이다. 이 요청에 대해서 어떻게 처리할지 고민을 하면 된다.

 

2번: 폼 기반 로그인 인증이라면 이걸 쓰는데... 난 쓰지 않았다. formLogin를 쓴다면 이라는 조건이다.

3번: 인증관리자로 넘어온다. 

4번: 실제 인증을 시도한다. 이걸 상속 안받고 그냥 쓰면 내부적인 인증시스템을 쓰는거 같다. 직접 상속을 받으면 구현을 직접할 수 있다.equals가 아니라 matches로 해야한다고

5번: DB든 어디서든 접속해서 가져오는 기능을 담당하는 모듈.

7부터 9까지는 다시 되돌아 오는 과정이고...

 

10번: 허가됨을 보낸다.

어떤 허가 과정인지는 눈에 안보이니 이걸 느낄수는 없다. 이론을 보면...

 

관련된 AuthenticationFilter가 획득한 Authentication 객체를 향후 필터 사용을 위하여 SecurityContext에 저장한다. (Authorization Filters를 위해 사용)

...이렇다고 한다. 솔직히봐도모르겠다스프링의 장점은 많은 부분이 추상화 되어고 캡슐화 되어 있어서 사용자가 건드릴 부분이 적다...이지만 반대로 사용자가 이론까지 알기가 힘들다.애초에그렬러고캡슐화은닉화스프링시큐리티만든거아닌가?

 

 

 

대략적으로 파악한 정도는 이렇다. 

대부분의 과정은 자동으로 처리가 가능하지만 implements로 상속을 받아서 처리가 가능하다.

상속을 받게되면 직접 처리를 해야 하지만 더 자세하고 자신만의 방식으로 처리를 할수 있다.

본인도 개발때 AuthenticationProvidor를 상속받아서 직접 구현을 한 적이 있다.