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

2024.05.05 - [Study/Java] - Spring Security 적용기 (5) Spring Security Authentication 동작원리

Spring Security 적용기 (5) Spring Security Authentication 동작원리

 

지난 시간에 이어 이번에는 Spring Security의 Authorization 작동 원리와 HttpRequest에 대한 인가 방법에 대해 알아보았다. 

이번 포스팅 역시 스프링 공식문서를 참고하였다.

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

Authorization :: Spring Security

---

개요

사용자의 인증 방법을 설정한 후에는 애플리케이션의 권한 부여 규칙을 구성해야 한다.

스프링 시큐리티는 스프링 시큐리티에서 제공하는 인증 방법을 사용하든지 혹은 다른 인증 방법과 통합하여 사용하든지와는 관계 없이, 권한 부여 서비스를 일관되고 간단한 방식으로 애플리케이션 내에서 사용할 수 있다. 

 

권한 규칙 부여는 요청 URI 및 메소드에 규칙을 부여하는 것이 좋다. 아래의 내용에서 요청 URI에 대한 권한 부여 작업 방식에 대해 상세히 다뤄보도록 하겠다. 

---

⚙️Authrization Architecture

Authorities

인증(Authentication) 과정에서는 사용자가 제공한 인증 자격 증명을 검증하고, 그 결과로 인증된 사용자 객체가 생성된다. 

이 인증된 사용자 객체는 사용자가 가지는 권한을 나타내는 객체를 포함한다. 이러한 객체들을 "GrantedAuthority"라 하며, 일반적으로 사용자가 접근할 수 있는 특정 리소스 또는 기능을 나타낸다. 

 

GrantedAuthority는 AuthenticationManager에 의해 Authentication 객체에 삽입되며,

나중에 AccessDecisionManager는 GrantedAuthority들을 사용하여 사용자가 특정 리소스나 기능에 엑세스 할 수 있는지 여부를 결정한다. 

따라서 이러한 GrantedAuthority는 사용자가 권한부여 결정을 내릴 때 필수적인 정보이다. 

 

GrantedAuthority 인터페이스는 단 하나의 메서드를 가지고 있다. 

String getAuthority();

 

해당 메서드는 AuthorizationManger 인스턴스가 GrantedAuthority의 정확한 문자열 표현을 얻기 위해 사용된다. 

만약, GrantedAuthority를 문자열로 정확히 표현될 수 없는 경우, GrantedAuthority는 복잡(complex)하다고 여겨지며 getAuthority()는 null을 반환해야 한다. 

 

Spring Security는 GrantedAuthority 인터페이스를 구현한 SimpleGrantedAuthority 구현체를 포함하고 있다. 이 구현체는 사용자가 지정한 문자열을 GrantedAuthority로 변환할 수 있다. 보안 아키텍처와 함께 제공되는 모든 AuthenticationProvider 인스턴스는 SimpleGrantedAuthority를 사용하여 Authentication 객체를 채운다. 

 

기본적으로 역할 기반의 권한 부여 규칙은 ROLE_을 접두어로 사용한다. 

또한 GrantedAuthorityDefaults를 사용하여 사용자 정의할 수 있다. 

 

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

 

GrantedAuthorityDefaults를 정적 메서드로 노출하여 Spring이 Spring Security의 메서드 보안 @Configuration 클래스를 초기화하기 전에 해당 빈을 게시하도록 한다. 

---

⚙️Invocation Handling

Spring Security는 메서드 호출이나 웹 요청과 같은 보안 객체에 대한 엑세스를 제어하는 인터셉터를 제공한다. 

AuthorizationManager 인스턴스는 메서드 호출 혹은 웹 요청이 진행될 수 있는지에 대한 사전 호출 결정을 내린다. 

주어진 값이 반환될 수 있는지에 대한 사후 호출 결정 또한 AuthorizationManager에 의해서 이루어진다. 

 

The AuthorizationManager

AuthorizationManager는 AccssDecisionManager와 AccessDecisionVoter를 대체한다. 

즉 이전에는 AccssDecisionManager 및 AccessDecisionVoter를 사용하여 엑세스 결정을 수행했지만, 이제는 AuthorizationManager를 사용하도록 권장한다. 

 

AuthorizationManager는 Spring Security의 요청 기반, 메서드 기반 및 메시지 기반 인가 구성 요소에서 호출되며 최종 엑세스 제어 결정을 담당한다. AuthorizationManager 인터페이스에는 두 개의 메서드가 포함되어 있다. 

 

//인가 결정을 내리기 위해 필요한 모든 관련 정보를 전달 받는다. 
//특히, 보안 객체를 전달함으로써 실제 보안 객체 호출에 포함된 인수를 검사할 수 있다. 
//엑세스 허용 -> 양수의 AuthorizationDecision, 거부 -> 음수의 AuthorizationDecision 
//결정을 내리지 않는 경우 null AuthorizationDecision 반환
AuthorizationDecision check(Supplier<Authentication> authentication, Object secureObject);

//check를 호출하고 AuthorizaitonDecision이 음수인 경우 AccessDeniedException을 throw
default AuthorizationDecision verify(Supplier<Authentication> authentication, Object secureObject)
        throws AccessDeniedException {
    // ...
}

 

Delegate 기반의 AuthorizationManager 구현

사용자들은 인가(authorization)의 모든 측면을 제어하기 위해 직접 AuthorizationManager를 구현할 수 있지만, 

Spring Security느 개별 AuthorizationManager와 협력할 수 있는 위임(delegate) 형식의 AuthorizationManager를 제공한다. 

 

요청에 대한 인가를 위해서는 RequestMatcherDelegatingAuthorizationManager,

메서드 보안의 경우 AuthorizationMangerBeforeMethodInterceptor와 AuthorizationManagerAfterMethodInterceptor를 사용할 수 있다. 

 

Authorization Manager Implementations

 

Hierarchical Roles

어떤 애플리케이션에서 특정 역할이 다른 역할을 자동으로 포함해야 하는 경우가 일반적이다. 

예를들어 관리자와 사용자 역할이 있는 애플리케이션에서 관리자는 일반 사용자가 할 수 있는 작업을 모두 수행할 수 있다.

이러한 경우 역할 계층을 사용하면 어떤 역할 혹은 권한이 다른 역할을 포함해야 하는지를 구성할 수 있다. 

Spring Security의 RoleVoter의 확장된 버전인 RoleHierarchyVoter RoleHierarchy로 구성되며, 사용자에게 할당된 모든 도달 가능한 권한을 얻는다. 

 

일반적인 구성은 아래와 같다. 

@Bean
static RoleHierarchy roleHierarchy() {
    RoleHierarchyImpl hierarchy = new RoleHierarchyImpl();
    hierarchy.setHierarchy("ROLE_ADMIN > ROLE_STAFF\n" +
            "ROLE_STAFF > ROLE_USER\n" +
            "ROLE_USER > ROLE_GUEST");
    return hierarchy;
}

// and, if using method security also add
@Bean
static MethodSecurityExpressionHandler methodSecurityExpressionHandler(RoleHierarchy roleHierarchy) {
	DefaultMethodSecurityExpressionHandler expressionHandler = new DefaultMethodSecurityExpressionHandler();
	expressionHandler.setRoleHierarchy(roleHierarchy);
	return expressionHandler;
}

 

위의 코드에서는 4가지 역할(ADMIN, STAFF, USER, GUEST)을 가지고 있으며, ">" 기호는 포함을 의미한다. 

역할 계층은 애플리케이션의 접근 제어 구성 데이터를 간편하게 단순화하거나, 사용자에게 할당해야 하는 권한 수를 줄이는 편리한 방법을 제공한다. 더 복잡한 요구사항의 경우, 애플리케이션이 필요로 하는 특정 액세스 구너한과 사용자에게 할당된 역할 간의 논리적 매핑을 정의하여, 사용자 정보를 로드할 때 이 둘 사이를 변환할 수 있다. 

 

단 RoleHierarchy 빈 구성은 아직 @EnableMethodSecurity로 이전되지 않았다. 따라서 이 예제는 AccessDecision Voter를 사용하고 있다. 메서드 보안에 RoleHierarchy 지원이 필요한 경우, github.com/spring-projects/spring-security/issues/12783 이슈가 완료될 때까지 @EnableGlobalMethodSecurity를 계속 사용해야 한다. 

→ 현재는 @EnableMethodSecurity에서 RoleHierarchy를 함께 사용할 수 없음.

→ 사용하려면 Spring Seucirty 설정 클래스에 @EnableGlobalMethodSecurity 어노테이션을 사용해 메서드 보안을 활성화할 수 있음

 

@EnableGlobalMethodSecurity(prePostEnabled = true)
@Configuration
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration {

     @Bean
     public RoleHierarchy roleHierarchy() {
        RoleHierarchyImpl roleHierarchy = new RoleHierarchyImpl();
        // 역할 계층 구성
        roleHierarchy.setHierarchy("ROLE_ADMIN > ROLE_USER");
        return roleHierarchy;
      }
    // 추가적인 설정
}

---

⚙️Authorize HttpServletRequests

 

Spring Security를 사용하면 요청 수준에서 권한을 모델링 할 수 있다. 예를 들어, Spring Security를 사용하면 /admin 하위의 모든 페이지에는 하나의 권한이 필요하고, 다른 모든 페이지에는 간단히 이증만 필요하다고 할 수 있다. 

 

기본적으로 Spring Security는 모든 요청에 인증이 필요하다. 그렇지만 HttpSecurity 인스턴스를 사용하는 경우마다 권한 부여 규칙을 선언해야 한다. 

 

http
    .authorizeHttpRequests((authorize) -> authorize
        .anyRequest().authenticated()
    )

 

해당 코드는 애플리케이션의 모든 엔드포인트가 이를 허용하기 위해서는 인증이 필요하다는 것을 Spring Security에 알려준다.

 

Authorize HttpServletRequest

 

기본적으로 AuthorizationFilter는 Spring Security 필터 체인에서 마지막에 위치한다. 따라서 그 이전에 존재하는 인증, 악용방지등의 필터는 권한이 필요하지 않다. AuthorizationFilter 이전에 자체 필터를 추가해도 이 필터는 권한이 필요하지 않다. 그러나 Spring MVC 엔드포인트를 추가할 때는 상황이 달라진다. DispatcherServlet에 의해 실행되므로 이는 AuthorizationFilter 이후에 실행되며, 엔드포인트가 허용되려면 authorizeHttpRequests에 포함되어야 한다. 

 

다음은 /endpoint가 USER 권한을 가진 최종 사용자에 의해서만 접근 가능하도록 요구하려면 아래와 같이 작성할 수 있다. 

 

@Bean
SecurityFilterChain web(HttpSecurity http) throws Exception {
	http
		.authorizeHttpRequests((authorize) -> authorize
			.requestMatchers("/endpoint").hasAuthority("USER")
			.anyRequest().authenticated()
		)
        // ...

	return http.build();
}

 

만약 /endpoint가 엔드포인트가 아닌 /resource 디렉터리 아래의 모든 엔드포인트를 매칭하고 싶다면 아래와 같이 작성할 수 있다. 이는 요청이 /resource 또는 하위 디렉터리인 경우 USER 권한을 요구하고 그렇지 않으면 인증만 필요로 한다고 읽을 수 있다. 

 

http
    .authorizeHttpRequests((authorize) -> authorize
        .requestMatchers("/resource/**").hasAuthority("USER")
        .anyRequest().authenticated()
    )

 

또한, 아래와 같이 경로에서 경로 값을 추출할 수도 있다. 

 

http
    .authorizeHttpRequests((authorize) -> authorize
        .requestMatchers("/resource/{name}").access(new WebExpressionAuthorizationManager("#name == authentication.name"))
        .anyRequest().authenticated()
    )

 

정규표현식을 이용하여 매칭이 가능하다. 

예를 들어, 사용자 이름을 포함하고 모든 사용자 이름이 알파벳과 숫자로만 이루어져야 하는 규칙이 있는 경우 RegexRequestMatcher를 사용하여 해당 규칙을 준수할 수 있다. 

아래의 코드는 요청이 /resouce/[A-Za-z0-9]+와 일치하면 USER 권한을 요구하고, 그렇지 않은 모든 요청은 거부한다고 읽을 수 있다. 

 

http
    .authorizeHttpRequests((authorize) -> authorize
        .requestMatchers(RegexRequestMatcher.regexMatcher("/resource/[A-Za-z0-9]+")).hasAuthority("USER")
        .anyRequest().denyAll()
    )

 

HTTP 메서드별로 규칙을 매칭할 수도 있다. 이 방법은 부여된 권한 기준으로 권한을 부여할 때이다. 

예를 들어, 모든 GET 요청이 읽기 권한을 가져야 하고, 모든 POST 요청이 쓰기 권한을 가져야 한다면 아래와 같이 사용할 수 있다. 

 

http
    .authorizeHttpRequests((authorize) -> authorize
        .requestMatchers(HttpMethod.GET).hasAuthority("read")
        .requestMatchers(HttpMethod.POST).hasAuthority("write")
        .anyRequest().denyAll()
    )

 

위의 다양한 예제와 같이 요청이 일치하면 permitAll, denyAll, hasAuthority와 같은 여러 가지 방법으로 인증할 수 있다. 

DSL에 내장된 권한 부여 규칙은 아래와 같다. 

 

permitAll : 요청에 대한 인증이 필요하지 않으며 공개 엔드포인트. 이 경우에는 세션에서 인증을 가져오지 않는다. 
denyAll : 어떠한 경우에도 요청을 허용하지 않는다. 이 경우에도 세션에서 인증을 가져오지 않는다. 
hasAuthority : 인증이 주어진 값과 일치하는 GrantedAuthortiy를 가져야 한다. 
hasRole : ROLE_ 접두사를 추가하여 hasAuthority의 단축키이다. 
hasAnyAuthority : 인증이 주어진 값 중 하나와 일치하는 GrantedAuthority를 가져야 한다. 
hasAnyRole : ROLE_ 접두사를 추가하여 hasAnyAuthority의 단축키이다. 
access : 사용자 정의 AuthorizationManager를 사용하여 액세스를 결정한다.

 

 

Security Matchers를 사용하여 HttpSecurity를 적용할 요청을 결정할 수 있다. 

@Configuration
@EnableWebSecurity
public class SecurityConfig {

	@Bean
	public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
		http
			.securityMatcher("/api/**")                            
			.authorizeHttpRequests(authorize -> authorize
				.requestMatchers("/user/**").hasRole("USER")       
				.requestMatchers("/admin/**").hasRole("ADMIN")     
				.anyRequest().authenticated()                      
			)
			.formLogin(withDefaults());
		return http.build();
	}
}

 

위의 코드의 경우 /api/user, /api/admin과 같은 경로로 요청이 들어온 경우에 authorizHttpRequest 설정이 된다는 의미로, 

보안 필터 체인에 대한 설정이 적용되는 요청을 지정하기 위해 사용한다.