사내 시스템 인가 프로세스를 개발할 기회가 있었다. 당시 해당 프로젝트의 개발 초기 단계에서 권한 관련 데이터베이스 스키마 구성에 대해 고민했었다. 해당 프로젝트에서 다루는 역할이 두 가지 밖에 없었고, 추가적인 역할 생성이 제한될 것으로 예상되는 상황이었기 때문이다. 무엇보다 향후 사내에서 다른 분산 서비스들을 모두 아우르는 통합 인증 인가 시스템을 개발하려는 계획이 있었다. 따라서 해당 프로젝트에서 구현하는 인증 인가를 적은 리소스를 사용하도록 효율적으로 구성해도 괜찮을 것 같았다.
그의 일환으로 권한 스키마에 대해 URL 자원 관리를 별도의 테이블로 분리하는 전통적인 접근법의 적합성을 관리와 성능 측면에서 고민해보았다. 이 글은 당시 관련 주제에 대해 탐구하며 정리했던 글이다. 주요 용어와 코드는 그대로 사용하지 않고 컨셉용으로 대체하였다.
현재 설계된 인가 시나리오는 다음과 같습니다.
먼저 클라이언트로부터 인가된 HTTP 요청이 들어오면 인가 필터를 통해 요청 처리를 시작합니다. 이 필터는 요청의 URI와 HTTP 메서드, 사용자 ID를 통해 캐시된 사용자 정보를 조회하고, 이 정보를 바탕으로 사용자의 접근 권한을 판단합니다. 사용 판단 케이스는 두 가지로 나뉩니다.
첫 번째는 사용자의 특정 주차장 권한 판단으로, URI에 포함된 주차장 접근 권한이 없는 경우 접근을 거부합니다.
두 번째는 특정 기 정의된 URL 리소스 정보에 기반한 권한 판단으로, 사용자의 역할에 따라 특정 URL에 대한 접근 권한을 확인합니다. 이를 위해 사용자 권한에 대한 정보는 RDB 형태로 영속화되어 있어야 합니다. 이상의 두 가지 프로세스를 기반으로 최종적으로 클라이언트에게 접근 허용 또는 에러 응답을 반환합니다.