본문 바로가기

카테고리 없음

[Spring Security] 7 - 인가 파헤치기. Authorization

728x90

인가> 자원 요청시 그 자원을 요청할 자격이 되는지 확인 하는 것. 즉, 당신에게 무엇이 허가되어 있는지 증명하는 것

 

그림

 

Web App 접근 > 인증여부 판단

(인증이 되었을 경우 이쪽으로 올 수 있음)Resoruce 접근  > 인가여부 판단 

 

시큐리티 지원하는 권한 계층

 

1) 웹 계층 >> URL 요청에 따른 메뉴 or 화면 단위 (/user 라는 경로로 자원 접근. 경로에 대해 설정된 권한 확인) 

2) 서비스 계층 >> 메소드 단위 (user() invoke 시 함수에 대해 설정된 권한 확인) 

3) 도메인 계층 >> 객체 단위의 레벨 보안 (user 객체 단위에 R/W 접근시 권한 확인)

 

(웹 계층과 서비스 계층을 제일 많이 함)

 

인가는 걍 얘임 > FilterSecurityInterceptor(또 등장함)

특징>>

1)인가처리를 담당하는 필터! Security 가 제공하는 ㅕㅇ러 보안 필터들 중에서 제일 마지막에 위치함. (최종적으로 인가를 확인한다는 뜻)

2) 아까 인가 완료하고 Authorities 박힌 Authentication 객체 없이 올 경우 AuthenticationException 발생

3) 인증 후 Authority 가 없을 경우에는 AccessDeniedException을 발생

4) HTTP 보안 처리

5) AuthManager 처럼, 권한처리를 AccessDecisionManager.class에게 맡김. 

 

(7분 40초대 그림) 

 

요청 >

1.FSInterceptor 가 받아서 인증되어 있는지 여부를 판단

2. S.C에 저장되어 있는 Auth를 조회, 없으면 AuthException 발생 >> ExceptionTranslationFilter 로 이동.

3. SecurityMetadataSource,class 로 이동. 이 클래스에서는 사용자가 요청한 자원에 필요한 권한 정보를 가져옴.

4. 그 자원에 권한이 없으면 바로 조회시켜준다. 있으면 최종 심의 결정자인 AccessDescisionManager로 이동. 

5. ACM은 AccessDecisionVoter 에게 심의를 요청하고, 이 class에서 승인 혹은 거부를 결정한다. 그리고 ADM으로 결과를 반환한다. 

6. 접근 결과에 따라 자원 접근을 허용하든지, AccessDeniedException을 발생시키던지 한다. 

 

참고 FSIntercpetor 의 부모를 따라가보면 AbstractSecurityInterceptor 가 나오고, 이 ASI를 상속받는 두 클래스가 FSInterceptor와 MethodSecurityInterceptor 임. 차이점은 MSInterceptor 는 필터가 아니라 AOP 기반이며 하는 일이 다름. 

 

FSInterceptor가 call 되었을 때 invoke()를 호출한다. invoke() 내 super.beforeInvocation을 하므로, ASInterceptor의 함수를 호출하는 것. 그 함수를 가보면 FilterInvocation 객체에 대한 obtainSecurityMetadataSource 를 가져오는 것을 볼 수 있음. attributes에 저장되어 있음.  그게 바로 3번. 그리고 바로 그 아래 보면 getAuthentication 여부를 확인하기도 함 (인증 객체가 있는지, Anonymous 객체도 있다고 판단함) 

 

========================================================================

 

AccessDecisionManager (역시 Interface) 

 

>> 인증 정보 / 요청 정보 / 권한 정보를 이용해서 자원접근 허용 결정. 최종 결정 주체

>> 여러개의 Voter 를 가질 수 있으며, Voter들로 부터 접근 허용 / 거부 / 보류에 대한 값을 반환받아 판단을 한다. (단순한게 아님)

 

접근 결정 전략

(각자 내부 클래스 switch 문 보면 그렇구나 할 수 있음) 

1. AffirmativeBased > 여러개의 Voter 중 하나라도 접근 허가로 결론 나면 허가 시킨다. 

2. ConsensusBasd > 다수표에 의해 결론 내림. 동수일 경우 default 는 허가이나 접근 거부로 설정 가능

3. UnanimousBased > 반대. 한명이라도 거부시 접근 거부. (1의 완전반대)

 

 

AccessDecisionVoter (역시 Interface) 

 

>> 판단을 심사하는 위원들. 결정값을 ADM에게 전달한다.

>> Voter가 전달받는 자료들 1. Authentication - 인증 정보(user) , 2. FilterInvocation - 요청. 필요 권한정보 (antMatcher), 3. ConfigAttributes - 보유. 권한정보(hasRole) 

>> vote() 함수에서 전달받은 값들을 가지고 판단을 한다.

>> 결정 결과: GRANTED (1), DENIED (-1), ABSTAIN (0) : 0 은 보류라는 뜻. 

 

(8분대의 그림도 참고해보자) 

 

ADM 은 자기의 ADV들에게 decide() 요청을 한다. 

ADV들은 [결정 결과] 값들을 반환하게 되고, ADM은 전략에 따라 최종 결정 여부를 판단. GRANTED일경우 다시 FSInterceptor 필터로 돌아감. 예외처리될 경우 ExceptionTransaltional Filter 로 돌아감. 

 

각 인터페이스는 직접 구현을 해서 접근 관리자들을 따로 만들어서 적용시켜볼 수도 있음. 

 

 

=======================================================================================

728x90