Spring Security Authorization Architecture

Authorization Architecture

Authorities

인증에서는 모든 인증 구현이 GrantedAuthority 객체 목록을 저장하는 방식을 설명한다. 이 객체는 주체에게 부여된 권한을 나타낸다. GrantedAuthority 객체는 AuthenticationManager에 의해 Authentication 객체에 삽입되며, 이후 AccessDecisionManager instance가 권한 부여 결정을 내릴 때 이 객체를 읽는다.

GrantedAuthority interface는 오직 하나의 method를 보유하고 있다:

String getAuthority();

이 method는 AuthorizationManager instance에서 GrantedAuthority의 정확한 문자열 표현을 얻는 데 사용된다. 표현을 문자열로 반환함으로써 GrantedAuthority는 대부분의 AuthorizationManager 구현에서 쉽게 “읽을” 수 있다. GrantedAuthority를 문자열로 정확하게 표현할 수 없는 경우, GrantedAuthority는 “복잡한” 것으로 간주되며 getAuthority()는 null을 반환해야 한다.

복잡한 GrantedAuthority의 예로는 다양한 고객 계좌 번호에 적용되는 작업 및 권한 임계값 목록을 저장하는 구현이 있다. 이 복잡한 GrantedAuthority를 문자열로 표현하는 것은 매우 어렵다. 따라서 getAuthority() method는 null을 반환해야 한다. 이는 모든 GrantedAuthority 구현의 내용을 이해하기 위해 해당 구현을 지원해야 함을 나타낸다.

Spring Security에는 구체적인 GrantedAuthority 구현인 SimpleGrantedAuthority가 포함되어 있다. 이 구현은 사용자가 지정한 모든 문자열을 GrantedAuthority로 변환할 수 있도록 한다. 보안 아키텍처에 포함된 모든 AuthenticationProvider instance는 SimpleGrantedAuthority를 사용하여 Authentication 객체를 채운다.

기본적으로 역할 기반 권한 부여 규칙에는 ROLE_이 접두사로 포함된다. 즉, 보안 컨텍스트에 “USER” 역할이 필요한 권한 부여 규칙이 있는 경우, Spring Security는 기본적으로 “ROLE_USER”를 반환하는 GrantedAuthority#getAuthority를 찾는다.

GrantedAuthorityDefaults를 사용하여 이를 사용자 정의할 수 있다. GrantedAuthorityDefaults는 역할 기반 권한 부여 규칙에 사용할 접두사를 사용자 정의할 수 있도록 한다.

다음과 같이 GrantedAuthorityDefaults bean을 노출하여 권한 부여 규칙이 다른 접두사를 사용하도록 구성할 수 있다:

@Bean
static GrantedAuthorityDefaults grantedAuthorityDefaults(){
	return new GrantedAuthorityDefaults("MYPREFIX_");
}

Invocation Handling

Spring Security는 method 호출이나 웹 Request와 같은 보안 객체에 대한 접근을 제어하는 Interceptor를 제공한다. 호출 전, 호출 진행 여부에 대한 결정은 AuthorizationManager instance에 이뤄진다. 또한, 호출 후, 주어진 값을 반환할 수 있는지 여부에 대한 결정은 AuthorizationManager instance에 의해 이뤄진다.

The AuthorizationManager

AuthorizationManager는 AccessDecisionManager와 AccessDecisionVoter를 모두 대체한다.

AccessDecisionManager 또는 AccessDecisionVoter를 사용자 정의하는 Application은 AuthorizationManager를 사용하도록 변경하는 것이 좋다.

AuthorizationManager는 Spring Security의 요청 기반, method 기반 및 메시지 기반 권한 부여 Component에 의해 호출되며 최종 액세스 제어 결정을 담당한다. AuthorizationManager interface에는 두 가지 method가 있다:

AuthorizationDecision check(Supplier<Authentication> authentication, Object secureObject);

default void verify(Supplier<Authentication> authentication, Object secureObject) throws AccessDeniedException{
	// ...
}

AuthorizationManager의 check method는 권한 부여 결정을 내리는 데 필요한 모든 관련 정보를 전달받는다. 특히, 보안 객체를 전달하면 실제 보안 객체 호출에 포함된 인수를 검사할 수 있다. 예를 들어, 보안 객체가 MethodInvocation이라고 가정해 보겠다. MethodInvocation에서 Customer 인수를 쿼리한 다음, AuthorizationManager에 보안 로직을 구현하여 주체가 해당 고객에 작업할 수 있도록 허용하는 것이 쉽다. 구현은 액세스가 허용되면 양수 AuthorizationDecision을 반환하고, 액세스가 거부되면 음수 AuthorizationDecision을 반환하며, 결정을 내리지 않을 때는 null AuthorizationDecision을 반환해야 한다.

verify는 check method를 호출한 후 AuthorizationDecision이 음수인 경우 AccessDeniedException을 throw한다.

Delegate-based AuthorizationManager Implementations

사용자가 자체 AuthorizationManager를 구현하여 권한 부여의 모든 측면을 제어할 수 있지만, Spring Security는 개별 AuthorizationManager와 협업할 수 있는 대표 AuthorizationManager를 제공한다.

RequestMatcherDelegatingAuthorizationManager는 Request를 가장 적합한 대표 AuthorizationManager와 매칭한다. method 보안을 위해 AuthorizationManagerBeforeMethodInterceptor와 AuthorizationManagerAfterMethodInterceptor를 사용할 수 있다.

Authorization Manager 구현은 관련 class를 보여준다.

AuthorityAuthorizationManager

Spring Security에서 제공하는 가장 일반적인 AuthorizationManager는 AuthorityAuthorizationManager이다. 이 관리자는 현재 인증에서 검색할 권한 집합을 지정한다. 인증에 구성된 권한이 포함되어 있으면 양수 AuthorizationDecision을 반환한다. 그렇지 않으면 음수 AuthorizationDecision을 반환한다.

AuthenticatedAuthorizationManager

또 다른 관리자는 AuthenticatedAuthorizationManager이다. 익명 사용자, 완전 인증 사용자, 그리고 Remember-Me 인증 사용자를 구분하는 데 사용할 수 있다. 많은 사이트에서 Remember-Me 인증을 통해 특정 제한적인 접근을 허용하지만, 전체 접근 권한을 얻으려면 login을 통해 신원을 확인해야 한다.

AuthorizationManagers

AuthorizationManagers에는 개별 AuthorizationManagers를 보다 정교한 표현식으로 구성하는 데 유용한 정적 팩토리도 있다.

Custom Authorization Managers

물론, 사용자 지정 AuthorizationManager를 구현하고 원하는 모든 액세스 제어 로직을 추가할 수 있다. Application에 특화되거나(비즈니스 로직 관련) 보안 관리 로직을 구현할 수도 있다. 예를 들어, Open Policy Agent나 자체 권한 부여 DB를 쿼리할 수 있는 구현을 만들 수 있다.

Hierarchical Roles

Application의 특정 역할이 다른 역할을 자동으로 “포함”해야 한다는 것은 일반적인 요구 사항이다. 예를 들어, “관리자” 역할과 “사용자” 역할이라는 개념이 있는 Application에서 관리자가 일반 사용자가 할 수 있는 모든 작업을 수행할 수 있도록 하려는 경우가 있다. 이를 위해 모든 관리자에게 “사용자” 역할도 할당하도록 할 수 있다. 또는 “사용자” 역할에 “관리자” 역할도 포함되도록 요구하는 모든 액세스 제약 조건을 수정할 수 있다. Application에 여러 역할이 있는 경우 이 작업은 상당히 복잡해질 수 있다.

역할 계층 구조를 사용하면 어떤 역할(또는 권한)이 다른 역할을 포함할지 구성할 수 있다. 이 기능은 HttpSecurity#authorizeHttpRequests의 Filter 기반 권한 부여와 사전-사후 annotation의 DefaultMethodSecurityExpressionHandler, @Secured의 SecuredAuthorizationManager, JSR-250 annotation의 Jsr250AuthorizationManager를 통한 method 기반 권한 부여에서 지원된다. 다음과 같은 방법으로 모든 항목에 대한 동작을 한 번에 구성할 수 있다:

@Bean
static RoleHierarchy roleHierarchy(){
	return RoleHierarchyImpl.withDefaultRolePrefix()
		.role("ADMIN").implies("STAFF")
		.role("STAFF").implies("USER")
		.role("USER").implies("GUEST")
		.build();
}

@Bean
static MethodSecurityExpressionHandler methodSecurityExpressionHandler(RoleHierarchy roleHierarchy){
	DefaultMethodSecurityExpressionHandler expressionHandler=new DefaultMethodSecurityExpressionHandler();
	expressionHandler.setRoleHierarchy(roleHierarchy);
	return expressionHandler;
}

여기에는 ROLE_ADMIN → ROLE_STAFF → ROLE_USER → ROLE_GUEST라는 네 가지 역할이 계층 구조로 존재한다. ROLE_ADMIN으로 인증된 사용자는 Filter 또는 method 기반 규칙에 따라 보안 제약 조건을 평가할 때 네 가지 역할을 모두 가진 것처럼 동작한다.

역할 계층 구조는 Application의 액세스 제어 구성 데이터를 간소화하고/하거나 사용자에게 할당해야 하는 권한 수를 줄이는 편리한 방법을 제공한다. 더 복잡한 요구 사항의 경우, Application에 필요한 특정 액세스 권한과 사용자에게 할당된 역할 간의 논리적 매핑을 정의하고, 사용자 정보를 로드할 때 두 매핑을 변환할 수 있다.

---

참조

https://docs.spring.io/spring-security/reference/servlet/authorization/architecture.html