Spring Security 권한 검증

원본 링크:
https://blog.gaoyuexiang.cn/2020/06/13/spring-security-authorization/ ，
내용 에 차이 가 없다.
앞의 글 에서 우 리 는 Spring Security 가 권한 검증 을 하 는 구성 요소 에 대해 대체적으로 알 고 있 습 니 다. 우 리 는 먼저 세부 사항 을 되 돌아 보고 탐구 합 니 다.
FilterSecurityInterceptor
이것 은 AbstractSecurityInterceptor 의 하위 클래스 이 며 Filter 인 터 페 이 스 를 실현 하여 부모 클래스 beforeInvocation(), afterInvocatio() 와 finallyInvocation() 방법 및 일부 Servlet 관련 업 무 를 수행 합 니 다.권한 검증 을 진정 으로 처리 하 는 코드 는 부모 클래스 에 있 습 니 다.그것 이 존재 하 는 의 미 는 Filter 에서 권한 검증 을 할 수 있 도록 하 는 것 이다.
이 Filter 기본 값 은 항상 SecurityFilterChain 의 마지막 에 배정 된다. 모든 신분 인증 과 관련 된 Filter 이후 에 보장 해 야 하기 때문이다.
AbstractSecurityInterceptor
이 종 류 는 진정한 권한 검증 의 논 리 를 실현 했다. 이 종 류 는 여러 개의 하위 클래스 가 있 는데 서로 다른 기술 에 적합 하기 위해 존재 한다. 예 를 들 어 위의 FilterSecurityInterceptor 은 Servlet Filter 에 적합 하기 위해 존재 한다.
우 리 는 위 에서 언급 한 세 가지 방법 을 주목 할 수 있다. 이것 은 모든 하위 클래스 가 호출 할 것 이다.
하위 클래스 의 실현 은 항상 아래 의 방법 입 니 다.

InterceptorStatusToken token = super.beforeInvocation(secureObject); // 1
try {
  // call target method, eg, filterChain.doFilter()
  // may get a returnedObject
} final {
  super.finallyInvocation(token);
}
super.afterInvocation(token, returnedObject);

secureObject 는 하나의 방법 으로 호출 되 는데 그 유형 은 Object 이지 만 보통 MethodInvocation 또는 FilterInvocation 이런 유형 을 볼 수 있다.

beforeInfocation 방법
이 방법의 목 표 는 호출 AccessDecisionManager.decide() 방법 으로 pre - invocation handling 작업 을 완성 하 는 것 이다.
앞의 개관 에서 소 개 했 듯 이 AccessDecisionManager.decide() 방법 은 세 개의 매개 변수 가 있다.그 중 secureObject 는 이미 하위 클래스 로 들 어 왔 습 니 다.그러면 실제 호출 전에 Authentication 대상 과 Collection 집합 을 가 져 와 pre - invocation handling 작업 을 합 니 다.
나중에 소개 해 드릴 게 요.ConfigAttribute
호출 시 AccessDecisionException 가 나타 나 면 그 는 ExceptionTranslationFilter 처 리 될 것 이다.
권한 검증 을 통과 하면 반환 값 으로 대상 InterceptorStatusToken 을 준비 합 니 다.
token 을 만 들 기 전에 RunAsManager 을 사용 하여 Authentication 대상 을 만 들 려 고 시도 합 니 다. 이 대상 이 null 가 아니라면 SecurityContext 에 있 는 것 을 하나 SecurityContextHolder 넣 고 교체 합 니 다.
원래 있 던 SecurityContext 은 항상 token 에 들 어 갑 니 다.
... 에 대하 여RunAsManager: 여기 논 리 는 바 꾸 는 거 예요.SecurityContextHolder 의 값 을 목표 방법 에서 볼 수 있 습 니 다.Authentication 대상 이 이거 예요.RunAsManager 생 성 된 대상 입 니 다.목표 방법 호출 완료 후, 즉
finally Invocation 방법 에서 원래 의SecurityContext 다시 넣 기SecurityContextHolder 중.
이러한 목적 은 인증 과 감 권 절차 중의 Authentication 대상 과 업무 방법 중의 구분 을 위 한 것 이다.
위의 이러한 절차 에서 일부 ApplicationEvent 를 보 낼 수 있 는데 PublicInvocationEvent, AuthorizationFailureEvent 와 AuthorizedEvent 를 포함한다.PublicInvocationEvent 오직Collection 비어 있 을 때 만 발생 하고 이 럴 때 는 호출 되 지 않 습 니 다.AccessDecisionManager 。
after Infocation 방법afterInvocation 방법의 주요 목적 은 returnedObject 에 따라 권한 검증 을 하기 위 한 것 이다. 이것 은 AfterInvocationManager 이 인터페이스 에 사용 되 었 다. 이것 은 개관 에서 언급 되 지 않 은 것 으로 after invocation handling 을 하 는 데 사용 된다.
이 방법 에서 필요 하 다 면 AfterInvocationManager.decide() 방법 으로 처리 returnedObject 하여 새로운 결 과 를 얻 었 다 returntedObject.
여기 서 필요 한 것 은:

token != null

afterInvocationManager 필드 가 비어 있 지 않 음

finally Infocation 방법
이 방법 은 수신 InterceptorStatusToken 을 매개 변수 로 한 가지 만 합 니 다. token 의 SecurityContext 대상 을 다시 SecurityContextHolder 에 넣 습 니 다.
이 조작 은 두 가지 판단 조건 이 있다.

token 은 null

이 아 닙 니 다.

token 의 contextHolderRefreshRequired 는 true 이다.SecurityContextHolder 의 값 이 beforeInvocation 에서 바 뀌 었 을 때 이 값 은 true

이다.
권한 검증 의 입구 FilterSecurityInterceptor 에 대한 소 개 는 여기까지 입 니 다. 다음은 pre - invocation handling 과 afterinvocation handling 의 내용, 즉 AccessDecisionManager 과 AfterInvocationManager 을 살 펴 보 겠 습 니 다.
AccessDecisionManager
개관 에서 소 개 했 던 내용 인 데 여기 서 빠르게 되 짚 어 볼 수 있다.AccessDecisionManager 은 pre - invocation handling 의 입구 입 니 다.그것 의 세 가지 구체 적 인 실현 은 여러 개 AccessDecisionVoter 의 실현 을 호출 한 다음 에 구체 적 으로 실현 되 는 전략 으로 voter 의 결과 에 따라 인증 여 부 를 판단 하 는 방법 을 결정 한다.모든 voter 는 현재 Authentication 대상, secureObject, Collection 에 따라 접근 허용 여 부 를 선택 합 니 다.AccessDecisionManager 의 세 가지 실현 은 바로 voter 결과 에 따라 최종 결 과 를 결정 하 는 세 가지 전략 으로 각각 AffirmativeBased, ConsensusBased 과 UnanimousBased 이다.책략 은 말 그대로 설명 하지 않 는 다.
AfterInvocationManager
이전에 after invocation handling 을 말 하지 않 은 부분 은 중요 하지 않다 고 생각 하고 장면 을 많이 사용 하지 않 았 습 니 다 (사실은 자신 이 만 나 지 못 했 습 니 다).지금 말씀 드 리 고 싶 은 것 은 spring-security-acl after invocation handling 의 메커니즘 을 사 용 했 기 때 문 입 니 다.그럼 어떻게 일 하 는 지 보 자.AfterInvocationManager 의 부분 은 새로운 개념 과 관련 되 어 단독으로 한 편 을 쓰 려 고 한다.
이 그림 을 통 해 우 리 는 acl 도 하나의 인터페이스 일 뿐 이라는 것 을 분명히 알 수 있다.그것 의 실현 AfterInvocationManager 은 '많은' AfterInvocationProviderManager 을 관리 하여 권한 검증 을 진정 으로 수행 하 는 작업 이다.
여기 "많아 요".AfterInvocationProvider 사실은 네 개 만 이 루어 졌 는데 그 중 세 개 는 모두AfterInvocationProvider 그림 속 의 이 두 개 를 포함한다.
나머지 그것 acl 도 사실 authorization 작업 을 제대로 하지 않 고 대리 로 처리 했다 PostInvocationAdviceProvider.이 PostInvocationAuthorizationAdvice 도 PostInvocationAuthorizationAdvice 만 이 루어 졌 다. 즉, ExpressionBasedPostInvocationAdvice 표현 식 을 바탕 으로 authorization 의 실현 이다.
위 에서 언급 한 모든 관리자 와 provider 는 권한 검증 을 위 한 SpEL 방법 을 제공 했다.decide 에 비해 이 방법 들 은 하나의 AccessDecisionManager.decide() 매개 변수 가 더 많아 졌 다.이 는 판단 조건 으로 의사 결정 과정 에 참여 해 야 하기 때 문 이기 도 하고 의사 결정 과정 에서 처 리 된 다음 에 새로운 returnedObject 을 처리 한 결과 로 돌아 갈 수 있 기 때문이다.
ConfigAttribute
이 종 류 는 보안 설정 을 저장 하 는 데 사 용 됩 니 다.
예 를 들 어 아래 코드 는 해당 하 는 returnedObject 을 생 성 합 니 다.

@Override
protected void configure(HttpSecurity http) throws Exception {
  http.authorizeRequests()
      .mvcMatchers("hello")
      .hasAuthority("test")
      .anyRequest()
      .authenticated();
}

위의 코드 정의:

접근 ConfigAttribute 요청 은 /hello 권한

이 있어 야 합 니 다.

기타 임 의 요청 은 인증 (익명 접근 불가)

을 통과 해 야 합 니 다.
이렇게 하면 우 리 는 이런 것 을 얻 을 수 있다 test.
이것 은 ConfigAttribute 의 캡 처 이다.그 중 FilterSecurityInterceptor 에는 많은 것 securityMetadataSource 이 저장 되 어 있다.ConfigAttribute 하위 클래스 를 통 해 이 루어 진 AbstractSecurityInterceptor 방법 으로 이 를 얻 은 다음 에 이 를 통 해 이번에 사용 한 obtainSecurityMetadataSource 을 얻 을 수 있다.
캡 처 된 Collection 은 requestMap 과 RequestMatcher 의 관 계 를 보존 했다.
우리 가 Collection 을 요청 하면 첫 번 째 /hello, 즉 Collection 를 포함 하 는 것 을 얻 을 수 있다.우리 가 다른 인 터 페 이 스 를 요청 하면 두 번 째 인 터 페 이 스 를 얻 을 수 있다.
이 어 이러한 획득 hasAuthority('test') 은 후속 검증 논리 에 사 용 될 수 있다.
총결산
본 고 는 Spring Security Authorization 을 소개 하고 ConfigAttribute 어떻게 FilterSecurityInterceptor 의 마지막 사용 SecurityFilterChain 과 AccessDecisionManager 을 통 해 pre - invocation handling 과 after invocation handling 을 실현 하 는 지 에 중심 을 두 었 다.AfterInvocationManager 와 AccessDecisionManager 에 대해 서 는 내부 의 논 리 를 상세 하 게 소개 하지 않 고 하위 클래스 와 다른 인 터 페 이 스 를 어떻게 이용 하여 권한 검증 을 완성 하 는 지 소개 했다.그 내부 의 구체 적 인 세부 논 리 는 독자 가 스스로 연구 할 수 있다.