Spring Security는 어느 계층의 관심사일까요?

[softmoca]

Spring Security는 필터 체인, 세션, 토큰, JWT, OAuth2 같은 기술을 다루기 때문에,
프레임워크 자체로는 Infrastructure에 가깝습니다.

하지만 Spring Security로 표현하는 규칙은 계층마다 성격이 달라질 수 있다고 생각했습니다.

예를 들어 “로그인한 사용자만 접근 가능”은 UI/Application 경계의 인증 정책에 가깝고,
“ADMIN만 관리자 API 접근 가능”은 역할 기반 접근 제어에 가깝습니다.
반면 “작성자 본인만 게시글을 수정할 수 있다”나 “매장 매니저는 자기 매장 예약만 관리할 수 있다”는,
실제 데이터를 보고 판단해야 하는 도메인 규칙에 가까울 수 있습니다.

즉, Spring Security라는 도구 자체의 소속과,
그 도구로 표현하려는 규칙의 소속은 다를 수 있다고 느꼈습니다.

질문입니다.

• Spring Security는 어느 계층의 관심사라고 생각하시나요?
• 인증과 인가는 같은 계층에서 처리해야 할까요?
• 역할 기반 접근 제어와 리소스 소유권 검사는 같은 종류의 인가일까요?
• “프레임워크 자체의 소속”과 “그 프레임워크가 표현하는 규칙의 소속”을 구분하는 것에 대해 어떻게 생각하시나요?

[koreaioi]

Spring Security는 어느 계층의 관심사라고 생각하시나요?

Spring Security는 보안 매커니즘을 담당하는 프레임워크라는 생각이 들었습니다!
Spring Security가 여러 계층에서 이로움을 제공하기 때문에, 어느 계층의 관심사라고 딱잘라 말하기는 어렵겠다는 생각이 들었으며, 이는 Spring Security가 프레임워크이기에 그런 듯합니다.

무엇을 책임지느냐로 계층을 나눈다고 생각합니다. 이때 Spring Security는 여러 계층의 실행시점에 끼어들어 책임을 보강해주는 역할을 한다고 생각합니다.

• FilterChain에 기본 SecurityFilterChain이 끼어듬 (Filter의 책임을 보강)
• @PreAuthorize를 사용하면 AOP를 기반으로 컨트롤러나 서비스에서 인가 작업 수행

인증과 인가는 같은 계층에서 처리해야 할까요? & 역할 기반 접근 제어와 리소스 소유권 검사는 같은 종류의 인가일까요?

여기서 인가를 본문에 있는 역할기반접근제어로 생각한다면,
계층은 같지만, 같은 계층 안에서 세부적으로 분리할 수 있다고 생각합니다.
Filter를 사용한다면 AuthenticationFilter, AuthorizationFilter로 분리하는 게 그 예시라고 생각합니다.

단, 인가가 리소스 소유권 검사에 대한 내용이라면, 도메인, 비즈니스 로직으로 처리하는게 좋다고 생각합니다.
비즈니스로직을 적용할 리소스가 Controller 앞단에서 처리되면, 레이어드 아키텍처의 의미가 흐려진다고 생각하기 때문입니다.

“프레임워크 자체의 소속”과 “그 프레임워크가 표현하는 규칙의 소속”을 구분하는 것에 대해 어떻게 생각하시나요?

좋다고 생각합니다. 이 구분은 실제 설계 결정으로 이어지기 때문입니다.
그리고 이런 구분을 통해, 도메인이 프레임워크에 의존하지 않는 설계를 만들 수 있다고 생각합니다.

@PreAuthorize("#post.authorId == authentication.principal.id")
public void updatePost(Post post, UpdateRequest req) { ... }

이 경우 규칙(본인이 쓴 글만 수정 가능)이 Spring Security에 의존하고 있습니다.
만약 Spring Security를 제거하거나 교체하면 이 규칙도 함께 사라지는 거죠!

반면 도메인 객체가 규칙을 직접 가지면 프레임워크를 삭제하더라도, 별 문제가 없습니다.

[sangjun121]

Spring Security는 어느 계층의 관심사라고 생각하시나요?

스프링 시큐리티를 어떤 계층의 관심사라고 딱 잘라 말하기는 어려운 것 같습니다. 말씀해주신 내용처럼 도메인 규칙과 관련된 인가작업은 MVC 내에서 일어날 수도 있으며, 애초에 접근 자체를 막아야하는 인가라면 MVC앞전의 필터단에서 수행될 필요가 있을 것이라고 생각이 드네요. 결국 시큐리티가 제공하는 도구를 통해, 서비스 요구사항과 인가의 성격에 따라 수행되는 위치를 먼저 지정하고, 도구를 적재적소로 사용하는 것이 좋을 것 같다는 생각이 듭니다.

인증과 인가는 같은 계층에서 처리해야 할까요?

이 또한 마찬가지로 서비스 요구사항에 따라 달라질 것이라고 생각하는데요, 일반적으로 인가에 앞서 이뤄지는 인증 작업은 비즈니스 영역 이전의 필터단에서 이뤄지는 경우가 많고, 인가는 성격에 따라 마찬가지로 비즈니스 이전의 영역이나, MVC 내부에서도 이뤄질 수 있다고 생각합니다.

예를 들어, 운영진A가 테니스 동아리의 회원이면서 코딩 동아리의 회장이라고 가정한다면, 로그인 유무와 상관없이 소속과 관련된 별도의 인가 작업이 필요합니다. 해당 정보를 테이블에서 관리하고 있다면, API 접근에 앞서 AOP와 같은 도구를 사용하여 인가 작업을 수행해줄 수도 있을 것 같은데요, 결국 데이터에 접근하고 비즈니스 규칙과 짙은 연관이 있기에 MVC 내부에서 인가작업을 진행하는 것이 저는 더 좋을 것 같다는 생각이 들었습니다.

결론적으로 서비스 요구사항에 따라 계층 위치가 결정될 것 같으며 고정된 것은 없다고 생각합니다. 이 주제와 유사하게 필터 내부의 예외를 MVC로 내릴지 말지 고민했던 과정이 있었는데요, 결국 특정 인가가 요구사항에 맞게 MVC 내에서 수행되었기에, MVC 내에서 함께 처리했던 경험이 있어 공유합니다. 블로그 포스트

역할 기반 접근 제어와 리소스 소유권 검사는 같은 종류의 인가일까요?

마찬가지로 둘다 인가 작업이지만 레벨이 다르다고 생각합니다. 일반적으로는 역할 기반 접근 제어가 선행되고, 해당리소스가 현재 사용자에게 속해있는지 확인하는 과정과 같은 리소스 소유권 검사가 연이어 진다고 생각이 드네요.

“프레임워크 자체의 소속”과 “그 프레임워크가 표현하는 규칙의 소속”을 구분하는 것에 대해 어떻게 생각하시나요?

프레임워크가 어떤 레이어에 소속되는가를 정할 필요가 있냐라는 질문으로 해석했는데요, 물론 각 프레임워크가 통용적으로 소속되는 레이어가 있을 수 있다고 생각합니다. 시큐리티의 경우에도 보통 핵심 비즈니스 레이어 이전에 인증/인가를 처리하는 도구를 지원하니까요. 다만 프레임워크의 성격에 따라서는 이렇게 딱 잘라 정하기는 어려운 것 같습니다.

규칙의 소속 또한 결국 요구사항이 비즈니스 규칙과 연관이 짙다면 비즈니스 레이어로 내리고, 이외 부가 시스템 레벨이나 비즈니스와는 무관한 규칙이라면 이와 독립적인 곳에 위치시키는 것이 좋아보입니다.