Spring Security RBAC 설정, @PreAuthorize 로 쌈@뽕하게 관리하기

1. 개요

진행 중인 프로젝트의 api 개수가 어느새 90개가 다되간다.

 

Spring Security를 사용하여 RBAC(Role-Based Access Control)을 구현 하고있고, 이 설정은 Security Config에서 관리하고 있다. 새로운 엔드포인트를 개발할 때마다 기존의 설정과 잘 매칭되는지 확인해야 했고, 그렇지 않다면 추가적인 설정이 필요했다.

 

이러한 과정 때문에 지금까지 개발된 API들에 RBAC이 제대로 적용되었는지 확인하기 어렵고, 놓친 부분을 점검하는 것도 번거로운 작업이 필요했다. 

 

URL에 prefix로 ROLE을 추가하여 일괄적으로 관리하는 방법을 고려해 보았지만, 보안상 좋은 방법이 아니라는 피드백을 여러 차례 받았다. 

 

 

 

다른 방법은 없을까 알아보다, 어노테이션으로써 관리할 수 있는 기능에 대해 알게 되었고 현재 마주한 불편한 점들을 해결할 수 있을 것 같아 정리 후 프로젝트에 적용하고자 한다. 

 

 

 

 

 

 

 

2. @Secured

@Secured는 특정 권한만 접근이 가능하다는 것을 나타내는 Annotation이다. 

간단하게 특정 기능은 Admin만 이용하게 하고 싶은 경우 위의 Annotation을 붙여주면 된다. 

 

public class ProjectController {

    private final ProjectService projectService;

    @PostMapping("/api/v1/project")
    @Secured("ROLE_ADMIN")
    public String save(@RequestBody ProjectSaveRequestDto requestDto) throws DuplicateException {

        return projectService.save(requestDto);
    }
}

 

일반적으로 컨트롤러의 메소드 레벨에 붙여 사용하는데, @Secured 같은 경우에는 컨트롤러에 매핑된 URI가 호출되면 메소드 실행 전, @Secured에 value의 권한을 갖는지 여부를 먼저 확인하고, 권한을 갖는 경우에만 해당 메소드를 실행한다. 

 

 

 

 

 

 

 

3. @PreAuthorize

public class ProjectController {

    private final ProjectService projectService;

    @PostMapping("/api/v1/project")
    @PreAuthorize("hasRole('ROLE_MANAGER') or hasRole('ROLE_ADMIN')")
    public String save(@RequestBody ProjectSaveRequestDto requestDto) throws DuplicateException {

        return projectService.save(requestDto);
    }
}

 

@Secured 와 달리 조건식을 사용하여 접근 레벨을 설정할 수 있다. 

또한 조건식을 사용하기 때문에 AND, OR 을 사용하여 접근 레벨을 여러 개 설정할 수도 있다. 

 

 

 

# 표현식 종류

• hasRole([role]) : 현재 사용자의 권한이 파라미터의 권한과 동일한 경우 true
• hasAnyRole([role1,role2]) : 현재 사용자의 권한디 파라미터의 권한 중 일치하는 것이 있는 경우 true
• principal : 사용자를 증명하는 주요객체(User)를 직접 접근할 수 있다.
• authentication : SecurityContext에 있는 authentication 객체에 접근 할 수 있다.
• permitAll : 모든 접근 허용
• denyAll : 모든 접근 비허용
• isAnonymous() : 현재 사용자가 익명(비로그인)인 상태인 경우 true
• isRememberMe() : 현재 사용자가 RememberMe 사용자라면 true
• isAuthenticated() : 현재 사용자가 익명이 아니라면 (로그인 상태라면) true
• isFullyAuthenticated() : 현재 사용자가 익명이거나 RememberMe 사용자가 아니라면 true

 

 

hasRole 로도 권한 여부를 체크할 수 있지만 Method로도 구현 가능하다. 

 

webSecurity라는 Bean/Component에 정의된 public boolean 메서드를 이용해 권한 여부를 체크할 수 있다.

@PreAuthorize("@webSecurity.checkAuthority(authentication, #loginId)")
public ResponseEntity<?> getUserInfo(@AuthenticationPrincipal PrincipalDetails principalDetails,
                        @PathVariable(name = "loginId") String loginId)

 

@Component("webSecurity")
public class WebSecurity {

    public boolean checkAuthority(Authentication authentication, String loginId) {
        if(authentication.getAuthorities().contains(new SimpleGrantedAuthority("ROLE_COMPANY"))
                || loginId.equals("me")) {
            return true;
        }else {
            return false;
        }

    }
}

 

 

 

 

 

 

 

 

4. 리펙토링 진행

기존의 security config 파일의 RBAC 설정 부분은 아래와 같다. 일부를 제외하곤 여기서 설정했던 권한을 PreAuthorize 어노테이션을 사용하여 변경할 예정이다. 

 

 

PreAuthorize는 다음과 같이 설정하는데 String 타입이기 때문에 개발자들의 실수를 컴파일 단계에서 잡을 수 없다. 따라서 별도의 커스텀 어노테이션을 적용하여 사용하기로 했다. 

 

 

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

}

 

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@PreAuthorize("isAuthenticated()")
public @interface AuthenticatedRequired {

}

 

@RestController
@RequiredArgsConstructor
@Slf4j
@CompanyRoleRequired // 권한 설정
public class ProjectController {

    private final ProjectService projectService;

    // 생략 .. 
}

 

위와 같이 어노테이션을 생성해주었고 클래스, 메소드 레벨에 각각 적용시켜주었다. 

 

 

 

 

하지만 예외 처리에서 문제가 발생했다.

 

인증, 인가에 관련한 예외는 다음과 같이 시큐리티 필터를 오버라이딩 하여 예외 처리를 해주고 있었다. 

@Component
@RequiredArgsConstructor
@Slf4j
public class AccessDeniedHandlerImpl implements AccessDeniedHandler {

    private final ObjectMapper objectMapper;

    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response,
        AccessDeniedException accessDeniedException) throws IOException, ServletException {
        log.error("접근 권한이 없습니다.");
        response.setCharacterEncoding("UTF-8");
        response.setContentType("application/json;charset=UTF-8"); // JSON 응답을 UTF-8로 설정
        response.setStatus(HttpStatus.FORBIDDEN.value());
        response.setContentType(APPLICATION_JSON_VALUE);
        response.getWriter().write(objectMapper.writeValueAsString(new Response<String>("접근 권한이 없습니다.")));
        response.getWriter().flush();
        response.getWriter().close();
    }
}

@Component
@RequiredArgsConstructor
@Slf4j
public class AuthenticationEntryPointHandlerImpl implements AuthenticationEntryPoint {

    private final ObjectMapper objectMapper;

    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response,
        AuthenticationException authException) throws IOException, ServletException {
        log.error("인증이 필요합니다.");
        response.setCharacterEncoding("UTF-8");
        response.setContentType("application/json;charset=UTF-8"); // JSON 응답을 UTF-8로 설정
        response.setStatus(HttpStatus.UNAUTHORIZED.value());
        response.setContentType(APPLICATION_JSON_VALUE);
        response.getWriter().write(objectMapper.writeValueAsString(new Response<String>("인증이 필요합니다.")));
        response.getWriter().flush();
        response.getWriter().close();
    }
}

 

 

기존엔 스프링 시큐리티 필터 체인을 타면서 예외가 발생하여, ControllerAdvice에선 예외를 잡지 못했었다. 하지만 @PreAuthorize 어노테이션을 사용할 경우, Controller 단에서 예외가 발생하였고, ControllerAdvice의 아래 로직에서 예외가 잡혔다. 

 

 

예외가 터지면 잡힐 때 까지 앞으로 throw를 하게 되는데, ControllerAdvice는 Servlet에서 터진 예외를 잡기 때문이다. 

 

 

@ControllerAdvice
@Slf4j
@RequiredArgsConstructor
public class ExceptionController {

    private final SlackService slackService;
    
    @ExceptionHandler(Exception.class)
    public ResponseEntity<?> handleUnhandledException(Exception e) {
        logError(e);
        sendSlackNotification(e);
        return ResponseEntity.badRequest().body(new Response<>(e.getMessage()));
    }
}

 

모든 예외를 완벽하게 제어할 수 없기 때문에, 처리하지 못한 예외가 발생할 경우 Exception으로 잡아 처리하고 있었다.

 

하지만 권한이 없는 상태에서 요청을 보내면 AccessDeniedException이 발생했고, 이 예외는 인증되지 않은 상태에서도 동일하게 발생했다.

 

401과 403 에러가 각각 다른 예외로 발생했다면 ControllerAdvice에서 간단히 예외 처리를 할 수 있었겠지만, 같은 예외가 발생했기 때문에 아래와 같이 별도로 예외를 잡아 그대로 throw 하도록 처리하였다.

 

// 시큐리티 필터에서 예외 처리하도록
@ExceptionHandler(AccessDeniedException.class)
public void handleOptimisticLockException(AccessDeniedException e) {
    throw e;
}

 

 

이렇게 함으로써 서블렛 보다 스프링 시큐리티가 더 앞단에 있기 때문에 기존에 사용하고 있던 ExceptionHandler를 그대로 사용할 수 있었다.