Method Security

김상욱·2024년 12월 11일
post-thumbnail

Spring Security는 요청 수준에서의 권한 부여뿐만 아니라 메서드 수준에서도 권한 부여를 모델링하는 것을 지원합니다.

애플리케이션에서 이를 활성화하려면, @Configuration 클래스에 @EnableMethodSecurity를 추가하거나 XML 구성 파일에 \<method-security>를 추가하면 됩니다. 아래는 예제입니다:

Java
Kotlin
Xml 

@EnableMethodSecurity

이렇게 하면 Spring에서 관리하는 클래스나 메서드에 대해 @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter와 같은 어노테이션을 사용하여 메서드 호출, 입력 매개변수 및 반환 값을 포함한 권한 부여를 설정할 수 있습니다.

Spring Boot Starter Security는 기본적으로 메서드 수준의 권한 부여를 활성화하지 않습니다.
메서드 보안은 AspectJ 지원, 사용자 정의 어노테이션, 여러 구성 포인트를 포함하여 다양한 사용 사례를 지원합니다. 아래와 같은 주요 사용 사례를 학습하는 것을 고려해 보세요:

  • @EnableGlobalMethodSecurity에서 마이그레이션
  • 메서드 보안이 작동하는 방식과 이를 사용하는 이유
  • 요청 수준과 메서드 수준 권한 부여 비교
  • @PreAuthorize 및 @PostAuthorize를 사용한 메서드 권한 부여
  • 권한이 거부되었을 때 대체 값을 제공
  • @PreFilter 및 @PostFilter를 사용한 메서드 필터링
  • JSR-250 어노테이션으로 메서드 권한 부여
  • AspectJ 표현식으로 메서드 권한 부여
  • AspectJ 바이트 코드 위빙과 통합
  • @Transactional 및 기타 AOP 기반 어노테이션과 조정
  • SpEL 표현식 처리를 사용자 정의
  • 사용자 정의 권한 시스템과의 통합

메서드 보안이 작동하는 방식

Spring Security의 메서드 권한 부여는 다음과 같은 상황에서 유용하게 사용됩니다:

  1. 세밀한 권한 부여 논리를 분리
    메서드의 매개변수와 반환값이 권한 부여 결정에 기여하는 경우.

  2. 서비스 계층에서 보안 강제
    비즈니스 로직이 위치하는 서비스 계층에 보안을 추가하여 애플리케이션의 보안성을 강화.

  3. HttpSecurity 기반 설정보다 어노테이션 기반 설정 선호
    코드의 가독성과 유지보수성을 높이는 방식으로 메서드 보안을 구성.

Spring AOP와의 통합

Spring Security의 메서드 보안은 Spring AOP를 기반으로 구축되었습니다. 이를 통해 Spring Security의 기본 동작을 필요한 대로 재정의할 수 있는 강력한 표현력을 제공합니다.

활성화 방법

  1. Java 구성 클래스에서 활성화
    @EnableMethodSecurity 어노테이션을 @Configuration 클래스에 추가합니다.

  2. XML 구성 파일에서 활성화
    <sec:method-security/>를 Spring XML 구성 파일에 추가합니다.

@EnableGlobalMethodSecurity와의 차이점

기존의 @EnableGlobalMethodSecurity 및 <sec:global-method-security/>는 더 이상 사용되지 않으며, 새로운 방식으로 마이그레이션하는 것이 권장됩니다.
새로운 구성 방식의 개선 사항은 다음과 같습니다:

  1. 간소화된 AuthorizationManager API 사용
    이전의 메타데이터 소스, 구성 속성, 결정 관리자, 투표자를 대체하여 재사용성과 사용자 정의가 쉬워졌습니다.

  2. 직접적인 빈 기반 구성
    GlobalMethodSecurityConfiguration을 확장하지 않고도 빈을 쉽게 사용자 정의 가능.

  3. 네이티브 Spring AOP 사용
    추상화를 제거하고 Spring AOP의 기본 빌딩 블록을 사용하여 커스터마이징 가능.

  4. 충돌 어노테이션 검사
    모호하지 않은 보안 구성을 보장하기 위해 충돌하는 어노테이션을 검사.

  5. JSR-250 준수
    Java 표준 권한 부여 어노테이션을 지원.

  6. 기본 어노테이션 활성화
    @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter가 기본적으로 활성화.

메서드 보안 흐름 예제

다음과 같이 어노테이션이 적용된 서비스 빈이 있다고 가정합니다:

@Service
public class MyCustomerService {
    @PreAuthorize("hasAuthority('permission:read')")
    @PostAuthorize("returnObject.owner == authentication.name")
    public Customer readCustomer(String id) {
        // 비즈니스 로직
    }
}

이 메서드를 호출했을 때 메서드 보안이 작동하는 과정은 다음과 같습니다:

1. @PreAuthorize 처리

  1. Spring AOP 프록시가 readCustomer 메서드를 호출합니다.

    • 이 프록시에는 AuthorizationManagerBeforeMethodInterceptor라는 어드바이저가 포함되어 있으며, 이 어드바이저가 @PreAuthorize 포인트컷에 매칭됩니다.

  2. 인터셉터가 PreAuthorizeAuthorizationManager#check를 호출합니다.

  3. 권한 관리자(AuthorizationManager)는 MethodSecurityExpressionHandler를 사용하여 어노테이션에 작성된 SpEL 표현식을 분석하고, 권한 부여를 평가하기 위한 EvaluationContext를 생성합니다.

    • 이 컨텍스트는 인증 정보(Supplier<Authentication>), 메서드 호출 정보(MethodInvocation) 등을 포함합니다.

  4. 컨텍스트를 기반으로 SpEL 표현식을 평가합니다.

    • 인증 정보에서 permission:read 권한이 있는지 확인.

  5. 평가 결과:

    • 성공: Spring AOP가 메서드 실행을 진행.
    • 실패:
      • AuthorizationDeniedEvent 이벤트가 발행.
      • AccessDeniedException 예외를 던짐.
      • 이 예외는 ExceptionTranslationFilter에서 포착되어 HTTP 응답으로 403 상태 코드를 반환.

2. @PostAuthorize 처리

  1. 메서드 실행이 완료된 후, Spring AOP가 AuthorizationManagerAfterMethodInterceptor를 호출합니다.

    • 이 어드바이저는 @PostAuthorize 포인트컷에 매칭됩니다.

  2. PostAuthorizeAuthorizationManager가 반환된 객체를 기반으로 SpEL 표현식을 평가합니다.

    • 예: 반환값의 owner가 인증된 사용자(authentication.name)와 동일한지 확인.

  3. 평가 결과:

    • 성공: 정상적으로 메서드 실행 완료.
    • 실패:
      • AuthorizationDeniedEvent 이벤트 발행.
      • AccessDeniedException 예외 발생 및 403 상태 코드 반환.

HTTP 요청이 아닌 경우

만약 메서드 호출이 HTTP 요청 컨텍스트 외부에서 발생한다면, AccessDeniedException을 직접 처리해야 할 수 있습니다.

요약

Spring Security의 메서드 보안은 AOP를 기반으로 동작하며, 권한 부여를 전후로 세밀하게 제어할 수 있습니다. 이를 통해 서비스 계층에서 보안성을 강화하고, 어노테이션 기반의 선언적 보안을 쉽게 적용할 수 있습니다.

여러 어노테이션은 순차적으로 계산됩니다.
위에서 설명한 것처럼, 메서드 호출에 여러 메서드 보안 어노테이션이 포함된 경우, 각 어노테이션은 하나씩 순차적으로 처리됩니다. 이는 이들이 함께 "AND" 연산으로 묶인 것처럼 간주될 수 있음을 의미합니다. 다시 말해, 호출이 권한 부여를 받으려면 모든 어노테이션 검사에서 권한 승인이 통과해야 합니다.

중복된 어노테이션은 지원되지 않습니다.
즉, 동일한 메서드에 동일한 어노테이션을 반복해서 사용할 수는 없습니다. 예를 들어, 하나의 메서드에 @PreAuthorize를 두 번 사용할 수는 없습니다.

대신, SpEL의 boolean 지원이나 별도의 빈으로 위임하는 방식을 사용할 수 있습니다.

각 어노테이션은 자체적인 포인트컷을 가집니다.
각 어노테이션은 메서드와 이를 포함하는 클래스에서 시작하여 전체 객체 계층 구조를 통해 해당 어노테이션 또는 메타 어노테이션을 찾는 고유한 포인트컷 인스턴스를 가지고 있습니다.

각 어노테이션은 고유한 메서드 인터셉터를 가짐

Spring Security의 메서드 보안에서, 각 어노테이션은 전용 메서드 인터셉터를 가지고 있습니다. 이는 보안 설정을 더 유연하고 조합 가능하게 만들기 위해 설계되었습니다. 예를 들어, 기본 제공되는 Spring Security 인터셉터를 비활성화하고, 특정 어노테이션에만 해당하는 메서드 인터셉터를 사용할 수 있습니다.

어노테이션별 메서드 인터셉터

  1. @PreAuthorize

    • 인터셉터: AuthorizationManagerBeforeMethodInterceptor#preAuthorize
    • 사용되는 관리자: PreAuthorizeAuthorizationManager
    • 역할: 메서드 실행 전에 권한을 확인합니다.

  2. @PostAuthorize

    • 인터셉터: AuthorizationManagerAfterMethodInterceptor#postAuthorize
    • 사용되는 관리자: PostAuthorizeAuthorizationManager
    • 역할: 메서드 실행 후 반환값을 기준으로 권한을 확인합니다.

  3. @PreFilter

    • 인터셉터: PreFilterAuthorizationMethodInterceptor
    • 역할: 메서드 실행 전에 입력 매개변수(리스트나 컬렉션)를 필터링합니다.

  4. @PostFilter

    • 인터셉터: PostFilterAuthorizationMethodInterceptor
    • 역할: 메서드 실행 후 반환값(리스트나 컬렉션)을 필터링합니다.

  5. @Secured

    • 인터셉터: AuthorizationManagerBeforeMethodInterceptor#secured
    • 사용되는 관리자: SecuredAuthorizationManager
    • 역할: 메서드 실행 전에 특정 권한(역할)을 요구합니다.

  6. JSR-250 어노테이션

    • 인터셉터: AuthorizationManagerBeforeMethodInterceptor#jsr250
    • 사용되는 관리자: Jsr250AuthorizationManager
    • 역할: JSR-250(Java 표준) 기반의 권한 어노테이션을 지원합니다.

Spring Security에서 기본 제공 인터셉터

Spring Security는 @EnableMethodSecurity를 추가했을 때 다음과 같은 인터셉터를 기본적으로 제공합니다. 이를 통해 메서드 수준에서 권한 부여를 효율적으로 처리할 수 있습니다.

@Bean
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
static Advisor preAuthorizeMethodInterceptor() {
    return AuthorizationManagerBeforeMethodInterceptor.preAuthorize();
}

@Bean
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
static Advisor postAuthorizeMethodInterceptor() {
    return AuthorizationManagerAfterMethodInterceptor.postAuthorize();
}

@Bean
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
static Advisor preFilterMethodInterceptor() {
    return AuthorizationManagerBeforeMethodInterceptor.preFilter();
}

@Bean
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
static Advisor postFilterMethodInterceptor() {
    return AuthorizationManagerAfterMethodInterceptor.postFilter();
}

주요 요소 설명

  1. @Bean 어노테이션
    Spring 컨텍스트에서 해당 메서드를 빈으로 등록.

  2. @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
    이 빈이 애플리케이션의 핵심 동작을 지원하는 역할임을 지정.

  3. AuthorizationManagerBeforeMethodInterceptor 및 AuthorizationManagerAfterMethodInterceptor
    각각 메서드 실행 전(Before)과 후(After)의 권한 검사를 담당.

사용 사례 예시

1. @PreAuthorize와 @PostAuthorize 예제

@Service
public class MyService {
    @PreAuthorize("hasRole('ADMIN')")
    @PostAuthorize("returnObject.owner == authentication.name")
    public Customer getCustomer(String id) {
        // 메서드 로직
    }
}
  • @PreAuthorize: 메서드 실행 전에 ADMIN 역할을 가진 사용자만 호출 가능.
  • @PostAuthorize: 반환된 객체의 owner가 로그인된 사용자와 동일해야 함.

2. @PreFilter와 @PostFilter 예제

@Service
public class MyService {
    @PreFilter("filterObject.startsWith('valid')")
    @PostFilter("filterObject.contains('result')")
    public List<String> processList(List<String> input) {
        return input.stream().map(String::toUpperCase).toList();
    }
}
  • @PreFilter: 입력 리스트 중 "valid"로 시작하지 않는 항목은 필터링.
  • @PostFilter: 반환 리스트 중 "result"가 포함되지 않은 항목은 필터링.

Spring AOP와의 통합

  • Spring Security는 Spring AOP 기반으로 인터셉터를 작동시킵니다.
  • 필요할 경우, 기본 인터셉터를 비활성화하고 커스터마이징이 가능합니다.
  • 이를 통해 애플리케이션 요구사항에 맞게 권한 부여 로직을 유연하게 구성할 수 있습니다.

요약

각 어노테이션이 고유한 인터셉터를 사용함으로써 메서드 수준에서 세밀한 권한 관리를 가능하게 합니다. 또한, Spring AOP를 통해 메서드 실행 전후로 권한 검사를 수행하며, 사용자 요구에 따라 이를 쉽게 커스터마이징할 수 있습니다.

복잡한 SpEL 표현식보다 권한 부여를 선호하는 이유

Spring Security에서 @PreAuthorize와 같은 어노테이션에 복잡한 SpEL(Spring Expression Language) 표현식을 사용하는 것은 흔하지만, 권한 부여를 단순화하고 유지보수를 쉽게 하기 위해 더 나은 방법이 존재합니다.
복잡한 SpEL 표현식 대신 권한을 미리 부여하는 방식을 사용하는 것이 좋습니다.

복잡한 SpEL 표현식의 예

다음은 복잡한 SpEL 표현식의 예입니다:

@PreAuthorize("hasAuthority('permission:read') || hasRole('ADMIN')")
  • 문제점:
    • 권한 논리가 어노테이션에 직접 정의되기 때문에 코드가 복잡하고 읽기 어렵습니다.
    • 비슷한 표현식을 여러 곳에서 사용할 경우, 변경 시 유지보수가 어렵습니다.
    • 테스트 및 디버깅이 더 복잡해질 수 있습니다.

대안: 권한 부여 사용

ROLE_ADMIN에 이미 permission:read 권한을 포함시키는 방식으로, SpEL 표현식을 단순화할 수 있습니다.
이 방법은 역할 계층(Role Hierarchy)을 활용합니다.

Role Hierarchy 정의

Spring Security에서 RoleHierarchy를 사용하여 상위 역할이 하위 권한을 포함하도록 설정할 수 있습니다.

Java 예제
@Bean
static RoleHierarchy roleHierarchy() {
    RoleHierarchyImpl roleHierarchy = new RoleHierarchyImpl();
    roleHierarchy.setHierarchy("ROLE_ADMIN > permission:read");
    return roleHierarchy;
}
설명
  • ROLE_ADMIN > permission:read는 ROLE_ADMIN이 permission:read 권한을 포함함을 나타냅니다.
  • ROLE_ADMIN을 가진 사용자는 자동으로 permission:read 권한도 가지게 됩니다.

MethodSecurityExpressionHandler에 Role Hierarchy 설정

RoleHierarchy를 Spring Security의 MethodSecurityExpressionHandler에 연결해야 작동합니다.

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

간단한 SpEL 표현식 사용

권한을 미리 설정하면 @PreAuthorize 표현식을 단순화할 수 있습니다:

@PreAuthorize("hasAuthority('permission:read')")
  • 더 이상 || 연산자나 복잡한 표현식을 사용할 필요가 없습니다.
  • 유지보수가 쉬워지고, 코드 가독성이 향상됩니다.

로그인 시 권한 부여로 로직 단순화

가능하다면, 애플리케이션의 특정 권한 논리를 사용자의 로그인 시점에 권한 부여로 전환할 수도 있습니다.

예제

사용자가 로그인할 때 다음과 같은 권한을 추가로 부여합니다:

if (user.hasRole("ROLE_ADMIN")) {
    authorities.add(new SimpleGrantedAuthority("permission:read"));
}

이 방법을 사용하면 권한 논리를 @PreAuthorize 대신 로그인 처리 로직으로 이동시켜 어노테이션 표현식을 더욱 단순화할 수 있습니다.

장점

  1. 가독성 향상

    • 어노테이션 표현식이 간단해져 코드 이해가 쉬워집니다.

  2. 유지보수 용이

    • 권한 논리가 중앙 집중화되어 변경이 쉽습니다.

  3. 재사용성 증가

    • 같은 권한 논리를 여러 곳에서 일관되게 사용할 수 있습니다.

  4. 보안 로직 통합

    • 로그인 시점에 권한을 부여하여 보안 로직을 체계적으로 관리할 수 있습니다.

요약

복잡한 SpEL 표현식을 사용하는 대신 역할 계층(RoleHierarchy)이나 로그인 시점의 권한 부여를 활용하여 보안 로직을 단순화하세요. 이는 코드 가독성, 유지보수성, 보안성을 모두 향상시키는 효과적인 방법입니다.

요청 수준(Request-level) vs 메서드 수준(Method-level) 권한 부여 비교

Spring Security에서 권한 부여는 요청 수준과 메서드 수준 두 가지 방식으로 구현할 수 있습니다. 각 방식은 보안 규칙을 어디에 선언하고, 얼마나 세밀하게 적용할 것인지에 따라 적합한 사용 사례가 달라집니다.

비교표

특징요청 수준(Request-level)메서드 수준(Method-level)
권한 부여의 유형대략적인(Coarse-grained)세밀한(Fine-grained)
구성 위치구성 클래스(Config Class)에 선언메서드 선언에 직접 선언
구성 스타일DSL (Domain Specific Language)어노테이션 (Annotations)
권한 정의 방식프로그래밍 방식 (Programmatic)SpEL (Spring Expression Language)

요청 수준(Request-level) 권한 부여

특징

  • 대략적인(Coarse-grained):
    요청 URL에 따라 권한 부여 규칙을 설정하며, 주로 컨트롤러의 전체적인 접근 제어를 정의합니다.
  • 구성 클래스(Config Class):
    보안 규칙이 HttpSecurity와 같은 중앙 집중된 구성 파일에 위치합니다.
  • DSL 기반:
    보안 규칙은 DSL 형식으로 선언됩니다.

장점

  1. 관리 용이:
    모든 보안 규칙이 한곳에 모여 있어 일관되게 관리 가능.
  2. URL 중심:
    RESTful API와 같이 URL이 중요한 애플리케이션에서 적합.
  3. 포괄적인 적용:
    특정 컨트롤러나 URL 경로 전체를 쉽게 보호할 수 있음.

단점

  • 세밀한 권한 부여에는 적합하지 않음.
    예를 들어, 특정 메서드의 매개변수나 반환값을 기준으로 권한을 제어할 수 없음.

메서드 수준(Method-level) 권한 부여

특징

  • 세밀한(Fine-grained):
    메서드의 매개변수나 반환값 등, 비즈니스 로직에 가까운 수준에서 권한 부여를 제어합니다.
  • 메서드 선언에 로컬(Local):
    각 메서드에 직접 권한 규칙을 설정하며, 보안 로직이 메서드와 함께 존재합니다.
  • 어노테이션 기반:
    @PreAuthorize, @PostAuthorize 등의 어노테이션과 SpEL을 활용하여 권한 부여 규칙을 정의합니다.

장점

  1. 세밀한 제어:
    특정 로직에 따라 권한을 부여하거나, 메서드의 반환값을 기준으로 권한을 검증할 수 있음.
  2. 로컬 선언:
    권한 규칙이 메서드에 바로 선언되므로, 메서드와 권한 로직을 한눈에 파악 가능.
  3. 유연성:
    SpEL을 통해 복잡한 권한 조건을 표현할 수 있음.

단점

  • 분산된 구성:
    메서드별로 권한 규칙이 흩어져 있을 수 있어, 전체적인 보안 규칙을 한곳에서 확인하기 어려움.
  • 기본값 없음:
    어노테이션을 사용하지 않은 메서드는 보호되지 않으며, 추가적인 보호 설정이 필요.

주요 차이점

1. 권한 규칙의 위치

  • 요청 수준 권한 부여는 중앙 집중형(구성 클래스에 선언).
  • 메서드 수준 권한 부여는 분산형(메서드에 직접 선언).

2. 적용 범위

  • 요청 수준은 대략적인 보안을 적용(URL 단위).
  • 메서드 수준은 세밀한 보안을 적용(매개변수 및 반환값 기준).

메서드 수준 보안의 주의점

  1. 보호되지 않은 메서드

    • 어노테이션 기반 메서드 보안을 사용할 때, 어노테이션이 없는 메서드는 보호되지 않습니다.
    • 해결책:
      HttpSecurity에서 포괄적인(기본값) 권한 부여 규칙을 선언해 놓습니다.
      http.authorizeRequests().anyRequest().authenticated();

  2. 권한 부여 로직의 중복

    • 메서드 수준에서 동일한 조건을 반복적으로 선언할 경우, 역할 계층(Role Hierarchy)이나 공통적인 권한 설정을 활용해 중복을 줄이는 것이 좋습니다.

어떤 방식을 선택해야 할까?

  • 요청 수준 권한 부여를 선호해야 하는 경우:

    • RESTful API와 같이 URL 중심의 애플리케이션.
    • 보안 규칙이 컨트롤러 단위로 일괄 적용되어야 할 때.

  • 메서드 수준 권한 부여를 선호해야 하는 경우:

    • 서비스 계층에서 세밀한 권한 관리가 필요한 경우.
    • 매개변수 및 반환값을 기준으로 권한을 제어할 때.

요약

  • 요청 수준 권한 부여는 중앙에서 관리하기 쉽고, URL 단위로 보호를 설정하는 데 적합합니다.
  • 메서드 수준 권한 부여는 더 세밀한 보안을 제공하며, 메서드와 권한 로직을 밀접하게 연결합니다.
  • 두 방식을 혼합하여 애플리케이션의 요구사항에 맞는 보안 구성을 설계할 수 있습니다.

Spring Security가 메서드 수준 권한 부여를 지원하는 주요 방법은 메서드, 클래스, 인터페이스에 추가할 수 있는 어노테이션을 사용하는 것입니다.

@PreAuthorize로 메서드 호출 권한 부여

Spring Security에서 @PreAuthorize는 메서드가 호출되기 전에 권한을 확인하는 어노테이션입니다. Method Security가 활성화된 상태에서, 특정 메서드에 접근하려면 미리 정의된 권한 조건을 충족해야 합니다.

기본 사용법

예제 코드

@Component
public class BankService {
    @PreAuthorize("hasRole('ADMIN')")
    public Account readAccount(Long id) {
        // 메서드 로직
    }
}
  • @PreAuthorize("hasRole('ADMIN')"):
    • hasRole('ADMIN') 조건을 만족하는 경우에만 readAccount 메서드가 실행됩니다.
    • 여기서 Authentication 객체가 ROLE_ADMIN 권한을 가져야 합니다.

테스트 코드로 확인

Spring Security의 메서드 보안을 테스트하기 위해 @WithMockUser를 사용하여 인증된 사용자 역할을 모의(Mock)할 수 있습니다.

테스트 예제

@Autowired
BankService bankService;

@WithMockUser(roles = "ADMIN")
@Test
void readAccountWithAdminRoleThenInvokes() {
    Account account = this.bankService.readAccount(12345678L);
    // 필요한 검증 로직 (assertion)
}

@WithMockUser(roles = "WRONG")
@Test
void readAccountWithWrongRoleThenAccessDenied() {
    assertThatExceptionOfType(AccessDeniedException.class).isThrownBy(
        () -> this.bankService.readAccount(12345678L));
}

  1. @WithMockUser(roles = "ADMIN")

    • ROLE_ADMIN 권한이 주어진 가상 사용자를 생성합니다.
    • 테스트에서 메서드 호출이 성공적으로 실행되는지 확인합니다.

  2. @WithMockUser(roles = "WRONG")

    • 올바르지 않은 권한(ROLE_WRONG)을 가진 가상 사용자.
    • 메서드 호출 시 AccessDeniedException이 발생하는지 확인합니다.

@PreAuthorize의 확장성

  1. 클래스 및 인터페이스 수준에서 사용 가능

    • 메서드뿐만 아니라 클래스나 인터페이스 전체에 @PreAuthorize를 선언할 수 있습니다.
    • 클래스 수준에서 선언하면, 해당 클래스의 모든 메서드가 동일한 권한 규칙을 따릅니다.

  2. 메타 어노테이션으로 사용

    • @PreAuthorize를 메타 어노테이션으로 정의하여 반복적인 설정을 줄일 수 있습니다.

  3. SpEL(Spring Expression Language) 사용

    • 메서드 매개변수를 포함한 복잡한 조건도 정의할 수 있습니다.

SpEL 예제

@PreAuthorize("#id == authentication.name or hasRole('ADMIN')")
public Account readAccount(Long id) {
    // `id`가 인증된 사용자 이름과 같거나 ADMIN 역할을 가진 경우에만 호출 가능
}
  • #id == authentication.name
    • 매개변수 id가 현재 인증된 사용자의 이름과 동일한지 확인.

장점

  1. 선언적 권한 부여

    • 메서드 수준에서 필요한 권한을 선언적으로 정의할 수 있어 가독성이 높아짐.

  2. 테스트 가능

    • @WithMockUser와 같은 테스트 도구를 사용해 권한 로직을 쉽게 검증 가능.

  3. 복잡한 조건 지원

    • SpEL을 통해 메서드 매개변수와 권한 정보를 조합한 정교한 조건 설정 가능.

  4. 유연한 사용 위치

    • 메서드, 클래스, 인터페이스에서 모두 사용 가능하며 메타 어노테이션으로 재활용 가능.

주의사항

  1. 메서드 호출 전 권한 확인

    • @PreAuthorize는 메서드 실행 전에 권한을 확인하며, 조건을 만족하지 않으면 AccessDeniedException이 발생합니다.

  2. 명확한 규칙 선언

    • 권한 조건을 명확히 선언하지 않으면, 보호되지 않은 메서드로 인해 보안 허점이 발생할 수 있습니다.

요약

  • @PreAuthorize는 Spring Security의 메서드 보안을 활성화하는 강력한 도구입니다.
  • 메서드 실행 전에 권한 조건을 선언적으로 정의할 수 있으며, SpEL을 사용해 복잡한 로직도 처리 가능합니다.
  • 테스트를 통해 권한 로직이 올바르게 작동하는지 확인할 수 있으며, 클래스나 인터페이스 수준에서도 사용 가능합니다.

@PostAuthorize를 사용한 메서드 반환값 권한 부여

Spring Security의 @PostAuthorize는 메서드가 실행된 후 반환값을 기준으로 권한을 확인하는 어노테이션입니다. 이는 Method Security가 활성화된 상태에서, 반환값이 특정 조건을 만족해야만 사용자에게 반환되도록 보장합니다.

기본 사용법

예제 코드

@Component
public class BankService {
    @PostAuthorize("returnObject.owner == authentication.name")
    public Account readAccount(Long id) {
        // 메서드 실행 로직
    }
}
  • @PostAuthorize("returnObject.owner == authentication.name")
    • 반환값인 Account 객체의 owner 속성이 인증된 사용자의 이름(authentication.name)과 같아야 반환됩니다.
    • 반환값은 returnObject로 참조됩니다.

작동 방식

  1. 메서드 실행 후 반환값 확인

    • @PostAuthorize는 메서드 로직이 실행된 후 반환값을 기준으로 권한을 확인합니다.
    • 조건을 만족하지 않으면, 예외를 던지고 사용자에게 반환값을 제공하지 않습니다.

  2. SpEL(Spring Expression Language) 사용

    • returnObject와 같은 반환값을 기준으로 한 권한 조건을 선언할 수 있습니다.
    • 인증 객체(authentication), 메서드 매개변수 등을 활용한 복잡한 로직 정의도 가능.

테스트 코드로 확인

테스트 예제

@Autowired
BankService bankService;

@WithMockUser(username = "owner")
@Test
void readAccountWhenOwnedThenReturns() {
    Account account = this.bankService.readAccount(12345678L);
    // 반환값 검증 로직 (assertion)
}

@WithMockUser(username = "wrong")
@Test
void readAccountWhenNotOwnedThenAccessDenied() {
    assertThatExceptionOfType(AccessDeniedException.class).isThrownBy(
        () -> this.bankService.readAccount(12345678L));
}

  1. @WithMockUser(username = "owner")

    • username이 owner인 가상 사용자 생성.
    • 반환값의 owner가 owner인 경우 정상적으로 반환됨.

  2. @WithMockUser(username = "wrong")

    • 반환값의 owner와 username이 다르면, AccessDeniedException이 발생.

@PostAuthorize의 확장성

  1. 클래스 및 인터페이스 수준에서 사용

    • @PostAuthorize는 메서드뿐만 아니라 클래스나 인터페이스 수준에서도 선언 가능.
    • 클래스 수준에서 선언하면, 해당 클래스의 모든 메서드가 동일한 권한 규칙을 따름.

  2. 메타 어노테이션으로 사용

    • 반복적인 선언을 줄이기 위해 @PostAuthorize를 메타 어노테이션으로 정의 가능.

메타 어노테이션 정의 예제

@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@PostAuthorize("returnObject.owner == authentication.name")
public @interface RequireOwnership {}
  1. 서비스 클래스에 메타 어노테이션 적용
@Component
public class BankService {
    @RequireOwnership
    public Account readAccount(Long id) {
        // 메서드 로직
    }
}
  • 결과:
    • readAccount 메서드는 반환된 Account 객체의 owner가 로그인된 사용자의 이름과 동일한 경우에만 반환.

보안 측면에서의 유용성

  1. IDOR(Insecure Direct Object Reference) 방지

    • @PostAuthorize는 반환값이 적절히 필터링되었는지 확인하기 때문에, 권한이 없는 사용자가 잘못된 데이터를 액세스하는 것을 방지.

  2. 복잡한 권한 로직 지원

    • 반환값을 기준으로 복잡한 권한 조건을 쉽게 구현 가능.

작동 과정

  1. 메서드 실행

    • readAccount(Long id) 메서드가 호출되고 로직이 실행됩니다.

  2. 반환값 검사

    • 반환값(returnObject)이 어노테이션에 정의된 SpEL 조건을 충족하는지 확인.

  3. 결과 처리

    • 조건 충족: 반환값이 사용자에게 제공됨.
    • 조건 미충족:
      • Spring Security가 AccessDeniedException을 발생.
      • HTTP 요청 컨텍스트에서는 403 상태 코드가 반환.

장점

  1. 반환값 기반 권한 부여

    • 반환값의 속성을 기준으로 권한을 확인할 수 있어 세밀한 보안 제어 가능.

  2. 코드 가독성

    • 선언적으로 권한 로직을 설정하므로, 메서드의 보안 로직이 명확히 드러남.

  3. 테스트 가능

    • @WithMockUser를 통해 다양한 권한 조건을 테스트 가능.

  4. 보안 강화

    • 조건을 만족하지 않는 반환값이 사용자에게 노출되는 것을 방지.

주의사항

  1. 추가 성능 비용

    • 메서드 실행 후 반환값을 검사하므로 약간의 추가 성능 비용이 발생할 수 있음.

  2. 조건 불충족 시 예외 처리 필요

    • HTTP 요청이 아닌 환경에서는 AccessDeniedException을 직접 처리해야 할 수 있음.

요약

@PostAuthorize는 메서드 실행 후 반환값을 기준으로 권한을 부여하는 강력한 도구입니다. IDOR 방지와 같은 보안 강화를 위해 사용되며, 메타 어노테이션으로 반복적인 선언을 줄일 수 있습니다.
테스트를 통해 반환값 기반의 권한 로직을 검증할 수 있으며, 복잡한 권한 조건도 SpEL을 통해 구현 가능합니다.

@PreFilter를 사용한 메서드 매개변수 필터링

Spring Security의 @PreFilter는 메서드가 호출되기 전에 매개변수에서 특정 조건을 충족하지 않는 항목을 필터링하는 어노테이션입니다. 이 어노테이션은 배열, 컬렉션, 맵, 스트림과 같은 데이터 구조를 지원하며, 특히 메서드 매개변수를 기준으로 세밀한 보안을 적용할 수 있습니다.

기본 사용법

예제 코드

@Component
public class BankService {
    @PreFilter("filterObject.owner == authentication.name")
    public Collection<Account> updateAccounts(Account... accounts) {
        // `accounts`는 로그인된 사용자가 소유한 계정만 포함하게 됩니다.
        return updated;
    }
}
  • @PreFilter("filterObject.owner == authentication.name"):
    • filterObject는 입력된 accounts 배열의 각 요소를 나타냅니다.
    • 각 요소의 owner 속성이 인증된 사용자의 이름(authentication.name)과 일치하는 경우에만 해당 요소가 필터링 후 남습니다.

작동 방식

  1. 메서드 호출 전 매개변수 필터링

    • @PreFilter는 메서드 호출 전에 매개변수를 순회하며 조건을 평가합니다.
    • 조건을 충족하지 않는 항목은 매개변수에서 제거됩니다.

  2. SpEL(Spring Expression Language) 사용

    • filterObject와 같은 SpEL 표현식을 사용하여 매개변수를 평가합니다.
    • 인증 정보(authentication), 매개변수의 속성, 그리고 복잡한 조건을 조합할 수 있습니다.

테스트 코드로 확인

테스트 예제

@Autowired
BankService bankService;

@WithMockUser(username = "owner")
@Test
void updateAccountsWhenOwnedThenReturns() {
    Account ownedBy = new Account("owner", ...);  // 로그인된 사용자가 소유한 계정
    Account notOwnedBy = new Account("other", ...); // 다른 사용자가 소유한 계정

    Collection<Account> updated = this.bankService.updateAccounts(ownedBy, notOwnedBy);

    // 결과 검증
    assertThat(updated).containsOnly(ownedBy);
}
  • @WithMockUser(username = "owner")
    • username이 owner인 가상 사용자 생성.
    • 로그인된 사용자가 소유한 계정만 결과에 포함되는지 검증.

데이터 구조에 따른 사용

@PreFilter는 다양한 데이터 구조를 지원하며, 배열, 컬렉션, 맵, 스트림 등에 동일한 방식으로 동작합니다.

배열

@PreFilter("filterObject.owner == authentication.name")
public Collection<Account> updateAccounts(Account[] accounts)
  • accounts 배열에서 owner가 로그인된 사용자와 일치하는 항목만 필터링 후 남음.

컬렉션

@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)
  • 맵의 value 부분에서 필터링 조건을 평가.

스트림

@PreFilter("filterObject.owner == authentication.name")
public Collection<Account> updateAccounts(Stream<Account> accounts)
  • 스트림이 열려 있는 상태에서 필터링이 수행됩니다.

클래스 및 메타 어노테이션으로 확장

  1. 클래스 수준 선언

    • 클래스 수준에서 @PreFilter를 선언하면 해당 클래스의 모든 메서드에 동일한 조건이 적용됩니다.

  2. 메타 어노테이션으로 정의

    • 반복적인 선언을 줄이기 위해 @PreFilter를 메타 어노테이션으로 정의할 수 있습니다.

메타 어노테이션 정의

@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@PreFilter("filterObject.owner == authentication.name")
public @interface RequireOwnership {}

서비스 클래스에 적용

@Component
public class BankService {
    @RequireOwnership
    public Collection<Account> updateAccounts(Account... accounts) {
        return updated;
    }
}
  • 결과:
    • 메타 어노테이션으로 정의된 조건이 updateAccounts 메서드에 적용됩니다.

장점

  1. 매개변수 기반 세밀한 보안

    • 메서드의 입력 매개변수를 필터링하여, 인증되지 않은 데이터가 처리되지 않도록 보장.

  2. 코드 가독성 향상

    • 보안 로직을 선언적으로 정의하여 메서드 보안이 명확히 드러남.

  3. 유연한 데이터 구조 지원

    • 배열, 컬렉션, 맵, 스트림 등 다양한 데이터 구조를 처리 가능.

  4. 테스트 가능

    • @WithMockUser를 사용하여 권한 조건에 따른 동작을 쉽게 검증.

주의사항

  1. 조건이 복잡할수록 성능 비용 증가

    • 필터링 조건이 복잡할수록 추가적인 성능 비용이 발생할 수 있음.

  2. 빈 데이터 처리

    • 필터링 결과가 빈 배열이나 빈 컬렉션일 경우, 메서드 로직에서 이를 처리해야 할 수 있음.

  3. 스트림 상태

    • 스트림은 열려 있어야 하며, 닫힌 스트림에서는 필터링이 작동하지 않음.

요약

@PreFilter는 메서드 매개변수를 기준으로 권한을 확인하고, 조건에 맞지 않는 항목을 필터링하는 강력한 도구입니다. 다양한 데이터 구조를 지원하며, 클래스 수준 또는 메타 어노테이션으로 재사용 가능성을 높일 수 있습니다. 이를 통해 보안 로직을 세밀하게 제어하고, 선언적으로 관리할 수 있습니다.

@PostFilter를 사용한 메서드 반환값 필터링

Spring Security의 @PostFilter는 메서드가 반환하는 데이터에서 특정 조건에 맞지 않는 값을 필터링하는 어노테이션입니다. Method Security가 활성화된 상태에서, 반환값을 세밀히 제어하고 불필요하거나 권한이 없는 데이터를 제거하는 데 사용됩니다.

기본 사용법

예제 코드

@Component
public class BankService {
    @PostFilter("filterObject.owner == authentication.name")
    public Collection<Account> readAccounts(String... ids) {
        // 반환값(accounts)은 로그인된 사용자가 소유한 계정만 포함합니다.
        return accounts;
    }
}
  • @PostFilter("filterObject.owner == authentication.name"):
    • filterObject는 반환값의 각 요소를 나타냅니다.
    • 각 요소의 owner 속성이 인증된 사용자의 이름(authentication.name)과 일치하는 경우에만 반환됩니다.

작동 방식

  1. 메서드 실행 후 반환값 필터링

    • @PostFilter는 메서드 실행이 끝난 후 반환된 데이터에서 조건을 만족하지 않는 항목을 필터링합니다.
    • 반환값은 배열, 컬렉션, 맵, 스트림 등 다양한 데이터 구조를 지원합니다.

  2. SpEL(Spring Expression Language) 사용

    • filterObject와 같은 SpEL 표현식을 사용하여 반환값을 평가합니다.
    • 반환값의 속성, 인증 객체(authentication) 등 다양한 조건을 조합 가능.

테스트 코드로 확인

테스트 예제

@Autowired
BankService bankService;

@WithMockUser(username = "owner")
@Test
void readAccountsWhenOwnedThenReturns() {
    Collection<Account> accounts = this.bankService.readAccounts("owner", "not-owner");

    // 반환값 검증
    assertThat(accounts).hasSize(1);
    assertThat(accounts.iterator().next().getOwner()).isEqualTo("owner");
}
  • @WithMockUser(username = "owner")
    • username이 owner인 가상 사용자 생성.
    • 반환값 중 owner가 로그인된 사용자와 동일한 계정만 포함되는지 확인.

데이터 구조에 따른 사용

@PostFilter는 배열, 컬렉션, 맵, 스트림과 같은 다양한 데이터 구조를 지원합니다.

배열

@PostFilter("filterObject.owner == authentication.name")
public Account[] readAccounts(String... ids)
  • 반환된 배열에서 조건에 맞지 않는 항목은 필터링 후 제거됩니다.

컬렉션

@PostFilter("filterObject.owner == authentication.name")
public Collection<Account> readAccounts(String... ids)
  • 컬렉션 형태의 반환값도 동일하게 필터링 동작 수행.

맵

@PostFilter("filterObject.value.owner == authentication.name")
public Map<String, Account> readAccounts(String... ids)
  • 맵의 value 부분에서 조건을 평가하여 필터링합니다.

스트림

@PostFilter("filterObject.owner == authentication.name")
public Stream<Account> readAccounts(String... ids)
  • 스트림이 열려 있는 상태에서 필터링이 수행됩니다.

클래스 및 메타 어노테이션으로 확장

  1. 클래스 수준 선언

    • 클래스 수준에서 @PostFilter를 선언하면 해당 클래스의 모든 메서드에 동일한 조건이 적용됩니다.

  2. 메타 어노테이션으로 정의

    • 반복적인 선언을 줄이기 위해 @PostFilter를 메타 어노테이션으로 정의할 수 있습니다.

메타 어노테이션 정의

@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@PostFilter("filterObject.owner == authentication.name")
public @interface FilterOwnedResults {}

서비스 클래스에 적용

@Component
public class BankService {
    @FilterOwnedResults
    public Collection<Account> readAccounts(String... ids) {
        return accounts;
    }
}
  • 결과:
    • 메타 어노테이션으로 정의된 조건이 readAccounts 메서드에 적용됩니다.

주의사항

  1. 메서드 반환값의 크기

    • 반환값이 크거나 데이터가 많은 경우, 필터링 작업은 메모리와 CPU에 큰 부담을 줄 수 있습니다.

  2. 데이터 계층에서 필터링 고려

    • 가능한 경우, 데이터 계층(예: 데이터베이스 쿼리)에서 조건을 필터링하여 불필요한 데이터가 애플리케이션 계층으로 전달되지 않도록 하는 것이 효율적입니다.

  3. 스트림 상태

    • 스트림을 반환하는 경우, 스트림이 열려 있어야 필터링이 올바르게 작동합니다.

장점

  1. 반환값 기반 세밀한 보안

    • 반환값의 속성을 기준으로 권한을 확인하여 불필요한 데이터 노출 방지.

  2. 코드 가독성 향상

    • 선언적으로 반환값 필터링 조건을 정의하여 보안 로직이 명확히 드러남.

  3. 유연한 데이터 구조 지원

    • 배열, 컬렉션, 맵, 스트림 등 다양한 데이터 구조에서 동작 가능.

  4. 테스트 가능

    • @WithMockUser를 통해 반환값 필터링 로직을 쉽게 검증할 수 있음.

요약

@PostFilter는 메서드 반환값에서 조건을 만족하지 않는 데이터를 제거하여 보안성을 높이는 강력한 도구입니다.
SpEL을 사용해 복잡한 조건도 처리 가능하며, 메타 어노테이션으로 확장해 반복적인 선언을 줄일 수 있습니다.
그러나 필터링이 많은 데이터를 처리할 경우 성능 비용이 발생할 수 있으므로, 필요하다면 데이터 계층에서 필터링을 수행하는 것이 권장됩니다.

@Secured를 사용한 메서드 호출 권한 부여

@Secured는 Spring Security에서 메서드 호출 권한을 부여하는 초기 방식 중 하나입니다. 현재는 @PreAuthorize가 이를 대체하며 더 강력하고 유연하기 때문에, @PreAuthorize를 사용하는 것이 권장됩니다. 그러나 @Secured도 여전히 사용할 수 있으며, 특정 상황에서 간단한 권한 부여 로직을 설정하는 데 적합할 수 있습니다.

@Secured 활성화 방법

1. Method Security 활성화

@Secured를 사용하려면 Method Security 선언에서 securedEnabled를 true로 설정해야 합니다.

@EnableMethodSecurity(securedEnabled = true)
@Configuration
public class SecurityConfig {
    // 보안 관련 설정
}
  • securedEnabled = true
    • Spring Security가 @Secured 어노테이션을 처리할 수 있도록 메서드 인터셉터를 활성화합니다.

@Secured 사용법

메서드에 @Secured 적용

@Secured는 메서드, 클래스, 인터페이스에 적용할 수 있으며, 권한을 지정하여 특정 권한을 가진 사용자만 메서드에 접근할 수 있도록 합니다.

예제 코드
@Component
public class BankService {
    @Secured("ROLE_ADMIN")
    public void performAdminTask() {
        // 관리자 작업 로직
    }

    @Secured({"ROLE_USER", "ROLE_ADMIN"})
    public void performUserTask() {
        // 사용자 및 관리자 작업 로직
    }
}

  • @Secured("ROLE_ADMIN")

    • ROLE_ADMIN 권한이 있는 사용자만 performAdminTask 메서드에 접근 가능.

  • @Secured({"ROLE_USER", "ROLE_ADMIN"})

    • ROLE_USER 또는 ROLE_ADMIN 권한이 있는 사용자는 performUserTask 메서드에 접근 가능.

테스트 코드로 확인

테스트 예제

@Autowired
BankService bankService;

@WithMockUser(roles = "ADMIN")
@Test
void performAdminTaskWithAdminRoleThenSucceeds() {
    bankService.performAdminTask();
    // 메서드 호출 성공 검증
}

@WithMockUser(roles = "USER")
@Test
void performAdminTaskWithUserRoleThenAccessDenied() {
    assertThatExceptionOfType(AccessDeniedException.class)
        .isThrownBy(() -> bankService.performAdminTask());
}

  1. @WithMockUser(roles = "ADMIN")

    • ROLE_ADMIN 권한을 가진 가상 사용자로 테스트.
    • 메서드 호출이 성공적으로 수행되는지 확인.

  2. @WithMockUser(roles = "USER")

    • ROLE_USER 권한을 가진 가상 사용자로 테스트.
    • AccessDeniedException이 발생하여 권한 부족이 제대로 동작하는지 확인.

@Secured와 @PreAuthorize 비교

1. 기능적 차이

  • @Secured: 단순히 권한(Role) 기반의 조건만 지원합니다.
    • 예: ROLE_ADMIN, ROLE_USER
  • @PreAuthorize: 권한뿐만 아니라 SpEL(Spring Expression Language)을 사용해 더 복잡한 조건을 정의할 수 있습니다.
    • 예: hasRole('ADMIN') and #user.id == authentication.name

2. 유연성

  • @Secured는 권한 확인만 가능하며, 매개변수나 반환값 기반 조건은 지원하지 않습니다.
  • @PreAuthorize는 메서드 매개변수, 인증 정보 등을 활용한 세밀한 조건을 지원합니다.

3. 권장 사용

  • @Secured는 단순한 권한 확인 로직이 필요한 경우 사용.
  • @PreAuthorize는 복잡한 보안 로직이 필요한 경우 사용.

@Secured의 장점

  1. 간단한 권한 부여 로직

    • 단순히 특정 권한(Role)만을 확인하는 경우, 코드가 짧고 간결합니다.

  2. 빠른 설정

    • 단순한 보안 로직이 필요한 애플리케이션에서 빠르게 사용할 수 있습니다.

제한사항

  1. SpEL 미지원

    • 매개변수나 반환값 기반 조건 설정 불가.
    • 예: #user.id == authentication.name 같은 조건 사용 불가.

  2. 복잡한 로직 부적합

    • 여러 조건을 결합한 복잡한 권한 부여 로직을 처리하기 어렵습니다.

  3. 유연성 부족

    • @PreAuthorize와 @PostAuthorize에 비해 기능이 제한적입니다.

요약

@Secured는 간단한 권한(Role) 기반 보안 설정에 유용하며, 활성화하려면 securedEnabled = true 설정이 필요합니다.
그러나 더 유연하고 복잡한 조건을 처리할 수 있는 @PreAuthorize를 사용하는 것이 대부분의 경우 더 적합합니다.
단순한 보안 로직을 설정할 때는 @Secured를 사용할 수 있지만, 확장성과 유지보수를 고려한다면 @PreAuthorize로 전환하는 것이 좋습니다.

JSR-250 어노테이션을 사용한 메서드 호출 권한 부여

Spring Security는 JSR-250 표준 어노테이션을 지원하며, 권한 부여를 선언적으로 정의할 수 있도록 제공합니다. 그러나 @PreAuthorize는 더 강력하고 유연한 표현력을 제공하므로 대부분의 경우 권장됩니다.

JSR-250 어노테이션 활성화

JSR-250 어노테이션을 사용하려면 @EnableMethodSecurity 설정에서 jsr250Enabled를 true로 활성화해야 합니다.

Java 예제

@EnableMethodSecurity(jsr250Enabled = true)
@Configuration
public class SecurityConfig {
    // 보안 관련 설정
}
  • jsr250Enabled = true
    • Spring Security가 JSR-250 어노테이션을 처리하도록 메서드 인터셉터를 활성화합니다.

지원되는 JSR-250 어노테이션

Spring Security는 다음과 같은 JSR-250 어노테이션을 지원합니다:

  1. @RolesAllowed
    • 특정 역할(권한)을 가진 사용자만 메서드에 접근 가능.
  2. @PermitAll
    • 모든 사용자에게 메서드 접근을 허용.
  3. @DenyAll
    • 모든 사용자에 대해 메서드 접근을 금지.

JSR-250 어노테이션 사용법

메서드에 어노테이션 적용

예제 코드
@Component
public class BankService {
    @RolesAllowed("ROLE_ADMIN")
    public void performAdminTask() {
        // 관리자 작업 로직
    }

    @PermitAll
    public void viewPublicInfo() {
        // 모든 사용자에게 공개된 정보
    }

    @DenyAll
    public void restrictedTask() {
        // 아무도 접근할 수 없음
    }
}
  • @RolesAllowed("ROLE_ADMIN")
    • ROLE_ADMIN 권한을 가진 사용자만 performAdminTask 메서드에 접근 가능.
  • @PermitAll
    • 인증 여부와 관계없이 모든 사용자가 viewPublicInfo 메서드에 접근 가능.
  • @DenyAll
    • 모든 사용자에게 restrictedTask 메서드 접근 금지.

테스트 코드로 확인

테스트 예제

@Autowired
BankService bankService;

@WithMockUser(roles = "ADMIN")
@Test
void performAdminTaskWithAdminRoleThenSucceeds() {
    bankService.performAdminTask();
    // 메서드 호출 성공 검증
}

@WithMockUser(roles = "USER")
@Test
void performAdminTaskWithUserRoleThenAccessDenied() {
    assertThatExceptionOfType(AccessDeniedException.class)
        .isThrownBy(() -> bankService.performAdminTask());
}

@Test
void viewPublicInfoThenSucceeds() {
    bankService.viewPublicInfo();
    // 인증 없이 호출 성공 검증
}

@Test
void restrictedTaskThenAccessDenied() {
    assertThatExceptionOfType(AccessDeniedException.class)
        .isThrownBy(() -> bankService.restrictedTask());
}

  1. @RolesAllowed 테스트

    • ROLE_ADMIN 권한을 가진 사용자만 메서드 호출 가능 여부를 검증.

  2. @PermitAll 테스트

    • 인증 여부와 관계없이 메서드 호출 성공 여부를 확인.

  3. @DenyAll 테스트

    • 모든 사용자에게 접근 금지됨을 검증.

JSR-250 어노테이션과 @PreAuthorize 비교

1. 표현력

  • @RolesAllowed
    • 특정 역할만 지정 가능.
  • @PreAuthorize
    • SpEL을 통해 매개변수, 인증 정보 등 복잡한 조건을 정의 가능.
    • 예: @PreAuthorize("hasRole('ADMIN') and #user.id == authentication.name")

2. 유연성

  • JSR-250 어노테이션은 간단한 권한 확인 로직에 적합.
  • @PreAuthorize는 복잡한 비즈니스 로직과 조건을 처리할 때 적합.

3. 권장 사용

  • JSR-250: 간단한 역할 기반 접근 제어.
  • @PreAuthorize: 더 세밀하고 복잡한 조건의 보안 로직 구현.

장점

  1. JSR 표준 준수

    • JSR-250 어노테이션은 Java 표준으로, Spring 외의 환경에서도 일관성을 제공합니다.

  2. 간단한 보안 로직

    • 간단한 역할 기반 권한 부여 로직을 설정하는 데 적합합니다.

제한사항

  1. SpEL 미지원

    • 반환값, 매개변수, 인증 정보를 기반으로 한 복잡한 조건 설정이 불가능합니다.

  2. 제한된 표현력

    • @PreAuthorize와 비교해 복잡한 권한 부여 로직을 구현하기 어렵습니다.

  3. Spring에 특화된 기능 부족

    • Spring Security가 제공하는 SpEL 기반의 강력한 기능을 활용하지 못합니다.

요약

JSR-250 어노테이션은 간단한 역할 기반 보안 로직에 적합하며, 표준화된 Java 어노테이션을 사용하려는 경우 유용합니다.
그러나 복잡한 조건을 정의하거나 더 유연한 보안 로직이 필요한 경우 @PreAuthorize를 사용하는 것이 권장됩니다.
jsr250Enabled를 활성화한 후 @RolesAllowed, @PermitAll, @DenyAll로 간단한 권한 제어를 구현할 수 있습니다.

클래스 및 인터페이스 수준에서의 메서드 보안 어노테이션 선언

Spring Security에서는 메서드 보안 어노테이션을 클래스와 인터페이스 수준에서도 선언할 수 있습니다. 이렇게 하면 코드의 가독성과 재사용성을 높이는 동시에, 보안 규칙을 구조적으로 관리할 수 있습니다.

클래스 수준에서 어노테이션 선언

예제 1: 클래스 수준 선언

@Controller
@PreAuthorize("hasAuthority('ROLE_USER')")
public class MyController {
    @GetMapping("/endpoint")
    public String endpoint() {
        // 메서드 로직
    }
}
  • 작동 방식:
    • 클래스에 선언된 @PreAuthorize("hasAuthority('ROLE_USER')")는 클래스 내부의 모든 메서드에 적용됩니다.
    • 즉, ROLE_USER 권한을 가진 사용자만 endpoint 메서드를 호출할 수 있습니다.
  • 장점:
    • 동일한 보안 규칙을 여러 메서드에 반복적으로 선언하지 않아도 됩니다.
    • 코드가 간결해지고 관리가 쉬워집니다.

예제 2: 클래스 및 메서드 수준에서 모두 선언

@Controller
@PreAuthorize("hasAuthority('ROLE_USER')")
public class MyController {
    @GetMapping("/endpoint")
    @PreAuthorize("hasAuthority('ROLE_ADMIN')")
    public String endpoint() {
        // 메서드 로직
    }
}

  • 작동 방식:

    • 클래스 수준에서 @PreAuthorize("hasAuthority('ROLE_USER')")가 선언되었지만, endpoint 메서드에는 @PreAuthorize("hasAuthority('ROLE_ADMIN')")가 선언되어 있습니다.
    • 메서드에 선언된 보안 규칙이 클래스 수준의 규칙을 재정의합니다.
    • 즉, endpoint 메서드는 ROLE_ADMIN 권한을 가진 사용자만 호출할 수 있습니다.

  • 장점:

    • 공통적인 보안 규칙은 클래스 수준에서 선언하고, 특정 메서드에 다른 규칙을 적용할 수 있어 유연합니다.

인터페이스 수준에서 어노테이션 선언

예제 1: 인터페이스 선언

public interface MyService {
    @PreAuthorize("hasAuthority('ROLE_USER')")
    String performTask();
}

@Service
public class MyServiceImpl implements MyService {
    @Override
    public String performTask() {
        // 메서드 로직
        return "Task performed";
    }
}
  • 작동 방식:
    • 인터페이스에 선언된 @PreAuthorize("hasAuthority('ROLE_USER')")는 이를 구현한 클래스의 메서드에 적용됩니다.
    • performTask 메서드는 ROLE_USER 권한을 가진 사용자만 호출할 수 있습니다.

예제 2: 다중 인터페이스 선언

public interface UserService {
    @PreAuthorize("hasAuthority('ROLE_USER')")
    void userTask();
}

public interface AdminService {
    @PreAuthorize("hasAuthority('ROLE_ADMIN')")
    void adminTask();
}

@Service
public class CombinedService implements UserService, AdminService {
    @Override
    public void userTask() {
        // 사용자 작업 로직
    }

    @Override
    public void adminTask() {
        // 관리자 작업 로직
    }
}

  • 문제점:

    • 클래스가 여러 인터페이스에서 서로 다른 보안 어노테이션을 상속받는 경우, Spring Security는 어떤 규칙을 사용할지 판단할 수 없습니다.
    • 결과: 애플리케이션이 시작 시 오류를 발생시킵니다.

  • 해결 방법:

    • 구체적인 메서드에 보안 어노테이션을 추가하여 모호성을 제거합니다.
    @Service
public class CombinedService implements UserService, AdminService {
    @Override
    @PreAuthorize("hasAuthority('ROLE_USER')")
    public void userTask() {
        // 사용자 작업 로직
    }

    @Override
    @PreAuthorize("hasAuthority('ROLE_ADMIN')")
    public void adminTask() {
        // 관리자 작업 로직
    }
}

요약

  1. 클래스 수준 선언

    • 클래스에 선언된 보안 규칙이 모든 메서드에 기본적으로 적용됩니다.
    • 개별 메서드에 선언된 어노테이션이 클래스 수준의 규칙을 재정의합니다.

  2. 인터페이스 수준 선언

    • 인터페이스에 선언된 어노테이션은 이를 구현한 클래스에 상속됩니다.
    • 다중 인터페이스에서 서로 다른 어노테이션을 상속받는 경우, 구체적인 메서드에 명시적으로 선언해야 모호성을 제거할 수 있습니다.

  3. 장점

    • 코드 재사용성 증가: 공통 규칙을 클래스나 인터페이스에 선언하여 중복을 줄임.
    • 유연성 확보: 특정 메서드에 별도의 규칙을 추가로 선언 가능.

  4. 주의점

    • 클래스와 메서드 수준의 어노테이션 충돌 시 메서드 규칙이 우선.
    • 다중 인터페이스 사용 시 규칙 충돌 가능성을 명시적으로 해결해야 함.
profile
김상욱
이전 포스트

Authorize HttpServletRequests

다음 포스트

Domain Object Security (ACLs)

0개의 댓글