스프링 시큐리티 요청에대한 권한 - 아키텍처 간단

이 글은 2.2 시큐리티 버전 WebSecurityConfigurerAdapter 버전이다

 

스프링 시큐리티는 기본적으로 13개의 필터가 존재한다 

 

그중 13번째 마지막에 위치한 필터가 바로 FilterSecurityInterceptor  이다.

 

세숫대야부터 확인하자

 

클래스는 필드와 메서드로 구성되어있는데,

 

해당 필드에 한번 집중해보자

FilterInvocationSecurityMetadataSource 타입은 인터페이스이며, 

특정 엔드포인트 URL에 대한 권한정보를 담당하는데

 

대표적인 시큐리티가 제공하는 구현체는 DefaultFilterInvocationSecurityMetadataSource 이다 (클래스)

 

 

여기서 잠깐 security 설정에

.antMatchers("/system").hasAnyRole("ADMIN", "ROOT")

 

를 적었다 쳐보자

 

 

그리고 이어 설명하자면, 여기서도 눈여결 볼 필드는 requestMap 이다

Map 타입으로 정의되어 있는데

요청 정보를 갖는 RequestMatcher

해당 요청 정보에 필요한 권한 리스트를 갖는 Collection<ConfigAttribute>

 

requestMap은 서버가 실행될때 security 설정 기반하여 채워진다

(이또한 DB로부터 가져올 수 있게 커스텀한다면 특정 자원에 대한 동적 권한 설정이 가능해진다)

 

 

쉽게말하면 

key       : /system (String은 아니지만)

value    : ROLE_ADMIN, ROLE_ROOT ... 

 

이런식 컨셉이다

 

 

참고로 Key에 해당하는 RequestMatcher 내부 코드를 보면 

 

match 라는 메서드가 있는데 이를통해 

 

사용자가 /admin 호출 하였을때

 

아까 언급한 requestMap 의 키와 매칭해서 매칭되었을때

requestMap의 value를 꺼내면 그안에 ROLE_ADMIN, ROLE_ROOT ... 등 과같은 권한 리스트가 나오는것이다

매칭되는게 없다면 권한이 필요없는 요청이였던것이다 ( login 페이지와같이 )

 

이에 대한 코드는 표시했다

 

 

 

결국 커스텀 필터를 만들고

FilterInvocationSecurityMetadataSource  를 DB로부터 불러온다면 

정적인 config 설정에서 동적로 설정할 수 있다.

 

그외에 지금은 다루진 않았지만,

AccessDecisionManager, AccessDecisionVoter의 구현체들로

심사를 이루는데 이에대한 내용도 중요하다.