세션 기반 사용자 인가 구현 : URL 패턴 기반 인가 설정

 - URL 패턴 기반 인가(Authorization) 개념

 - HttpSecurity.authorizeRequests() 메서드를 활용한 권한 설정 방법

 - requestMatchers(), hasRole(), hasAuthority(), access() 메서드의 차이

 - 권한 계층 구조(Role Hierarchy) 를 설정하여 실무에서 효율적으로 권한 관리하기

 - 예제와 다이어그램을 통해 인가 흐름 이해하기

---

URL 패턴 기반 인가 설정하기

세션 기반 인증이 완료된 후, 사용자가 특정 URL 에 접근할 수 있는지에 대한 것을
URL 패턴 기반 인가 설정을 통해 제어할 수 있다

Security 에서는 HttpSecurity 의 authorizeHttpRequests() 메서드를 사용하여 URL 별 접근 권한을 설정한다

 

    @Bean
    @Order(1)
    public SecurityFilterChain sessionFilterChain(HttpSecurity http, 
                    CustomUserDetailsService customUserDetailsService) throws Exception {
        http
                .userDetailsService(customUserDetailsService)
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/login","/session-expired", "/css/**").permitAll()
                        .requestMatchers("/admin/**").hasRole("ADMIN")
                        .requestMatchers("/user/**").hasAnyRole("USER", "ADMIN")
                        .requestMatchers("/public/**").permitAll()
                        .anyRequest().authenticated()
                )
                .formLogin(form -> form
                        .loginPage("/login")
                        .defaultSuccessUrl("/", true)
                        .permitAll()
                 );
        return http.build();
    }

 

 

1. authorizeHttpRequests() 기본 구조

메서드 종류	설명
requestMatchers()	URL 패턴을 지정함
hasRole(), hasAnyRoles()	특정 역할(Role, Roles()) 이 있어야 접근을 허용함
hasAuthority()	특정 권한(Authority) 이 있어야 접근을 허용함
access()	SpEL 표현식으로 접근 제어 가능
permitAll()	누구나 접근 가능
authenticated()	인증된 사용자만 접근 가능

 

 

팁

• /admin/** 처럼 와일드카드 패턴을 활용해서 도메인 이후 전체 경로를 제어할 수 있다
• 인증이 필요 없는 페이지(/login, /public/**) 는 반드시 permitAll() 을 적용해야한다
• anyRequest(), authenticated() 를 마지막에 넣어서, 지정하지 않은 URL은 기본적으로 인증을 요구하도록 설정하는게 편하다

 

정리

authorizeHttpRequests()	URL 패턴 기반 인가 설정
requestMatchers()	접근 제어할 URL 패턴 지정하기
hasRole()	특정 역할 필요
hasAuthority()	특정 권한 필요

 

---

다양한 매처와 권한 설정하기

Spring Security 는 URL 접근 제어시 여러 메서드를 제공하고 있다

 

1. hasRole()

.requestMatchers("/admin/**").hasRole("ADMIN")
.requestMatchers("/user/**").hasAnyRole("USER", "ADMIN")

 

사용자가 ROLE_ADMIN 권한을 가지고 있어야 접근할 수 있다

hasRole("ADMIN") 은 내부적으로 ROLE_ prefix 가 붙는다

 

 

2. hasAuthority()

.requestMatchers("/reports/**").hasAuthority("REPORT_VIEW")

 

사용자가 특정 권한을 가지고 있어야 접근할 수 있다

ROLE_ prefix가 자동으로 붙지 않기 때문에, 직접 권한명을 정의할 수 있다

 

 

3. access()

.requestMatchers("/dashboard/**").access("hasRole('ADMIN') and hasAuthority('DASHBOARD_VIEW')")

 

SpEL(Spring Expression Language) 을 활용하여 복잡한 조건을 지정할 수 있다

관리자 권한이 있으면서, 동시에 DASHBOARD_VIEW 권한도 있어야 접근 허용하게끔 함

 

 

팁

• hasRole()은 단순 역할(Role) 제어에 적합함
• hasAuthority() 는 세밀한 권한 관리가 필요한 경우에 사용함
• access() 는 복잡한 조건식을 사용할 때 적합하지만, 유지보수성을 고려해야함

 

메서드	특징
hasRole()	ROLE_ prefix 자동 적용
hasAuthority()	prefix 없이 권한을 직접 지정함
access()	SpEL 로 복잡한 조건을 처리함

 

---

권한 계층 구조(Role Hierarchy)

실무에서 권한(Role)이 여러 단계로 구성되는 경우가 많다

ADMIN 은 USER 가 할 수 있는 모든 작업을 포함해야 함

 

Security에서 Role Hierarchy 를 설정해서 계층 구조를 지정할 수 있다

 

1. 예제

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.access.hierarchicalroles.RoleHierarchy;
import org.springframework.security.access.hierarchicalroles.RoleHierarchyImpl;

@Configuration
public class RoleHierarchyConfig {

    @Bean
    public RoleHierarchy roleHierarchy() {
        RoleHierarchyImpl roleHierarchy = new RoleHierarchyImpl();
        roleHierarchy.setHierarchy("ROLE_ADMIN > ROLE_USER"); // 지원 중단
        return roleHierarchy;
    }
}

 

 

예제에서 RoleHierarchy 를 통해 ROLE_ADMIN 이 ROLE_USER 의 모든 권한을 자동으로 상속하게 만든다

 

 

2. 계층 구조 동작 원리

RoleHierarchy 를 통해 ROLE_ADMIN 은 ROLE_USER의 권한을 함께 갖는다

 

 

ROLE_ADMIN 을 가진 사용자는 ROLE_USER 권한이 필요한 페이지에도 접근할 수 있게 된다

 

 

팁

• 권한이 많아질수록 계층 구조를 정리하면 관리가 쉬워진다
• 계층이 깊어지면 직관성이 떨어질 수 있으므로, 문서화가 필요하다
• 권한 이름은 일관된 네이밍 규칙(ROLE_ prefix)을 유지해야한다

항목	설명
Role Hierarchy	권한 계층 구조 설정 기능
예시	ROLE_ADMIN > ROLE_USER
장점	중복 설정 제거, 관리가 용이함