Spring Security 적용기 (7) Spring Security Authorization(Method Security)

지난번에 이어 이번에는 Authorization의 Method Security와 추가 내용에 대한 내용을 정리했다. 

2024.05.05 - [Study/Java] - Spring Security 적용기 (6) Spring Security Authorization(HttpServletRequests)

Spring Security 적용기 (6) Spring Security Authorization(HttpServletRequests)

 

Spring Security 공식 문서

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

Method Security :: Spring Security

---

🎁 Method Security 개요

이전 시간에 등장했던 request level에 대한 인가 방식에 이어 Spring Security는 method level에서의 모델도 지원한다. 

 

method 수준의 Spring Security를 사용하기 위해서는 @Configuration 클래스에 @EnableMethodSecurity를 추가해야 한다. 그러면 즉시, @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter와 같은 메소드 인가 어노테이션을 사용할 수 있게 된다. 

---

🎁 Method Security 동작 원리

Spring Security의 메소드 인가 지원은 아래와 같은 경우에 편리하다. 

 

1. 세밀한 인가 로직 추출 : 예를 들어 메소드의 매개변수와 반환값이 인가 결정에 기여하는 경우이다. 

2. 서비스 레이어에서 보안 강제 : 서비스 레이어에서 직접적으로 보안을 강제할 수 있다. 

3. 스타일적으로 어노테이션 기반 구성을 HttpSecurity 기반 구성보다 선호할 때

4. Spring AOP를 사용하여 메소드 보안이 구축되었기 때문에 Spring Security의 기본 동작을 필요에 따라 재정의할 수 있다.(유연한 보안 설정)

 

메서드 인가는 메서드 전후에 인가를 적용하는 조합이다. 

 

다음은 메서드 보안이 적용된 예이다. 

@Service
public class MyCustomerService {
    @PreAuthorize("hasAuthority('permission:read')")
    @PostAuthorize("returnObject.owner == authentication.name")
    public Customer readCustomer(String id) { ... }
}

 

 

1. Spring AOP는 readCustomer에 대한 프록시 메서드를 호출한다. AuthorizationManagerBeforeInterceptor가 @PreAuthorize 포인트컷과 일치한다. 

2. 인터셉터는 PreAuthorizeAuthorizationManaer#check을 호출한다. 

3. 권한 관리자는 어노테이션의 SpEl 표현식을 파싱하고, MethodSecurityExpressionRoot를 포함한 MethodSecurityExpressionHandler를 사용하여 해당 표현식에 대한 EvaluationContext를 생성한다. 

4. 인터셉터는 3번의 EvaluationContext를 사용하여 표현식을 평가한다. 구체적으로는 인터셉터는 Supplier에서 인증 정보를 읽고, 해당 권한 목록에 permission:read 권한이 있는지 확인한다. 

5. 평가가 통가하면 Spring AOP는 메서드를 호출한다. 

6. 평가가 실패하면 인터셉터는 AuthorizationDeniedEvent를 게시하고 AccessDeniedException을 던진다. 이 예외는 ExceptionTranslationFilter에서 catch 되고 응답에 403 상태코드를 반환한다. 

7. 메서드가 반환된 후에는 Spring AOP가 @PostAuthorize 포인트컷과 일치하는 AuthorizationManagerAfterMethodInterceptor를 호출한다. 이전과 마찬가지로 동작하지만 PostAuthorizationManager가 사용된다. 

8. 평가가 통과하면 처리가 정상적으로 계속된다. 

9. 평가가 실패하면 인터셉터는 AuthorizationDeniedEvent를 게시하고 AccessDeniedException을 던진다. 이 예외는 ExceptionTranslationFilter에서 catch되고 응답에 403 상태 코드가 반환된다. 

 

위에서 보여준 것처럼, 메서드 호출에 여러 개의 메서드 보안 어노테이션이 포함되어 있으면 각각 처리한다. 이는 이러한 어노테이션이 모두 "AND"로 연결된 것이라고 생각할 수 있다. 다시말해, 인가되기 위해서는 모든 어노테이션 검사가 통과되어야 한다. 

 

그러나 동일한 어노테이션을 동일한 메서드에 여러번 반복하는 것은 지원되지 않는다. 예를들어, 동일한 메서드에 두 번의 @PreAuthorize를 배치할 수 없다. 

 

각각의 method 인가 어노테이션은 해당 어노테이션 또는 메타 어노테이션 상위 항목을 찾는 고유한 포인트컷 인스턴스를 갖는다. 또한 각각의 어노테이션은 고유한 메서드 인터셉터를 갖는다. 이는 기능을 더욱 구성 가능하도록 하기 위함이다. 

 

각 메서드 인터셉터는 아래와 같다. 

 

@PreAuthorize

AuthenticationManagerBeforeMethodInterceptor#preAuthorize

PreAuthorizeAuthorizationManager

@PostAuthorize

AuthenticationManagerAfterMethodInterceptor#postAuthoriza

PostAuthorizaAuthorizationManager

@PreFilter

PreFilterAuthorizationMethodInterceptor

@PostFilter

PostFilterAuthorizationMethodInterceptor

@Secured

AuthenticationManagerBeforeMethodInterceptor#secured

SecuredAuthorizationManager

 

또한 아래와 같이 복잡한 SqEL 표현식을 도입하는 것이 유혹적일 수 있다. 

@PreAuthorize("hasAuthority('permission:read') || hasRole('ADMIN')")

 

그러나 위의 코드 대신 RoleHierarchy를 사용하여 ROLE_ADMIN을 가진 사용자에게 permissioned:read를 부여할 수 있다. 

@Bean
static RoleHierarchy roleHierarchy() {
    return new RoleHierarchyImpl("ROLE_ADMIN > permission:read");
}

 

그런 다음 MethodSecurityExpressionHandler 인스턴스에 설정하면 더 간단한 @PreAuthorize 표현식을 사용할 수 있다. 

@PreAuthorize("hasAuthority('permission:read')")

---

🎁 Requst-level vs Method-level Authorization

	request-level	method-level
authorization type	전체 엑세스 레벨	세부적인 엑세스 레벨
configure location	config class 내	로컬 메서드 내
configuraion style	DSL	Annotaion
authorization definition	programmatic(코딩)	SqEL(Spring Expression Language)

** DSL(Domain Specific Language) : 특정 도메인(예 : Spring Security)에 특화된 언어

 

어노테이션 기반 메서드 보안을 사용할 때 주의해야 할 점은 어노테이션이 없는 메서드는 보호되지 않는다는 것이다. 이를 방지하기 위해 HttpSecurity 인스턴스에서 catch-all(모든 경우를 다루는) 인가 규칙을 선언하는 것이 중요하다. 이 규칙은 모든 요청에 대해 적용되며, 일치하는 다른 규칙이 없을 때 사용된다. 이렇게 함으로써 애플리케이션 전반에 보안을 유지할 수 있다. 

---

@PreAuthorize

@Component
public class BankService {
	@PreAuthorize("hasRole('ADMIN')")
	public Account readAccount(Long id) {
        // ... is only invoked if the `Authentication` has the `ROLE_ADMIN` authority
	}
}

 

@PostAuthorize

@Component
public class BankService {
	@PostAuthorize("returnObject.owner == authentication.name")
	public Account readAccount(Long id) {
        // ... is only returned if the `Account` belongs to the logged in user
	}
}

 

이 경우에는 주어진 표현식 returnObject.owner == authentication.name이 통과할 경우에만 메서드가 값을 반환한다. 여기서 returnObject는 Account를 말한다. 이 표현식은 요청한 사용자가 해당 계정의 소유자인지를 확인한다. 만약 표현식이 true를 반환하면 메서드가 값을 반환한다. 

 

@PreFilter

@Component
public class BankService {
	@PreFilter("filterObject.owner == authentication.name")
	public Collection<Account> updateAccounts(Account... accounts) {
        // ... `accounts` will only contain the accounts owned by the logged-in user
        return updated;
	}
}

 

해당 어노테이션은 메서드가 실행되기 전에 수행되며, 계정이 소유자와 현재 인증된 사용자의 이름이 같지 않은 경우 계정 값을 필터링하여 제외하는 것을 의미한다. filterObject는 accounts에 포함된 각 계정을 나타낸다.  

@PreFilter는 배열, 컬렉션, 맵, 스트림을 지원한다. 

 

@PreFilter("filterObject.owner == authentication.name")
public Collection<Account> updateAccounts(Account[] accounts)

@PreFilter("filterObject.owner == authentication.name")
public Collection<Account> updateAccounts(Collection<Account> accounts)

@PreFilter("filterObject.value.owner == authentication.name")
public Collection<Account> updateAccounts(Map<String, Account> accounts)

@PreFilter("filterObject.owner == authentication.name")
public Collection<Account> updateAccounts(Stream<Account> accounts)

 

@PostFilter

@Component
public class BankService {
	@PostFilter("filterObject.owner == authentication.name")
	public Collection<Account> readAccounts(String... ids) {
        // ... the return value will be filtered to only contain the accounts owned by the logged-in user
        return accounts;
	}
}

 

해당 어노테이션은 메서드가 실행된 후에 반환값에서 filterObject.owner == authentication.name 표현식이 실패하는 경우 해당 값을 필터링하여 제외하는 것을 말한다. @PostFilter 또한 배열, 컬렉션, 맵, 스트림을 지원한다. 

 

@Secured

해당 어노테이션은 @PreAuthorize의 legacy option이다. 

 

Method Security는 클래스와 인터페이스 수준에서의 인가도 지원한다. 

@Controller
@PreAuthorize("hasAuthority('ROLE_USER')")
public class MyController {
    @GetMapping("/endpoint")
    public String endpoint() { ... }
}

 

혹은 아래와 같이 클래스와 메서드 단위에 모두 선언되어 있을 수도 있다. 

@Controller
@PreAuthorize("hasAuthority('ROLE_USER')")
public class MyController {
    @GetMapping("/endpoint")
    @PreAuthorize("hasAuthority('ROLE_ADMIN')")
    public String endpoint() { ... }
}

 

메서드 수준의 어노테이션은 클래스 수준의 어노테이션을 재정의한다. 따라서 endpoint()는 "hasAuthority('ROLE_ADMIN')"의 인가를 따라가게 된다. 

---

🎁 Meta Annotaion

Method Security는 메타 어노테이션을 지원한다. 이는 애플리케이션의 특정 어노테이션을 작성하여 가독성을 향상시킬 수 있다는 것을 의미한다. 

 

예를 들어, @PreAuthorize("hasRole('ADMIN')")을 다음과 같이 @IsAdmin으로 간소화할 수 있다. 

@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@PreAuthorize("hasRole('ADMIN')")
public @interface IsAdmin {}

 

새로 정의된 @IsAdmin 어노테이션을 사용할 수 있다. 

@Component
public class BankService {
    @IsAdmin
    public Account readAccount(Long id) {
        // ... is only returned if the `Account` belongs to the logged in user
    }
}

---

🎁 일부 어노테이션만 활성화

@EnableMethodSecurity의 사전 구성을 해제하고 사용자가 직접 지정 가능하다. 만약 @PostAuthorize와 같은 특정 어노테이션만 활성화하려면 아래와 같이 작성할 수 있다. 

@Configuration
@EnableMethodSecurity(prePostEnabled = false)
class MethodSecurityConfig {
	@Bean
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	Advisor postAuthorize() {
		return AuthorizationManagerBeforeMethodInterceptor.postAuthorize();
	}
}

 

위의 코드는 MethodSecurity의 사전 구성을 비활성화 한 다음 @PostAuthoriza 인터셉터 자체를 직접 작성한다. 

---

🎁 Java 코드로 Authorization(인가)

Custom Bean

MethodSecurityExpressOperations를 매개변수로 가지는 메서드를 가지는 빈을 선언한다. 

@Component("authz")
public class AuthorizationLogic {
    public boolean decide(MethodSecurityExpressionOperations operations) {
        // ... authorization logic
    }
}

 

bean은 아래와 같이 사용할 수 있다. 

@Controller
public class MyController {
    @PreAuthorize("@authz.decide(#root)")
    @GetMapping("/endpoint")
    public String endpoint() {
        // ...
    }
}

 

이 방식의 좋은 점은 모든 권한 부여(Authorize) 로직이 별도의 클래스에 있어 독립적으로 단위 테스트 및 정확성 검증이 가능하다는 것이다. 

 

Custom Authorization Manager 사용

프로그래밍적으로 인가를 구현하는 두번째 방법은 custom AuthorizationManager를 생성하는 것이다. 

아래와 같이 authorization manager를 구현할 수 있다. 

@Component
public class MyAuthorizationManager implements AuthorizationManager<MethodInvocation>, AuthorizationManager<MethodInvocationResult> {
    @Override
    public AuthorizationDecision check(Supplier<Authentication> authentication, MethodInvocation invocation) {
        // ... authorization logic
    }

    @Override
    public AuthorizationDecision check(Supplier<Authentication> authentication, MethodInvocationResult invocation) {
        // ... authorization logic
    }
}

 

그런 다음 AuthorizationManager를 실행하려는 시점에 해당하는 포인트컷을 사용하여 메서드 인터셉터를 게시한다. 예를들어 @PreAuthoriza 및 @PostAuthorize 작동 방식을 아래와 같이 바꿀 수 있다. 

@Configuration
@EnableMethodSecurity(prePostEnabled = false)
class MethodSecurityConfig {
    @Bean
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	Advisor preAuthorize(MyAuthorizationManager manager) {
		return AuthorizationManagerBeforeMethodInterceptor.preAuthorize(manager);
	}

	@Bean
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	Advisor postAuthorize(MyAuthorizationManager manager) {
		return AuthorizationManagerAfterMethodInterceptor.postAuthorize(manager);
	}
}

 

Customizing Expression Handling

SpEL 표현식이 처리되는 방식을 사용자 정의할 수 있다. 이를 위해 사용자 정의 MethodSecurityExpressionHandler 를 노출할 수 있다. 기본 MethodSecurityExpressionHandler를 사용자 정의하여 기본값 이외의 사용자 지정 권한 부여 표현식을 추가할 수 있다. 

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

 

MethodSecurityExpressionHandler는 Spring Security에서 SpEL 표현식을 평가하고 권한 부여를 처리하는 데 사용되는 인터페이스이다. 해당 코드는 MethodSecurityExpressionHandler를 구현하고 있는 DefaultMethodSecurityExpressionHandler의 인스턴스를 생성하여 반환한다. 

DefaultMethodSecurityExpressionHandler는 Spring Security에서 기본적으로 제공되는 메서드 보안 표현식 처리를 담당한다. 그러나 위의 코드에서는 setRoleHierarchy 메서드를 호출하여 RoleHierarchy를 설정하고 있다.

---

🎁 Method Parameter 사용

추가적으로 Spring Security는 메서드의 파라미터 또한 SpEL 표현식으로 접근할 수 있도록 기능을 제공한다. 

DefaultSecurityParameterNameDiscoverer는 사용하여 매개변수 이름을 검색한다. 

import org.springframework.security.access.method.P;

...

@PreAuthorize("hasPermission(#c, 'write')")
public void updateContact(@P("c") Contact contact);

 

Spring Security가 매개변수로 들어가는 경우 @P 어노테이션을 사용한다. 

해당 코드는 매개변수 Contanct가 write 권한을 가지고 있어야 한다는 의미이다. 

 

import org.springframework.data.repository.query.Param;

...

@PreAuthorize("#n == authentication.name")
Contact findContactByName(@Param("n") String name);

 

Spring Data가 매개변수로 들어가는 경우 @Param을 사용할 수 있다. 

해당 코드를 통해 이름이 인증의 이름이 경우에만 호출이 인가됨을 구현할 수 있다. 

---

🎁 Domain Object Security(ACLs)

Spring Secuiry는 요청과 메서드 인가에 대한 기능을 제공하는 것 뿐만 아니라 도메인 객체의 보안 기능도 제공한다. 

 

복잡한 애플리케이션은 종종 웹 요청이나 메서드 호출의 수준을 넘어 액세스 권한을 정의해야 한다. 보안 결정은 누가(Authentication), 어디서(MehtodInvocation), 무엇에 대한 것(SomeDomainObject)로 구성되어야 한다. 다시 말해, 인가 결정은 메서드 호출의 주체가 되는 실제 도메인 객체도 고려해야 한다는 뜻이다. 

 

예를 들어, 애완동물 클리닉을 위한 애플리케이션을 설계한다고 가정하자. Spring 기반 애플리케이션의 주요 사용자 그룹은 애완동물 클리닉의 직원과 고객이다. 직원은 모든 데이터에 접근 가능하나, 고객은 자신의 고객 레코드만 볼 수 있어야 한다. 좀 더 복잡하게 하기위해 추가적으로 고객은 다른 사용자에게 자신의 레코드를 볼 수 있는 권한을 부여할 수 있다. 예를 들어, 강아지 유치원의 담당 선생님이나 강아지 동호회의 회장에게 자신의 레코드를 보여줄 수 있도록 할 수 있는 것이다. Spring Security를 기반으로 사용할 때는 아래와 같은 접근 방식을 사용할 수 있다. 

 

1. 비즈니스 메서드를 작성하여 보안을 강제한다.

비즈니스 메서드 내에서 보안 규칙을 직접 구현하는 것이다. 예를 들어, Customer 도메인 객체의 컬렉션을 사용하여 사용자가 엑세스할 수 있는지 여부를 확인할 수 있다. 

→ 권한 확인을 비즈니스 코드에 결합하여 단위 테스트가 어려워지며, Customer 권한 로직을 다른 곳에서 재사용하기 어렵다. 

 

2. AccessDecisionVoter를 작성하여  Authentication에 저장된 GrantedAuthority[] 인스턴스에 보안을 강제한다.

이 방법은 Spring Security의 AccessDecisionVoter 인터페이스를 구현하여 사용자의 Authentication 객체에 저장된 권한 정보를 기반으로 보안을 강제하는 것이다. 각 도메인 객체에 대한 사용자 권한은 사용자 정의 GrantedAuthority[] 객체로 Authentication에 설정된다. AccessDecisionVoter는 이를 기반으로 각 메서드 호출의 인가 결정을 내린다. 

→ 만약 하나의 동호회가 5000명의 고객을 확보했다면, 5000명의 고객에 모두 접근하여 권한을 확인해야 한다. 이는 Authentication  객체를 구성하는 데 소비되는 메모리 양과 시간이 많아진다는 뜻이다. 

 

3. AccessDecisionVoter를 작성하여 보안을 강제하고 대상 고객 도메인 객체를 직접 열어보는 것이다.

이 방법은 DAO(Data Access Object)를 사용하여 대상 모데인 객체를 검색하고 해당 객체의 승인된 사용자 컬렉션에 엑세스하여 사용자 권한을 확인한다. AccessDecisionVoter는 이를 기반으로 인가 결정을 내린다.

→ 1, 2번 방법에 비해 좋지만 비즈니스 메서드 자체가 Customer 객체를 검색하는 DAO에 대한 호출을 수행하므로 메서드 호출당 두 번의 엑세스가 발생한다는 점에서 비효율적이다. 

 

이러한 비효율과 문제를 해결하기 위해 ACL을 사용할 수 있다. 

이에 대한 자세한 내용은 아래 링크를 참고하길 바란다. 

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

Domain Object Security (ACLs) :: Spring Security

---

🎁 Authorization Events

거부된 권한에 대해서는 AuthorizationDeniedEvent가 발생한다. 또한 부여된 권한에 대해서도 AuthorizationGrantedEvent를 발생시킬 수도 있다. 

 

이러한 이벤트를 사용하려면 먼저 AuthorizationEventPublisher를 게시해야 한다. 

@Bean
public AuthorizationEventPublisher authorizationEventPublisher
        (ApplicationEventPublisher applicationEventPublisher) {
    return new SpringAuthorizationEventPublisher(applicationEventPublisher);
}

 

그 다음 Spring의 @EventListener를 사용할 수 있다. 

@Component
public class AuthenticationEvents {

    @EventListener
    public void onFailure(AuthorizationDeniedEvent failure) {
		// ...
    }
}

 

이 방법을 통해 권한 거부 이벤트를 캐치하여 적절한 작업을 수행할 수 있다.